Overview

UML Introduction and Evolution UML Diagrams Class Diagram notations  Class notation
 Attributes  Operations  Class relations

08/18/05

UML

UML Introduction
What Is the Unified Modeling Language (UML)?

The Unified Modeling Language (UML) is the standard visual modeling language used for modeling businesses, software applications, and system architectures.

08/18/05

UML

UML Introduction
Why do we need UML as a standard?
UML models allows us communicate unambiguously Understood around the world UML is flexible enough to support new ways of modeling as technologies and businesses change.

Is the UML Proprietary?

The UML is not proprietary It is an open modeling standard designed and supported by software companies, consultants, other corporations, and governments who need and rely on this standard.
08/18/05 UML 3

UML Introduction
Is the UML Only for Object-Oriented Development? UML is used for modeling businesses, data, organizations, theoretical political systems, legal contracts, biological systems, languages, hardware, non-object-oriented application modeling such as COBOL, and many other modeling tasks. Why should we have to use UML for Object-Oriented Development? In an OO system, generally several components are tied together using what are called interfaces. To understand how those different components interact, it is quite useful to build a model UML.
08/18/05 UML 4

UML Evolution
Where Did the UML Come From?

08/18/05

UML

UML Introduction
Is the UML a Methodology?
The UML is a language with rules for syntax and usage. A methodology is much more than a language with procedures (i.e., processes) or practices. Object-oriented analysis and design (OOAD) is a process, governed by specific practices.

08/18/05

UML

UML Introduction
Three amigos and their Methodologies?
James Rumbaughs Objectory Method (OMT) had strong business modeling capability. Grady Boochs Booch method had strengths in design and implementation Ivar Jacobsons Object Oriented Software Engineering (OOSE) is based around the use-case concept

08/18/05

UML

UML Introduction
What is Object Management Group? How UML was standardized?
It is a standards body that brought us CORBA Interface Definition Language (IDL) and CORBA Internet Inter-ORB Protocol (IIOP) In response to overwhelming need, the OMG published a Request for Proposal (RFP). Rational Software Corporation created the UML Partners Consortium (software companies, consultants, other corporations, and governments who need and rely on this standard) and published UML 1.0.
08/18/05 UML 8

UML Diagrams
What types of diagrams Are in the UML?
Structure Diagrams - Structure diagrams depict the static structure of the elements in your system. Class diagrams, Component diagrams, Object diagrams, Deployment diagrams, Composite structure, Package diagrams. Behavior diagrams - Depict the dynamic behavior of the elements in your system. Activity diagrams, Use case diagrams, Statechart diagrams, Collaboration diagrams ( in UML2.0 it is communication diagram), Sequence diagrams, Timing diagrams (UML 2.0), Interaction overview diagrams (UML 2.0)

08/18/05

UML

Class Diagram
Class diagram describes the static view of a system in terms of classes and relationships among the classes. Class diagram can be used as foundation for other diagrams showing other aspects of the system

08/18/05

UML

10

A Class in UML
A Class notation has three compartments Name - mandatory Attributes - optional Operations - optional

08/18/05

UML

11

Modeling Visibility

Visibility Private Protected Public Package

Symbol

Meaning Only the class itself can access these attributes. Any child class of this class can access these attributes. Any class can access these attributes. Any class in the same package can access these attributes.

# + ~

08/18/05

UML

12

Modeling Multiplicity
Multiplicity applies to both attributes and associations

Type
Range of values Specific value Range without limit

Symbol
[0..5] [5] [0..*] or [*] [1..*]

Example
-physicianAddress[1..2]:Address -knownPlanets[9]:Planet

-contracts[1..*]:Contract

08/18/05

UML

13

Modeling Multiplicity and ordering

The syntax for ordering and uniqueness is as follow:
[ { <order_designator> [, <uniqueness_designator>] } ] <order_designator> ::= ordered | unordered <uniqueness_designator> ::= unique | nonunique

isOrdered
Unordered Ordered Unordered

isUnique
Unique Unique Nonunique Nonunique

Collection Type Set OrderedSet Bag Sequence

Ordered

08/18/05

UML

14

Modeling Attribute Compartment

The syntax for attribute definition is as follow:
[visibility][/] name [:type] [multiplicity] [=default] [{property-string}]

Modeling derived attribute: using / Employee

-dateOfBirth:Date -/age:int

08/18/05

UML

15

Modeling Attribute Compartment

[visibility][/] name [:type] [multiplicity] [=default] [{property-string}]

The attribute name is required. The name should be unique within the class. It should be as descriptive as possible. Employee
-dateOfBirth:Date -/age:int -employeeId:int -address:Address

08/18/05

UML

16

Modeling Attribute Compartment

[visibility][/] name [:type] [multiplicity] [=default] [{property-string}]

An attribute type identifies a classifier as given below:

A reference to a UML primitive Data Type (Integer, UnlimitedInteger, or String) An enumeration such as Boolean A reference to a language-specific type such as float, long in java A reference to another class in you system

Employee
-dateOfBirth:Date -/age:int -sex:Boolean -id:int -address:Address
08/18/05 UML 17

Modeling Attribute Compartment

[visibility][/] name [:type] [multiplicity] [=default] [{property-string}] To protect the integrity of the system from being corrupted by missing or invalid values. We can avoid the programming language assigning default values to primitive type variables.

Event
-name:String = no default, required -start_date[1]:Calendar=no default, required -/end_date[1]:Calendar=start_date+duration_in_days -duration_in_days :int = 1 -nbr_of_shows_allowed[1]:int = 1 -nbr_of_shows_scheduled[1]:int = 1

08/18/05

UML

18

Modeling Attribute Compartment

[visibility][/] name [:type] [multiplicity] [=default] [{property-string}] Property strings can be used to include any thing we want to include in the definition but for which there is no designated location. Most common use is to express the rules required to guarantee the integrity of the attribute using Object Constraint Language (OCL).

Event
-name:String = no default {Required, 1..30 chars, spaces and punctuation allowed} -start_date[1]:Calendar=no default {Required, >today and valid day of operation} -/end_date[1]:Calendar=start_date+duration_in_days { = start_date+duration_in_days} -duration_in_days :int = 1 {>0} -nbr_of_shows_allowed[1]:int = 1{>0} -nbr_of_shows_scheduled[1]:int = 1 {>=0 and <= nbr_of_shows_allowed}

08/18/05

UML

19

Modeling Attributes Compartment

Class-level attribute
A class-level attribute is also referred to as static attribute in some languages. UML 1.4 stated that a static or class scoped attribute is designated by underlining the entire definition text string. UML 2.0 does not exactly say that a static attribute is underlined. However it does define all attributes as having a Boolean attribute called isStatic.

Ticket
-next_ticket_nbr[1]:int=1 -ticket_nbs[1]:int = assigned at creation

08/18/05

UML

20

Modeling Operations Compartment

The syntax for operation notation is as follow:
[visibility] name ( [parameter-list]) : [return-result] [{properties}] Visibility private, package, public or protected Name does not have to be unique within a class Signature of the operation name, parameter-list and return-result Signature of the operation is unique

08/18/05

UML

21

Modeling Operations Compartment

[visibility] name ( [parameter-list]) : [return-result] [{properties}] Parameter list is an ordered list of attributes that together define the input to an operation. Each parameter is defined as name : datatype Multiple parameters are separated with commas.

Event
+Event(name:String, start_date:Calendar, duration:int) +getName() +getStartDate() +getDuration() +setDuration(new_duration:int) +cancel() +reschedule(new_start_date:Calendar)

08/18/05

UML

22

Modeling Operations Compartment

[visibility] name ( [parameter-list]) : [return-result] [{properties}] The return-result is the output of the operation. The return-result may be any primitive type or object reference.

Event
+Event(name:String, start_date:Calendar, duration:int) +getName() : String +getStartDate() : Calendar +getDuration() : int +setDuration(new_duration:int) +cancel() : Boolean +reschedule(new_start_date:Calendar)

08/18/05

UML

23

Modeling Operations Compartment

[visibility] name ( [parameter-list]) : [return-result] [{properties}] The properties element allows you to add any additional information about the operation that does not fit into one of the other predefined element. We can use it as description of the implementation for the operation as shown below: setDuration(new_duration:int):void {the new duration may not cause overlap with another scheduled event}

08/18/05

UML

24

Modeling Operations Compartment

Class-level operation
A class-level operation is also referred to as static operation in some languages. UML 1.4 stated that a static or class scoped operation is designated by underlining the entire definition text string. UML 2.0 does not exactly say that a static operation is underlined. However it does define all operations as having a Boolean attribute called isStatic.

Ticket
-next_ticket_nbr[1]:int=1 -ticket_nbs[1]:int = assigned at creation +getNextTicketNbr():int

08/18/05

UML

25

Modeling Name Compartment

Stereotype
The Stereotypes in UML allows us to further define a class. For example, when modeling business application it is common to draw a distinction between classes that describe entity elements and control elements. Entity elements part of domain like Event, Show etc.. Control elements present as part of software solution like Scheduler
<<entity>> Event <<control>> Scheduler <<utility>> Math

+round(value:float, precision:int):float +squareroot(square:float):float

08/18/05

UML

26

Modeling Abstract Classes

Abstract Classes and operations
Abstract classes are the classes that cannot be used to create objects.

ProviderStatusManager

ProviderStatusManager #processProviderStatus()

08/18/05

UML

27

Modeling Interfaces
Interface notation
An interface is a declaration rather than an actual class. An implementation is provided by the class that realizes or implements the interface.

<<interface>> Collection +add(o:Object):Boolean .

08/18/05

UML

28

Modeling Class Relationships

UML relationships come in three different types:
Association is a connection between classes which means that it is also a connection between objects of those classes. Ex:Author writes book. Generalization is a relationship between a more general and a more specific element. Ex:Editorial Review is a kind of review Dependency is a relationship between elements, one independent and one dependent. The dependent element is called the client or source the independent element is called the supplier or target

08/18/05

UML

29

Modeling Class Relationships

A simple association

Author

Uses

Computer

1..* Person

Uses OwnedBy

0..* Car

08/18/05

UML

30

Modeling Class Relationships

An aggregation association
Navy Contains Warships

A shared aggregation association

* Team * members Person

08/18/05

UML

31

Modeling Class Relationships

A composition aggregation association

GeneralLedger

GLAccount

This relationship specifies that a GLAccount in a composition relationship with a particular GeneralLedger is destroyed when that GeneralLedger is destroyed.

08/18/05

UML

32

Modeling Class Relationships

A generalization

Provider

Physician

Hospital

Ancillary

MedicalGroup

ProviderNetwork

08/18/05

UML

33

Modeling Class Relationships

An Usage Dependency
A usage dependency is one in which the client requires the presence of the supplier for its correct functioning or implementation.

Abstraction dependancy
An abstraction dependency is one in which the client is at one level of abstraction and the supplier is at a different level

08/18/05

UML

34

Modeling Class Relationships

Permission Dependencies
A permission dependency (permit) signifies that the supplier grants the client permission to access some or all of its constituent elements.

08/18/05

UML

35

Modeling Class Relationships

Refinement relationship
<<interface>> Product +buy() +inventory() +price() +sell()

Shirt

08/18/05

UML

36

Modeling Class Relationships

Relationship Generalization Description One class is a more specialized version of another Notation Solid line arrow with a closed arrowhead pointing to the more general class

Association

One class uses the services of another

Solid line connecting the associated classes. Optional open arrowhead shows direction of navigation Unfilled diamond at the "owner" end of association Shown either using a filled diamond at the "composite" end or the composite graphically contains the "component" Same as generalization except that the line is dashed

Aggregation Composition

One class "owns" another. A special form of association. One class is composed of another. A special form of aggregation.

Refinement

One entity is a more refined version of another - used to show template instantiation One class depends on another
UML

Dependency
08/18/05

Dashed line with an open arrowhead

37