1. 6.0 SYSTEM DESIGN System Design Process – transforms the analysis model into design model Process: 1) Decomposition (guided by design goals) 2) Hardware/software platform mapping (deployment diagram) 3) Persistent data (DB) 4) Overall control flow (activity/collaboration diagram) 5) Access control policy 6) Boundary conditions Transitional activities from system spec (RAD) to final system construction A) system design B) object design C) implementation

2. 6.0 SYSTEM DESIGN 6.1 Introduction Step A – System design Elicitation of specs focuses on functionality and goals System design focuses on data structures, processes, software, hardware, legacy systems The decomposition process entails matching design goals against constraints ( See Fig 6.1 – successive changes indicates matching constraints against user goals) Similarities (House design vs. Software Engineering): i) Rooms – subsystemsv) Kitchen layout – coding complexity/modularity ii) Doors – interfaces/servicesvi) Re-draw/moving walls – redesign of interfaces iii)Living area – response time/QoS iv) No. of rooms – use cases

3. N Bedroom2 Master Bedroom Dining Hallway Stairs Bath Kitchen Study Bath Kitchen Master Bedroom Dining Hallway Stairs Entrance door Master Bedroom Bedroom2 Dining Hallway Stairs Entrance door Study Bath Kitchen Bedroom2 Entrance door Version 1 Version 2 Version 3 Figure 6-1. Example of iterative floor plan design. Three successive versions show how we minimize walking distance and take advantage of sunlight.

4. 6.0 SYSTEM DESIGN 6.2 Overview System design – addresses the internal structure or software architecture of the system, and how the internal functions are impacted by the external/operating environment, e.g., OS, DB, hardware platform Results of system design – optimized design goals (derived from the non-functional requirements) the software architecture (guided by several issues)

5. 6.0 SYSTEM DESIGN 6.2 Overview – 1 Issues that guide system decomposition – toward the software architecture i) hardware/software mapping – processors, communication, data migration, concurrency, services using off-the-shelf, DB, user-interfaces, compo encapsulation ii) data management – persistency, storage, control, access, security, consistency, retrieval, reliability/availability, overall DBMS iii) Access Control – policy and mechanism, extent (system-wide or select components) iv) Control Flow – sequence of operations (in embedded system world = software architecture), event-driven, interrupt-driven, OS-control – threads with semaphores/CS V) Boundary conditions – initialization, exception handling (nesting?), e.g., in distributed systems, shutdown (See Fig 6.2)

6. Figure 6-2. The activities of system design (UML activity diagram).

7. 6.0 SYSTEM DESIGN 6.3 SD Concepts – System Decomposition Properties: Subsystem – a) Application domain is decomposed into Classes and organized as Packages and b) Solution domain is decomposed into Parts (domain Classes and Subsystems Interfaces – subsystems provide services through the interfaces. Services are related operations which a subsystem implements to support others. (System design focuses on the ‘services’ definition and Object design focuses on the ‘operational details’ for implementing/realizing the services.) Coupling/Coherence – aspects of subsystem dependencies (low coupling and high cohesion) Layering – organizing a system as hierarchy of subsystems (lower layers support upper layers) Partitioning – organizing subsystems into peer-to-peer service providers All 6 properties define the software architecture E.g. (Fig 6-3 – decomposition, and Fig 6-4 – decomposition into packages)

8. Figure 6-3. Subsystem decomposition (UML class diagram).

9. Notification IncidentManagement FieldOfficerInterfaceDispatcherInterface Figure 6-4. Subsystem decomposition for an accident management system (UML class diagram, collapsed view). Subsystems are shown as UML packages. Dashed arrows indicate dependencies between subsystems.

10. 6.0 SYSTEM DESIGN 6.3.2 SD Concepts – Services and Interfaces Service – a set of complementary operations serving the needs of client subsystems, e.g., ‘notification service [ops to snd/recv notices, channel alloc,..] Interfaces – the collection of services subsystems provide in an environment (also called API) includes the op types, parameters, name of ops, constraints – access control, return values, etc. SD – focused on defining and designing the high-level behaviors in the interfaces ( without implementation details ) – and abstraction concept

11. 6.0 SYSTEM DESIGN 6.3.3 SD Concepts – Coupling and Coherence Coupling – measure of the degree of subsystem dependencies; highly coupled subsystems are highly dependent and changes in one has more impact on others (See Fig 6-5 and Fig 6-6 – a syntax and semantic analyzer subsystem sharing a parse- tree – common interface – via attributes vs. via operations. Interfacing via operations requires no changes to interface, hence the two subsystems won’t change ) Coherence – measure of the strength of object (inter)dependencies within a subsystem in performing complementary tasks. (Low coherence is not good!) (See Fig 6-7 – with low coherence and Fig 6-8 – with reduced complexity and increased coherence in 2 subsystems using the 7 +/- 2 decomposition rule)

12. add1:OpNode add2:OpNode c:ArgNodeb:ArgNode a:ArgNode Binary tree representation Sharing through attributes class OpNode { ArgNode left; ArgNode right; String name; } class ArgNode { String name; } Sharing through operations class OpNode { Enumeration getArguments(); String getName(); } class ArgNode { String getName(); } Figure 6-5. Example of coupling reduction (UML object diagram and Java declarations). This figure shows a parse tree for the expression “a + b + c”. The left column shows the interface of the OpNode class with sharing through attributes. The right column shows the interface of OpNode with sharing through operations. Figure 6-6 shows the changes for each case when a linked list is selected instead.

13. add:OpNode c:ArgNodeb:ArgNodea:ArgNode Linked list representation Sharing through attributes class OpNode { ArgNode first; ArgNode left; ArgNode right; String name; } class ArgNode { String name; ArgNode next; } Sharing through operations class OpNode { Enumeration getArguments(); String getName(); } class ArgNode { String getName(); } Figure 6-6. Example of coupling reduction (UML object diagram and Java declarations). This figure shows the impact of changing the parse tree representation of Figure 6-5 to a linked list. In the left column, with sharing through attributes, four attributes need to change (changes indicated in italics). In the right column, with sharing through operations, the interface remains unchanged.

14. Figure 6-7. Decision tracking system (UML class diagram). The DecisionSubsystem has a low coherence: The classes Criterion, Alternative, and DesignProblem have no relationships with Subtask, ActionItem, and Task.

15. subtasks * assesses solvableBy resolvedBy based-on * ** implementedBy RationaleSubsystem PlanningSubsystem CriterionAlternative Decision DesignProblem SubTask ActionItem Task Figure 6-8. Alternative subsystem decomposition for the decision tracking system of Figure 6-7 (UML class diagram). The coherence of the RationaleSubsystem and the PlanningSubsystem is higher than the coherence of the original DecisionSubsystem. Note also that we also reduced the complexity by decomposing the system into smaller subsystems.

16. 6.0 SYSTEM DESIGN 6.3.4 Layer and Partitions One design goal – to reduce complexity by problem decomposition Layers: Layered architecture – in which lower layers support upper ones (with abstraction) (See Fig 6.9) Closed architecture – layered but each layer depends only on one directly below it (e.g., ISO-OSI protocol stack or Unix OS) (See Fig 6.10 – in these, the OS provides middleware such as CORBA OMG, JavaRMI between upper the Application and Transport Layers and protocols like TCP/IP as middleware for the lower layers) (See Fig 6.11)

17. Figure 6-9. Subsystem decomposition of a system into three layers (UML object diagram). A subset from a layered decomposition that includes at least one subsystem from each layer is called a vertical slice. For example, the subsystems A, B, and E constitute a vertical slice, whereas the subsystems D and G do not.

18. Application Presentation Session Transport Network DataLink Physical Frame Packet Bit Connection Format Message Level of abstraction Figure 6-10. An example of closed architecture: the OSI model (UML class diagram). The OSI model decomposes network services into seven layers, each responsible for a different level of abstraction.

19. Application Presentation Session Transport Network DataLink Physical Socket CORBA TCP/IP Object Ethernet Wire Figure 6-11. An example of closed architecture (UML class diagram). CORBA enables the access of objects implemented in different languages on different hosts. CORBA effectively implements the Presentation and Session layers of the OSI stack.

20. 6.0 SYSTEM DESIGN 6.3.4 Layers and Partitions – 1 Open architectures – E.g., Motif – user interface toolkit for X11 (Xlib for a window object, Xt for geometricl-object manipulation) Users of a ‘window manager’ in Motif can bypass the upper layers and include lower layers like Xlib – fostering low coupling and integration, but limits reuse in case of changes in, e.g., Xlib (See Fig 6.12)

21. Xlib Xt Motif Application Figure 6-12. An example of open architecture: the OSF/Motif library (UML class diagram, packages collapsed). Xlib provides low-level drawing facilities. Xt provides basic user interface widget management. Motif provides a large number of sophisticated widgets. The Application can access each of these layers independently.

22. 6.0 SYSTEM DESIGN 6.3.4 Layers and Partitions – 2 Partitions: Subsystems at the peer-to-peer level, each responsible for a class of services E.g., A Car system with partitions; ignition system, fuel system, navigation system General Decomposition – First decompose into partitions and into layers Too many subsystems and detailed decomposition adds complexity and overhead in interface definition/management

23. 6.0 SYSTEM DESIGN 6.3.5 Software Architecture Definition: The overall decomposition process which takes into account the spatial relationship among the resultant subsystems, interface protocols, global control flow, and error/exception management – policies and mechanisms Types: A. Repository – subsystems communicate via centralized data (using lock for concurrency and integrity issues) E.g., a bank DBMS or Compiler’s parse-tree and symbol-table Because of the volume of traffic (comm) to the repository coupling among subsystems is high and modifications of the repository are difficult (See Fig 6.13 and Fig 6.14)

24. Subsystem Repository createData() setData() getData() searchData() Figure 6-13. Repository architecture (UML class diagram). Every subsystem depends only on a central data structure called the Repository. The Repository in turn, has no knowledge of the other Subsystems.

25. LexicalAnalyzer SyntacticAnalyzer SemanticAnalyzer CodeGenerator SourceLevelDebuggerSyntacticEditor ParseTree SymbolTable Compiler Repository Optimizer Figure 6-14. An instance of the Repository architecture (UML Class diagram). A modern Compiler incrementally generates a ParseTree and a SymbolTable that can be later used by Debuggers and SyntaxEditors.

26. 6.0 SYSEM DESIGN 6.3.5 Software Architecture - 1 B. Model-View-Controller (MVC) architecture – has three component subsysems: A) Model subsystem for keeping domain knowledge/data B) View subsystem for visualizing/viewing the domain data C) Controller subsystem for managing user interactions with the system The Model subsystem (like the repository architecture) holds the state of objects The Controller subsystem holds the (user-personified) control objects for processing the models – the control flow The View subsystem holds the boundary objects (for user visualization) Communication among objects is via notify/subscribe protocols (See Fig 6.15)

27. Controller Model subscriber notifier initiator * repository1 1 * View Figure 6-15. Model/View/Controller architecture (UML class diagram). The Controller gathers input from the user and sends messages to the Model. The Model maintains the central data structure. The View (s) display the Model and is notified (via a subscribe/notify protocol) whenever the Model is changed.

28. 6.0 SYSTEM DESIGN 6.3.5 Software Architecture - 2 E.g., sequence of events in a MVC architecture – Using a collaboration diagram (Fig 6-16 – flow of events among the objects) And the corresponding effects – two views of a file-object, named 9DesignPatterns2.ppt (See Fig 6-17) The subscription/notification protocols removes interdependencies among the objects in Model and View – allowing decoupling of their functions due to the frequent changes A design tool for accomplishing this is – the Observer Pattern MVC architecture is suitable for interactive systems and developing visualization tools

29. :Controller :InfoView :Model 2.User types new filename 1. Views subscribe to event 3. Request name change in model 4. Notify subscribers 5. Updated views :FolderView Figure 6-16. Sequence of events in the Model/View/Control architecture (UML collaboration diagram).

30. Figure 6-17. An example of MVC architecture. The “model” is the filename 9DesignPatterns2.ppt. One “view” is a window titled Comp-Based Software Engineering, which displays the contents of a folder containing the file 9DesignPatterns2.ppt. The other “view” is window called 9DesignPatterns2.ppt Info, which displays information related to the file. If the file name is changed, both views are updated by the “controller”.

31. 6.0 SYSTEM DESIGN 6.3.5 Software Architecture - 4 C. Client-Server architecture – C-S service request/response is via RPC (remote procedure call protocol) Like the Repository model, the C-S server implements a ‘process’ that protects server data / programs (sort of localized in the server) and provides request service E.g., a centralized database for an information system E.g., a WWW with multiple user browser types and request from clients C-S architecture is good for distributed systems design and modeling (See Fig 6-18 and Fig 6.19)

32. Client Server service1() service2() serviceN() … * * requesterprovider Figure 6-18. Client/server architecture (UML class diagram). Clients request services from one or more Servers. The Server has no knowledge of the Client. The client/server architecture is a generalization of the repository architecture.

33. netscape:WebBrowser www12.in.tum.de:WebServer www.cs.cmu.edu:WebServer lynx:WebBrowser mosaic:WebBrowser iexplorer:WebBrowser Figure 6-19. The World Wide Web as an instance of the client/server architecture (UML object diagram).

34. 6.0 SYSTEM DESIGN 6.3.5 Software Architecture -5 D. Peer-to-Peer architecture – a generalization of the C-S architecture: clients can become servers (from the other side) and servers can become clients similarly. Useful, but difficult to design as it is susceptible to deadlocks and complex control flow (See Fig 6-20 and Fig 6-21)

35. Peer service1() service2() serviceN() … requester provider * * Figure 6-20. Peer-to-peer architecture (UML class diagram). Peers can request services from and provide services to other Peers.

36. application1:DBUser database:DBMS application2:DBUser 1. updateData 2. changeNotification Figure 6-21. An example of peer-to-peer architecture (UML collaboration diagram). The database server can both process requests from and send notifications to applications.

37. 6.0 SYSTEM DESIGN 6.3.5 Software Architecture - 6 E. Pipe and Filter architecture – a subsystem (serving as a filter) received input set, processes it internally and sends output set (through a pipe) to a ‘waiting’ subsystem (on the receiving end). Concept is Unix OS environment – used for interprocess communication (automatic transformation of input data, automatic piping, and synchronized reception – without human intervention) (See Fig 6-22 and Fig 6-23)

38. Pipe inputoutput input*1 *1 Filter Figure 6-22. Pipe and filter architecture (UML class diagram). A Filter can have many inputs and outputs. A Pipe connects one of the outputs of a Filter to one of the inputs of another Filter.

39. % ps auxwww | grep dutoit | sort | more dutoit 19737 0.2 1.6 1908 1500 pts/6 O 15:24:36 0:00 -tcsh dutoit 19858 0.2 0.7 816 580 pts/6 S 15:38:46 0:00 grep dutoit dutoit 19859 0.2 0.6 812 540 pts/6 O 15:38:47 0:00 sort psgrepsortmore Figure 6-23. An instance of the pipe and filter architecture (Unix command and UML activity diagram).

40. 6.0 SYSTEM DESIGN 6.3.6 UML Deployment Diagrams Used for relating (connecting) component diagrams to hardware nodes. The components are self-contained run-time entities that provide services to other components E.g. The Netscape browser (component) servicing the user (actor) Notation: A node in a deployment diagram is a box, containing component icons, and interfaces between boxes are represented by dashed arrow (See Fig 6-24 – more high level component nodes, revealing nothing about the interfaces used for communication or classes they contain)

41. :WebServer myMac:Mac:UnixHost :IExplorer aPC:PC :Database :UnixHost :Netscape Figure 6-24. A UML deployment diagram representing the allocation of components to different nodes and the dependencies among components. Web browsers on PCs and Macs can access a WebServer that provides information from a Database.

42. 6.0 SYSTEM DESIGN 6.3.6 UML Deployment Diagrams – 1 Fig 6-25 – Depicts a refined deployment diagram, showing the classes (no need to show associations/links, etc) and the interfaces/port for communication

43. GET POST HttpRequest URL File WebServer DBQuery DBResult Figure 6-25. Refined view of the WebServer component (UML deployment diagram). The WebServer component provides two interfaces to browsers: A browser can either request the content of a file referred by a URL (GET) or post the content of a form (POST). The WebServer component contains five classes: URL, HttpRequest, DBQuery, File, and DBResult.

44. 6.0 SYSTEM DESIGN 6.4 System Design Activities System design entails the transformation of the analysis model, together with the non-functional requirements and constraints in the RAD, into the design model toward the implementation Example: ‘car driving’ plan to motivate the discussion of 8 main activities Consider the ‘input’ Car Trip Analysis Model – collection of use cases, class diagram with data dictionary, and non-functional requirements (See Fig 6-26 and Fig 6-27 and Fig 2-8) The non-functional requirements: - using a wireless modem for reliable connection to a PlanningService procider - accurate directions are given even on modem failure - modem connection time must be minimized - support replanning of the trip while connection is still available - PlanningService can support 50 drivers and 1000 trips

45. Location Segment Crossing Direction Destination Trip RouteAssistant PlanningService Figure 6-28. Analysis model for the MyTrip route planning and execution.

46. 6.0 SYSTEM DESIGN 6.4 System Design Activities – 1 A. Identifying design goals: From the non-functional requirements: reliability, fault tolerance, connectivity, security, number of drivers and trips, replanning/modifiability, cost-effectiveness. Others: connection time or response time, performance, maintenance (upkeep of driving data), etc., which are gleaned from the RAD or application domain Criteria and goals may be conflicting – requires compromises, trade-offs and optimization (See Table 6-1 to Table 6-6)

47. 6.0 SYSTEM DESIGN 6.4 System Design Activities - 2 B. Identifying Subsystems: Similar application of Abbott’s heuristics to identifying objects Requires subsystem decomposition, mergers, and additions – iterative process Initial decomposition is from the functional and object models (use cases – base use cases, shared use cases, extended/included use cases) and the classes. Key: grouping use cases and classes into related entities as ‘packages’ of subsystems Heuristics for Identifying subsystems: Assign objects identified in one use case into the same subsystem Create a dedicated subsystem for ‘data moving’ objects in the system Use a fewer number of links/associations crossing subsystem boundaries Objects in the same subsystem must be functionally related

48. 6.0 SYSTEM DESIGN 6.4 System Design Activities – 3 C. Encapsulating subsystems – Packages of subsystems reduce complexity or minimize dependencies among classes Encapsulating subsystems inside a ‘front-end’ package, called a Façade, further hides the internals of the classes – making the internals only accessible by the façade. The outside world can get to these classes only via public services/interface provided in the façade. This design strategy uses the Façade Pattern via encapsulation E.g., Encapsulating the ‘Compiler’ subsystem in a Façade, by providing an interface service routine, compile(s). (See Fig 6-30)

49. Compiler compile(s) create() getToken() CodeGenerator create() generateParseTree()create() Compiler OptimizerLexerParserParseNode Figure 6-30. An example of the Facade pattern (UML class diagram).

50. 6.0 SYSTEM DESIGN 6.4 System Design Activities – 4 4. Mapping Subsystems to Processors and Components Selecting a hardware configuration and a platform Allocating/assigning subsystems to different processors, and design comm support between subsystems Underlying processors are modeled as nodes in Deployment Diagrams Underlying virtual machines (the OS’s, the DBMS’s, Networks), compatible with the processors, but the selection could be constrained by cost, processor-type, etc. E.g., For the MyTrip problem, select two processors (nodes) – an Internet host and an onboard (embedded in the car) processor, the Unix-Netscape for the host, and some RTOS-Explorer for the onboard (See Fig 6-31)

51. RoutingSubsystem PlanningSubsystem :OnBoardComputer :WebServer Figure 6-31. Allocation of MyTrip subsystems to hardware (UML deployment diagram). RoutingSubsystem runs on the OnBoardComputer while PlanningSubsystem runs on a WebServer.

52. 6.0 SYSTEM DESIGN 6.4 System Design Activities – 5 Allocating objects/subsystems to nodes – done after selecting the operating environ Object/subsystem assignment exposes missing subsystems, e.g., for data movement E.g., in the MyTrip, a CommunicationSubsystem is need to support the comm between the wireless modem and all other objects/subsystems There is the need for surrogate subsystems: SegmentProxy- one that takes care of info pertaining to a segment (of trip) and TripProxy - another that helps in planning a trip. These are needed inside the RoutingSubsystem to act as Proxies on behalf of the two subsystems in the PlanningSubsystem. The two proxies communicate with the CommicationSubsystem. The Proxy Design Pattern is used to create proxy subsystems as surrogates of others without duplicating full functionality (See Fig 6-32)

53. Trip Location PlanningService Segment Crossing RouteAssistant Direction Destination TripProxy SegmentProxy PlanningSubsystem Message Connection CommunicationSubsystem RoutingSubsystem Figure 6-32. Revised design model for MyTrip (UML Class diagram, associations omitted for clarity).

54. 6.0 SYSTEM DESIGN 6.4 System Design Activities – 6 Encapsulating Existing/Legacy and Off-the-Shelf Components – Need to incorporate existing systems and reuse of off-the-shelf components to reduce design/development time and costs Encapsulating also hides the internals of the existing component, further decoupling the system under construction from the existing The ‘integrator / glue’ is called the Adapter Pattern or Wrapper Wrappers are useful in developing e.g., communication protocol glues for distributed applications developed in different languages or that use different protocols (e.g., CORBA environment) (See Fig 6-33 and Fig 6-34)

55. NewInterface Request() adaptee LegacySystem ExistingRequest()Adaptor Request() Subsystem Figure 6-33. Adapter pattern (UML class diagram). The Adapter pattern is used to provide a different interface ( NewInterface ) to an existing component ( LegacySystem ).

56. 6.0 SYSTEM DESIGN 6.4 System Design Activities - 7 5. Defining Persistent Data Stores – preserving data values consistently over time The kind DB system and its DBMS for storage/processing/retrieval impacts system decomposition, control strategy, and concurrency management E.g., in the MyTrip problem, a small file in RoutingSubsystem will hold trip-files on short-term basis on the onboard computer, while the PlanningSubsystem will hold persistent trip-files in a DB over time Persistent data are kept because it may be costly to recalculate, otherwise don’t Factors to consider in selecting DB type: complex queries, data size/space, management, use of flat files, Relational DB, OO database (see p. 205 – tradeoffs) (See Fig 6-35)

57. PlanningSubsystem MapDBStoreSubsystem TripFileStoreSubsystem RoutingSubsystemCommunicationSubsystem Figure 6-35. Subsystem decomposition of MyTrip after deciding on the issue of data stores (UML class diagram, packages collapsed for clarity).

58. 6.0 SYSTEM DESIGN 6.4 System Design Activities – 8 Encapsulating data stores – once a DB is selected provide an ‘interface,’ a bridge to the DB which will hide the vendor-specific services and data layout. The interface will decouple your classes/subsystems from the DB The ‘abstract’ interface available to the client (your program) and corresponding ‘abstract’ implementation, which maps requests/queries to specific DBMS queries, are need. The AbstractInterface and AbstractImplementor classes are supported by the Bridge Pattern [E.g., ODBC and JDBC provide abstractions to relational databases] (See Fig 6-36 and Fig 6-37)

59. RefinedAbstraction Implementor imp Concrete ImplementorA Concrete ImplementorB provides Abstraction Subsystem Figure 6-36. Bridge pattern (UML class diagram).

60. ODBC Implementation ODBC imp Oracle ODBC Driver DB2 ODBC Driver Informix ODBC Driver Figure 6-37. Bridge pattern for abstracting database vendors (UML class diagram). Removing the dependency from database vendors from the systems provides more flexibility.

61. 6.0 SYSTEM DESIGN 6.4 System Design Activities – 9 6. Defining Access Control Multiple actor access to functionality and shared data – requires protected or restricted access Access control is modeled using different use cases during the analysis phase Access control is modeled by focusing on the object model – determining which actor accesses which objects and creating an ‘authentication’ for access control and ‘encryption’ to encrypt traffic data for security (See Table 6-7 – expanded to include authentication-of-drivers and traffic-encryption concerns in the design model) General implementation strategy: develop an access matrix of user/object, where the cells indicate the permissible operations, or access rights – classical in OS, DB, Network applications (See Table 6-8)

62. 6.0 SYSTEM DESIGN 6.4 System Design Activities – 10 Access control matrix representations – the select method can impact performance 1) global access control – (actor, class, operation)-tuple in each cell 2) access control list – (actor, operation)-pair for each class in the list 3) capability list – (class, operation)-pair for each actor in the list Subclassing under the access-control-list method can discriminate actor access Static access control – typically implemented as access matrix Dynamic access control – supports dynamically assigned roles to actors or objects, and can be modeled using the Proxy Pattern (See Fig 6-38 – dynamic assignment of portfolios to brokers)

63. Portfolio buy() sell() estimateYield() 1 1 * 1 Broker buy() sell() estimateYield() Access isAccessible(op) Figure 6-38. Dynamic access implemented with a protection Proxy. The Access association class contains a set of operations that Broker can use to access a Portfolio. Every operation in the PortfolioProxy first checks with the isAccessible() operation if the invoking Broker has legitimate access. Once access has been granted, PortfolioProxy delegates the operation to the actual Portfolio object. One Access association can be used to control access to many Portfolios. PortfolioProxy

64. 6.0 SYSTEM DESIGN 6.4 System Design Activities – 11 Authentication – verifying association between an actor/subsystem and the system. Typical mechanisms: name, ID, password (with encryption), smart cards, fingerprints Encryption – preventing unauthorized access by converting plaintext (message) to a ciphertext (encrypted). Need a key and an algorithm to decipher (decrypt) the ciphertext. Encapsulating access control If using off-the-shelf or vendor-supplied algorithms, policies, and mechanisms – be careful of Trojan Horse entrapment (no escape hatches hidden in the product). General solution – develop an encapsulation of general algorithms, with an abstract interface, for several concrete algorithms using the Strategy Pattern (See Fig 6.40)

65. Message getBlock() IDEA IDEA_Vendor_AIDEA_Vendor_B encrypt(key, block) decrypt(key, block) Context class Strategy class ConcreteStrategy classes Figure 6-40. An example of a Strategy pattern encapsulating multiple implementation of the IDEA encryption algorithm (UML class diagram). The Message and IDEA classes cooperate to realize the encryption of plain text. The selection of an implementation can be done dynamically.

66. 6.0 SYSTEM DESIGN 6.4 System Design Activities 7. Designing the Global Control Flow Which operations to execute and the order/sequence of operations In OO (UML) methodologies, it is the actor’s initiation or passage of time During analysis, objects are assumed to interact with each other and timing and processor on which they are interacting is not a big issue During design, objects’ behavior and on which processors (assigned) they would run and timing issues become important

67. 6.0 SYSTEM DESIGN 6.4 System Design Activities Mechanisms for implementing Control Flow: 1) Procedure-driven: operations wait on input from actor – not suitable for OO design since control flow is distributed in an object-space and the other is not determinable 2) Event-driven: a main program initiates the external event to activate objects in the system (which are waiting on that event) – centralizes control but hard to implement in multi-step (nested conditions) sequences 3) Threads: concurrent version of procedure-driven, where several operations (threads of execution) wait on different event (input arrival) and behavior according – they respond to input-stimuli from the actor. Hard to debug and create repeatable test cases and degenerates to non-deterministic control flow (See Fig. 6-41, Fig 6-42, and Fig 6-43)

68. 6.0 SYSTEM DESIGN 6.4 System Design Activities Issues: A) procedure-driven is good for unit testing (using test-drivers) subsystems B) Event-driven (debugging tools) and interface support are more matured than threads control flow, which currently lacks such tools. (Event-driven flow can influence design rationale and choices, e.g., in embedded systems.) C) Control objects are used to describe the control flow (or software architecture) of the system. Control objects receive ‘stimuli’, store state on temporary basis, and issue signals to activate other control objects, entity objects, and boundary objects D) Good idea to allow one control object to start up control flow in a use case

69. 6.0 SYSTEM DESIGN 6.4 System Design Activities Encapsulating Control Flow Control flow is determined by the sequence of stimuli/inputs to the various control objects waiting on the inputs. The objects request the input – and to decouple the requesting control objects from the service objects (the input handlers), the request satisfaction must be assigned to separate ‘command objects.’ The decoupling can be achieved by using the Command Pattern, which effectively centralizes control flow in control objects and not in boundary or entity objects The Command abstract class defines the order of execution of the commands (sequence of operations based on order of input arrivals). The Command abstract class issues the ‘concrete/specific’ commands using the ConcreteCommand class to satisfy the control flow (or order) (See Fig 6-44 and Fig 6-45)

70. User ConcreteCommand1 execute() Calling Subsystem invokes ConcreteCommand2 execute() Receiver action2() action1() execute() Command execute() Figure 6-44. Command pattern (UML class diagram).This pattern enables the encapsulation of control such that user requests can be treated uniformly, independent of the specific request.

71. execute() MenuItem PasteCommand execute() Command execute() Menu Application * * copy() paste() Document execute() CopyCommand Figure 6-45. An example of a Command pattern (UML class diagram). In this example, menu items and operations on documents are decoupled. This enables us to centralize control flow in the command objects ( CopyCommand and PasteCommand ) instead of spreading it across boundary objects ( MenuItem ) and entity objects ( Document ).

72. 6.0 SYSTEM DESIGN 6.4 System Design Activities 8. Identifying Boundary Conditions Focus is on how the system is initiated/started, shutdown/closed, handling exceptions or failures (software or hardware) E.g., for the MyTrip systems – how maps get into onboard computer, how to load the software to onboard computer, how data (route into, schedules, etc.) get into or modified in the computer, … To complete the design, go back to define new use cases to “include” the missing boundary objects – a set of use cases which constitutes the Administrative Subsystem and other > use cases for common functions Modify the MyTrip analysis model to include the Administrative Subsystem, and modify the MapDBStoreSubsystem use case to reflect ‘boundary’ conditions of shutdown, data corruption, data consistency check, etc. (See Fig 6-46, Fig 6-47, and Fig 6.48)

73. PlanningService ManageDrivers ManageMaps ManageServer Administrator StartServer ShutdownServer ConfigureServer > Figure 6-46. Administration use cases for MyTrip (UML use case diagram). ManageDrivers is invoked to add, remove, modify, or read data about drivers (e.g., user name and password, usage log, encryption key generation). ManageMaps is invoked to add, remove, or update maps that are used to generate trips. ManageServer includes all the functions necessary to start up and shutdown the server.

74. 6.0 SYSTEM DESIGN 6.4 System Design Activities Exceptions and Handling – Causes a) user error – wrong input (range or constraint error), b) hardware failure – power fail, surge, worn-out part, network failure; c) software error – design/programming error Exception Handling – mechanisms for handling and correcting the error without total shutdown

75. 6.0 SYSTEM DESIGN 6.4 System Design Activities 9. Anticipating Change System decomposition into subsystem foster low coupling (minimal impact on changes) and reduces complexity System decomposition must allow flexible software architecture for future changes Anticipating changes and design techniques/methodologies to deal with them: 1) new vendor/technology – replacements in response to growth, performance, dynamics 2) new implementation – efficiency, performance, new non-functional requirements 3) new views – usability issues and new users/perceptions of system 4) new complexity of application domain – deployed systems that generates new goals (See Fig 6.49)

76. 6.0 SYSTEM DESIGN 6.4 System Design Activities 10. Reviewing the Design Done between project manager and development team (without user/client) The process may involve peer reviews (e.g., developers from different project) Some of the factors to observe during review A) traceability/correctness – mapping the design model to the analysis model B) completeness – all boundary conditions, missing use cases/subsystems, etc. C) consistent – no contradictions, prioritized goals, addressed non-func req, naming D) realistic – feasibility of supporting technologies, reliability/performance achievable E) readable – subsystem names, relating entity names – functionality/phenomena

77. 6.0 SYSTEM DESIGN 6.5 Managing System Design 1. The Design Document (SDD) – baselined for object design step (p.222) Include a section on how design communication was handled/documented; communication modes and mechanisms used in the system design process 2. Assigning Responsibilities – an architect architecture team document editor, configuration manager, reviewer