Task: Refactor the Service Model |
|
 |
Refactor the service model to remove redundancy and to improve comprehension, consistency, and flexibility. |
Disciplines: Architecture |
|
Purpose
Create a Service Model that is free of redundancies, easier to understand, and easier to
maintain.
|
Relationships
Roles | Primary Performer:
| Additional Performers:
|
Inputs | Mandatory:
| Optional:
|
Outputs |
|
Main Description
Building a significant service model can involve the participation of several SOA architects over an extended period of
time. It is likely that, in the absence of efforts to periodically examine the model critically, undesired
redundancies in concepts (ServiceInterfaces, MessageTypes, Participants, and so on) will appear, and the quality of the model will
degrade. To combat this, the SOA architect team needs to be continually seeking refactoring opportunities,
and needs to periodically perform formal reviews to refactor the service model.
The main tool that is used to perform the refactoring is commonality and variability analysis. This is
introduced in Concept: Variability Analysis. Guideline: Variability Analysis provides additional discussion on this
technique. Example: Variability Analysis presents an example, and also illustrates
some common taxonomic hierarchies that are used to describe variability.
|
Steps
Identify common and variable elements
Identifying the elements of a design that do not change when used in different situations is best done
iteratively. Create instance diagrams for a set of scenarios and note which elements are common in all cases.
The more scenarios available, obviously the more data points there are available to you and therefore you are able to
validate early results and assumptions.
Provide some form of encapsulating element to separate the changing elements from the rest of the design. The
choice of encapsulation technique depends on the context, but consider the following:
-
Introduce a package to own the elements. This only changes the ownership of the elements, but not the
relationship between the elements or with elements outside the package. This is most commonly applied to analysis
models.
-
Introduce a component to own the elements. This not only changes the ownership, but it also introduces a
formal encapsulation so you might choose to define an interface exposing the relevant elements to the outside.
-
Introduce a UML 2.0 collaboration. This allows the common elements to be defined as part of the
composite structure of the collaboration as well as defining the variable elements as roles. Later on,
a binding can be made from the variable element roles to concrete elements. This is a common approach to
defining design patterns in UML. A collaboration does not own the elements themselves, only roles
corresponding to the elements.
-
Introduce a templated class where the template corresponds to the type of the variable element(s). This is a
common approach in languages such as Ada, C++, Eiffel, and now Java, which support generic programming.
-
You might simply choose to use a visual cue. It is common, for example, to use a single diagram and to color the
common and variable elements differently.
|
Document variability forms
Variability itself takes a number of different forms, any of which might be appropriate. In some cases, more
than one form is present in a given situation. Common kinds of variability are:
-
Variability by Type -- for example, in Example: Variability Analysis, the variability of the legal contract is based on
the type hierarchy used to represent the concept "Party:
-
Variability by Role -- in this case, the type of the element is generally immaterial (or at least of
secondary importance). It is the role it plays that is of value. This type of variability is often found in
pattern development. A pattern is defined so that it can be applied to the broadest set of
possibilities. To achieve this, the parameters to the pattern are defined in terms of the roles the
provided elements play.
-
Variability of Implementation -- In this case the element provided is required to perform
some behavior, and so needs to implement a given interface (or more formally a protocol) to be applicable. In such a
case, it is usual that the container of the common elements describes the interface. It also has either a template
parameter of the interface type, or it requires the interface.
Example: Variability Forms provides illustrations of each of the above forms of
variability.
|
|
Illustrations
More Information
Licensed Materials - Property of IBM
© Copyright IBM Corp. 1987, 2012. All Rights Reserved.
|
|