You are on page 1of 48

Chapter 7

Object Oriented

• In the design phase there are two major
activities to be performed.
1. Designing the architecture of the system
2. Carrying out detailed design
• The architecture is an over all structure
of the program.
• The purpose of design is to create a clear
or relatively simple internal structure
called architecture for a program.
• The architecture is like a frame work into
which the individual classes can fit.

Layering Models –Class type
• Layering software increases its
• Layering is the concept of organizing
software design into layers /
collections of classes or components
that fulfill a common purpose, such
as implementing your user interface
or the business logic of your system.

• A class type architecture provides a
strategy for layering the classes of the
software to distribute the functionality of
the software among the classes.
• Class type architectures provide
guidance as to what other types of
classes will interact with, and how that
interaction will occur. This increases the
extensibility, maintainability, and
portability of the systems you create.
• The following diagram shows the layers of
system based on class types
User Interface classes

cess classes System

Business/ domain

Persistence classes

store(s )

The user interface layer
• A user interface class contains the code
for the user interface part of an
• E.g. A GUI is implemented as a menu,
editing screen, and report classes.
• E.g.2. Integrated voice response (IVR)
systems using telephone technology.
• You should be able to change the UI in
any way you choose without changing the
fundamental business.
• UI classes are often identified as part of
UI prototyping and sequence modeling.
• Also represented in UML as <<interface
class>> or <<boundary class>> 6
The controller/Process layer
• The purpose of controller/Process
class is to implement business logic
that pertains to several objects,
particularly objects that are
instances of different classes.
• Controller classes are given stereo
type << controller class>>.
• Controller classes collaborate with
other controller classes and business
classes. 7
The business / domain layer
• Also called analysis or entity class is
usually identified during analysis.
• SMEs usually identify the business classes
• Modeled by conceptual class model
• The business layer enables you to
encapsulate the basic business
functionality with out having concern with
UI , data management or system
management issues.

The persistence Layer
• The persistence layer provides the
infrastructure for the storage and retrieval
of objects.
• The business objects should not be affected
by changes to persistence strategy.
• E.g. You might decide to install the latest
version of database, change your database
schema ,migrate to a new database vender
or even change your data storage
completely (perhaps migrating from a
relational database to an object database.)
• The following picture shows a persistence
model for a simple human resource
• The persistence layer encapsulates
access to permanent storage, but not
the storage mechanism itself.
• E.g. The persistence layer may
encapsulate access to the relational
database. But it is not the database
it self.

• In the layered class type architecture
,messages flow from the
business/domain class layer to the
persistence class layer. This
messages take the form of :
•Create a new object
•Retrieve this object from the
•Update this object
•Delete this object

• This type of messages are referred to
as object oriented create, retrieve,
update and delete (OOCRUD).
• The persistence layer only provides
access to the permanent storage. It
is not the permanent storage
mechanism it self.
• The persistence layer minimizes the
effort required to handle change to
permanent storage.

The system layer
• The system layer provides access to
the operating system and non OO
• Every operating system offers
functionality that we want to be able
to access in our applications like file
handling, multitasking,
multithreading and network access.

• You want to wrap the features of an
operating system in such a way that
when you port an application, you
need to modify a minimum number
of classes. In other words, you need
to create classes that wrap specific
features of the operating system.
• This is because the operating
systems get upgraded.

Class modeling
• Inheritance
• Associations
• Dependency
• Multiplicity
• Aggregation and composition
• Modeling methods
• Modeling attribute

Modeling methods during
• Methods also called operations or
member functions are the OO
equivalent of functions and
• On design class diagrams, include
the visibility, name, parameters,
return value, and stereo type of

Types of operations
• Constructor operation
• Query operation
• Update operation
• Scope operation

• Constructor operation -creates a new
instance of a class
– E.g. you can have an operation called
createStudent with a student class that
creates a new student and initializes its
• Query operation –An operation that
accesses the state of an object but
does not alter the state.
• Update operation –An operation that
alters the state of an object.
• Scope operation – an operation that
applies to a class rather than an
object instances.
• E.g. averageGpa for the student
classes for the student class
calculates the average gpa across all
students (the operation name is
underlined to indicate that it is a
scope operation)

• Visibility- the level of access that
external objects have to a method,
on your class diagrams.
• Public(+)-a public method can be
invoked by any other method in any
other object or class.
– Use when the method must be
accessible by objects and classes
outside of the class hierarchy in which
the method is defined

• Protected(#)-a protected method
can be invoked by any method in the
class in which it is defined or any sub
classes of that class.
– used when the method provides
behavior that is needed internally within
the class hierarchy but not externally.
• Visibility also works for attributes
– But all attributes should be private and
accessed by getter and setter methods

• Getter –a method to obtain the
values of a data attribute, or
calculate the value, of an object or
• Setter- a method that sets the value
of a data attribute of an object or
class. Also know as mutator

• Private(-)-can only be invoked by
other methods in the class in which it
is defined, but not in the sub classes
– Used when the method provides
behavior that is specific to the class.

Strategies for naming
• Method should be named using a full
description, using mixed case with the
first letter of any non-initial words
capitalized using the format
• The common practice is for the first word
of member function a strong action verb.
• The naming strategy works also for

Bad name Good Name
1. openAcc() 1. openAccount()
2. mailingLabelPrint() 2. printMailingLabel()
3. Purchaseparkingpass() 3. purchaseParkingPass()
4. saveTheObject() 4. Save()
5. fName 5. firstName
6. firstname 6. firstName
7. firstNameString 7. firstName

State chart Modeling
• Objects have both behavior and state
or, in other words, they do things
and they know things.
• To understand complex classes
better particularly those act in
different manners depending on their
state, you should develop a UML
state chart diagram describing how
their instances work.

• UML state chart diagrams depict the
various states an object may be in
and the transitions between those
• Like activity diagrams it has initial
states and final states.
• An initial state is called creation state
is the one that an object is in when it
is first created.
• A final state is one in which no
transitions exist.
• the above figure shows state chart
diagram for the seminar during
registration. The rounded rectangle
represents states; instances of
seminar can be in the “proposed”,
“scheduled”, “open for enrolment”,
“full”, and “closed for enrolment”
• Has filled circle and boardered circle
for initial and final state.
• The arrows represent transitions
,progressions from one state to an
How to draw a state diagram
1. Identify the initial/creation state
2. Identify the final state(s) ,if any
3. Identify as many other applicable
,”real-world” states as possible.
4. Identify potential substates
5. Identify the transitions leaving a
6. Identify the target state to which a
transition leads
• State diagrams are used to
document complex classes often in
real-time states.
• The state charts differ between a
super class and its subclasses.
• This is because ,although the
subclass is similar to the super class
still they are different.

Collaboration Modeling
• Collaboration diagrams depict a
birds-eye view of the interactions
between objects.
• Collaboration diagrams show the
message flow between objects in the
object oriented application and also
imply the basic associations
(relationships) between classes.

• In the figure above the “seminar
details” user interface class
collaborates with the seminar
object to obtain the information
needed to display its information.
• It first invokes the getter method
to obtain the name of the seminar.
• It is the first massage invoked
because its sequence number is
• To fulfill this responsibility, the
seminar object then collaborates with
the course object that describes it to
obtain the name of the course.
• The invocation of getname() and
getnumber() on the course object is
clearly the result of invoking getname()
on the seminar object.
• The name of a seminar is in the format
“course Number:course Name ”

• The rectangles represent the various
objects involved that make up the
• The lines between the rectangles
represent the relationships between them.
• The same notation for classes and objects
in sequence diagrams are used on UML
collaboration diagrams.
• Messages are depicted as a labeled arrow
that indicates the direction of the message
using notations similar to that used on
sequence diagrams
• Optionally, you may indicate the
sequence number in which the
message is sent.
• Indicate an optional return
value, and indicate the method
name and the parameters (if any
passed to it).
• Model return values when it is
not obvious.

Drawing collaboration
• Identify the scope of the diagram
• Identify the objects
• Identify the relationship between
the objects
• Identify the messages passed
between the objects

Component modeling (UML)
• Component based development and
OO development go hand- in-hand.
• It is generally recognized that object
technology is the preferred
foundation from which to build
• UML includes component diagram
that can be used both to analyze and
design component based software.

• Components are modeled as
rectangles with two smaller
rectangles jutting out from the left
hand side.
• Components implement one or more
interfaces, modeled using the same
“lollipop” that UML class diagrams
• Components have dependencies on
the interfaces of other components.
• The diagram above depicts the
component model for a university
system. 42
Deployment Diagram
• A UML deployment diagram depicts a
static view of the run-time configuration of
processing nodes and the components
that run on those nodes.
• In other words, deployment diagrams
show the hardware for your system, the
software that is installed on that
hardware, and the middleware used to
connect the disparate machines to one
• You want to create a deployment model
for applications that are deployed to
several machines.
• A point-of-sales application running
on a thin-client network computer
directly accessing a centralized
database server would be a good
candidate for a deployment model.
• So would a customer service system
deployed using a distributed object
architecture such as CORBA
(Common Object Request Broker

• Deployment models are also needed
for the design of embedded systems,
showing how the hardware and
software components work together.
• In short, all but the most trivial of
systems will require a deployment

• In the figure below presents an example
of a UML deployment diagram for the
student administration application.
• The three-dimensional boxes represent
nodes such as computers or switches and
connections between nodes are
represented with simple lines.
• As you would expect software
components, interfaces, and dependencies
are indicated using the standard UML

• In Figure stereotypes indicate that
the connection between the browser
and the application server uses the
Internet’s standard HTTP protocol
and that Java’s Remote Method
Invocation (RMI) protocol is used
across the connection between the
application server and the data
• The components have the same type
of stereotypes as they did on the
UML component diagram.