Topics for Week 7

1
System Design Addressing Design Goals We are
starting from an initial design, along with a set
of design goals. What is the next step?
2
Design process (figure 6-2)
Nonfunctional requirements
We were here
Analysis
these include --use cases and
scenarios --class (ER) diagrams --sequence
diagrams --CRC cards --state diagrams

Dynamic model

Analysis object model
System design
Design goals guide trade-offs
Now were here
Subsystem decomposition teams of developers
Object design
Object design model
3

• Process
• --Examine each design goal, one at a time,
  keeping
• desired trade-offs in mind
• --Determine any resulting
• subsystem redefinitions
• interface modifications
• --assign each subsystem to a team for
  implementation
• interfaces have already been specified
• subsystem design can proceed independently

4
Decomposition into subsystems For this strategy
to work, system-wide issues must be clearly and
completely addressed, e.g. hardware /
software mapping data management access
control control flow boundary
conditions This phase is highly interactive and
can result in new or modified subsystems, along
with system-wide revisions
5
hardware / software mapping ---functionality
of each node ---communication between nodesmay
require new subsystem ---what existing software
components can be used? ---concurrency,
reliability need to be addressed ---off-the-shelf
components may be efficient but may cause
incompatability problems later on data
management ----what data is persistent?
----How can it be efficiently accessed, stored,
protected from corruption? -may require
addition of a new subsystem
6
access control who can access what data?
---How can access be changed dynamically?
---How do we keep access rules consistent
system- wide? control flow sequential?
---Event-driven? (subsystems need to have event
handlers) ---Threads (subsystems need to
guarantee mutual exclusion in critical sections,
e.g., shared resources, producers/consumers) b
oundary conditions --initialization /
shutdown --exceptions
7
UML Deployment and Component Diagrams (diagrams
7-2,7-3)
ltlthttpgtgt
Note no direct connect web-DB
ltlthttpgtgt
ltltjdbcgtgt
WebServer
Deployment what components go to what
(physical) nodes Component interfaces, classes
http
jdbc
Servlet
HttpService
DBProxy
8
Example (Chapter 6) MyTrip Use
cases PlanTrip Execute Trip Analysis Model
(6-28)
PlanningService
RouteAssistant
Trip
Location
Direction
Destination
Crossing
Segment
9
--Select a hardware configuration and a
platform --Allocate objects and subsystems to
nodes
ltltdevicegtgt WebHost
ltlthttpgtgt
Safari
10
PlanningSubsystem
PlanningService
Trip
Destination
Direction
Crossing
Segment
CommunicationSubsystem
Items in bold initial objects defined
Message
Connection
11
--Identify and store persistent data persistent
data does not disappear at the end of a single
execution MyTrip Store current trip on a disk
for removal Store Trips in a database in
PlanningSubsystem for later use which objects
must be persistent? what type of database is
most appropriate? flat files--voluminous data
(images), temporary data core dump), low
information density (archival files,
logs) relational / object-oriented
database--concurrent accesses, difference
levels of detail, multiple platforms,
aps relational--complex queries, large data
set object-oriented database--extensive use of
associations, medium-sized data set, irregular
associations among objects
12
Access Control Who gets to access what? MyTrip
each driver should only be able to access the
trips they created create a Driver class which
will be used by the Communication Subsystem and
the Planning Subsystem to control access In
general 3 common approaches --global access
table store tuples (actor,class,operation)these
define allowable accessuses a lot of
memory --access control liststore pairs (actor,
operation), each object checks this list when an
operation is requestedcan easily answer who has
access to this object?) --capabilityassociate
(class,operation) pairs with each actorcan
easily answer which objects can this actor
access?
13
Global Control Flow 3 standard choices --procedur
e-driven good for testing works well if a
procedural language is used does not work well
for object-oriented systems where operations are
distributed over many objects --event-driven use
s main loop, with dispensing to appropriate
object simple structure, all input goes to main
loop well-supported in most current
languages --threads concurrent version of
procedural control, each thread can respond to a
different event can introduce nondeterminism har
d to test, tools not mature in general
14
Identifying Services e.g., often need a
communication system Identifying Boundary
Conditions input / output / exceptions may
generate Boundary Use Cases Reviewing System
Design must be consistent, realistic, readable
(to developers) mapping between subsystems / use
cases mapping between design goals /
nonfunctional requirements making sure every
nonfunctional requirement is addressed providing
each actor with an access policy consistent with
security
15
Managing the System Design Process --activities
must be documented (fig. 7-18) --responsibilities
must be assigned architect liaisons document
editor, configuration manager, reviewer --communi
cation must be managed --iteration may be
required