Advance Information Systems Development (SD3043) UML Overview

1. Advance Information Systems Development (SD3043)UML Overview

2. Learning Objectives • After this lecture you should be able to: • Understand UML concepts • Understand UML notations • Use UML to model information systems

3. Lecture Layout • Notation • An introduction to the Unified Modeling Language (UML) • An overview of UML • Use Case Diagrams • Class Diagrams • Interaction diagrams • Statechart Diagrams • Activity Diagrams • Conclusion

4. Notation • According to the “hyper dictionary” notation is defined as a technical system of symbols used to represent special things • Notation enable us to articulate complex ideas precisely • In large projects accuracy and clarity are vital • A notation should • Have well defined semantics • Be well suited for representing a given aspect of a system • Be well understood among project participants

5. An introduction to UML Object Modeling Technique (OMT) Booch Method UML Coad and Yourdon Shlaer and Mellor Martin and Odell Object Oriented Software Engineering (OOSE) THE GOAL: Provide a standard notation that can be used by all object-oriented methods to model Object Oriented Systems Result of the unification Has influenced

6. An introduction to UML (II) • UML has been designed for a broad range of applications • Introduce only five diagrams • Use Case Diagrams • Class Diagrams • Interaction Diagrams • Statechart Diagrams • Activity Diagrams

7. Use Case Diagrams • A use case diagram • Describes the functional behavior of the system (as seen by the users) • Defines the boundaries of the system • Displays the relationships between actors and use cases • Actor • A user or another system that will interact with the system under development • Use Case • an external view of the system that represents some functionality of the system (an action the user might perform) • System Boundary • Defines the scope of the system

8. Use Case description • A use case is initiated by an actor • A use case should have: • Unique Name • Participating actors • Entry/Exit Condition • Flow of Events • Describe Exceptions • Describe Special Requirements (Constraints, Nonfunctional Requirements)

9. Graphical Representation Actor Use Case Login Boundary (optional) Library System

10. Use Case Relationships • Communication • Denote access to functionality • Only relationship between actors and use cases • Depicted by solid line between actor and use case Login

11. Include Relationship • Include (uses) • in an include relationship, a use case includes the functionality described in another use case as a part of its process • Adds extra behaviour into a base use case • Include reduces complexity • Depicted by a dashed open arrow originating from the base use case and labelled with the stereotype “<<include>>”

12. Passenger PurchaseMultiCard PurchaseSingleTicket Include Relationship (II) <<include>> CollectMoney <<include>>

13. Extend Relationship • Extend • Adds extra functionality • A use case extends another use case by adding events • Extend is also used to model exception cases, helps, errors, and other unexpected conditions • Depicted by a dashed arrow (similar to the include), originating from the child (extend) use case and labelled with the stereotype "<<extend>>"

14. Passenger PurchaseMultiCard PurchaseSingleTicket NoChange Cancel Extend Relationship (II) <<include>> <<extends>> <<extends>> CollectMoney <<include>>

15. Use Case diagram testing questions • Is our notation correct? • Are all actors identified? • Can the system described actually be built? • Are all the system's functional requirements reflected in the use cases? • Do the use cases define all the functionality within the scope of the system and nothing outside the scope? • Can we trace each use case back to its requirements?

16. Use Case diagram guidelines • Do have a clear idea of the system you intend to describe • Do ensure all use cases provide value to at least one actor • Do involve a “user” in the writing process. It is users’ requirements • Do not believe anyone telling you use case modelling is simple…It is not!!! • Do not include system design elements in the use cases • Do not get worked up about <<extend>>, <<include>>! • Do not forget actors representing other systems!

17. The name of the class The attributes of the class The operations (methods) of the class Class Diagram • Represent the structure of a system in terms of classes • A class is a collection of objects • Classes have a name, attributes, operations and relationships. • Class names start with uppercase letter

18. Developing a class diagram • Not right or wrong technique • One technique • Pick all the nouns (person, place, thing) and noun phrases from the requirements • Discard any inappropriate candidates • Redundant, event, operation, attribute, outside the scope of the system • Practice!

19. Associations • Associations depict relationships between classes • If classes correspond to nouns, associations correspond to verbs • Two types • Bidirectional • Unidirectional: an arrow indicates the direction Module Module Student Is taking Student Is taking Unidirectional Bidirectional

20. Aggregation • Special case of association • It indicates a whole-part (is part of) relationship • Denoted by a hollow diamond at the end of the whole • Composition is a special case of aggregation • The whole owns its part (if whole is destroyed the part is destroyed) Module Degree Window Menu

21. Inheritance (generalization) • Relationship between a general class (superclass) and a more specialised one (subclass) • It is an “is a” relationship • It enables us to describes all the attributes and operations that are common to a set of classes • Denoted by a hollow triangle at the end of the superclass Button Cancel Button OK Button

22. Multiplicity • Indicate the number of links that can legitimate originate from an instance of a class connected to the association end • Label the association end by a set of integers • Three common types • One-to-One • One-to-Many • Many-to-Many Police Station 1 1..* Police Officer

23. Class Diagram testing questions • Does each class define attributes, methods, relationships, and multiplicity? • Is each association well named? • Is each association’s and aggregation’s multiplicity correct? • Is each class named with a strong noun? • Have all redundant, irrelevant, or vague classes been removed from the diagram?

24. Class diagram guidelines • Use singular names because each class represents a generalised version of a singular object • Use simple class names (Student instead of …PersonWhoStudies) • Do not model actors in class diagrams • Use full names for attributes • Make sure you class diagram is consistent with the requirements • Try to avoid using only * for multiplicity (Is it 0..* or 1..*)

25. Quiz time!!! • Consider an ATM System. Which of the following is NOT an actor. • Customer • Central Bank computer • ATM processor • Thief

26. PurchaseMultiCard PurchaseSingleTicket Question 2-1 • Which of the following use case diagrams is NOT correct (if any) Passenger

27. Passenger PurchaseMultiCard PurchaseSingleTicket NoChange Cancel Question 2-2 <<include>> <<extends>> <<extends>> CollectMoney <<include>>

28. Passenger PurchaseTicket <<extends>> OutOfOrder TimeOut <<extends>> <<extends>> Cancel Question 2-3

29. Interaction diagrams • Used to describe communication between interacting objects (and actors) • Communication takes place through messages • Interaction diagrams should be used when you want to look at the behaviour of several objects within a single use case.

30. Interaction Diagrams (II) • Two types • Sequence: focus on the order that messages sent • Collaboration: focus on the relationship between the objects

31. Sequence diagrams • Sequence diagrams describe interactions among classes in terms of an exchange of messages over time • During requirements analysis • Refine use case descriptions, find additional objects • During design • Refine interfaces • Sequence diagrams are NOT useful for showing the behaviour within an object

32. TicketMachine Passenger selectZone() insertCoins() pickupChange() pickUpTicket() Sequence diagram (II) Object Actor lifeline message Active (activation)

33. Creation ChangeProcessor createTicket(selection) Ticket print() Destruction free() Creation & Destruction

34. Message Types [Taken from Smartdraw.com]

35. Sequence diagram testing questions • Does each object required for the interaction appear on the diagram? • Have all objects not required in the interaction been removed from the diagram? • Does each object’s lifeline begin and end at the proper time? • Is each object’s activation described properly? • If the object’s lifetime terminates, is it indicated with an X? • Is each use case represented by at least one sequence diagram? • Does each actor appear on at least one sequence diagram?

36. Sequence diagram guidelines • Start the message flow of a sequence diagram in the top-left corner • Have in mind that a message that appears lower in the diagram is sent after one that appears above it • Arrange your actors, classes across the top of the diagram in such a way as to depict message flow from left to right • Make sure the actors that appear on the sequence diagrams have the same name as on the use case diagrams

37. Sequence Diagram guidelines (II) • Have in mind that an actor CAN have the same name as a class • Include a description of the logic you are modelling • Model proactive (activate the sequence) actors, classes on the left-hand side of the diagram • Model reactive (system initiates interaction with) actors on the right-hand side of the diagram

38. Collaboration diagrams • Depict the same information as sequence diagrams • It shows the objects and their association with other objects in the system apart from how they interact with each other. • Represent the sequence of messages by numbering the interactions • More compact diagram • More difficult to follow

39. Collaboration Diagram Example

40. Statechart diagrams • Useful for describing the behaviour of individual objects over the full set of use cases that affect those objects • Statechart diagrams describe • All of the states that an object can have, • The events under which an object changes state (transitions), • The conditions that must be fulfilled before the transition will occur (guards), • The activities undertaken during the life of an object (actions).

41. Elements of Statecharts • Initial state • The object’s initial state • States • A condition during the life of an object in which it satisfies some condition, performs some action, or waits for some event • Transitions • The change of state within an object • Events • An occurrence (signal from outside the system, invocation from inside the system, passage of designated period of time) that may trigger a state transition. • Action • One or more actions taken by an object in response to a state change • Guard • A Boolean expression which, if true, enables an event to cause a transition • Final state • The object’s final state

42. Active Entry/play dial tone An example: A telephone class Initial State Event Guard Transition Action Off hook [signal OK] /play dial tone Idle Active On hook Off Final State State

43. Statechart diagram testing questions • Does each state-transition diagram have one and only one initial state? • Does each state have at least one exit transition? • If multiple guards exist for a single event, are the guards mutually exclusive? • Is each state and transition clearly named? • Are all of the required states, events, guards, transitions, and actions shown on the diagram?

44. Statechart diagrams guidelines • Make sure that each statechart diagram refers to only one class! • You do not have to develop a statechart diagram for every class (unless you told so) • All statechart diagrams should have an initial state (the state the class is when it is created)

45. Activity Diagrams • Activity diagrams describe the workflow behaviour of a system • An Activity diagram is a dynamic diagram that shows the activity and the event that causes the object to be in the particular state • However, activity diagrams should not take the place of interaction diagrams and state chart diagrams. Activity diagrams do not give detail about how objects behave or how objects collaborate • A State diagram shows the different states an object is in during the lifecycle of its existence in the system, and the transitions in the states of the objects. These transitions depict the activities causing these transitions, shown by arrows • An Activity diagram talks more about these transitions and activities causing the changes in the object states

46. Activity Diagram Elements • Initial Activity • The initial activity of the workflow • Activity • A state of doing something. • Transition • Progression to the next activity • Synchronisation bar (fork or join) • Describes concurrent activities • Decision diamond • Indicates decisions and the available options • Final Activity • The final activity of the workflow

47. Get Dressed Read Newspaper Have breakfast [Not In time for bus] Take bus [In time for bus] Take cab Attend Lecture Example of activity diagram Synch. Bar (fork) Transition Activity Initial Activity Synch. Bar (join) Decision diamond Decision option Final Activity

48. Swim lanes • Enable developers to indicate which actor performs which activity • The diagram is partitioned in such a way that we can indicate who/what is performing the activity • Partitions called “swim lanes” • Useful because they provide more information • The diagram becomes larger

49. Example of swim lanes [Taken from prestwood.com]

50. Quiz time • Which of the following diagrams you would use to show the behaviour of an object? • Sequence • Collaboration • Statechart • Activity