Activity#6: Object Oriented Design/OOD

• Overview of system Design

• System Design Activities
•Managing System Design
Learning Outcomes

• In this activity, you should be able to define and

understand
– What Object Oriented Design is
– Describe system design
– System Design Concepts
– The System Design Activities: From Objects to
Subsystems

Compiled By: BDU, OOD 2

Introduction

• 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
Intro…
• 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.
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
 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.
 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
 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
 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
Connectivity Security
• System design is decomposed into several activities,
each addressing part of the overall problem of
decomposing the system:
– Identify design goals. Developers identify and prioritize the
qualities of the system that they should optimize.
– Design the initial subsystem decomposition. Developers
decompose the system into smaller parts based on the use case
and analysis models. Developers use standard architectural
styles as a starting point during this activity.
– Refine the subsystem decomposition to address the design
goals. The initial decomposition usually does not satisfy all design
goals. Developers refine it until all goals are satisfied.
 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
• 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.
The activities of system design
System Design Concepts

• In this section, we describe subsystem decompositions and

their properties in more detail
– First, we define the concept of subsystem and its relationship to
classes
– Subsystem services and interfaces
– Two properties of subsystems, coupling and cohesion
– look at layering and partitioning, two techniques for relating
subsystems to each other
– describe a number of typical software architectures styles that are
found in practice.
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.
– 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.
Subsystem decomposition for an accident management system
(UML component diagram)
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)
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?
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
 A: Subsystem Layer 1

B:Subsystem C:Subsystem D:Subsystem Layer 2

E:Subsystem F:Subsystem G:Subsystem Layer 3

Subsystem Decomposition into Layers

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
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
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()
• 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.
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.
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)
 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
 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
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.
• Three-tier architectural style (UML component diagram).
•Objects are organized into three layers realizing the user interface, the
processing, and the storage.
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() *
…
provider
serviceN()

1. updateData
application1:DBUser

database:DBMS

application2:DBUser
2. changeNotification
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)
•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)

• 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.
 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
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
*
• 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
 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.
 – 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.
 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
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
 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.
• 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?

• 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?
• 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.
• Maintenance criteria determine how difficult it is to
change the system after deployment.
• 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?
• 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
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.
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
• Heuristics for grouping objects into subsystems
– Assign objects identified in one use case into the same
subsystem.
– Create a dedicated subsystem for objects used for
moving data among subsystems.
– Minimize the number of associations crossing subsystem
boundaries.
– All objects in the same subsystem should be functionally
related.
System Design: Addressing Design Goals
• During system design, we identify design goals, decompose
the system into subsystems, and refine the subsystem
decomposition until all design goals are addressed.
• system design is a highly iterative activity that likely results
in the identification of new subsystems, the modification of
existing subsystems, and system-wide revisions that impact
all subsystems.
• Design goals guide the decisions to be made by the
developers especially when trade-offs are needed.
• Developers divide the system into manageable pieces to
deal with complexity: each subsystem is assigned to a team
and realized independently.
• 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
The activities of system design
 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
• 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?
 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
 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.
 Component Diagram Example

Scheduler reservations

UML Component
UML Interface

Planner update

GUI
 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)
 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.
• 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.
 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
• 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?
• 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
• 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
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
• 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.
 6. Decide on Software Control
• Two major design choices:
– Choose implicit control (non-procedural, declarative languages)
• Rule-based systems
• Logic programming
– Choose explicit control (procedural languages): Centralized or
decentralized
• 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.
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
 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”).
• 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.
 ManageServer Use Case

<<include>>

StartServer
PlanningService
Administrator <<include>>

ManageServer ShutdownServer

<<include>>

ConfigureServer
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?
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.
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).
 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
 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
Summary
In this activity, we reviewed the activities of system design:
• Design goals
• Subsystem decomposition
• 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.
 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.
The End!