Ch 6: Sys. Architecture Design: System Decomposition Qutaibah Malluhi Software Engineering Qatar University Based on slides by Bernd Bruegge & Allen H.

Ch 6: Sys. Architecture Design: System Decomposition

Qutaibah MalluhiSoftware EngineeringQatar University

Based on slides by Bernd Bruegge & Allen H. Dutoit

System Architecture Design

Analysis: Focuses on the application domain Design: Focuses on the solution domain

Define design goals Decompose into subsystems

Subsystems are realized by individual teams

Design decisions on building strategies Hardware/software mapping Concurrency Persistent data management Global control flow Access control Boundary conditions

Chapter 6

Chapter 7

System Design Activities

2. System

Layers/PartitionsCohesion/Coupling

5. Data

1. Design Goals

DefinitionTrade-offs

4. Hardware/

Special purpose

Software

Buy or Build Trade-offAllocationConnectivity

3. Concurrency

Data structure

Persistent ObjectsFilesDatabases

ManagementAccess controlSecurity

6. Global Resource Handling

8. BoundaryConditions

InitializationTerminationFailure

Decomposition

Mapping

7. Software Control

Identification of Threads

MonolithicEvent-DrivenThreadsConc. Processes

System DesignSystem Design

System Arch. Design Overview

System design

Object design

object designmodel

design goals

subsystemdecomposition

Analysis

analysis objectmodel

dynamic model

nonfunctionalrequirements

Includes:Subsystems and their dependenciesDesign strategiesBoundary use cases

Includes:Subsystems and their dependenciesDesign strategiesBoundary use cases

From nonfunctional requirements

From nonfunctional requirements

List of Design Goals Good documentation Well-defined interfaces User-friendliness Reuse of components Rapid development Minimum # of errors Readability Ease of learning Ease of remembering Ease of use Increased productivity Low-cost Flexibility

Reliability Modifiability Maintainability Understandability Adaptability Reusability Efficiency Portability Traceability of requirements Fault tolerance Backward-compatibility Cost-effectiveness Robustness High-performance

Relationship Between Design Goals

Reliability

Low cost Increased ProductivityBackward-CompatibilityTraceability of requirementsRapid developmentFlexibility

Client

End User

(Customer,

PortabilityGood Documentation

RuntimeEfficiency

Sponsor)

Developer/Maintainer

Minimum # of errorsModifiability, ReadabilityReusability, AdaptabilityWell-defined interfaces

FunctionalityUser-friendlinessEase of UseEase of learningFault tolerantRobustness

Typical Design Trade-offs

Cost vs. Fault Tolerance Efficiency vs. Portability Rapid development vs. Functionality Functionality vs. Usability Cost vs. Reusability Backward Compatibility vs. Readability

2. System Decomposition

1. Decompose into Subsystems. Subsystem

Simpler part of the system Can be handled by a single developer or development

team Modeled as UML packages Some languages have subsystem modeling constructs

Java packages In other languages (e.g. C & C++) subsystems are represented

as directories with all related files

2. Define on services provided by each subsystem Specified by the subsystem interface

3. Define relationships among subsystems

Services and Subsystem Interfaces

(Subsystem) Service: Group of operations provided by the subsystem A set of related operations that share a common

purpose

Service is specified by subsystem interface: Set of fully typed related operations Specifies interaction at subsystem boundaries (not

inside the subsystem) Should be well-defined and small. Also called API: Application Programming Interface

The term API is often used during implementation, not during system design

Choosing Subsystems

Criteria for subsystem selection: Most of the interaction should be within

subsystems, rather than across subsystem boundaries (high cohesion + low coupling)

Questions: What kind of service is provided by the

subsystems (subsystem interface)?What kind of model describes the relationships

among subsystems (layers and partitions)?

Coupling and Cohesion

Goal: Reduction of complexity while change occurs Cohesion measures the dependence within a subsystem

High cohesion: The classes in the subsystem perform similar tasks and are related to each other (via associations)

Low cohesion: Lots of miscellaneous and auxiliary classes, no associations

Coupling measures dependencies between subsystems High/tight coupling: Changes to one subsystem will have high

impact on other subsystems (change of model, massive recompilation, etc.)

Low coupling: A change in one subsystem does not affect other subsystems

Subsystems should have maximum cohesion and minimum coupling as possible

Partitions and Layers

Partitioning and layering are techniques to achieve low coupling.

A large system is usually decomposed into subsystems using both, layers and partitions.

Partitions vertically divide a system into several independent (or weakly-coupled) subsystems that provide services on the same level of abstraction.

A layer is a subsystem that provides subsystem services to a higher layers (level of abstraction) A layer can only depend on lower layers A layer has no knowledge of higher layers

Relationships between Subsystems

Layer relationshipLayer A “Calls” Layer B (runtime)Layer A “Depends on” Layer B (“make”

dependency, compile time) Partition relationship

The subsystem have mutual but not deep knowledge about each other

Partition A “Calls” partition B and partition B “Calls” partition A

Software Architectural Styles

Subsystem decomposition Identification of subsystems, their services, and their relationship

to each other.

System may conform to a generic architectural model or style. Examples: Abstract machine (or layered) Repository (shared data) Client/Server

Thin client, thick client, multi-tier Peer-To-Peer Model/View/Controller Pipes and Filters Service-oriented architecture

Layered (Abstract Machine) Style

Layered systems are hierarchical: Organised into a set of layers (or abstract machines) each of which provide a set of services. A layer can only depend on lower layers Closed layering: only depend on layer immediately below

Reduce complexity (by low coupling) When a layer interface changes, only the adjacent layer is affected Less efficient: speed and storage overhead of each layer in the path

If a subsystem is a layer, it is often called a virtual machine.

Supports the incremental development of sub-systems in different layers. When a layer interface changes, only the adjacent layer is affected

OSI and TCP/IP Layered Models

Application

Presentation

Session

Transport

Network

DataLink

Physical

Socket

TCP/IP

Object

Ethernet Wire

Application

OSI model Layers‘ Responsibilities

The Physical layer represents the hardware interface to the net-work. It allows to send() and receive bits over a channel.

The Datalink layer allows to send and receive frames without error using the services from the Physical layer.

The Network layer is responsible for that the data are reliably transmitted and routed within a network.

The Transport layer is responsible for reliably transmitting from end to end. (This is the interface seen by Unix programmers when transmitting over TCP/IP sockets)

The Session layer is responsible for initializing a connection, including authentication.

The Presentation layer performs data transformation services, such as byte swapping and encryption

The Application layer is the system you are designing (unless you build a protocol stack). The application layer is often layered itself.

Repository Architecture Style (I)

Sub-systems must exchange data. This may be done in two ways:Shared data is held in a central data structure

or repository and may be accessed by all sub-systems;

Each sub-system maintains its own data structure and passes data explicitly to other sub-systems.

When large amounts of data are to be shared, the repository model of sharing is most commonly used.

Repository Architectural Style (II)

Subsystems access and modify data from a single data structure

Subsystems are loosely coupled (interact only through the repository)

Control flow is dictated by central repository (triggers) or by the subsystems (locks, synchronization primitives)

Subsystem

Repository

createData()setData()getData()searchData()

Repository Style Characteristics Advantages

Efficient way to share large amounts of data Easy to deal with concurrent access and data integrity among

different subsystems Centralised data management e.g. backup, security, etc.

Disadvantages Central repository can become the performance bottleneck Tight coupling between subsystems and repository

Modifiability limitations Sub-systems depend on the repository data model Data evolution is difficult and expensive

No scope for subsystem-specific (rather than global) management policies;

Examples of Repository Architectures Database Applications Modern Compilers and IDEs Case Tools

Model/View/Controller Arch. Style Subsystems are classified into 3 different types

Model subsystem: Maintains application domain knowledge View subsystem: Display application domain objects to the user Controller subsystem: Responsible for sequence of interactions with

the user and notifying views of changes in the model. Model is independent of View and Controller

Propagate model changes through subscribe/notify protocol MVC is a special case of a repository architecture:

Model subsystem implements the central datastructure, the Controller subsystem explicitly dictate the control flow

Controller

Model

subscribernotifier

initiator

*

repository1

1

*

View

MVC Example: File System

Consider changing the file name

Sequence of Events (Collaborations)

:Controller

:InfoView

:Model

2.User types new filename

1. View subscribes to event

3. Request name change in model

4. Notify subscribers5. Updated views

:FolderView

1. View subscribes to event

MVC Advantages

Easy to modify user interfacesUser interfaces changes more often than

modelUser interface is independent from the modelGood for systems with multiple views of the

same model Similar to advantages and disadvantages

of repository (model is the repository)

Client/Server Architectural Style

One or many servers provides services to instances of subsystems, called clients.

Client calls on the server, which performs some service and returns the result Client knows the interface of the server (its service) Server does not need to know the interface of the client

Response in general immediately Users interact only with the client

Client

Server

service1()service2()

serviceN()…

**

requester provider

Client/Server Application Examples Network applications

FTP WWW Chat

Database applications Front-end: User application (client)

User input through customized user interface Front-end processing of data Initiation of transactions Typically access to database server across the network

Back end: Database access and manipulation (server) Centralized data management Data integrity and database consistency Database security Concurrent operations (multiple user access) Centralized management (for example archiving)

Client/Server Substyles

Thin client Fat client Multi-tier

Distinction is based on distribution of application functionality described in the Layered Application Architecture (see next slides)

Layered Application Architecture

Presentation layer Present results of a computation to

system users and collect user inputs

Application logic layer Business rules, processes and

application-specific functions. E.g., in a banking system, banking functions such as open account, close account, etc.

Data management layer Concerned with managing the system

databases

PresentationPresentation

Application LogicApplication Logic

Data ManagementData Management

Thin and fat clients Thin-client model

Application processing (business logic) and data management is carried out on the server. The client is simply responsible for running the presentation software.

Fat-client model The server is only responsible for data management. The software on the client

implements the business logic and the interactions with the system user.

ClientClient

ServerServer

Data ManagementApplication Logic

Data ManagementApplication Logic

Presentation

Thin Client

ClientClient

ServerServer

Data ManagementData Management

PresentationApplication Logic

Fat Client

Thin client model

Used when legacy systems are migrated to client server architectures. The legacy system acts as a server in its own right with

a graphical interface implemented on a client.

The small-size thin client software can be downloaded on-the-fly before running E.g. Web-based clients

A major disadvantage is that it places a heavy processing load on both the server and the network.

Fat client model

More processing is delegated to the client as the application processing is locally executed.

Most suitable for new C/S systems where the capabilities of the client system are known in advance.

More complex than a thin client model especially for management. New versions of the application have to be installed on all clients.

Three-tier architectures

In a three-tier architecture, each of the application architecture layers may execute on a separate processor.

Allows for better performance than a thin-client approach and is simpler to manage than a fat-client approach.

A more scalable architecture - as demands increase, extra servers can be added.

ClientClient

ServerServer

Application LogicApplication Logic

Presentation

Three-Tier

ServerServer

Data ManagementData Management

3-Tier Example: Internet banking system

Database server

Customeraccountdatabase

Web serverClient

Client

Account serviceprovision

SQLSQL query

HTTP interaction

Client

Client

Use of C/S architectures

Architecture Applications

Two-tier C/S architecture with thin clients

Legacy system applications where separating application processing and data management is impractical.

Computationally-intensive applications such as compilers with little or no data management.

Data-intensive applications (browsing and querying) with little or no application processing.

Two-tier C/S architecture with fat clients

Applications where application processing is provided by off-the-shelf software (e.g. Microsoft Excel) on the client.

Applications where computationally-intensive processing of data (e.g. data visualisation) is required.

Applications with relatively stable end-user functionality used in an environment with well-established system management.

Three-tier or multi-tier C/S architecture

Large scale applications with hundreds or thousands of clients Applications where both the data and the application are volatile. Applications where data from multiple sources are integrated.

Peer-to-Peer Architectural Style

Generalization of Client/Server Architecture Clients can be servers and servers can be clients More difficult because of possibility of deadlocks

Peer

service1()service2()

serviceN()…

requester

provider

*

*

Peer

Client Server

Summary

Analysis: Focuses on the application domain Design: Focuses on the solution domain

Define design goals Decompose into subsystems

Subsystems are realized by individual teams

Design decisions on building strategies Hardware/software mapping Concurrency Persistent data management Global control flow Access control Boundary conditions

Chapter 6

Chapter 7