Software Engineering
Natallia Kokash
email: nkokash@liacs.nl
N. Kokash, Software Engineering
1
Software Engineering
Agenda

Software Architecture
 Definition
 Architecture
Design
 Viewpoints and view models
 Architectural styles
 Architecture assessment

Software Design
 Principles
 Methods
N. Kokash, Software Engineering
2
Software Engineering
Architecture around us
Differences:




Scale
Process
Cost
Schedule
N. Kokash, Software Engineering




Skills and development teams
Materials and technologies
Stakeholders
Risks
3
Software Engineering
The Winchester “Mystery” House



Built by Sarah Winchester, widow of gun magnate
Started in 1884, finished on September 5, 1922: 38
years of construction, 147 builders, 0 architects
160 rooms: 40 bedrooms, 6 kitchens, 2 ball rooms,
950 doors, 10000 window panes, 17 chimneys


N. Kokash, Software Engineering
$5.5 million in 1922 ≈
$71 million in 2010
65 doors to blank walls,
24 skylights in floors, 13
staircases abandoned
4
Software Engineering
Complex structures without
architecture

The result is at best baroque.
 Clumsiness,
inelegance, discord in
the structures
 Duplication, redundancy, wasted
effort, rework, gaps
 Poor integration, inconsistency,
mismatch

N. Kokash, Software Engineering
We simply cannot imagine
building a skyscraper without an
architecture!
5
Software Engineering
The beginning of Software
Architecture

1968/69 NATO conferences:
“I think we have something
in addition to software
engineering [..] This is the
subject of software
architecture. Architecture
is different from
engineering”
N. Kokash, Software Engineering
6
Software Engineering
Understanding architecture (1)
“The architecture of a
software system defines
that system in terms of
computational
components and
interactions among those
components.”
Shaw & Garlan,
Software Architecture: Perspectives on
an Emerging Discipline, 1996
N. Kokash, Software Engineering
7
Software Engineering
Understanding architecture (2)
“The software architecture of
a system is the structure or
structures of the system,
which comprise software
elements, the externally visible
properties of those elements,
and the relationships among
them.”
Bass, Clements & Kazman,
Software Architecture in Practice, 2003
N. Kokash, Software Engineering
8
Software Engineering
Understanding
architecture
statement

procedure
 multiple
system structures;
 externally visible (observable)
properties of components.
module

(design)
pattern
architecture
N. Kokash, Software Engineering
Important issues raised:
This definition does not
include:
 process
 rules
and guidelines
 architectural styles
9
Software Engineering
Understanding architecture:
popular views

Architecture is high-level design
 Architecture
≈ Global design
 Architect ≈ Designer



Architecture is components and connectors
Architecture is overall structure of the system
Architecture is the structure, including the
principles and guidelines governing their
design and evolution over time
N. Kokash, Software Engineering
10
Software Engineering
Understanding architecture:
common elements
Defines major components
 Defines component relationships (structures)
and interactions
 Omits content information about components
that does not pertain to their interactions
 Defines the rationale behind the components
and the structure

N. Kokash, Software Engineering
11
Software Engineering
Definition
1471-2000
Software 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.
IEEE Standard on the Recommended
Practice for Architectural Descriptions,
2000
N. Kokash, Software Engineering
12
Software Engineering
Architectural structures:









N. Kokash, Software Engineering
Module structure
Conceptual, or logical structure
Process, or coordination
structure
Physical structure
Usage structure
Calls structure
Data flow
Control flow
Class structure
13
Software Engineering
Software architecture: example
N. Kokash, Software Engineering
14
Software Engineering
Architecture in IT

Business architecture
 Business

model as it relates to an automated solution.
Technical architecture
 Specific
to technology and the use of this technology:
.NET, J2EE, hardware

Enterprise architecture
 Set
of principles, policies and technical choices to
achieve standardization and integration requirements.
 Concerns cross project/solution and communication



Solutions architecture
Product-line architecture
…
N. Kokash, Software Engineering
15
Software Engineering
Architecture vs. Design


Architecture: where non-functional decisions are cast, and
functional requirements are partitioned
Design: where functional requirements are accomplished
non-functional
requirements
functional
requirements
N. Kokash, Software Engineering
architecture
design
16
Software Engineering
Architecture starts early

Architecture represents the set
of earliest design decisions
 Hardest
to change
 Most critical to get right



Architecture is the first design
artifact where a system’s quality
attributes are addressed
Some qualities are observable via execution:
performance, security, availability, functionality, usability
And some are not observable via execution: modifiability,
portability, reusability, integrability, testability
N. Kokash, Software Engineering
17
Software Engineering
System attributes




Performance
Availability
Usability
Security

End user’s
view







Maintainability
Portability
Reusability
Testability
N. Kokash, Software Engineering

Developer’s
view
Time to market
Cost and benefits
Projected life time
Targeted market
Integration with legacy
systems
Business community
view
18
Software Engineering
The role of software architect
requirements
client,
user
assess
solutions
architect
developers
creates
assess
prescribe
visualize
appearance,
behavior
N. Kokash, Software Engineering
architectural design
construction,
cooperation
19
Software Engineering
Adding architecture: easy way
stakeholders
(few)
requirements
architecture
quality
agreement
detailed design
implementation
N. Kokash, Software Engineering
development
20
Software Engineering
Architecture in the lifecycle



Iteration on both
functional and quality
requirements
Many stakeholders
involved
Balancing of
functional and quality
requirements
stakeholders
(many)
requirements
quality
architecture
agreement
development
N. Kokash, Software Engineering
21
Software Engineering
Why software architecture is
important?
Manifests the early set of design decisions
 The vehicle for stakeholder communication:

 Architect,
requirements engineers, designers
(also of other systems), programmers, testers,
integrators, maintainers, managers, quality
assurance people…

Transferable abstraction of a system
 Product lines share a common architecture
 Allows for template-based development
 Basis for training
N. Kokash, Software Engineering
22
Software Engineering
Global workflow in
architecture design
assets
architecture
ideas
synthesis
backlog
evaluation
constraints
significant
requirements
N. Kokash, Software Engineering
evaluation results
23
Software Engineering
Architecture design

Attribute-Driven Design
 Choose module to decompose
 Refine this module:
 choose architectural drivers (quality is driving force)
 choose pattern that satisfies drivers
 apply pattern
 Repeat

Example:
 Top-level:
 usability  separate user interface  three tier architecture
 Lower-level, within user interface:
 security  authenticate users
 Lower-level, within data layer:
 availability  active redundancy
N. Kokash, Software Engineering
24
Software Engineering
Taking decisions
Design
problem
Sub-problem
Decision =
best option
Design
option
Design
option
Problem
space
Decision
space
Sub-problem
Design
option
Design
option
Decision =
best option
Alternative
solutions
N. Kokash, Software Engineering
Alternative
solutions
25
Software Engineering
Decision space
The space of possible designs that can be
achieved by choosing different sets of
alternatives.
fat-client
client
style
client-server
client in a
separate
user interface
layer
Programmed in Java
Programmed in Visual Basic
thin-client
Programmed in C++
monolithic
N. Kokash, Software Engineering
no separate
user interface
layer
26
Software Engineering
Types of decisions

Implicit, undocumented
 Unaware,
tacit, of course
knowledge

Explicit, undocumented
 Vaporizes

Explicit, explicitly
undocumented
 Tactical,

over time
personal reasons
Explicit, documented
 Preferred
N. Kokash, Software Engineering

Document your decisions

Prevents repeating steps

Explains why this is a
good architecture

Emphasizes qualities and
criticality for requirements

Provides context and
background
27
Software Engineering
Elements of a design decision
Issues: design issues being addressed
 Decision: detailed description of the decision
 Status: e.g., pending, approved
 Assumptions: underlying assumptions
 Alternatives: what are other options?
 Rationale: the why of the decision taken
 Implications: e.g. need for further decisions

N. Kokash, Software Engineering
28
Software Engineering
Architecture presentation

Building
 Overall picture of
building (client)
 Front view (client,
“beauty” committee)
 Water supply plan
(plumber)
 Electrical wiring plan
(electrician)
N. Kokash, Software Engineering

Software
 Powerpoint
slides
(managers, users,
consultants)
 UML diagrams,
models in specialized
languages (ADLs)
(technicians)
29
Software Engineering
Some more examples…
N. Kokash, Software Engineering
30
Software Engineering
N. Kokash, Software Engineering
31
Software Engineering
N. Kokash, Software Engineering
32
Software Engineering
N. Kokash, Software Engineering
33
Software Engineering
Model for architecture
description
N. Kokash, Software Engineering
34
Software Engineering
Viewpoint specification



View: a representation of a whole system
from the perspective of a related set of
concerns.
Viewpoint: establishes the purposes and
audience for a view and the techniques or
methods employed in constructing a view.
Viewpoint specification includes:
 Viewpoint name
 Stakeholders addressed
 Concerns addressed
 Language,
N. Kokash, Software Engineering
modeling techniques
35
Software Engineering
Kruchten’s 4+1 view model

Logical viewpoint:



Process viewpoint:



Shows concurrent aspects at runtime
(e.g., threads and processes)
Takes into account non-functional
requirements
Deployment viewpoint:



Supports functional requirements
Typically shows the key abstractions
(e.g., classes)
Maps logical, process, and implementation elements to physical
infrastructure
Takes into account non-functional requirements
Implementation viewpoint:

Shows software packaged in small chunks-program libraries or
subsystems
N. Kokash, Software Engineering
36
Software Engineering
Kruchten’s 4+1 view model

The scenario viewpoint
 Consists
of a small subset of
important scenarios (e.g., use
cases)
 Used to show that the elements of
the four viewpoints work together
seamlessly.

Redundant with the other ones
(hence the "+1"), but it plays
two critical roles:
 acts
as a driver to help designers
discover architectural elements;
 validates and illustrates the
architecture design.
N. Kokash, Software Engineering
37
Software Engineering
Architectural views (Bass et al.)

Module views
 Module is unit of implementation
 Decomposition, uses, layered, class

Component and connector (C & C) views
 Runtime elements
 Process (communication),
concurrency, shared
data (repository), client-server

Allocation views
 Relationship
between software elements and
environment
 Work assignment, deployment, implementation
L. Bass et al, Sofware Architecture in Practice, 2003.
N. Kokash, Software Engineering
38
Software Engineering
Architecture Description
Language (ADL)



Languages and/or conceptual models to
describe and represent system architectures
Graphical syntax
 Some examples:
Hierarchical modeling
 Acme
 AADL
 Rapide
 Darwin
 Wright
N. Kokash, Software Engineering
39
Software Engineering
An ADL Example (in ACME)
System simple_cs = {
Component client = {Port send-request}
Component server = {Port receive-request}
Connector rpc = {Roles {caller, callee}}
Attachments : {client.send-request to
rpc.caller;
server.receive-request to rpc.callee}
}
rpc
client
server
caller
send-request
N. Kokash, Software Engineering
callee
receive-request
40
Software Engineering
ADL: Good and bad
Formal way of representing
architecture
Both human and machine
readable
Permit analysis of architectures –
completeness, consistency,
ambiguity, and performance
Can support automatic generation
of simulations / software systems
N. Kokash, Software Engineering
Representations are relatively
difficult to parse
There is not universal agreement
on what ADLs should represent
Are not supported by commercial
tools
Optimized toward a particular kind
of analysis
41
Software Engineering
Architectural styles

An architectural style is a description of
component and connector types and a pattern
of their runtime control and/or data transfer.

Examples:
 main
program with subroutines
 data abstraction
 implicit invocation
 pipes and filters
 repository (blackboard)
 layers of abstraction
N. Kokash, Software Engineering
42
Software Engineering
Component / connector types
Computational
• does a computation of some sort
• E.g. function, filter
Controller
• governs time sequence
of events
• E.g. control module,
scheduler
Memory
• Maintains a collection of
persistent data
• E.g. data base, file system,
symbol table
Manager
• contains state + operations
• State is retained between
invocations of operations
data flow (e.g. pipes)
procedure call (including RPC)
implicit invocation
instantiation
N. Kokash, Software Engineering
shared data (e.g.
blackboard or
shared data base)
message passing
43
Software Engineering
Alexander’s patterns



High buildings have no genuine
advantage, except in speculative gains.
They are not cheaper, they do not
help to create open space, they make
life difficult for children, they wreck
the open spaces near them.
But quite apart from this, empirical
evidence shows that they can actually
damage people’s minds and feelings.
In any urban area, keep the majority
of buildings four stories high or less.
N. Kokash, Software Engineering
44
Software Engineering
General flavor of a pattern
IF you find yourself in • THEN for some <reasons>, apply
<pattern> to construct a solution
<context>, for
example <examples>, leading to a <new context> and
<other patterns>
with <problem>

Structure of architectural style description
 Problem: type of problem that the style addresses.
 Context: characteristics of the environment that
constrain the designer
 Solution: in terms of components and connectors
(choice not independent), and control structure (order
of execution of components)
 Variants
 Examples
N. Kokash, Software Engineering
45
Software Engineering
Example: Abstract-data-type



Problem: identify and protect related bodies of
information. Data representations likely to
change.
Context: OO-methods which guide the design,
OO-languages which provide the class-concept
Solution:
 system
model: component has its own local data
 components: managers (servers, objects)
 connectors: procedure call (message)
 control structure: single thread, decentralized

Variants: caused by language facilities
N. Kokash, Software Engineering
46
Software Engineering
More architectural styles
Layern
Layer2
Layer1
Client
Client
Client
Shared
Data
View
n
Controller
n
Implicit-invocation
 Pipes-and-filters
 Layered style
 Repository style
 Model-ViewController (MVC)
…

Model
N. Kokash, Software Engineering
47
Software Engineering
Architecture assessment

Assess whether architecture meets certain
quality goals
 e.g.,
maintainability, modifiability, reliability,
performance

The architecture is assessed, and we hope the
results will hold for a system yet to be built
Software
architecture
Properties
N. Kokash, Software Engineering
implementation
System
properties
Qualities
48
Software Engineering
Assessment techniques

Questioning:
 How
does the system react to various situations?
 Use different types of scenarios


use-cases, likely changes, stress situations, risks, far-intothe-future scenarios...
Measuring:
 Quantitative

measures, metrics, simulation.
Preconditions for successful assessment:
 Clear
goals and requirements for the architecture,
controlled scope, key personnel availability,
competent evaluation team…
N. Kokash, Software Engineering
49
Software Engineering
Architecture Tradeoff Analysis
Method (ATAM)
0: Preparation
1: Evaluation (1)
(evaluation team + decision makers, 1 day)
 Present method, business drivers and architecture
 Identify architectural approaches/styles
 Generate utility tree
 Analyze architectural approaches
2: Evaluation (2)
(evaluation team + decision makers + stakeholders, 2 days)
 Brainstorm and prioritize scenarios
 Analyze architectural approaches
 Present results
3: Follow up (evaluation team + client)
N. Kokash, Software Engineering
50
Software Engineering
ATAM: example of utility tree
Transaction response time (H, M)
Performance
Throughput
150 transactions/sec
Training
Utility
Usability
Normal operations
Maintainability
N. Kokash, Software Engineering
Database vendor releases
new version
51
Software Engineering
Output of ATAM





Concise presentation of the architecture
Articulation of business goals
Quality requirements expressed as set of
scenarios
Architectural decisions mapped to quality
requirements
Set of sensitivity points, tradeoff points and
risks:
 Sensitivity
point: decision/property critical for certain
quality attribute
 Tradeoff point: decision/property that affects more
than one quality attribute
 Risk: decision/property that is a potential problem
N. Kokash, Software Engineering
52
Software Engineering
Software Architecture Analysis
Method (SAAM)
1.
Develop scenarios


2.
3.
Describe architecture(s)
Classify scenarios


4.
5.
for activities the system must support
for anticipated changes
direct – use requires no change,
indirect – use requires change
Evaluate indirect scenarios: changes and cost
Reveal scenario interaction (i.e., scenarious that
require changes in the same component)


6.
Interaction exposes allocation of functionality to the design
Architecture might not be at right level of detail
Overall evaluation
N. Kokash, Software Engineering
53
Software Engineering
SUMMARY
Architectural styles and design
pattern describe (how are
things done) as well as
prescribe (how should things
be done)
 Architecture supports
stakeholder communication,
early evaluation of design,
transferable abstraction

N. Kokash, Software Engineering
54
Software Engineering
Homework
Read chapter 11
 Design the architecture of Image2UML
system

 Use
rup_sad.dot template
N. Kokash, Software Engineering
55
Software Engineering
Software Engineering (3rd Ed.)


















N. Kokash, Software Engineering
1. Introduction
2. Introduction to Software Engineering Management
3. The Software Life Cycle Revisited
4. Configuration Management
5. People Management and Team Organization
6. On Managing Software Quality
7. Cost Estimation
8. Project Planning and Control
9. Requirements Engineering
10. Modeling
11. Software Architecture
12. Software Design
13. Software Testing
14. Software Maintenance
17. Software Reusability
18. Component-Based Software Engineering
19. Service Orientation
20. Global Software Development
56