GooBiz

Identity : Executable Service Specifications

Intent : Early testing service specifications of business experts in order to validate their completeness independently of technological platforms as well as capitalizing on such service descriptions independently of design level solutions. This allows business experts to keep validity of their service descriptions whatever appropriate solutions may become in the future for realising them.

 

 

 

Solution Step 1 : In this first step, this pattern helps to understand how to test service specifications of business experts using their corresponding object-oriented representations, independently of technologies that can be used on target platforms. 

 

Solution Step 2 : In this second step, the motivation of the pattern PEXS is about capitalising on service descriptions independently of design level solutions at the CIM and PIM levels of the MDA.

 

 

Explanation step 1 : Early testing service specifications of business experts independently of target technologies

In order to render specifications of business experts, testable independently of target platforms, we need first to capture them using their own language (such as an activity diagram at the CIM level of MDA), then transform them in the language of analysts and designers (at the PIM level of the MDA).

The example given in the figure below shows an example of transformation as referenced by the Pattern for Identifiable Services Specifications (PISS). Actions and guard conditions described in the activity diagram are respectively transformed into contextual operations and attributes of the corresponding Goal-Oriented Object (GOO) at the PIM.

 

 

Figure 1 : Transforming actions and guard-conditions of an activity diagram drafted at the CIM into operations and attributes of the corresponding GOO (at the PIM)

 

Service specifications may be tested autonomously (unit test) as well as on the basis of their interaction with other components (integration test).

 

Unit test of a service :

In order to unit test service specifications at the PIM, contextual operations of the related GOO are triggered by their controler operation (register_visitor() in the example above). To orchestrate execution of its contextual operations, the controler compares the pre-condition of each operation to the state reached by the service before launching the operation whose pre-condition is satisfied. In its turn, a contextual operation updates the state of the related GOO before its completion. This allows the controler operation to wake-up the appropriate contextual operation.

 

 

The figure below shows at the left actions that describe the business service Register Visitor using the UML activity diagram. On the right, PIM level specifications are automatically generated in order to test these behaviours.

 

Actions and guard conditions are transformed respectively into operations and their pre-conditions. An orchestrator (controler operation) is designed to launch them depending on the state of the service (described by a Goal-Oriented Object - GOO).

 

 

 

Figure 2 : Transforming CIM level service specifications into PIM level ones for testing their behaviours

 

 

 

Integration test between services :

The integration test of services is realised via their controler operation. During its execution, a contextual operation of service A may need to communicate with the service B. Such an invocation is supported by the controler operation of the service B.

The state transition diagram below illustrates how to test such an interaction between services.

 

Figure 3 : The state diagram shows transitions between states of the service A and B, as well as communication between services

 

 

 

 

Explanation step 2 : Capitalizing on service descriptions independently of related design level decisions.

 

For succeeding with the transformation of specifications from description of services by business experts till their implementation on the target platform by platform specialists, the pattern PEXS suggests to use the MDA specification platforms (viewpoints).

 

In order to avoid redundancy of the work between business experts, analysts/designers and target platform specialists, semantical boundaries must be assigned to the languages of these stakeholders.

In this perspective, the pattern PEXS assigns the following semantical boundaries to the CIM, PIM and PSM levels (specification platforms) of the OMG's MDA as well as to their respective analysis and design levels :

 

·        CIM : Functional analysis and design levels  that focus respectively on the functional what and how

·        PIM : Technical analysis and design levels that focus respectively on the technical what and how,

·        PSM : Technological analysis and design levels that focus respectively on the technological what and how

 

The figure below illustrates specification platforms assigned respectively to business experts, analysts / designers and target implementation platform specialists on the OMG's MDA infrastructure. The abstraction boundaries for each stakeholder are specified within parenthesis.

 

 

 

 

Figure 4 : Service specification levels on the basis of the OMG's Model Driven Architecture (MDA) in order to

avoid redundancy of the work between stakeholders

 

 

RULES FOR CAPITALIZING ON SERVICE SPECIFICATIONS...

 

In order to capitalise on service specifications independently of related design level decisions, a 1 to 1 traceability relationship between specifications of business experts and system analysts/designers must be ensured first. Such a traceability should guarantee validity of tested services even in face of changes that may arise on the potential design level processes that may realise these services.

 

For succeeding with this one-to-one traceability relationship, the pattern PEXS suggests to capture service specifications by grouping them under service structures at the CIM level of the MDA, then transforming them into Goal-Oriented Objects (GOO) at the PIM level.

 

Secondly, inside the CIM and PIM specification platforms, in order to prevent invalidation of analysis level specifications later by design level choices, analysis level specifications are to be isolated from design concerns.

 

This means goal-driven service specification (at the analysis level) and processes that realise them (at the design level) must be isolated carefully. In order to ensure such an isolation :

• at the CIM level, use appropriate action names in that they constitute identifiable goals for guiding underlying processes (solutions) to attain these goals,

• at the PIM, assign actions to operations of Goal-Oriented Objects (GOO) ; do not assign such business responsibilities to entity objects like Customer, Product, Order, etc...

 

Using the above principles (a 1-to-1 traceability mechanism and analysis/design levels isolation), service descriptions are not altered by design level decisions even if related design level solutions are transformed later into PIM level components then mapped on the service oriented architecture. 

 

The class diagram below shows descriptions of service components and entity objects they invoke at the PIM level of the MDA. Service components carry their business responsibilities (operations with constraints) that are to be implemented later depending on design level decisions.

 

 

 Figure 5 : Service specifications transformed into PIM level descriptions allows us to prototype CIM level service behaviours

 

 

On the basis of such a capitalisation on the business knowledge independently of related design level decisions, we can go ahead and specify design level behaviours of service descriptions at the CIM level in order to guide developers in implementing corresponding operations at the PIM.

 

The figure below shows at the left design level behaviours of the service component Enter Visitor using the UML activity diagram and the Java Code comment lines (at the right) that can be automatically generated in order to guide developers in implementing operations that correspond to these actions.

 

 

Figure 6 : Transforming CIM level service specifications into PIM level source code comment lines

 

 

Conclusion (Forces of the pattern PEXS) :

 

This pattern helps to prototype goal-driven service specifications without waiting for the target platform and technological skills to be ready for testing them. It also allows business experts to capitalise on their service descriptions independently of related design level decisions that might be integrated later to support realisation of such services.

 

Relations : The pattern PEXS requires identifiable and evolvable services provided respectively by the pattern PISS (Identifiable Service Specifications) and PESS (Evolvable Services Specifications) in order to render them executable. Solutions that are provided by Executable Service Specifications are to be used by the Pattern for Traceable Abstraction Layers - PTAL that aim at making business behaviours usable by the application layer.

 

 

 

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