Building Blocks of UML

(1)

Object-Oriented Modeling

oleh:

I Gede Made Karma

Outline

• Unified Modeling Language

• Principles and Concepts

• Modeling Relations and Structures

Object-Oriented Modeling Using UML 2

• Modeling Relations and Structures

• Modeling Dynamic Behavior

• Modeling Requirements with Use

Cases

What is a Model?

A model is a simplification of reality.

A model may provide

– blueprints of a system

Object-Oriented Modeling Using UML 3 blueprints of a system

– Organization of the system – Dynamic of the system

Why We Model

“A successful software organization is

one that consistently deploys quality

software that meets the needs of its

A

i ti th t

users. An organization that can

develop such software in a timely and

predictable fashion, with an efficient

and effective use of resources, both

human and material, is one that has

sustainable business.”

Why We Model

• Model is built to

– Communicate the desired structure and behavior of the system

Vi li d t l th t ’ hit t – Visualize and control the system’s architecture – Better understand the system that being built – Manage risk

– Expose opportunities for simplification and reuse

Why We Model

• We build models so that we can see

and better understand the system we

(2)

Importance of Modeling

• Models help us

– to visualize a system as it is or as we want it to be.

f h b h f

Object-Oriented Modeling Using UML 7 – to specify the structure or behavior of a

system.

– in providing a template that guides us in constructing a system.

– in providing documenting the decisions we have made.

Principles of Modeling

• The choice of what models to create has a major influence on how a problem is approached and how a solution is shaped. • Every model may be expressed at

y y p

different levels of precision.

• The best models are connected to reality. • No single model is sufficient. Every

nontrivial system is best approached through a small set of nearly independent models.

Objected-Oriented Modeling

• Two most common ways in modeling

software systems are

– Algorithmic

Object-Oriented Modeling Using UML 9 Algor thm c

• Procedures or functions

– Object oriented

• Objects or classes

What is UML?

• UML is a language for

– Visualizing

– Specifying

Object-Oriented Modeling Using UML 10 Specifying

– Constructing – Documenting

Building Blocks of UML

• Things -- abstraction

• Relations -- tie things together

• Diagrams

group interesting

• Diagrams -- group interesting

collections of things

Principles and Concepts

• Objects and Classes

• Principles

(3)

Objects and Classes

Interpretation in the Real World Interpretation in the Model

Object An object is a thing that can be _{distinctly identified.} An object has an identity, a _{state, and a behavior.}

y

Class

A class represents a set of objects with similar characteristics and behavior. This objects are called the instances of the class.

A class characterizes the structure of states and behaviors that are shared by all instances.

Objects

• Each of object has a unique identity.

• The state of an object is composed of a set of fields (data fields), or attributes.

• Each field has a name, a type, and a value.

f m , yp , • Behaviors are defined by methods. • Each method has a name, a type, and a value. • Each method may or may not return a value. • Features are a combination of the state and the

behavior of the object.

Properties of Objects

• Two objects are equal if their states are equal.

• Two objects are identical if they are the same objects.

Object-Oriented Modeling Using UML 15 j

• The values of the fields are mutable. • Methods that do not modify the state of

the object are called accessors. • Methods that modify the state of the

object are called mutators.

• Objects can be mutable or immutable.

Classes

• A class defines a template for

creating or instantiating its instances

or objects.

j

• A class is a description of a set of

objects that share the same

attributes, operations, relationships,

and semantics.

Classes

• A class defines

--– the names and types of all fields

– the names, types, implementations of all methods

• The values of the fields are not defined or fixed in the class definition.

• The values of the fields are mutable. • Each instance of the class has its own state. • Different instances of the class may have

different states.

• The implementations of methods are defined in the class definition and fixed for a given object.

Example

Class name: Point class Point { Fields: x, y int x, y;

Method: move public void move p

(4)

UML Notation for Classes

ClassName The top compartment shows

the class name.

field₁ _{The middle compartment}

Object-Oriented Modeling Using UML 19 1

… fieldn

The middle compartment contains the declarations of the fields of the class. method1

… method_m

The bottom compartment contains the declarations of the methods

Field Declaration

• The name of the field is required in the field declaration.

• Field declaration may include:

[Visibility][Type]Name[[Multiplicity]][=InitialValue] [Visibility]Name[[Multiplicity]][:Type][=InitialValue]

[Visibility]Name[[Multiplicity]][:Type][InitialValue] • Visibility or accessibility defines the scope:

– Public -- the feature is accessible to any class – Protected -- the feature is accessible to the class itself,

all the classes in the same package, and all its subclasses. – Package -- the feature is accessible to the class itself

and all classes in the same package.

– Private -- the feature is only accessible within the class itself.

Visibility syntax

in Java and UML

Visibilty Java Syntax UML Syntax

public public +

protected protected #

package ~

private private

-Examples

Java Syntax UML Syntax

Date birthday Birthday:Date

Public int duration = 100 +duration:int = 100

Private Student

students[0..MAX_Size] -students[0..MAX_Size]:Student

Method Declaration

• The name of the method is required

in the method declaration.

• Method declaration may include:

Method declaration may include:

[Visibility][Type]Name([Parameter, ...]) [Visibility]Name([Parameter, ...])[:Type]

• Each parameter of a method can be

specified by --

Type Name

Examples

Java Syntax UML Syntax

void move(int dx, int dy) ~move(int dx, int dy)

(5)

Example

Point

Point -x:int -y:int

private int x private int y

public void move(int dx,int dy)

+move(dx:int,dy:int)

Point x

y move()

UML Notation for Object

ObjectName : ClassName The top compartment shows the _{object name and its class.}

field1= value1

Object-Oriented Modeling Using UML 26 field1= value1

… fieldn = valuen

The bottom compartment contains a list of the fields and their values.

objectName -- objectName whose class is of no interest :ClassName -- anonymous object of ClassName which can be identify only through its relationship with other object.

Examples

P1:Point Point p1 = new Point();

x = 0 0

p1.x = 0; P1 0

y = 0 P1.y = 0;

P1:Point Point p1 = new Point();

x = 24 y = 40

p1.x = 24; P1.y = 40;

Message Passing or

Method Invocation

• Objects communicate with one

another through message passing.

• A message represent a command sent

A message represent a command sent

to an object --

recipient

• A message consists of the receiving

object, the method to be invoked and

the arguments to method.

Example

Recipient p1

p1.move(10,20) Method move()

Arguments (10,20)

Packages

• Package name are in lower case --Java.awt.event

javax.swing.*

• Packages that will be widely used should be named as the reverse of the internet domain as the prefix of the package name

(6)

UML notation of packages

Principles

• Modularity:

– alleviate complexity of large-scale systems

• Abstraction:

– separating the essential from the non-essential

p g

characteristics of an entity

• Encapsulation:

– Information hiding

• Polymorphism:

– Portability

• Levels of Abstraction:

– Organization of classes and interfaces

Principle of Modularity

• A complex software system should be decomposed into a set of highly cohesive but loosely coupled

modules.

• The basic for decomposition are cohesion and

coupling.

– Cohesion -- functional relatedness of the entities within modules.

– Coupling – inter-dependency among different modules.

• Each module is relatively small and simple • Interactions among modules are relatively simple • hierarchical

Principle of Abstraction

• The behaviors or functionalities

should be precisely characterized as

contractual interface which captures

p

the essence of the behavior.

• The complexity of the module is

hidden from the clients.

Principle of Encapsulation

• The implementation of a module

should be separated from its

contractual interface and hidden

from the clients of the module.

• Information hiding

Principle of Polymorphism

• Ability to interchange modules

dynamically without affecting the

system.

y

• refers to a contractual interface with

multiple interchangeable

(7)

Modeling Relationships and

Structures

• A class diagram consists of

– A set of nodes that represent classes and interfaces

A t f li k t l ti hi

– A set of links represent relationships among classes

• Class diagrams can be used to model:

– Inheritance -- extension and implementation – Association -- aggregation and compostion – Dependency

Inheritance

• Define a relationship among classes

and interfaces

• Inheritance model -- the is-a(n)

relationship

Example

Principle of Levels of

Abstraction

• Abstractions can be organized into

different levels.

• Higher level is more general

Higher level is more general

Association

• Association represents binary

relationship between classes

* enroll *

Student Course

Faculty advisee

adviser * enroll

teach

* *

1 1

*

Aggregation and Compositon

• Aggregation is a special form of association

– Has-a or part-whole relationship

(8)

Example

1

1 1

University Department

Faculty

Chairman-of Member-of

* College 1 * * Student

1 1

1 1..*

Dependency

• Dependency is a relationship between

entities such that the proper

operation of one entity depends on

the presence of the other entity and

the presence of the other entity, and

changes in one entity would affect

the other entity.

Example

Registrar

CourseSchedule

Object-Oriented Modeling Using UML 45 void addCourse(CourseSchedule a, Course c)

void removeCourse(CourseSchedule Course findCourse(String title)

void enroll(Course c, Student s) void drop(Course c, Student s

Course

Student

Modeling Dynamic Behavior

• Sequence diagram

– Depict object interaction by highlighting the time ordering of method invocation

Example

• State diagram

– Depict the flow of control using the concepts of state and transitions

Object-Oriented Modeling Using UML 48 p

– Labels of transitions are in the form: [Event-List][[Guard]][/Action] - Entry action and exit action

(9)

Graphical notations

• Nested state diagram

– Composite of state diagrams

Example

talk

Modeling Requirements with

Use Cases

• Use cases describes the externally observable behavior of system functions in the form of interactions between the system to be developed and the external

Object-Oriented Modeling Using UML 52 system to be developed and the external entities --Actors.

• Actors may represent roles played by users of the system or other systems. • Consist of a name and scenarios • One of scenarios is the main scenario

Use Case Diagram

• Consist of:

– Use cases – Actors

– Relationships among actors and use casesp g

(10)

Dependency relationships

among use cases

Case Study: An E-Bookstore

• Problem requirements

• Program specifications

• Object models

Object models

– Identifying classes

– Identifying the features of classes --states and behaviors

– Identifying relationships among classes – inheritance and interfaces.

Requirements

• Allow customers to browse and order

books, music CDs, and computer

software

Specifications

• Provide information on the books, CDs, and software

• Provide a functionality for customers registration as well as updating customer’s

Object-Oriented Modeling Using UML 58 registration as well as updating customer s information

• Provide a functionality for ordering and shipping

• Provide a functionality for updating inventory

Register

Shop

Manage catalog Logon

Customer

Manager

Manage

Acount Process order g

System