IBM SG24-7368-00 Fitness Equipment User Manual


 
32 Model Driven Systems Development with Rational Products
The new mechanism for connecting all of these items is a joint realization table
(JRT). The joint realization method is how the JRT is completed, and is therefore
the process by which decomposition is accomplished within MDSD. Joint
realization is covered in “Joint realization” on page 86.
Requirement derivation
With current requirements-driven development methods, the system’s
nonfunctional requirements (NFRs) are often found in a software requirements
specification or similar document. The engineers decompose the functional
requirements and then document them in a specification tree. The objective is to
continue to suballocate functionality into ever-finer levels of granularity until the
details are sufficiently documented for development to proceed. MDSD differs
from this approach by decomposing the system into components, in contrast to
traditional methods that decompose the requirements into a specification tree.
MDSD is able to recursively define the component architecture at each level of
the hierarchy; after this, the NFRs are suballocated to the components. The JRT
is used in this approach to link the system behavior, logical components,
distribution components, and NFRs into a coherent model that maintains context
and traceability throughout the system analysis. With this method, MDSD
provides a robust means for system decomposition and modeling
.
Summary: The core MDSD process
We have discussed a set of transformations that form the basis of MDSD.
The first transformation is black box to white box, from specification to realization.
This is both structural and behavioral; we decompose the system structurally
(system subsystems) through system decomposition. We decompose the
system behaviorally in the context of collaborations through operation analysis.
We unify these transformations with joint realization.
First of all, we would like to point out the alternation between specification and
realization—in the black-box view, we specify or derive the functional
requirements (use cases and operations), the constraints on those functional
requirements, and we specify the constraints on the system as a whole. These
requirements are analyzed in the context of collaborations with system's actors.
In the white-box view(s), we analyze how the system will
realize those
requirements, and how it will meet the constraints imposed on it (both constraints
on the behavior and constraints on the system itself). This involves
understanding collaborations across multiple viewpoints. We look at both the
collaborations from the perspective of a single viewpoint with sequence
diagrams, and across multiple viewpoints with joint realization tables.