Chapter 6 Object components

Object Models
Till now we have used OOSE to transform the requirements for our application system into a use case model, and we have reused appropriate use case components from the available component system to build it. Starting from this use case model, we now develop the object models, containing the various model elements shown in figure on next slide:

A component system that include several object models, each consisting of types or classes, subsystems.

Use case model

Analysis model

Design model

Implementation model

Test model

Object models:

Describes how the system is architected, designed and implemented to meet these user requirements.

Contd..
In the diagram, use case model is primarily used to express what the system should do. The analysis and design models are used to express system structure and design. Each object model describes the design of a system at some level of abstraction.

Contd.
Each object model consist of types or classes, usually organized into subsystems. In general each object model defines how responsibilities are allocated to types or classes, indicating what responsibilities each type or class has in relation to others. Responsibilities here means something that an object needs to do or keep track of as the system is in use.

Example:
Type: Account Responsibilities:
monitor overdrafts Validate customer access rights Log transactions Transfer money correctly Compute interest

Contd.
The analysis model is more abstract and closer to the application domain, while the design model is closer to the implementation. The analysis model defines an architecture that should be reusable. The design model is derived from the analysis model and serves as a blueprint of the implementation.

Traceability between a use case

You can help stakeholders understand the dependencies that exist between the elements in a project by establishing trace relationships between the elements that you create.
Withdraw money Withdraw money

Reusing analysis and design components

The reuse constructs such as component systems, facades can be directly applied to types, classes and subsystems in the various object models. Reusable object components, consisting of types, classes and subsystems in analysis, design and implementation models, will be exported from the component systems via facades.

Object component
It is a type or class which is reusable in several systems. A subsystem component is a set of object components organized as a subsystem. Subsystems can also be used to represents components such as java applets. When we are engineering an application system we will want to reuse individual types or classes as well as complete subsystems.

Example: XYB account management component system

<<Component system>> Account management
<<facade.>> transfers

Transfer between accounts

<<use case model>>

<<design model>>

Transfer between accounts Use cases

Contd
The given diagram illustrates several elements and relationships in the XYB account management component system., which provides components for many of the application systems. Components of various types in the different models are imported into the faade by the <<import>> dependency.

Expressing variability in object model components

When several application system need exactly the same type, class or subsystem, the element can be represented as a concrete object component. Concrete object components can be reused as-is, which means that the component does not have to be specialized before reuse.

Example:
LOGIN class could be reused as-is if several application systems, such as ATM cashier or bank customer needs to identify themselves to the system. Several types of variability mechanisms can be used for specialization.

Contd
The most frequent reason to define object components that need to be specialized is when these components offer both common and varying responsibilities. First the object component is assigned those responsibilities that are common to the application types and classes, and then the responsibilities that vary are defined.

Contd
Variations points are used to define varying responsibilities in the object component. When such components are later reused, they have to be specialized at their variation points, which is done by attaching variants at the variation points. A variant provides a specialization of an object component at one or more of its variation points.

Contd
The variability mechanisms most appropriate to type and class specialization are:
Inheritance Extensions Parameters Templates and generation

Tracing use case variability to the object models