Software Architecture

software architecture  global design?

architect  designer)
Course overview

▪ Pre requirements course ( )

▪ Course hours ( 3 hrs )
▪ Only 8 weeks & 8 lectures
▪ one midterm on semester

SE, Software Architecture, Hans van Vliet, ©2008 2

Overview

▪ What is it , why bother? (Architecture & Design)

▪ Architecture concepts
▪ SW Design
▪ Role of the software architect
▪ Viewpoints and view models
▪ Architectural styles
▪ Architecture asssessment

SE, Software Architecture, Hans van Vliet, ©2008 3

The Role of the Architect

requirements solutions
client,
architect developers
users

assess creates assess

visualises prescribes

appearance, architectural construction,

behaviour design co-operation

SE, Software Architecture, Hans van Vliet, ©2008 4

Architecture & Organization 1

▪ Architecture is those attributes visible to the

programmer
▪ Instruction set, number of bits used for data representation, I/O
mechanisms, addressing techniques.
▪ Organization is how features are implemented
▪ Control signals, interfaces, memory technology.
▪ e.g. Is there a hardware multiply unit or is it done by repeated
addition?
Architecture & Organization 2

▪ All Intel x86 family share the same basic

architecture
▪ The IBM System/370 family share the same basic
architecture ( This gives code compatibility)

▪ Organization differs between different versions

Structure & Function

▪ Structure is the way in which components

relate to each other ( linked efficiently )

▪ Function is the operation of individual

components as part of the structure
( components job )
Pre-architecture life cycle

stakeholders
requirements quality
(few)

agreement

development

SE, Software Architecture, Hans van Vliet, ©2008 8

Characteristics

▪ Iteration mainly on functional requirements

▪ Few stakeholders involved (engaged )

▪ No balancing of functional and quality

requirements

SE, Software Architecture, Hans van Vliet, ©2008 9

Adding architecture, the easy way

stakeholders
requirements quality
(few)

agreement

architecture

detailed design development

implementation

SE, Software Architecture, Hans van Vliet, ©2008 10

Architecture in the life cycle

stakeholders
(many)

requirements quality

architecture

agreement

development

SE, Software Architecture, Hans van Vliet, ©2008 11

 Characteristics

▪ Iteration on both functional and quality requirements

▪ Many stakeholders involved

▪ Balancing of functional and quality requirements

SE, Software Architecture, Hans van Vliet, ©2008 12

Why Is Architecture Important?

▪ Architecture is the vehicle for stakeholder

communication
▪ Architecture manifests the earliest set of design
decisions
▪ Constraints on implementation
▪ Dictates ( control ) organizational structure
▪ Inhibits (disable ) or enable quality attributes
▪ Architecture is a transferable abstraction of a
system
▪ Product lines share a common architecture
▪ Allows for template-based development
▪ Basis for training

SE, Software Architecture, Hans van Vliet, ©2008 13

 Where did it start?

▪ 1969: I.P. Sharp @ NATO Software

Engineering conference:
“I think we have something in addition to
software engineering , Architecture is
different from engineering.”
❑1972 (1969): Edsger Dijkstra, program families
❑1978 / 79: David parnas, program families

SE, Software Architecture, Hans van Vliet, ©2008 14

Design Will Remain the Center
Consequences

▪ We can always stay gainfully employed!

▪ Design provides a guiding star for
▪ Our educational practices
▪ Our research emphases
▪ Our characterization of what we do to outside parties
▪ Design will remain as a worthy and clear as (
important ) subject of study
Design of What?

▪ Past and current software design research

▪ Prescriptive design methods, Notations, The wisdom of experience,
HCI design, Design outside of software and social strategies
▪ Agile methods, Aspect-oriented design, Design analysis, Component-
based design , Software architecture
▪ Point: almost all are focused on structure of software
▪ Design in other disciplines (automotive,
architectural, fashion, consumer products)
▪ We need to focus on design of structure and
appearance (facet ) and behavior
Application Design
v. Software Design

▪ Is this a false dichotomy (segmentation ) ?

▪ The software engineering literature seems pretty one-sided…
▪ Is it just HCI v. software design?
▪ What issue predominates in the following:
▪ An airline reservation website
▪ Mashups (dynamically composed web apps)
▪ GoogleEarth
▪ If it is not our job to design applications, who’s job
is it?
When Does Design Happen?

▪ Simple test: When is the user interface to an

application designed in your favorite software
process?

▪ A problem: we still speak of “requirements, then

design”. But design is being done in
“requirements” -- much of the time.
▪ But if you don’t treat it as design you’ll likely do a poor job of it
▪ Kudos ( famousness ) to the agile movement for the right focus
here.
Where Did We Go Wrong?

▪ First, a little test from Math class:

One Student’s Answer….
 Find Design

[From W. Royce’s 1970 paper]

Find Design
 Or Here?

[From W. Royce’s 1970 paper]

Or Here?
This Early Work Misled Us

▪ When one thing is labeled “Design” or “Preliminary

Design” that implies that those things that are NOT
so labeled are NOT design

▪ Especially when some of those other things are

indicated as predecessors of Design
Requirements Engineering
Involves Designing
Just What is Design?

▪ Design as Decision Making

▪ Decisions of how to accomplish something
▪ Decisions of how to represent something
▪ A solid approach to design should offer a solid
approach to decision making
▪ Capturing them, and their rationale
▪ Recognizing them when they are made, in the context
▪ Analyzing, comparing and managing alternatives
▪ Reflecting upon them to improve future designs (future
decision making)
▪ Distilling them into practical, reusable design knowledge
Software architecture, definition (1)

The architecture of a software system

defines that system in terms of
computational components and
interactions among those components.

(from Shaw and Garlan, Software Architecture, Perspectives on an

Emerging Discipline, Prentice-Hall, 1996.)

SE, Software Architecture, Hans van Vliet, ©2008 32

Software Architecture

statement

procedure

module

(design) pattern

architecture

SE, Software Architecture, Hans van Vliet, ©2008 33

Software Architecture, definition (2)

The software architecture of a system is the

structure or structures of the system, which
comprise (contains) software elements, the
externally visible properties of those elements,
and the relationships among them.

(from Bass, Clements, and Kazman, Software Architecture in

Practice, SEI Series in Software Engineering. Addison-Wesley,
2003.)

SE, Software Architecture, Hans van Vliet, ©2008 34

Software Architecture

▪ Important issues raised in this definition:

▪ multiple system structures;
▪ externally visible (observable) properties of components.

▪ The definition does not include:

▪ the process;
▪ rules and guidelines;
▪ architectural styles.

SE, Software Architecture, Hans van Vliet, ©2008 35

Architecture & Organization 1

▪ Architecture is those attributes visible to the

programmer
▪ Instruction set, number of bits used for data representation, I/O
mechanisms, addressing techniques.

▪ Organization is how features are implemented

▪ Control signals, interfaces, memory technology.
▪ e.g. Is there a hardware multiply unit or is it done by repeated
addition?
Structure & Function

▪ Structure is the way in which components relate to

each other

▪ Function is the operation of individual components

as part of the structure
Architectural Structures

▪ module structure
▪ conceptual, or logical structure
▪ process, or coordination structure
▪ physical structure
▪ uses structure
▪ calls structure
▪ data flow
▪ control flow
▪ class structure

SE, Software Architecture, Hans van Vliet, ©2008 38

Software Architecture, definition (3)

Architecture is the fundamental organization of a

system embodied (shaped ) 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.)

SE, Software Architecture, Hans van Vliet, ©2008 39

Software Architecture

▪ Architecture is conceptual.

▪ Architecture is about fundamental of things.

▪ Architecture exists in some context.

SE, Software Architecture, Hans van Vliet, ©2008 40

Other points of view

▪ Architecture is high-level design

▪ Architecture is overall structure of the system

▪ Architecture is the structure , including the

principles and guidelines governing their design
and evolution over time

▪ Architecture is components and connectors

SE, Software Architecture, Hans van Vliet, ©2008 41

Software Architecture & Quality

▪ The idea of quality is central in software

architecting: a software architecture is devised to
gain insight in the qualities of a system at the
earliest possible stage.

▪ Some qualities are observable via execution:

performance, security, availability, functionality,
and usability , And some are not observable via
execution: like modifiability, portability,
reusability, integrity and testability

SE, Software Architecture, Hans van Vliet, ©2008 42

Overview

▪ Architecture Design

▪ Viewpoints and view models

▪ Architectural styles
▪ Architecture asssessment
▪ Role of the software architect

SE, Software Architecture, Hans van Vliet, ©2008 43

Attribute-Driven Design (Bass et al, Ch 7)

▪ Choose module to decompose

▪ Refine (polish ) this module:
▪ choose architectural drivers (quality is driving force)
▪ choose pattern that satisfies drivers
▪ apply pattern
▪ Repeat steps

SE, Software Architecture, Hans van Vliet, ©2008 44

Example ADD iterations

▪ 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

SE, Software Architecture, Hans van Vliet, ©2008 45

 Generalized model

▪ Understand problem

▪ Solve it

▪ Evaluate solution

SE, Software Architecture, Hans van Vliet, ©2008 46

Global workflow in architecture design

synthesis architecture
context

backlog evaluation

evaluation
requirements
results

SE, Software Architecture, Hans van Vliet, ©2008 47

Generalized model (cont’d)

assets
architecture

ideas synthesis

backlog evaluation
constraints

eval results

sign.reqs

SE, Software Architecture, Hans van Vliet, ©2008 48

Design issues, options and decisions

A designer is faced with a series of design issues

▪ These are sub-problems of the overall design problem.
▪ Each issue normally has several alternative solutions (or
design options)
▪ The designer makes a design decision to resolve each
issue.
▪ This process involves choosing the best option from
among the alternatives.

SE, Software Architecture, Hans van Vliet, ©2008 49

 Taking decisions

Design Problem
problem space

sub- sub-
problem problem
(or issue) (or issue)

Decision =
best option Decision
Desig
space
Design Design Design
option option n option
option
Decision =
Alternative Alternative best option
solutions solutions

SE, Software Architecture, Hans van Vliet, ©2008 50

 Decision space

The space of possible designs that can be achieved

by choosing different sets of alternatives.

fat-client client in a Programmed in Java

separate
client-server user interface
client layer
style
thin-client Programmed in Visual Basic

Programmed in C++

no separate
monolithic user interface
layer

SE, Software Architecture, Hans van Vliet, ©2008 51

 Tree or graph?

▪ Issues and options are not independent ...

fat-client client in a
separate flexibility
client-server user interface
client layer
style
thin-client
layered MVC

no separate
monolithic user interface
layer

SE, Software Architecture, Hans van Vliet, ©2008 52

 More than just IT

▪ Technical and non- techical issues and options are

intertwined (linked)
▪ Architects deciding on the type of database
Versus (faced )
▪ Management deciding on new strategic partnership (co -
operation's )
or
▪ Management deciding on budget

SE, Software Architecture, Hans van Vliet, ©2008 53

Some (tacit) decisions are related to norms
(lows) and values

SE, Software Architecture, Hans van Vliet, ©2008 54

Types of decisions

▪ Implicit ( tacit ), undocumented

▪ Unaware, tacit, of course knowledge
▪ Explicit (clear) , undocumented
▪ Vaporizes over time
▪ Explicit, explicitly undocumented
▪ Tactical, personal reasons
▪ Explicit, documented
▪ Preferred, exceptional situation

SE, Software Architecture, Hans van Vliet, ©2008 55

Why is documenting design decisions
important?

▪ Prevents repeating (expensive) past steps

▪ Explains why this is a good architecture
▪ Emphasizes (assurance ) qualities and criticality
for requirements/goals
▪ Provides context and background

SE, Software Architecture, Hans van Vliet, ©2008 56

Uses of design decisions

▪ Identify key decisions for a stakeholder

▪ Make the key decisions quickly available.
▪ E.g., introducing new people and make them up2date.
▪ ..., Get a rationale, Validate decisions against reqs
▪ Evaluate impact
▪ If we want to change an element, what are the elements
impacted (decisions, design, issues)?
▪ ..., Clean up the architecture, identify important architectural
drivers

SE, Software Architecture, Hans van Vliet, ©2008 57

Elements of a design decision

▪ Issues: design issues being addressed

▪ Decision
▪ Status: e.g., pending (waiting ), approved
▪ Assumptions: underlying assumptions
▪ Alternatives
▪ Rationale: the why of the decision taken
▪ Implications: e.g. need for further decisions

SE, Software Architecture, Hans van Vliet, ©2008 58

Overview

▪ Viewpoints and view models

▪ Architectural styles
▪ Architecture asssessment
▪ Role of the software architect

SE, Software Architecture, Hans van Vliet, ©2008 59

Software design in UML

▪ Class diagrams, state diagrams, sequence

diagram, etc

▪ Who can read those diagrams?

▪ Which type of questions do they answer?

▪ Do they provide enough information?

SE, Software Architecture, Hans van Vliet, ©2008 60

Who can read those diagrams?

▪ Designer, programmer, tester, maintainer, etc.

▪ Client ?
▪ User ?

SE, Software Architecture, Hans van Vliet, ©2008 61

Which type of questions do they answer?

▪ How much will it cost?

▪ How secure will the system be?
▪ Will it perform?
▪ How about maintenance cost?
▪ What if requirement A is replaced by requirement
B?

SE, Software Architecture, Hans van Vliet, ©2008 62

Analogy with building architecture

▪ Overall picture of building (client)

▪ Front view (client, “beauty” committee)
▪ Separate picture for water supply (plumber)
▪ Separate picture for electrical wiring (electrician)
▪ etc

SE, Software Architecture, Hans van Vliet, ©2008 63

LUC 4

Architecture presentations in practice

▪ By and large two flavors ( types) :
▪ Power point slides – for managers, users, consultants, etc
▪ UML diagrams, for technicians

▪ A small sample …

SE, Software Architecture, Hans van Vliet, ©2008 64

SE, Software Architecture, Hans van Vliet, ©2008 65
SE, Software Architecture, Hans van Vliet, ©2008 66
SE, Software Architecture, Hans van Vliet, ©2008 67
SE, Software Architecture, Hans van Vliet, ©2008 68
SE, Software Architecture, Hans van Vliet, ©2008 69
So, …

▪ Different representations

▪ For different people

▪ For different purposes

▪ These representations are both descriptive and

prescriptive ( progressing )

SE, Software Architecture, Hans van Vliet, ©2008 70

IEEE model for architectural descriptions

Mission

Environment System Architecture

Architecture
Stakeho lder Description Rational e

Concern Viewpoin t View

Library
Viewpoin t Model

SE, Software Architecture, Hans van Vliet, ©2008 71

Some terms (from IEEE standard)

▪ System stakeholder: an individual, team, or

organization (or classes hereof) with interests in,
or concerns relative to a system.

▪ View: a representation of a whole system from the

perspective of a related set of concerns.

▪ Viewpoint: A viewpoint establishes the purposes

and audience for a view and the techniques or
methods employed in constructing a view.

SE, Software Architecture, Hans van Vliet, ©2008 72

Stakeholders

▪ Architect
▪ Requirements engineer
▪ Designer (also of other systems)
▪ Implementor
▪ Tester, integrator
▪ Maintainer
▪ Manager
▪ Quality assurance people

SE, Software Architecture, Hans van Vliet, ©2008 73

Viewpoint specification

▪ Viewpoint name
▪ Stakeholders addressed
▪ Concerns addressed
▪ Language, modeling techniques

SE, Software Architecture, Hans van Vliet, ©2008 74

Kruchten’s 4+1 view model

End-user Programmers
Functionality Software management

Implementation
Logical
Viewpoint
Viewpoint

Scenarios

Process Deployment
Viewpoint Viewpoint

Integrators System engineers

Performance Topology
Scalability Communications

SE, Software Architecture, Hans van Vliet, ©2008 75

4 + 1: Logical Viewpoint

▪ The logical viewpoint supports the functional

requirements, i.e., the services the system should
provide to its end users.

▪ Typically, it shows the key abstractions (e.g.,

classes and interactions amongst them).

SE, Software Architecture, Hans van Vliet, ©2008 76

4 + 1: Process Viewpoint

▪ Addresses concurrent aspects at runtime (tasks,

threads, processes and their interactions)

▪ It takes into account some nonfunctional

requirements, such as performance, system
availability, concurrency and distribution, system
integrity, and fault-tolerance.

SE, Software Architecture, Hans van Vliet, ©2008 77

4 + 1: Deployment Viewpoint

▪ The deployment viewpoint defines how the

various elements identified in the logical, process,
and implementation viewpoints-networks,
processes, tasks, and objects-must be mapped
onto the various nodes.

▪ It takes into account the system's nonfunctional

requirements such as system availability,
reliability (fault-tolerance), performance
(throughput), and scalability.

SE, Software Architecture, Hans van Vliet, ©2008 78

4 + 1: Implementation Viewpoint

▪ The implementation viewpoint focuses on the

organization of the actual software modules in the
software-development environment.

▪ The software is packaged in small chunks-

program libraries or subsystems-that can be
developed by one or more developers.

SE, Software Architecture, Hans van Vliet, ©2008 79

4 + 1: Scenario Viewpoint

▪ The scenario viewpoint consists of a small subset

of important scenarios (e.g., use cases) to show
that the elements of the four viewpoints work
together seamlessly.

▪ This viewpoint is redundant with the other ones

(hence the "+1"), but it plays two critical roles:
▪ it acts as a driver to help designers discover architectural
elements during the architecture design;
▪ it validates and illustrates the architecture design, both
on paper and as the starting point for the tests of an
architectural prototype.

SE, Software Architecture, Hans van Vliet, ©2008 80

Architectural views from Bass et al
(view = representation of a structure)

▪ Module views
▪ Module is unit of implementation
▪ Decomposition, uses, layered, class
▪ Component and connector (C & C) views
▪ These are runtime elements
▪ Process (communication), concurrency, shared data (repository),
client-server
▪ Allocation views
▪ Relationship between software elements and environment
▪ Work assignment, deployment, implementation

SE, Software Architecture, Hans van Vliet, ©2008 81

Module views

▪ Decomposition: units are related by “is a sub

module of”, larger modules are composed of
smaller ones
▪ Uses: relation is “uses” (calls, passes information
to, etc). Important for modifiability
▪ Layered is special case of uses, layer n can only
use modules from layers <n
▪ Class: generalization, relation “inherits from”

SE, Software Architecture, Hans van Vliet, ©2008 82

Component and connector views

▪ Process: units are processes, connected by

communication or synchronization
▪ Concurrency: to determine opportunities for
parallelism (connector = logical thread)
▪ Shared data: shows how data is produced and
consumed
▪ Client-server: cooperating clients and servers

SE, Software Architecture, Hans van Vliet, ©2008 83

Allocation views

▪ Deployment: how software is assigned to

hardware elements
▪ Implementation: how software is mapped onto file
structures
▪ Work assignment: who is doing what

SE, Software Architecture, Hans van Vliet, ©2008 84

How to decide on which viewpoints

▪ What are the stakeholders and their concerns?

▪ Which viewpoints address these concerns?

▪ Prioritize and possibly combine viewpoints

SE, Software Architecture, Hans van Vliet, ©2008 85

Decision visualization

SE, Software Architecture, Hans van Vliet, ©2008 86

Business
viewpoint

SE, Software Architecture, Hans van Vliet, ©2008 87

A caveat (precaution) quality

▪ A view can be used to assess one or more quality

attributes
▪ E.g., some type of module view can be used to
assess modifiability
▪ It should then expose the design decisions that
affect this quality attribute

SE, Software Architecture, Hans van Vliet, ©2008 88

Overview

▪ Architectural styles

▪ Architecture asssessment
▪ Role of the software architect

SE, Software Architecture, Hans van Vliet, ©2008 89

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

SE, Software Architecture, Hans van Vliet, ©2008 90

Components and Connectors

▪ Components are connected by connectors.

▪ They are the building blocks with which an
architecture can be described.
▪ No standard notation has emerged yet.

SE, Software Architecture, Hans van Vliet, ©2008 91

Types of components

▪ computational: does a computation of some sort.

E.g. function , filter.
▪ 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. E.g.
client , server.
▪ controller: governs time sequence of events. E.g.
control module, scheduler.

SE, Software Architecture, Hans van Vliet, ©2008 92

Types of connectors

▪ procedure call (including RPC)

▪ data flow (e.g. pipes)
▪ implicit invocation
▪ message passing
▪ shared data (e.g. blackboard or shared data base)
▪ Instantiation ‫تجسيد ا وتمثيل‬

SE, Software Architecture, Hans van Vliet, ©2008 93

Framework for describing architectural
styles

▪ problem: type of problem that the style addresses.

Characteristics of the reqs’s guide the designer in
his choice for a particular style.
▪ context: characteristics of the environment that
constrain the designer, req’s imposed by the
style.
▪ solution: in terms of components and connectors
(choice not independent), and control structure
(order of execution of components)

SE, Software Architecture, Hans van Vliet, ©2008 94

Main-program-with-subroutines style

a main program and a set of subroutines ( procedures or functions).

problem: hierarchy of functions; result of functional
decomposition, single thread of control
context: language with nested procedures
solution:
▪ system model: modules in a hierarchy, may be weak or strong,
coupling /cohesion arguments
▪ components: modules with local data, as well as global data
▪ connectors: procedure call
▪ control structure: single thread, centralized control: main program
pulls the strings
variants: OO versus non-OO

SE, Software Architecture, Hans van Vliet, ©2008 95

Abstract-data-type style

where the focus is on defining a data type by its behavior (what

operations can be performed on the data) rather than its
implementation (how the data is stored or the operations are
carried out).
ADTs provide a way to encapsulate data and operations .

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

SE, Software Architecture, Hans van Vliet, ©2008 96

solution:
▪ system model: component has its own local data (= secret it hides)
▪ components: managers (servers, objects, adt’s)
▪ connectors: procedure call (message)
▪ control structure: single thread, usually; control is decentralized
variants: caused by language facilities

SE, Software Architecture, Hans van Vliet, ©2008 97

Implicit-invocation style

▪ This style is often used in systems that need to be

flexible and modular, such as event-driven systems
like GUI applications, message-passing systems, or
systems with publish-subscribe architectures.
▪ problem: loosely coupled collection of
components. Useful for applications which must
be reconfigurable.
▪ context: requires event handler, through OS or
language.

SE, Software Architecture, Hans van Vliet, ©2008 98

▪ solution:
▪ system model: independent, reactive processes,
invoked when an event is raised
▪ components: processes that signal events and
react to events
▪ connectors: automatic invocation
▪ control structure: decentralized control.
Components do not know who is going to react.
▪ variants: Tool-integration frameworks, and
languages with special features.

SE, Software Architecture, Hans van Vliet, ©2008 99

Pipes-and-filters style

▪ data flows through a sequence of processing

elements, known as filters, which are connected
by pipes.
▪ Each filter processes the input data it receives
and passes the transformed data to the next filter
through the pipe.

▪ This style is particularly useful for systems that

need to process data in stages, like compilers,
data transformation pipelines, or image
processing systems.
▪ an effective way to build systems where data needs to
be processed in a series of steps.

SE, Software Architecture, Hans van Vliet, ©2008 100

▪ problem: independent, sequential transformations on
ordered data. Usually incremental, Ascii pipes.
▪ context: series of incremental transformations. OS-
functions transfer data between processes. Error-handling
difficult.
▪ solution:
▪ system model: continuous data flow; components incrementally
transform data
▪ components: filters for local processing
▪ connectors: data streams (usually plain ASCII)
▪ control structure: data flow between components; component has
own flow
▪ variants: From pure filters with little internal state to batch
processes

SE, Software Architecture, Hans van Vliet, ©2008 101

Repository (warehouse ) style

Client
Client
Shared
Data
Client

an architectural pattern used to manage large amounts of data and

facilitate its sharing among multiple, independent subsystems or
components
problem: manage richly structured information, to be
manipulated in many different ways. Data is long-lived.
context: shared data to be acted upon by multiple clients

SE, Software Architecture, Hans van Vliet, ©2008 102

solution:
system model: centralized body of information. Independent
computational elements.
components: one memory, many computational
connectors: direct access or procedure call
control structure: varies, may depend on input or state of
computation
variants: traditional data base systems, compilers, blackboard
systems
The Repository (Warehouse) style provides a centralized,
consistent storage system that facilitates communication
between independent clients, making it an effective pattern for
large-scale, data-centric systems.

SE, Software Architecture, Hans van Vliet, ©2008 103

Layered style
Layern

Layer2

Layer1

is a widely-used architectural pattern in software design where a system is

organized into layers, each with specific responsibilities. In this style,
each layer is designed to perform a distinct role, and the layers interact
with each other in a controlled, hierarchical manner.
problem: distinct, hierarchical classes of services.
“Concentric circles” of functionality
context: a large system that requires decomposition (e.g.,
virtual machines, OSI model)

SE, Software Architecture, Hans van Vliet, ©2008 104

solution:
▪ system model: hierarchy of layers, often limited visibility
▪ components: collections of procedures (module)
▪ connectors: (limited) procedure calls
▪ control structure: single or multiple threads
variants: relaxed layering
▪ The Layered Style is an effective way to structure complex
software systems, promoting modularity, separation of
concerns, and maintainability.
▪ It is particularly suitable for large-scale systems where
different functionalities can be logically separated into
distinct layers, improving organization and scalability

SE, Software Architecture, Hans van Vliet, ©2008 105

Model-View-Controller (MVC) style

Controller View
n n

Model
is a popular architectural pattern used in software development,
especially in web applications. It separates the application into
three interconnected components: Model, View, and Controller
problem: separation of UI from application is desirable due to
expected UI adaptations
context: interactive applications with a flexible UI

SE, Software Architecture, Hans van Vliet, ©2008 106

solution:
▪ system model: UI (View and Controller Component(s)) is
decoupled from the application (Model component)
▪ components: collections of procedures (module)
▪ connectors: procedure calls
▪ control structure: single thread
variants: Document-View
▪ How MVC Works: The user interacts with the View, typically by
inputting data or making selections. The View forwards user input
to the Controller, which processes the input. The Controller
updates the Model based on the input, modifying data or triggering
business logic .The Model updates its data and notifies the View
of any changes .The View retrieves the updated data from the
Model and refreshes the UI.

SE, Software Architecture, Hans van Vliet, ©2008 107