UML Diagrams ( Unified Modeling Language)

1. UML Diagrams (Unified Modeling Language) C.Thomas Wu.Introduction to O-O Programming

2. UML Diagram Introduction Graphical notations are useful and straight-forward in displaying information about a system design. Three gurus Booch, Rumbaugh, and Jacobson developed the UML diagrams C.Thomas Wu.Introduction to O-O Programming

3. UML • Models various aspects of software development for OO systems • Includes several types of diagrams • Class • Use Case • Collaboration • Sequence • State • Activity C.Thomas Wu.Introduction to O-O Programming

4. Class Diagrams (are static) • Are one of the most significant diagram of the UML diagrams used by software developers • Are used to create logical models of the computer-based systems • Show data members, methods, and the static relationships between the classes that are used to build the system. The relationships are also called associations C.Thomas Wu.Introduction to O-O Programming

5. BasicUML Class and Object Diagram C.Thomas Wu.Introduction to O-O Programming

6. Class Diagrams - Data Types and Parameters • Sometimes the data type of attributes and parameters, and return types are not shown on the class diagram. • If you see just the aMethodName(), don’t assume that there is no parameters for the method. Sometimes they are omitted to save space. C.Thomas Wu.Introduction to O-O Programming

7. Class Diagram for Premiere Products Database - Source: Adamski and Pratt

8. Class Diagram with Constraints Source: Pratt and Adamski

9. Class Diagram with a • Generalization (super class) and a • 2. Specialization (subclass) with a Constraint • Source: Pratt and Adamski

10. Building a Specification Model • The OO way of modeling reality does not try to organize all of reality • We usually try to model only the relevant features of a specific application domain • select a manageable domain • One way of bounding the domain is to use Use Cases • The main purpose of use case modeling is to understand the external behavior of the system. The later stages will be easier if up-front requirements are clear and unambiguous C.Thomas Wu.Introduction to O-O Programming

11. One of the values of use cases is that they ease the discussions between stakeholders and analysts/developers. They are usually written using business terms known to the majority of the stakeholders C.Thomas Wu.Introduction to O-O Programming

12. Use Cases • Uses cases capture the functional requirements and the business-value propositions of a proposed system -along with its high-level processes needed to achieve these specific value propositions • A used case is a generic description of an entire transaction involving several objects (Lee and Tepfenhart) C.Thomas Wu.Introduction to O-O Programming

13. Building a Specification Model • A use case: • Specifies a sequence of actions, including variants, that a system performs and that yields an observable result of value to an actor (Jacobson, Booch, Rumbaugh) • Is a description of all the possible sequences of interactions among the system and one or more actors in response to some initial stimulus by one of the actors (Rumbaugh) • Is a collection of possible sequences of interactions between the system under discussion and its external actors, related to a particular goal (Cockburn) C.Thomas Wu.Introduction to O-O Programming

14. Use Cases • Uses cases are concerned with the actors and the sequences of interactions between them • Some important concepts include: • The goal - the business value to the user(s) • The system - the application with all the hardware that will be used by the “users” • An actor – external entity that interacts with the system -represented by a labeled stick figures • Use case – describes an interaction that achieves a goal for an actor • Use-case bundle – a collection of used cases that are highly correlated with some activity or organizing business element C.Thomas Wu.Introduction to O-O Programming

15. Use Cases • Programmers use Use Cases to develop test plans • The Goal • use cases describe in a formal way how a computer system works from an external view • to capture a scenario that completes to some point the business value of the user’s view • To model the system functional requirements • The System • Usually viewed as a “black-box” system -the user cannot see the system inner workings. The user verifies that the system behaves the way it is suppose to no matter how it is built. C.Thomas Wu.Introduction to O-O Programming

16. Use Cases –Information Captured • The Actors • Uses cases divide the world into two parts: the system and the users (actors) • Actors are a way of classifying system users who share a set of common interactions to achieve a goal • An actor represents an external entity that can initiate actions or receive requests from the system • A specific user is an instance of an actor • The set of requests/responses from/to the actors represents the system boundaries C.Thomas Wu.Introduction to O-O Programming

17. Use Cases • Use Case and Scenario • A use case describes a system in terms of sequences of interactions between various actors and the system • A scenario is a short narrative that outlines a sequence of requests and responses between a user and the system –what happens next • A scenario describes how a user will use the system to achieve a goal • A use case is the generalized form of a family of scenarios • A scenario is a specific instance of a use case C.Thomas Wu.Introduction to O-O Programming

18. Use Cases • The Use Case describes • The pre-conditions that must exist for the used case to be successfully invoked • The post-conditions that define the state of the system after the use case is concluded • Detailed business logic that is performed (non-technology-dependent) • Business exceptions that can occur required data not location, computations aborted • Business constraints that apply to the system when reacting to a specific user request –resource allocation not available C.Thomas Wu.Introduction to O-O Programming

19. Use Cases • To effectively capture the functional aspects of a system the description of the system must be kept at a consistent level of abstraction • To successfully develop use cases we must know the dimension of the functional description we are trying to capture • These dimensions include: • High-level and low-level • Primary and secondary • Essential and concrete Richard C. Lee and William M. Tepfenhart

20. Use Cases • High-level functional descriptions • Provide general and brief descriptions of the essence of the business values provided by the system- No concern of how to achieve the business values • Low-level functional descriptions • Provide details showing the exact order of activities, tasks, or alternatives Richard C. Lee and William M. Tepfenhart

21. Use Cases • Primary functions • Describe the essential functionality provided to the user – the reason the system exists • Secondary functions • Deal with rare and exceptional cases –necessary to deliver a robust system • Essential functions • Describe business solutions that are independent of implementation (Hardware and software -black-box implementation is done in total ignorance of how the object was constructed) • Concrete functions • Describe use cases that are design dependent (clear-box) Richard C. Lee and William M. Tepfenhart

22. High-level, primary, essential use case diagram Drop Course Add Course Delete Course Cancel Course Register Student Admin Prof Course Registration System Richard C. Lee and William M. Tepfenhart

23. Template for Documenting Use Cases – Textual Description Richard C. Lee and William M. Tepfenhart

24. Template for Documenting Use Cases – Textual Description Richard C. Lee and William M. Tepfenhart

25. The Vending Machine Class Diagram 1 buys * Customer money insertCoint() receiveProduct() Merchant money product removeMoney() addProduct() Coin Box money requestProduct() rejectCoin() 1 owns 1 Coin * * 1 1 Bad Coin 1 supplier Dispenser product dispenseProduct() reject Request() Apple Juice 1 0..* Product 1 1 C.Thomas Wu.Introduction to O-O Programming

26. Merchant Customer The Vending Machine System Use Case Diagram Add product Remove Coins Receive product Request product <<extends>> A link that displays exactly how an optional actor interact with an exception Rejected Coin C.Thomas Wu.Introduction to O-O Programming

27. Sequence Diagrams • Model system behavior (methods) for use cases by showing the necessary class interactions. Shows the time ordering of a sequence of method calls. • They show how the user (actor) communicates with the system to complete the job. • The events modeled in the diagram are external events started by an actor. • The actors and objects are placed horizontally across the top of the diagram. • The vertical lines called a lifeline is attached to each actor or object. The lifeline becomes an activation box to depict the live activation period of the object or actor. • A message is represented using an arrow labeled with a message. The message may hold an argument list and a return type. • Dashed arrows may be used to indicate object flow. If an object’s ends during the execution of the use case an X is placed at the bottom of its lifeline. C.Thomas Wu.Introduction to O-O Programming

28. Customer The Vending Machine System Sequence Diagram Dispenser Coin Box insertCoin() requestProduct() rejectRequest() rejectCoin() Product C.Thomas Wu.Introduction to O-O Programming

29. See the skeleton code to use for the Vending Machine System sequence diagram: Vending Machine Sequence UML Diagram Skeleton Code.doc Stored on the M: drive …in the UML folder. C.Thomas Wu.Introduction to O-O Programming

30. Customer Collaboration Diagrams Show the message passing structure of the system. The emphasis is on the roles of the objects as they work together to complete a system function. They can be used to display parts of a design pattern and they are helpful for verifying class diagrams 2. requestProduct 1. SendCoin :Coin Box :Dispenser 4. returnCoin 3. rejectRequest Return coin collaboration diagram C.Thomas Wu.Introduction to O-O Programming

31. Customer Collaboration Diagrams Product delivery collaboration diagram 2. e 1. SendCoin 2. requestProduct :Coin Box 3. deliverProduct :Dispenser C.Thomas Wu.Introduction to O-O Programming

32. State Diagram Describes the behavior (method) of a system, subsystem, or an individual object. The system state is determined by the values assigned to object’s data members. A system’s current state is only changed by a new event.. State diagrams display changes that affect the system behavior or its object data members when an external factor triggers an event.. Wait for Coin insert coin Return Coin bad coin Check Coin good coin Check Dispenser no product product available Dispense Product C.Thomas Wu.Introduction to O-O Programming

33. Activity Diagram Display the work flow of an object. They are similar to state diagrams See Activity Diagram.doc C.Thomas Wu.Introduction to O-O Programming