tailieunhanh - Lecture Software engineering: Lecture 7 - Ivan Marsic

Lecture 7: Object oriented design. The main contents of this chapter include all of the following: Assigning responsibilities to objects, design principles (Expert doer, high cohesion, low coupling), business policies, class diagram. | Ivan Marsic Rutgers University LECTURE 7: Object Oriented Design Topics Assigning Responsibilities to Objects Design Principles Expert Doer High Cohesion Low Coupling Business Policies Class Diagram select function(“unlock") : System User «initiating actor» prompt for the key enter key verify key signal: valid key, lock open open the lock, turn on the light Timer «offstage actor» start ("duration“) System Sequence Diagrams considered interactions between the actors We already worked with interaction diagrams: System Sequence Diagrams System Sequence Diagrams Design: Object Interactions System Sequence Diagrams considered interactions between the actors Object Sequence Diagrams consider interactions between the objects System Sequence Diagram Design Sequence Diagram Metaphor for Software Design: “Connecting the Dots” We start with objects/concepts from the Domain Model and modify or introduce new objects, as needed to make the system function work. . | Ivan Marsic Rutgers University LECTURE 7: Object Oriented Design Topics Assigning Responsibilities to Objects Design Principles Expert Doer High Cohesion Low Coupling Business Policies Class Diagram select function(“unlock") : System User «initiating actor» prompt for the key enter key verify key signal: valid key, lock open open the lock, turn on the light Timer «offstage actor» start ("duration“) System Sequence Diagrams considered interactions between the actors We already worked with interaction diagrams: System Sequence Diagrams System Sequence Diagrams Design: Object Interactions System Sequence Diagrams considered interactions between the actors Object Sequence Diagrams consider interactions between the objects System Sequence Diagram Design Sequence Diagram Metaphor for Software Design: “Connecting the Dots” We start with objects/concepts from the Domain Model and modify or introduce new objects, as needed to make the system function work. Types of Object Responsibilities Knowing responsibility: Memorizing data or references, such as data values, data collections, or references to other objects, represented as a property Doing responsibility: Performing computations, such as data processing, control of physical devices, etc., represented as a method Communicating responsibility: Communicating with other objects, represented as message sending (method invocation) How To “Connect the Dots” Use Case UC-1: Unlock (flow of events): 1. User enters the key code 2. System verifies that the key is valid 3. System signals the key validity 4. System signals: (a) to LockDevice to disarm the lock (b) to LightSwitch to turn the light on Starting Points: Domain Model from UC-1 (domain concepts): Q: who handles this data? Interface objects and Controller Q: who performs the verification? Based on what data? Key Checker, based on entered key-code and stored valid keys message: checkKey(k) Controller and Interface objects, based on