About this module. Object-oriented analysis and design. About this module. Analysis

Transcription

1 About this module McGill ECE 321 Intro to Software Engineering Radu Negulescu Fall 2001 Object-oriented analysis and design The modules of an object-oriented program preserve state between calls. This is different from procedural programs, where the local variables of a procedure are lost when the procedure terminates. Analysis: transform a linear list of requirements into a structured model of the application. A.k.a. understanding Design: make implementation decisions to meet targets and optimize goals. Changeability, maintainability are elusive goals, but usually of highest importance. Design patterns: good opportunity to learn by example. Required reading: B&D 5.2, 5.3.1, , 5.5.5, ; 6.5.1; 7.5.1; Appendix A. OOAD Slide 2 About this module What is the point of the cover picture of [B&D]? Analysis Transform a list of requirements into a highly structured model of the application. A.k.a. understanding Analysis has a dual purpose: Understanding the problem at hand by building a compact, structured model. A side effect is cross-checking of elicited requirements: structuring is likely to detect inconsistencies and omissions/ambiguities. Communicating requirements to developers, without any unnecessary restrictions. This is a model of the problem, not just one solution. => Allow all reasonable solutions. => Typically, but not always, this means giving a black-box view over the system. => Include as many features as possible without introducing implementation bias. Make things as simple as possible, but no simpler. OOAD Slide 3 OOAD Slide 4

2 Object identification Half the battle in writing an object-oriented program is to identify a good set of classes, along with their responsibilities and collaborations. This is a highly iterative process: Draft, review, repeat. Many objects in an OO program tend to correspond to entities from the real world. Call them entity objects. E.g. time, location, map. In addition, other objects serve to define the boundary of the system. Call them boundary objects. E.g. menu, button, shopping cart, sensor status. Yet another common class of objects serve to control the interactions with the actors, usually by tracking the progress of a use case or a part of a use case. Call them control objects. E.g. user registration, phone connection. Natural language analysis Abbott s natural language analysis: often, objectoriented program elements can be identified by a grammatical analysis on text in a natural language. Proper noun: entity object, actor instance Common noun: class, actor, attribute Doing verb: operation, method Being verb: generalization Having verb: aggregation Modal verb: constraint Adjective: attribute Although Abbott s rules work in a large number of cases, they do suffer from limitations inherent to natural languages: Imprecision, dependency on style of writing. E.g. compare: the TV set shall allow a selection of channels the TV set shall allow selection of channels the TV set shall allow users to select channels. There are more nouns than relevant classes. E.g. minutes is as a noun, but it should be an attribute of a Time class. Sort out attributes, synonyms. OOAD Slide 5 OOAD Slide 6 Identifying entity objects Textual clues: a noun in the textual specification of a program can be an object (O), class (C), actor (A), attribute (F), synonym of another noun (S), or of no concern to the system (N). Example: A certain city hall (N) commissions your company (N) to develop RoadRunner (O), a web-based system (S RoadRunner) to allow the citizens (A) to report the presence (N) of potholes (C) in the public roads (C). A report (C) must contain the following information (N) for each reported pothole: size (N) of the pothole (width (F), depth (F) ), location (N) (street address (F) ), and, optionally, a textual comment (F). RoadRunner also displays the status (F) of the repair work (C) for each pothole, as determined by the dispatchers (A) from the city hall: under assessment (N), assigned, work in progress (N), finished. The repair status of each pothole is updated simultaneously in all reports containing that pothole, and can be viewed by the public (S citizen). Heuristics for identifying entity objects [B&D, p. 141]: almost the same as the initial analysis objects. Recurring nouns. Terms that need clarification. Real-world entities and processes tracked. Data sources or sinks. Avoid interface artifacts (boundary objects). Identifying boundary objects Track an actor and translate its interactions in an interface-neutral form. Initially, specify only a general level of user interface: Examples of objects specified at the analysis stage: form, screen, page, button. Examples of objects specified at the detailed design stage: drawing ruler, load command, etc. Example: the 321 course web page. To be specified at the analysis stage: page, hyperlink, frame. To be specified at the detailed design stage: welcome page, menu frame, content frame, lecture notes, image file. Other techniques are better suited for detailed design of the UI through trial and error (storyboards, mock up prototypes). Heuristics [B&D, p. 143]: System inputs: forms, windows. System outputs: notices, messages. Avoid visual aspects: maximize the freedom of the artistic designer. OOAD Slide 7 OOAD Slide 8

3 Identifying control objects Collect info from the boundary and dispatch it to the entity objects. Track status of interaction. Usually not mentioned in the problem description. Examples: Sequencing of forms, screens presented to user. Undo and history queues. Event listener objects. Dispatching info in a distributed system. Heuristics [B&D, p. 145]: Status of a use case. Status of an actor in a use case. User sessions. If unclear, revise the use case models. Identifying associations Possible starting point: sequence diagrams. One scenario for each use case, plus some secondary (exceptional) flows. Heuristics for identifying associations Natural language cues: Manages, reports to, is triggered by, talks to Aggregation: has, is part of, is contained in, includes Name associations and roles precisely. For each class, examine the sequence of associations that need to be traversed to reach an instance of that class. Eliminate redundant associations E.g. from [B&D] author document * writes 1 FieldOfficer EmergencyReport 1 reports 1 Incident 1 1 triggers Determine multiplicities only after the associations are stable. OOAD Slide 9 OOAD Slide 10 Identifying attributes Attributes are properties of individual objects. Only properties relevant to the system should be considered. Attributes represent the least stable part of the model, discovered or added late. Do not spend a lot of effort on them until validation of the analysis model. Pay more attention to entity attributes than control or boundary attributes. Heuristics: Examine possessive phrases. Think of stored state. Attributes are highly volatile, low risk. How should we organize development? CRC cards Object-oriented design is a highly iterative process. Several round-trips to optimize modularity and other design objectives. A good strategy is to stabilize a rough first-cut before the low-level details. First-cut of the object model: class names, responsibilities, and associations. CRC cards: class responsibility collaboration. 6x4 inch cards. Sizes, numbers of lines are deliberate. E.g. [Beck, Cunningham] OOAD Slide 11 OOAD Slide 12

4 Example: ATM software [Beck, Cunningham] Example: MVC [Beck, Cunningham] CRCs: OOAD Slide 13 OOAD Slide 14 Reviewing the analysis model Analysis is done incrementally and iteratively. Per use case / segment of functionality. Several review-and-revise cycles. The review needs focus on some key points. Here is a short list: Consistency between analysis model and use cases. For each use case, walk the model to ensure that all scenarios are represented. Does each object have the necessary associations to access related objects? For each object, attribute, association: which use cases access it? create it? set it? traverse it? Auxiliary flows: maintenance, error, start-up/shutdown, application-specific, work-specific, Description and naming of analysis model elements. Meaningful, understandable by users. Conformant to Abbott s rules. Uniform level of detail in the descriptions. Realism (feasibility): demonstrate by prototypes or feasibility studies. Novel features (not present in previous systems). Non-functional requirements. Design activities Design vs. analysis Analysis focuses on understanding the problem. Design focuses on finding a good solution. There is no general recipe for going from a problem statement to the design. However, we can apply: Heuristics, e.g. object identification. Pre-determined architectures. Components and libraries. Design patterns. OOAD Slide 15 OOAD Slide 16

5 System design Using the analysis model as a starting point, developers take implementation decisions to optimize design goals. System design comprises the following activities: Identifying design goals and constraints. Defining the architecture. Decomposing the system into subsystems. Selecting system-wide conventions and policies: Persistency Security Global control flow Start-up, shut-down, error handling Selecting reusable components, libraries, etc. Mapping to hardware. (Will discuss in the Architecture module.) Object design Object design closes the gap between the application model and the deployment platform. The following activities are typically performed at this level: Service specification: precisely describe interfaces (see Correctness, Design modules). Component selection: find pre-made parts that are suitable for the functionality of the system. Object model restructuring: optimize maintainability. Reduce multiplicity. Implement binary associations as references. Merge similar classes. Collapse trivial classes into attributes. Split complex classes. Object model optimization: maximize performance. Use different algorithms / data structures. Add or remove redundant associations. Add derived attributes. Open up the architecture. Difficulty: many factors conspire to introduce inconsistencies in a software system. Notice a trade-off between performance and maintainability. OOAD Slide 17 OOAD Slide 18 Realizing associations Several options to implement associations Offer a tradeoff of maintainability/changeability vs. asymptotic performance. Unidirectional: Use references Collapse the target class into an attribute of the source class. Bi-directional: References both ways, plus set methods that access the partner class s attribute. Or, collapse one class into an attribute of the other. One-to-one, many-to-one, one-to-many, many-tomany. The to-one sides are easy to implement. The to-many sides can be implemented as a collection of references Array or Vector for ordered associations Hashtable for qualified associations Complex associations may justify implementations as separate objects. Realizing associations Bi-directional associations present maintainability challenges. Example [B&D, fig. 7.22]: =RRP,Q$FWLRQ WDUJHW0DS0DS$UHD ГJHW7DUJHW0DS ГVHW7DUJHW0DSPDS 0DS$UHD ]RRP,Q=RRP,Q$FWLRQ ГJHW=RRP,Q$FWLRQ ГVHW=RRP,Q$FWLRQDFWLRQ FODVVÛ0DS$UHD H[WHQGVÛ-3DQHO ^ SULYDWHÛ=RRP,Q$FWLRQÛ]RRP,Q Û2WKHUÛPHWKRGVÛRPLWWHGÛ YRLGÛVHW=RRP,Q$FWLRQ DFWLRQ=RRP,Q$FWLRQÛ^ LIÛ]RRP,Q Ü ÛDFWLRQÛ^ ]RRP,Q ÛDFWLRQ ]RRP,QVHW7DUJHW0DSWKLV FODVVÛ=RRP,Q$FWLRQ H[WHQGVÛ$EVWUDFW$FWLRQ ^ SULYDWHÛ0DS$UHDÛWDUJHW0DS Û2WKHUÛPHWKRGVÛRPLWWHGÛ YRLGÛVHW7DUJHW0DSPDS0DS$UHDÛ^ LIÛWDUJHW0DS Ü ÛPDSÛ^ WDUJHW0DS ÛPDS WDUJHW0DSVHW=RRP,Q$FWLRQWKLV OOAD Slide 19 OOAD Slide 20

6 Realizing associations Realizing associations Reducing multiplicity by qualifiers Associations as separate objects E.g. [B&D]: &DU SDUWV 3DUW Object design model before transformation date author CPUtime getoutline() SimulationRun class Car { Vector parts; EmissionSource * 1 SimulationResult } Object design model after transformation &DU 3DUW1DPH 3DUW SDUWV SimulationRun date author CPUtime getoutline() 1 1 class Car { EmissionSource * 1 SimulationResult Hashtable parts; } OOAD Slide 21 OOAD Slide 22 Object behavior State charts can help define the behavior of single objects, interactions with the actors, etc. Building a state chart for every object is overkill. However, building state charts is justified for certain intricate objects, classes, or interfaces. E.g. Applet life cycle: init destroy Inactive start stop Active Design patterns Pattern, in the context of software engineering: partial solution to a common software development problem. Excellent examples of design for change Distilled experience of software designers In object-oriented design: a pattern is an abstraction of a collaboration. Problem: conditions to be met where it makes sense to apply the pattern; constraints, optimization goals ( forces ) Solution: small collection of classes and their relationships. Not all details are represented. Consequences: results and tradeoffs. Beyond object-oriented design: Testing patterns Process modeling patterns CM patterns OOAD Slide 23 OOAD Slide 24

7 Composite pattern Leaf Component Composite Organizing recursive data structures. Examples: Recursive pictures. File and directory hierarchy. * Entry File * Directory 0..1 Example: recursive pictures The following example illustrates how to combine inheritance and encapsulation for modular design. Pictures in a document editor can be image files, text boxes, or contain other pictures recursively. Several possible structures are shown. Can you comment on their modularity properties (cohesion, decoupling)? 3LFWXUH 7H[W,PDJH 3LFWXUH 3LFWXUH 7H[W,PDJH &RQWDLQHU Notice: Multiplicity of the aggregation. Some things are left unspecified Patterns are rarely encountered in pure form Recursive implementation of each service. E.g. move image. De-coupling of traversal and storage mechanisms. 7H[W%R[ 7H[W%R[,PDJH,PDJH 3LFWXUH &RQWDLQHU OOAD Slide 25 OOAD Slide 26 Observer pattern Proxy pattern 6XEMHFW DWWDFKÛ2EVHUYHU GHWDFKÛ2EVHUYHU QRWLI\Û IRUÛDOOÛVÛLQÛVXEVFULEHUÛOLVWÛ ^ VXSGDWHÛ VXEVFULEHU 2EVHUYHU XSGDWHÛ &OLHQW 6HUYHU RSHUDWLRQ &RQFUHWH6XEMHFW VXEMHFW6WDWH VHW6WDWH JHW6WDWH SXEOLVKHU &RQFUHWH2EVHUYHU REVHUYHU6WDWH XSGDWHÛ 3UR[\6HUYHU RSHUDWLRQ 5HDO6HUYHU RSHUDWLRQ REVHUYHU6WDWH ÛSXEOLVKHUJHW6WDWH Decoupling model from views: Observer pattern. Examples: Listeners in Java (not pure observer pattern). Discussion: Decouple model from views, as in the MVC architecture. However, does NOT decouple views from model. A.k.a. Publisher-Subscriber. Examples: Web pages cache stored at the browser s site. Firewall proxy. Discussion: Save expensive operations Protection OOAD Slide 27 OOAD Slide 28

8 Abstract factory pattern MotifFactory createwindow()... AbstractFactory createwindow()... MacFactory createwindow()... MotifWindow AbstractWindow MacWindow Using graphical widgets regardless of the operating system. Example: Encapsulating windowing styles. Discussion Shield an application from platform-specific classes. Each platform is represented by a specific factory class inheriting from the abstract factory class, that returns specific widgets inheriting from the abstract widgets classes. Other patterns Creational: abstract the instantiation process. Abstract factory: encapsulating platforms Structural: describe ways to compose objects. Adapter: wrapping around legacy code Composite: representing recursive hierarchies Bridge: separating an interface from alternate implementations Proxy: encapsulating expensive objects Façade: encapsulating subsystems Behavioral: abstract behavior (algorithms, communication, etc.) Observer: decoupling entities from views Strategy: encapsulating algorithms Command: encapsulating control More: [Gamma et. al. Design patterns: elements of reusable object-oriented software. Addison- Wesley, 1994] OOAD Slide 29 OOAD Slide 30 Textual clues for finding patterns Design patterns are another great source of object identification. Use objects that appear in design patterns. The natural language statement of the problem can indicate a design pattern. An X may contain several sub-x ; Shall implement a hierarchy of X -> composite pattern. Separate data from its views -> observer pattern. Separate policy from its implementation -> strategy pattern. Work with many databases from different vendors -> bridge pattern. Cache data items -> proxy pattern. OOAD Slide 31