Uml

Object-Oriented Modeling
Using
Modified Modeling Language
(UML)
Outline
Unified Modeling Language

Principles and Concepts
Modeling Relations and Structures
Modeling Dynamic Behavior
Modeling Requirements with Use
Cases
CS 3300 Object-OrienteObject-Oriented Model
What is a Model?
A model is a simplification of reality.
A model may provide
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
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
Visualize and control the systems 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
are developing.
Importance of Modeling
Models help us
to visualize a system as it is or as we
want it to be.
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 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
Procedures or functions
Object oriented
Objects or classes
What is UML?
UML is a language for
Visualizing
Specifying
Constructing
Documenting
10
Building Blocks of UML

Things -- abstraction
Relations -- tie things together
Diagrams -- group interesting
collections of things
11
Principles and Concepts

Objects and Classes
Principles
12
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.
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.
13
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.
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.
14
Properties of Objects
Two objects are equal if their states are
equal.
Two objects are identical if they are the
same objects.
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.
15
Classes
A class defines a template for
creating or instantiating its instances
or objects.
A class is a description of a set of
objects that share the same
attributes, operations, relationships,
and semantics.
16
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.
Values of methods are immutable
17
Example
Class name: Point class Point {
Fields:
x, y
int x, y;
Method:
move
public void move
(int dx, int dy){
// implementation
}
18
UML Notation for Classes

ClassName
field1
fieldn
method1
methodm
The top compartment shows

the class name.
The middle compartment
contains the declarations of
the fields of the class.
The bottom compartment
contains the declarations of
the methods
19
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 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.
20
Visibility syntax
in Java and UML
Visibilty
Java Syntax
UML Syntax
public
public
protected
protected
package
private
~
private
21
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
22
Method Declaration
The name of the method is required
in the method declaration.
Method declaration may include:
[Visibility][Type]Name([Parameter, ...])
[Visibility]Name([Parameter, ...])[:Type]
Each parameter of a method can be

specified by -- Type Name
23
Examples
Java Syntax
UML Syntax
void move(int dx, int dy)
~move(int dx, int dy)
public int getSize()
+int getSize()
24
Example
Point
Point
private int x
private int y
-x:int
-y:int
+move(dx:int,dy:int)
Point
public void move(int dx,int dy)
x
y
move()
25
UML Notation for Object

ObjectName : ClassName
field1 = value1
fieldn = valuen
The top compartment shows the

object name and its class.
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.
26
Examples
P1:Point
x = 0
y = 0
P1:Point
x = 24
y = 40
Point p1 = new Point();
p1.x = 0;
P1.y = 0;
Point p1 = new Point();

p1.x = 24;
P1.y = 40;
27
Message Passing or
Method Invocation
Objects communicate with one
another through message passing.
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.
28
Example
Recipient
p1.move(10,20) Method
p1
move()
Arguments (10,20)
29
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
-EDU.emporia.mathbeans.MathTable
EDU.emporia.mathtools.*
30
UML notation of packages
31
Principles
Modularity:
alleviate complexity of large-scale systems
Abstraction:
separating the essential from the non-essential

characteristics of an entity
Encapsulation:
Information hiding
Polymorphism:
Portability
Levels of Abstraction:
Organization of classes and interfaces
32
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
33
Principle of Abstraction
The behaviors or functionalities
should be precisely characterized as
contractual interface which captures
the essence of the behavior.
The complexity of the module is
hidden from the clients.
34
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
35
Principle of Polymorphism
Ability to interchange modules
dynamically without affecting the
system.
refers to a contractual interface with
multiple interchangeable
implementation
36
Modeling Relationships and

Structures
A class diagram consists of
A set of nodes that represent classes and
interfaces
A set of links represent relationships among
classes
Class diagrams can be used to model:

Inheritance -- extension and implementation
Association -- aggregation and compostion
Dependency
37
Inheritance
Define a relationship among classes
and interfaces
Inheritance model -- the is-a(n)
relationship
38
Example
39
Principle of Levels of
Abstraction
Abstractions can be organized into
different levels.
Higher level is more general
40
Association
Association represents binary
relationship between classes
Student
advisee
*
* enroll
Course
*
teach
1
adviser
1
Faculty
41
Aggregation and Compositon

Aggregation is a special form of association
Has-a or part-whole relationship
Composition is a stronger form of

aggregation
42
Example
University
College
Department
Student
Member-of
1..*
Chairman-of
Faculty
43
Dependency
Dependency is a relationship between
entities such that the proper
operation of one entity depends on
the presence of the other entity, and
changes in one entity would affect
the other entity.
44
Example
CourseSchedule
Registrar
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
45

Sequence diagram
Depict object interaction by highlighting
the time ordering of method invocation
46
Example
47

State diagram
Depict the flow of control using the
concepts of state and transitions
Labels of transitions are in the form:
[Event-List][[Guard]][/Action]
- Entry action and exit action
entry/Action1
exit/Action2
48
Graphical notations
49

Nested state diagram
Composite of state diagrams
50
Example
talk
51
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
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
52
Use Case Diagram

Consist of:
Use cases
Actors
Relationships among actors and use cases
53
Extension relationships
among actors
54
Dependency relationships
among use cases
55
Case Study: An E-Bookstore

Problem requirements
Program specifications
Object models
Identifying classes
Identifying the features of classes -states and behaviors
Identifying relationships among classes
inheritance and interfaces.
56
Requirements
Allow customers to browse and order
books, music CDs, and computer
software
57
Specifications
Provide information on the books, CDs, and
software
Provide a functionality for customers
registration as well as updating customers
information
Provide a functionality for ordering and
shipping
Provide a functionality for updating
inventory
58
Register
Customer
Logon
Manager
Manage
catalog
Shop
Catalog
Manager
Manage
Acount
System
administrator
Process
order
Inventory
manager
59

Uml

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Uml

Uploaded by

Copyright:

Available Formats

Object-Oriented Modeling

Unified Modeling Language

CS 3300 Object-OrienteObject-Oriented Model

CS 3300 Object-OrienteObject-Oriented Model

CS 3300 Object-OrienteObject-Oriented Model

CS 3300 Object-OrienteObject-Oriented Model

CS 3300 Object-OrienteObject-Oriented Model

CS 3300 Object-OrienteObject-Oriented Model

CS 3300 Object-OrienteObject-Oriented Model

Building Blocks of UML

CS 3300 Object-OrienteObject-Oriented Model

Principles and Concepts

CS 3300 Object-OrienteObject-Oriented Model

Objects and Classes

An object is a thing that can be

An object has an identity, a

A class represents a set of objects

A class characterizes the

CS 3300 Object-OrienteObject-Oriented Model

CS 3300 Object-OrienteObject-Oriented Model

the names and types of all fields

The values of the fields are not defined or fixed in the

CS 3300 Object-OrienteObject-Oriented Model

CS 3300 Object-OrienteObject-Oriented Model

UML Notation for Classes

The top compartment shows

CS 3300 Object-OrienteObject-Oriented Model

Visibility or accessibility defines the scope:

Public -- the feature is accessible to any class

CS 3300 Object-OrienteObject-Oriented Model

CS 3300 Object-OrienteObject-Oriented Model

Public int duration = 100

CS 3300 Object-OrienteObject-Oriented Model

Each parameter of a method can be

void move(int dx, int dy)

~move(int dx, int dy)

public int getSize()

CS 3300 Object-OrienteObject-Oriented Model

public void move(int dx,int dy)

CS 3300 Object-OrienteObject-Oriented Model

UML Notation for Object

The top compartment shows the

objectName -- objectName whose class is of no interest

CS 3300 Object-OrienteObject-Oriented Model

Point p1 = new Point();

Point p1 = new Point();

CS 3300 Object-OrienteObject-Oriented Model

Packages that will be widely used should be

UML notation of packages

CS 3300 Object-OrienteObject-Oriented Model

alleviate complexity of large-scale systems

separating the essential from the non-essential

Organization of classes and interfaces

CS 3300 Object-OrienteObject-Oriented Model

Each module is relatively small and simple

CS 3300 Object-OrienteObject-Oriented Model

CS 3300 Object-OrienteObject-Oriented Model

CS 3300 Object-OrienteObject-Oriented Model

Modeling Relationships and

Class diagrams can be used to model:

CS 3300 Object-OrienteObject-Oriented Model

CS 3300 Object-OrienteObject-Oriented Model

CS 3300 Object-OrienteObject-Oriented Model

CS 3300 Object-OrienteObject-Oriented Model