GooBiz

Identity :Traceable Abstraction Layers

Intent : Closing the gap between the business and application layers in order to align IT actors and service components to the changes on the business needs. 

Solution : Ensure traceability of specifications between these layers by assigning relevant responsibilities to actors and service components of the application layer in order to allow them realize behaviours of the business services as described in the business layer.

 

 

Explanation :

 

The solution is explained below in 4 steps :

 

Step 1 : Specify actions of business services and responsibilities of their participants at the analysis level

Step 2 : Bridge analysis level specifications with the design level ones at the CIM level of the MDA

Step 3 : Transform CIM level specifications into PIM level ones

Step 4 : Plug-in PIM level service specifications into the Goal-Driven SOA (GD-SOA) Framework

 

 

Step 1 : Specify actions of business services and responsibilities of their participants at the analysis level

 

In order to model communication between business services then fix out responsibilities of the actors of the IT system in their contribution to their realisation, an activity diagram may be used.

 

The pseudo activity diagram below illustrates a draft overview on the interactions between business services and the assignment of the responsibility "turning visitor into buyer" to the Sales_Manager once a new visitor is registered in the system. This responsibility is expressed using the object-in-state Sales_Mgr [turn to buyer] .

 

Figure 1 : Modeling high-level collaborations between business processes and responsibilities assigned to their participants using a pseudo Activity Diagram without swimlanes

 

 

As illustrated in steps 2 and 3 below, such a representation of the business cartography brings the advantage that ensures a 1 to 1 traceability relationship between the CIM and the PIM level representations. In this sense, it helps for automating the CIM to PIM transformation.

 

 

On the basis of interactions between business services, we focus now on the internal realization of each business service to better understand in details actions and responsibilities to assign to its participants.

In figure 2, on the left, a business service "Register Visitor" is illustrated with its participants.

The realization scenario of this business service is described using an activity diagram where activities of these participants are illustrated within swimlanes on the right.

 

 

Figure 2 : Responsibilities are assigned to participants of the Business Service at the left. Based on this specification, the corresponding business process that realises the business service is described via an Activity Diagram at the CIM level of the MDA

 

 

 

 

 

Step 2 : Bridge analysis level specifications with the design level ones

 

Now, in order to align IT applications with the changes captured at the business layer, realization of responsibilities assigned to participants at the analysis level (the what) of the CIM are to be described using use case and service components at the design level (the how)of the CIM .

In such a behavioral description, use case components describe actor/system interactions whereas service components describe behaviours of the system. 

The figure below shows this bridge between analysis (the what) and design (the how) levels at the CIM.

 

Figure 3 : Bridging the functional what (analysis) and the functional how (design) at the CIM

 

As an example, the activity diagram below shows at the design level of the CIM behavioral description of use case and service components that realize the responsibility Enter Visitor assigned to Visitor in the context of the service Register Visitor.

 

Figure 4 : Description of actor / system  interactions for the responsibility Enter Visitor assigned to Visitor

 

 

Step 3 : Transforming CIM level specifications into PIM level ones

 

At the PIM level, functional description of the above use case and service component interactions are described using two classes.

 

Figure 5 : Operations and their pre-conditions for the use case and service components are discovered on the basis of CIM level specifications captured using an activity diagram.

 

 

 

Step 4 : Plug PIM level service specifications into the Goal-Driven SOA (GD-SOA) Framework

 

Finally, in order to be tested, use case and service components should be integrated (plugged) on their related Goal-Driven Service Oriented Architecture (GD-SOA) backbone at the PIM level of the MDA.

Thus, business processes and their dependency relationships described at the CIM in the business process cartography (illustrated in figure 1) are transformed at the PIM into components and invocation relationships between these components. These structures constitute together the architectural backbone of the business system.

The component diagram below illustrates the architectural backbone of the business system and components of business use cases and services that are to be plugged into their corresponding parent components.

 

 

Figure 6 : Components of the Goal-Driven Service Architecture are directly obtained from the Cartography of Business Processes (figure 1)

 

Based on actor/system interactions, related use case and service behaviors are plugged into the appropriate parent components of the GD-SOA framework

 

 

 

Strengths of the pattern PTAL :

 

Based on the traceability needs between the business and application layers, the pattern PTAL allows IT applications as well as their participants to be "synchronized" with changes that happen on the business service behaviors. Responsibilities assigned to participants of business services permit to guide actors of the application systems in using such service behaviors according to their application choices ( ref. Pattern for Using Business Services from the Application Layer - PUBS-AL ).

 

 

Relationships : This pattern is typically used on the basis of business functions discovered as part of the Pattern for Coherent Evolution - PCE. It requires application of the pattern PESS (Evolvable Services) to determine evolvable services and also may use early test functions provided by the pattern PEXS. Its relationships with other patterns of the GD-SOA are illustrated below.

 

 

 

 

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