Chapter 5: Object Oriented System Design

System Design
System Design process
Object Design
Object Oriented Design
Architectural Design
Class Diagrams
Deployment Diagrams

DEPARTMENT OF COMPUTER SCIENCE-UNITY UNIVERSITY, DESSIE CAMPUS 1

System Design
 System design: focuses on the processes, 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.

DEPARTMENT OF COMPUTER SCIENCE-UNITY UNIVERSITY, DESSIE CAMPUS 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.
we need to ensure that the system design model is
correct, complete, consistent, realistic, and readable.
The system design model is correct if the analysis
model can be mapped to the system design model.
DEPARTMENT OF COMPUTER SCIENCE-UNITY UNIVERSITY, DESSIE CAMPUS 3
 Object Design
During object design:
adding details to the requirements analysis
we refine the analysis and system design models,
identify new objects, and close the gap between the
application objects and off-the-shelf
components(something that is in stock and not
customized).
This includes the identification of custom objects, the
adjustment of off-the-shelf components, and the precise
specification of each subsystem interface and class.
making implementation decisions, Thus, object design
serves as the basis of implementation.
DEPARTMENT OF COMPUTER SCIENCE-UNITY UNIVERSITY, DESSIE CAMPUS 4
 Cont’d…
The object designer can choose among different ways to
implement the system model obtained during requirements
analysis.
Full definition of all the classes in the system
Implementation alternatives evaluated and chosen/ algorithms
Optimize access paths and controls to data during external
interactions
Adjust class structure and associations to increase inheritance
As a result, the object design model can be partitioned into
sets of classes such that they can be implemented by individual
developers.
DEPARTMENT OF COMPUTER SCIENCE-UNITY UNIVERSITY, DESSIE CAMPUS 5
Object design includes four groups of activities

1.Service specification: specify the subsystem services

(identified during system design) 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.

DEPARTMENT OF COMPUTER SCIENCE-UNITY UNIVERSITY, DESSIE CAMPUS 6

 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 DEPARTMENT OF COMPUTER SCIENCE-UNITY UNIVERSITY, DESSIE CAMPUS 7
 Object communication
Conceptually, objects communicate by message passing.
Messages
The name of the service requested by the calling object.
Copies of the information required to execute the service.
Messages are often implemented by method calls.
Name = method name.
Information = parameter list.

DEPARTMENT OF COMPUTER SCIENCE-UNITY UNIVERSITY, DESSIE CAMPUS 8

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
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.
9
DEPARTMENT OF COMPUTER SCIENCE-UNITY UNIVERSITY, DESSIE CAMPUS 9
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()

DEPARTMENT OF COMPUTER SCIENCE-UNITY UNIVERSITY, DESSIE CAMPUS 10

 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

DEPARTMENT OF COMPUTER SCIENCE-UNITY UNIVERSITY, DESSIE CAMPUS 6-11

 Specific Widget Guidelines
Menu Design
Common functions should be easiest to reach
>8 options is too much, grouping to organize
Opposite and dangerous operators should be
physically separated to avoid accidents
Icon Design
Immediately recognizable (small and simple)
Easily distinguishable from others
More important than being very descriptive

12
Specific Widget Guidelines
Web Design Specifics
 Unique with hyperlink nature
 Menu positions
 Sidebar placements
 Key questions web pages should answer at design
phase.
1
1. Where am I?
2. Where can I go?
3. What’s here? 2 3

13
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/behaviour.
System functionality is expressed in terms of object services
Shared data areas are eliminated.
Objects communicate by message passing

DEPARTMENT OF COMPUTER SCIENCE-UNITY UNIVERSITY, DESSIE CAMPUS 14

Interacting objects
o1: C1 o3:C3 o4: C4
state o1 state o3 state o4
ops1() ops3 () ops4 ()

o2: C3 o6: C1 o5:C5

state o2 state o6 state o5
ops3 () ops1 () ops5 ()

DEPARTMENT OF COMPUTER SCIENCE-UNITY UNIVERSITY, DESSIE CAMPUS 15

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.

DEPARTMENT OF COMPUTER SCIENCE-UNITY UNIVERSITY, DESSIE CAMPUS 16

An object-oriented design process
Define the context and modes of use of the system
Design the system architecture
Identify the principal system objects
Develop design models
Specify object interfaces

DEPARTMENT OF COMPUTER SCIENCE-UNITY UNIVERSITY, DESSIE CAMPUS 17

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

DEPARTMENT OF COMPUTER SCIENCE-UNITY UNIVERSITY, DESSIE CAMPUS 18

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.

DEPARTMENT OF COMPUTER SCIENCE-UNITY UNIVERSITY, DESSIE CAMPUS 19

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.

DEPARTMENT OF COMPUTER SCIENCE-UNITY UNIVERSITY, DESSIE CAMPUS 20

Purpose of Design

Design is where customer requirements, business

needs, and technical considerations all come together
in the formulation of a product or system.
The design model provides detail about the software
data structures, architecture, interfaces, and
components.
The design model can be assessed for quality and be
improved before code is generated and tests are
conducted.

21
DEPARTMENT OF COMPUTER SCIENCE-UNITY UNIVERSITY, DESSIE CAMPUS 21
Cont’d…

Software design is an iterative process through which

requirements are translated into a blueprint for
constructing the software.
Design begins at a high level of abstraction that can be
directly traced back to the data, functional, and
behavioural requirements.
As design iteration occurs, subsequent refinement leads
to design representations at much lower levels of
abstraction.

22
DEPARTMENT OF COMPUTER SCIENCE-UNITY UNIVERSITY, DESSIE CAMPUS 22
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.

DEPARTMENT OF COMPUTER SCIENCE-UNITY UNIVERSITY, DESSIE CAMPUS 23

 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.
Layered architecture is appropriate for the description
of architectural design.
 There should be no more than 7 entities in an
architectural model.

DEPARTMENT OF COMPUTER SCIENCE-UNITY UNIVERSITY, DESSIE CAMPUS 24

Architectural Design
An early stage of the system design process.
 Represents the link between specification and design
processes.
 Often carried out in parallel with some specification
activities.
 It involves identifying major system components and their
communications

DEPARTMENT OF COMPUTER SCIENCE-UNITY UNIVERSITY, DESSIE CAMPUS 25

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 the equivalent of running an application on a
personal computer.
All the required component to run the application are
located within it.

DEPARTMENT OF COMPUTER SCIENCE-UNITY UNIVERSITY, DESSIE CAMPUS 26

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.

DEPARTMENT OF COMPUTER SCIENCE-UNITY UNIVERSITY, DESSIE CAMPUS 27

Cont’d…
Note: A layer is a subsystem that provides a service to
another subsystem.
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.

DEPARTMENT OF COMPUTER SCIENCE-UNITY UNIVERSITY, DESSIE CAMPUS 28

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

DEPARTMENT OF COMPUTER SCIENCE-UNITY UNIVERSITY, DESSIE CAMPUS 29

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

DEPARTMENT OF COMPUTER SCIENCE-UNITY UNIVERSITY, DESSIE CAMPUS 30

 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.

DEPARTMENT OF COMPUTER SCIENCE-UNITY UNIVERSITY, DESSIE CAMPUS 31

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.

DEPARTMENT OF COMPUTER SCIENCE-UNITY UNIVERSITY, DESSIE CAMPUS 32

 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 process.
 Stakeholders can relate to it and understand an abstract
view of the system.
They can discuss the system as a whole without being
confused by detail.
 As a way of documenting an architecture that has been
designed

DEPARTMENT OF COMPUTER SCIENCE-UNITY UNIVERSITY, DESSIE CAMPUS 33

Design Guidelines (what about principles?
A design should exhibit an architecture that :
has been created using recognizable
architectural styles or patterns
 is composed of components that exhibit good
design characteristics and can be implemented in
an evolutionary fashion
A design should be modular; that is, the
software should be logically partitioned into
elements or subsystems
A design should contain distinct representations
of data, architecture, interfaces, and components.
DEPARTMENT OF COMPUTER SCIENCE-UNITY UNIVERSITY, DESSIE CAMPUS 34
 Design Principles
The design process should not suffer from ‘tunnel vision.’
The design should be traceable to the analysis model.
The design should not reinvent the wheel.
The design should exhibit uniformity and integration.
The design should be structured to accommodate change.
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.

DEPARTMENT OF COMPUTER SCIENCE-UNITY UNIVERSITY, DESSIE CAMPUS 35

 Guidelines Vs Principles
Principles:
Very broad statements that provide advice on design issues
and principles.
Usually based on research.
Eg. Be consistent, keep users informed
Guidelines:
Lower level, more specific than principles
Take advantage of practical experience
Eg. Be consistent in a way that you have users leave every
menus

DEPARTMENT OF COMPUTER SCIENCE-UNITY UNIVERSITY, DESSIE CAMPUS 36

Example

DEPARTMENT OF COMPUTER SCIENCE-UNITY UNIVERSITY, DESSIE CAMPUS 37

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

DEPARTMENT OF COMPUTER SCIENCE-UNITY UNIVERSITY, DESSIE CAMPUS 38

Cont’d…
operations
brief description
list of parameters and parameter types
return type (if applicable)
Algorithm and data structure specification

DEPARTMENT OF COMPUTER SCIENCE-UNITY UNIVERSITY, DESSIE CAMPUS 39

 The Scope of System Design
Bridge the gap between a problem and an existing
system in a manageable way.
 How? Problem
 Use Divide & Conquer:
1) Identify design goals
2) Model the new system design System
as a set of subsystems Design
3-8) Address the major design
goals.

Existing System
DEPARTMENT OF COMPUTER SCIENCE-UNITY UNIVERSITY, DESSIE CAMPUS 40
 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
DEPARTMENT OF COMPUTER SCIENCE-UNITY UNIVERSITY, DESSIE CAMPUS 41
How the Analysis Models influence System Design
Nonfunctional Requirements : Definition of Design Goals
Functional model : Subsystem Decomposition
Object model : Hardware/Software Mapping, Persistent
Data Management
Dynamic model : Identification of Concurrency, Global
Resource Handling, Software Control
Last: Hardware/Software Mapping: Boundary conditions

DEPARTMENT OF COMPUTER SCIENCE-UNITY UNIVERSITY, DESSIE CAMPUS 42

 Example of Design Goals
Reliability, Maintainability  Good documentation
Understandability  Well-defined interfaces
Adaptability, Reusability  User-friendliness/Ease of use
Efficiency, Portability  Reuse of components
Traceability of requirements
 Rapid development
Fault tolerance,
 Minimum number of errors
 Readability, Ease of learning
Cost-effectiveness
 Ease of remembering
Robustness/High-
performance
 Increased productivity
 Low-cost, Flexibility
DEPARTMENT OF COMPUTER SCIENCE-UNITY UNIVERSITY, DESSIE CAMPUS 43
Web application architecture using the
MVC

DEPARTMENT OF COMPUTER SCIENCE-UNITY UNIVERSITY, DESSIE CAMPUS 44

 TIME TO
TAKE
BREAK !!!
DEPARTMENT OF COMPUTER SCIENCE-UNITY UNIVERSITY, DESSIE CAMPUS 45
 Subsystem Decomposition
Subsystem: Collection of classes, associations, operations,
events and constraints that are closely interrelated with each
other.
The objects and classes from the object model are the
“seeds” for the subsystems.
In UML subsystems are modeled as small packages
Service
A set of named operations that share some common
purpose
The origin (“seed”) for services are the use cases from the
functional model
Services are defined during system design.
DEPARTMENT OF COMPUTER SCIENCE-UNITY UNIVERSITY, DESSIE CAMPUS 46
Subsystem Interfaces vs API
 Subsystem interface:
 Set of fully typed UML operations
 Specifies the interaction and information flow from
and to subsystem boundaries.
 Refinement of service, should be well-defined and
small.
 Subsystem interfaces are defined during object
design.

DEPARTMENT OF COMPUTER SCIENCE-UNITY UNIVERSITY, DESSIE CAMPUS 47

Cont’d…
Application programmer’s interface (API)
The API is the specification of the subsystem interface
in a specific programming language.
APIs are defined during implementation.

The term API should not be used during system design

and object design, but only during implementation.

DEPARTMENT OF COMPUTER SCIENCE-UNITY UNIVERSITY, DESSIE CAMPUS 48

 Example of a Subsystem Decomposition
Partition Layer
relationship Relationship
A:Subsystem „depends on“ Layer 1

B:Subsystem C:Subsystem D:Subsystem Layer 2

E:Subsystem F:Subsystem G:Subsystem Layer 3

Layer
Relationship
„calls“
DEPARTMENT OF COMPUTER SCIENCE-UNITY UNIVERSITY, DESSIE CAMPUS 49
 Properties of Layered Systems
Layered systems are hierarchical.
 This is a desirable design, because hierarchy reduces
complexity .
Similar tasked are performed at the same layer.
Upper layers are dependent on lower layers.

DEPARTMENT OF COMPUTER SCIENCE-UNITY UNIVERSITY, DESSIE CAMPUS 50

Example: Notification subsystem
Services provided by Notification Subsystem
LookupChannel()
SubscribeToChannel()
SendNotice()
UnscubscribeFromChannel()
Subsystem Interface of Notification Subsystem
Set of fully typed UML operations
API of Notification Subsystem
Implementation in Java

DEPARTMENT OF COMPUTER SCIENCE-UNITY UNIVERSITY, DESSIE CAMPUS 51

Subsystem decomposition, Architectural Style & Architecture

Differences:
Subsystem decomposition: Identification of subsystems,
services, and their association to each other (hierarchical,
peer-to-peer, etc. )
Architectural Style: A pattern for a subsystem
decomposition
Software Architecture: Instance of an architectural style.

DEPARTMENT OF COMPUTER SCIENCE-UNITY UNIVERSITY, DESSIE CAMPUS 52

Examples of Architectural Styles

Client/Server
Peer-To-Peer
Model/View/Controller
Service-Oriented Architecture (SOA)

DEPARTMENT OF COMPUTER SCIENCE-UNITY UNIVERSITY, DESSIE CAMPUS 53

Client/Server Architectural Style
One or many servers provide services to instances of
subsystems, called clients
Each client calls on the server, which performs some
service and returns the result
The response in general is immediate
 End users interact only with the client.

Server

Client * 1
requester provider +service1()
+service2()
+serviceN()

DEPARTMENT OF COMPUTER SCIENCE-UNITY UNIVERSITY, DESSIE CAMPUS 54

Client/Server Architectures
Often used in the design of database systems
Front-end: User application (client)
Back end: Database access and manipulation (server)
Functions performed by client:
Input from the user (Customized user interface)
Front-end processing of input data
Functions performed by the database server:
Centralized data management
Data integrity and database consistency
Database security
DEPARTMENT OF COMPUTER SCIENCE-UNITY UNIVERSITY, DESSIE CAMPUS 55
Design Goals for Client/Server Architectures
 Service Portability: Server runs on many operating
systems and many networking environments.
 Location transparency: Server might itself be distributed,
but provides a single "logical" service to the user.
 High performance:
 Client optimized for interactive display-intensive tasks;
 Server optimized for CPU-intensive operations
 Scalability: Server can handle large # of clients as needed
 Flexibility: User interface of client supports a variety of
end devices (PDA, Handy tablets, laptop, mobile phone)
 Reliability: A measure of success with which the observed
behavior of a system confirms to the specification of its
behavior .

DEPARTMENT OF COMPUTER SCIENCE-UNITY UNIVERSITY, DESSIE CAMPUS 56

Problems with Client/Server Architectures
Client/Server systems do not provide peer-to-peer
communication
Server failure causes the interruption of the
communication in the system.
Professional IT person is a must to control the server
Dependability

DEPARTMENT OF COMPUTER SCIENCE-UNITY UNIVERSITY, DESSIE CAMPUS 57

Model-View-Controller Architectural Style
 Subsystems are classified into 3 different types
 Model subsystem:
 Responsible for application domain knowledge
 Used keeping domain knowledge/data
 View subsystem:
 Responsible for displaying application domain objects
to the user
 Used for visualizing/viewing the domain data
 Controller subsystem:
 Responsible for sequence of interactions with the
user and notifying views of changes in the model
 Used for managing user interactions with the system
DEPARTMENT OF COMPUTER SCIENCE-UNITY UNIVERSITY, DESSIE CAMPUS 58
Class Diagrams to Design a System

DEPARTMENT OF COMPUTER SCIENCE-UNITY UNIVERSITY, DESSIE CAMPUS 59

Deployment Diagrams to Design a System

DEPARTMENT OF COMPUTER SCIENCE-UNITY UNIVERSITY, DESSIE CAMPUS 60

DEPARTMENT OF COMPUTER SCIENCE-UNITY UNIVERSITY, DESSIE CAMPUS 61
 Application vs solution objects revisited
During analysis, we identify application objects, their
relationships, and attributes and operations.
During system design, we identify subsystems and most
important solution objects.
During object design, we refine and detail both sets of
objects and identify any remaining solution objects needed
to complete the system.

DEPARTMENT OF COMPUTER SCIENCE-UNITY UNIVERSITY, DESSIE CAMPUS 62

Managing Object Design
Two primary management challenges during
object design:
Increased communication complexity.
The number of participants involved during this phase of
development increases dramatically.
The object design models and code are the result of the
collaboration of many people.
 Management needs to ensure that decisions among
these developers are made consistently with project goals.

DEPARTMENT OF COMPUTER SCIENCE-UNITY UNIVERSITY, DESSIE CAMPUS 63

Managing Object Design
Consistency with prior decisions and documents.
Developers often do not appreciate completely the
consequences of analysis and system design decisions
before object design.
When detailing and refining the object design model,
developers may question some of these decisions and
reevaluate them in the light of lessons learned.
The management challenge is to maintain a record of
these revised decisions and to make sure all documents
reflect the current state of development.

DEPARTMENT OF COMPUTER SCIENCE-UNITY UNIVERSITY, DESSIE CAMPUS 64

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

DEPARTMENT OF COMPUTER SCIENCE-UNITY UNIVERSITY, DESSIE CAMPUS 65

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 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.
DEPARTMENT OF COMPUTER SCIENCE-UNITY UNIVERSITY, DESSIE CAMPUS 66
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.

DEPARTMENT OF COMPUTER SCIENCE-UNITY UNIVERSITY, DESSIE CAMPUS 67

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.

DEPARTMENT OF COMPUTER SCIENCE-UNITY UNIVERSITY, DESSIE CAMPUS 68

End of Chapter five

DEPARTMENT OF COMPUTER SCIENCE-UNITY UNIVERSITY, DESSIE CAMPUS 69