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. Activity Diagram: Through an activity diagram, the designer/analyst specifies the essential sequencing rules the method or use case has to follow

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

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

20. Class Diagram

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

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

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

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

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

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

27. UML Class Notation

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

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

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

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

32. 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];

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

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

35. UML Class Example

36. Activity Diagram

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

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

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

41. Thank you

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