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
RolesPrimary Performer: Additional Performers:
InputsMandatory:
    Optional:
    • None
    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 (ServiceInterfacesMessageTypes, 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