Task: Identify Functional 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 Functional Components

Functional components provide additional business function to a service component; in many respects, the capability provided by a service component is dependent entirely on its functional components and any additional business logic it implements on top of these.

Functional components are often to be found among Type Managers - components that manage a particular domain element, for example "Vehicle", "Customer", "Schedule", and so forth. It should be made clear that these domain elements are more frequently large-grained graphs of data rather than simple structures.

Example

Considering the Rent-a-Car example, the Reservation service component need to be able to pull together details about the customer, the location they wish to hire from and the vehicles available for the class they specify. Also we need to be able to determine the customer's rating such that we can provide the correct level of service in the event of issues such as unavailable vehicles. The following diagram demonstrates the component model for Reservation.



Properties
Multiple Occurrences
Event Driven
Ongoing
Optional
Planned
Repeatable
More Information