Chapter 5: object oriented system design

➢System Design
➢System Design process
➢Object Oriented Design
➢Architectural Design
➢State Machine Modeling
➢Component Modeling
➢Deployment Diagrams
➢Collaboration Modeling

1
System Design
➢System design: focuses on the process of defining the
architecture, modules, interfaces, data structures, and
software and hardware components necessary to
implement it.
➢System Design Process : transforms the analysis model into
design model/system design.
✓is a process that focuses on decomposing the system into
manageable parts.
➢Like analysis, system design is an evolutionary and iterative
activity.
➢Object Oriented Design is the concept that forces
programmers to plan out their code in order to have a
better flowing program.
2
Cont’d…
➢Unlike analysis, there is no external agent, such as the
client, to review the successive iterations and to ensure
better quality.
➢Several alternatives exist, such as using the
developers who were not involved in system design to
act as independent reviewers, or to use developers
from another project to act as a peer review.
➢Like analysis model, we need to ensure that the
system design model is correct, complete, consistent,
realistic, and readable.

3
Objectives
➢To explain how a software design may be
represented as a set of interacting objects that
manage their own state and operations
➢To describe the activities in the object-oriented
design process
➢To introduce various models that can be used to
describe an object-oriented design
➢To show how the UML may be used to represent
these models

4
Object design includes four groups of activities

1.Service specification: specify the subsystem services

in terms of class interfaces, including operations and
arguments or type signatures, and exceptions.
2.Component selection: we use and adapt the off-the-
shelf components identified during system design to
realize each subsystem. We select class libraries and
additional components for basic data structures and
services.

5
 Cont’d…
3.Restructuring: manipulate the system model to increase code
reuse or meet other design goals.
4.Optimization: address performance requirements of the
system model.
➢ This includes:
✓ changing algorithms to respond to speed or memory
requirements,
✓reducing multiplicities in associations to speed up queries,
✓rearranging execution orders,
✓adding derived attributes to improve the access time to
objects
6
From Analysis to Design
➢Each element of the analysis model provides
information that is necessary to create design models.
✓ The data/class modelling transforms analysis
classes into design classes along with the data
structures required to implement the software.
✓ The architectural design defines the relationship
between major structural elements of the software.
✓ Architectural styles and design patterns help to
achieve the requirements defined for the system.
✓ The interface design describes how the software
communicates with systems that interoperate with
it and with humans that use it. 7
7
From analysis through implementation
Analysis Design
Investigation of the Implementation
problem Logical solution code

Book Book Public class Book{

concept Public void print();
Title Public string title;}
Printf()

8
 Design
➢A software design specifies how a program will accomplish
its requirements.
That is, a software design determines:
✓how the solution can be broken down into manageable
pieces
✓what each piece will do.
➢Design transforms requirements into:
✓an architecture diagram
✓subsystems, modules and their relationships

6-9
Object Oriented Design
➢Designing systems using self-contained objects and object
classes.
➢Characteristics:
✓Objects are abstractions of real-world or system entities and
manage themselves.
✓Objects can be independent and encapsulate state and
representation information/behavior.
✓System functionality is expressed in terms of object services
✓Shared data areas are eliminated.
✓Objects communicate by message passing

10
Objects
➢ An object is an entity which has a state and a defined set of
operations which operate on that state.
✓ The state is represented as a set of object attributes.
✓ The operations associated with the object provide services
to other objects (clients) which request these services when
some computation is required.
➢ Objects are created according to some object class
definition.
✓ An object class definition serves as a template for objects.
✓ It includes declarations of all the attributes and services
which should be associated with an object of that class.

11
Cont’d….
OOD Activities:
➢Identification of existing components
➢Full definition of associations
➢Full definition of classes
➢Specifying the contract for each component
➢Choosing algorithms and data structures
➢Identifying possibilities of reuse

12
Object identification
➢Identifying objects (or object classes) is the most
difficult part of object oriented design.
➢There is no 'magic formula' for object identification.
➢ It relies on the skill, experience and domain knowledge
of system designers.
➢Object identification is an iterative process. You are
unlikely to get it right first time.

13
Design models
➢Design models show the objects and object classes
and relationships between these entities.
➢Static models describe the static structure of the
system in terms of object classes and relationships.
➢Dynamic models describe the dynamic interactions
between objects.

14
Software Architecture
➢Architecture: The overall structure of the software
and the ways in which that structure provides
conceptual integrity for a system.
➢The output of this design process is a description
of the software architecture.
➢Each structure comprises software elements ,
relations among them, and properties of both
elements and relations.

15
 Architectural design
➢Architectural design: The design process for identifying
the sub-systems making up a system and the framework
for sub-system control and communication.
➢Once interactions between the system and its
environment have been understood, you use this
information for designing the system architecture.

16
Architectural Types(layered approach)
➢"Tier" can be defined as "one of two or more rows,
levels, or ranks arranged one above another".
❖1-Tier Architecture:
✓ the simplest, single tier on single user
✓ is equivalent of running an application on a personal
computer.
✓All the required component to run the application are
located within it.

17
Cont’d…
✓User interface and data storage are all located on the
same machine.
✓They are the easiest to design, but the least scalable.
✓Because they are not part of a network, they are useless
for designing web applications.
❑Note: A layer is a subsystem that provides a service to
another subsystem.

18
Cont’d…
❖2-Tier Architectures:
✓ supply a basic network between a client and a server.
✓ For example, the basic web model is a 2-Tier
Architecture. A web browser makes a request from a web
server, which then processes the request and returns the
desired response, in this case, web pages.

19
Cont’d…
❖3-Tier Architecture:
➢ An architectural style, where an application consists of 3
hierarchically ordered subsystems.
✓So the 3 layers commonly known as:
▪ User interface: Presentation Layer(PL/UI)
▪ Middleware: Business Logic Layer(BLL) &
▪ Database system: Data Access Layer(DAL).

20
Cont’d…

✓ is most commonly used to build web applications.

✓This approach separates business logic from display
and data.
✓The middleware subsystem services data requests
between the user interface and the database subsystem

21
 Cont’d…
➢Three-Layer architectural style are often used for the
development of Websites:
✓The Web Browser implements the user interface
✓ The Web Server serves requests from the web browser
✓ The Database manages and provides access to the
persistent data.

22
Cont’d…
❖4-Layer-architectural styles (4-Tier Architectures) are
usually used for the development of electronic commerce
sites. The layers are
✓ The Web Browser, providing the user interface
✓ A Web Server, serving static HTML requests
✓ An Application Server, providing session management
(for example the contents of an electronic shopping
cart) and processing of dynamic HTML requests
✓ A back end Database, that manages and provides
access to the persistent data.

23
1 tier architecture

24
2 tier architecture

25
3 tier architecture

26
Summary of three-tier architecture
27
4 tier architecture

28
 Use of Architectural models
➢As a way of facilitating discussion about the system design
➢ The architectural view of a system is useful for
communication with system developers and other actors in
re-engineering process.
➢ Stakeholders can relate to it and understand an abstract
view of the system.
➢They can then discuss the system as a whole without being
confused by detail.
➢ As a way of documenting an architecture that has been
designed

29
Detailed Design
➢Detailed design is the process of completely specifying
an architectural design such that module implementation
can proceed independently.
➢Interface specifications
✓brief description of each module
✓Attributes
✓brief description and specify types
➢operations
✓brief description
✓list of parameters and parameter types
✓return type (if applicable)
➢Algorithm and data structure specification 30
 System Design
8. Boundary
1. Identify Design Goals Conditions
Additional NFRs (non functional requirements) Initialization
Trade-offs Termination
Failure.
2. Subsystem Decomposition 7. Software
Layers vs Partitions Control
Coherence Vs Coupling(degree of interdependence)
Monolithic
Event-Driven
3. Identify Concurrency Conc. Processes
Identification of 4. Hardware/ 5. Persistent Data 6. Global Resource
Parallelism Software Mapping Management Handlung
(Processes, Identification of Nodes Storing Persistent Access Control
Threads) Special Purpose Systems Objects ACL vs Capabilities
Buy vs Build Filesystem vs Database Security
Network Connectivity
31
 State Machines
➢A state is a condition in which an object can be at some
point during its lifetime, for some finite amount of time.
➢An object can do any or all of the following while it's in a
particular state:
--Perform an activity.
--Wait for an event.
--Satisfy one or more conditions.
➢the UML constructs that you can use to model discrete
object behavior in terms of the states an object can reside
in and the transitions that can happen between those
states.
32
 State Machines
➢ The activity addresses both:
-- behavioral state machines, which specify sequences
of states that objects go through during their lifetimes
in response to events and the responses that the
objects make to those events,
--and protocol state machines, which specify which
operations of a given class can be called when
instances of that class are in particular states and
under which conditions.
➢The UML notation for a state is a rectangle with
rounded corners.
33
State Machines
➢A state can be a passive quality, such as On and Off
for a light object.
➢ A state can also be an active quality, or something
that an object is doing.
➢ For example, a coffeemaker has the state Brewing
during which it is brewing coffee.

➢If the state is a "doing" state, you can write the

behavior inside the state, as shown in Figure

34
State Machines

➢the coffeemaker in Figure does the behavior brew

coffee while in the Brewing state.
➢The next figure shows three sample states in which
an Order object can reside.

▪When an Order is in the Posting state, it performs an

activity that involves other objects—in this case, objects
that belong to the Accounting portion of the system.
35
Cont’d…
▪The Retrieving Books state involves an ongoing activity but
no outside objects.
▪The Shipped state is an example of a state in which an
object has satisfied some condition.
➢A transition, shown with an arrow, is a change of an object
from one state (the source state) to another (the target
state).
➢A transition description, written along the arrow, describes
the circumstances causing the state change to occur.
➢The full notation for transition descriptions is
trigger[guard] / behavior, where each element is optional

36
Cont’d…

➢A transition "fires" when an event of interest to the given

object occurs. (The event "triggers" the transition.)
➢Alternatively, a transition may fire unconditionally when the
object is ready to move from one state to another, generally
because the activity associated with the source state is
complete. This is called a triggerless transition.
➢There may also be an action associated with a triggered
transition. Unless there's also a guard, this action executes
unconditionally before the object enters the target state.

37
Cont’d…
➢An object doesn't have to go from one state to a different
state within a transition.
➢A self-transition is a transition whose source state and
target state are the same.
➢Let us see some transitions that an Order object might go
through.

38
Cont’d…
➢The transition from Packaging to Shipping is triggerless,
just like the ones that appear on activity diagrams.
➢The transition from Shipping to Shipped occurs when the
shipConfirm event occurs; the Order object records the
change in state by performing a call action (invoking the
setFulfilledFlag method on itself).
➢The Retrieving Books state has a self-transition.
➢The symbol for a state may contain any of several other
pieces of information, as follows:
▪An entry action is an action that the object always performs
immediately upon entering the given state.

39
Cont’d…
This appears as entry/actionName within the state symbol.
If a self-transition occurs, the object performs the entry
action.

Entry Action

▪An exit action, similarly, is an action that the object always

performs immediately before leaving the given state, in
response to a regular transition or a self-transition.
This appears in the form exit/actionName.

Exit Action

40
Cont’d…
▪A deferred event is an event that's of interest to the object,
but which the object defers handling until the object
reaches a different state.
This is shown as eventName/defer.
Deferred events get put into a queue; when the object
changes state, the object first checks to see whether there
are events in the queue to which it can now respond.

If the GeneralLedger object receives a generateReport

event, the object defers responding to the event because
it's in the middle of posting journal entries. 41
Cont’d…
➢Most notations of state chart diagram is the same as
activity diagram , here in this description we focus only on
the different notations:
✓An entry point represents a point of entry into a state
machine.

✓An exit point represent a point of exit from a state

machine.

42
Cont’d…
✓ A junction makes it possible to build a single overall
transition from a series of transition fragments.

✓ A shallow history "remembers" only the outermost

nested state that the given object was in before it left
the enclosing composite state.
43
Cont’d…
The notation for shallow history is H inside a small circle.

✓A deep history "remembers" the innermost nested state

at any depth within a composite state.
The symbol for a history state is H* inside a small circle.

44
Cont’d…
✓A terminate represents the termination of the execution
of a state machine.
➢In state machine diagram, the emphasis is the flow of
control between states.

The use of an enclosing box

and a name for the diagram
are optional

45
Component Diagram
➢A component is a physical and replaceable part of a system
that conforms to and provides the realization of a set of
interfaces.
➢You use components to model the physical things that may
reside on a node, such as: executables, libraries, tables, files,
and documents.
➢As we stated before, a component is a physical thing that
conforms to and realizes a set of interfaces.
➢ Interfaces therefore, bridge, your logical and physical
models.
➢For example, you may specify an interface for a class in a
logical model, and that same interface will carry over to
some physical component that realizes it. 46
Component Diagram
➢A component, by contrast, defines a system's functionality.
➢Just as a component is the implementation of one or more
classes, an artifact (if it's executable) is the implementation
of a component.
➢You model components and their relationships so that:
1.-- Clients can envision the structure and the functionality in
the finished system.
2.-- Developers have a structure to work toward.
3.-- Technical writers who have to provide documentation
and help files can understand what they're writing about.
4.– You are ready for reuse.
47
Component Diagram
➢Graphically, a component is rendered like a class with a
special icon in the upper right corner.
Alternative
Notation

➢A component can have:

– Interfaces : An interface represents a declaration of a set of
operations and obligations. The interface symbols with a
complete circle at their end represent an interface that the
component provides. Interface symbols with only a half circle at
their end represent an interface that the component requires.

48
Component Diagram
– Ports: Port represents an interaction point between a component
and its environment.
– Connectors
• Connect two components
• Connect the external contract of a component to the internal
structure.
➢A component defines its behaviour in terms of provided
and required interfaces.
➢The next figure shows an example of a component along
with two each of provided interfaces and required
interfaces.

49
Component Diagram

50
Component Diagram
➢Components can be connected by usage dependencies
Usage Dependency
---A usage dependency is a relationship in which one
element requires another element for its full
implementation.
---Is a dependency in which the client requires the presence
of the supplier.
---Is shown as dashed arrow with a <<use>> keyword.
---The arrowhead point from the dependent component to
the one of which it is independent

51
Component Diagram
Ports
➢Specify a distinct interaction point.

➢Ports are associated with the interfaces that specify the

nature of the interactions that may occur over a port.
➢Ports are shown as a small square symbol

➢Ports can be named, and the name is placed near the

square symbol.
➢Ports can support unidirectional communication or bi-
directional communication
The interfaces can be listed in the compartment of a
component box.
52
 Component Diagram

➢ A component diagram provides a physical view of the

system.
➢ It focuses on a set of components and the structural
relationships among them.
➢ Its purpose is to show the dependencies that the software
has on the other software components (e.g., software
libraries) in the system.
53
Component Diagram
➢The next figure shows a component diagram where there
is a component's relationship with other components, and
how the use of the lollipop and socket notation must also
include a dependency arrow (as used in the class diagram).
➢On a component diagram with lollipops and sockets, note
that the dependency arrow comes out of the consuming
(requiring) socket and its arrow head connects with the
provider's lollipop.

54
 Component Diagram

➢ The Order System component depends both on the Customer

Repository and Inventory System components.

55
 Deployment Diagram
Nodes
➢A node represents a computational resource that generally
has memory and often has processing capability.
➢The notation for a node is a cube. The name of the node
always appears on the cube; optionally, a list of the
components that reside on that node also appears.

two example nodes, connected with a communication path, which is comparable to an

association between classes
56
Deployment Diagram
The UML defines the following two specific kinds of nodes:
✓A device is a physical computational resource with processing
capability upon which artifacts may be deployed for execution.

✓An execution environment offers an environment for the execution of

specific types of components that are deployed on the environment, in
the form of executable artifacts.

57
Deployment Diagram
➢Nodes represent deployment targets—in other words,
locations on which artifacts can be deployed.
➢An artifact that exists on a particular node is called a
deployed artifact; a deployment is the pairing of a deployed
artifact with a deployment target.
➢A deployment diagram shows how the finished system will
be deployed on one or more machines.
➢It shows the configuration of run time processing nodes
and the components that live on them.
➢ A deployment diagram can include all sorts of features
such as: machines, processes, files and dependencies.

58
Deployment Diagram
Deployment diagram are used:
1. To model embedded systems.
2. To model client/ server systems.
3. To model fully distributed systems.
➢The next figure shows that any number of HTMLClient
nodes (each hosting a WebBrowser) and GUIClient nodes
communicate with two server machines, each hosting a
WebServer and a CootBusinessServer; each WebServer
communicates with a CootBusinessServer; and each
CootBusinessServer communicates with a DBMS running on
one of two DBServer nodes.

59
Deployment Diagram

60
Deployment Diagram
➢System architectures can be depicted in UML on a
deployment diagram.
➢Deployment diagrams are similar to class diagrams and
object diagrams in that they can show:
---possible architectures (node types),
---and actual architectures (node instances).
➢When showing node instances, just like objects on an
object diagram, the node label takes the form name:Type,
and should be underlined.
➢Nodes can be given multiplicities to indicate how many
might exist at run time: thus, in this diagram, we have nodes
that are duplicated (CootServer and DBServer) and nodes
that are multiplied (CootHTMLClient and CootGUIClient).
61
Deployment Diagram

a simple deployment diagram

62
Deployment Diagram

an example that uses user-defined visual stereotypes.

63
Documenting Object Design
➢Object design is documented in the Object Design
Document (ODD).
➢ It describes:
✓ object design trade-offs made by developers,
✓ guidelines they followed for subsystem interfaces,
✓ the decomposition of subsystems into packages and
classes, and the class interfaces.
➢The audience for the ODD includes system architects, (i.e.,
the developers who participate in the system design),
developers who implement each subsystem, and testers.

64
Cont’d…
➢The ODD enables developers to understand the subsystem
sufficiently well that they can use it. In general, an interface
specification should satisfy the following criteria.
✓Restrictiveness. A specification should be precise enough
that it excludes unwanted implementations.
✓ Generality. A specification, however, should not restrict its
implementation. This allows developers to develop and
substitute increasingly efficient or elegant implementations
that may not have been thought of when the subsystem was
specified.
✓ Clarity. A specification should be easily and unambiguously
understandable by developers.
65
Documenting System Design
➢System design is documented in the System Design
Document (SDD).
➢ It describes :
✓design goals set by the project,
✓the subsystem decomposition (with UML class
diagrams),
✓ the hardware/software mapping (with UML
deployment diagrams),
✓ the data management, and access control,
✓ control flow mechanisms, and boundary conditions.

66
Cont’d…
➢The SDD is used to define interfaces between teams of
developers and as reference when architecture-level
decisions need to be revisited.
➢The audience for the SDD includes:
✓ the project management team,
✓ the system architects (i.e., the developers who participate
in the system design),
✓and the developers who design and implement each
subsystem.

67
End of Chapter four

68