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?

* * 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

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

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

---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

—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

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

Example (Chapter 6): MyTrip Use cases: PlanTrip Execute Trip Analysis Model (6-28): PlanningService RouteAssistant Trip Location Direction Destination Crossing Segment

--Select a hardware configuration and a platform --Allocate objects and subsystems to nodes <<device>> :OnboardComputer :Routingsubsystem <<device>> :WebHost <<http>> <<webserver>> :Apache :PlanningSubsystem :Safari

CommunicationSubsystem RoutingSubsystem RouteAssistant Location TripProxy SegmentProxy PlanningSubsystem PlanningService Trip Destination Direction Crossing Segment CommunicationSubsystem Items in bold: initial objects defined Message Connection

--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

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?”

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

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

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