Chapter Five–Part I

Object Oriented Design

How to Construct?
 Introduction
 The object oriented analysis part does not do well
on how the system should be build.
 This gap is filled by the design phase that provides
such details for the implementation.
 There are various artifacts that would be used to
model the design of the system that evolve from
the analysis phase.

2
 What it is?
• Designing of object oriented software requires
– the definition of a multilayered software architecture,
– the specification of subsystems that perform required functions
and provide infrastructure support,
– a description of objects (classes) that form the building blocks
of the system, and
– a description of the communication mechanisms that allow data
to flow between layers, subsystems, and objects.
• Object-oriented design accomplishes all of these things.

3
 Cont…
 The input for object-oriented design is provided by the
output of object-oriented analysis.
 Realize that an output artifact does not need to be
completely developed to serve as input of object-oriented
design.
 Some typical input artifacts for object-oriented design are;
Conceptual model, Use case, Sequences Diagram and User
interface.

4
Object-Oriented Analysis and Design

Analysis Design Construction

Investigation
Logical solution Code
of problem
 Thus
 Design is defined as
 a meaningful engineering representation of something that is to be
built.
 both “the process of defining the architecture, components,
interfaces, and other characteristics of a system or component” and
“the result of that process.”
 As a process, software design is the software engineering life
cycle activity in which software requirements are analyzed in
order to produce a description of the software’s internal
structure that will serve as the basis for its construction.

6
 Cont…
 More precisely, a software design (the result) must
describe
 the software architecture  how software is
decomposed and organized into components and the
interfaces between those components.
 It must also describe the components at a level of detail
that enable their construction.
 In the software engineering context, design focuses
on four major areas of concern:
 data, architecture, interfaces, and components.
7
 Why is it important?

 Would you try to build a house without a blueprint? You’d risk

confusion, errors, a floor plan that didn’t make sense, windows
and doors in the wrong place . . . a mess.
 Computer software is considerably more complex than a house;
hence, we need a blueprint  the design.
 It can be traced to a customer’s requirements and at the same
time assessed for quality against a set of predefined criteria for
“good” design.

8
 How do I ensure that I’ve done it right?
 At each stage, software design work
products are reviewed for
 Clarity,
 Correctness,
 Completeness, and
 Consistency
 with the requirements and with one another.

9
 The software design process
 Software design is
 an iterative process through which requirements are translated into a
“blueprint” for constructing the software.
 is generally considered a two-step process:
 Architectural design  describes how software is decomposed and
organized into components (the software architecture)
 Class type architecture, Component, Deployment, persistent
diagrams
 Detailed design  describes the specific behavior of these
components.
 Refined class model ,Statechart, collaboration

10
 Software Design Principles
 The design should be traceable to the analysis model.
 The design should not reinvent the wheel.
 The design should “minimize the intellectual distance” between
the software and the problem as it exists in the real world.
 The design should exhibit uniformity and integration.
 The design should be structured to accommodate change.

11
 Cont…
 The design should be structured to degrade gently, even
when aberrant data, events, or operating conditions are
encountered.
 Design is not coding, coding is not design.
 The design should be assessed for quality as it is being
created, not after the fact.
 The design should be reviewed to minimize conceptual
(semantic) errors.

12
 Thus
 What to design? Some examples are…
 – Process and association
 --User Interfaces
 – Storage
 – Networking/Distribution
 • Each requires the addition of extra classes and
associations.

13
 Software Architecture
Software architecture is the process of designing the global
organization of a software system, including:
 Dividing software into subsystems.
 Deciding how these will interact.
 Determining their interfaces.
 The architecture is the core of the design, so all software
engineers need to understand it.
 The architecture will often constrain the overall efficiency,
reusability and maintainability of the system.

14
 The importance of software
architecture
Why you need to develop an architectural model:
 To enable everyone to better understand the system
 To allow people to work on individual pieces of the
system in isolation
 To prepare for extension of the system
 To facilitate reuse and reusability

15
 Contents of a good architectural model
A system’s architecture will often be expressed in terms of
several different views
 The logical breakdown into subsystems
 The interfaces among the subsystems
 The dynamics of the interaction among components at run
time
 The data that will be shared among the subsystems
 The components that will exist at run time, and the machines
or devices on which they will be located

16
 Describing an architecture using UML
 All UML diagrams can be useful to describe aspects of the
architectural model
 Some UML diagrams are particularly suitable for
architecture modelling and for implementation issues:
 Class Type architecture (not in UML)
 Component diagrams
 Deployment diagrams
 Persistent diagram
 Package/subsystem diagram

17
 Design Tasks and Models
 Class Type Architecture (not in UML)
 Class diagrams
 State chart diagrams
 Collaboration diagrams
 Component models
 Deployment diagrams
 Persistent diagram
 Evolving UI

18
 Class Type Architecture (not in UML)
 A common architectural strategy, some might call it a
pattern, is to layer the architecture of a system into several
layers/strata.
 Some strategies simply define N layers stacked on top of each
other where layer J interacts only with layers J-1 and J+1.
 That's an interesting theory, and it clearly makes sense from a
logical point of view, but in practice I've found that it isn't
quite so simple.

19
 Cont…
 The following slide Presents a high-level layering strategy for
a software application.
 The various layers are represented by the rectangles and
collaboration between layers by the arrows.
 The primary name of a layer is indicated first, and other
common names in parenthesis

20
 Layered class type architecture

21
 Cont…
 Interface:
 There are two categories of interface class – user interface (UI)
classes that provide people access to your system and system
interface (SI) classes that provide access to external systems to
your system
 Domain
 This layer implements the concepts pertinent to your business
domain such as Student or Seminar, focusing on the data aspects
of the business objects, plus behaviors specific to individual
objects

22
 Cont…
 Process
 The process layer implements business logic that involves collaborating with several
domain classes or even other process classes
 Persistence
 Persistence layers encapsulate the capability to store, retrieve, and delete
objects/data permanently without revealing details of the underlying storage
technology. often implement between your object schema and your database
schema and there are various available to you.
 System
 System classes provide operating-system-specific functionality for your applications,
isolating your software from the operating system (OS) by wrapping OS-specific
features, increasing the portability of your application

23
 Class Modeling
 The class model at the design level will add some
additional details than that of the analysis level
class model.
 Here the focus will be the solution domain rather
than the problem domain.
 In practice, the analysis level class model will
evolve into a design level class model.

24
 Cont…
 There will be changes to be introduced to the
analysis class model based on implementation
technologies.
 This gives the developers the chance to make
amendments and modification to improve the
quality of the system.
 Changes will also be forced into the class model
due to the implementation technology to be
used.

25
 Cont…
 The design level class model will concentrate on how to
implement attributes methods, inheritance, association,
aggregation, composition and the likes.
 Modeling Methods
 Methods, also called operations or member functions, are the
object-oriented equivalent of functions and procedures.
 The design level will model more information about methods
than the analysis.

26
 Cont…
 The design level may include:
 Visibility: the level of access that external objects
have to a method.
 To reduce the effect of coupling within a system, more
restrictions on access of methods should be set.
 In other words, if a method does not have to be public
then make it protected and if it does not have to be
protected then make it private.

27
 Cont…
Visibility Symbol Description Proper Usage
Public + A public method can be When the method must be
invoked by any other accessible by objects and classes
method in any other object outside of the class hierarchy in
or class. which the method is defined.
Protected # A protected method can be When the method provides behavior
invoked by any method in needed internally within the class
the class in which it is hierarchy, but not externally.
defined or any subclasses
of that class.
Private - A private method can only When the method provides behavior
be invoked by other specific to the class. Private
methods in the class in methods are often the result of
which it is defined, but not refactoring.
in the subclasses.
28
 Cont…
 Name: Descriptive name for the method. A good name
is the one that is capable of explaining the purpose of the
methods just by looking at its name.
 In giving a name to methods the designer needs to know what
programming language will be used for the development so that
the naming convention of that language will be used here.
 Parameters: The names of parameters, and optionally
their types and default values (if any);
 Return value type: The data type of the return value
(if available)

29
 Cont…
 Modeling Attributes
 Attributes are the data aspects of objects.
 The design level will model more information
about methods than the analysis.
 The design level may include:
 Visibility: This is the level of access external
objects have to an attribute.

30
 Cont…
Visibility Symbol Description

Public + A public attribute can be accessed by any other

method in any other object or class.

Protected # A protected attribute can be accessed by any

method in the class in which it is declared or by
any method defined in subclasses of that class.

Private - A private attribute can only be accessed by

method in the class in which it is declared, but
not in the subclasses.
31
 Cont…
 Name: descriptive name to attributes.
 A good attribute name is the one that is capable of
explaining the purpose of the attribute just by looking
at its name.
 Attributes that are collections, such as arrays, should
be given names that are plural to indicate they
represent multiple values, the rest should be singular.

32
 Cont…
 In giving a name to attributes the designer needs to
know what programming language will be used for the
development so that the naming convention of that
language will be used here.
 The most important technique for designing and using
attributes effectively is not to access them directly in
your code.

33
 Cont…
 Following are some of the recommendations:
 Assign private visibility to all attributes;
 Update attributes only in their setter methods;
 Directly access attributes only in their getter methods;
 enforce simple validation logic for an attribute in its setter
method;
 Implement complex validation logic in separate methods; and
 Apply initialization in getter methods for attributes

34
 Cont…
 Type: The data type of an attribute should be
determined (could be a primitive type, such as
string or int, or a class such as Address.)
 Initial value: The initial value for an attribute
should also be indicated (if available).

35
 Cont…
 Modeling Association
 Objects in any system cannot exist and work alone. For this
reason they need to depend one another or collaborate with
each other.
 The dependency and collaboration will help the development
team to define how they interact with each other.
 The collaboration is important as an object needs to know about
another object to work with it.
 For each association multiplicity should be modeled, one on
each end of the association line
36
In Design Minimize coupling and Maximize
cohesion
 Coupling is a measure of how much two items, such as classes or
methods, are interrelated. When one class depends on another class,
we say they are coupled.
 When one class interacts with another class, but does not know any of
the implementation details of the other class, we say they are loosely
coupled.
 A class is coupled to another class when it has knowledge of that other
class.
 Coupling is important because when Class A is coupled to Class B, a
change in B could necessitate a change in A.

37
 Cont…
 Cohesion is a measure of how much an item, such as a
class or method, makes sense.
 A good measure of the cohesiveness of something is
how long describing it takes using only one sentence:
the longer it takes, the less cohesive it likely is.You
want to design methods and classes that are highly
cohesive.

38
 Cont…
 In other words, it should be completely clear what a
method or class is all about.
 A good rule of thumb is if you cannot describe a class or
method with one sentence in less than 15 seconds, then
it probably is not cohesive.
 Classes should represent only one kind of object, and
methods should do one thing and one thing well.

39
 Following is an example to compare
Analysis and design versions of a class
Analysis Level Design Level

40
 Collaboration Diagrams
 Collaboration Diagrams show the same
information as a sequence diagram.
 The emphasis is on the organization of the
objects.
 Sequence is shown by including a sequence
number on the message.

18-41
 Collaboration Diagram Example

18-42
 Statechart Diagrams
 Statechart diagrams show class states and the
events that cause them to transition between
states.
 It is also called a state transition diagram
 An event happens at a specific time and place.
 They cause a change of state, or the transition
“fires”

18-43
 Statechart Diagrams (Continued)
 Each time an object changes state, some of its
attributes must change.
 There must be a method to change the attributes.
 Often there is a display screen or Web form to
enter the attributes.

18-44
 Statechart Diagrams (Continued)
 Statechart diagrams are not created for all classes.
 They are created when:
 A class has a complex life cycle.
 An instance of a class may update its attributes in a number of
ways through the life cycle.
 A class has an operational life cycle.
 The object’s current behavior depends on what happened
previously.

18-45
 Statechart Example

18-46
 End of Part I

47