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 Analysis Design process (figure 6-2): System design Object design Nonfunctional requirements Dynamic model Analysis object model Design goals— guide trade-offs Subsystem decomposition— teams of developers Object design model * * *: these include --use cases and scenarios --class (ER) diagrams --sequence diagrams --CRC cards --state diagrams We were here Now we’re here

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 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 *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): > myMac:Mac :Safari > :UnixHost :Webserver > aPc:PC :Firefox > :UnixHost :Database > Deployment: what components go to what (physical) nodes Component: interfaces, classes WebServer HttpServiceDBProxy Servlet Note: no direct connect web-DB jdbc http

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

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

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

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