1. UML CSE 470 : Software Engineering

2. Unified Modeling Language UML is a modeling language to express and design documents, software –Particularly useful for OO design –Not a process –Independent of implementation language What is UML?

3. Types of UML Diagrams 1. Use Case Diagram: capture requirements. Clarify exactly what the system is supposed to do 2. Class Diagram: static relationships between classes. Describe the types of objects in the system and various kinds of static relationship that exist among them. 3. Sequence Diagram: Displays the time sequence of the objects participating in the interaction.

4. Use Case Diagram

5. Use Case Diagrams: A series of actions performed by user Use case diagrams represent external behavior Use case diagrams are useful as an index into the use cases

6. Actor An actor models an external entity which communicates with the system:  User  External system  Physical environment An actor has a unique name and an optional description. Examples:  Passenger: A person in the train  GPS satellite: Provides the system with GPS coordinates Passenger

7. Actor Primary actor: interact to achieve required system function and derive the intended Secondary actor: support the system so that primary actors can do their work. It is important to note that an actor and an end user are not necessarily the same thing.

8. Use case A use case represents a class of functionality provided by the system as an event flow. A use case consists of: Unique name Participating actors Entry conditions Flow of events Exit conditions PurchaseTicket

9. Use Case Diagrams Library System Borrow Order Title Fine Remittance Client Employee Supervisor A generalized description of how a system will be used. Provides an overview of the intended functionality of the system Boundary Actor Use Case

10. Object oriented approach?

11. Use Case Diagram(core relationship) Include: a dotted line labeled > beginning at base use case and ending with an arrows pointing to the include use case. An “Include” relationship is used to indicate that a particular Use Case must include another use case to perform its function. > or in MS Visio A Use Case may be included by one or more Use Cases, so it reduces duplication of functionality. Example: the Use Case may be included every time when the Use Case is run.

12. Use Case Diagram (core relationship) Extend : a dotted line labeled > with an arrow toward the base case. The extending use case may add behavior to the base use case. The base class declares “extension points”. > Used when exceptional circumstances are encountered. For example, the Use Case may optionally extend the regular Use Case. Note: other expressions. For example, in MS Visio

13. Example Problem: Develop a system where a patient can make an appointment, cancel his appointment and pay bill to the corresponding authority

14. Example At first, try to define your actors List the set of user cases Connect each user cases to an actor Show the relation between each user cases

15. An approach of Jacobson Who is the primary actor, the secondary actor(s)? What are the actor’s goals? What preconditions should exist before the story begins? What main tasks or functions are performed by the actor? What exceptions might be considered as the story is described? What variations in the actor’s interaction are possible? What system information will the actor acquire, produce, or change? Will the actor have to inform the system about changes in the external environment? What information does the actor desire from the system? Does the actor wish to be informed about unexpected changes?

16. Practice yourself

17. Solution

18. Use Case Diagrams (cont.) Pay Bill is a parent use case and Bill Insurance is the child use case. (generalization) Both Make Appointment and Request Medication include Check Patient Record as a subtask.(include) The extension point is written inside the base case Pay bill; the extending class Defer payment adds the behavior of this extension point. (extend)

19. Use Case Diagram: Example Name: Purchase ticket Participating actor: Passenger Entry condition: Passenger standing in front of ticket distributor. Passenger has sufficient money to purchase ticket. Exit condition: Passenger has ticket. Event flow: 1. Passenger selects the number of zones to be traveled. 2. Distributor displays the amount due. 3. Passenger inserts money, of at least the amount due. 4. Distributor returns change. 5. Distributor issues ticket. Anything missing ? Exceptional cases!

20. Use Cases are useful to… Determining requirements  New use cases often generate new requirements as the system is analyzed and the design takes shape. Communicating with clients  Their notational simplicity makes use case diagrams a good way for developers to communicate with clients. Generating test cases  The collection of scenarios for a use case may suggest a suite of test cases for those scenarios.

21. Class Diagram

22. A class is a description of a set of objects Each class is represented by a rectangle subdivided into three compartments  Name  Attributes  Operations Class Diagram

23. Notation: Classes Window origin size open() close() move() display() name attributes operations

24. The "Hello, World" Example import java.awt.Graphics; class HelloWorld extends java.applet.Applet { public void paint (Graphics g) { g.drawString ("Hello, World!", 10, 10); } Example from: BJR

25. HelloWorld paint() class name operations The "Hello, World" Example

26. HelloWorld paint() g.drawString ("HelloWorld", 0, 10)" class name operations annotation The "Hello, World" Example

27. UML Class Notation A class is a rectangle divided into three parts  Class name  Class attributes (i.e. data members, variables)  Class operations (i.e. methods) Modifiers  Private: -  Public: +  Protected: #  Static: Underlined Abstract class: Name in italics

28. UML Class Notation

29. Lines or arrows between classes indicate relationships  Association  A relationship between instances of two classes, where one class must know about the other to do its work, e.g. client communicates to server  indicated by a straight line or arrow  Aggregation  An association where one class belongs to a collection, e.g. instructor part of Faculty  Indicated by an empty diamond on the side of the collection  Composition  Strong form of Aggregation  Lifetime control; components cannot exist without the aggregate  Indicated by a solid diamond on the side of the collection  Inheritance  An inheritance link indicating one class a superclass relationship, e.g. bird is part of mammal  Indicated by triangle pointing to superclass

30. Binary Association myB.service();myA.doSomething() ; Binary Association: Both entities “Know About” each other Optionally, may create an Associate Class

31. Unary Association A knows about B, but B knows nothing about A Arrow points in direction of the dependency myB.service();

32. Aggregation Aggregation is an association with a “collection-member” relationship void doSomething() aModule.service(); Hollow diamond on the Collection side No sole ownership implied

33. Composition Composition is Aggregation with: Lifetime Control (owner controls construction, destruction) Part object may belong to only one whole object Filled diamond on side of the Collection members[0] = new Employee(); … delete members[0];

34. Inheritance Standard concept of inheritance class B() extends A … Base Class Derived Class

35. UML Multiplicities MultiplicitiesMeaning 0..1 zero or one instance. The notation n.. m indicates n to m instances. 0..* or * no limit on the number of instances (including none). 1exactly one instance 1..*at least one instance Links on associations to specify more details about the relationship

36. Problem Problem: Design a software tool for a shopping mall where customer can buy different types of products Make a class diagram with customer, order, item, item details and other classes Show the relationship between the existing classes

37. UML Class Example

38. Sequence / Activity Diagram

39. Activity diagram Activity diagram supplements the use case by providing a graphical representation of the flow of interaction within a specific scenario Similar to the flowchart

40. Activity diagram: notation Rounded rectangles to imply a specific system function, Arrows to represent flow through the system, Decision diamonds to depict a branching decision Solid horizontal lines to indicate that parallel activities are occurring

41. Activity diagram for Access camera surveillance via the Internet—display camera views function

42. Thank you

43. References Cornell University, USA http://www.cs.cornell.edu/courses/cs501/2000fa/slides.html Shiyuan Jin, Fall 2006 (Student in UCR) Shiyuan Jin, Fall 2006 (Student in UCR) Roger s. pressman, Software Engineering a practitioners approach, 7 th ed