v 8 September 1994

15-413

Lecture Notes on
System Design

Bernd Bruegge
School of Computer Science
Carnegie Mellon University
Pittsburgh PA 15213

8 & 13 October 1998

Bernd Bruegge 15-413 Software Engineering 1 2

Outline of the Lecture

v Odds and Ends:

w Requirements Analysis Tasks
w RAD Submission Process
w Project Calendar for October
w Presentations
v System Design

Bernd Bruegge 15-413 Software Engineering 2

Collaborative Requirements Analysis
v The PAID system is a collection of applications and
services
v Team level analysis of applications and services are
provided by User Interface, Network, Authentication,
Learning and Database.
v Each team writes a requirements analysis document from
the perspective of their subsystem.
v The architecture team and the documentation team are
responsible for the RAD integration and documentation.

Bernd Bruegge 15-413 Software Engineering 3

RAD Schedule
ü 9/15 Release of Template (project management)
ü Each team works on the RAD for their subsystem
ü 9/30 Team RADs are due (teams)
ü Project management reviews the team RADs
ü 10/5 Reviews are due (project management)
àTeams incorporate review comments
v 10/10 Second revision of team RADs due (teams)
v 10/15 Integrated version of RAD (architecture team,
documentation team)

Bernd Bruegge 15-413 Software Engineering 4

RAD Model Integration
v All models must be submitted in Together/J.
v Each model description must follow the model
documentation standard
w UML Notation
w Navigation text for each model
v Task of the Architecture and Documentation team is to
integrate the individual system modules and identify
problems with consistency, completeness and
ambiguities. If these problems are not solvable during the
integration they will be discussed and identified during the
analysis review (Oct 22 & 27)

Bernd Bruegge 15-413 Software Engineering 5

Typical RAD Problems

v Consistency problems:
w Different signatures by method provider and method user
v Completeness problems:
w Dangling associations (associations pointing to nowhere)
w Double defined classes
w Missing classes (imported by one module but not defined
anywhere)
v Ambiguity problems:
w Entities referred to in more than one of the models are not
identical
w Names are spelled differently in different models or within the
same model
w Classes in different subsystems have the same name but different
meanings

Bernd Bruegge 15-413 Software Engineering 6

Presentation Schedule

v Presentations
w Analysis Review: Oct 22 & 27, 9:00-10:20am
w System Design Review: Nov 11, 9:00-10:20am
w Object Design & Implementation Review: Nov 24
w Client Acceptance Test: Dec 10 (precise date to be announced)
v Speakers:
w 5-6 Speakers per Review
w 15-20 minute presentations
w Every student will have to give one presentation
w Scheduling and elicitation of speakers on the announce bboard

Bernd Bruegge 15-413 Software Engineering 7

Analysis Review Agenda
v Review will be run as a meeting
v Primary facilitator & Minute taker (2 Coaches)
v Project Management (1 Speaker, 15 minutes)
w Problem statement and global requirements
w Project Management issues & Process model for PAID Project
v Subsystem presentations (5 Speakers, 15 minutes each)
w Go through one or two use cases
w Show object diagram for subsystem (class hierarchy if it exists)
w Present illustrative prototype for user interface
w Present state diagrams for objects with important dynamic
behavior
v Discussion (15 minutes)
v Identification of Action Items (5 minutes)

Bernd Bruegge 15-413 Software Engineering 8

Project Calendar
October 1998
Thu Fri Sat Sun Mon Tue Wed
1 2 3 4 5 6 7
Project
Mgt RAD
Review Due

8 9 10 11 12 13 14
System Design
Design I Second Rev Patterns,
System Design II Team RADs Gamma, Ch. 1
SDD template due

15 16 17 18 19 20 21
Prototyping
RAD Integration RAD Review
Design
Due Presentation
Patterns II
Deadline
22 23 24 25 26 27 28
Analysis
Analysis Review
Review
SDD Due

29 30 31 1 2 3 4
Unit Testing
Database
Management Test Manual
Template Out

Bernd Bruegge 15-413 Software Engineering 9

Advice for presentations
v Present the global picture
v Project Management
w Is our communication structure working?
u How is the communication with the client?
u Communication with management?
u Intergroup communication
u How about the architecture meetings, project meetings?
u How about the bulletin boards?
w What can be improved?
w Anything wrong with the phases (Planning, Analysis, Design,
Implementation,....)?
w Is iteration working?
w Is our incremental process working?

Bernd Bruegge 15-413 Software Engineering 10

Presentation of PAID Subsystems

v Services (Sets of methods provided by PAID subsystems)

w Services provided by your subsystem
w Services needed by other subsystems
w Any mismatch between "needed from others" and "provided by
you"?
w Services needed from other subsystems but not yet provided by
them
v Analysis Models (Functional, Object and Dynamic
Models needed to explain subsystem)
v Design and Implementation Issues
w Nonfunctional and constraints (pseudo requirements)

Bernd Bruegge 15-413 Software Engineering 11

Miscellaneous Presentation Advice

v Dry-run (send e-mail to [email protected] if you want

to schedule a meeting)
w Discussion of presentation techniques
w Tools for presentations
v There is no winner or looser

Bernd Bruegge 15-413 Software Engineering 12

Design

v There are two ways of constructing a software design:

One way is to make it so simple that there are obviously
no deficiencies, and the other way is to make it so
complicated that there are no obvious deficiencies.
– C.A.R. Hoare

Bernd Bruegge 15-413 Software Engineering 13

Why is Design so Difficult?

v Analysis: Concentrates the application domain

v Design: Has to worry about the implementation domain
w Design knowledge is a moving target
w The reasons for design decisions are changing very rapidly
u Halftime knowledge in software engineering: About 3-5 years
u What I teach today will be out of date in 3 years
u Cost of hardware rapidly sinking
v “Design window”:
w Time in which design decisions have to be made

Bernd Bruegge 15-413 Software Engineering 14

Outline of the next two classes

1. Design Goals
2. Subsystem decomposition
3. Identify concurrency
4. Allocate subsystems to processors
5. Specify management of data
6. Identify global resources and access methods
7. Define control
8. Define boundary conditions
System Architecture Patterns
System Design Template

Bernd Bruegge 15-413 Software Engineering 15

System Design
System Achitecture

1. Design Goals 9. Design

Definition Rationale
Trade-offs
8. Software
2. System Control
Decomposition
Layers 7. Boundary
Partition
Topology Conditions
Initialization
Termination
3. Concurrency Failure
Thread 6. Global
identification
4. Hardware/ 5. Data
Software Resources
Mapping Management
Access control
Data structures
Special purpose
Trade-offs Files
Databases
Allocation
Connectivity

Bernd Bruegge 15-413 Software Engineering 16

How to use the results from the Requirements
Analysis for System Design

v Nonfunctional Requirements =>

w Chapter 1: Design Goals
v Use Case Model =>
w Chapter 2: System decomposition (Based on functionality)
v Object Model =>
w Chapter 4: Hardware/software mapping
w Chapter 5: Data management
v Dynamic Model =>
w Chapter 3: Identification of concurrency
w Chapter 6: Global resource handling
w Chapter 7: Software control
w Chapter 8: Boundary conditions

Bernd Bruegge 15-413 Software Engineering 17

Design Goals
(Analysis Phase: Nonfunctional requirements)
v Reliability v Good documentation
v Modifiability v Well-defined interfaces
v Maintainability v User-friendliness
v Understandability v Reuse of components
v Adaptability v Rapid development
v Reusability v Minimum # of errors
v Efficiency v Readability
v Portability v Ease of learning
v Traceability of requirements v Ease of remembering
v Fault tolerance v Ease of use
v Backward-compatibility v Increased productivity
v Cost-effectiveness v Low-cost
v Robustness v Flexibility
v High-performance

Bernd Bruegge 15-413 Software Engineering 18

Relationship Between Design Goals
End User
Low cost
Increased Productivity Functionality
Backward-Compatibility User-friendliness
Traceability of requirements Runtime
Ease of Use
Rapid development Efficiency Ease of learning
Flexibility Fault tolerant
Robustness
Reliability
Portability
Good Documentation
Client
(Customer,
Sponsor) Minimum # of errors
Modifiability, Readability
Reusability, Adaptability
Well-defined interfaces Developer/
Maintainer
Bernd Bruegge 15-413 Software Engineering 19
Typical Design Trade-offs

v Functionality vs. Usability

w Client vs. Developer
v Cost vs. Robustness
w Client vs. User
v Efficiency vs. Portability
w?
v Rapid development vs. Functionality
w?
v Cost vs. Reusability
w?
v Backward Compatibility vs. Readability
w?

Bernd Bruegge 15-413 Software Engineering 20

Nonfunctional Requirements lead to Design
Patterns
v Read the problem statement again
v Use textual clues (similar to Abbot’s technique in Analysis) to
identify design patterns
v Text: “manufacturer independent”, “device independent”, “must
support a family of products”
w Abstract Factory Pattern
v Text: “must interface with an existing object”
w Adapter Pattern
v Text: “must deal with the interface to several systems, some of them
to be developed in the future”, “ an early prototype must be
demonstrated”
w Bridge Pattern

Bernd Bruegge 15-413 Software Engineering 21

 Textual Clues in Nonfunctional Requirements
v Text: “complex structure”, “must have variable
depth and width”
w Composite Pattern
v Text: “must interface to an set of existing objects”
w Façade Pattern
v Text: “must be location transparent”
w Proxy Pattern
v Text: “must be extensible”, “must be scalable”
w Observer Pattern
v Text: “must provide a policy independent from the
mechanism”
w Strategy Pattern

Bernd Bruegge 15-413 Software Engineering 22

The Purpose of System Design

Problem

v Bridging the gap between

v
the desired and available
systems in a manageable
way
Use Divide and Conquer
w We model the new system
?
Subsystem
Decomposition

to be developed as a set of
subsystems

Hardware (or existing system)

Bernd Bruegge 15-413 Software Engineering 23
2. System Decomposition
v Subsystem (UML: Package)
w Collection of classes, associations, operations, events and
constraints that are interrelated
w Seed for subsystems: UML Objects and Classes.
v Service:
w Group of operations provided by the subsystem
w Seed for services: Subsystem use cases
v Service is specified by Subsystem interface:
w Specifies interaction and information flow from/to subsystem
boundaries, but not inside the subsystem.
w Should be well-defined and small.
w Often called API: Application programmer’s interface
u Use “Service” during system design,
u Use “API” during implementation

Bernd Bruegge 15-413 Software Engineering 24

Choosing Subsystems

v Criteria for subsystem selection: Most of the interaction

should be within subsystems, rather than across
subsystem boundaries.
w Client-Server: Does one subsystem always call the other for the
service?
w Peer-Peer: Which of the subsystems call each other for service?
v Primary: What kind of service is provided by the
subsystems (subsystem interface)?
v Secondary: Can the subsystems be hierarchically
ordered?
v What kind of model is good for describing layers and
partitions?

Bernd Bruegge 15-413 Software Engineering 25

Partitions and Layers

v A large system is usually decomposed into subsystems

using both, layers and partitions.
v Partitions vertically divide a system into several
independent (or weakly-coupled) subsystems that
provide services on the same level of abstraction.
v A layer is a subsystem that provides services to a higher
level of abstraction

Bernd Bruegge 15-413 Software Engineering 26

Relationships between subsystems

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

Bernd Bruegge 15-413 Software Engineering 27

Layering (Dijkstra, 1965)
v A system should be developed by an ordered set of
virtual machines, each built in terms of the ones below it.
Problem

C1
C1
attr attr
C1
attr
VM1
opr opr opr

C1 C1
attr attr VM2
opr opr

C1
C1
attr
attr VM3
opr
opr

C1
attr VM4
opr

Existing System
Bernd Bruegge 15-413 Software Engineering 28
Virtual Machine
v A virtual machine is a subsystem connected to higher
and lower level virtual machines by "provides services
for" associations.

v A virtual machine is an abstraction that provides a set of

attributes and operations.
v Virtual machines can implement two types of software
architecture: closed and open architectures.

Bernd Bruegge 15-413 Software Engineering 29

Opaque Architecture (Closed Layers)

C1
C1
attr
C1
VM1
attr attr

vA virtual machine can opr opr opr

only call operations C1

attr
C1
attr
opr
VM2

from the layer below

opr

C1
C1
attr VM3
v Design Goal: High
attr
opr
opr

Maintainability C1
attr
C1
attr
VM4
opr opr

Bernd Bruegge 15-413 Software Engineering 30

Transparent Architecture ( Open Layers)

vA virtual machine can

C1
C1
attr attr
C1
attr
VM1
opr opr opr

call operations from C1 C1

VM2
any layers below attr
opr
attr
opr

v Design Goal: Runtime

C1
C1
attr
attr VM3
opr

Efficiency
opr

C1 C1 VM4
attr attr
opr opr

Bernd Bruegge 15-413 Software Engineering 31

Properties of Layered & Partitioned Systems

v Decomposition reduces complexity of system (divide and

conquer)
v Closed architectures are more portable
v Open architectures are more efficient
v If a subsystem is a layer, it is usually called a virtual
machine
v Layered systems often have chicken-and egg problem
w Example: Debugger opening a file while debugging a file system

Bernd Bruegge 15-413 Software Engineering 32

Other relationships between subsystems
v Client-Server relationship (Also called Client-Supplier)
w Client calls server, who performs service and returns result
w Client knows the interface of the server (“its service”)
w Server does not need to know the interface of the client
w Response in general immediately
v Peer-to-Peer relationship
w Each of the subsystems may call on the others
w Response not necessarily immediate
w More complicated than client/server
u Deadlocks are possible: "Communication cycles”

Bernd Bruegge 15-413 Software Engineering 33

Client/Server Architecture
v Often used in database systems:
w Frontend: User application (client)
w Back end: Database access and manipulation (server)
v Functions performed by client:
w Customized user interface
w Front-end processing of data
w Initiation of server remote procedure calls
w Access to database server across the network
v Functions performed by the database server:
w Centralized data management
w Data integrity and database consistency
w Database security
w Concurrent operations (multiple user access)
w Centralized processing (for example archiving)
Bernd Bruegge 15-413 Software Engineering 34
Design Goals for Client/Server Systems
v Portability:
w Server can be installed on a v Expandability:
variety of machines and w Server has spare capacity
operating systems and to handle larger number of
functions in a variety of clients
networking environments v Flexibility:
v Transparency: w Should be usable for a
w The server might itself be variety of user interfaces
distributed (why?), but v Reliability
should provide a single
"logical" service to the user w System should survive
individual node and/or
v Performance: communication link
w Client should be problems
customized for interactive
display-intensive tasks
w Server should provide
CPU-intensive operations
Bernd Bruegge 15-413 Software Engineering 35
Properties of a Client/Server Architecture
v Consumer/Producer: v Message-based
w Client is a consumer of w Client and Servers are loosely
services, server is provider of coupled systems which
services interact through messages
v Shared resource v Encapsulation of services
w Server often regulates access w The client tells the server the
to a shared resource WHAT, the server knows
v Asymmetrical protocols HOW to do it.
w Many to one association v Scalability:
between clients and servers w Horizontal scalability:
Adding/Removing clients
v Transparency of location
w Vertical scalability: Migrating
w Client does not need to know
to larger or faster servers
the location of the server
v Mix and match v Integrity
w Server code and server data is
w Client and Servers can run on
centrally maintained:
different platforms
u Cheaper maintenance
u Higher security
Bernd Bruegge 15-413 Software Engineering 36
Middleware

v Definition: The distributed software needed to support

interactions between clients and servers.
w The Slash in Client/Server :-)
w The glue that ties all clients to all servers
v Middleware is becoming more and more a problem
because of the existence of multiple servers, muliple
vendors and multiple network.

Bernd Bruegge 15-413 Software Engineering 37

Middleware design problem

w Library approach: Add new middleware software on each client

whenever a new server appears
u Requires linking of new library and recompilation of clients.
u Clients become very large
w Server approach: Introduce a middleware service than handles
all communications with the servers. (Gateway server)
u Clients need to know only the protocol with the Gateway server
u “Older” clients can continue to communicate with server without
recompilation (as long as the gateway server is backward
compatible)

Bernd Bruegge 15-413 Software Engineering 38

Applications of Client/Server Architectures

v File Servers
w Client passes request for file over a network to the file server
w Useful for sharing files over a network
w Granularity supported by server:
u File
v Database Servers
w Client passes query to the server which finds the requested
data and send them back to the client
w Useful for decision support systems that require ad hoc queries
and flexible reports
w Granularity supported by server:
u Table, table entry

Bernd Bruegge 15-413 Software Engineering 39

Applications of Client/Server Architectures

v Transaction Servers
w Clients sends a transaction ( a series of logically connected queries)
to the server which executes it locally, and sends the return result.
w If one of the queries fails, the transaction fails
w Useful for online reservation systems (airline, banking, ...)
w Granularity supported by server: Table, table entry
v Groupware Servers
w Client passes information (post, file, cursor movement) to server
which stores them in a repository and notifies other clients.
w Useful for communication over space and/or time
w Granularity supported by server:
u Depends on groupware product (Lotus Notes: Files, Posts).

Bernd Bruegge 15-413 Software Engineering 40

Applications of Client/Server Architectures

v Object Servers
w Client invokes a remote method offered by a class residing on
a server
w Useful for heterogenous environments (multivendor,
multinetwork, multiplatform)
w Granularity supported by server:
u Objects

Bernd Bruegge 15-413 Software Engineering 41

Fat Clients vs Fat Servers

UI Application Data

Client Server

Data UI

UI Application

Application Data

Very Fat Client Very Fat Server

Bernd Bruegge 15-413 Software Engineering 42
Four Types of Client/Server Configurations

Middle
Client Server
Ware

v Single Machine v Multi Server

Configuration Configuration
w “Client/Server for tiny w “Client/Server for global
shops and nomadic tribes” enterprises”
w Everything on a single w Multiple Clients/Multiple
machine Servers
v Single Server v Peer-To-Peer Architecture
Configuration w Every machine is client and
w “Client/Server for small server
shops and departments”
w Multiple clients/Single
Server

Bernd Bruegge 15-413 Software Engineering 43

Single Machine Configuration

v “For tiny shops and

nomads”
v Association: One to One
w One Client, One Server
w Middleware: Could be as simple
as Procedure Call Client
v Hardware Mapping:
Middle
w Client and Server are running on Ware
the same machine.
v Administration: Nonexistent Server
problem
v Easy to use package
v Often done during system
integration testing
v Problem with response times
v Needs operating system support

Bernd Bruegge 15-413 Software Engineering 44

Single Server Configuration
v Client/Server for “small shops
and departments”
v Assocation: Many to One: Client
w Clients: Multiple clients
w Server: Single server (often a “local”
server)
w Middleware: Configuration file to
look up server’s name
Middle
v Hardware Mapping: Ware
LAN
w Clients and Servers on different
machines
v Administration: Easy (not an explicit
role, everybody does it)
v Failures: Easy to identify (either client
or server or wrong name in
Server
configuration file)
v 80% of today’s client/server
installations
Bernd Bruegge 15-413 Software Engineering 45
Multi Server Configuration
v For global enterprises
v Clients: Multiple clients
v Server: Mix of heterogenous Client
servers. Partitioned because of
w Function they provide
w Resource they control
w Database they own
w Fault tolerance Middle
WAN Ware
w High performance
v Middleware: CORBA, DCE,
ODBC
v Administration: Special role
v Failures: Not always obvious
Server

Bernd Bruegge 15-413 Software Engineering 46

Peer-to-Peer Configuration
Middle
v Every machine is both a client Client Server
Ware
and a server
v Middleware: RMI, CORBA,
DCE
v Network: WAN
v Administration: Difficult and
everybody has to do it
v Failures: Should be easy to Middle
identify with good middleware Ware
design

Middle
Client Server
Ware

Bernd Bruegge 15-413 Software Engineering 47

Peer-to-Peer Architectures….

v Peer-to-peer communication is often needed

w Example: Database receives queries from application but also
sends notifications to application when data have changed
w “Server” may specifiy user interface for example, by sending a
user interface to the client)
w Back-end processing of data is needed (filtering, aggregation,
forwarding)
v Most important in peer-to-peer architectures: Protocol
between subsystems
v PAID System Design issue:
w What are the "communication associations" between the
subsystems of PAID? (Who calls whom?)

Bernd Bruegge 15-413 Software Engineering 48

Peer-to-Peer Architecture and Notification

v Provision of push and pull

notification within the same
software architecture Peer
v Pull Notification Request()
w The client looks for certains
information by requesting it
explicitly from the server.
v Push Notification
w Events are modeled as an
inheritance hierarchy
w The client subscribes to an
event Client Server
w When a certain event occurs,
the server notifies all
subscribers

Bernd Bruegge 15-413 Software Engineering 49

Push/Pull Notification with an Event Service

Client

Event Service

Subscribers: List of Peer

Subscribe(Event JEvent)
UnSubscribe (Event JEvent)
Server Notify(Event JEvent)

Bernd Bruegge 15-413 Software Engineering 50

Choosing Subsystems

v Criteria for subsystem selection: Most of the interaction

should be within subsystems, rather than across
subsystem boundaries.
w Client-Server: Does one subsystem always call the other for the
service?
w Peer-Peer: Which of the subsystems call each other for service?
v Primary Question:
w What kind of service is provided by the subsystems (subsystem
interface)?
v Secondary Question:
w Can the subsystems be hierarchically ordered?
v What kind of model is good for describing layers and
partitions?

Bernd Bruegge 15-413 Software Engineering 51

Presentation of PAID as Peer-to-Peer
Architecture

UI

Authentication

Event Service
Network

Learning

Database

Bernd Bruegge 15-413 Software Engineering 52

Alternative Presentation of PAID with Software
Bus and Interface Objects
Event Service
User
Interface

Learning
Authentication

Database
Network

A SubsystemInterface Object publishes the service (= Set of public methods)

provided by the subsystem

Bernd Bruegge 15-413 Software Engineering 53

Definition: Subsystem Interface Object

v A Subsystem Interface Object publishes a service

w This is the set of public methods provided by the subsystem
w Interface specification describes all the methods of the interface
object

Bernd Bruegge 15-413 Software Engineering 54

PAID System as a set of services

PAID Services

Database
Interface
Object

Event Service
UI Interface
Interface Object
Object Authentication
Learning
Interface
Interface
Object
Object
Network
Interface
Object

Bernd Bruegge 15-413 Software Engineering 55

Example: JAMES Documentation
Subsystem Decomposition as navigatable Map
Notification
User
Interface

Travel
SDD
VIP

Logbook
Vehicle
ODD
Maintenance

A SubsystemInterface Object publishes the service (= Set of public methods)

provided by the subsystem

Bernd Bruegge 15-413 Software Engineering 56

3. Identify Concurrency
v Two objects are inherently concurrent if they can receive
events at the same time without interacting
w Inherently concurrent objects should be assigned to different
threads of control
v Goal: Find as many concurrent objects as possible =>
High Performance
v Definition:
w A thread of control is a path through a set of state diagrams on
which a single object is active at any time.
v Each thread control should have its on processor
(physically or logically)
v Objects with mutual exclusive activity should be folded
into a single thread of control (Why?)

Bernd Bruegge 15-413 Software Engineering 57

Concurrency Questions for PAID

v Which objects of the object model are independent?

w Describe the parallelism in PAID in terms of threads and
processes/processors
v Does the system provide access to multiple users?
w How many parallel users can the system have?
v How many databases does PAID have?
w Can a single "query" consists of multiple queries?

Bernd Bruegge 15-413 Software Engineering 58

4. Allocate Subsystems: Hardware or Software?

v Major part of the design problem:

w How is the object model mapped on the existing hardware&
software?
v Much of the difficulty of designing a system comes from
meeting externally-imposed hardware and software
constraints.
w The designer does not have full freedom

Bernd Bruegge 15-413 Software Engineering 59

Hardware/Software Allocation Questions
v What are the estimated performance needs?
w (# of transactions/sec * transaction_processing_time)
v What are the estimated hardware resource requirements?
w Number of processors depend on processing power required to
maintain steady state load
v Is the response time too slow? What can be done to
improve it?
w If load is too demanding for a single processor, consider a
speedup by distributing it across several processors.
v What is the connectivity among physical units (Dealer,
MLC, Headquarters)?
w Tree, star, matrix, ring
v What is the appropriate communication protocol between
the subsystems?
w Function of estimated bandwidth, latency and desired reliability)
Bernd Bruegge 15-413 Software Engineering 60
Hardware/Software Allocation Questions ctd
v Is certain functionality already available in hardware? (Smartcard)
v Do certain tasks require specific locations to control the hardware or
to permit concurrent operation? Often true for embedded systems
w Example: ATM machine
v General system performance questions:
w What is the desired response time?
w What is the expected transaction rate? (requests/sec)?
v I/O questions:
w Do you need an extra hardware to handle the data generation rate?
w Does the response time or information flow rate exceed the available
communication bandwidth between subsystems or a task and a piece
of hardware?
v Processor questions:
w Is the computation rate too demanding for a single processor?
v Memory questions:
w Is there enough memory to buffer bursts of requests?

Bernd Bruegge 15-413 Software Engineering 61

Connectivity (Associations)
v Describe the physical connectivity of the hardware
(Physical layer in ISO’s OSI Reference Model)
w Which associations in the object model are mapped to physical
connections?
w Which of the client-supplier relationships in the
analysis/design model correspond to physical connections?
v Describe the logical connectivity (software connections)
w Identify the logical connections that do not directly map into
physical connections:
u How are the logical connections implemented? By
procedure calls? Remote procedure calls?

Bernd Bruegge 15-413 Software Engineering 62

Connectivity in Distributed Systems

v If the architecture is distributed, we need to describe the

network architecture (communication subsystem) as
well:
w What are the transmission media?
w What kind of connection channels and communication
protocols are used?
w Is the interaction asynchronous, synchronous or blocking?
w What are the available bandwidth requirements
u User Interface <-> Database Subsystem?
u Event Service <-> All other PAID Subsystems?
u Learning Subsystem <-> Database Subsystem?

Bernd Bruegge 15-413 Software Engineering 63

Example of a Physical Connectivity Drawing
for a Distributed Database
Application Application Application
Client Client Client

Ethernet

Communication
Agent for
Application Clients WAN Global
Data
Communication Server
Communication
Backbone Network Agent for Data
Agent for What is the problem OODBMS
Server
Application Clients
With this drawing?
Communication Global
Agent for Data Data
Server Server
TCP/IP RDBMS

Local Data Global Data

Server Server

Bernd Bruegge 15-413 Software Engineering 64

 Physical vs Logical Connectivity
v ISO’s OSI Reference Model
w ISO = International Standard Organization
w OSI = Open System Interconnection
v Reference model defines 7 layers of network protocols and strict methods of
communication between the layers.
Application Application
Layer Layer
Presentation Presentation
Layer Layer
Session Session
Layer Layer
Bidirectional associa-
Transport tions for each layer Transport
Layer Layer
Network Network
Layer Layer
Data Link Data Link
Layer Layer

Hardware Hardware
Bernd Bruegge 15-413 Software Engineering 65
Logical vs Physical Connectivity and the
relationship to Subsystem Layering

Application Layer Application Layer

Presentation Layer Presentation Layer

Logical
Session Layer Connectivity
Session Layer
Bidirectional associa- Layers
tions for each layer
Transport Layer Transport Layer

Network Layer Network Layer

Data Link Layer Data Link Layer

Physical
Physical Layer Physical Layer Connectivity

Processor 1 Processor 2
Bernd Bruegge 15-413 Software Engineering 66
 Subsystem 1
Layer 1 Subsystem 2

Layer 2 Layer 1
Layer 3 Layer 2
Layer 4 Layer 3
Application Layer Application Layer

Presentation Layer Presentation Layer

Session Layer Session Layer

Bidirectional associa-
tions for each layer
Transport Layer Transport Layer

Network Layer Network Layer

Data Link Layer Data Link Layer

Hardware Hardware

Processor 1 Processor 2
Bernd Bruegge 15-413 Software Engineering 67
Another View at the ISO Model
Defines an object-oriented open software architecture
Each layer is a UML package containing a set of objects

“Protocoll Stacks” Application

Presentation Format

CORBA
Session Connection

Transport Message

TCP/IP Network Packet

DataLink Frame

Ethernet
TokenRing Physical Bit

Bernd Bruegge 15-413 Software Engineering 68

5. Management of Data

v Data Stores (Databases , files, ...) can provide clean

separation points between subsystems with well-defined
interfaces.
v A data store in general consists of
w Data structures
u Volatile
w Files
u Cheap, simple, permanent storage
u Low level, applications must have additional code to provide
suitable level of abstraction
w Data bases
u Powerful, easy to port
u Awkward interface with existing programming languages
u Functionality often insufficient (mostly developed for commercial
applications)

Bernd Bruegge 15-413 Software Engineering 69

File or Data base?

v When should you choose a file?

w Voluminous data (bit maps)
w Lots of raw data (core dump, event trace)
w Data needs to be kept only for a short time
w Low information density for archival files and history logs
v When should you choose a data base?
w Data requires access at fine levels of details by multiple users
w Data must be ported across multiple platforms (heterogeneous
systems)
w Data must be accessible by multiple application programs
w Data management requires a lot of infrastructure

Bernd Bruegge 15-413 Software Engineering 70

Data Management Questions
v Should the data be distributed?
v Should the database be extensible?
v What is the expected request (query) rate? In the worst case?
v How often is the database accessed?
v What is the size of typical requests (queries), worst case requests?
v Do the data need to be archived?
v Does the system design try to hide the location of the databases
(location transparency)?
v Is there a need for a single interface to access the data?
v What is the query format?
v Should the database be relational or object-oriented?

Bernd Bruegge 15-413 Software Engineering 71

6. Global Resources

v Discusses access control

v Describes access rights for different classes of actors
v Describes how object guard against unauthorized access

Bernd Bruegge 15-413 Software Engineering 72

Global Resource Questions

v Does the system need authentication?

v If yes, what is the authentication scheme?
w User name and password?
w Tickets?
v What is the user interface for authentication?
v Does the system have a network-wide name server?
v How is a service known to the rest of the system?
w At runtime? At compile time?
w By Port?
w By Name?

Bernd Bruegge 15-413 Software Engineering 73

7. Decide on Software Control
v Choose explicit control (procedural languages)
w Centralized control
u Procedure-driven control

–Control resides within program code.

Example: Main program calling procedures of
subsystems.
– Simple, easy to build

u Event-driven control
–Control resides within a dispatcher who calls
subsystem functions via callbacks.
– Flexible, good for user interfaces

Bernd Bruegge 15-413 Software Engineering 74

Software Control, ctd

w Decentralized control
u Control resided in several independent objects
(supported by some languages).
u Possible speedup by parallelization, increased
communication overhead.
u Example: Message based system.

v Or choose implicit control (non-procedural or

declarative languages)
w Rule-based systems
w Logic programming

Bernd Bruegge 15-413 Software Engineering 75

Procedure-Driven Control Example

module1 module2
op1()

module3
op2()
op3()

Bernd Bruegge 15-413 Software Engineering 76

Event-Based System Example: MVC

v Smalltalk-80 Model-View-Controller
v Client/Server Architecture

Control

Update View3
Model has changed
Update Update

Model View2
View1

Bernd Bruegge 15-413 Software Engineering 77

Centralized vs. Decentralized Designs

v Centralized Design
w One control object or subsystem ("spider") controls
everything
w Change in the control structure is very easy
w Possible performance bottleneck
v Decentralized Design
w Control is distributed
w Spreads out responsibility
w Fits nicely into object-oriented development
v Should PAID use a centralized or decentralized design?

Bernd Bruegge 15-413 Software Engineering 78

8. Boundary Conditions
v Most of the system design effort is concerned with
steady-state behavior.
v However, the system design phase must also address the
initiation and finalization of the system.
w Initialization
u Describes how the system is brought from an unitialized
state to steady-state ("startup scenario”).
w Termination
u Describes what resources are cleaned up and what tasks or
other systems are notified upon termination ("termination
scenarios").
w Failure
u Many possible causes: Bugs, errors, external problems
(power supply). Good system design foresees fatal failures.
Example: Catch Unix signals or Java Exceptions

Bernd Bruegge 15-413 Software Engineering 79

Boundary Condition Questions
v 9.1 Initialization
w How does the system start up?
u What data need to be accessed at startup time?

u What services have to registered?

w What does the user interface do at start up time?

u How does it present itself to the user?

v 9.2 Termination
w Are single subsystems allowed to terminate?
w Are other subsystems notified if a single subsystem terminates?
w How are local updates communicated to the database?
v 9.3 Failure
w How does the system behave when a node or communication link
fails? Are there backup communication links?
w How does the system recover from failure? Is this different from
initialization?
Bernd Bruegge 15-413 Software Engineering 80
Design Rationale
v The system design describes a solution based on existing
technology
w What issues were discussed?
w What other solutions have been considered? Why
were these not used?
w What is the reasoning behind the decisions made?
w What resolutions were made? Why?
w What kind of technological enablers were discussed
but not used? Did they influence your design?
v Lecture on November 10

Bernd Bruegge 15-413 Software Engineering 81

System Design Document:
Assignments and Deadlines
v Individual Section Assignments:
w 1. Goals and Trade-offs (Documentation Core Team)
w 2. System Decomposition (Architecture Core Team)
w 3. Concurrency Identification (Learning Team)
w 4. Hardware/Software Mapping (Network Team)
w 5. Data Management(Database Team)
w 6. Global Resource Handling (Authentication Team)
w 7. Software Control Implementation (Architecture Core Team)
w 8. Boundary Conditions (User Interface Team)
w 9. Design Rationale (All Teams)
v Deadlines:
w Submission of section 1 to 8: Oct 27, 6pm.
w Integration of section 1 to 8 (Documentation team): Nov 4, 3pm
w Submission of section 9: Nov 17, 6pm
w Integration, Revision of SDD and ODD (JavaDoc
Documentation): Due Nov 23, 3pm
Bernd Bruegge 15-413 Software Engineering 82