Overview Object-Oriented Software Engineering Chapter 7 System Design I (previous lecture) 0. Overview of System Design Addressing Design Goals 1. Design Goals 2. Subsystem Decomposition Using UML, Patterns, and Java System Design II 3. Concurrency 4. Hardware/Software Mapping 5. Persistent Data Management 6. Global Resource Handling and Access Control 7. Software Control 8. Boundary Conditions Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 2 3. Concurrency Implementing Concurrency ♦ Identify concurrent threads and address concurrency issues. ♦ Design goal: response time, performance. ♦ Concurrent systems can be implemented on any system that provides � physical concurrency (hardware) ♦ Threads � A thread of control is a path through a set of state diagrams on or which a single object is active at a time. � logical concurrency (software): Scheduling problem � A thread remains within a state diagram until an object sends an (Operating systems) event to another object and waits for another event � Thread splitting: Object does a nonblocking send of an event. ♦ Two objects are inherently concurrent if they can receive events at the same time without interacting ♦ Inherently concurrent objects should be assigned to different threads of control ♦ Objects with mutual exclusive activity should be folded into a single thread of control (Why?) Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 3 Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 4 Classroom Activity – Concurrency 4. Hardware Software Mapping Description: For your design identify the potential ♦ ♦ This activity addresses two questions: concurrency. � How shall we realize the subsystems: Hardware or Software? � Which objects of the object model are independent? � How is the object model mapped on the chosen hardware & � What kinds of threads of control are identifiable? software? � Does the system provide access to multiple users? � Mapping Objects onto Reality: Processor, Memory, Input/Output � Can a single request to the system be decomposed � Mapping Associations onto Reality: Connectivity into multiple requests? Can these requests be ♦ Much of the difficulty of designing a system comes from handled in parallel? meeting externally-imposed hardware and software constraints. Process: ♦ � Certain tasks have to be at specific locations � Meet as teams Choose a scribe to record design goals � � Use questions � You have about 5 minutes. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 5 Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 6 Page 1
Mapping the Subsystems Associations: Mapping the Objects Connectivity ♦ Processor issues: ♦ Describe the physical connectivity of the hardware � Is the computation rate too demanding for a single processor? � Often the physical layer in ISO’s OSI Reference Model � Can we get a speedup by distributing tasks across several � Which associations in the object model are mapped to physical processors? connections? � Which of the client-supplier relationships in the analysis/design model � How many processors are required to maintain steady state load? correspond to physical connections? ♦ Memory issues: � Is there enough memory to buffer bursts of requests? ♦ Describe the logical connectivity (subsystem associations) ♦ I/O issues: � Identify associations that do not directly map into physical � Do you need an extra piece of hardware to handle the data connections: generation rate? � How should these associations be implemented? � Does the response time exceed the available communication bandwidth between subsystems or a task and a piece of hardware? Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 7 Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 8 Typical Informal Example of a Connectivity Drawing Connectivity in Distributed Systems Physical Application Application Application Connectivity ♦ If the architecture is distributed, we need to describe the network Client Client Client architecture (communication subsystem) as well. TCP/IP Ethernet ♦ Questions to ask Logical LAN Connectivity � What are the transmission media? (Ethernet, Wireless) Communication Agent for � What is the Quality of Service (QOS)? What kind of communication Application Clients LAN Global protocols can be used? Data Communication Server � Should the interaction asynchronous, synchronous or blocking? Communication Agent for Data Backbone Network Agent for � What are the available bandwidth requirements between the OODBMS Server Application Clients subsystems? Communication Global � Stock Price Change -> Broker Agent for Data Data Server Server � Icy Road Detector -> ABS System LAN RDBMS Local Data Global Data Server Server Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 9 Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 10 Drawing Hardware/Software Mappings in Component Diagram UML ♦ System design must model static and dynamic structures: ♦ Component Diagram � Component Diagrams for static structures � A graph of components connected by dependency relationships. � show the structure at design time or compilation time � Shows the dependencies among software components � Deployment Diagram for dynamic structures � source code, linkable libraries, executables � show the structure of the run-time system ♦ Dependencies are shown as dashed arrows from the client component to the supplier component. ♦ Note the lifetime of components � The kinds of dependencies are implementation language specific. � Some exist only at design time ♦ A component diagram may also be used to show dependencies � Others exist only until compile time on a façade: � Some exist at link or runtime � Use dashed arrow the corresponding UML interface. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 11 Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 12 Page 2
Component Diagram Example Deployment Diagram ♦ Deployment diagrams are useful for showing a system design after the following decisions are made Scheduler reservations � Subsystem decomposition � Concurrency UML Component � Hardware/Software Mapping UML Interface Planner update ♦ 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 GUI of the component) Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 13 Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 14 Deployment Diagram Example CAT – Hardware/Software Mapping ♦ Description: For your design, map the software to hardware. Compile Time Dependency � What is the connectivity among physical units? Tree, star, matrix, ring � � What is the appropriate communication protocol between the subsystems? :HostMachine Function of required bandwidth, latency and desired reliability, desired quality � <<database>> of service (QOS) meetingsDB � Is certain functionality already available in hardware? � Do certain tasks require specific locations to control the hardware :Scheduler or to permit concurrent operation? Often true for embedded systems Runtime � � General system performance question: Dependency What is the desired response time? � Process: ♦ :PC � Meet as teams Choose a scribe to record design goals :Planner � � Use questions � You have about 10 minutes. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 15 Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 16 5. Data Management File or Database? ♦ Some objects in the models need to be persistent ♦ When should you choose a file? � Provide clean separation points between subsystems with well- defined interfaces. � Are the data voluminous (bit maps)? ♦ A persistent object can be realized with one of the following � Do you have lots of raw data (core dump, event trace)? � Data structure � Do you need to keep the data only for a short time? � If the data can be volatile � Is the information density low (archival files,history logs)? � Files ♦ When should you choose a database? � Cheap, simple, permanent storage � Do the data require access at fine levels of details by multiple users? � Low level (Read, Write) � Must the data be ported across multiple platforms (heterogeneous � Applications must add code to provide suitable level of abstraction systems)? � Database � Do multiple application programs access the data? � Powerful, easy to port � Does the data management require a lot of infrastructure? � Supports multiple writers and readers Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 17 Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 18 Page 3
Recommend
More recommend
