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

2. 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

3. 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

4. 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.)

5. 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

6. 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.

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

8. Component Diagram Example II

9. 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)

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

11. 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?)

12. 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?

13. 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

14. 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

15. 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)

16. 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

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

18. 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.

19. 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

20. 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?

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

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

23. 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.