Ch 7: Sys. Architecture:

Design Decisions to Address GoalsQutaibah MalluhiSoftware EngineeringQatar 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

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

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

UML InterfaceUML Component

Scheduler

Planner

GUI

reservations

update

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

RuntimeDependency

Compile TimeDependency

:Planner

:PC

:Scheduler

:HostMachine

<<database>>meetingsDB

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

Objects --------------------

Actors

Corporation LocalBranch Account

Teller postSmallDebit()

PostSmallCredit()

examineBalance()

Manager examineBranceStates() postSmallDebit()

PostSmallCredit()

postLargeDebit()

PostLargeCredit()

examineBalance()

examineHistory()

Analyst examineGlobalStates() examineBranceStates()

AccessRight

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.