Werabe University IT Department

Chapter 6
Determining How to Build Your System:
Object-Oriented Design
The purpose of design is to determine how you are going to build your system
& to obtain information needed to drive the actual implementation of your
system. This is different from analysis, which focuses on understanding what
will be built. Design is an iterative process (possibility to come back to the
previous first step and revise things). Analysis and design are highly iterative &
interrelated. Similarly design & Programming are iterative and interrelated.

Persistence
Use case State Chart
Model
Model Diagram

Class Model Class Model Deployment

(Analysis) (Design) Model

User Interface Collaboration Component

Prototype Diagram Model

6.1 Design Decision

1. Are we going to develop component based application or a pure object
oriented application?
 In component based development your software is developed from
collection of components.
 In pure object oriented application development your software is
built from a collection of classes.
2. Are we going to use a business architecture?
 Will you follow a common business architecture?
3. Are we going to use a technical infrastructure supported by common
software developers like Enterprise Java Beans, COBRA?
 Will you follow a common technical architecture?
4. Which non functional (technical) and constraints are going to be
implemented?

1
Object Oriented System Analysis & Design
Werabe University IT Department

6.2 Class Type Architecture or Layering

Layering is the concept of organizing your software design into layer collections
of classes or components that fullfill a common purpose, such as implementing
your user interface or the business logic of your system.
Class type architecture increases the extensibility, maintainability & portability
of the systems you create.

User Interface
(Boundary) Classes

Controller
(Process) Classes

System
Classes
Business/Domain
Entity or Analysis Classes

Persistence Classes

Permanent Storage

System Classes
 Are only allowed to send message to other system classes, even though
each type of class is allowed to send messages to system classes.
 Provide Operating System specific functionality for your application,
isolating your software from the operating system by wrapping OS-
specific features, in creating the portability of your application.
Persistence Classes:
 Used for storing objects, we can create, update, retrieve, delete objects.
 Encapsulate the capability to store, retrieve, delete, create objects
permanently without revealing details of the underlying storage
technology.
Business/ Domain Classes:
 Implement the concepts pertinent to your business domain.
 Enables you to encapsulate the basic business functionality without

2
Object Oriented System Analysis & Design
Werabe University IT Department

having to concern yourself with user interface, data management, system

management
Controller/Process Classes:
 Implement business logic that involves collaborating with several
business/domain classes or even other controller/ process.
What is the advantage of layering?
 To make our system portable (i.e from one OS to another)
 This makes one system maintainable (because one problem will be
limited in one layer)
6.3 State Chart Modeling
 Also called state, state transition, state machine.
 Used to explore the different state a class can be in (an actor, subsystem
and component can be in its life time).
 UML state chart diagram depicts the various states that an object may be
in & the transitions between those states.
 Transitions are the result of method invocation and often reflect business
rules.
 To understand complex classes better, particularly that act in different
manners depending on their states you should develop one or more UML
state chart diagram
Statechart diagrams: is a notation for describing the sequence of states an
object goes through in response to external events.
 A state is a condition that object satisfies.
 The statechart diagram focuses on the transitions between states as a
result of external events for an individual object
 A small solid black circle indicates the initial state.
 A circle surrounding a small solid black circle indicates a final state.
 A state is depicted by a rounded rectangle.
 A transition represents changes of state triggered by events, conditions,
or time
How to draw a state chart

1. Identify the creation/initial state

2. Identify the final states , if any.

3. Identify as many other applicable, “real world” states as possible.

4. Identify potential substates.

3
Object Oriented System Analysis & Design
Werabe University IT Department

5. Identify the transitions leaving the state.

6. Identify the target state to which a transition nature leads.
 Class diagrams model the static of your system, sequence diagrams
model the logic of usage scenarios & state chart diagram models the
behavior of complex class.

A UML state chart diagram for SetTime use case of the SimpleWatch.
6.4 Collaboration Modeling
 Shows collaboration of different objects in our system. Similar to
sequence diagram in analysis which shows class & object collaboration.
 Used to show the bahaviour of several objects collaborating together to
fulfill a common purpose.
 Depicts a bird eye view of the interaction between objects.
 Shows the message flow between objects in Object Oriented application
and also, imply the basic assocaiations (relationships) between classes.
Drawing Collaboration Diagram
Collaboration diagrams are usually drawn in parallel with class diagram and
sequence diagram.
1. Identify the scope of the diagram.
2. Identify the objects.
3. Identify the relationships between the objects.
4. Identify the messages passed between the objects.
 UML sequence diagrams and UML collaboration diagrams are
interchangeable & their usage often boils down to a matter of personal
taste.

4
Object Oriented System Analysis & Design
Werabe University IT Department

6.5 Component Modeling

 Component diagrams depicts how components are wired together to form
larger components and or System.
 Used both to analyse and design your component based software.
 The goal of component modeling is to distribute the classes of your
system in to larger-scale, cohesive component.
 Identifying the component is the design equivalent of identifying
packages.
 Component diagrams are different in terms of nature and behavior.
 Component diagrams are used to model physical aspects of a system.
 Now the question is what are these physical aspects? Physical aspects
are the elements like executables, libraries, files, documents etc which
resides in a node.
 So component diagrams are used to visualize the organization and
relationships among components in a system. These diagrams are also
used to make executable systems.
 Component diagram cannot be matched directly with other UML
diagrams discussed so far. Because it is drawn for completely different
purpose.
Five steps exist, typically performed in an iterative manner, to componentize
your object design.
1. Handle non business/domain classes
2. Define class contracts
 Class contracts: is any service/behavior of a class that is requested
of it. It is a public method that directly respondes to a message
from other classes.
3. Simplify inheritance & aggregation hierarchies.
4. Identify potential domain component.
 Domain component: is a set of classes that collaborate among
themselves to support a cohesive set of contracts.
 Server classes belong in component
 Client classes don’t belong in component
5. Define domain-component contracts.

5
Object Oriented System Analysis & Design
Werabe University IT Department

6.6 Deployment Modeling

 Deployment diagrams are used to visualize the topology of the physical
components of a system where the software components are deployed.
 So deployment diagrams are used to describe the static deployment view
of a system. Deployment diagrams consist of nodes and their
relationships.
 Developed by architects, networking engineers & system engineers.
 Depicts a static view of the run-time configuration of processing nodes
and the components that run on those nodes.
 Deployment models are typically developed in parallel with component
model.
Steps to develop deployment model
1. Identify the scope of the model
 Deployment configuration for a single application
2. Identify the distribution architecture.
3. Identify the nodes & their connections.
4. Distribute components to nodes.
5. Model dependencies between component.

6
Object Oriented System Analysis & Design
Werabe University IT Department

6.7 User Interface Design

User interface design is a difficult task requiring a wide range of skills.
User interface design principles
1. The structure principle
2. The simplicity principle
3. The visibility principle
4. The feedback principle
5. The tolerance principle
6. The reuse principle

7
Object Oriented System Analysis & Design