Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 Advance Information Systems Development (SD3043) Lecture 2: UML Overview Dr. Haris Mouratidis 3 th October 2006.

Similar presentations


Presentation on theme: "1 Advance Information Systems Development (SD3043) Lecture 2: UML Overview Dr. Haris Mouratidis 3 th October 2006."— Presentation transcript:

1 1 Advance Information Systems Development (SD3043) Lecture 2: UML Overview Dr. Haris Mouratidis 3 th October 2006

2 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 3 Learning Objectives  After this lecture you should be able to:  Understand UML concepts  Understand UML notations  Use UML to model information systems

4 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 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 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 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 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 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 10 Graphical Representation Login Actor Use Case Boundary (optional) Library System

11 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 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 13 Include Relationship (II) Passenger PurchaseMultiCardPurchaseSingleTicket CollectMoney >

14 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 " >"

15 15 Extend Relationship (II) Passenger PurchaseMultiCardPurchaseSingleTicket CollectMoney > Cancel > NoChange >

16 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 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 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 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 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 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 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 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 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 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 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 27 Question 2-1  Which of the following use case diagrams is NOT correct (if any) Passenger PurchaseMultiCardPurchaseSingleTicket

28 28 Question 2-2 Passenger PurchaseMultiCardPurchaseSingleTicket CollectMoney > Cancel > NoChange >

29 29 Question 2-3 Passenger PurchaseTicket OutOfOrder > Cancel > TimeOut >

30 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 31 Interaction Diagrams (II)  Two types  Sequence: focus on the order that messages sent  Collaboration: focus on the relationship between the objects

32 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 33 Sequence diagram (II) selectZone() pickupChange() pickUpTicket() insertCoins() Passenger TicketMachine Actor Object lifeline message Active (activation)

34 34 Creation & Destruction ChangeProcessor Ticket createTicket(selection) free() Creation Destruction print()

35 35 Message Types [Taken from Smartdraw.com]

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

40 40 Collaboration Diagram Example

41 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 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 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 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 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 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 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 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 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 50 Example of swim lanes [Taken from prestwood.com]

51 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 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 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 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 55 Announcements  Problem with WebCT you can find info on D3043 D3043 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


Download ppt "1 Advance Information Systems Development (SD3043) Lecture 2: UML Overview Dr. Haris Mouratidis 3 th October 2006."

Similar presentations


Ads by Google