Ch 7: Sys. Architecture: Design Decisions to Address Goals Qutaibah Malluhi Software Engineering Qatar University Based on slides by Bernd Bruegge & Allen H. Dutoit

System Architecture Design Define design goals Decompose into subsystems Subsystems are realized by individual teams Design decisions on building strategies Hardware/software mapping Concurrency Persistent data management Access control Global control flow Boundary conditions Chapter 6 Chapter 7

Hardware/Software Mapping Selection of platform (hardware configuration and software platform) Processors, memory, network, and Input/output OS platform (Linux, Windows, etc.), DB engine (Oracle, Sybase, etc.), communication protocols (TCP/IP, UDP, HTTP, etc.) Other off-the-shelf components How are the subsystems mapped on the chosen hardware & software? Mapping to processors: Parallel processing Mapping to computers: Client/server and distributed computing

Platform Selection Issue Examples Processor issues: Is the computation rate too demanding for a single processor? Can we get a 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? Is data caching useful? Caching strategy? Size? Etc. I/O and network issues: Do you need an extra piece of hardware to handle the data generation rate? Required data transfer bandwidth? Interconnection network (hypercube, mesh, Gigabit Ethernet, Infiniband etc.) and topology (star, ring, bus, etc.) Appropriate communication protocol? (RMI, Socket, HTTP, etc.)

Hardware/Software Mappings in UML System design must model static and dynamic structures: Component Diagrams for static structures Show the structure at design time or compilation time Deployment Diagram for dynamic structures show the static structure of the run-time system

Component Diagram Component: A physical and replaceable part of the system that compiles to an interface E.g., class libraries, frameworks, binary programs E.g., HTML editor, progress bar, spell-checker Component Diagram A graph of components connected by dependency relationships Model the high-level software components, and more importantly the interfaces to those components Shows the dependencies among software components Dependencies are shown as dashed arrows from the client component to the supplier component. A component diagram may also be used to show dependencies on a façade (face/interface): Use dashed arrow the corresponding UML interface.

Component Diagram Example Scheduler reservations UML Component UML Interface Planner update GUI

Component Diagram Example II

Deployment Diagram Used to show Subsystem decomposition Hardware/Software Mapping Shows a static view of the run-time configuration of processing nodes and the components that run on those nodes. I.e. shows Hardware for your system Software that is installed on that hardware, and Middleware used to connect the disparate machines to one another. Use for applications that are deployed to several machines (e.g., multi-tier applications) 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)

Deployment Diagram Example Compile Time Dependency :Scheduler :HostMachine <<database>> meetingsDB Runtime Dependency :Planner :PC

Concurrency Identify concurrent threads and address concurrency issues. Design goal: response time, performance A thread of control is a single sequential flow of control within a program 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?)

Concurrency Questions Which objects of the object model are independent? Does the system provide access to multiple users? Concurrent handling of user requests Improve response time Can a single request to the system be decomposed into multiple requests? Can these requests be handled in parallel? Improve performance How do we identify and manage concurrent access to shared resources?

Data Management Some objects in the models need to be persistent Data persistence Provide clean separation points between subsystems with well-defined interfaces. A persistent object can be realized with one of the following Files Flat files (unstructured data) XML files (semi-structured data) Database Relational DB (structured data) Object-oriented DB (store data as objects and associations) Other data structures E.g., raw disk, B-Tree, serialization, XML DB, etc. Hybrid data approaches are very common in practice

Data Management Files Databases Other data structures Cheap, simple, permanent storage Low level (Read/Write) Applications must handle many issues: concurrent access, data loss after a crash, etc. Databases Powerful, queries Structured data: schema Handles many issues on behalf of the application: concurrency, consistency, integrity, etc. Other data structures Needed for special application requirements/optimizations

File or Database? When should you choose a file? Voluminous data (e.g. bit maps) Lots of raw unstructured data (core dump, event trace) Transient data that lives for a short time Low information density (archival files, history logs) When should you choose a database? Access data at fine levels of details by multiple users Multiple application programs access the data Does the data management require a lot of infrastructure When should you use object-oriented database Need to reduce the cost/need to translate data to objects Quick development (higher-level interface) Not too many queries (queries are slower than relational DB)

Access Control Different actors have access to different functionality and data During analysis we model this by associating use cases with actors During system design we model this by determining which objects and functions are accessible to actors. Access rights for different classes for actors

Access Control Questions Authorization: How object guard against unauthorized access? Authentication: How do we verify the identity of actors? Privacy: Encryption requirements?

Access Matrix We model access on classes with an access matrix. Rows represent the actors of the system Columns represent classes whose access is controlled Access Right An entry in the access matrix (class, actor) Lists the operations that can be executed on instances of the class by the actor.

Access Matrix Example Access Right Corporation LocalBranch Account Objects  -------------------- Actors Corporation LocalBranch Account Teller postSmallDebit() PostSmallCredit() examineBalance() Manager examineBranceStates() postLargeDebit() PostLargeCredit() examineHistory() Analyst examineGlobalStates() Access Right

Access Matrix Implementations Global access table: Represents explicitly every cell in the matrix as a (actor, class, operation) tuple. Determining if an actor has access to a specific object requires looking up the corresponding tuple. If no such tuple is found, access is denied. Access control list associates a list of (actor, operation) pairs with each class to be accessed. Every time an object is accessed, its access list is checked for the corresponding actor and operation. Example: guest list for a party. A capability associates a (class, operation) pair with an actor. A capability provides an actor to gain control access to an object of the class described in the capability. Example: An invitation card for a party. Which is the right implementation?

Decide on Software Control Procedure-driven control Event-driven control Distributed control (Covered by Student Presentation -- Setarah)

Boundary Conditions Configuration Start-up Shutdown Exception handling (Covered by Student Presentation -- Setarah)

Summary We reviewed the design decisions activities suring system design: Hardware/Software mapping Concurrency identification Persistent data management Software control selection Boundary conditions Each of these activities revises the subsystem decomposition to address a specific issue. Once these activities are completed, the interface of the subsystems can be defined.