Page 202 -
P. 202

7.1   Object-oriented design using the UML  185


                                7.1.4 Design models

                                       Design or system models, as I discussed in Chapter 5, show the objects or object classes
                                       in a system. They also show the associations and relationships between these entities.
                                       These models are the bridge between the system requirements and the implementation
                                       of a system. They have to be abstract so that unnecessary detail doesn’t hide the rela-
                                       tionships between them and the system requirements. However, they also have to
                                       include enough detail for programmers to make implementation decisions.
                                         Generally, you get around this type of conflict by developing models at different
                                       levels of detail. Where there are close links between requirements engineers, design-
                                       ers, and programmers, then abstract models may be all that are required. Specific
                                       design decisions may be made as the system is implemented, with problems resolved
                                       through informal discussions. When the links between system specifiers, designers,
                                       and programmers are indirect (e.g., where a system is being designed in one part of
                                       an organization but implemented elsewhere), then more detailed models are likely to
                                       be needed.
                                         An important step in the design process, therefore, is to decide on the design
                                       models that you need and the level of detail required in these models. This depends
                                       on the type of system that is being developed. You design a sequential data-process-
                                       ing system in a different way from an embedded real-time system, so you will need
                                       different design models. The UML supports 13 different types of models but, as I
                                       discussed in Chapter 5, you rarely use all of these. Minimizing the number of mod-
                                       els that are produced reduces the costs of the design and the time required to com-
                                       plete the design process.
                                         When you use the UML to develop a design, you will normally develop two kinds
                                       of design model:


                                       1.  Structural models, which describe the static structure of the system using object
                                          classes and their relationships. Important relationships that may be documented
                                          at this stage are generalization (inheritance) relationships, uses/used-by rela-
                                          tionships, and composition relationships.
                                       2.  Dynamic models, which describe the dynamic structure of the system and show
                                          the interactions between the system objects. Interactions that may be docu-
                                          mented include the sequence of service requests made by objects and the state
                                          changes that are triggered by these object interactions.


                                         In the early stages of the design process, I think there are three models that are
                                       particularly useful for adding detail to use case and architectural models:


                                       1.  Subsystem models, which that show logical groupings of objects into coherent
                                          subsystems. These are represented using a form of class diagram with each sub-
                                          system shown as a package with enclosed objects. Subsystem models are static
                                          (structural) models.
   197   198   199   200   201   202   203   204   205   206   207