uml class diagram

1Spring 2005Specification and Analysis of Information Systems

Session 2:

Specifying System Structure using UML Class Diagrams

Spring 2008

Analysis and Specification of Information Systems

Eran Tochhttp://www.technion.ac.il/~erant

2

Outline

• Introduction

• Classes, attributes and operations

• Relations

• Generalization

• Guidelines for effective class modeling

All images are under Creative Commons license

3

System Development Process

Intro | Classes | Relations | Generalization | Guidelines

Phase Actions Outcome

Initiation Raising a business needBusiness documents

AnalysisInterviewing stakeholders, exploring the system environment

Organized documentation

SpecificationAnalyze the engineering aspect of the system, building system concepts

Logical System Model

ImplementationProgram, build, unit-testing, integrate, documentation

Testable system

Testing & Integration

Integrate all components, verification, validation, installation, guidance

Testing results, Working sys

Maintenance Bug fixes, modifications, adaptationSystem versions

5

Elements of Modelling Language

• Symbols: Standard set of symbols

• Syntax: Acceptable ways of combining symbols

• Semantics: Meaning given to language expressions

C

C

C2

C1 sends a message to C2

C

C1


6

Advanced Properties

• Expressiveness: What the language can say

• Methodology: Procedures to be followed

• Guidelines: Suggestions on how to build effective models

OK: C1 sends messages to C2

Not OK: C1 sends messages to C2, after all messages of C2 were recieved

1. Model all classes2. Model all relations3. Model all inheritance

Try to model classes with a balanced number of associations


7

Modeling Approaches

Modeling approaches differ from each other according to their view of the world

Structural Models Behavior Models

Focused on describing the structure of the system – the elements that are fixed and remain unchanged over time

Focused on the dynamics of the system: how does it change over time.


8

Example: from Architecture

Architect Louis Isadore Kahn 1901-1074

9

Structural Architecture Model

Plans for Philadelphia’s City Center(1953)

10

Behavior Modeling

Models of Philadelphia’s Traffic Behavior (1953)

11

Outline

• Introduction


• Relations

• Generalization


12

Object-Oriented Approach

• Objects are abstractions of real-world or system entities

Reality Domain Model Domain

vehicle

car

bus

cup

models

models

models


13

Classes

buy()display()

serialNumbernameprice

Produt


Class Name

Attributes

Operations

A class is a template for actual, in-memory, instances

14

Attributes - Signature

[visibility] name [[multiplicity]] [: type] [=initial value] [{property}]

• visibility: the access rights to the attribute

- multiplicity: how many instances of the attribute are they:- middleName [0..1] : String, phoneNumber [1..*]

- Type: the type of the attribute (integer, String, Person, Course)

- initial value: a default value of the attribute- salary : Real = 10000, position : Point = (0,0)

- property: predefined properties of the attribute- Changeable, readOnly, addOnly, frozen (C++: const, Java: final)


15

Attributes - Examples

+ isLightOn : boolean = false

- numOfPeople : int

mySport

+ passengers : Customer[0..10]

- id : long {readOnly}


16

Operations - Signature

[visibility] name [(parameter-list)] [: return-type] [{property}]

• An operation can have zero or more parameters, each has the syntax:– [direction] name : type [=default-value]– Direction can be: in (input paremter - can’t be modified), out (output

parameter - may be modified), inout (both, may be modified)

• Property:– {leaf} – concrete operation– {abstract} – cannot be called directly– {isQuery} – operation leaves the state of the operation unchanged– …

Intro | Classes | Relations | Generalization | Objects | Guidelines

17

Operations - Examples

+ isLightOn() : boolean

+ addColor(newColor : Color)

+ addColor(newColor : Color) : void

# convertToPoint(x : int, y : int) : Point

- changeItem([in] key : string, [out] newItem : Item) : int

What’s the difference?


18

Visibility

• public (+) – external objects can access the member• private (-) – only internal methods can access the

member• protected (#) – only internal methods, or methods of

specialized objects can access the member

+ buy()+ display()- swap(x:int,y: int)

- serialNumber- name# price

Produt We will try to keep the visibility as minimal as

possible


19

Full Blown Class

Window

+default-size:Rectangle#maximum-size:Rectangle

+create ()

+display ()

+size:Area = (100,100)#visibility:Boolean = invisible

+hide ()

-xptr: XWindow

-attachXWindow(xwin:Xwindow*)

{transientstatus=tested} Constraints

<<abstract>>

Stereotype


20

Object Diagram

• In an Object Diagram, class instances can be modeled

buy()display()


Produt Apple Ipod : Product

name = “IMac 1C”price = 1456 $serialNumber = 184934

Apple IMac : Product

name = “Vaio Portable”price = 2999 $serialNumber = 113234

Sony Vaio : Product

In runtime

Class Diagram Object Diagram


21

Outline

• Introduction


• Relations

• Generalization


22Intro | Classes | Relations | Generalization | Guidelines

23

Relations

• A relation is a template for a connection between two instances.

• Relations are organized in a Hierarchy:– Dependency: indicate runtime relation

between classes– Associations: consistent relations– Composition: whole-part

relations


Dependency

Association

Composition Aggregation

24

Associations

buy()display()


Produt

checkout()addProduct(Product p)clearAll()

orderIDdate

Order

includes

* *

MultiplicityIndicates cardinality• – 1:1default•3 – exactly 3 object•* (or n) - unbounded•1..* - 1 to eternity •3..9 – 3 to 9


• Objects on both sides of the association can find each other

• The relation is consistent in time (unless removed)

Name + reading direction

25

Navigation

• If an association is directed, messages can pass only on that direction

• If the association does not have directions, then it’s defined as a bidirectional association, and messages can pass in both directions

• By default, all relations should be directed, unless the requirements dictate a bidirectional relation

Folder File


Why is it directional? For example, if we want to know the files of each folder. However, we do not have a requirement for knowing the folder of each file.

26

Association Classes

Denoted as a class attached to the association, and specify properties of the association

buy()display()


Produt

checkout()addProduct(Product p)clearAll()

orderIDdate

Order

* *

addAnother()removeOne()

numberOfProducts : intgiftWrap : boolean

OrderLine


According to the requirements, each product can appear is several orders, and each order may include several products

An association class is a “normal” class, and may include relations, inheritance etc.

27

Association Class - Objects

Links should be verified, according to the association multiplicity

For each link, an association class instance should be declared


28

Relations & Attributes

• Relations are denoted with associations, not attributes.

• Implementation (pointers, arrays, vectors, ids etc) is left to the detailed design phase.


What is the problem here?

29

Role Names

• Names may be added at each end of the association

• Provide better understanding of the association meaning

• Especially helpful in self-associated classes

Person

Manager

Worker

Manages

Companyemployee employer

*

1..0

..*1 *


30

Ternary Associations


empNum : integer

Employee

theDate : Date

WorkingDay

ID:integer

Project

hours : doubleworkDescription : String

ProjectAttendance

**

*

31

Qualifiers

• A qualifier is an attribute or list of attributes whose values serve to partition the set of objects associated with an object across an association

• The qualifier limits the multiplicity of the target object according to the qualifier attribute. Thus, even though a Bank has many persons, it has one or zero person with a particular account #


Qualifier

College

Student

Student ID

1

1..*

Chessboard

Square

rank : intfile : int

1

1

32

Constraints

• Constrains are simple properties of associations, classes and many other things in UML

• Specify limitations that implementers need to satisfy

Windowlengthwidth

{0.8 length/width1.5}

Dictionary Language Word{ordered}

*

1

Property Constraints

Denotes explicit order of instance


33

Constraints - cont’d

Project

Task

Outsource

{xor}

Employeesalary

boss

{salary < boss.salary}*


Only one of the associations can exist for a given instance (what is the meaning of “or”?)

Committee*

**

memberOf

chairOf{subset}

*

0..1

{ordered}

A full order on associated objects

34

Constraints

• Constraints can be applied to almost every element in UML diagrams, using:– natural language – mathematical notation – OCL (Object Constraint Language)

• Expressing:– Invariants: interest > 3%– Preconditions: before loan() takes place, salary > 5,000$– Postconditions: after loan() takes place, dayCollect = 1 or 10

See http://www.klasse.nl/ocl/index.html


36

Dependency

• Notated by a dotted line

• The most general relation between classes

• Indicates that an object affects another object

AccountingSystem

Reciept

<<creates>>

Order

SecurityControl

<<modifies>>


AccountingSystem creates a Receipt object

37

Dependency – cont’d

• Dependencies are the most abstract type of relations.

• Properties:– Dependencies are always directed (If a given class depends

on another, it does not mean the other way around).– Dependencies do not have cardinality.

• If instances of two classes send messages to each other, but are not tied to each other, then dependency is appropriated.

• Types:– «call»

– «create»


38

Aggregation

• “Whole-part” relationship between classes

• Assemble a class from other classes– Combined with “many” - assemble a class from a couple of

instances of that class


AuthorfileNamePermission

Word Processing Document

Picture

name

Folder

*

*

*

39

Composition

• Composition is a stronger form of aggregation• Contained objects that live and die with the container• Container creates and destroys the contained objects


close()move()

Window

Operating System

Slider Header Panel

0..2 1

40

Composition vs. Aggregation

AggregationAggregation CompositionComposition

Part can be shared by several wholes

Part is always a part of a single whole

Parts can live independently (i.e., whole cardinality can be 0..*)

Parts exist only as part of the whole. When the wall is destroyed, they are destroyed

Whole is not solely responsible for the object

Whole is responsible and should create/destroy the objects

0..4category document

*Window Frame

*


41

Outline

• Introduction


• Relations

• Generalization


42

Generalization – Definitions

• Super Class (Base class)– Provides common functionality and

data members

• Subclass (Derived class)– Inherits public and protected

members from the super class

– Can extend or change behavior of super class by overriding methods

• Overriding– Subclass may override the behavior

of its super class

Super Class

Subclass

…


44

Generalization – advantages

• Modularity: – Eliminate the details– Find common

characteristics among classes

– Define hierarchies

• Reuse:– Allow state and behavior

to be specialized

paint()repaint()

x : inty : int

GraphicComponent

press()

caption : String

Button

paint()

picture : File

Image

clickImage()

ImageButton


Multiple Inheritance

Overriding

45

Generalization Guidelines

• Look carefully for similar properties between objects, sometimes they are not so obvious

What’s the problem here?


id : longname : Stringdesc : StringSalary : FloatworkYears : int

Worker

getCategory() : Category

id : longname : Stringdesc : Stringavailability : int

Product

name : Stringimportance : int

Category

id : longname : Stringdesc : Stringdate : Date

Order


id : longname : Stringdesc : Stringsubject : Subject

Document

updateName(...)updateDesc(...)

User Interface

** | includes

*

*Done by }

*

*

*

*

46

id : longname : Stringdesc : String

Resource

Salary : FloatworkYears : int

Worker

availability : int

Product


CategorizedResource

name : Stringimportance : int

Category

subject : Stringdate : Date

Document

date : Date

Order

updateName(...)updateDesc(...)

User Interface

** includes }

* *Done by }

**

Generalization – cont’d

ID and name are common to all classes


Association is the same as any other attribute

47

Content

<<abstract>>

Article Picture

News Article

MagazineArticle

has picture

1..*

1..*

Abstract Class

• A class that has no direct instances

Denoted by an Italics name

Or by the stereotype “abstract”



Models and Sets

49

Generalization and Sets

paint()repaint()

x : inty : int

GraphicComponent

press()

caption : String

Button

paint()

picture : File

Image

clickImage()

ImageButton

GraphicComponent

ImageButton

ImageButtonClass

Instances

Class Representation Set Representation


50

Interface

Interfaces

• Interface encapsulates the internal behavior of a class and its signature.

• It is actually, a contract, that each implementing class must honor.

ImplementationOperation 1

Operation 2

Data

Operation 1 Impl’

Operation 2 impl’

External Object

Operation 1Operation 1Operation 1 Declaration

Operation 2 Declaration


51

Interface Terminology

Realization relation:


method1()method2()

«interface»ISomething

Class1

Class2

52

Example: Microsoft’s Common Object Model

0

10

20

30

40

50

60

70

80

90

1st Qtr 2nd Qtr 3rd Qtr 4th Qtr

EastWestNorth

4 53 2

..0

1


מרץ מרץ 20072007

א ב ג ד ה ו ש

25 26 27 28 1 2 3

4 5 6 7 8 9 10

11 12 13 14 15 16 17

18 19 20 21 22 23 24

25 26 27 28 29 30 31

1 2 3 4 5 6 7

53

Interfaces Notation

Realization: The object guarantees to carry out the contract specified by the interface


create()move()delete()display()

uniqueID : IDwidth : intheight : int

«interface»ICommonObject Client

Application

EquationPowerPoint Document

Excel Document

54

Interfaces Notations - cont’d

• Another way to notate interfaces:

Client

ICommonObject

Equation. . .

. . .

Provided Interface

Required


55

Outline

• Introduction


• Relations

• Generalization & Encapsulation


56

Guidelines

• How to model? – Methodologies for class specification

• Class normalization

• Course Assumptions

57

How to Model?

Bottom-up Process Top-down Process

Starting with throwing all classes on the page, and then combining them:

Starting with an overview ofthe system, and then splittingclasses


Catalogue Customer

Order

Shipping details

Purchase Process

Charging process Product spec

Search engine results

Category

Credit data

Product Configuration

58

Top-Down Methodology

Analyzing Scope

Identifying major classes

Identifying properties

Identifying methods

Refining and normalizing classes

Generalizing classes

Reviewing

Catalogue Credit card validator

Catalogue Order Customer

Order id, state...

Order id

State started, ended

changeState()ship()

Order id

Business Order

: Order id = 18734

: Customer name = “cohen”

59

CRC Cards

• CRC Cards:– Class,

Responsibility, Collaboration


Example

60

Normalization

61

Normal Forms in UML Classes

Naïve Model

• A naïve model may have a bad problem of coupling:– Data is inter-related– It is difficult to manage data

items individually

• Normalization:– A collection of design

strategies – Ensures loosely coupled

design

• Origin: relational database– But, we do not have primary

keys in Class diagram

systemNumber : longtitle : Stringauthor : StringorderOfAuthor : intcategory : String[]copyNumber : longholderName : StringreturnDate : Datelocation : StringcourseId : StringcourseName : String

Book

62

First Normal Form

All properties must have a final number of values

The number of categories for a book is unbounded

systemNumber : longtitle : Stringauthor : StringorderOfAuthor : intcategory : String[]copyNumber : longholderName : StringreturnDate : Datelocation : StringcourseId : StringcourseName : String

Book

systemNumber : longtitle : Stringauthor : StringorderOfAuthor : intcopyNumber : intholderName : StringreturnDate : Datelocation : StringcourseId : StringcourseName : String

Book

name : String

Category**categorized

Here, I should add a 1:n with an example of n:n

63

Second Normal Form

All properties must depend on the whole class essence, and not just a part of it

systemNumber : longtitle : StringcourseId : StringcourseName : Stringlocation : String

Book

name : String

Author

name : String

Category

1..*

*

written by

*

* categorized

copyNumber : intholderName : StringreturnDate : Datelocation : String

Copy1..*

Has

orderOfAuthor : int

Order

systemNumber : longtitle : Stringauthor : StringorderOfAuthor : intcopyNumber : intholderName : StringreturnDate : Datelocation : StringcourseId : StringcourseName : String

Book

name : String

Category**categorized

Author is a 1st normalization

64

Third Normal Form

All properties must depend only on the class’s essence

systemNumber : longtitle : Stringlocation : String

Book

name : String

Author

name : String

Category

1..*

*

written by*

*categorized

copyNumber : intholderName : StringreturnDate : Date

Copy1..*

Has

courseId : StringcourseName : String

Course

1..*

Textbook of

orderOfAuthor : int

Order

systemNumber : longtitle : StringcourseId : StringcourseName : Stringlocation : String

Book

name : String

Author

name : String

Category

1..*

*

written by

*

* categorized

copyNumber : intholderName : StringreturnDate : Datelocation : String

Copy1..*

Has

orderOfAuthor : int

Order

65

Guidelines for Effective Classes

• Identifying classes– Very similar to identifying data repositories in DFD. Identify data

elements, and model them.– Plus, think of classes that handle processes. If operations are

complicated enough, we might want to model them separately.– Plus, think of the actors. Are all their needs covered by existing

operations?


66

General Assumptions

• Access– Users can execute any public operation of the classes

(except when using specialized stereotypes).

• Lifespan– Objects (except transient objects) have an endless life span. – We don’t need to bother with their serialization.

• Simplicity– No need for get/set.– No need for constructors / distracters .


67

Finding Objects

• Objects can be found, browsed through and located without any aggregating class.


That’s enough for Loan Service to access all instances of Book

68

Guidelines – Modeling Actors

• A common mistake is to model actors as classes

• Remember -– Actors interact with the system directly, they don’t need to be

represented a priory– Sometimes, the system saves data about customers, but it

does not mean that they do all their actions through this class


69

Summary

Introduction– Structural modeling

Classes– Attributes and operations

Relations– Associations, constraints– Dependencies, compositions

Generalization– Inheritance– Interfaces

Object Diagrams Guidelines:

– Methodology– Normalization

uml class diagram

Education

model classes

introduction classes

intintro classes

system structure

inheritance guidelines

system concepts model

data models

c2 language