System Design: Addressing Design Goals

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): 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 (hw/sw “codesign”) *data management *access control *control flow *boundary conditions This phase is highly interactiveand 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. <<device>> myMac:Mac <<device>> :UnixHost <<device>> aPc:PC <<device>> :UnixHost :Safari :Webserver :Firefox :Database UML: Deployment and Component Diagrams (diagrams 7-2,7-3): <<http>> Note: no direct connect web-DB <<http>> <<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. <<device>> :OnboardComputer <<webserver>> :Apache :Routingsubsystem :PlanningSubsystem --Select a hardware configuration and a platform --Allocate objects and subsystems to nodes <<device>> :WebHost <<http>> :Safari

10. 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. 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 betweendesign 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