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.
