1. Sucha Smanchat sucha.smanchat@acm.org

2.  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

3.  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

4.  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

5.  Use the > and > 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_casehttp://en.wikipedia.org/wiki/Use_case

6. 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.

7.  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

8.  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

9.  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?

10.  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?

11.  Draw sequence diagrams for the use cases in your use case diagrams  Try to be as much detailed as possible

12.  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)

13.  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

14.  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)

15.  It is possible to specify the type of classes by inscribing > with class name  GUI classes may be inscribed with >  Controller classes (classes that contain business rules and/or calculations) may be inscribed with >  Classes that model data (database) may be inscribed with >  Be careful as stereotype may cause confusion  Do not use > for GUI classes

16.  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

17.  Software Development Methodology  SDLC ?  ERD & DFD  Object-Oriented Concept & UML  OOAD  Use Case Diagram  Sequence Diagram  Class Diagram