Software Architecture

CSCI 5801: Software Engineering

Software Architecture

Software Architecture

Architecture is the fundamental organization of a system embodied in its components, their relationships to each other and to the environment and the principles guiding its design and evolution

(from IEEE Standard on the Recommended Practice for Architectural Descriptions, 2000.)

Decomposition

• Main goal: Decompose overall system into components connected by interfaces– Component simple enough to be implemented by

smaller teams– Interfaces well defined enough to allow

independent development

• Architecture: shows components of a system and their interface relationships

UML for Components

• Node– Physical device (computer,

sever, etc) which is part of system

• Component– Significant subsystem that

implements an interface

• Package– Submodule of a component, such as

a set of related classes

UML for Interfaces

• Component 1 implements Interface, with methods Operation1 and Operation2

• Component 2 communicates with Component 1 through that interface by calling those methods

UML Example

• Client-server system:– A client computer running a browser communicates with a

server running Tomcat through the GET and POST protocols– The Tomcat server uses JSPs, control servlets, and business

logic classes

Physical Architectures

• Highest levels of architecture often determined by physical location and other restrictions (such as security)

• Interfaces then designed to enable communication

Additional UML for Design

• Sequence diagrams also common in design• Specify data flow between major components

of system instead of between system and users

• Can also specify methods called and data passed/returned

Sequence Diagrams

User

Login Logic

WithdrawInterface

Withdraw Logic

Account Database

Accountdatabase

AccountObject

constructconstruct

constructIDID

IDquery

account dataaccount data

construct

ID, type

accountType, amount

withdraw (accountType, amount)

hasAccount

account data

[1] withdraw (amount)

[2] IllegalAmount

[3] Error message

[3] InsufficientBalance[3] Insufficient

Balance [1] setBalance (amount, accountType)

[1] update

[2] Error message

[3] Confirmation message

Role of the Client

• Client usually involved in high-level architecture design– Architecture (particularly physical) affects cost– Not involved at lower level (class design, etc.)

• Usual step: present high-level architecture to client for approval– Can be done at requirements stage

• No fixed representation (like UML) for this– Whatever the client might best understand

Example Architecture

Example Architecture

Example Architecture

Example Architecture

Iterative Decomposition

• Decomposition done iteratively– System network of components– Component set of packages– Package set of classes …

• Key idea: – A subteam responsible for a module can make own

decisions about how to best decompose that module– Only restriction: Must make sure module

implements required interface

Iterative Decomposition Example

• Overall team decides on client-server architecture

• Web server team decides on model-view-control paradigm

• Web design subteam creates template page and derives all pages from it

Decomposition Methods

• Functional decomposition• Data-driven decomposition• Object-oriented decomposition• Process-oriented decomposition• Event-oriented decomposition• And many others…

• Often influence overall system architecture

Functional Decomposition

• Indentify top-level functions than meet requirements• Decompose into simpler subfunctions (looking for

reuse)Requirement Requirement

Requirement

FunctionFunction

Sub-function Sub-function Sub-function

Sub-function Sub-function Sub-function

Data-driven Decomposition

• Identify major data system needs to store– Decompose into simpler components– Identify what components might be stored where

Section

Course Info

Time Instructor Room

Days Hours

Roster

Students

Course Inventory Roster Database

Student Database

Object-oriented Decomposition

• Combines data-driven decomposition and functional attributes– Each class contains all methods needed to

manipulate its data– Packages are sets of classes– Classes can implement an interface

• Object-oriented decomposition concerned with identifying object classes, their attributes and operations

Process-oriented Decomposition

• Decompose requirements into series of steps• Design component for each step (looking for

reuse among different requirements)

Process step A Process step B

Process step C Process step D Process step E

Process step F

Requirement

Requirement

Event-driven Decomposition

• Identify main external signals system must handle

• Create a component for each

Handler1

Handler2

Handler3

Handler4

Process1

Process2

Process3

Process4

Interrupts

Interruptvector

Design and Reuse

• Most architecture based on existing systems– Most good design ideas have already been created

• Overall architectures based on common styles• Components based on design patterns

Common Architectural Styles

• Centralized control• Layered• Distributed objects• Repository • Pipelining• Client/Server• Event-driven

Centralized Control

• A control component manages the execution of other components

• Call-return model– Top-down subroutine model where control starts at

the top of a subroutine hierarchy and moves downwards.

• Manager model– Applicable to concurrent systems. One system

component controls the stopping, starting and coordination of other system processes.

Call-return Model

Routine 1.2Routine 1.1 Routine 3.2Routine 3.1

Routine 2 Routine 3Routine 1

Mainprogram

Manager Model

Systemcontroller

Userinterface

Faulthandler

Computationprocesses

Actuatorprocesses

Sensorprocesses

Centralized Control

• Advantages:– Simple to implement, debug as all actions can be

traced to single point

• Disadvantages:– Centralized control must be error free– Can become overwhelmed in concurrent systems

Layered Model

• System organized into layers of components• Each layer only communicates with previous

and next layer

Layern

Layer2

Layer1

3-Tier Architecture

Data AccessUser Interface Business Logic

OrderDatabase

ProductDatabase

UI developers just need to know UI design and how to call business logic methods

Business logic developers just need to know business model, how will be called by UI, and how to call data access methods

Data access developers just need to know SQL and database design and how will be called by business logic

Layered Model

• Advantages:– Limited communication greatly simplifies interface

design, as designers of each layer only have to worry about 2 other layers

• Disadvantages:– May not be possible to subdivide system in this

way (what are layers in registration system?)

Object Model

• System decomposed into a set of loosely coupled objects with well-defined interfaces

• When implemented, objects are created from these classes and some control model used to coordinate object operations– Control components created at start, persist

throughout operation– Other components created/destroyed as needed

Object Model

• UI (persistent component) creates customer invoice and supporting objects as needed from database

issue ()sendReminder ()acceptPayment ()sendReceipt ()

invoice#dateamountcustomer

invoice#dateamountcustomer#

invoice#dateamountcustomer#

customer#nameaddresscredit period

Customer

Payment

Invoice

Receipt

Object Model

• Advantages:– OOP design is highly modular, allowing developers

to easily create and test objects, as well as reuse among multiple project

• Disadvantages:– Complex entities may be hard to represent as

objects– May not be most efficient implementation

Repository Model

• Data to be shared among subsystems kept in single location

• All components communicate with repository to access/modify data

Repository Model

Projectrepository

Designtranslator

Programeditor

Designeditor

Codegenerator

Designanalyser

Reportgenerator

Repository Model

• Advantages– Efficient way to share large amounts of data– Centralised management (backup, security, etc.)

• Disadvantages– Components must agree on a repository data

model. Inevitably a compromise– Difficult to distribute data efficiently, resulting in

slowdowns

Pipelining Model

• Functional transformations process their inputs to produce outputs

• Input of next stage is output of previous stage• “Pipe and filter model” in UNIX shell• Same as batch sequential model extensively

used in data processing systems

Pipelining Model

Read issuedinvoices

Identifypayments

Issuereceipts

Findpayments

due

Receipts

Issuepaymentreminder

Reminders

Invoices Payments

Pipelining Model

• Advantages– Can support concurrent processing– Easy to add new transformations to pipeline, or

reuse filters in other projects• Disadvantages

– Requires a common format for data transfer along the pipeline

– Not really suitable for interactive systems

Client-Server Model

• Data and processing is distributed across a range of components– Stand-alone servers which provide specific

services such as printing, data management, etc.– Set of clients which call on these services– Network which allows clients to access servers

Client-Server Model

Catalogueserver

Librarycatalogue

Videoserver

Film clipfiles

Pictureserver

Digitisedphotographs

Web server

Film andphoto info.

Client 1 Client 2 Client 3 Client 4

Internet

Client-Server Model

• Advantages– Simple distribution of data– Makes effective use of networked systems– Easy to add new servers or upgrade existing servers

• Disadvantages– No simple way to coordinate activities or data over all

servers (hard to get list of all items accessed, for example)

– Redundant management in each server

Event-driven Model

• Driven by externally generated events where the timing of the event is outside the control of the components which process the event

• Two principal event-driven models– Broadcast models: An event is broadcast to all

subsystems. Any subsystem which can handle the event may do so

– Interrupt-driven models: Used in real-time systems where interrupts are detected by an interrupt handler and passed to some other component

Broadcast Model

• Effective integration of different computers in a network. Subsystems register an interest in specific events. When these occur, control is transferred to the sub-system which can handle the event.

• However, no guarantee any subsystems will handle an event

Sub-system1

Event and message handler

Sub-system2

Sub-system3

Sub-system4

Interrupt-driven Systems

• Used in real-time systems for fast response• There are known interrupt types with a handler defined

for each type• However, complex to program and difficult to validate

Handler1

Handler2

Handler3

Handler4

Process1

Process2

Process3

Process4

Interrupts

Interruptvector