1. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 1 Overview  System Design II 3. Concurrency 4. Hardware/Software Mapping 5. Persistent Data Management 6. Global Resource Handling & Access Control 7. Software Control 8. Boundary Conditions

2. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 2 Concurrency  Design goal  Reduce response time, improve performance.  Activity  Identify concurrent threads & address concurrency issues.  Thread  A thread of control is a path through a [set of] state diagram[s] in which 1 object is active at a time (sequential execution).

3. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 3 Concurrency …  2 objects are inherently concurrent if they never interact.  Inherently concurrent objects are assigned to different threads.  Objects with mutual exclusive activity can be folded into 1 thread (Why?)  Should they always be folded into 1 thread?  Decoupled communication Q ComputeCommunicate Q ComputeCommunicate Server Client

4. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 4 Concurrency Questions  Which objects of the object model are inherently concurrent?  Does the system provide access to multiple users?  Can 1 request decompose into many requests?  Can these requests be handled concurrently?  Can we model thread identification as a graph problem?

5. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 5 Implementing Concurrency  Concurrent systems can be implemented on a system with  physical concurrency (hardware: processors) or  logical concurrency (software: processes or threads)

6. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 6 Hardware Software Mapping  This activity addresses 2 questions  How shall we realize a subsystem: Hardware or Software?  How is the object model mapped on the hardware & software?  Mapping Objects onto Reality: Processor, Memory, Input/Output  Mapping Associations onto Reality: Connectivity –Example: Mirrors on same LAN for speed vs. different LANS for reliability?

7. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 7 Mapping the Objects  Processor issues  Is the computation rate too demanding for 1 processor?  Can we get speedup by distributing tasks across several processors?  How many processors are required to maintain steady state load?  Memory issues  Is there enough memory to buffer bursts of requests?  I/O issues  Do I need an extra hardware to handle the data generation rate?  E.g., radar returns  Latency vs. bandwidth  Decouple server transaction logging from processing: –Shortens transaction time  increases # clients serviceable –Lengthens total processing time (e.g. CX producer/server: getTask vs. storeResult)

8. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 8 Mapping the Subsystems Associations: Connectivity  Describe the physical connectivity of the hardware  Which associations in the object model map to physical connections?

9. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 9 Connectivity in Distributed Systems  If the architecture is distributed, describe the network architecture (communication subsystem).  Questions to ask  What are the transmission media? (Ethernet, Wireless)  What is the Quality of Service (QOS)?  What communication protocols can be used?  Should interaction be asynchronous or synchronous?  What is the bandwidth requirement between the subsystems?  1 bit/s: pacemaker  1MByte/s: Latest Survivor episode

10. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 10 Typical Example of a Physical Connectivity Drawing DistributedDatabaseArchitectureTue, Oct 13, 199212:53 AM Application Client Application Client Application Client Communication Agent for Application Clients Communication Agent for Application Clients Communication Agent for Data Server Communication Agent for Data Server Local Data Server Global Data Server Global Data Server Global Data Server OODBMS RDBMS Backbone Network LAN TCP/IPEthernet

11. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 11 Hardware/Software Mapping Questions  What is the connectivity among physical units?  Tree, star, matrix, ring  What is the appropriate communication protocol between subsystems (e.g., RMI, TCP, UDP)?  Function of required bandwidth, latency, & desired reliability  Do some tasks require specific locations to control the hardware?  Often true of embedded systems: Thermostat  General system performance question:  What is the desired response time?  Again, getTask vs. storeResult

12. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 12 Data Management  Some objects in the models need to be persistent  Separate subsystems with well-defined interfaces.  A persistent object can be realized as  Data structure (1 st choice)  If the data can be volatile  Files (2 nd choice)  Cheap, simple, permanent storage  Low level (Read, Write)  Applications must add code to provide suitable level of abstraction  Database (3 rd choice)  Powerful, easy to port  Supports multiple writers & readers

13. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 13 Database Management System  Has mechanisms to  describe data  manage persistent storage  backup data  Provides concurrent access  Contains information about the data (“meta-data”)  aka data schema

14. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 14 Issues To Consider When Selecting a Database  Storage space  Databases require about triple the storage space of actual data  Locking modes  Granularity:  Table (relation)  Record  Field  Administration  Large databases require trained support staff to:  set up security policies  manage the disk space  prepare backups  Monitor/tune performance

15. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 15 Relational Databases  Data is presented as 2-dimensional tables.  A tables has:  A fixed number of columns  An arbitrary numbers of rows  Primary key  Combination of attributes that uniquely identify a row.  Each table should have only 1 primary key  Foreign key  Reference to a primary key in another table  SQL: the standard language for defining & manipulating tables.  Leading commercial databases support constraints.  E.g., referential integrity: ensures that references to rows in other tables actually exist.

16. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 16 Mapping an object model to a relational database  UML object models can be mapped to relational databases  Mapping  Each class is mapped to a table  Each class attribute is mapped onto a column  An object represents a row  A *-* association is mapped into its own table  A 1-to-many association is implemented as foreign key  Methods are not mapped

17. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 17 Turning Object Models into Tables I City cityName Airport airportCode airportName * * Serves cityName Houston Albany Munich Hamburg City Table cityName Houston Albany Munich Hamburg Serves Table airportCode IAH HOU ALB MUC HAM Airport Table airportCode IAH HOU ALB MUC HAM airportName Intercontinental Hobby Albany County Munich Airport Hamburg Airport Primary Key *-* Associations: Separate Table Separate Table

18. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 18 Turning Object Models into Tables II Transaction transactionID Portfolio portfolioID... * portfolioID... Portfolio Table transactionID Transaction Table portfolioID Foreign Key 1-To-Many or Many-to-1 Associations: Buried Foreign Keys

19. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 19 Data Management Questions  Must the data be distributed?  Must the database be extensible?  What is the expected request (query) rate? In the worst case?  What is the size of typical/worst case requests?  Should the database be relational or object-oriented?

20. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 20 Global Resource Handling  Access control: Guarding against unauthorized access  Access rights for different classes of actors

21. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 21 Global Resource Questions  Does the system need authentication?  E.g., ATM requires a card & PIN  What is the user interface for authentication?  Government mandate: babies born under government medical coverage have a unique “bar” code embedded in the junk part of their DNA?  Is a system-wide name server needed?  How is a service known to the rest of the system?  By Port?  By Name?  Jini Lookup Service (LUS)

22. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 22 Decide on Software Control  Implicit control (non-procedural or declarative languages)  Rule-based systems  Logic programming  Explicit control (procedural languages)  Centralized control  1. Procedure-driven control –Example: Main program calling procedures of subsystems. – Simple, easy to build  2. Event-driven control –Dispatcher calls subsystem functions via callbacks. – Flexible, good for user interfaces  Decentralized control  Control resides in independent objects.  Concurrency.  Example: Message based system.  Natural, hard to make correct.

23. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 23 Procedure-Driven Control Example module1module2 module3 op1() op2()op3()

24. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 24 Event-Based System Example: MVC  Model-View-Controller  Client/Server Architecture Control Model View Model has changed Update

25. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 25 Centralized vs. Decentralized Designs  Centralized Design  1 control object or subsystem ("spider") controls everything  Change in the control structure is very easy  Performance bottleneck  Decentralized Design  Control is distributed  Distributes out responsibility/authority  Fits into object-oriented design (message-passing)  Models autonomous objects

26. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 26 Boundary Conditions  Most system design effort concerns steady-state behavior.  System design also addresses start & stop of the system.  Start  How does system go from a non initialized state to steady-state? –"start use cases”  Stop  What resources are cleaned up?  Which systems are notified upon stop –“stop use cases"  Failure  Bugs, bad user behavior, external problems (e.g., power supply).  System design foresees fatal failures –“failure use cases”

27. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 27 Boundary Condition Questions  Start  How does the system start?  What data must be accessed at start?  What services must be registered?  What is the user interface at start?  Human administration to initialize configuration data?  Stop  How are subsystems shut down gracefully?  What data must be stored at stop?  What services must be unregistered?  Failure  How does the system behave when a node or communication link fails?

28. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 28 Summary  Some activity of system design  Concurrency identification  Hardware mapping  Persistent data management  Global resource handling  Software control  Boundary conditions  Each activity addresses an aspect of subsystem decomposition.  When complete, subsystem interfaces are defined.

29. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 29 Drawing Subsystems in UML  System design models static & dynamic structures  Component Diagrams for static structures  show the structure at design time or compilation time  Deployment Diagram for dynamic structures  show the structure of the run-time system  Note the lifetime of components  Some exist only at design time  Others exist only until compile time  Some exist at link or runtime

30. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 30 Component Diagram  Component Diagram  A graph of components connected by dependency relationships.  Shows the dependencies among software components  source code, linkable libraries, executables  Dependencies are shown as dashed arrows from the client component to the supplier component.  The kinds of dependencies are implementation language specific.  A component diagram may also be used to show dependencies on a façade:  Use dashed arrow the corresponding UML interface.

31. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 31 Component Diagram Example UML Interface UML Component SchedulerPlannerGUI reservations update

32. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 32 Deployment Diagram  Deployment diagrams are useful for showing a system design after the following decisions are made  Subsystem decomposition  Concurrency  Hardware/Software Mapping  A deployment diagram is a graph of nodes connected by communication associations.  Nodes are shown as 3-D boxes.  Nodes may contain component instances.  Components may contain objects (indicating that the object is part of the component)

33. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 33 Deployment Diagram Example Runtime Dependency Compile Time Dependency :Planner :PC :Scheduler :HostMachine > meetingsDB

34. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 34 File or Database?  When should you choose a file?  Are the data voluminous (bit maps)?  Do you have lots of raw data (core dump, event trace)?  Do you need to keep the data only for a short time?  Is the information density low (archival files,history logs)?  When should you choose a database?  Do the data require access at fine levels of details by multiple users?  Must the data be ported across multiple platforms (heterogeneous systems)?  Do multiple application programs access the data?  Does the data management require a lot of infrastructure?

35. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 35 Object-Oriented Databases  Support all fundamental object modeling concepts  Classes, Attributes, Methods, Associations, Inheritance  Mapping an object model to an OO-database  Determine which objects are persistent.  Perform normal requirement analysis and object design  Create single attribute indices to reduce performance bottlenecks  Do the mapping (specific to commercially available product). Example:  In ObjectStore, implement classes and associations by preparing C++ declarations for each class and each association in the object model