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 realizing them.

 

 

 

Solution Step 1 : In this first step, this pattern helps to understand how to test services independently of technologies that can be used on target platforms. 

 

Solution Step 2 : In this second step, it aims at capitalizing on service descriptions independently of design level solutions at the CIM and PIM levels of the MDA (Model- Driven Architecture).

 

 

Explanation step 1 : Early testing service specifications 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-Driven Service (GDS) 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 GDS (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 realize unit tests of service specifications at the PIM, contextual operations of the related GDS 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 GDS 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-Driven Service - GDS).

 

 

 

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

(GOO - Goal-Oriented Object is used here to accentuate the "role of controler" of a Goal-Driven Service (GDS))

 

 

 

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.

 

To succeed with the transformation of specifications from description of services till their implementation on the target platform, the pattern PEXS suggests to use the MDA specification platforms (viewpoints) provided below.

 

In order to avoid redundancy of specifications between business experts, analysts/designers and target platform specialists, the following semantical boundaries for CIM, PIM and PSM levels must be assigned to languages of these stakeholders in their respective analysis and design works :

 

·        CIM (for business experts): Functional analysis and design levels  that focus respectively on the functional what and how,

·        PIM (IT analysts/designers): Technical analysis and design levels that focus respectively on the technical what and how,

·        PSM (target platform specialists): 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 capitalize on service specifications independently of related design level decisions, a 1 to 1 traceability relationship between specifications of business experts (CIM level) and those of system analysts/designers (PIM level) must be ensured first. Such a traceability must also guarantee validity of tested services in face of changes on 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 functional service structures at the CIM level of the MDA, then transforming them into Goal-Driven Service (GDS) 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 realize them (at the design level) must be isolated carefully. In order to ensure such an isolation :

 

• at the CIM level, regarding the figure 1, use appropriate activity names to constitute identifiable goals for guiding underlying processes (solutions) to attain these goals,

• at the PIM, assign these activities directly as operations of Goal-Driven Services (GDS) ; 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 though 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 on their business responsibilities (operations and possible constraints like pre-conditions, ...) 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 capitalization 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

 

 

Strengths 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 capitalize on their service descriptions independently of related design level decisions that might be integrated later to support realization of such services.

 

Relationships : 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 Framework : Click on each referenced pattern icon to visualise its detailed description