Task: Create Component Class Diagram
This task specifies the details of the Service Components which realize a Design Subsystem.
Purpose

To elaborate on one or more Artifact: Design Subsystems which were described during Task: Subsystem Design (SOA) and to provide detailed Artifact: Service Component designs.

Relationships
RolesMain: Additional: Assisting:
InputsMandatory: Optional: External:
  • None
Outputs
Main Description

Services used in an SOA based solution are realized through Artifact: Service Components which belong to a specific business function aligned subsystem. Each Service Component will have the responsibility of ensuring the QoS of the services it will realize. As an enterprise-scale asset, each Service Component qualifies for funding, governance and maintenance associated with it. Infrastructure management must be in place to ensure availability, load balancing, security, performance, versioning and overall health of the Service Component that will be responsible for implementing the functionality of a set of services and ensuring its quality of service. Functional components and technical components can be used across several Service Components.

Steps
Model Component Internal Structure

During this activity, it is important to create at least a class diagram showing the relationships between the functional and technical components of each service component. Standard UML modeling is applied at this stage. Use of patterns is encouraged to structure the resulting object graph in a manner that is extensible and open to changes. If a large degree of change is anticipated, it is recommended to conduct Variability Analysis at this stage.

As described in the previous task, when designing for change, or anticipating significant impact on the design and structure of IT system as a result of the future business changes, then it is wise to employ the Variability Analysis techniques. These techniques refactor commonality and externalize variations using design patterns. The commonality and variations discovered earliercan be used as a starting point and augmented through the use of common design patterns such as Strategy, State [i], Rule Object [ii] ,Type Object, etc.

Analysis done during detailed design identifies commonality and focuses on building pluggable variations and involves six principles that help separate the changing from the less changing aspects of software systems and isolate and encapsulate the changes:

  1. Separate and model changing from non-changing aspects of the domain: Identify, Separate, Encapsulate and Externalize Increasing Variations.
  2. Create type hierarchies for each variation point.
  3. Assign Rule Types to each Variation Type.
  4. Implement three-levels of abstraction; use aggregate inheritance meta-pattern.
  5. Start from reuse levels higher than objects and Build Assets at each reuse Level; Build Small Frameworks around Variation Points. In general, each Framework should have no more than 7+-2 classes.
  6. Each Reuse Element has its own behaviors. Externalize behavior as configurable data that can be read into the application to allow soft-wiring.

[i] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Design Patterns, Addision-Wesley 1994.

[ii] Arsanjani, A., Rule Object: A Pattern Language for Flexible Modeling and Construction of Business Rules, Washington University Technical Report number:  wucs-00-29, Proceedings of the Pattern Languages of Program Design, 2000.

Properties
Multiple Occurrences
Event Driven
Ongoing
Optional
Planned
Repeatable
More Information