Object Oriented Design Jerry KotubaSYST Object Oriented Methodologies1
Recap SSDs ICE-07 Take up Schedule Today Finalize SSD’s – Message notation Sequence Diagrams - Part I Jerry KotubaSYST Object Oriented Methodologies2
3
Explain the purpose and objectives of object- oriented design Develop design class diagrams Develop Sequence Diagrams Learn the importance of “low” coupling and “high” cohesion in design Explain the fundamental principles of object- oriented design 4
Bridge between users’ requirements and new system’s programming Object-oriented design is process by which detailed object-oriented models are built Programmers use design to write code and test new system User interface, network, controls, security, and database require design tasks and models 5
6 Design Patterns and the Use Case Controller Use Case Realization Designing with Sequence Diagrams Object Responsibility Three-Layer Design Design Patterns
7 Design pattern A standard solution template to a design requirement that facilitates the use of good design principles Use case controller pattern Design requirement is to identify which problem domain class should receive input messages from the user interface for a use case
8 Solution is to choose a class to serve as a collection point for all incoming messages for the use case. Controller acts as intermediary between outside world and internal system Artifact – a class invented by a system designer to handle a needed system function, such as a controller class
9 Use Case Controller Pattern
10 Realization of use case done through interaction diagram development Determine what objects collaborate by sending messages to each other to carry out use case Sequence diagrams and communication diagrams represent results of design decisions Use well-established design principles such as coupling, cohesion, separation of responsibilities
11
12
SSD Detailed Sequence Jerry KotubaSYST Object Oriented Methodologies13
Register for Course Use Case Jerry KotubaSYST Object Oriented Methodologies14
15 Sequence diagrams used to explain object interactions and document design decisions Document inputs to and outputs from system for single use case or scenario Capture interactions between system and external world as represented by actors Inputs are messages from actor to system Outputs are return messages showing data
16 Objects are responsible for system processing Responsibilities include knowing and doing Knowing about object’s own data and other classes of objects with which it collaborates to carry out use cases Doing activities to assist in execution of use case Receive and process messages Instantiate, or create, new objects required to complete use case Design means assigning responsibility to the appropriate classes based on design principles and using design patterns
17 Start with elements from SSD Replace :System object with use case controller Add other objects to be included in use case Select input message from the use case Add all objects that must collaborate Determine other messages to be sent Which object is source and destination of each message?
18
19 First Cut Design Class Diagram for Cancel an Order
20
21
22 Take each input message and determine internal messages that result from that input For that message, determine its objective Needed information, class destination, class source, and objects created as a result Double check for all required classes Flesh out components for each message Iteration, guard-condition, passed parameters, return values
23 Perfect technology assumption Don’t include system controls like login/logout (yet) Perfect memory assumption Don’t worry about object persistence (yet) Assume objects are in memory ready to work Perfect solution assumption Don’t worry about exception conditions (yet) Assume happy path/no problems solution
24
25 First cut DCD for Create new phone order
26
27
28 Complete Sequence Diagram
29 Object-Oriented Three-Layer Program
Diagrams developed for analysis/requirements Use case diagrams, use case descriptions and activity diagrams, domain model class diagrams, and system sequence diagrams Diagrams developed for design Component diagrams and Deployment diagrams Interaction diagrams and package diagrams Design class diagrams 30
Design class diagrams and detailed sequence diagrams Use each other as inputs and are developed in parallel Sequence diagrams define the interactions between objects in order to execute a use case. Interactions are called messages Correspond to method calls in programming language Design Classes show attributes and method signatures
32
UML does not distinguish between design class notation and domain model notation Domain model class diagram shows conceptual classes in users’ work environment Design class diagram specifically defines software classes UML uses stereotype notation to categorize a model element by its characteristics 34
35
SYST39409-Object Oriented Methodologies36 Illustration Exercise[1]
SYST39409-Object Oriented Methodologies37 Illustration Exercise[2] Use Case – Check-out Book S.S.D. Domain Class Diagram
SYST39409-Object Oriented Methodologies38 ClassResponsibilitiesCollaborating classes with return data Library PatronCreate a reservation Create a loan [Reservation] (ID) [Loan] (ID) ReservationIdentify Book title[Book Title] (Title details) LoanIdentify Book title[Book Title] (Title details) Book TitleIdentify Book Copy Number[BookCopy] (ID) BookCopy Think of responsibilities as “Requests” to do something.
Jerry KotubaSYST Object Oriented Methodologies39
Sequence Diagrams continued… Jerry KotubaSYST Object Oriented Methodologies40