2010-08-31
Introduktion till Software Engineering
Why are we here?
It’s harder to build solid software than it is to build a solid bridge

Size and complexity makes it harder

Teams make it harder (and easier)

Customers make it harder

Your project is hard
Software engineering is an answer

Methods for tackling the problem
2
Linköpings universitet
1
2010-08-31
What is software engineering?
The application of a systematic, disciplined, quantifiable approach to the
development,
p
operation,
p
and maintenance of software; that is, the
application of engineering to software.
– IEEE Software Engineering Body of Knowledge
Engineering is:
The creative application of scientific principles to design or develop
structures, machines, apparatus, or manufacturing processes, or works
utilizing them singly or in combination; or to construct or operate the same
with full cognizance of their design; or to forecast their behavior under
specific operating conditions; all as respects an intended function,
economics of operation and safety to life and property.
– Engineers Council for Professional Development
3
What is software engineering?
 It’s about communication and managing risk
What the customer described
How the project leader
understood it
How the analyst designed it
What the customer
really needed
4
www.projectcartoon.com
Linköpings universitet
2
2010-08-31
What is software engineering?
 It’s about communication and managing expectations
What the customer described
How the business consultant
described it
What the customer
really needed
What marketing advertised
5
www.projectcartoon.com
What is software engineering?
 It’s about being professional and delivering quality
How it was documented
How it was supported
When it was delivered
How the customer was billed
6
www.projectcartoon.com
Linköpings universitet
3
2010-08-31
Agenda
Irrelevant image just to fill the empty space
Processes

Process models

Process frameworks
Modeling

The Unified Modeling Language
Activities

Requirements

Architecture

Design
7
Process
 Organization of activities to achieve a certain objective
Defect Causal Analysis: Preventing Problems
Prioritize problem
reports
Perform cause
analysis
Identify
mitigations
Prioritize
mitigations
 Showstoppers have
top priority
 Perform analysis in
order of priority
 Identify common
problem causes
 Estimate cost and
benefit of mitigations
 Perform AHP on
remaining reports
 Create Ishikawa
diagrams based on
standard template
 Prioritize causes in
order of problem
priority; common
causes are given
extra priority
 Management decides
which to implement
based on
cost/benefit analysis
 Create prioritized list
of reports
 Attach diagrams to
the cause reports
 Identify actions in
each category and
attach to cause
reports
8
Linköpings universitet
4
2010-08-31
Lincoln Laboratory Process (1956)
H. Bennington. Production of Large Computer Programs.
Proceedings of the ONS Symposiym on Advanced Programming Methods for Digital Computers, June 1956.
9
Processes model
 Group of processes of the same character
10
Linköpings universitet
5
2010-08-31
The V model
Concept of
operations
Operations and
maintenance
Validate concepts
Requirements
Acceptance
testing
Validate requirements, verify specification
Verify system design
System design
Verify module design
Program design
System testing
Integration
testing
Implementation and unit testing
11
The waterfall model
System
q
Requirements
Software
Requirements
Analysis
Program Design
Coding
Testing
Operations
12
W. Royce. Managing the Development of Large Software Systems. Proceedings of IEEE WESCON, August 1970.
Linköpings universitet
6
2010-08-31
The waterfall model
System
Requirements
q
Software
Requirements
Preliminary
Program Design
Analysis
Preliminary
Design
Program Design
Analysis
Coding
Program Design
Coding
Testing
Testing
Operations
Usage
13
W. Royce. Managing the Development of Large Software Systems. Proceedings of IEEE WESCON, August 1970.
Iterative development
Planning
Evaluation
Requirements
Testing
Analysis
Implementation
Design
14
Linköpings universitet
7
2010-08-31
Spiral model
15
B. Boehm. A Spiral Model of Software Development and Enhancement. IEEE Computer 21(5):61-72, 1988.
Process frameworks
 Somewhere between process models and processes
Unified Process
Scrum
Inception
Iterative
Development
Transition
Elaboration
Construction
Rational Unified Process
Open Unified Process
Essential Unified Process
Scrum @ Medius
Scrum @ Ericsson
Scrum @ LiU-IT
16
Linköpings universitet
8
2010-08-31
Processes – conclusions
Less concrete
Process terminology

Process model – the character of a process

Process framework – a model that can be instantiated

Process – a concrete organization of activities
More terminology

Method – a concrete way of doing something

Tool – a device that supports a given method
More concrete
17
AGILE AND LEAN
18
Linköpings universitet
9
2010-08-31
Agile software development
 Reaction to traditional heavyweight methods
 Iterative
Iterati e with
ith emphasis on reacting to change
 Rapid iteration, evolving requirements, emergent design
 Emphasis on collaboration in small cross-functional teams
Examples
 Extreme Programming
g
g
 Feature-Driven Development
 Open Unified Process
19
The Agile Manifesto
We are uncovering better ways of developing software by doing it
and helping others do it. Through this work we have come to
value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is,, while there is value in the items on the right,
g , we value the
items on the left more.
20
Linköpings universitet
10
2010-08-31
Lean software development
 Complement to agile development methods
 Agile is about
abo t doing;
doing lean adds a thinking dimension
 Lean eliminates waste – a little thinking can prevent redoing
 Lean brings decisions forward – but only the right ones
 Lean organizes teams – agile individuals within teams
 Lean is about high throughput (agile about low latency)
 Lean is about maximizing long-term business value
21
The Toyota Way
Some principles applied to software

Eliminate waste through continuous improvement


Excess inventory,
inventory waiting,
waiting incorrect processing,
processing defects
Make decisions slowly, implement decisions rapidly

Go-and-see, determine cause, consider alternatives, consensus

Build a culture of stopping to fix problems, to get quality right

Use visual control to expose problems

Sort,, straighten,
g
, shine,, standardize,, sustain

Grow leaders who understand the work and live the philosophy

Develop exceptional people and teams who follow the philosophy
22
J. Liker. The Toyota Way: 14 Management Principles from the Worl’ds Greatest Manufacturer. McGraw-Hill, 2004.
Linköpings universitet
11
2010-08-31
REQUIREMENTS
23
Requirements engineering
Domain understanding
Requirements elicitation
Requirements quality
assurance
Requirements evaluation
Requirements
specification and
documentation
24
Linköpings universitet
12
2010-08-31
Requirements
Requirements

What is the problem to be solved

Why does the problem need to be solved

Who should be involved in solving it

How should the problem be solved
Architecture
Design
Implementation
25
Domain understanding and
requirements elicitation
Objectives

Understand the current situation

Identify problems and opportunities

Discover stakeholder needs

Explore alternatives
Domain understanding
Requirements elicitation
Requirements quality
assurance
Requirements
evaluation
Requirements
specification and
documentation
Knowlege acquisition

Organization: structure,
structure objectives,
objectives policies,
policies roles,
roles responsibilities

Domain: concepts, objectives, regulations, processes

Current system: actors, tasks, workflows, problems, opportunities
26
Linköpings universitet
13
2010-08-31
Some methods

Background study

Talking to stakeholders

Observation

Questionnaires

Storyboards

Scenarios

Mock-ups
Domain understanding
Requirements elicitation
Requirements quality
assurance
Requirements
evaluation
Requirements
specification and
documentation
27
Scenarios

Early-stage requirements validation/elicitation technique

Narrative of how things work or how they should work
 Passive: stakeholders are told story – for validation
 Active: stakeholders contribute to story – for elicitation
Positive
Desirsable behavior in
abnormal circumstances
Desirable behavior in
normal circumstances
Abnormal
Normal
Undesirsable behavior in
abnormal circumstances
Undesirable behavior in
normal circumstances
Negative
28
Linköpings universitet
14
2010-08-31
Scenario structure

Who are the players

What if some event occurs

What happens to them

What could go wrong

Why this happens
A rescue worker reports an obstacle on a major road to the incident command system. The report
is logged for postmortem analysis, and the obstacle is added to the overall situation report.
Since a new obstacle impacts operations, the operations section chief and liaison is notified of the
new obstacle. Since it is a potential safety hazard, the safety officer is notified. Since the road is
open to the public, the public information officer is notified of the new obstacle. Rescue workers
known to be headed for the obstacle (based on their last known route and/or position) are also
notified. If there is an area commander assigned to the location, that area commander is notified.
29
Mock-ups
Functional prototypes

Not fully functional

For validating functionality
User interface prototype

Low or high fidelty possible

To validate user interface
30
Linköpings universitet
15
2010-08-31
Requirements evaluation
Requirements issues

Inconsistencies

Conflicts

Exposure to risk

Prioritization

Feasibility
Incident commander: all personal details of all potential
victims
i ti
should
h ld be
b available
il bl to
t allll staff
t ff upon request.
t
Conflict: this is illegal
Risk: exposure of
information to outsiders
Feasibility: a lot of
information is unavailable
Important techniques

Conflict resolution

Risk analysis (e.g. CORAS)

Cost/value analysis (e.g. AHP)
31
Prioritization by cost/value

Estimate (relative) cost

Estimate (relative) values
100
90
High
80
Medium
70
60
50
40
30
20
10
Low
0
0
20
40
60
80
100
32
Linköpings universitet
16
2010-08-31
Requirements specification
Communications
should be secure
Users need to
make audio calls
R8.1 Audio calls
The user interface shall have a facility for
initiating audio calls.
R3.2: Encryption
yp
All network communications shall be
encrypted with an AES128 session key.
R8 6 Destination selection
R8.6
When selecting a destination, common and
important destinations shall be selectable with
no more than two clicks.
R3.3: Session keys
Session keys shall be random and negotiated
using a secure key exchange protocol.
R8.33 Voice encoding
Audio calls shall use G.729 encoding at
8kbit/s.
33
Requirements specification
Natural language
SMART

Easy to write and read

Specific

Need good guidelines

Measurable

Risk of ambiguities

Attainable

Realizable

Time-bounded or Traceable
Specification language

Precise and unambiguous

Difficult to learn

Good tool support
Functional vs.
vs non-functional
non functional
Modeling – a bit of both
34
Linköpings universitet
17
2010-08-31
S.M.A.R.T.
Specific
Specific means
Consider

There is no ambiguity

Terminology is consistent

Requirements are simple

Appropriate level of detail
The map should be shown in a
640x480 window and obviously show
most of the surrounding area including
relevant map objects. Icons should be
used to display map elements.
The map shall be shown in a 640px by
480px window.
The
e map
ap s
shall
a s
show
o a use
user-selected
se ected
area surrounding the user’s current
position.
Relevant map objects (defined in R32)
shall be displayed using icons (see
R61) on the map.
35
S.M.A.R.T.
Measurable
Measurable means
Consider

The program shall use as little memory
as possible.
It is possible to verify that this
requirement has been met
The program shall output the optimum
route with respect to driving time.
Non-measurable means

You never know if you’re done

Opportunity for conflict
The program shall never consume
more than 48MB of memory.
36
Linköpings universitet
18
2010-08-31
S.M.A.R.T.
Attainable
Attainable means
Consider

The system shall be 100% reliable and
100% available.
It is physically possible to meet
the requirement under the given
conditions
Ask

Is there a theoretical solution

Are there physical constraints

Are there environmental
constraints
The system shall operate for at least 20
hours between charges.
For any input, the system shall
compute an optimal schedule in no
more than one hour.
hour
37
S.M.A.R.T.
Realizable
Realizable means
Consider

I have no good examples.
examples
It is possible to achieve this
requirements given the
constraints under which it is
developed
Do you?
Ask questions like

Can we do it?

I there
Is
th
enough
h time
ti

Are there enough people

Is there enough money
38
Linköpings universitet
19
2010-08-31
S.M.A.R.T.
Traceable
Traceable means
Consider

We can trace each requirement
from analysis through design
and implementation

We can understand the reason
for each requirement
The program shall display time and
date and the latest notifications
and battery status and network
status in the status bar.

We can verify that each has
been implemented
R23 The program shall display
time and date in the status bar

Modifications are easy to make
R24 The program shall display
battery status in the status bar
R25 The program shall display
network status in the status bar
39
Discuss
The map should display the geographical location of the user.
The system shall never lose any data.
The user shall be able to make a voice call with good audio quality.
The system shall have a response time of one second.
The map display shall be 1024x768 pixels large.
40
Linköpings universitet
20
2010-08-31
Conclusions
On elicitation

Crucial to understand the problem and solution domains

Crucial to identify and communicate with all stakeholders
On evaluation

Lots of techniques and tools exist for evaluation

Don’t discart requirements – just defer them
On documentation

If in doubt, write S.M.A.R.T. requirements
41
MODELING
42
Linköpings universitet
21
2010-08-31
Models in software engineering
Documentation
Verification

Concise and precise language

Represent expected behavior

Visual models easy to read

Test behavior against model
Communication
Development


Formal specification

Stepwise refinement

MDD/MDA
Models focus on key issues
Exploration

Test modifications on models
43
Model criteria
Mapping criterion

There is an original object that
is mapped to a model
Modeled
Attributes
Mapping
Original
Reduction criterion

Not all properties of the original
are mapped, but some are
Pragmatic criterion

Mapped
Attributes
The model can replace the
original for some purpose
Model
44
Linköpings universitet
22
2010-08-31
The Unified Modeling Language (UML)
Unified Modeling Language
Model

Visual modeling language in
software engineering

Concepts in the system

Objects in the system

Multiple levels of abstraction

Structures in the system

Well-defined metamodel

Support for extensions
Diagram

Visual representation of model
45
UML Diagrams
class Diagrams
Diagram
Structure Diagram
Profile Diagram
Class Diagram
Component Diagram
Behavior Diagram
Deployment Diagram
Composite Structure
Diagram
Package Diagram
Activ ity Diagram
Interaction Diagram
Use Case Diagram
State Machine
Diagram
Sequence Diagram
Communication
Diagram
Interaction Ov erv iew
Diagram
Timing Diagram
Obj ect Diagram
46
Linköpings universitet
23
2010-08-31
Class diagrams
Static structure
Abstract Class
Concrete Class

Classes and their attributes
+
-
static_ attribute: type
yp
private_attribute: type

Relationships between classes
#
+
protected_operation(type1, type2) : type
public_operation(type1, type2) : type
+
+
abstract_method()
abstract
method()
concrete_method()
Composition: B is a part of A
A
Common elements
B
Aggregation: A contains but does not own B

Class and interface

Attribute and operation

Association and dependency

Generalization and realization

Note and constraint
1..*
1
Association: Every B has a reference to one or more A
B implements Interface
C is a specialization of A
«interface»
Interface
C
47
Class diagram example
«interface»
Queue
+
+
+
+
+
FIFOQueue
+
+
+
+
+
Obj ect
enqueue(Object) : void
dequeue() : Object
clear() : void
iterator() : Iterator
size() : int
«interface»
QueueDiscipline
PriorityQueue
enqueue(Object) : void
dequeue() : Object
clear() : void
iterator() : Iterator
size() : int
+
+
+
+
+
enqueue(Object) : void
dequeue() : Object
clear() : void
iterator() : Iterator
size() : int
+strategy
1
+
+
enqueue(PriorityQueue, Object) : void
dequeue(PriorityQueue) : Object
1
1
WeightedQueue
+
+
weight: float = 1.0
setWeight(float) : void
getWeight() : float
WRR
+queues
1..*
+
+
enqueue(PriorityQueue, Object) : void
dequeue(PriorityQueue) : Object
WFQ
+
+
enqueue(PriorityQueue, Object) : void
dequeue(PriorityQueue) : Object
DRR
+
+
enqueue(PriorityQueue, Object) : void
dequeue(PriorityQueue) : Object
48
Linköpings universitet
24
2010-08-31
Component diagrams
cmp Component Diagram
Static structure
Composite Component

Components and interfaces

Relationships
Collaboration
A
B
Required
Elements
Provided
«delegate»

Components and ports

Interfaces and collaborations

Dependencies

Notes and constraints
«delegate»
Port
Port
Required
Provided
49
Component diagram example
AudioSource
AudioDecoder
Player
Input
«delegate»
Codec
«delegate»
AudioSource
AudioDecoder
AudioDecoder
Buffer
Decoder
Queue
AudioSource
AudioCodec
AudioSink
Source
«delegate»
AudioEncoder
Output
PlayerControl
AudioSink
SourceControl
AudioSink
Data
SourceControl
PlayerControl
Sink
«delegate»
Playlists
Controller
Playlist
Playlist
SinkControl
Control
Control
GUI
SinkControl
Control
«delegate»
Control
AudioSink
«interface»
Sink::AudioSink
Control
Sink::AlsaSink
Sink::IceCastSink
WebUI
50
Linköpings universitet
25
2010-08-31
Deployment diagrams
Run-time architecture

deployment Deployment Diagram
Maps software elements to
hardware elements (nodes)
Node
Artifact
Component
Elements
Association

Nodes (various types)

Artifacts and components

Associations
«client»
Client Node
«execution environ...
Execution Env ironment
«device»
Physical Dev ice
51
Deployment diagram example
deployment Deployment Diagram
«device»
Workstation
W
k t ti
«device»
Media
M
di Center
C t
tags
Desktop = KDE
Distribution = Ubuntu 10.04
OS = Linux
tags
Distribution = Ubuntu 9.10
OS = Linux
«device»
S
Serv
er
tags
{protocol=NFS}
«artifact»
XBMC
Distribution = Debian Etch
OS = Linux
NFS Serv er
HTTP Serv er
{protocol=CIFS}
«artifact»
MPD Controller
«artifact»
Jinzora
{protocol=MPD}
«artifact»
MPD
Web Brow ser
{protocol=MPD}
MPDJukebox
{protocol=HTTP}
«artifact»
Database
tags
vendor = MySQL
52
Linköpings universitet
26
2010-08-31
Activity diagram example
Customer
act Activ ity Diagram
Place Order
Make Payment
Order
Invoice
Invoice
Notify Customer
Send Inv oice
[order rejected]
Accept Payment
Seller
Order
[order accepted]
Receiv e order
Fill Order
Close Order
Ship
p Order
53
Use case diagrams
uc Use Case Diagram
ATM System
Serv ice ATM
Bad PIN
«extend»
Employee
ATM Transaction
Check Balance at ATM
Technician
Withdraw Money
«extend»
Withdraw Cash from
ATM
B kT
Bank
Teller
ll
«include»
Transfer Money at ATM
Deposit Money
«include»
Customer
54
Linköpings universitet
27
2010-08-31
Conclusions
On modeling

Models are not necessarily lean: what value do they contribute

Models can support effective and efficient communications

There are development methods that rely on models
On modeling languages

The Unified Modeling Language is the most well-known language

There are many others (not all are graphical)
55
ARCHITECTURE
56
Linköpings universitet
28
2010-08-31
Architecture
Architecture is design
Not all design is architecture
Software architecture

Concentrates on issues that
would be hard to change after
the system is built

Addresses non-functional and
quality
lit requirements
i
t

Is a compressed view of a
design
57
Architecture

Software architecture goes beyond the algorithms and data structures
of the computation;
p
designing
g g and specifying
p
y g the overall system
y
structure emerges as a new kind of problem. Structural issues include
gross organization and global control structure; protocols for
communication, synchronization, and data access; assignment of
functionality to design elements; physical distribution; composition of
design elements; scaling and performance; and selection among
design alternatives.
Garlan and Shaw: An Introduction to Software Architecture (1993)
58
Linköpings universitet
29
2010-08-31
Architecture

Architecture is defined by the recommended practice as the
fundamental organization
g
of a system,
y
embodied in its components,
p
their relationships to each other and the environment, and the
principles governing its design and evolution.
ANSI/IEEE Std 1471-2000 (2000)

The software architecture of a program or a computing system is the
structure or structures of the system, which comprise software
elements, the externally visible properties of those elements, and the
relationships amond them.
Bass, Clements, Kazman: Software Architecture in Practice (2003)
59
Architecture (simplified)
Defines structure
Defines communication

System partitioning

Communications mechanisms

Component interfaces

Control flow

Component functionality
cmp Architecture
Visualization
Controller
Recorder
«use»
Mediator
Database
Simulator
60
Linköpings universitet
30
2010-08-31
Architecture example
cmp Architecture
SSL Frontend
«SSL,HTT P»
Client
«HT TP»
Cache
Load Balancer
«HTTP»
Server 1
«HTTP»
«HTTP»
«HT TP»
«HTTP»
Server 2
«HTTP»
«ODBC»
«ODBC»
Static Server
Database Cluster
Database 1
Database 2
61
Some techniques for lean architecture
1.
Separate components according to their rates of change
2
2.
Partition the system so that each part can be managed autonomously
3.
Let human considerations drive the partitioning
4.
Don’t split a domain across architectural units or geographic locations
5.
Module partitioning follows domain knowledge, if possible
6.
Module partitioning follows end user cognitive model of the domain
7.
Don’t forget system artifacts and other constraints
8
8.
If you have a pattern language,
language then use it
62
Linköpings universitet
31
2010-08-31
Pushing my friends’ books 
63
Patterns
Patterns
A good pattern


It solves a problem

It is a proven concept

The solution isn't obvious

It describes a relationship

The pattern has a significant
human component
A recurring solution to a
recurring problem in context
Pattern Language

A system of patterns for a
particular domain

The relationships and
interactions between the
patterns
James Coplien
p
64
Linköpings universitet
32
2010-08-31
Patterns
Each pattern is a three-part rule, which
expresses a relation between a certain
context, a problem, and a solution.
As an element in the world, each
pattern is a relationship between a
certain context, a certain system of
forces which occurs repeatedly in that
context, and a certain spatial
configuration which allows these forces
to resolve themselves.
The pattern is, in short, at the same
time a thing, which happens in the
world, and the rule which tells us how to
create that thing, and when we must
create it. It is both a process and a
thing; both a description of a thing
which is alive, and a description of the
process which will generate that thing.
– Christopher Alexander
The Timeless Way of Building
As an element of language, a pattern is
an instruction, which shows how this
spatial configuration can be used, over
and over again, to resolve the given
system of forces, wherever the context
makes it relevant.
65
133 Staircase as a stage
If the entrances are in position – Main
Entrance (110); and the pattern of
movement through the building is
established – The Flow Through
Rooms (131), Short Passages (132),
the main stairs must be put in and
given an appropriate social character.
A staircase is not just a way of getting
from one floor to another. The
stair is itself a space, a
volume, a part of the building;
and unless this space is made
to live, it will be a dead spot,
and work to disconnect the
building and to tear its
processes apart.
Therefore:
Place
ace tthe
e main
a sta
stair in a key
ey pos
position,
to ,
central and visible. Treat the whole
staircase as a room (or if it is outside,
as a courtyard). Arrange it so that the
stair and the room are one, with the
stair coming down around one or two
walls of the room. Flare out the bottom
of the stair with open windows
or balustrades and with widesteps so that the people coming
down the stair become part of
the action in the room while
they are on the stair, and so
that people below will naturally
use the stair for seats.
66
Christopher Alexander. A Pattern Language. Oxford University Press, 1977.
Linköpings universitet
33
2010-08-31
Architectural patterns in software
High-level patterns

Layers

Pipes and filters

Blackboard
Distributed systems

Microkernel

Broker
Interactive systems

Model-View-Controller (MVC)

Presentation-AbstractionControl
67
Layers
Context: A large system that
requires
q
decomposition
p
Problem: A mix of low- and highlevel issues where high-level
issues rely on the lower-level one.
Forces: Late source code
changes, stable interfaces,
exchangeable parts, subdivision of
work
Solution: Structure the system in
layers and place them on top of
each other
cmp Architecture
Component 3.1
Component 2.1
Component 1.2
12
Layer 3
Layer 2
Layer 1
Component 3.2
Component 2.2
Component 1.1
11
68
Linköpings universitet
34
2010-08-31
Pipes and filters
Context: Processing data streams
Problem: Developing a monolithic
module for processing may be
infeasible due to complexity and
inability to divide work.
cmp Architecture
Input
p filter
Source
Filter
Forces: Reuse of modules,
reconfigurability, flexibility, varied
input, output, data, parallelism.
Solution: Divide the system into
several sequential processing
steps.
«interface»
AbstractFilter
Filter
Output Filter
Sink
69
Broker
Context: Distributed and possibly
heterogeneous system with
independent cooperating components.
cmp Architecture
Client
Client-side proxy
«calls»
Problem: When distributed
components handle communication
themselves, dependencies and
limitations arise. Services for
communication are also needed.
uses API
«communicates»
Broker
«use»
Bridge
uses API
Forces: Transparent remote access,
run-time reconfiguration, hide system
details from users
Solution: Introduce a broker
component and have services register
with the broker.
uses API
«communicates»
Serv er
Serv er-side proxy
«calls»
70
Linköpings universitet
35
2010-08-31
Model-View-Controller (MVC)
Context: Interactive applications with a
flexible human-computer interface
cmp M...
View
Problem: Interfaces are prone to
change and can be very complex.
Forces: Same information presented in
multiple ways, display must reflect
changes immediately, user interface
should be easy to change.
Observ er
manipulate display
create
Controller
get data
Solution: Divide application into three
areas: processing (model), output
(view) and input (controller)
(controller). Model
notifies views of changes.
notify on change
manipulate
Model
Observ able
71
Architecture example redux
cmp Architecture
SSL Frontend
«SSL,HTTP»
Client
«HTTP»
Cache
Load Balancer
«HTTP»
Server 1
«HTTP»
«HTTP»
«HTTP»
«HTTP»
Server 2
«HTTP»
«ODBC»
«ODBC»
Static Server
Database Cluster
Database 1
Database 2
What pattern does this (mostly) conform to?
72
Linköpings universitet
36
2010-08-31
Conclusions
On architecture

Architecture is the bridge from requirements to design

Architecture defines the overall shape of the program

Architecture determines many of its properties

With emergent design, architecture is even more important

There is no clear line between architecture and design
On patterns

Don’t reinvent the wheel – if a pattern will do the job, use it

If a pattern doesn’t do the job, invent something that will
73
DESIGN
74
Linköpings universitet
37
2010-08-31
Design
Continues from architecture

Decomposition of the system

Specification of interactions

Decomposition of components
Agile development and design

Design is emergent

Architecture is critical
75
Traditional software design
class Coupling-Cohesion
Coupling

Class 1
Measure of interconnection
among components
«call»
«flow»
Cohesion

Measure of how focused a
single component is
Class 2
«flow»
«use»
«use»
«flow»
Class 4
«use»
«call»
Class 3
«use»
«call»
Goals

Low coupling

High cohesion
76
Linköpings universitet
38
2010-08-31
Coupling
class Coupling-Cohesion
Loose (low) coupling
Class A

Software easier to understand

Easier to maintain, change, test
Class B
Class 1
Class 2
Class 3
Types of coupling (low to high)

Data coupling

Stamp coupling

Control coupling

External coupling

Common coupling

Content coupling
class Coupling-Cohesion
Class A
Class B
Class M
Class 1
Class 2
Class 3
77
Cohesion
Types of (low-medium) cohesion
High (tight) cohesion

Logical cohesion

Reduces coupling

Temporal cohesion

Easier to maintain, understand

Procedural cohesion

Communicational cohesion
class Coupling-Cohesion
Reader
+
create(DataFormat, DataSource) : Reader
class Coupling-Cohesion
DataSource
DataOutput
+
+
+
+
+
Utilities
read_xml_from_file()
read csv from file()
read_csv_from_file()
read_xml_from_network()
read_csv_from_network()
+
+
+
DataFormat
+
read()
FileSource
Netw orkSource
XMLFormat
+
«use»
Socket
«use»
parse()
decode_xml_entity()
unquote csv item()
unquote_csv_item()
current_timestamp()
decode_entity()
CSVFormat
+
unquote_csv_item()
«use»
SAXParser
«use»
«use»
«use»
FileIO
Socket
SAXParser
FileIO
78
Linköpings universitet
39
2010-08-31
Design patterns
A definition

A recurring solution to a
recurring design problem in
context

Discovered, not designed
Don’t rely just on this book
Design patterns and agile

Support emergent design

Pattern language helps
79
Singleton (creation)
Problem: Need a single instance
and don’t want to use g
global
variables (or can’t)
class Singleton
Singleton
Solution: Control creation of
objects through static method
-
instance: Singleton
+
Singleton()
get_instance() : Singleton
Problems:

Similar to global variables

E
Easy
tto overuse singletons
i l t
def get_instance():
Singleton.instance = Singleton()
return instance
80
Linköpings universitet
40
2010-08-31
AbstractFactory (creation)
Problem: Select concrete types to
create at run-time or easilyy
change concrete types created.
class AbstractFactory
y
AbstractFactory
Solution: Define an interface for
creating instances, and create
different implementations for
different families of objects.
AbstractProduct
+
create_product() : AbstractProduct
+
create_product() : Product
ConcreteFactory
Product
«instantiate»
81
Composite (structural)
Problem: Want to represent partwhole relationships
p with a
consistent interface.
class Composite
Component
+
+
+
+
Solution: Define a common
component type and have both
interior nodes and leaves
implement the same interface.
Dispatch operations from the
composite to its components.
components
add(Component) : void
remove(Component) : void
get_child(int) : Component
operation()
Leaf
+
operation()
Composite
+
+
+
+
add(Component) : void
remove(Component) : void
get_child(int) : Component
operation()
def operation(self):
for c in self.children:
c.operation()
82
Linköpings universitet
41
2010-08-31
Chain of responsibility (behavior)
Problem: Not sure what will
handle a g
given event/command
but know their relationships.
class ChainOfResponsibility
def handle_request(self):
self.successor.handle_request()
successor
Solution: Create a chain of
handlers, and just call the head
of the chain with the command.
Handler
Client
+
handle_request()
ConcreteHandler
Note: Often used with composite
and/or command patterns; the
chain can be a tree if handlers
dispatch to multiple objects or
other chains.
def handle _ request():
q
()
if self.can_handle():
# Handle request
else:
super.handle_request()
+
handle_request()
83
Observer (behavior)
Problem: Keeping track of state
Solution: Automatically update
depdents when object state
changes
class Observ ...
def notify(self):
f o in
for
i self.observers:
lf b
o.notify()
Subject
Observer
+observers
+
+
+
attach(Observer) : void
detach(Observer) : void
notify() : void
+
-
state: State
+subject
+
+
get_state()
t t t () : State
St t
set_state(State) : void
1
update() : void
*
Problems:

Garbage collection

Infinite notify loops
ConcreteSubj ect

Error handling
ConcreteObserv er
+
update() : void
def set_state(self, state):
self.state = state
self.notify()
84
Linköpings universitet
42
2010-08-31
Command (behavior)
Problem: Want to do undo,
scripting,
p g record commands,
defer execution …
class Command
Inv oker
Command
+
Solution: Encapsulate all state
needed to perform command
(or undo) in a command object,
and invoke it using an invoker.
Receiv er
+
action()
execute()
ConcreteCommand
receiver
-
state: State
+
execute()
«instantiate»
Client
def execute(self):
receiver.action()
85
Conclusions
On design

Design defines the detailed shape of the program

Design determines many functional properties of the program

Agile processes often omit the design phase
On patterns

Don’t reinvent the wheel – if a pattern will do the job, use it

If a pattern doesn
doesn’tt do the job,
job invent something that will

Beware of the design pattern hype!
86
Linköpings universitet
43
2010-08-31
WRAP-UP
87
Topics covered
Processes and modeling

Processes models and frameworks

Agile and lean development philosophies

The Unified Modeling Language
Key software engineering activities

Requirements

Architecture and architectural patterns

Design and design patterns
88
Linköpings universitet
44
2010-08-31
Other important topics
Software engineering activities

More about requirements,
requirements design,
design architecture

Coding and other implementation

Testing, verification and validation

Delivery, deployment and maintenance
Support activities

Configuration management

Documentation
89
In your project
Requirements – current step

Determines the course of the project

Read more about it – techniques for elicitation, analysis …
Architecture – next step

Crucial – you are depending on emergent design

Need architecture to support non-functional requirements
Design

Emergent design – no up-front design needed
90
Linköpings universitet
45
2010-08-31
www.liu.se
Linköpings universitet
46