COS 315

1
COS 315 SOFTWARE ENGINEERING 12. System Design
II Other High-Level Design Issues
2
Overview

• System Design I - Activities
• - Overview of System Design
• - Design Goals
• - Subsystem Decomposition
• - Architectural Style
• System Design II - Activities
• - Concurrency Identification
• - Hardware/Software Mapping
• - Persistent Data Management
• - Global Resource Handling and Access Control
• - Software Control
• - Boundary Conditions

3
The activities of system design
Define
Implement
Define
subsystems
subsystems
design goals
Map subsystems
to hardware/
software platform
Manage
persistent data
Define access
control policies
Select a
global
control flow
Describe boundary
conditions
4
Drawing Subsystems in UML

• System design must model both static and dynamic
  structures via two more UML diagrams
• Component Diagram for static structures
• shows the structure at design time or compilation
  time
• shows the various components in the system and
  their dependencies
• Deployment Diagram for dynamic structures
• shows the structure of the run-time system
• shows the physical layout of components on
  hardware nodes

5
Component Diagram

• Component Diagram
• A diagram of components connected by dependency
  relationships.
• Shows the dependencies among software components
• Dependencies are shown as dashed arrows from the
  client component to the supplier component.
• The kinds of dependencies are implementation
  language specific.

Note A component is a self-contained entity that
provides services to other components or actors
may be a class or subsystem.
6

• Can use the lollipop notation to indicate the
  interfaces supported by a component
• Components may contain classes (indicating that
  the class is part of the component)

7
A component is often the same as a package, i.e.
subsystem By default, each component has a
specification (i.e. an interface) and a body
(i.e. an implementation)
Specification
Warning Component is a word whose meaning varies
enormously depending on who is using it!
8
Component Diagram Example
Shows the various components in a system and
their dependencies
reservations
UML Interface
UML Component
update
Lollipop notation
9
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.

10
Components in a deployment diagram represent
physical modules (subsystems) of code. They
correspond exactly to the packages of a package
diagram, so the deployment diagram shows where
each package (i.e. subsystem) is running on the
system
11
Deployment Diagram Example
ltltdatabasegtgt meetingsDB
PC
Planner
12
Example
myMacMac
UnixHost
WebServer
UnixHost
aPCPC
Database
IExplorer
A UML deployment diagram representing the
allocation of components to different nodes and
the dependencies among components - Web browsers
on PCs and Macs can access a Web server that
provides information from a Database
13
WebServer
GET
URL
POST
DBQuery
HttpRequest
DBResult
File
Refined view of the WebServer component
diagram. The WebServer component provides two
interfaces to browsers A browser can either
request the contents of a file referred by a URL
(GET) or post the content of a form (POST). The
WebServer component contains five classes URL,
HttpRequest, DBQuery, File, and DBResult
14
Now look at various design problems
15
Concurrency - Design Problem 1

• Identify any concurrency within the application
  and address this issue (i.e. decide how to
  implement).
• tied up with Control Flow another design
  problem!
• Aside concurrency refers to simultaneous or
  parallel execution of parts of the program
  those parts of the system which can, in
  principle, be executed at the same time.
• Design goal response time, performance.

16
Concurrency Questions To Ask

• Which objects in the object model are
  independent?
• and therefore concurrent.
• What kinds of concurrency is identifiable?
• thread-level, process-level,
• Does the system provide access to multiple users?
• If so, concurrency is important!
• E.g. Web server can process several
  simultaneous client requests.
• Can a single request to the system be decomposed
  into multiple requests?
• - Can these requests be handled simultaneously?

17
Implementing Concurrency

• Concurrent systems can be implemented on any
  system that provides
• physical concurrency (multiple hardware
  platforms)
• E.g. distributed system
• or
• logical concurrency (software)
• E.g. Java threads, or timesharing execution of
  threads or processes via operating system

18
Concurrent activity visible in an interaction
diagram
ClassD
ClassC
ClassA
ClassB
Asynchronous messages
Simultaneous execution
Do not execute simultaneously
Concurrency
19
OS Scheduler Handling Concurrency
20
Hardware/Software Mapping - Design Problem 2

• This activity addresses two questions
• Single or multiple processor system?
• How is the object model mapped onto the chosen
  hardware?
• 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.

21
Hardware/Software Mapping Questions To Ask

• 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 a
  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?

22
Mapping the Subsystems Associations Connectivity
Some class associations may be implemented at the
physical level (but most will be at the logical
level).

• Describe the physical connectivity of the
  hardware
• E.g. via network connections
• Which associations in the object model are mapped
  to physical connections, e.g. communications
  links?
• Which of the client-supplier relationships in
  the analysis/design model correspond to physical
  connections?
• Describe the logical connectivity (subsystem
  associations)
• Identify associations that do not directly map
  into physical connections
• How should these associations be implemented?
• See later!

23
Connectivity in Distributed Systems

• If the architecture is distributed, we need to
  describe the network architecture (communication
  subsystem) as well.
• Questions to ask
• What is the transmission medium? (Ethernet,
  Wireless, )
• What is the Quality of Service (QOS)?
• What kind of communication protocols can be used?
• What are the available bandwidth (i.e. speed)
  requirements between the subsystems?

24
Typical Example of a Physical Connectivity Drawing
Physical Connectivity
Ethernet
Logical Connectivity
TCP/IP
25
Logical versus Physical Connectivity and the
Relationship to Subsystem Layering
TCP/IP protocol stack
Application Layer
Application Layer
Presentation Layer
Presentation Layer
Session Layer
Session Layer
Bidirectional associations for each layer -
Logical
Transport Layer
Transport Layer
Network Layer
Network Layer
Data Link Layer
Data Link Layer
Physical Layer
Physical Layer
Physical
26
Subsystem 1
Layer 1
Layer 2
Layer 3
Layer 4
Application Layer
Application Layer
. . .
. . .
27
Hardware/Software Mapping Questions

• What is the connectivity among physical units?
• Tree, star, matrix, ring
• What is the appropriate communication protocol
  between the subsystems?
• Function of required bandwidth, latency and
  desired reliability
• Is certain functionality already available in
  hardware?
• Do certain tasks require specific locations to
  control the hardware or to permit concurrent
  operation?
• Often true for embedded systems
• General system performance question
• What is the desired response time?

28
Processor Allocation - Summary

• Allocation of a system to multiple processors
• Application should be divided into subsystems
• Estimate processing requirements for subsystems
• Determine access criteria and location
  requirements
• Identify concurrency requirements
• Each subsystem should be allocated to an
  operating platform
• Communication requirements between subsystems
  should be determined
• The communications infrastructure should be
  specified

29
Allocation of MyTrip subsystems to hardware
OnBoardComputer
WebServer
PlanningSubsystem
RoutingSubsystem
MyTrip software for cars On-board routing system
interacts via wireless network to central route
planning system
30
Data Management - Design Problem 3

• Some objects in the models need to be persistent
• Objects which survive program termination.
• A persistent object can be realized with one of
  the following
• File
• Cheap, simple, permanent storage
• Low level (Read, Write)
• Applications must add code to provide suitable
  level of abstraction
• Database
• Powerful, easy to port
• Supports multiple writers and readers

31
File or Database?

• When should you choose a file?
• Is the data voluminous (bit maps - images)?
• 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?

32
Data Management Questions

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

33
Issues To Consider When Selecting a Database

• Storage space
• Database require about triple the storage space
  of actual data
• Response time
• Mode databases are I/O or communication bound
  (distributed databases). Response time is also
  affected by CPU time, locking contention and
  delays from frequent screen displays
• Locking modes
• Pessimistic locking Lock before accessing object
  and release when object access is complete
• Optimistic locking Reads and writes may freely
  occur (high concurrency!) When activity has been
  completed, database checks if contention has
  occurred. If yes, all work has been lost.
• Administration
• Large databases require specially trained support
  staff to set up security policies, manage the
  disk space, prepare backups, monitor performance,
  adjust tuning.

34
Global Resource Handling - Design Problem 4

• Discuss access control
• Describe access rights for different classes of
  actors
• Describe how objects guard against unauthorized
  access

35
Defining Access Control

• In multi-user systems, different actors will 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 examining the object model to
  determine which objects are shared among actors.
• Depending on the security requirements of the
  system, we also define how actors are
  authenticated by the system and how selected data
  in the system should be accessed.

36
Access Matrix

• Model access on classes with an access matrix.
• The rows of the matrix represents the actors of
  the system
• The columns represent classes whose access we
  want to control.
• Access Right An entry (cell) in the access
  matrix.
• It lists the operations that can be executed on
  instances of the class by the actor.

37
Classes
Actors
Access matrix example for a banking application
cells would actually define allowed operations
for each user.
38
Access Matrix Implementations

• Global access table Represents explicitly every
  cell in the matrix as a (actor, class, operation)
  tuple.
• Determining if an actor has access to a specific
  object requires looking up the corresponding
  tuple. If no such tuple is found, access is
  denied.
• Access control list associates a list of (actor,
  operation) pairs with each class to be accessed.
• Every time an object is accessed, its access list
  is checked for the corresponding actor and
  operation.
• Example guest list for a party.
• A capability associates a (class, operation) pair
  with an actor.
• A capability allows an actor to gain control
  access to an object of the class described in the
  capability.
• Example An invitation card for a party.
• Which is the right implementation?

39
Global Resource Questions

• Does the system need authentication?
• If yes, what is the authentication scheme?
• User name and password?
• Global access table?
• Access control list?
• Tickets? Capability-based
• What is the user interface for authentication?
• Does the system need a network-wide
  authentication server?
• If so, how is the authentication service known to
  the rest of the system?
• At runtime? At compile time?
• By Port?
• By Name?

40
Software Control - Control Flow Design
Problem 5

• Another design problem is control flow - the
  sequencing of actions in a system.
• Possible control flow mechanisms are
• Centralized control
• 1. Procedure-driven control classic/traditional
• Control resides within program code (logic).
• Operations wait for input whenever they need data
  from an actor.
• E.g. Main program calling procedures of
  subsystems.
• Simple, easy to build
• Mainly used in legacy systems. Not suitable for
  OO languages. Useful for procedural-type
  languages, e.g. C

41
E.g. Input data ... Process data ... Output
result
Driven by control that is embedded in the code
42

• 2. Event-driven control
• Control resides within a dispatcher/scheduler
  which calls appropriate subsystem functions.
• A main loop waits for an external event.
• Whenever an event becomes available, it is
  dispatched to the appropriate object.
• Flexible, good for user interfaces
• Decentralized control
• Control resided in several independent objects -
  threads. Each thread responds to a different
  event.
• Possible speedup by parallelization, increased
  communication overhead.
• Example Message-based system.

Threaded, event-driven control is standard in
modern systems.
43
Aside Threads A thread of control is a path of
execution through a set of state diagrams for
which a single object is active at a time.
44
Control code for event handling control
loop do forever if no event then sleep if
event then wakeup hand control
appropriate event handling code Event is
handled i.e. serviced by special event handling
code Driven by externally generated
events. Interrupt (event)-driven models. Used in
systems where interrupts (events) are detected by
an interrupt handler and passed to some other
component for processing
45
Threaded control concurrent extension of event
driven do forever if no event then sleep
if event then wakeup create a new
instance (thread) of event handling code
hand control to this event handling code
The system can create an arbitrary number of
threads threads of control, each
corresponding to a different event, each running
simultaneously. Scheduling of threads
implemented by runtime environment (e.g. Java) or
by operating system scheduler.
46
Centralized versus Decentralized Designs

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

47
Boundary Conditions - Design Problem 6

• Most of the system design effort is concerned
  with steady-state behaviour.
• However, the system design phase must also
  address the initiation and termination of the
  system.
• 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).

48
Boundary Condition Questions

• Initialization
• How does the system start up?
• What data need to be accessed at startup time?
• What does the user interface do at start up time?
• How does it present itself to the user?
• Termination
• What services have to registered?
• 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?

49
ManageServer Use Case
ltltincludegtgt
StartServer
PlanningService
ltltincludegtgt
Administrator
ManageServer
ShutdownServer
ltltincludegtgt
ConfigureServer
50
Questions?
51
Reading Bruegge and Dutoit Chapter 7 System
Design Pressman Chapter 22 - Object-Oriented
Design