1. Software Engineering SI334 Lessons 24, 26 – 28 & 30: Classical & Object-Oriented Design October 6, 8, 10, 15, 2014

2. Software Engineering SI334 2 Data and Actions  Two aspects of a product  Actions that operate on data  Data on which actions operate  The two basic ways of designing a product  Operation-oriented design  Data-oriented design  Third way  Hybrid methods  For example, object-oriented design © The McGraw-Hill Companies, 2011

3. Software Engineering SI334 3 Object-Oriented Design

4. Software Engineering SI334 4 * Object-Oriented Design  Classes are extracted during the object-oriented analysis workflow, and  Designed during the design workflow  Accordingly  Classical architectural design corresponds to part of the object-oriented ____________workflow  Classical detailed design corresponds to part of the object-oriented ____________workflow © The McGraw-Hill Companies, 2011 analysis design

5. Software Engineering SI334 5 * Object-Oriented Design  Goal: Design product in terms of objects identified during OOA  OOD consists of two key steps: 1.Complete the detailed class diagram 2.Perform the detailed design

6. Software Engineering SI334 6 * Object-Oriented Design  Completing the detailed class diagram consists of: 1.Determining the formats of the attributes a.Formats of attributes generally deduced directly from analysis artifacts 2.Determining the methods and assigning them to the relevant classes a.Methods determined by constructing interaction diagrams for each scenario. Two flavors: i.Collaboration diagrams (Spatial) and ii.Sequence Diagrams (Temporal) b.Methods assigned to classes by designing the product in terms of clients of objects

7. Software Engineering SI334 7 *Determining Class’ Attributes Consider class Elevator Controller  If User wants to check and update requests, needs requests attribute  Needs methods:  check requests,  update requests Detailed: As used here means that all method names, and (as a by-product) attributes ID’d by designer, are represented on the diagram

8. Software Engineering SI334 8 *Determining Class’ Attributes Consider class Elevator Controller  If User wants to check and update requests, needs requests attribute  Needs methods:  check requests,  update requests Detailed: As used here means that all method names, and (as a by-product) attributes ID’d by designer, are represented on the diagram

9. Software Engineering SI334 9 Interaction Diagrams  Construct interaction diagrams for each scenario; focus is on objects and the messages passed between them.  “Passing a message” between objects really means having one object invoke a public method of another object. Example: An elevator controller that asks the doors to open and close themselves An interaction is implemented by a group of objects that collaborate by exchanging messages. These messages are represented along the links that connect the objects, using arrows pointed towards the recipient of the message. Elevator Controller Elevator Doors close doors open doors

10. Software Engineering SI334 10 *Collaboration Diagrams: spatial representation  Focus is on the relationships between objects  Structure becomes clear  Timing info is obscure, messages numbered to indicate sending order Actors represent the triggering of interactions by an element that is external to the system Example: A Person Calling an Elevator Example: Elevator Controller requesting Elevator move up one floor Elevator Controller Elevator *move up one floor

11. Software Engineering SI334 11 *Sequence Diagrams: temporal representation  Focus is on message broadcast chronology of interactions between objects. Loops and conditional branches may be represented. Example: Shows that object A sends a message to object B or object C according to a condition (X).  An object is represented by a rectangle and a vertical bar called the object's lifeline.  The message sending order is indicated by position of message on vertical axis.  Vertical axis may be labeled to express temporal constraints precisely. The following diagram shows a loop fragment.

12. Software Engineering SI334 12 *Sequence Diagrams: temporal representation  Focus is on message broadcast chronology of interactions between objects. Loops and conditional branches may be represented. Example: Shows that object A sends a message to object B or object C according to a condition (X).  An object is represented by a rectangle and a vertical bar called the object's lifeline.  The message sending order is indicated by position of message on vertical axis.  Vertical axis may be labeled to express temporal constraints precisely. The following diagram shows a loop fragment.

13. Software Engineering SI334 13 Use Scenarios to Create Interaction Diagrams Example of a Normal Use Scenario

14. Software Engineering SI334 14 Collaboration Diagram Start with diagram of objects and actors

15. Software Engineering SI334 15 *Collaboration Diagram Use scenario to identify messages passed among objects Most other messages, such as press floor button (step 1) open doors (steps 6, 14) go from an actor to an object, or from one object to another Some messages, such as start timer (steps 7, 15) go from an object to itself

16. Software Engineering SI334 16 *ICE- Complete Elevator Collaboration Diagram

17. Software Engineering SI334 17 *Equivalent Sequence Diagram

18. Software Engineering SI334 18 *Equivalent Sequence Diagram

19. Software Engineering SI334 19 Homework- Interaction Diagrams Apartment Automatic Garage Door Produce an interaction diagram (your choice of sequence or collaboration) for the Apartment Automatic Garage Door Scenario 1: “User swipes card and drives car into garage.” Scenario 1 1.Driver A swipes card. 2.If door is open, GarageDoorController resets timer. 3.If door is closed, GarageDoorController sends msg to Garage Door to open. 4.When door is fully opened, DoorOpenSensor notifies GarageDoorController. 5.GarageDoorController resets timer. 6.Timer times out; GarageDoorController notified. 7.GarageDoorController sends msg to GarageDoor to close. 8.When door is fully closed, DoorClosedSensor notifies Garage DoorController.

20. Software Engineering SI334 20 *Assigning Methods to Classes  A well-structured Interaction Diagram gives very specific information on what responsibilities a class should have.  Main question, do we assign an action to a class or to a client of that class?  Examples close doors assigned to? move one floor down assigned to?  Typical: Class at head of arrow on Interaction Diagram gets tasked with the labeled responsibility, and implements it as a method. Things to consider: Information hiding Reducing # of copies of an action Responsibility-driven design Elevator Doors Elevator

21. Software Engineering SI334 21 *Determine Clients of Objects  Design Product in Terms of Clients of Objects to determine which objects should create other objects  Draw a single arrow from each object to a client of that object  Objects that are not clients of any object have to be initiated, probably upon system launch, Additional methods may be needed.  elevator controller needs method elevator event loop so that elevator application can call it. This Completes High-Level Design for OOD!

22. Software Engineering SI334 22 ICE- Detailed Class Diagrams Elevator, ICE: Complete the Detailed Class Diagram for the Elevator, showing all method names and attributes identified by the designer for each class.

23. Software Engineering SI334 23 Homework- Detailed Class Diagrams Apartment Automatic Garage Door, Homework: Produce a Detailed Class Diagram for the Apartment Automatic Garage Door, showing all method names and attributes identified by the designer. Scenario 1 1.Driver A swipes card. 2.If door is open, GarageDoorController resets timer. 3.If door is closed, GarageDoorController sends msg to Garage Door to open. 4.When door is fully opened, DoorOpenSensor notifies GarageDoorController. 5.GarageDoorController resets timer. 6.DoorCloseTimer times out; GarageDoorController notified. 7.GarageDoorController sends msg to GarageDoor to close. 8.When door is fully closed, DoorClosed Sensor notifies GarageDoorController

24. Software Engineering SI334 24 *Step 2 of OOD: Perform Detailed Design  Detailed design of method elevator event loop, draws heavily from prior UML diagrams. Design Team:  Should not do too much: Detailed design should not become complete code  Should not do too little: It is essential for detailed design to fully indicate how all functionality is met.  So, what should detailed design’s output be?  Detailed Design’s output is program description language for all the Classes in Detailed Class diagram, with fully described interfaces.

25. Software Engineering SI334 25 *Step 2 of OOD: Perform Detailed Design

26. Software Engineering SI334 26 ICE/Homework- Detailed Design Apartment Automatic Garage Door, ICE/Homework: Produce a Detailed Design for method garageDoorControlLoop in class GarageDoorController for the Apartment Automatic Garage Door, using Java-like pseudo-code.

27. Software Engineering SI334 27 Real-Time Design Techniques  Difficulties associated with real-time systems  Inputs come from the real world Software has no control over the timing of the inputs  Frequently implemented on distributed software Communications implications Timing issues  Problems of synchronization Race conditions Deadlock (deadly embrace) Major difficulty in design of real-time systems? Determining whether timing constraints are met by the design © The McGraw-Hill Companies, 2011

28. Software Engineering SI334 28 * Design Testing  Design reviews are essential  A client representative is not usually present (except in DoD procurements)  Types of faults uncovered: © The McGraw-Hill Companies, 2011  logic faults  interface faults  lack of exception handling  non-conformance to specification

29. Software Engineering SI334 29 *Testing During the Design Workflow  Goal of Design Testing- answer the following:  Is the specification accurately and completely incorporated into the design?  Is the design itself correct? No logic faults Interface for each class fully defined.  Design reviews. Purpose is to show that Design correctly reflects the Specification. How can this be shown?  Show how each normal/abnormal scenario is met by the design.  Critical that proper set of scenarios was developed during OOA.

30. Software Engineering SI334 30 Formal Techniques for Detailed Design  Implementing a complete product and then proving it correct is hard  However, use of formal techniques during detailed design can help  Correctness proving can be applied to module-sized pieces  The design should have fewer faults if it is developed in parallel with a correctness proof  If the same programmer does the detailed design and implementation The programmer will have a positive attitude to the detailed design This should lead to fewer faults © The McGraw-Hill Companies, 2011

31. Software Engineering SI334 31 *Case Tools for OOD  UpperCASE tools  Examples of UpperCASE tools: Software through Pictures, Visual Paradigm Rational Rose  Built around data dictionary  Screen, report generators  What automated support could be provided by a case tool that represents OOD using UML? Automated conversion between Diagrams, Generation of Class Constructs from Class Design with Class names, attributes, methods filled in. Programmers focus on fleshing out method bodies

32. Software Engineering SI334 32 *Metrics for OOD  What Metrics can be used to describe various aspects of the Design?  One is McCabe’s Cyclomatic complexity. Measure based on # of control flow decisions, can apply to pseudo-code.  the number of binary decisions plus 1,  a metric of design quality, the lower the M the better  What other aspects of a Design can be Measured?  Raw number of modules gives a crude measure of size of the targeted product.  Couplings between Modules and Cohesiveness of Modules. Advantage: Easy to compute, can be automated Disadvantage: Measures control complexity only, does not measure data complexity.

33. Software Engineering SI334 33 Design and Abstraction  Classical design activities  Architectural design  Detailed design  Design testing  Architectural design  Detailed design © The McGraw-Hill Companies, 2011  Each module is designed Specific algorithms, data structures  Input: Specifications  Output: Modular decomposition

34. Software Engineering SI334 34 Data and Actions  Two aspects of a product  Actions that operate on data  Data on which actions operate  The two basic ways of designing a product  Operation-oriented design  Data-oriented design  Third way  Hybrid methods  For example, object-oriented design © The McGraw-Hill Companies, 2011

35. Software Engineering SI334 35 Operation-Oriented Design  Data flow analysis  Use it with most specification methods (Structured Systems Analysis here)  Key point: We have detailed action information from the DFD Figure 14.1 © The McGraw-Hill Companies, 2011

36. Software Engineering SI334 36 Data Flow Analysis  Every product transforms input into output Figure 14.1

37. Software Engineering SI334 37 Data Flow Analysis  Every product transforms input into output  Determine  “Point of highest abstraction of input”  “Point of highest abstract of output” After Figure 14.2

38. Software Engineering SI334 38 Data Flow Analysis (cont.)  Use these points to decompose the product into three modules  Repeat stepwise until each module has high cohesion (degree of interaction within a module)  Minor modifications may be needed to lower the coupling (degree of interaction between two modules) © The McGraw-Hill Companies, 2011 Figure 14.2

39. Software Engineering SI334 39 *Mini Case Study: Word Counting  Example: Design a product which takes as input a file name, and returns the number of words in that file (like UNIX wc ) Figure 14.3 © The McGraw-Hill Companies, 2011

40. Software Engineering SI334 40 *Mini Case Study: Word Counting (cont.)  First refinement  Now refine the two modules of communicational cohesion* (*module performs series of operations (on same data) related by sequence of steps to be followed) Figure 14.4 © The McGraw-Hill Companies, 2011

41. Software Engineering SI334 41  Second refinement  All eight modules now have functional cohesion* (*module that performs exactly one operation or achieves a single goal) Mini Case Study: Word Counting (cont.) Figure 14.5 © The McGraw-Hill Companies, 2011

42. Software Engineering SI334 42 Data Flow Analysis Extensions  In real-world products, there is  More than one input stream, and  More than one output stream © The McGraw-Hill Companies, 2011

43. Software Engineering SI334 43 Data Flow Analysis Extensions (cont.)  Find the point of highest abstraction for each stream  Continue until each module has high cohesion  Adjust the coupling if needed Figure 14.8 © The McGraw-Hill Companies, 2011

44. Software Engineering SI334 44 ICE- Course Project Data Flow Analysis ICE: Produce a high-level Data Flow Diagram (DFD) for your course project, showing the point of highest abstraction of input and point of highest abstraction of output.

45. Software Engineering SI334 45 *Detailed Design  The architectural design is complete  So proceed to the detailed design  Two formats for representing the detailed design: © The McGraw-Hill Companies, 2011  Tabular  Pseudocode (PDL—program description language)

46. Software Engineering SI334 46 Detailed Design: Tabular Format Figure 14.6(a) © The McGraw-Hill Companies, 2011

47. Software Engineering SI334 47 Detailed Design: PDL Format Figure 14.7 © The McGraw-Hill Companies, 2011

48. Software Engineering SI334 48 Data-Oriented Design  Basic principle  The structure of a product must conform to the structure of its data  Three very similar methods  Michael Jackson [1975], Warnier [1976], Orr [1981]

49. Software Engineering SI334 49 Data-Oriented Design  Basic principle  The structure of a product must conform to the structure of its data  Three very similar methods  Michael Jackson [1975], Warnier [1976], Orr [1981]

50. Software Engineering SI334 50 Data-Oriented Design  Basic principle  The structure of a product must conform to the structure of its data  Three very similar methods  Michael Jackson [1975], Warnier [1976], Orr [1981]  Data-oriented design  Has never been as popular as action-oriented design  With the rise of OOD, data-oriented design has largely fallen out of fashion

51. Software Engineering SI334 51 Recap: Relationships Between UML Diagrams