1. Addressing Design Goals
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): Analysis System design Object design
We were here
Nonfunctional
requirements
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 we’re 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. ---functionality of each node
*hardware / software mapping:
---functionality of each node
---communication between nodes—may 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. —who can access what data? ---How can access be changed dynamically?
*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)
*boundary conditions
--initialization / shutdown
--exceptions

7. UML: Deployment and Component Diagrams (diagrams 7-2,7-3):
<<device>>
myMac:Mac
:Safari
<<device>>
:UnixHost
:Webserver
<<http>>
Note: no direct connect web-DB
<<http>>
<<device>>
aPc:PC
:Firefox
<<device>>
:UnixHost
:Database
<<jdbc>>
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
<<device>>
:OnboardComputer
:Routingsubsystem
<<device>>
:WebHost
<<http>>
<<webserver>>
:Apache
:PlanningSubsystem
:Safari

10. CommunicationSubsystem
RoutingSubsystem
RouteAssistant
Location
TripProxy
SegmentProxy
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. In general: 3 common approaches
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 access—uses a lot of memory
--access control list—store pairs (actor, operation), each object checks this list when an operation is requested—can easily answer “who has access to this object?)
--capability—associate (class,operation) pairs with each actor—can easily answer “which objects can this actor access?”

13. Global Control Flow
3 standard choices:
--procedure-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
uses 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
hard 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
--communication must be managed
--iteration may be required