Information Technology Reference
In-Depth Information
Modeler may iterate over this model, creating a new refined model based on
the original analysis model. The Analysis Modeler can declare a dependency on
another component and, if the component depends on other components, the
Analysis Modeler first fetches the models of these supplier components from the
shared pool. Upon completing the model, the Analysis Modeler is responsible
for verifying that the model is consistent, and validating that it realizes the re-
quirements. Prototyping can be done and run-time checking can be applied in
addition to the analysis of the requirements specification outlined in Section 3.2.
Note that for formal analysis and its automated tool support, MasterCraft must
be extended by adding translators of the UML diagrams into machine readable
textual specifications in rCOS. Formal verification and validation tools, such as
FDR, SPIN and JML or static checkers must be integrated into MasterCraft so
that these tools can be invoked by the analysis modeller. For this, programs for
converting rCOS specification to inputs of the tools should be implemented.
The Model Manager can afterwards release the model into the shared pool,
making it available for Analysis Modelers working on components depending
on this component. The release is not to simply drop the model there. The
Model Manager should check on the consistency of the model with the others
by removing redundancy and integrating identical modelling elements. After
being released into the shared pool, the model in the application workspace is
frozen, and any additional changes would start a new modelling cycle. Before
releasing the model into the shared pool, the model manager has to ensure that
the Analysis Modeler has validated the model.
Support to Design Modeller. A Design Modeler (e.g. Alice) fetches the
released model of requirements of a component ( SalesHandler resp.) from
the shared pool assigned to her, and refines the analysis model into a logical
design model. This involves the application of the expert pattern for refining the
use case sequence diagram to a design sequence diagram. The conceptual classes
from the analysis model are also refined into design classes.
Then the Design Modeler decomposes a component into composition of in-
ternal components, and composes a number of components together to for a
component model. For example, the original design of SalesHandler is de-
signed into the composition of SalesHandler , Clock and Bank
and mark the latter two as components already implemented. The Design mod-
eller may also decide on which objects should be persistent, and defines database
mapping and primary keys for these classes. This is the case for the decomposi-
tion of the Inventory component into the three layer architecture in Fig. 12.
Further, the Design Modeler defines the component interface in terms of class
operations and queries provided, and may declare additional dependencies on
other components. This is the case for Alice. She has to declare that component
SalesHandler requires services from Inventory to get product descrip-
tions and to log a completed sales via interface CashDeskIf .Itisthesamefor
Inventory that requires services from Supplier via interface SupplierIf .
Note that before commencing the work on the design model, the Design Modeler
needs to fetch models of the supplier components from the shared pool.
Search WWH ::




Custom Search