GooBiz

Identity : Controled Evolution in SOA

Intent : Ensuring coherent evolution to service components of the system according to changes captured on higher-level business requirements and allowing actors of the application system to use these behaviours.

Solution Step 1 : Changes are assigned as operations, classes or components to appropriate goal structures of the system able to control directly achievement of related behaviours. This ensures better propagation of the changes allowing underlying structures of the system evolve coherently with the evolution of their parent goal.

Solution Step 2 : Impacts of the changes are traced throughout the system in order to allow actors of the application layer to use changed business behaviours. The related propagation of the changes is supported by refinement and traceability capabilities offered by the Pattern for Evolvable Service Specifications (PESS) and by the Pattern for Traceable Abstraction Layers (PTAL) that aims at closing the gap between business and application layers.

 

Explanation Step 1 :

This pattern assists analysts and designers in the identification of goal components and classes able to support changes, based on inputs from the business experts. In order to confering to the system a coherent evolution according to its existing business goals, behaviors related to changes are to be plugged into appropriate goal structures of the existing system that are able to host them .

These behaviours are inserted as operations or as classes respectively within existing classes or components (composites of classes) of the system that are able to control directly their evolution.

 

 

Explanation Step 2 :

Impacts of the changes are traced throughout chains of refinement of operations (Ref: Pattern for Evolvable Service Specifications-PESS).

Consequently, responsibilities of actors of the application system are reconfigured (Ref: Pattern for Traceable Abstraction Layers (PTAL) ) according to these changes.

As an example to the propagation of the changes using step 1 and step 2, the figure below shows new requirements that are to be mapped onto an initial business process architecture of the system WebSite [Turn visitor into buyer].

 

Figure 1 : New requirements are to be mapped into components of the existing business architecture being driven by goals

 

There are different manners for mapping new requirements (changes) onto the existing architecture of the system.

An initial mapping implements them as operations on the existing service component of the system. If in addition the related behaviors need to be identified separately, operations are rendered identifiable (reified) using underlying service components,  by applying the Pattern for Evolvable Specifications (PESS) . So, these underlying components are inserted in the business architecture as new components as indicated on the example shown below.

 

Figure 2 : New requirements are mapped inside appropriate components of the business architecture

 

Conclusion (Forces of the pattern PCE) : 

 

This pattern confers a controled evolution to service components of the system according to changes captured on higher-level business requirements and allows actors of the application system to use these behaviours in coherence.

 

 

Relationships : The pattern PCE requires contributions from PESS (Evolvable Service Specifications), PTAL (Traceable Abstraction Layers) and PUBS-AL (Using Service Specifications). Its relationships with these patterns of the GD-SOA are illustrated below.

 

 

 

 

 

Figure 3 : Relationships between the pattern PCE and other patterns for the Goal-Driven SOA : Click on each referenced pattern icon to visualise its detailed description