Lecture 02

Software Architecture
By Engr Muhammad Usman Malik

Sommerville, Mejia-Alvarez, 2009 Software Engineering, Slide 1

From Requirements to Architecture
 From problem definition to requirements specification
• Determine exactly what the customer and user want
• Specifies what the software product is to do
 From requirements specification to architecture
• How do we plan to build (design) the system ?
• Decompose software into modules with interfaces
• Specify high-level behavior, interactions, and non-functional properties
• Consider key tradeoffs
» Schedule vs. Budget
» Cost vs. Robustness
» Fault Tolerance vs. Size
» Security vs. Speed
• Maintain a record of design decisions and traceability
• Specifies how the software product is to do its tasks (from design to programming).

Sommerville, Mejia-Alvarez, 2009 Software Engineering, Slide 2

Architectural design
 An early stage of the system design process.
 Represents the link between specification and design
processes.
 Where do we finish requirements and start design ?.
 Often carried out in parallel with some specification
activities.
 It involves identifying major system components and
their communications.

Sommerville, Mejia-Alvarez, 2009 Software Engineering, Slide 3

Advantages of explicit architecture
 From Requirements to Design
 Stakeholder communication
• Architecture may be used as a focus of discussion by system
stakeholders.
 System analysis
• Means that analysis of whether the system can meet its non-
functional requirements is possible.
 Large-scale reuse
• The architecture may be reusable across a range of systems.
 From Design to Programming ,Testing &
Mantenaince.

Sommerville, Mejia-Alvarez, 2009 Software Engineering, Slide 4

Architecture and system characteristics
How the system must be designed to achieve:

 Performance
 Security
 Safety
 Reliability
 Availability
 Maintainability
 Quality

Sommerville, Mejia-Alvarez, 2009 Software Engineering, Slide 5

Architectural design process
 System structuring
• The system is decomposed into several principal sub-systems
and communications between these sub-systems are identified
 Control modelling
• A model of the control relationships between the different parts
of the system is established
 Modular decomposition
• The identified sub-systems are decomposed into modules

Sommerville, Mejia-Alvarez, 2009 Software Engineering, Slide 6

Design quality
 Design quality is an elusive concept. Quality
depends on specific organisational priorities
 A 'good' design may be the most efficient, the
cheapest, the most maintainable, the most
reliable, etc.
 The attributes discussed here are concerned
with the maintainability of the design
 Quality characteristics are equally applicable to
function-oriented and object-oriented designs

Sommerville, Mejia-Alvarez, 2009 Software Engineering, Slide 7

Design principles

 Abstraction
 Modularity, coupling and cohesion
 Information hiding
 Limit complexity
 Hierarchical structure
 Understandability
 Adaptability

Sommerville, Mejia-Alvarez, 2009 Software Engineering, Slide 8

Abstraction
 procedural abstraction: natural consequence of
stepwise refinement: name of procedure denotes
sequence of actions

abstraction subproblems

time

Sommerville, Mejia-Alvarez, 2009 Software Engineering, Slide 9

Abstraction
 data abstraction: aimed at finding a hierarchy in
the data
application-oriented
data structures

simpler data
general structure
data structures

Sommerville, Mejia-Alvarez, 2009 Software Engineering, Slide 10

Modularity
 structural criteria which tell us something about
individual modules and their interconnections

 cohesion and coupling

 cohesion: the glue that keeps a module together

 coupling: the strength of the connection between

modules

Sommerville, Mejia-Alvarez, 2009 Software Engineering, Slide 11

Cohesion
 A measure of how well a component 'fits
together'
 A component should implement a single logical
entity or function
 Cohesion is a desirable design component
attribute as when a change has to be made, it
is localised in a single cohesive component
 Various levels of cohesion have been identified

Sommerville, Mejia-Alvarez, 2009 Software Engineering, Slide 12

Cohesion levels
 Coincidental cohesion (weak)
• Parts of a component are simply bundled together
 Logical association (weak)
• Components which perform similar functions are grouped
 Temporal cohesion (weak)
• Components which are activated at the same time are grouped
 Procedural cohesion (weak)
• The elements in a component make up a single control
sequence

Sommerville, Mejia-Alvarez, 2009 Software Engineering, Slide 13

Cohesion levels
 Communicational cohesion (medium)
• All the elements of a component operate on the same input or
produce the same output
 Sequential cohesion (medium)
• The output for one part of a component is the input to another part
 Functional cohesion (strong)
• Each part of a component is necessary for the execution of a single
function
 Object cohesion (strong)
• Each operation provides functionality which allows object attributes
to be modified or inspected

Sommerville, Mejia-Alvarez, 2009 Software Engineering, Slide 14

Cohesion as a design attribute
 Not well-defined. Often difficult to classify
cohesion
 Inheriting attributes from super-classes
weakens cohesion
 To understand a component, the super-classes
as well as the component class must be
examined
 Object class browsers assist with this process

Sommerville, Mejia-Alvarez, 2009 Software Engineering, Slide 15

Coupling
 A measure of the strength of the inter-connections
between system components
 Loose coupling means component changes are
unlikely to affect other components
 Shared variables or control information
exchange lead to tight coupling
 Loose coupling can be achieved by state
decentralisation (as in objects) and component
communication via parameters or message
passing

28
Sommerville, Mejia-Alvarez, 2009 Software Engineering, Slide 16
Tight coupling

Module A Module B

Module C Module D

Shared data
area

Sommerville, Mejia-Alvarez, 2009 Software Engineering, Slide 17

Loose coupling
Module A

A’s data

Module B Module C

B’s data C’s data

Module D

D’s data

Sommerville, Mejia-Alvarez, 2009 Software Engineering, Slide 18

Coupling and inheritance
 Object-oriented systems are loosely
coupled because there is no shared state and
objects communicate using message passing
 However, an object class is coupled to its
super-classes. Changes made to the attributes
or operations in a super-class propagate to all
sub-classes. Such changes must be carefully
controlled

Sommerville, Mejia-Alvarez, 2009 Software Engineering, Slide 19

Information hiding
 each module has a secret
 design involves a series of decision: for each such
decision, wonder who needs to know and who can
be kept in the dark
 information hiding is strongly related to
• abstraction: if you hide something, the user may abstract from that
fact
• coupling: the secret decreases coupling between a module and its
environment
• cohesion: the secret is what binds the parts of the module together

Sommerville, Mejia-Alvarez, 2009 Software Engineering, Slide 20

Complexity
 measure certain aspects of the software (lines of
code, # of if-statements, depth of nesting, …)
 use these numbers as a criterion to assess a design,
or to guide the design
 interpretation: higher value  higher complexity
 more effort required (= worse design)
 two kinds:
• intra-modular: inside one module
• inter-modular: between modules

Sommerville, Mejia-Alvarez, 2009 Software Engineering, Slide 21

Top-down design
 In principle, top-down design involves starting
at the uppermost components in the hierarchy
and working down the hierarchy level by level
 In practice, large systems design is never
truly top-down. Some branches are designed
before others. Designers reuse experience (and
sometimes components) during the design
process

Sommerville, Mejia-Alvarez, 2009 Software Engineering, Slide 22

Hierarchical design structure
System level

Sub-system
level

Sommerville, Mejia-Alvarez, 2009 Software Engineering, Slide 23

Understandability
 Related to several component characteristics
• Cohesion. Can the component be understood on its own?
• Naming. Are meaningful names used?
• Documentation. Is the design well-documented?
• Complexity. Are complex algorithms used?
 Informally, high complexity means many
relationships between different parts of the
design. hence it is hard to understand
 Most design quality metrics are oriented
towards complexity measurement. They are
of limited use

32
Sommerville, Mejia-Alvarez, 2009 Software Engineering, Slide 24
Adaptability
 A design is adaptable if:
• Its components are loosely coupled
• It is well-documented and the documentation is up to date
• There is an obvious correspondence between design levels
(design visibility)
• Each component is a self-contained entity (tightly cohesive)
 To adapt a design, it must be possible to trace the
links between design components so that change
consequences can be analysed

33
Sommerville, Mejia-Alvarez, 2009 Software Engineering, Slide 25
Design traceability
C
F
B
D Object interaction
A level

P O R
Object decomposition
level

Sommerville, Mejia-Alvarez, 2009 Software Engineering, Slide 26

Key points
 Design is a creative process
 Design activities include architectural design,
system specification, component design, data
structure design and algorithm design

36
Sommerville, Mejia-Alvarez, 2009 Software Engineering, Slide 27