Software Engineering

Lecture 5
Software Architecture.
Reading:
Ian Summerville, Software Engineering (Chapter 6 – Architectural
Design)
 Software Architecture
• Software Architecture: technical decisions made early
in a project that are expensive to change
– E.g your software is it client/server or layered?
– Is it distributed or works on one computer?
– How is one component planned to send data to another
(method call, messaging, …)?

• Software Architecture is the first step in Software

Design

• “Good software architecture makes the rest of the

project easy.”
Steve McConnell, Survival Guide
2
Why SW Architecture

Requirements

How do you bridge

????
the gap between
requirements and code?

Code

3
Better answer

Requirements

Provides high level

Software Architecture
framework to build and
evolve the system

Code

4
 Software Architecture
“The architecture of a software system defines that
system in terms of computational components and
interactions among those components. …

In addition to specifying the structure and topology of

the system, [a good] architecture shows the
correspondence between the requirements and
elements of the constructed system, thereby providing
some rationale for the design decisions.”
- Shaw & Garlan 96

5
 Architecture Example
• Boxes are components and Arrows are Interactions
– Boxes within boxes indicate that the component has been
decomposed to sub-components
component
connector

6
 Software Architecture
• Components define a unit of computations or data
store comprising the system and their behaviors
– A component is an implementation of a subsystem.
• E.g client and server components/subsystems
• E.g Network, transport, application components/subsystems
• E.g Game UI, Game Event handler, Game Engine components
– Has an interface specifying the services it provides
– A unit of reuse and replacement
– A unit of deployment
• Connectors define the interconnections between
components
– procedure call, event announcement, asynchronous
message sends, etc. through an interface
• Difference between connector and components is
7
 What is Good Architecture?
• A good architecture satisfies functional requirements
– Components host functionality (functional requirements)

• A good architecture meets non-functional requirements

– If performance is critical requirement:
• Architecture should localize critical operations within a few
relatively large components
– Components deployed on the same computer rather than
distributed across the network.
– Reduces the number of component communications

• Architecture should consider run-time system organizations

that allow the system to be replicated and executed on
different processors

8
 What is Good Architecture?
• A good architecture satisfies functional requirements
– Components host functionality (functional requirements)

• A good architecture meets non-functional requirements

– If security is critical requirement:
• A layered structure for the architecture should be used,
– The most critical assets protected in the innermost layers, with a
high level of security validation.

– If safety is a critical requirement:

• Architecture should put safety-related operations in a single
component or in a small number of components.
– Reduces the costs and problems of safety validation
– Provides related protection systems that can safely shut down the
system in the event of failure.
9
 What is Good Architecture?
• A good architecture satisfies functional requirements
– Components host functionality (functional requirements)

• A good architecture meets non-functional requirements

– If availability is a critical requirement
• The architecture should include redundant components
– Makes it possible to replace and update components without
stopping the system.

– If maintainability is a critical requirement:

• The architecture should be designed self-contained
components that may readily be changed.
• Producers of data should be separated from consumers
• Shared data structures should be avoided.
10
 What is Good Architecture?
• A good architecture satisfies functional requirements
– Components host functionality (functional requirements)

• A good architecture meets non-functional requirements

– What if performance and maintainability are our
requirements
• Using large components improves performance and using
small, fine-grain components improves maintainability.
• Achieved by using different architectural patterns or styles
for different parts of the system
• Some compromise must be found

11
Drawing Architecture
Symbols

13
 UML (Unified modeling
language)
• A standardized way to describe (draw) architecture
– Also implementation details such as sub classing,
dependences, and much more
Web application
• UML represents components as:

• Node is a physical component: Represents Server

hardware or software objects, which are
of a higher level than components.

• Components are deployed on a node:

Web application

14
15
 Component Diagram
• Architectures can be expressed as component
diagrams in UML

WebBrowser WebServer
HTTP

interface

16
Library system

17
 Deployment Diagram
Deployment diagrams have several valuable
applications. You can use them to
• Show which software elements are deployed by which
hardware elements.
• Illustrate the runtime processing for hardware.
• Provide a view of the hardware system’s topology.

18
 Deployment Diagram
• Deployment diagrams also express another view of the
Architecture. nodes

PersonalComp DeptServer

WebBrowser WebServer

components

19
 Architectural Styles

An architectural style is system architecture that recurs in

many different applications.
See: Mary Shaw and David Garlan, Software architecture:
perspectives on an emerging discipline. Prentice Hall,
1996

20
 Architectural Styles

• Layered

• Repository

• Client/Server

• Pipe and filter

21
 Layered Architecture
• Layers up will use services from layer beneath them
• the system functionality is organized into separate layers

22
Advantages
• Allows replacement of entire layers so long as the interface is
maintained.
• Redundant facilities (e.g., authentication) can be provided in each
layer to increase the dependability of the system.

Disadvantages
• In practice, providing a clean separation between layers is often
difficult and a high-level
• Performance can be a problem because of multiple levels of
interpretation of a service request as it is processed at each layer.

23
Library system example

24
 Architectural Style:
Repository
Input Transactions
components

Repository

• The majority of systems that use large amounts of data are

organized around a shared database or repository.
Advantages: Flexible architecture for data-intensive systems.
Disadvantages: Difficult to modify repository since all other
components are coupled to it.
25
 Architectural Style: Repository
with Storage Access Layer

Repository

Input Storage Transactions

components Access

This is sometimes
called a "glue" layer
Data Store

Advantages: Data Store subsystem can be changed without

modifying any component except the Storage Access.
26
 Architectural Style:
Client/Server
Web example: Serving static pages

Firefox Apache
client server

The control flows in the client and the server are independent.
communication between client and server follows a protocol.

In a peer-to-peer architecture, the same component acts as

both a client and a server.

27
Advantages
• servers can be distributed across a network.
• General functionality (e.g., a printing service) can be available to all
clients and does not need to be implemented by all services.
Disadvantages
• Each service is a single point of failure so susceptible to denial of
service attacks or server failure.
• Performance may be unpredictable because it depends on the network
as well as the system.
• May be management problems if servers are owned by different
organizations.

28
Architectural Style: Pipe

Example: A three-pass compiler

Lexical Parser Code

analysis generation

Chain or pipe of components

Output from one subsystem is the input to the next.

29
Advantages
• Easy to understand and supports transformation.
• Can be implemented as either a sequential or concurrent system.

Disadvantages
• The format for data transfer has to be agreed upon between
communicating transformations.
• Each transformation must parse its input and un parse its output to the
agreed form. This increases system overhead and may mean that it is
impossible to reuse
30
 Three Tier Architecture

Presentation Application DataAccess

tier tier tier

• run-time organization
Web example: Serving dynamic pages
Each of the tiers can be replaced by other components that
implement the same interfaces
Very very common (also called MVC – Model (db), View
(presentation), Controller(application tier))
This is the architecture you will probably use
31
 Architectural Style:
Three Tier Architecture
These components might be
located on a single node

Firefox Apache MySQL

HTTP JDBC

32
UML Notation: Package

JavaScript

A package is a general-purpose mechanism for organizing

elements into groups.
Note: Some authors draw packages with a different shaped box:

JavaScript

We use package diagram to depict import and access dependencies

between packages, classes, components, and other named elements
within your system.
33
Example: Web Browser
WebBrowser
Each package
HTMLRender represents a group of
classes.

JavaScript

HTTP

34
 Other Architectures
• Read Sommervillie, Software Engineering, Chapter 6
• Read more on UML diagrams we learned so far(component,
deployment and package).
• Read more on three tier architecture.
• Reminder for SRS Submission and presentation

35