uml diagrams by: muhammad aamir salem. unified modeling language unified modeling language (uml) is...

UML Diagrams

By: Muhammad Aamir Salem

Unified Modeling Language Unified Modeling Language (UML) is a

standardized general-purpose modeling language in the field of software engineering. The standard is managed, and was created by, the Object Management Group.

UML includes a set of graphic notation techniques to create visual models of software-intensive systems.

3

Using Use Case Diagrams Use case diagrams are used to

visualize, specify, construct, and document the (intended) behavior of the system, during requirements capture and analysis.

Provide a way for developers, domain experts and end-users to Communicate.

Serve as basis for testing. Use case diagrams contain use cases,

actors, and their relationships.

מידע מערכות ניתוח 4

Use Case

Use cases specify desired behavior. A use case is a description of a set of

sequences of actions, including variants, a system performs to yield an observable result of value to an actor.

Each sequence represent an interaction of actors with the system.

name

5

Specifying the Behavior of a Use Case

Describing the flow of events within the use case.

Can be done in natural language, formal language or pseudo-code.

Includes: how and when the use case starts and ends; when the use case interacts with actors and what objects are exchanged; the basic flow and alternative flows of the behavior.

6

Actors

An actor represents a set of roles that users of use case play when interacting with these use cases.

Actors can be human or automated systems.

Actors are entities which require help from the system to perform their task or are needed to execute the system’s functions.

Actors are not part of the system.

name

7

Use Cases and Actors From the perspective of a given

actor, a use case does something that is of value to the actor, such as calculate a result or change the state of an object.

The Actors define the environments in which the system lives

8

Example of Use Case Diagram

student

registration

updatinggrades

outputgenerating

faculty

9

Relationships between Use Cases1. Generalization - use cases that are

specialized versions of other use cases.

2. Include - use cases that are included as parts of other use cases. Enable to factor common behavior.

3. Extend - use cases that extend the behavior of other core use cases. Enable to factor variants.

10

1. Generalization The child use case inherits the

behavior and meaning of theparent use case.

The child may add to or override the behavior of its parent.

parent

child

11

registration

graduateregistration

non-graduateregistration

More about Generalization

12

2. Include

The base use case explicitly incorporates the behavior of another use case at a location specified in the base.

The included use case never stands alone. It only occurs as a part of some larger base that includes it.

base included<<include>>

13

More about Include Enables to avoid describing the same

flow of events several times by putting the common behavior in a use case of its own.

updatinggrades

outputgenerating

verifyingstudent id

<<include>>

<<include>>

14

3. Extend

The base use case implicitly incorporates the behavior of another use case at certain points called extension points.

The base use case may stand alone, but under certain conditions its behavior may be extended by the behavior of another use case.

base extending<<extend>>

15

More about Extend Enables to model optional behavior

or branching under conditions.

Exam copy

request

Exam-grade

appeal

<<extend>>

16

Relationships between Actors Generalization.

student

non-graduatestudent

graduatestudent

17

Relationships between Use Cases and Actors

Actors may be connected to use cases by associations, indicating that the actor and the use case communicate with one another using messages.

updatinggrades

faculty

18

Example

placephone call

cellularnetwork

user

receivephone call

placeconference

call

receiveadditional

call

usescheduler

<<extend>>

<<extend>>

Cellular Telephone

19

Update Items

Bookshop Worker

Ship Order

Bookshop Manager

Update Staff Details

Register Details

Customer1

System Login

Update Customer Details

Add Items to ShoppingCart

Handle Order

<<include>>

<<extend>>

<<include>>

Make Order

<<include>>

A More Complicate Example

20

Each use case may include all or part of the following:

Title or Reference Name - meaningful name of the UC Author/Date - the author and creation date Modification/Date - last modification and its date Purpose - specifies the goal to be achieved Overview - short description of the

processes Cross References - requirements references Actors - agents participating Pre Conditions - must be true to allow execution Post Conditions - will be set when completes

normally Normal flow of events - regular flow of activities Alternative flow of events - other flow of activities Exceptional flow of events - unusual situations Implementation issues - foreseen implementation problems

Use Case Description

21

Example- Money Withdraw Use Case: Withdraw Money Author: ZB Date: 1-OCT-2004 Purpose: To withdraw some cash from user’s bank account Overview: The use case starts when the customer inserts

his credit card into the system. The system requests the user PIN. The system validates the PIN. If the validation succeeded, the customer can choose the withdraw operation else alternative 1 – validation failure is executed. The customer enters the amount of cash to withdraw. The system checks the amount of cash in the user account, its credit limit. If the withdraw amount in the range between the current amount + credit limit the system dispense the cash and prints a withdraw receipt, else alternative 2 – amount exceeded is executed.

Cross References: R1.1, R1.2, R7

22

Example- Money Withdraw (cont.) Actors: Customer Pre Condition:

The ATM must be in a state ready to accept transactions The ATM must have at least some cash on hand that it can

dispense The ATM must have enough paper to print a receipt for at

least one transaction Post Condition:

The current amount of cash in the user account is the amount before the withdraw minus the withdraw amount

A receipt was printed on the withdraw amount The withdraw transaction was audit in the System log file

23

Example- Money Withdraw (cont.)

Typical Course of events:

Actor ActionsActor Actions System ActionsSystem Actions

1. Begins when a Customer arrives at ATM1. Begins when a Customer arrives at ATM

2. Customer inserts a Credit card into ATM2. Customer inserts a Credit card into ATM 3. System verifies the customer ID and status3. System verifies the customer ID and status

5. Customer chooses “Withdraw” operation5. Customer chooses “Withdraw” operation 4. System asks for an operation type4. System asks for an operation type

7. Customer enters the cash amount7. Customer enters the cash amount 6. System asks for the withdraw amount6. System asks for the withdraw amount

8. System checks if withdraw amount is legal8. System checks if withdraw amount is legal

9. System dispenses the cash9. System dispenses the cash

10. System deduces the withdraw amount from 10. System deduces the withdraw amount from accountaccount

11. System prints a receipt11. System prints a receipt

13. Customer takes the cash and the receipt13. Customer takes the cash and the receipt 12. System ejects the cash card12. System ejects the cash card

24

Example- Money Withdraw (cont.) Alternative flow of events:

Step 3: Customer authorization failed. Display an error message, cancel the transaction and eject the card.

Step 8: Customer has insufficient funds in its account. Display an error message, and go to step 6.

Step 8: Customer exceeds its legal amount. Display an error message, and go to step 6.

Exceptional flow of events: Power failure in the process of the transaction

before step 9, cancel the transaction and eject the card

25

Example- Money Withdraw (cont.) One method to identify use cases is actor-based:

- Identify the actors related to a system or organization.- For each actor, identify the processes they initiate or participate in.

A second method to identify use cases is event-based: - Identify the external events that a system must respond to. - Relate the events to actors and use cases. The following questions may be used to help identify the use

cases for a system:- What are tasks of each actor ?- Will any actor create, store, change, remove, or read information in the

system ?- What use cases will create, store, change, remove, or read this

information ?- Will any actor need to inform the system about sudden, external

changes ? - Does any actor need to be informed about certain occurrences in the

system ?- Can all functional requirements be performed by the use cases ?

26

Moving on The “things” that “live” inside the

system are responsible for carrying out the behavior the actors on the outside expect the system to provide.

To implement a use case, we create a society of classes that work together to carry out the behavior of the use case.

Class Diagrams The main building block in object oriented

modeling They are used both for general conceptual

modeling of the systematics of the application, and for detailed modeling translating the models into programming code

The classes in a diagram represent both the main objects and/or interactions in the application and the objects to be programmed

In the diagram these classes are represented with boxes which contain three parts

Class Diagrams A class with three sections.

The upper part holds the name of the class The middle part contains the attributes of the class The bottom part gives the methods or operations the class

can take or undertake

Class Diagrams In the system design of a system, a number of classes

are identified and grouped together in a class diagram which helps to determine the static relations between those objects

With detailed modeling, the classes of the conceptual design are often split in a number of subclasses

In order to further describe the behavior of systems, these diagrams can be complemented by state diagram or UML state machine

Also instead of class diagrams, Object role modeling can be used if you just want to model the classes and their relationships

The class icon Defines

Persistent system state

System behavior The class icon has

Name Attributes Operations

It’s a rectangle divided into three compartments.

Steps followed Draw class symbol in the editor

and name it List the class attributes List the class operations/methods Make the links and associations Give notations

Construct Description Syntax

class a description of a set of objects that share the same attributes, operations, methods, relationships and semantics.

interface a named set of operations that characterize the behavior of an element.

component a modular, replaceable and significant part of a system that packages implementation and exposes a set of interfaces.

node a run-time physical object that represents a computational resource.

«interface»

Structural Modeling: Core Elements

Reference: OMG tutorial on UML by Cris Kobryn

Structural Modeling: Core Elements (cont’d)


constraint¹ a semantic condition or restriction.

{constra in t}

¹ An extension mechanism useful for specifying structural elements.



association a relationship between two or more classifiers that involves connections among their instances.

aggregation A special form of association that specifies a whole-part relationship between the aggregate (whole) and the component part.

generalization a taxonomic relationship between a more general and a more specific element.

dependency a relationship between two modeling elements, in which a change to one modeling element (the independent element) will affect the other modeling element (the dependent element).

Structural Modeling: Core Relationships



realization a relationship between a specification and its implementation.

Structural Modeling: Core Relationships (cont’d)


Interfaces: Longhand Notation

Fig. 3-29, UML Notation Guide

+create()+login(UserNam e, Passwd)+find(StoreId)+getPOStotals(POSid)+updateStoreTotals(Id,Sales)+get(Item )

-storeId: Integer-POSlist: List

Store

POSterm inal

POSterm inalHom e

<<use>>

StoreHom e

POSterm inal

+getPOStotals(POSid)+updateStoreTotals(Id,Sales)+get(Item )

<<interface>>Store


Associations An Association represents

a family of links Binary associations (with

two ends) are normally represented as a line, with each end connected to a class box

Higher order associations can be drawn with more than two ends; in such cases, the ends are connected to a central diamond



Person

Manages

JobCompany

boss

worker

employeeemployer

0..1

Job

Account

Person

Corporation

{Xor}

salary

Associations An association can be

named, and the ends of an association can be adorned with role names, ownership indicators, multiplicity, visibility, and other properties

There are five different types of association; bi-directional and uni-directional associations are the most common ones



Person

Manages

JobCompany

boss

worker

employeeemployer

0..1

Job

Account

Person

Corporation

{Xor}

salary

Aggregations

Aggregation is a variant of the "has a" or association relationship; aggregation is more specific than association

It is an association that represents a part-whole or part-of relationship. As a type of association, an aggregation can be named and have the same adornments that an association can

However, an aggregation may not involve more than two classes

Aggregations (Weak type)

Aggregation can occur when a class is a collection or container of other classes, but where the contained classes do not have a strong life cycle dependency on the container—essentially, if the container is destroyed, its contents are not

In UML, it is graphically represented as a hollow diamond shape on the containing class end of the tree of lines that connect contained class(es) to the containing class

Example: Football team players If one gone, other may survive

Composition (Strong type) Composition is a stronger variant of the "owns

a" or association relationship; composition is more specific than aggregation

It is represented with a solid diamond shape Has a strong life cycle dependency between

instances of the container class and instances of the contained class(es): If the container is destroyed, normally every instance that it contains is destroyed as well

Note that a part can (where allowed) be removed from a composite before the composite is deleted, and thus not be deleted as part of the composite

The UML graphical representation of a composition relationship is a filled diamond shape on the containing class end of the tree of lines that connect contained class(es) to the containing class

Example : House with rooms

Fig. 3-45, UML Notation GuideReference: OMG tutorial on UML by Cris Kobryn

Window

scrollbar [2]: Slidertitle: Headerbody: Panel

Window

scrollbar title body

Header Panel

2 1 1

Slider

111

Generalization Indicates that one of the two

related classes (the subtype) is considered to be a specialized form of the other (the super type) and supertype is considered as 'Generalization' of subtype

In practice, this means that any instance of the subtype is also an instance of the supertype

An exemplary tree of generalizations of this form is found in binomial nomenclature: human beings are a subtype of simian, which are a subtype of mammal, and so on. The relationship is most easily understood by the phrase 'A is a B' (a human is a mammal, a mammal is an animal).

Fig. 3-47, UML Notation Guide Reference: OMG tutorial on UML by Cris Kobryn

Shape

SplineEllipsePolygon

Shape


Shared Target Style

Separate Target Style

. . .

. . .

Generalization The UML graphical

representation of a Generalization is a hollow triangle shape on the supertype end of the line (or tree of lines) that connects it to one or more subtypes.

The generalization relationship is also known as the inheritance or "is a" relationship.

The supertype in the generalization relationship is also known as the "parent", superclass, base class, or base type.

The subtype in the specialization relationship is also known as the "child", subclass, derived class, derived type, inheriting class, or inheriting type.


Shape


Shape


Shared Target Style


. . .

. . .

Generalization Note that this relationship

bears no resemblance to the biological parent/child relationship: the use of these terms is extremely common, but can be misleading

Generalization-Specialization relationship

A is a type of B E. g. "an oak is a type of tree",

"an automobile is a type of vehicle"

Generalization can only be shown on class diagrams and on Use case diagrams.


Shape


Shape


Shared Target Style


. . .

. . .

Dependencies Dependency is a

weaker form of relationship which indicates that one class depends on another because it uses it at some point of time

It exists if a class is a parameter variable or local variable of a method of another classFig. 3-50, UML Notation Guide


«friend»ClassA ClassB

ClassC

«instantiate»

«call»

ClassD

operationZ()«friend»

ClassD ClassE

«refine»ClassC combines

two logical classes

UML Class Diagram Examples

Reference: www.smartdraw.com

70

UML sequence diagrams sequence diagram: an "interaction

diagram" that models a single scenario executing in the system perhaps 2nd most used UML diagram

(behind class diagram) relation of UML diagrams to other

exercises: CRC cards -> class diagram use cases -> sequence diagrams

71

Key parts of a sequence diag. participant: an object or entity that

acts in the sequence diagram sequence diagram starts with an

unattached "found message" arrow message: communication between

participant objects the axes in a sequence diagram:

horizontal: which object/participant is acting

vertical: time (down -> forward in time)

72

Sequence diag. from use case

73

Representing objects squares with object type,

optionally preceded by object name and colon write object's name if it clarifies the

diagram object's "life line" represented by

dashed vert. line

74

message (method call) indicated by horizontal arrow to other object write message name and arguments above

arrow

dashed arrow back indicates return different arrowheads for normal / concurrent

(asynchronous) methods

Messages between objects

75

Lifetime of objects creation: arrow with

'new' written above it notice that an object

created after the start of the scenario appears lower than the others

deletion: an X at bottom of object's lifeline Java doesn't explicitly

delete objects; they fall out of scope and are garbage-collected

76

Indicating method calls activation: thick box over object's life line; drawn

when object's method is on the stack either that object is running its code, or it is on the

stack waiting for another object's method to finish nest to indicate recursion

Activation

Nesting

77

Indicating selection and loops frame: box around part of a sequence

diagram to indicate selection or loop if -> (opt) [condition] if/else -> (alt) [condition], separated by

horiz. dashed line loop -> (loop) [condition or items to loop

over][balance <> 0]opt [balance < 100.00]

[balance >= 100.00]

alt

[balance < 0]loop

78

linking sequence diagrams if one sequence diagram is too large or

refers to another diagram, indicate it with either: an unfinished arrow and comment a "ref" frame that names the other diagram when would this occur in our system?

Verify customer credit

refCustomer Info

Approved?

79

Example sequence diagramsd Example

loop

StoreFront Cart Inventory

AddItemReserveItem

PlaceItemInOrder

Checkout

ProcessOrderConfirmOrder

80

(De)centralized system control What can you say about the control flow

of each of the following systems? centralized? distributed?

81

Flawed sequence diagram 1 What's wrong with this sequence

diagram? (Look at the UML syntax and the viability of the scenario.)

82


diagram?

83


diagram?:Computer :PrintServer :Printer :Queue

print(file)[if printer free] print(file)

[else] enqueue(file)

84

Why not just code it? Sequence diagrams can be

somewhat close to the code level. So why not just code up that algorithm rather than drawing it as a sequence diagram?

a good sequence diagram is still a bit above the level of the real code (not EVERY line of code is drawn on diagram)

sequence diagrams are language-agnostic (can be implemented in many different languages

non-coders can do sequence diagrams easier to do sequence diagrams as a team can see many objects/classes at a time on same

page (visual bandwidth)

85

Sequence diagram exercise 1 Let's do a sequence diagram for the following casual

use case, Start New Poker Round : The scenario begins when the player chooses to start a new round in the UI. The UI asks whether any new players want to join the round; if so, the new players are added using the UI.All players' hands are emptied into the deck, which is then shuffled. The player left of the dealer supplies an ante bet of the proper amount. Next each player is dealt a hand of two cards from the deck in a round-robin fashion; one card to each player, then the second card.If the player left of the dealer doesn't have enough money to ante, he/she is removed from the game, and the next player supplies the ante. If that player also cannot afford the ante, this cycle continues until such a player is found or all players are removed.

86

Sequence diagram exercise 2 Let's do a sequence diagram for the following casual

use case, Add Calendar Appointment : The scenario begins when the user chooses to add a new appointment in the UI. The UI notices which part of the calendar is active and pops up an Add Appointment window for that date and time.

The user enters the necessary information about the appointment's name, location, start and end times. The UI will prevent the user from entering an appointment that has invalid information, such as an empty name or negative duration. The calendar records the new appointment in the user's list of appointments. Any reminder selected by the user is added to the list of reminders.

If the user already has an appointment at that time, the user is shown a warning message and asked to choose an available time or replace the previous appointment. If the user enters an appointment with the same name and duration as an existing group meeting, the calendar asks the user whether he/she intended to join that group meeting instead. If so, the user is added to that group meeting's list of participants.

uml diagrams by: muhammad aamir salem. unified modeling language unified modeling language (uml) is...

Documents