Chapter Five

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

12
 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

13
 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.
 Loosely coupled and strong cohesion subsystems
14
 Contents of a good architectural model
Registration
Security
Employee
User Account
Customer
Login
Vendor

Backup & Restore Inventory Items

Error Handling
Data management Products

Ado Connection Journal entry

Report Create store Procedure

Kadisco Report Create Trigger

Create View
Ledger Report
Search
Payroll Report
Search info
Subsidiary ledger report

Transaction

Sales

Purchase

15
 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

16
 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

17
 SOFTWARE ARCHITECTURE
 Soft ware architecture is the blue print of the new system.
 It in closed the system decomposition, the global control
flow, error handling policies and intercommunication
protocols
 Examples
 Class Type Architecture
 Repository Architecture
 MVC (Model View Controller)
 CLIENT/SERVIR ARCHITECTURE
 P2P (PEER TO PEER)

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

19
 Layered class type architecture

20
 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

21
 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

22
 Repository Architecture
 Sub systems access or modify data from a single data structure called
repository
 The subsystem are relatively independent and interact through the
central data structure.
 The control how can be directed by the central repository
 It is applicable for
 Database oriented application
 DBMS Design
 Global control flow is needed
DRAWBACKS
 The repository/Central store is the single point of failure
 The performance of the system is dependent of the repository.
In general, the repository is a bottleneck from the performance and
23
maintablity point of view.
 MVC (Model View Controller)
 IN MVC the subsystems are divided into three different
types.
 Model Subsystem

 Responsible for maintaining domain knowledge.

 View Sub System

 Responsible for display the result operation to user

Control Sub System
 Responsible to managing the sequence of interaction with
the user
 In MVC: The controller and the view sub systems are
independent. But the model part is the repository of MVC.
So MVC is the special kind of Repository
24
 CLIENT/SERVIR ARCHITECTURE
 The different sub systems are categorized functionally in to
client and server
 A client sub system requests service from other sub system
called Server. The server responds the request.
 Client server special kind of Repository
 The clients in the client server architecture may maintain its
own data
 P2P (PEER TO PEER)
 In this architecture there is no difference between clients and
server
 In P2P there is no client or server we have only a peer .
Peers are equal.
25
 Peer act as both clients and server
 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.
 There will be changes to be introduced to the
analysis class model based on implementation
26 technologies.
 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.

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

28
 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.
29
 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)

30
 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.(public , protected or
privitae)

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.
 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).

32
 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
33
 Following is an example to compare
Analysis and design versions of a class
Analysis Level Design Level

34
 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-35
 Collaboration Diagram Example

18-36
 Statechart Diagrams
 Statechart diagrams show class states and the events
that cause them to transition between states.
 Each time an object changes state, some of its
attributes must change.
 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.
18-37  The object’s current behavior depends on what happened
 Statechart Example

18-38
 Component Diagram (Architectural Design)
 Is another static model
 Particularly use full for larger sized development teams
 Is essentially a class diagram focusing on system’s components
 Used to represent the different high-level reusable parts of a
system and also captures the inter-relationships between these
parts.
 The primary difference with other UML diagrams is that
Component diagrams represent the implementation perspective
of a system.
 Hence, components in a Component diagram reflect grouping of the
different design elements of a system, for example, classes of the system.

39
 Cont…
 All system processes are placed into separate components
so that all of the data and functions inside each component
are semantically related (just as with the contents of
classes).
 Because of this principle, it is often said that components
are modular and cohesive.
 A component diagram will also help to describe the
organization of the physical components in a system.
 Thus, the goal of component model is to distribute the
classes of a system into large scale cohesive components.
 Components communicate with each other via interfaces.
40
 Cont…
 This principle results in components referred to as
encapsulated
 This modeling task of components helps to divide a large
software development task into smaller parts making it much
easier to organize the software development effort between
sub-teams.
 The component diagram shows the relationship between
software components, their dependencies, communication,
location and other conditions.

41
 Elements of a Component Diagram
Element and its description Symbol

Component: The objects interacting with

each other in the system. Depicted by a
rectangle with the name of the object in it,
preceded by a colon and underlined.

Interface: An interface describes a group of

operations used or created by components. Lollipop
symbol are used to indicate an implemented interface.

Relation/Association/Dependency: Similar to
the relation/association used in class diagrams

42
 Steps:
 one option to componentize your system
 non-business/domain class
 Assign a stereotype “application” by categorizing related UI classes
 Assign a stereotype “infrastructure” for persistence and security system
components
 domain components
 Identify domain components which is a set of classes that collaborate
among them selves to support cohesiveness

43
 Example of a component model for student management
system

44
 Example: Courseware Management System

 In the first instance, the application may seem to be

too simplistic to contain components.
 The Courseware Management System has its own
share of components, some implicit in the design.

45
 Identifying Components in the Courseware
Management System

 The different classes that are modeled for the Courseware Management
System, such as CourseAdministrator, Course, Topic, CourseCalendar,
and Student that fall in the Model layer need to provide a consistent
interface to enable other classes and components to interact with them
and utilize their services.
 We can as well define our own set of simple interface methods to access
these services.
 But, to enable our application components to be used by external
applications, we can consider basing the components on well-defined
component standards.

46
 Component diagram for the Courseware
Management System

47
  The diagram shows the different components, such as
CourseAdministrator, Course, Topic, Tutor, and so forth in the
Model layer and how the Controller layer component interacts
with these components.
 The diagram also depicts a database access component that
represents a library component that the Model layer components
will use to interact with a database.

48
 Deployment Diagram (Architectural Design)

 Captures the configuration of the runtime

elements of the application.
 More useful when a system is built and ready to
be deployed.
 Should start from the time your static design is
being formalized using class diagrams.

49
 Component vs. Deployment Diagrams
 Essentially, the components in a component diagram
are contained in the deployment diagram elements.
 Hence, while components provide the application
functionality, the deployment diagram elements
provide the necessary environment for the
components to execute in.

50
 Deployment Diagram

 Shows the physical relationships among software and hardware

components in the delivered system.
 is a good place to show how components and objects are routed and
move around a distributed system.
 Each node on a deployment diagram represents some kind of
computational unit—in most cases, a piece of hardware.
 The hardware may be a simple device or sensor, or it could be a
mainframe.
 It shows where components will be located, on what servers,
machines or hardware.

51
 Elements of a Deployment Diagram
Element and its description Symbol
Node: The element that provides the
execution environment for the
components of a system. Depicted by a
cube with the name of the object in it,
preceded by a colon, and underlined.

Connection: Similar to the

relation/association used in class
diagrams to define the
interconnection between nodes.

52
 How?
 Identify scope of the model (a part or a whole)
 Identify the distribution architecture (architectural style)
 Layered , Clinet/Server (2 or 3 teir), Repository,
 Distribute components to nodes
 In case of three tier C/S architecture for example
 Application components (UI) to client machine
 Domain components to the application server
 Persistent components to the database server

53
 Example of Deployment Diagram

54
55
 Example
Courseware Management System (using MVC architecture)

 The first part in defining the deployment diagram of the

Courseware Management System is to identify the
components that need to be deployed.
 Once we are clear on this, we will identify what deployment
environment will be needed.
 the Courseware Management System will interact with a
database to store and retrieve the data manipulated by the
application.

56
 Cont…

 Since components of the Courseware Management System will be

the primary elements represented in the deployment diagram, we
will add the components from the component diagram to the
deployment diagram.
 These components are:
 View
 Controller
 Model
 Database Access

57
 A good deployment environment is normally well partitioned to ensure
that the application components have proper resources in their execution
environment. Hence, we will define the nodes of our deployment
environment as follows:
 Web Server—represents the Web server that will receive user requests and send
responses from the application.
 Application Server—a process user requests from the Web server and send application
responses back to the Web server is represented by this node. This node will host the
different components of the Courseware Management System, such as View,
Controller, Model, and Database Access.
 Database Server—host the database used by the components in the application server
node to store and retrieve the data used by the Courseware Management System.

58
 Deployment diagram for the Courseware
Management System

59
 Persistent Modeling
(Can be see both as architectural and or Detail)
 Persistent data modeling is conceptually similar to design
class modeling in terms of content.
 There are minor things to remove and add in persistent
modeling due to the nature of the DBMS to be used for data
management.
 The model describes the internal schema of a database,
depicting the data tables, the data columns of those tables,
the unique nature of some functional columns (attributes)
and the relationships between the tables.

60
 Cont…
 Even though the design so far is object oriented, the data
management part is relational and needs the object oriented
class diagram to be converted to a persistent diagram.
 Mapping objects to tables
 All attributes have public visibility from the DBMS point
of view.
 In persistent diagram, while uniqueness of each object is
maintained using primary keys relationships are
implemented via the use of foreign keys.

61
 Cont…
 The limitation with Relational data model is that it does
not support many to many relationships to be modeled
as it is
 Relational databases do not support inheritance and
designers will be forced to map inheritance structures
within object schema to data schema.
 There are three possible solutions for mapping
inheritance into a relational database:
 Map the entire class hierarchy to a single table.
 Map each concrete class to its own table.
 Map each class to its own table.
62
 Example

63
 Option One
 One can create one table that contains the attributes of
customer class, corporate customer class and personal
customer class all together.
Customer
 In such kind of mapping, all information concerning
Name: String
customers will be put in this table whether the Address: String
customer is corporate or personal customer. ContactName: String
 It is obvious that for some instances, the rows of the creditRating: String
creditLimit: Double
table will have NULL value as some attributes won’t creditCard: LongInt
apply for all.

64
 Option Two
 The other approach is to create two tables; one contacting the
attributes of customer class and that of corporate customer class
and another table that contains attributes of customer class and that
of personal customer class.

CorporateCustomer PersonalCustomer
Name: String Name: String
Address: String Address: String
ContactName: String creditCard: LongInt
creditRating: String
creditLimit: Double

65
 Cont…
 Note here that while the corporate customer
table is without creditCard information the
Personal customer table will not have contatName,
creditRating and creditLimit as its attributes.
 Note also that the attribute Name and Address exist
is both as it is shared through the superclass

66
 Option Three
 The third option is to create three tables; the first table would be
the customer table with its attribute and then a table for corporate
customer and relate it to customer table using foreign key and do
the same for the personal customer class.

Customer CorporateCustomer PersonalCustomer

Name: String ContactName: String creditCard: LongInt
Address: String creditRating: String
creditLimit: Double

67
 Cont…
 In this third option, the primary key selected for
customer table need to be posted in either
PersonalCustomer or CorporateCustomer table to link
instances of the customer class to either of the
special tables.

68
 Cont…
 After the mapping process, data normalization is required to
maintain less duplication in the database.
 Normalization is a process in which data attributes within a
data model are organized to increase the cohesion of tables
and to reduce the coupling between tables.
 The fundamental goal is to ensure that data are stored in one
and only one place.

69
The user interface
 User interfaces should be designed to match the skills,
experience and expectations of its anticipated users.
 System users often judge a system by its
interface rather than its functionality.
 A poorly designed interface can cause a user to make
catastrophic errors.
 Poor user interface design is the reason why so many
software systems are never used.
Design issues in UIs
 Two problems must be addressed in interactive systems
design
 How should information from the user be provided to the
computer system?
 How should information from the computer system be
presented to the user?
 User interaction and information presentation may be
integrated through a coherent framework such as a user
interface metaphor.
 Documenting SDD
System Design
4.1 Introduction
4.2 Proposed software Architecture subsystem
decomposition
4.3 Systems Class Diagram
4.4 State chart
4.5 Collaboration Diagram
4.6 Persistent data management
4.7 Component Diagram
4.8 Deployment Diagram (Hardware/software mapping)
4.9 UI
72
End