Object Oriented Design/OOD

04/17/2025 KMU - OOD 1

 Software Design
• Design is the highly significant phase in the software
development where the designer plans “how” a software
system should be produced in order to make it
– Functional
– Reliable
– reasonably easy to understand, modify and maintain.
• It is about solution of the problems mentioned in
requirement document.
• Design is a creative activity
– it determines the major characteristics of a system
• Design has great impact on testing and maintenance
• The output of this phase is a design document to be used
for implementing the system
 Software Design
• Definition: Design is a problem-solving process whose
objective is to find and describe a way:
• to implement the system’s functional requirements...
• while respecting the constraints imposed by the quality,
platform and process requirements including the budget
• and while adhering to general principles of good design
quality
• A designer is faced with a series of design issues
– These are sub-problems of the overall design problem.
– Each issue normally has several alternative solutions: design
options.
– The designer makes a design decision to resolve each issue.
• This process involves choosing the best option from among
the alternatives.
 Levels in Design Process
• The design process for software systems often has two
levels.
• Top-level design (System design or conceptual design ):
– Identifies the components (sub-systems) needed for the
system, their behavior, and relationships.
• Detailed design (Logic design):
– The internal design of the modules, or how the
specifications of the module can be satisfied, is decided.
– For each module data structures and algorithms are
designed.
– Outcome of detailed design is module specification.
 Strategy of design
• Top-down design
– First design the very high level structure of the system.
– Then gradually work down to detailed decisions about
low-level constructs.
– Finally arrive at detailed decisions such as:
• the format of particular data items;
• the individual algorithms that will be used.
• Bottom-up design
– Make decisions about reusable low-level utilities.
– Then decide how these will be put together to create
high-level constructs.
 Strategy of design…

bottom-up top-down

 Hybrid Design: Normally a mix of top-down and bottom-up

approaches are used
Top-down design is almost always needed to give the system a
good structure.
Bottom-up design is normally useful so that reusable
components can be created.
 Phases of Design
 Architectural design: Identify sub-systems
 Abstract specification: Specify sub-systems
 Interface design: Describe sub-system interfaces
 Component design: Decompose sub-systems into
components
 Data structure design: Design data structures to hold
Requirements problem data
specification
 Algorithm design: Design algorithms for problem
functions Design acti
vities

Architectur
al Abstract Interface Component Data Algorithm
design specificatio design design structur
e design
n design

Software Data
System Interface Component Algorithm
specification structure
architectur
e specifica
tion specification specifica
tion
specification

Design pr
oducts
• OOD
– Emphasizes a conceptual solution that fulfills the
requirements and define s/w objects, their responsibilities
and how they collaborate to fulfill the requirement.
– The products of object-oriented design can then be used
as blueprints for completely implementing a system using
object-oriented programming methods.
– detailed (or objects) OOD: provides the complete definition
of classes and associations to be implemented, as well as
the data structures and the algorithm of methods that
implement class operations
– OOD model, which adds the technical details of the
hardware/software solution that defines how the software
has to be implemented

04/17/2025 KMU - OOD 8

Cont’d…
• System design, object design, and implementation constitute the
construction of the system.
• During these three activities, developers bridge the gap between the
requirements specification, produced during requirements elicitation
and analysis, and the system that is delivered to the users.
• System design is the first step in this process and focuses on
decomposing the system into manageable parts.
• During requirements elicitation and analysis, we concentrated on the
purpose and the functionality of the system.
• During system design, we focus on the processes, data structures,
and software and hardware components necessary to implement it.
• The challenge of system design is that many conflicting criteria and
constraints must be met when decomposing the system.

04/17/2025 KMU - OOD 9

Overview of System Design
• Analysis: Focuses on the application domain
• Design: Focuses on the solution domain
• System Design
– Reduces the gap between requirements and the (virtual) machine
– Decomposes the overall system into manageable parts
• Design Goals Definition
– Describes and prioritizes the qualities that are important for the
system
– Defines the value system against which options are evaluated
• Subsystem Decomposition
– Results into a set of loosely dependent parts which
make up the system
– Use Divide and Conquer
• We model the new system to be developed as a set of subsystems
04/17/2025 KMU - OOD 10
 Cont’d
• System design is the transformation of an analysis model
into a system design model.
• During system design, developers define the design goals
of the project and decompose the system into smaller
subsystems that can be realized by individual teams.
• Developers also select strategies for building the system,
such as the hardware/software strategy, the persistent data
management strategy, the global control flow, the access control
policy, and the handling of boundary conditions.
• The result of system design is a model that includes a
subsystem decomposition and a clear description of each of
these strategies.

04/17/2025 KMU - OOD 11

 System Design
1. Design Goals
Definition
8. Boundary
Trade-offs
Conditions
Initialization
T ermination
Failure
2. System
Decomposition
Layers/Partitions 7. Software
Cohesion/Coupling
Control
Monolithic
Event-Driven
3. Concurrency Threads
Identification of 4. Hardware/ 6. Global Conc. Processes
Threads Software 5. Data Resource Handling
Mapping Management
Access control
Special purpose Persistent Objects Security
Buy or Build Trade-off Files
Databases
Allocation Data structure
Connectivity

04/17/2025 KMU - OOD 12

 How to use the results from the Requirements
Analysis for System Design
• Nonfunctional requirements => Activity 1: Design Goals Definition
• Functional model =>
– Activity 2: System decomposition (Selection of subsystems
based on functional requirements, cohesion, and coupling)
• Object model =>
– Activity 4: Hardware/software mapping
– Activity 5: Persistent data management
• Dynamic model =>
– Activity 3: Concurrency
– Activity 6: Global resource handling
– Activity 7: Software control
• Subsystem Decomposition
– Activity 8: Boundary conditions

04/17/2025 KMU - OOD 13

 From Analysis to System Design
Nonfunctional Functional Model
Requirements
8. Boundary
1. Design Goals Conditions
Definition Initialization
Trade-offs Termination
Functional Model Failure
2. System Decomposition Dynamic
Layers vs Partitions Model
Coherence/Coupling 7. Software
Control
Monolithic
Dynamic Object Model Event-Driven
Model Conc. Processes
4. Hardware/ 5. Data
6. Global Resource
3. Concurrency Software Mapping Management
Handlung
Special Purpose Systems Persistent Objects
Identification of
Threads
Buy vs Build Filesystem vs Database Access Control List
Allocation of Resources vs Capabilities
04/17/2025 Connectivity KMU - OOD
Security 14
 Overview of System Design
• Analysis results in the requirements model described
by the following products:
– a set of nonfunctional requirements and constraints, such as
maximum response time, minimum throughput, reliability,
operating system platform, and so on
– a use case model, describing the system functionality from
the actors’ point of view
– An object model, describing the entities manipulated by the
system
– A sequence diagram for each use case, showing the
sequence of interactions among objects participating in the
use case

04/17/2025 KMU - OOD 15

• The analysis model describes the system completely
from the actors’ point of view and serves as the basis of
communication between the client and the developers.
• The analysis model, however, does not contain
information about the internal structure of the system, its
hardware configuration, or more generally, how the
system should be realized.
– System design is the first step in this direction.
• The design goals are derived from the nonfunctional
requirements. Design goals guide the decisions to be
made by the developers when trade-offs are needed.

04/17/2025 KMU - OOD 16

System Design Concepts
Subsystems and Classes

• 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,” which are made of a number of solution
domain classes.
• A subsystem is a replaceable part of the system with
well-defined interfaces that encapsulates the state and
behavior of its contained classes.
– This subsystem decomposition is depicted using UML components.

04/17/2025 KMU - OOD 17

 – Dependencies among components can be depicted with
dashed stick arrows.
– In UML, components can represent both logical and
physical components.
• A logical component corresponds to a subsystem that has no
explicit run-time equivalent, for example, individual business
components that are composed together into a single run-time
application logic layer.
• A physical component corresponds to a subsystem that has an
explicit run-time equivalent, for example, a database server .

04/17/2025 KMU - OOD 18

Services and Subsystem Interfaces

– A subsystem is characterized by the services it provides to

other subsystems.
– Service: A set of related operations that share a common
purpose
• A subsystem providing Notification service: defines operations to
– LookupChannel()
– SubscribeToChannel()
– SendNotice()
– UnscubscribeFromChannel()
• Services are defined in System Design
– Subsystem Interface: Set of fully typed related operations ( i.e the
name of the operations, their parameters, their types, and their return values).
• Subsystem Interfaces are defined in Object Design
• Also called application programmer interface (API)

04/17/2025 KMU - OOD 19

Coupling and Cohesion

• Goal: Reduction of complexity while change occurs

• Cohesion measures the dependence among classes
– High cohesion: The classes in the subsystem perform similar tasks
and are related to each other (via associations)
– Low cohesion: Lots of miscellaneous and auxiliary classes, no
associations
• Coupling measures dependencies between subsystems
– High coupling: Changes to one subsystem will have high impact on
the other subsystem (change of model, massive recompilation, etc.)
– Low coupling: A change in one subsystem does not affect any other
subsystem
• Subsystems should have as maximum cohesion and minimum
coupling as possible:
– How can we achieve high cohesion?
– How can we achieve loose coupling?

04/17/2025 KMU - OOD 20

Partitions and Layers

• Partitioning and layering are techniques to achieve low

coupling.
• A large system is usually decomposed into subsystems using
both, layers and partitions.
• Partitions vertically divide a system into several independent
(or weakly-coupled) subsystems that provide services on the
same level of abstraction.
• A layer is a subsystem that provides subsystem services
to a higher layers (level of abstraction)
– A layer can only depend on lower layers
– A layer has no knowledge of higher layers

04/17/2025 KMU - OOD 21

 A: Subsystem Layer 1

B:Subsystem C:Subsystem D:Subsystem Layer 2

E:Subsystem F:Subsystem G:Subsystem Layer 3

Subsystem Decomposition into Layers

04/17/2025 KMU - OOD 22

Relationships between Subsystems

• Layer relationship
– Layer A “Calls” Layer B (runtime)
– Layer A “Depends on” Layer B (“make” dependency,
compile time)
• Partition relationship
– The subsystem have mutual but not deep knowledge
about each other
– Partition A “Calls” partition B and partition B “Calls”
partition A

04/17/2025 KMU - OOD 23

Software Architectural Styles

• Includes Subsystem decomposition

– Identification of subsystems, services, and their relationship
to each other.
• As the complexity of systems increases, the specification
of system decomposition is critical.
• Patterns for software architecture
– Client/Server Architecture
– Peer-To-Peer Architecture
– Repository Architecture
– Model/View/Controller Architecture
– Pipes and Filters Architecture
• several architectural styles that can be used as a basis for the
architecture of different systems
04/17/2025 KMU - OOD 24
Client/Server Architectural Style
• One or many servers provides services to instances of
subsystems, called clients.
• Client calls on the server, which performs some service
and returns the result
– Client knows the interface of the server (its service)
– Server does not need to know the interface of the client
• Response in general immediately
• Users interact only with the client
Server

* *
Client
requester provider service1()
service2()
…
serviceN()

04/17/2025 KMU - OOD 25

• The request for a service is usually done via a remote procedure
call mechanism or a common object broker (e.g., CORBA, Java
RMI, or HTTP). Control flow in the clients and the servers is
independent except for synchronization to manage requests or to
receive results.
• Clients request services from one or more Servers. The Server
has no knowledge of the Client.
• An information system with a central database is an example of a
client/server architectural style.
• The clients are responsible for receiving inputs from the user,
performing range checks, and initiating database transactions
when all necessary data are collected.
• The server is then responsible for performing the transaction and
guaranteeing the integrity of the data.

04/17/2025 KMU - OOD 26

 The Web as an instance of the client/server architectural style (UML
deployment diagram).

•Client/server architectural styles are well suited for distributed

systems that manage large amounts of data.

04/17/2025 KMU - OOD 27

Cont’d
• Often used in database systems:
– Front-end: User application (client)
– Back end: Database access and manipulation (server)
• Functions performed by client:
– Customized user interface
– Front-end processing of data
– Initiation of server remote procedure calls
– Access to database server across the network
• Functions performed by the database server:
– Centralized data management
– Data integrity and database consistency
– Database security
– Concurrent operations (multiple user access)
– Centralized processing (for example archiving)

04/17/2025 KMU - OOD 28

 Design Goals for Client/Server Systems
• Service Portability
– Server can be installed on a variety of machines and operating
systems and functions in a variety of networking environments
• Transparency, Location-Transparency
– The server might itself be distributed (why?), but should provide a
single "logical" service to the user
• Performance
– Client should be customized for interactive display-intensive tasks
– Server should provide CPU-intensive operations
• Scalability
– Server should have spare capacity to handle larger number of clients
• Flexibility
– The system should be usable for a variety of user interfaces and end
devices (eg. WAP Handy, wearable computer, desktop)
• Reliability
– System should survive node or communication link problems

04/17/2025 KMU - OOD 29

 Problems with Client/Server Architectural
Styles

• Layered systems do not provide peer-to-peer

communication
• Peer-to-peer communication is often needed
• Example: Database receives queries from application
but also sends notifications to application when data
have changed

04/17/2025 KMU - OOD 30

Three-tier Client/Server Architecture

• The three-tier architectural style organizes subsystems

into three layers
– The interface layer includes all boundary objects that deal with
the user, including windows, forms, web pages, and so on.
– The application logic layer includes all control and entity
objects, realizing the processing, rule checking, and notification
required by the application.
– The storage layer realizes the storage, retrieval, and query of
persistent objects.

04/17/2025 KMU - OOD 31

 • Three-tier architectural style (UML component diagram).
•Objects are organized into three layers realizing the user interface, the
processing, and the storage.

04/17/2025 KMU - OOD 32

Peer-to-Peer Architectural Style
• Generalization of Client/Server Architecture
• Clients can be servers and servers can be clients
• More difficult because of possibility of deadlocks
requester
Peer
*

service1()
service2() *
…
serviceN() provider

1. updateData
application1:DBUser

database:DBMS

application2:DBUser
2. changeNotification

04/17/2025 KMU - OOD 33

Repository Architectural Style

• In the repository architectural style, subsystems access

and modify a single data structure called the central
repository.
– Subsystems access and modify data from a single data structure
• Subsystems are relatively independent and interact only
through the repository.
– Subsystems are loosely coupled (interact only through the
repository)
• Control flow is dictated by central repository (triggers) or
by the subsystems (locks, synchronization primitives)

04/17/2025 KMU - OOD 34

 •Repositories are typically used for database management systems,
such as a payroll system or a bank system.
•The central location of the data makes it easier to deal with
concurrency and integrity issues between subsystems.

Repository architectural style (UML component diagram)

04/17/2025 KMU - OOD 35
• The repository subsystem can also be used for implementing
the global control flow.
• In the compiler, each individual tool (e.g., the compiler, the
debugger, and the editor) is invoked by the user.
• The repository only ensures that concurrent accesses are
serialized.
• Once a central repository is well defined, we can easily add
new services in the form of additional subsystems.
• The main disadvantage of repository systems is that the
central repository can quickly become a bottleneck, both from
a performance aspect and a modifiability aspect.
• The coupling between each subsystem and the repository is
high, thus making it difficult to change the repository without
having an impact on all subsystems.
04/17/2025 KMU - OOD 36
 Examples of Repository Architectural Style
Compiler

SemanticAnalyzer
SyntacticAnalyzer
Optimizer

LexicalAnalyzer CodeGenerator

• Hearsay II speech Repository

understanding system
(“Blackboard architecture”) ParseTree SymbolTable

• Database Management
Systems
• Modern Compilers SourceLevelDebugger SyntacticEditor

04/17/2025 KMU - OOD 37

Model/View/Controller Architectural Style
• Subsystems are classified into 3 different types
– Model subsystem: Responsible for application domain knowledge
– View subsystem: Responsible for displaying application domain
objects to the user
– Controller subsystem: Responsible for managing sequence of
interactions with the user and notifying views of changes in the
model.
• MVC is a special case of a repository architecture:
– Model subsystem implements the central datastructure, the
Controller subsystem explicitly dictate the control flow

initiator
Controller
* 1 repository
Model
1 notifier
subscriber
View
*
04/17/2025 KMU - OOD 38
• The Controller gathers input from the user and sends
messages to the Model.
• The Model maintains the central data structure.
• The Views display the Model and are notified (via a
subscribe/notify protocol) whenever the Model is changed.
• MVC is well suited for interactive systems, especially when
multiple views of the same model are needed.
• MVC can be used for maintaining consistency across
distributed data

04/17/2025 KMU - OOD 39

 Pipe and Filter Architectural Style

• In the pipe and filter architectural style, subsystems process

data received from a set of inputs and send results to other
subsystems via a set of outputs.
• The subsystems are called “filters,” and the associations
between the subsystems are called “pipes.”
• Each filter knows only the content and the format of the data
received on the input pipes, not the filters that produced
them. Each filter is executed concurrently, and
synchronization is accomplished via the pipes.
• The pipe and filter architectural style is modifiable: filters can
be substituted for others or reconfigured to achieve a
different purpose.

04/17/2025 KMU - OOD 40

 – A Filter can have many inputs and outputs. A Pipe connects one of the outputs of
a Filter to one of the inputs of another Filter.
• Pipe and filter styles are suited for systems that apply
transformations to streams of data without intervention by
users.
• They are not suited for systems that require more complex
interactions between components, such as an information
management system or an interactive system.

04/17/2025 KMU - OOD 41

 System Design Activities: From Objects to
Subsystems

• System design consists of transforming the analysis

model into the design model that takes into account the
nonfunctional requirements described in the
requirements analysis document.
– Identifying Design Goals
– Identifying Subsystems
– Refine the subsystem decomposition

04/17/2025 KMU - OOD 42

1. Identifying Design Goals

• The definition of design goals is the first step of system

design.
• It identifies the qualities that our system should focus on.
• Many design goals can be inferred from the nonfunctional
requirements or from the application domain. Others will
have to be elicited from the client.
• It is, however, necessary to state them explicitly such that
every important design decision can be made consistently
following the same set of criteria

04/17/2025 KMU - OOD 43

 Cont’d

• In general, we can select design goals from a long list of

highly desirable qualities.
• The possible number of design criteria’s are organized
into five groups: performance, dependability, cost,
maintenance, and end user criteria
• Performance, dependability, and end user criteria are
usually specified in the requirements or inferred from the
application domain.
• Cost and maintenance criteria are dictated by the
customer and the supplier.

04/17/2025 KMU - OOD 44

• Performance criteria include the speed and space
requirements imposed on the system.
– Should the system be responsive, or should it accomplish a
maximum number of tasks?
– Is memory space available for speed optimizations, or should
memory be used sparingly?

Design criterion Definition

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

Throughput How many tasks can the system accomplish in a

fixed period of time?

Memory How much space is required for the system to run?

04/17/2025 KMU - OOD 45

• Dependability criteria determine how much effort
should be expended in minimizing system crashes and
their consequences.
– How often can the system crash? How available to the user
should the system be? Should the system tolerate errors and
failures? Are security risks associated with the system
environment? Are safety issues associated with system
crashes?

04/17/2025 KMU - OOD 46

• Cost criteria include the cost to develop the system, to
deploy it, and to administer it.
– Note that cost criteria not only include design considerations but
managerial ones, as well.

04/17/2025 KMU - OOD 47

• Maintenance criteria determine how difficult it is to
change the system after deployment.

04/17/2025 KMU - OOD 48

• End user criteria include qualities that are desirable
from a users’ point of view, but have not yet been
covered under the performance and dependability
criteria.
– Is the software difficult to use and to learn? Can the users
accomplish needed tasks on the system?

04/17/2025 KMU - OOD 49

• When defining design goals, only a small subset of these
criteria can be simultaneously taken into account.
• Typically, developers need to prioritize design goals and
trade them off against each other as well as against
managerial goals as the project runs behind schedule or
over budget.
• Typical Design Trade-offs
– Functionality vs. Usability
– Cost vs. Robustness
– Efficiency vs. Portability
– Rapid development vs. Functionality
– Cost vs. Reusability
– Backward Compatibility vs. Readability

04/17/2025 KMU - OOD 50

04/17/2025 KMU - OOD 51
2. Identifying Subsystems

• Finding subsystems during system design is similar to

finding objects during analysis.
• Subsystem decomposition is constantly revised whenever
new issues are addressed: several subsystems are merged
into one subsystem, a complex subsystem is split into parts,
and some subsystems are added to address new
functionality.
• The initial subsystem decomposition should be derived from
the functional requirements.

04/17/2025 KMU - OOD 52

Cont’d
• Subsystem (UML: Package)
– Collection of classes, associations, operations, events and
constraints that are interrelated
– Seed for subsystems: UML Objects and Classes.
• (Subsystem) Service:
– Group of operations provided by the subsystem
– Seed for services: Subsystem use cases
• Service is specified by Subsystem interface:
– Specifies interaction and information flow from/to
subsystem boundaries, but not inside the subsystem.
– Should be well-defined and small.
– Often called API: Application programmer’s interface, but
this term should used during implementation, not during
System Design

04/17/2025 KMU - OOD 53

• In order for this to be possible developers need to
address system-wide issues when decomposing the
system.
• In particular, they need to address the following issues:
– Hardware/Software Mapping
– Persistent Data Management
– Global Resource Handling and Access Control
– Software Control
– Boundary Conditions

04/17/2025 KMU - OOD 54

 The activities of system design
04/17/2025 KMU - OOD 55
 3. Hardware Software Mapping

• This activity addresses two questions:

– How shall we realize the subsystems: Hardware or
Software?
– How is the object model mapped on the chosen
hardware & software?
• Mapping Objects onto Reality: Processor, Memory,
Input/Output
• Mapping Associations onto Reality: Connectivity
• Much of the difficulty of designing a system comes from
meeting externally-imposed hardware and software
constraints.
– Certain tasks have to be at specific locations
04/17/2025 KMU - OOD 56
• Mapping the Objects
– Processor issues:
• Is the computation rate too demanding for a single processor?
• Can we get a speedup by distributing tasks across several
processors?
• How many processors are required to maintain steady state
load?
– Memory issues:
• Is there enough memory to buffer bursts of requests?
– I/O issues:
• Do you need an extra piece of hardware to handle the data
generation rate?
• Does the response time exceed the available communication
bandwidth between subsystems or a task and a piece of
hardware?

04/17/2025 KMU - OOD 57

 Drawing Hardware/Software Mappings in UML

• System design must model static and dynamic structures:

– Component Diagrams for static structures
• show the structure at design time or compilation time
– Deployment Diagram for dynamic structures
• show the structure of the run-time system
• Note the lifetime of components
– Some exist only at design time
– Others exist only until compile time
– Some exist at link or runtime

04/17/2025 KMU - OOD 58

 Component Diagram

• Component Diagram
– A graph of components connected by dependency
relationships.
– Shows the dependencies among software components
• source code, linkable libraries, executables
• Dependencies are shown as dashed arrows from the client
component to the supplier component.
– The kinds of dependencies are implementation language
specific.
• A component diagram may also be used to show
dependencies on a façade:
– Use dashed arrow the corresponding UML interface.

04/17/2025 KMU - OOD 59

 Component Diagram Example

Scheduler reservations

UML Component
UML Interface

Planner update

GUI

04/17/2025 KMU - OOD 60

 Deployment Diagram

• Deployment diagrams are useful for showing a system

design after the following decisions are made
– Subsystem decomposition
– Concurrency
– Hardware/Software Mapping

• A deployment diagram is a graph of nodes connected by

communication associations.
– Nodes are shown as 3-D boxes.
– Nodes may contain component instances.
– Components may contain objects (indicating that the object is
part of the component)

04/17/2025 KMU - OOD 61

 Deployment Diagram Example

•A UML deployment diagram representing the allocation of components to

different nodes.
•Web browsers on PCs and Macs can access a WebServer that provides
information from a Database.

04/17/2025 KMU - OOD 62

• The above diagram, depicts an example of a deployment
diagram with two Web browsers accessing a Web
server.
• The Web server in turns accesses a database server.
• We can see from the diagram that the Web browsers do
not directly access the database at any time.

04/17/2025 KMU - OOD 63

 4. Data Management
• Some objects in the system model need to be persistent:
– Values for their attributes have a lifetime longer than a single
execution
• A persistent object can be realized with one of the following
mechanisms:
– Data structure
• If the data can be volatile
– File system:
• If the data are used by multiple readers but a single writer
• Cheap, simple, permanent storage
• Low level (Read, Write) and Applications must add code to provide
suitable level of abstraction
– Database:
• If the data are used by concurrent writers and readers.
• Powerful, easy to port and Supports multiple writers and readers
04/17/2025 KMU - OOD 64
• File or Database?
– When should you choose a file?
• Are the data voluminous (bit maps)?
• Do you have lots of raw data (core dump, event trace)?
• Do you need to keep the data only for a short time?
• Is the information density low (archival files, history logs)?
– When should you choose a database?
• Do the data require access at fine levels of details by multiple
users?
• Must the data be ported across multiple platforms
(heterogeneous systems)?
• Do multiple application programs access the data?
• Does the data management require a lot of infrastructure?

04/17/2025 KMU - OOD 65

• Object-Oriented Databases
– Support all fundamental object modeling concepts
• Classes, Attributes, Methods, Associations, Inheritance
– Mapping an object model to an OO-database
• Determine which objects are persistent.
• Perform normal requirement analysis and object design
• Create single attribute indices to reduce performance
bottlenecks
• Do the mapping (specific to commercially available product).
Example:
– In Object Store, implement classes and associations by
preparing C++ declarations for each class and each
association in the object model

04/17/2025 KMU - OOD 66

• Mapping Object Models
– UML object models can be mapped to relational
databases
– The mapping:
• Each class is mapped to its own table
• Each class attribute is mapped to a column in the table
• An instance of a class represents a row in the table
• One-to-many associations are implemented with a buried
foreign key
• Many-to-many associations are mapped to their own tables
– Methods are not mapped

04/17/2025 KMU - OOD 67

5. Global Resource Handling

• Discusses access control

• Describes access rights for different classes of actors
• Describes how object guard against unauthorized
access
• Defining Access Control

04/17/2025 KMU - OOD 68

• Defining Access Control
– In multi-user systems different actors have access to
different functionality and data.
• During analysis we model these different accesses
by associating different use cases with different
actors.
• During system design we model these different
accesses by examing the object model by
determining which objects are shared among actors.
– Depending on the security requirements of the
system, we also define how actors are authenticated
to the system and how selected data in the system
should be encrypted.

04/17/2025 KMU - OOD 69

 6. Decide on Software Control
• Centralized control:
– Procedure-driven: Control resides within program code.
• Simple, easy to build, hard to maintain (high recompilation
costs)
– Event-driven: Control resides within a dispatcher calling
functions via callbacks.
• Very flexible, good for the design of graphical user
interfaces, easy to extend
• Decentralized control
– Control resides in several independent objects.
• Examples: Message based system, RMI
– Possible speedup by mapping the objects on different
processors, increased communication overhead .

04/17/2025 KMU - OOD 70

Centralized vs. Decentralized Designs
• Should you use a centralized or decentralized design?
– Take the sequence diagrams and control objects from the
analysis model
– Check the participation of the control objects in the
sequence diagrams
• If sequence diagram looks more like a fork: Centralized design
• The sequence diagram looks more like a stair: Decentralized design
• Centralized Design
– One control object or subsystem ("spider") controls
everything
• Pro: Change in the control structure is very easy
• Con: The single control object is a possible performance bottleneck
• Decentralized Design
– Not a single object is in control, control is distributed, That
means, there is more than one control object
• Con: The responsibility is spread out
• Pro: Fits nicely into object-oriented development
04/17/2025 KMU - OOD 71
 7. Boundary Conditions
• Most of the system design effort is concerned with steady-state
behavior.
• However, the system design phase must also address the initiation and
finalization of the system. This is addressed by a set of new uses cases
called administration use cases
– Initialization
• Describes how the system is brought from an non initialized
state to steady-state ("startup use cases”).
– Termination
• Describes what resources are cleaned up and which systems
are notified upon termination ("termination use cases").
– Failure
• Many possible causes: Bugs, errors, external problems (power
supply).
• Good system design foresees fatal failures (“failure use cases”).
04/17/2025 KMU - OOD 72
• Example: Administrative Use cases for MyTrip
– Administration use cases for MyTrip (UML use case
diagram).
– An additional subsystems that was found during
system design is the server. For this new subsystem
we need to define use cases.
– ManageServer includes all the functions necessary to
start up and shutdown the server.

04/17/2025 KMU - OOD 73

 ManageServer Use Case

<<include>>

StartServer
PlanningService
Administrator <<include>>

ManageServer ShutdownServer

<<include>>

ConfigureServer

04/17/2025 KMU - OOD 74

Boundary Condition Questions
• Initialization
– How does the system start up?
• What data need to be accessed at startup time?
• What services have to registered?
– What does the user interface do at start up time?
• How does it present itself to the user?
• Termination
– Are single subsystems allowed to terminate?
– Are other subsystems notified if a single subsystem terminates?
– How are local updates communicated to the database?
• Failure
– How does the system behave when a node or communication link
fails? Are there backup communication links?
– How does the system recover from failure? Is this different from
initialization?
04/17/2025 KMU - OOD 75
Modeling Boundary Conditions

• Boundary conditions are best modeled as use cases with

actors and objects.
• Actor: often the system administrator
• Interesting use cases:
– Start up of a subsystem
– Start up of the full system
– Termination of a subsystem
– Error in a subystem or component, failure of a
subsystem or component
• Task:
– Model the startup of the ARENA system as a set of use
cases.
04/17/2025 KMU - OOD 76
Managing System Design

• The software architecture and the system interfaces

should describe a single cohesive system understandable
by a single person.
• We first describe a document template that can be used to
document the results of system design
• System design is documented in the System Design
Document (SDD).

04/17/2025 KMU - OOD 77

 Documenting System Design
• System design is documented in the System Design Document
(SDD).
• It describes design goals set by the project, subsystem
decomposition (with UML class diagrams), hardware/software
mapping (with UML deployment diagrams), data management,
access control, control flow mechanisms, and boundary
conditions.
• The SDD is used to define interfaces between teams of
developers and serve as a reference when architecture-level
decisions need to be revisited.
• The audience for the SDD includes the project management, the
system architects (i.e., the developers who participate in the
system design), and the developers who design and implement
• each subsystem
04/17/2025 KMU - OOD 78
 System Design Document Sample Template

1. Introduction 3. Proposed software architecture

1.1 Purpose of the system 3.1 Overview
1.2 Design goals 3.2 Subsystem decomposition
1.3 Definitions, acronyms, and 3.3 Hardware/software mapping
abbreviations 3.4 Persistent data management
3.5 Access control and security
1.4 References
3.6 Global software control
1.5 Overview
3.7 Boundary conditions
2. Current software architecture
4. Subsystem services
Glossary

04/17/2025 KMU - OOD 79

Summary
In this activity, we reviewed the activities of system design:
• Design goals
• Subsystem decomposition
• Concurrency
• Hardware/Software mapping
• Persistent data management
• Global resource handling
• Software control selection
• Boundary conditions
Each of these activities revises the subsystem decomposition
to address a specific issue.
Once these activities are completed, the interface of the
subsystems can be defined.

04/17/2025 KMU - OOD 80

 Summary

• Each of these activities may affect the subsystem decomposition

• Two new UML Notations
– UML Component Diagram: Showing compile time and
runtime dependencies between subsystems
– UML Deployment Diagram: Drawing the runtime
configuration of the system.

04/17/2025 KMU - OOD 81

 Object Model

04/17/2025 KMU - OOD 82