Chapter 7

Object Oriented
Design

1
• 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.

2
 Layering Models –Class type
architecture
• Layering software increases its
robustness
• 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.

3
• 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
4
 User Interface classes

Controller/Pro
cess classes System
classes

Business/ domain
classes

Persistence classes

Persistence
store(s )

5
 The user interface layer
• A user interface class contains the code
for the user interface part of an
application.
• 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.

8
 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
database
9
10
• 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.

11
• 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
database
•Update this object
•Delete this object

12
• 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.

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

14
• 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.

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

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

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

18
• 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
state.
• 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.
19
• 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)

20
• 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

21
• 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

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

23
• 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.

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

25
 Examples
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

26
 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.

27
28
• UML state chart diagrams depict the
various states an object may be in
and the transitions between those
states.
• 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.
29
• 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”
states.
• Has filled circle and boardered circle
for initial and final state.
• The arrows represent transitions
,progressions from one state to an
other.
30
 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
state
6. Identify the target state to which a
transition leads
31
• 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.

32
 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.

33
34
• 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
one.
35
• 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 ”

36
• The rectangles represent the various
objects involved that make up the
application.
• 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
37
• 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.

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

39
 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
components.
• UML includes component diagram
that can be used both to analyze and
design component based software.

40
41
• 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
use.
• Components have dependencies on
the interfaces of other components.
• The diagram above depicts the
component model for a university
system. 42
 Deployment Diagram
(UML)
• 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
another.
• You want to create a deployment model
for applications that are deployed to
several machines.
43
• 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
Architecture).

44
• 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
model.

45
• 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
notations.

46
47
• 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
server.
• The components have the same type
of stereotypes as they did on the
UML component diagram.
48