Software Architecture Course - Part III Taxonomies - Definitions

Software Architecture
School of Computer Science University of Oviedo
University of Oviedo
Part II. Taxonomies
1: Definitions
2014 Jose Emilio Labra Gayo

High level structure of a software system
“Main design decisions of a system”
If you have to change them  High cost

¿How to design?
Creativity
Fun
Risk
Can offer new solutions
Can be unnecessary
Method
Efficient in familiar domains
Predictable result
Not always the best solution
Proven quality techniques
Architect

Software architecture
Discipline evolves
Architect must be aware of new advances
New development techniques
Styles and patterns
Best tool = experience (no silver bullet)
Self experience
From community
Architect

Software architecting
Principles
Patterns
Styles
Anti-patterns Software
Architect
Community
Experience
Stakeholders
Quality
Attributes
Constraints
Technology
Architecture

Quality attributes
A requirement that specifies how well the system
does by some measure
Also known as non-functional requirements
Quality attributes are not about some specific behavior
Most of them are -ities
Security, Deployability, Modifiability, Accessibility,
reliability, scalability, testability, usability, operability...
Not all are -ities:
Perfomance, resilience, fault tolerance, price, ...
ISO 25010: list of some non-functional requirements

Constraints
Pre-specified design decisions
They reduce the space of architectures in which to
search for a solution
Very little software is "greenfield"
Example:
Frameworks, languages, languages that are required
Constraints are given
Architect makes design decisions to achieve other
requirements within given constraints

Architectural styles
Architectural style:
General shape of a system
It contains:
Elements: Components that carry out functionality
Constraints: define how to integrate elements
Attributes: Advantages/disadvantages of a style

Are there pure styles?
Pure styles = idealization
In practice, pure styles rarely appear
Usually, systems...
deviate from pure styles...
...or combine several architectural styles
It is important to understand pure styles to:
Understand pros and cons of a style
Assess the consequences of a deviation from the style

Definitions
Architectural pattern:
Reusable and general solution to some problem that
appears in a given context
Important: problem

Pattern vs style
Pattern = solution to a problem
Style = generic, it does not have to be associated with a
problem
Style defines the general architecture of an
application
Usually, an application has one style
...but it can have several patterns
Patterns can appear at different scales
High level (architectural patterns)
Design (design patterns)
Implementation (idioms)
. . .

Pattern vs Style
Styles = independent of each other
A pattern can be related with other patterns
A pattern composed of several patterns
Interactions between patterns

Pattern languages and catalogs
Pattern catalog
A set of patterns about a subject
It does not have to be exhaustive
Pattern language
A full pattern catalog about some subject
Goal: document all the possibilities
They usually include relationships between patterns
Graphical map

Example of pattern language
Source: "SOA with REST" book

Architectural tactic
A transformation on an architecture that results in
the improvement of some specific quality attributes
Enumeration of techniques employed to achieve some
particular quality attributes
How to find good tactics?
Experience of architects
Documented experience in architectural styles & patterns

Temporal aspect
Architecture has a temporal aspect
Design decisions are made and unmade over a
system’s lifetime
At any given point in time the system has only one
architecture
A system’s architecture will change over time

Prescriptive Architecture
As intended architecture
Design decisions made prior to system's implementation
Can be different from the implemented system
Architecture of the system as-designed
It usually employs pure styles

Prescriptive architecture: example

Descriptive Architecture
As-implemented architecture
Describes how the system was built
Design decisions taken during development and
maintenance

Prescriptive vs Descriptive
Prescriptive (as intended) Descriptive (as implemented)
Which architecture is “correct”?
Are the two architectures consistent with one another?
What criteria are used to establish the consistency between the two architectures?
On what information is the answer to the preceding questions based?

Architecture evolution
When a system evolves, ideally its prescriptive
architecture is modified first
In practice, the system – and thus its descriptive
architecture – is often directly modified
This happens because of
Developer sloppiness
Perception of short deadlines which prevent
thinking through and documenting
Lack of documented prescriptive architecture
Need or desire for code optimizations
Inadequate techniques or tool support

Architecture drift
Introduction of design decisions that do not appear
in prescriptive architecture, but do not conflict
with it.
Does not necessarily result in violations of
prescriptive architecture
It may cause violations of architectural styles
If not properly addressed, it can lead to architecture
erosion

Architectural degradation/erosion
Introduction of design decisions in descriptive architecture
that violate prescriptive architecture
It can lead to technical debt

Technical debt
Work that needs to be done before some job can
be considered done
If the debt is not paid, it keeps accumulating
It makes changes harder later
Some causes
Business pressures, lack of process understanding, lack
of test suite, non-modularity, lack of documentation,
lack of collaboration, delayed refactoring...
Interest payments:
Local maintenance by users or absence of
maintenance
http://martinfowler.com/bliki/TechnicalDebt.html

Architecture recovery
Determining the software architecture from its
implementation artifacts
Implementation artifacts:
source code, executable files, generated docs,...
Every system has an architecture
Not always documented or identified
Architecture recovery from a software system
Reverse-engineering
Usually with documentation
Ensure that descriptive architecture matches
prescriptive one

Application level view

Deployment view
A software system cannot fulfill its purpose until it
is deployed
Executable modules are physically placed on the
hardware devices on which they are supposed to
run
The deployment view of an architecture can be
critical in assessing whether the system will be
able to satisfy its requirements
Possible assessment dimensions
Available memory
Power consumption
Required network bandwidth

Example: Deployment view
Source: Software Architecture, foundations, theory and practice. Taylor et al. 2009

Software architecture's elements
A software system’s architecture typically is not
(and should not be) a uniform monolith
A software system’s architecture should be a
composition and interplay of different elements
Processing
Data, also referred as information or state
Interaction

Components
Elements that encapsulate processing and data at runtime
Definition
A software component is an architectural entity that
encapsulates a subset of the system’s functionality and/or
data
restricts access to that subset via an explicitly defined
interface
has explicitly defined dependencies on its required
execution context
Components typically provide application-specific services

Connectors
In complex systems interaction may become more
important and challenging than the functionality
of the individual components
Definition
A software connector is an architectural building
block tasked with effecting and regulating
interactions among components
Examples:
procedure calls, shared memory connectors,
message passing, streaming connectors,
wrappers/adaptors, ...

Taxonomy of Software applications
Systems software (utilities)
Helps analyze, configure, optimize, maintain a computer
It serves some application software
It doesn't serve a user directly
Examples
Operating systems, Utility programs, Library programs,
Translator software
Application software
It serves a user
It usually depends on system software
Classification
General purpose, Special purpose

Some types of Software applications
Desktop applications
Libraries
Command line tools
Web applications
Mobile apps
RIA (Rich Internet Applications)
Web services
Mashups
Embedded systems
Real Time systems
…
More info: http://en.wikipedia.org/wiki/Application_software

Parts of a style description
Overview
Elements and relations
Constraints
Pros & cons (quality attributes)
Relations with other styles
Examples

Classification of styles
Allocation
Building, deployment and distribution
Modularity
Structure of the system at development time
Components & connectors: Behavior
Expresses runtime behavior
Integration
Relationship between software systems
Business
Relationship with enterprise environment

Software Architecture Course - Part III Taxonomies - Definitions

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (18)

Similar to Software Architecture Course - Part III Taxonomies - Definitions

Similar to Software Architecture Course - Part III Taxonomies - Definitions (20)

More from Jose Emilio Labra Gayo

More from Jose Emilio Labra Gayo (20)

Recently uploaded

Recently uploaded (20)

Software Architecture Course - Part III Taxonomies - Definitions