Design level
At the design level, the decisions that drive the implementation are captured. In the transition from the analysis to the design level, subsystems, classes, and localities are transformed into hardware, software, and worker designs. This is not a direct mapping from system elements to designs, rather, design decisions are made by deriving the design from the functionality represented in the subsystems and classes. These design decisions are constrained by the supplementary requirements and distribution choices represented by the localities and their attributes. The resulting design transformation realizes all of the specifications from the analysis level. In other words, the system architecture is specified at the analysis level, creating requirements that the design level must satisfy.
Implementation level
At the implementation level, decisions about technology choices for the implementation are captured. Commercial products can be specified, or items might be specified for internal implementation. As before, moving from the design level to the implementation level is a transformation, but this time the mapping is more direct. For example, at the design level, the functional activities of a worker are mapped to a position specification with a defined set of skills. Then, at this level, the specification can be fulfilled either by hiring someone with the correct skill set (similar to choosing a commercial product with certain capabilities) or by training an individual to acquire the required skills (similar to doing an internal implementation).
Viewpoints
A viewpoint is defined as a subset of the architecture model that addresses a certain set of engineering concerns. The same artifact can appear in more than one viewpoint. Viewpoints allow framework users to separately address different engineering concerns while maintaining an integrated, consistent representation of the underlying design. Table
26Model Driven Systems Development with Rational Products
