Summary

< Free Open Study >

Summary Much has been covered in terms of model creation in this chapter, and a large number of models have been presented. The summary will consist of a short review of the steps and the resulting project artifacts of each method. Review: Steps in Structured Analysis and Structured Design During both structured analysis and structured design, the PM needs to know: What tasks are being done? What artifacts should I expect? How long it will take? What process is being used? What method is being used�pure structured methods or a combination with OO? How should the organization be structured to support the process? What tools, automated or manual, should be employed to support the process? A "big picture" of SA/SD is shown in Figure 22-52. Reading from the top downward, this picture shows, at the top, that data (static) models may include entity relationship diagrams or class models, that functional models are data context diagrams, control context diagrams, data flow diagrams, and control flow diagrams. At the top, or beginning, of SA/SD is also a good time to begin a data dictionary and to flesh out process specifications and control specifications (which are often represented as state transition diagrams). Figure 22-52. The Big Picture of Analysis and Design In the center of the picture, architecture context diagrams, architecture flow diagrams, and architecture interconnect diagrams are represented. This is the phase in which requirements models are parsed out into one of five boxes (core system, user interface, input, output, maintenance and self-help), data flows are bundled, and then the system is decomposed again. For most projects, this is a necessary part of particularly complex real-time or control systems only. The bottom third of the picture shows how repositioned functional modules undergo transform or transaction analysis to form a series of structure charts, decomposed to their lowest level. At the lowest level, where each black-box module on a structure chart is identified, the modules may be designed for internal structure (white box). These designs, known as Chapin charts or Nassi-Schneiderman diagrams, are used in the construction of actual program code. Review: Steps in Object-Oriented Analysis and Object-Oriented Design The questions that a PM wants to answer are the same as for SA/SD methods. They can mostly be answered by deciding upon which of the OOA/OOD models will be used and if any will be used in combination with SA/SD models. There are several ways to create, use, and refine OO models of use case diagrams/scenarios, activity diagrams, class/object diagrams, collaboration diagrams, interaction diagrams, state transition diagrams, data context diagrams, and the data dictionary. Some are thought of as top-down, some as bottom-up, and all are iteratively refined through elaboration. Derived from writings of Richter and Larman, two approaches are listed here. One sequence of steps would involve something like this: Identify actors and identify their interactions with the system. Create use cases, working on high-level ones first and deferring their expansion until the design phase or when it is their turn to be developed. Create high-level class/object models quickly, emphasizing obvious roles, things, and concepts. Make use of noun phrases from a problem specification. Analyze the life cycles of each class, considering what use cases cause an instance of each class to be created, changed, or destroyed. Document the flow of messages between instances and the invocation of methods via collaboration diagrams. Analyze the action-oriented verb phrases in a problem specification. Use collaboration diagrams to determine how objects interconnect and what methods belong to each class. An alternative approach is this: Write the problem statement, or use narrative descriptions from SRS documents. Identify objects. Beginning with nouns, select only entities and concepts that are relevant to the project. Defer aggregation and generalization until a later iteration. Concentrate on objects and the most obvious attributes�they can be expanded later. Create a data context diagram and prune terminators and actors. Begin a data dictionary. Select classes. Eliminate redundant classes or those that should be something else (an attribute or an operation); eliminate implementation constructs. Clarify vague classes. Heavily involve domain experts. Construct the data dictionary. Create an entry for each object class and define scope, assumptions, associations, attributes, operations, and methods. Create the class diagram. Iterate models and diagrams, begun early in the project, with domain experts and users. Identify associations and aggregations. Eliminate associations that are irrelevant or redundant, or that are implementation-specific. Begin the estimation of multiplicity for each association, and then reduce it where possible. Clarify ambiguous associations. Decompose higher-order associations. Identify attributes. Simplify using inheritance. Search classes for similar attributes, associations, or operations, and assign them to a superclass. Refine existing classes into specialized subclasses (define subclasses where a class is treated differently in the application). Avoid complexity�too much detail, deeply nested generalizations. And, as always, iterate, iterate, iterate.

< Free Open Study >