Presentation on theme: "1 Advance Information Systems Development (SD3043) Lecture 2: UML Overview Dr. Haris Mouratidis 3 th October 2006."— Presentation transcript:
1 Advance Information Systems Development (SD3043) Lecture 2: UML Overview Dr. Haris Mouratidis email@example.com 3 th October 2006
2 Last Week’s Lecture Introduction to the Module Description of the Module Teaching & Assessment methods Module Content Overview of Software Engineering Definitions of Software Engineering Concepts Development Activities
3 Learning Objectives After this lecture you should be able to: Understand UML concepts Understand UML notations Use UML to model information systems
4 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
5 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
6 An introduction to UML Object Modeling Technique (OMT)Booch Method Object Oriented Software Engineering (OOSE) Coad and Yourdon Martin and Odell UML Shlaer and Mellor Result of the unification Has influenced THE GOAL: Provide a standard notation that can be used by all object-oriented methods to model Object Oriented Systems
7 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
8 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
9 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)
10 Graphical Representation Login Actor Use Case Boundary (optional) Library System
11 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
12 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 “ >”
13 Include Relationship (II) Passenger PurchaseMultiCardPurchaseSingleTicket CollectMoney >
14 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 " >"
16 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?
17 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 >, >! Do not forget actors representing other systems!
18 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 The name of the class The attributes of the class The operations (methods) of the class
19 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!
20 Associations Associations depict relationships between classes If classes correspond to nouns, associations correspond to verbs Two types Bidirectional Unidirectional: an arrow indicates the direction Student Module Is taking Student Module Is taking Bidirectional Unidirectional
21 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) Degree Module Window Menu
22 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 OK Button Cancel Button
23 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 Police Officer 1 1..*
24 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?
25 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..*)
26 Quiz time!!! Consider an ATM System. Which of the following is NOT an actor. A.Customer B.Central Bank computer C.ATM processor D.Thief
27 Question 2-1 Which of the following use case diagrams is NOT correct (if any) Passenger PurchaseMultiCardPurchaseSingleTicket
30 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.
31 Interaction Diagrams (II) Two types Sequence: focus on the order that messages sent Collaboration: focus on the relationship between the objects
32 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
33 Sequence diagram (II) selectZone() pickupChange() pickUpTicket() insertCoins() Passenger TicketMachine Actor Object lifeline message Active (activation)
36 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?
37 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
38 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
39 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
41 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).
42 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
43 An example: A telephone class IdleActive Initial State State Transition /play dial tone Event Guard Action On hook Off Final State Off hook [signal OK] Active Entry/play dial tone
44 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?
45 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)
46 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
47 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
48 Example of activity diagram Take busTake cab Attend Lecture Get Dressed Read Newspaper Have breakfast [In time for bus] [Not In time for bus] Activity Synch. Bar (fork) Synch. Bar (join) Decision diamond Decision option Initial Activity Final Activity Transition
49 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
50 Example of swim lanes [Taken from prestwood.com]
51 Quiz time Which of the following diagrams you would use to show the behaviour of an object? A.Sequence B.Collaboration C.Statechart D.Activity
52 Question 2 Which of the following diagrams you would use to describe communication between interacting objects along with their relationships? A.Sequence B.Collaboration C.Statechart D.Activity
53 Question 3 Receive Payment Close Order Receive Order Send Invoice Fill Order Which of the following applies to the diagram below A) The diagram is correct B) The diagram is not correct
54 Conclusion Notation An introduction to the Unified Modeling Language (UML) An overview of UML Reading list: Chapter 2 (essential), any book about UML Next week: Requirements Elicitation and Analysis
55 Announcements Problem with WebCT you can find info on http://homepages.uel.ac.uk/H.Mouratidis/S D3043 http://homepages.uel.ac.uk/H.Mouratidis/S D3043 http://homepages.uel.ac.uk/H.Mouratidis/S D3043 If you haven’t got a handbook get one from Godfried or download one from the above link Pick up your assignment Practicals only some weeks