Class Diagram

The class diagram provides a static structure of all the classes that exist within the system. Classes are arranged in hierarchies sharing common structure and behaviour and are associated with other classes.
Class diagrams are used in:

Analysis To build a conceptual domain model with semantic associations between concepts Design Structural model of a design in terms of class interfaces Implementation Source code documentation, exposing the implementation

Class
Class class is abstract concept each object is instance of a class classes classify objects attribute has no values

Customer
Custno Name Address

Order
Orderno dateReceived Price

Object analysis than values to attributes

Class diagram
A class diagram describes the type of objects in a system and the static relationships between them.
Static relations:

Associations Subtypes
Static structure:

Attributes Operations

Objects
An object is a thing that can be tangible or intangible. Examples tangible : bike, car, house intangible : order, account

An object has properties. Example a Customer has a name and address

Customer Name Address

Object diagram
An object diagram is a diagram that shows a set of objects and their relationships at a point in time; object diagrams address the static design view or static process view of a system. An object diagram is shown as a class, and the name is underscored, although an objects name can be shown optionally preceding the class name as: objectname: classname. The object does not have to be named, in which case only the classname is shown underscored.

Object diagram: example

Class operations
An operation is the implementation of a service that can be requested from any object of the class in order to affect behaviour. Operations are used to manipulate the attributes or to perform other actions. Operations are normally called functions, but they are inside a class and can be applied only to objects of that class. An operation is described with a return-type, a name and zero or more parameters. Together, the return-type, name, and parameters are called the signature of the operation. The signature describes everything needed to use the operation.

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)

Attributes - Examples
+ isLightOn : boolean = false - numOfPeople : int mySport + passengers : Customer[0..10] - id : long {readOnly}

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

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
Whats the difference?

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
Produt - serialNumber - name # price + buy() + display() - swap(x:int,y: int)

We will try to keep the visibility as minimal as possible

Association adornments: name, role

The association has a name - the descriptive term, often a verb, for the association. Each association has two association ends; each end is attached to one of the classes in the association. An end can be explicitly named with a label. This label is called a role name (association ends are often called roles).
employee employer

Person
works for

Company

employee

employer

Person
has employment for

Company

Associations: multiplicity
Multiplicity defines the number of objects associated with an instance of the association.
Default of 1 (1: 1) 0 or 1: 0..1 Zero or more (0..infinite): * 1 or more (1..infinite): 1..* n..m; range from n to m inclusive
transports

Car
passenger

Person
transports 5

Car
passenger

Person
transports *

Car
passenger

Person
transports 1..*

Car
passenger

Person
transports 2..5

Car
passenger

Person

Full Blown Class

Stereotype <<abstract>> Window {transient status=tested} +size:Area = (100,100) #visibility:Boolean = invisible +default-size:Rectangle #maximum-size:Rectangle -xptr: XWindow +display () +hide () +create () -attachXWindow(xwin:Xwindow*) Constraints

Object Diagram
In an Object Diagram, class instances can be modeled
Produt serialNumber name price buy() display()

Apple Ipod : Product

In runtime

Apple IMac : Product name = IMac 1C price = 1456 $ serialNumber = 184934

Sony Vaio : Product name = Vaio Portable price = 2999 $ serialNumber = 113234

Class Diagram

Object Diagram

 A relation is a template for a connection between two instances. Relations are organized in a Dependency Hierarchy:
Dependency: dynamic relations Association Associations: consistent relations Composition: whole-part Composition relations

Relations

Associations
Produt serialNumber name price buy() display() * includes * orderID date checkout() addProduct(Product p) clearAll() Order

Objects on both sides of the association can find each other The relation is consistent in time (unless removed)

Multiplicity Indicates cardinality 1:1 default 3 exactly 3 object * (or n) - unbounded 1..* - 1 to eternity 3..9 3 to 9

Navigation
Folder Given a folder, we want to know the files of each folder. However, we do not have a requirement for knowing the folder of each file. File

If an association is directed, messages can pass only on that direction If the association does not have directions, then its a bidirectional association By default, all relations should be directed, unless the requirements dictate a bidirectional relation

Association Classes
Denoted as a class attached to the association, and specify properties of the association
Produt serialNumber name price buy() display() * * orderID date checkout() addProduct(Product p) clearAll() Order

OrderLine

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

numberOfProducts : int giftWrap : boolean addAnother() removeOne()

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

Association Class - Objects

Links should be verified, according to the association multiplicity For each link, an association class instance should be declared

Class Normalization
Classes should be normalized, if:
1. Attributes are selected from large or infinite sets 2. Relations with attributes are in n:n form 3. Groups of attributes are related
1 2
3

Before

After

Relations & Attributes

What is the problem?

Relations are denoted with associations, not attributes. Implementation (pointers, arrays, vectors, ids etc) is left to the detailed design phase.

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
Worker

*..1
Person 1..0
Manager employee

*
employer

Company

Manages

Ternary Associations
Year season team goalkeeper

Team

Player

Record goals for goals against wins losses ties

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
College Qualifier
Student ID 1..*

Chessboard
rank : int file : int 1 1

Student

Square

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 #

 Constrains are simple properties of associations, classes and many other things in UML Specify limitations that implementers need to satisfy Window
length width {0.8 length/width1.5} Property Constraints

Constraints

Dictionary

Language

{ordered}
*

Word

Denotes explicit order of instance

Constraints - contd
Project
{ordered}

A full order on associated objects

Outsource *
{xor}
memberOf

* Task

Committee
chairOf

{subset}

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

Employee
salary

0..1

*
{salary < boss.salary}

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

Dependency
Notated by a dotted line The most general relation between classes Indicates that an object affects another object
Accounting System SecurityControl <<creates>> <<modifies>>

AccountingSystem creates a Receipt object

Reciept

Order

Dependency contd
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

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
Word Processing Document Author fileName Permission * * * Picture

Folder name

Composition Composition is a stronger form of

aggregation Contained objects that live and die with the container Container creates and destroys the contained objects
Window close() move() Operating System

0..2

Slider

Header

Panel

Composition vs. Aggregation

Aggregation Part can be shared by several wholes
0..4 category

Composition Part is always a part of a single whole

Window

document

Frame

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

Generalization Definitions
Super Class (Base class)
Provides common functionality and data members
Super Class

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

Subclass

Generalization advantages
Modularity:
Eliminate the details Find common characteristics among classes Define hierarchies
GraphicComponent x : int y : int paint() repaint()

Button caption : String press()

Image picture : File paint()

Reuse:
Allow state and behavior to be Multiple specialized Inheritance
ImageButton

Overriding
clickImage()

Generalization Guidelines
Look carefully for similar properties between objects, sometimes they are not so obvious
User Interface

Whats the problem here?

Document id : long name : String desc : String subject : Subject getCategory() : Category * * Category name : String importance : int * Product id : long name : String desc : String availability : int

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

Order * *|includes id : long name : String desc : String date : Date

Worker id : long name : String desc : String Salary : Float workYears : int * Done by } *

getCategory() : Category *

Generalization contd
ID and name are common to all classes
Resource id : long name : String desc : String User Interface updateName(...) updateDesc(...)

Order date : Date Done by } * *

Worker Salary : Float workYears : int includes } *

Product availability : int

Document subject : String date : Date

Association is the same as any other attribute

CategorizedResource getCategory() : Category

Category * * name : String importance : int