Task: Identify Technical Components
This task extends the traditional RUP subsystem design with details specific to a SOA solution, especially where subsystems were identified from business analysis models. Once we make the transition from the business domain to the IT domain, we map identified functional areas defined by the former to subsystems, their IT counterparts.
Purpose

To link the business models to their IT counterparts we perform the following:

  • Identify the relationship between Functional Areas (Concept: Functional Area Analysis) in the Artifact: Business Analysis Model to corresponding Artifact: Design Subsystem.
  • To define the behaviors specified in the subsystem's interfaces in terms of collaborations of contained design elements and external subsystems/interfaces.
  • To document the internal structure of the subsystem, in terms of Artifact: Service Components that realize the Subsystem.
  • To define realizations between the subsystem's interfaces and contained components and classes.
  • To determine the dependencies upon other subsystems.
Relationships
Main Description

We begin with the determination and documentation of the dependencies between subsystems that correspond to the functional areas that have been identified during Task: Functional Area Analysis. Usually a functional area will correspond to a single subsystem; that is, the simplifying assumption that has been found to be accurate in many, if not most cases. If we decide to map a functional area to several subsystems, that can also be feasible and valid; but usually means the domain decomposition did not go deep enough and the functional areas are not granular enough.

Steps
Identify Technical Components

Technical, or Infrastructure, components serve to make available horizontal platform capabilities; that is the capabilities they provide are not specific to the business domain but cut across business domains. These technical services are frequently provided by middleware products including operating systems and are used either directly by the service component or by the functional components on which they rely.

Example

In completing the Rent-a-Car component model (see functional component step above) we include two technical components into the model, one for the Reservation to log the completion of a reservation request and one to denote that the Vehicle and Location components rely on EJB Services to persist their business data.

Alternatively you can use a tabular format in expressing the required components and their relationship to the services previously identified, as shown in the figure below.



Properties
Multiple Occurrences
Event Driven
Ongoing
Optional
Planned
Repeatable
More Information