Chapter 9: Determining How to Build Your

System: OO Design

Objectives
Understand object-oriented design process
Draw different diagrams at design level
Introduction
 After the analysis phase, the conceptual model is
developed further into an object-oriented model using
object-oriented design (OOD). In OOD, the technology-
independent concepts in the analysis model are mapped
onto implementing classes, constraints are identified, and
interfaces are designed, resulting in a model for the
solution domain.
 Design goals
 The definition of design goals is the first step of system design. It
identifies the qualities that our system should focus on.
Design goals Definition
Performance

Response time How soon is a user request acknowledged after the request has been issued?
criteria

Throughput How many tasks can the system accomplish in fixed period of time

Robustness Ability to handle invalid user input

Dependability criteria

Reliability Difference between specifies and observed behavior

Availability Percentage of time system that can be used to accomplish normal tasks

Fault tolerance Ability to operate under erroneous conditions

Security Ability to withstand malicious attacks

Extensibility How easy to add functionality or new classes of the system

Maintenance criteria

Modifiability How easy to change the functionality

Portability How easy to port in different platforms

Adaptability How easy to port in different application domains

Readability How easy to understand the code

Utility How well does the system support the work of the user
criteria
End
user

Usability How easy is it for the user to use the system

Class modeling
 Class model is a visual representation of conceptual
classes in real situation. Example fig. below shows
domain model of banking
Con..
 Object is an entity that has a well-defined role in the
application domain and has state, behavior, and identity.
 State: A condition that encompasses an object’s
properties (attributes and relationships) and the values
those properties have.
 Behavior: Represents how an object acts and reacts
 Class diagram
 Class diagrams describe the structure of the system in terms of
classes and objects.
 Class diagrams describe the system in terms of classes, attributes,
operations, and their associations.
 A diagram that shows the static structure of an object-oriented
model: the object classes (A set of objects that shares a common
structure and a common behavior), their internal structure, and the
relationships in which they participate.
 In UML, classes and objects are depicted by boxes composed of
three compartments
 visually represent the structure and relationships of classes within
a system i.e. used to construct and visualize object-oriented
systems.
 Class name
Attributes

Method or operations

UML class and object diagrams: (A) Class diagram showing two classes, (B)
Object diagram with two instances.
Purpose of class diagram

 Model the static view of an application.

 Can be directly mapped with object-oriented languages
and thus widely used at the time of construction.
 The object model, represented in UML with class
diagrams, describes the structure of the system in
terms of objects, attributes, associations, and
operations.
 Class diagrams are used to describe the structure of the
system.
 Con….
 Class Name: name of a class usually written as bold
 Attributes: represent the data members of the class. May include the visibility (e.g., public,
private) and the data type of each attribute.
 Methods: also known as functions or operations, represent the behavior or functionality of
the class. include the visibility (e.g., public, private), return type, and parameters of each
method.
 Visibility Notation:Visibility notations indicate the access level of attributes and methods.
Common visibility notations include:
◦ + for public (visible to all classes)
◦ - for private (visible only within the class)
◦ # for protected (visible to subclasses)
 Class relationships
◦ Generalization: inheritance
 A generalization is a taxonomic relationship between a more general
classifier and a more specific classifier. Each instance of the specific classifier
is also an indirect instance of the general classifier. Thus, the specific classifier
inherits the features of the more general classifier.
 Represents an "is-a" relationship.

sample class diagram with inheritance and generalization

◦Association: represents a relationship between
two classes where the association has a direction,
indicating that one class is associated with
another in a specific way.
Aggregation

◦ form of association that represents a “whole-part”

relationship.
Composition
Composition is a stronger form of aggregation, indicating a more
significant ownership or dependency relationship.

Cardinality
One-to-one
One-to-many
Many-to-many
 Class Diagram example
example we are asked to create a class diagram for a banking system. It must have the following classes:
•Bank, ATM, Customer, Account, Transaction, Checking Account, Savings Account
Object diagram
Class and object diagram
have
Student
Department +ID : char
-0...1
+did : char -Fname : char
* -0...1
+Dname : string have *
-mname : char
-DoB : Date 1…*
+addstudent() : string
+enroll() : Take
string
1…*

Take
1…*
courses
+code : char
-cname : char
-crhr : int
+enroll() : string

Department:IT
+did : <unspecified> = 001
+Dname : <unspecified> = IT

Student: Zelalem
-id : <unspecified> = DTR0012/16
-Fname : <unspecified> = Zelalem
courses:Java
+code : char = 002
-cname : char = JAVA
-crhr : int = 4
 Example 2: sample class diagram for library system

uses 0...* Book

user
1* +Author name : string
+ID : char *
* +title : string
-Name : char
-ISBN : char
-sex : char
-email : string
0..* -Publisher
account
+reservation_status()
+check account() : string -username : string
-pasword : string
+login()

0...1
1
student librerian
Staff Amin
-cardNo
+borrow() -cardno
+checkbookreturn()
+return() +borrow() +manage_account()
+addbooks()
+return() +deletebooks()
+update()
 A state–chart diagram
 A state–chart diagram shows a state machine that depicts the
control flow of an object from one state to another. A state
machine portrays the sequences of states which an object
undergoes due to events and their responses to events.
 State-chart diagrams are used for modeling objects which are
reactive in nature.
 State machine diagrams describe the dynamic behavior of an
individual object as a number of states and transitions between
these states. A state represents a particular set of values for an
object.
 These are very useful to describe the behavior of objects that act
differently according to the state they are in at the moment
 Represents the events and
states of an object and the
behavior of an object in reaction
to that event
 Shows the life cycle of an object
 State–Chart Diagrams comprise
of −
◦ States: Simple or Composite
◦ Transitions between states
◦ Events causing transitions
◦ Actions due to the events
 e.g. Customer insert ATM cards
State diagram for ATM nested state that occur states
appear within the one super state
Example .In the Automated Trading House System, let us model
Order as an object and trace its sequence. The following figure
shows the corresponding state–chart diagram.
State diagram for State diagram for order
elevator management system
 Architectural components
 The major architectural components of any system are the
software and the hardware.
 software systems can be divided into four basic functions which are
the basic building blocks of any information system
1. data storage-most IS require data to be stored and retrieved
2. data access logic- the processing required to access data, like
database queries
3. application logic: the logic documented in the DFDs, use cases,
and functional requirements
4. presentation logic: the display of information to the user and
the acceptance of the user’s commands (the user interface)
Cont…
 The three primary hardware components of a system are
client computers, servers, and the network that connects them.
 Client computers are the input–output devices employed by
the user and are usually desktop or laptop computers, but can
also be handheld devices, smartphones, special-purpose
terminals, and so on.
 Servers typically are larger multi-user computers used to
store software and data that can be accessed by anyone who
has permission.
 The network that connects the computers
 Client–Server
 two-tiered architecture
client is responsible for the presentation logic, whereas the server is responsible for
the data access logic and data storage. The application logic may reside on the client,
reside on the server, or be split between both. Client–server architectures have four
important benefits
◦ scalable,
◦ support many different types of clients and servers ( using middleware)
◦ use Internet standards, it is simple to clearly separate the presentation logic, the application logic,
and the data access logic and design each to be somewhat independent
◦ if a server fails in a client–server architecture, only the applications requiring that server will fail.
Three tier architecture
 There are many ways in which the application logic can be partitioned
between the client and the server. the software on the client computer is
responsible for presentation logic, an application server(s) is responsible
for the application logic, and a separate database server(s) is responsible
for the data access logic and data storage.
Layered architecture
N-tired architecture
 distributes the work of the application (the middle tier)
among multiple layers of more specialized server computers.
This type of architecture is common in today’s Web-based e-
commerce systems
System decomposition
 Developers divide the system into manageable pieces to deal with
complexity. In order to reduce the complexity of the application domain, we
identified smaller parts called classes and organized them into packages.
 Similarly, to reduce the complexity of the solution domain, we decompose a
system into simpler parts, called subsystems.
 Class and exam scheduling sub system decomposition example
 Package diagram
 Arrange and organize model for large-scale project with package
diagrams.
 Package diagram is also good in visualizing structure and dependency
between sub-systems
 a logical grouping of UML elements (classes, associations, generalizations,
and lesser packages) with a common theme.
 Is used to simplify UML diagrams by grouping related elements into a single
higher-level element
 COMPONENT DIAGRAM
 Component diagrams are used to model physical aspects of a system (elements
like executables, libraries, files, documents etc.)
 Illustrate the physical relationships among the software Physical Design,
components; implementation
 Component diagrams are used to visualize the organization and relationships
among components in a system.
◦ Visualize the components of a system
◦ These diagrams are also used to make executable systems
◦ Describe the organization and relationships of the components.
◦ It does not describe the functionality of the system but it describes the
components used to make those functionalities.
◦ The components can be a software component such as a database or user
interface; or a hardware component
Sample Example – ATM System
An example UML component diagram for the university.
Dashed arrows indicate dependencies between subsystems.
 Three-tier architectural style (represented by UML
component diagram). Objects are organized into three
Layers realizing the user interface, the processing, and the
storage.
 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 another
example
example
 Data/Persistence Model
 An important aspect of developing object-oriented systems is
persistency of data. A database is an ordered collection of related data.
 Relational databases are often used as the mechanism to make your
objects persistent. Because relational databases do not completely
support object-oriented concepts the design of your database is often
different than the design of your class diagram.
 A database management system (DBMS) is a collection of software
that facilitates the processes of defining, creating, storing, manipulating,
retrieving, sharing, and removing data in databases.
 Persistence modeling is the process of mapping objects in relational
database
 Each row is uniquely identified by a chosen set of minimal
attributes called primary key.
 A foreign key is an attribute that is the primary key of a
related table.
 Representing Classes as Tables in RDBMS
 To map a class to a database table, each attribute is
represented as a field in the table. Either an existing
attribute(s) is assigned as a primary key or a separate ID
field is added as a primary key. The class may be
partitioned horizontally or vertically as per requirement.
For example, the Circle class can be converted to table as shown in
the figure below.
Mapping Inheritance to Tables
Example of persistence diagram
 Access control
 Who can access which data?
 Access control and security are system-wide issues.
 The access control must be consistent across the system; in other
words, the policy used to specify who can and cannot access certain
data should be the same across all subsystems
 E.g.
activity actors
Admin student instructor
Create account() ✓ x x
Update grade() x x ✓

View Grade() ✓ ✓ ✓
 Summery of some UML diagrams

UML diagram Description phases

name
Class diagrams Illustrate the relation ship between classes, captures the static Analysis, design
structure of a system
Object diagram Illustrate the relation ship between objects modeled in the system Analysis, design
used when actual instances of a class will better to communicate ,
shows individual objects and their relationships
Package Group other UML diagrams together to form higher level constructs design
Deployment Shows the physical architecture of the system, also used to show design
software components being deployed to the physical architecture
Component Illustrating the physical relationships among the software components design
Activity Illustrate workflows independent of classes analysis
Sequence Model the behavior of objects in time-based manner analysis
Use case Capture functional requirements for the system to illustrate the analysis
interaction between the system and the external environment