180 likes | 328 Vues
* Object-Oriented Design ( Schach Chap 14). Goal: Design product in terms of objects identified during OOA OOD consists of four steps: Construct interaction diagrams for each scenario. Two types: Collaboration Diagrams (Spatial),
E N D
*Object-Oriented Design (Schach Chap 14) • Goal: Design product in terms of objects identified during OOA • OOD consists of four steps: • Construct interaction diagrams for each scenario. Two types: • Collaboration Diagrams (Spatial), • Sequence Diagrams (Temporal) • Develop detailed class diagram • Design the product in terms of clients of objects • Proceed to detailed design Result of our Elevator System OOA: A UML Class Diagram 1..3 Constitute “High-Level” Design
*Step 1 of OOD: Interaction Diagrams • Construct interaction diagrams for each scenario, focus is on the objects and the messages passed between them. • “Passing a message” between objects really means having one object invoke a public member function of another object. • An interaction is implemented by a group of objects that collaborate by exchanging messages. • Two variants of UML Interaction Diagrams: • Collaboration/Communication and • Sequence Diagrams
*Collaboration Diagrams:spatial representation • Focus is on the relationships between objects • Goal is to understand Structure of Design’s components • Timing info is obscure, messages numbered to indicate sending order • Example: Consider making a hotel reservation
Example: Elevator Collaboration Diagram • Sally is on the 10th floor and presses a floor button. The elevator arrives from the ground floor to pick her up.
*Sequence Diagrams:temporal representation • Focus is on message broadcast chronology of interactions between objects from a temporal standpoint. • An object is represented by a rectangle and a vertical bar. • Message sending order indicated by position on axis. • Again, consider making a hotel reservation
Example: Elevator Sequence Diagram • Sally is on the 10th floor and presses a floor button. The elevator arrives from the ground floor to pick her up.
Connection between Scenarios & Sequence Diagrams Example of a Normal Use Scenario
A Collaboration Diagram is equivalent to its corresponding Sequence Diagram A UML Collaboration Diagram
MFKA UML Sequence Diagram • ICE:Produce a UML Sequence Diagram for the Marine Field Kitchen Assistant scenario of “Finding a recipe for chili that includes chipotle powder, scaling it for 200 Marines per meal, and generating a grocery list for a week’s worth of chili (to be eaten 3 times a day).”
*Step 2 of OOD: Construct Detailed Class Diagram • 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? • Information hiding • Reducing copies of an action • Responsibility-driven design • Examples • close doors assigned to Elevator Doors • move one floor down assigned to Elevator • Typical: Class at head of arrow on Interaction Diagram gets tasked with the labeled responsibility, and implements it as a method.
*Construct Detailed Class Diagram Consider class Elevator Controller • If User wants to log and update requests, needs requests attribute • Needs methods: • log request, • update requests, • request is pending Detailed: As usedhere means that all method names, and (as a by-product) attributes ID’d by designer, are represented on the diagram
*Step 3 of OOD: 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 control loop so that elevator application can call it. This Completes High-Level Design for OOD!
*Step 4 of OOD: Perform Detailed Design • Detailed design of method elevator controller 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, how to verify we are done with detailed design?
*ICE: Detailed Design • Detailed design of method elevator controller 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? • ICE: Take an assigned class, and • Complete the detailed UML class diagram of assigned class (to include its methods and attributes), and • Give the pseudo-code for the most complex method in the class. • We will pick a QA volunteer to walk thru the chipotle chili scenario and make sure each class has the methods the sequence diagram expects of it.
*Testing During the Design Phase • Design itself must be correct • No logic faults • Interface for each class fully defined. • Design reviews. Purpose is to show that Design correctly reflects Specification. How can this be shown?
*Case Tools for OOD • Computer Aided Software Engineering (CASE) tools • Examples of CASE tools: • Software through Pictures, • Rational Rose • Visual Paradigm • Built around data dictionary • Screen, report generators • What automated support could be provided by a case tool that represents OOD using UML?
*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 controlflow 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? • Advantage: Easy to compute, can be automated • Disadvantage: Measures control complexity only, does not measure data complexity.