Sucha Smanchat firstname.lastname@example.org. Object-Oriented Analysis and Design (1). UML in System Analysis and Design. Steps in OOAD using UML Use Case Diagram Sequence Diagram / Communication Diagram Class Diagram State Machine Diagram Activity Diagram Package Diagram Component Diagram
UML in System Analysis and Design Steps in OOAD using UML Use Case Diagram Sequence Diagram / Communication Diagram Class Diagram State Machine Diagram Activity Diagram Package Diagram Component Diagram Deployment Diagram
A Note UML is somewhat hard One problem can be solved by different designs No exact answer UML Specification is continuously updated And it’s !@#$% hard to catch up Different books say things differently The steps in this presentation is but one common guideline
Step 1:Use Case Diagram Identify functional requirements of existing and/or new system Identify stakeholders/users of the system Draw system boundary Draw each functional requirement as a use case Less or more use cases? Why? Represent users as actors
Step 1:Use Case Diagram(cont.) Use the <<extend>> and <<include>> relationships as needed Usually, an extending use case is adding extra function to the extended use case Usually, an included use case is a common function which is shared by many other use cases Write use case description for each and every use case Format varies - see http://en.wikipedia.org/wiki/Use_case
Use Case Description Example Name: Primary Actor: Stakeholders and Interests: Preconditions: Postconditions: Main Scenario: 1. 2. … Extensions: 1a. 2a. Adapted from Craig Larman, “Applying UML and Patterns: An Introduction to Object- Oriented Analysis and Design and the Unified Process”, 2nd Ed., Prentice Hall, 2002.
Exercise Draw a ‘complete’ use case diagram (including use case description) for one of the following scenarios (at least 3 use cases) Automatic Teller Machine (ATM) An online game server A customer support system for a product of your choice Or a system being used in your work
Step 2:Sequence Diagram Based on the use case diagram, draw a sequence diagram (or communication/collaboration diagram) for each use case There might be more than one sequence diagram to represent alternate routes When drawing sequence diagram, think of the real world scenario (that you write in use case description) and select potential objects/classes
Step 2:Sequence Diagram (Cont) Drawing sequence diagram helps identify classes and objects in the system along with the communications between them The communications, in turn, identify the behavior of the classes and objects in the system How do you tell what should be a class/object? If it’s not a class, what should it be?
Step 2:Sequence Diagram (Cont) Distinguish different types of communications (refer to UML slides) Use them appropriately Be careful about notation Do you need to refer to a specific object of a class?
Exercise Draw sequence diagrams for the use cases in your use case diagrams Try to be as much detailed as possible
Step 3:Class Diagram Most of the objects/classes in the system are identified in sequence diagram Additional classes may (likely) be required Draw classes identified from step 2 Add necessary attributes Specify data type of the attributes Specify visibility of the attributes Usually ‘private’ (encapsulation / data hiding) ‘public’ or ‘protected’ may be used (e.g. static variable)
Step 3:Class Diagram (cont) Add behavior (methods) as identified by communications between objects in sequence diagrams What can an object do? What should an object do for other objects? Specify method’s parameters Parameter VS Argument? Specify visibility Usually ‘public’ or ‘protected’, but ‘private’ is possible for method used within the class
Step 3:Class Diagram (cont) Add relationships between classes Association (uni-directional / bi-directional) Generalization (inheritance) Aggregation Composition Specify name of relationship and/or roles of the classes involved Specify multiplicity (0..1, 1..1, 0..m, 1..m)
Step 3:Class Diagram (cont) It is possible to specify the type of classes by inscribing <<stereotype>> with class name GUI classes may be inscribed with <<boundary>> Controller classes (classes that contain business rules and/or calculations) may be inscribed with <<controller>> Classes that model data (database) may be inscribed with <<entity>> Be careful as stereotype may cause confusion Do not use <<interface>> for GUI classes
Exercise Draw a class diagram for your system using the objects/classes and their behavior obtained from the sequence diagrams Again, try to be as much detailed as possible
SummaryFirst Half Software Development Methodology SDLC ? ERD & DFD Object-Oriented Concept & UML OOAD Use Case Diagram Sequence Diagram Class Diagram