Professional Documents
Culture Documents
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
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
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.
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)
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
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)
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
Object Diagram
In an Object Diagram, class instances can be modeled
Produt serialNumber name price buy() display()
In runtime
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.
According to the requirements, each product can appear is several orders, and each order may include several products
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 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
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
Constraints - contd
Project
{ordered}
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>>
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
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
document
Frame
Parts exist only as part of the whole. When the wall is destroyed, they are destroyed
Generalization Definitions
Super Class (Base class)
Provides common functionality and data members
Super Class
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()
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
updateName(...) updateDesc(...)
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(...)