Software Architecture Course - Part III Taxonomies - Definitions

Software ArchitectureS

ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Software ArchitecturePart II. Taxonomies1: Definitions

Jose Emilio Labra Gayo

2014

ENEnglish

University of Oviedo


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Software Architecture

High level structure of a software system“Main design decisions of a system”

If you have to change them High cost


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Software Architecture

¿How to design?

CreativityFunRiskCan offer new solutionsCan be unnecessary

MethodEfficient in familiar domains

Predictable resultNot always the best solution

Proven quality techniques

Architect


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Software architecture

Discipline evolvesArchitect must be aware of new advances

New development techniquesStyles and patterns

Best tool = experience (no silver bullet)Self experience From community

Architect


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Software architecting

PrinciplesPatterns

StylesAnti-patterns Software

Architect

CommunityExperience

Stakeholders

Quality Attributes

Constraints

Technology

Architecture


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Quality attributes

A requirement that specifies how well the system does by some measureAlso known as non-functional requirements

Quality attributes are not about some specific behavior

Most of them are -itiesSecurity, 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


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Constraints

Pre-specified design decisionsThey reduce the space of architectures in

which to search for a solutionVery little software is "greenfield"Example:

Frameworks, languages, languages that are required

Constraints are givenArchitect makes design decisions to achieve

other requirements within given constraints


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Architectural styles & patterns


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Architectural styles

Architectural style: General shape of a systemIt contains:

Elements: Components that carry out functionality

Constraints: define how to integrate elementsAttributes: Advantages/disadvantages of a

style


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Are there pure styles?

Pure styles = idealizationIn practice, pure styles rarely appearUsually, systems...

deviate from pure styles......or combine several architectural styles

It is important to understand pure styles to:Understand pros and cons of a styleAssess the consequences of a deviation from

the style


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Definitions

Architectural pattern: Reusable and general solution to some

problem that appears in a given contextImportant: problem


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Pattern vs style

Pattern = solution to a problemStyle = generic, it does not have to be

associated with a problem

Style defines the general architecture of an applicationUsually, an application has one style

...but it can have several patterns

Patterns can appear at different scalesHigh level (architectural patterns)Design (design patterns)Implementation (idioms). . .


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Pattern vs Style

Styles = independent of each otherA pattern can be related with other patterns

A pattern composed of several patternsInteractions between patterns


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Pattern languages and catalogs

Pattern catalogA set of patterns about a subjectIt does not have to be exhaustive

Pattern languageA full pattern catalog about some subject

Goal: document all the possibilitiesThey usually include relationships between

patterns Graphical map


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Example of pattern language

Source: "SOA with REST" book


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Architectural tactic

A transformation on an architecture that results in the improvement of some specific quality attributesEnumeration of techniques employed to

achieve some particular quality attributesHow to find good tactics?

Experience of architectsDocumented experience in architectural styles &

patterns


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Software Architectures


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Temporal aspect

Architecture has a temporal aspectDesign decisions are made and unmade over

a system’s lifetimeAt any given point in time the system has

only one architectureA system’s architecture will change over

time


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Prescriptive Architecture

As intended architectureDesign decisions made prior to system's

implementationCan be different from the implemented systemArchitecture of the system as-designedIt usually employs pure styles


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Prescriptive architecture: example


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Descriptive Architecture

As-implemented architectureDescribes how the system was builtDesign decisions taken during development

and maintenance


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Prescriptive vs Descriptive

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?

Prescriptive (as intended) Descriptive (as implemented)


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

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 ofDeveloper sloppinessPerception of short deadlines which prevent

thinking through and documenting Lack of documented prescriptive

architectureNeed or desire for code optimizationsInadequate techniques or tool support


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

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 architectureIt may cause violations of architectural stylesIf not properly addressed, it can lead to

architecture erosion


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Architectural degradation/erosionIntroduction of design decisions in descriptive

architecture that violate prescriptive architectureIt can lead to technical debt


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Technical debtWork that needs to be done before some

job can be considered doneIf the debt is not paid, it keeps accumulating

It makes changes harder laterSome 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

maintenancehttp://martinfowler.com/bliki/TechnicalDebt.html


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Architecture recovery

Determining the software architecture from its implementation artifactsImplementation artifacts:

source code, executable files, generated docs,...

Every system has an architectureNot always documented or identified

Architecture recovery from a software systemReverse-engineeringUsually with documentationEnsure that descriptive architecture matches

prescriptive one


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Application level view

Complex and virtually incomprehensible!


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Deployment view

A software system cannot fulfill its purpose until it is deployedExecutable 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 dimensionsAvailable memoryPower consumptionRequired network bandwidth


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Example: Deployment view

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


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Software architecture's elementsA 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 elementsProcessing Data, also referred as information or stateInteraction


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Components

Elements that encapsulate processing and data at runtime

DefinitionA 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


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

ConnectorsIn complex systems interaction may

become more important and challenging than the functionality of the individual components

DefinitionA 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, ...


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Taxonomy of Software applications


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Taxonomy of Software applications

Systems software (utilities)Helps analyze, configure, optimize, maintain a

computerIt serves some application softwareIt doesn't serve a user directly

ExamplesOperating systems, Utility programs, Library

programs, Translator software

Application softwareIt serves a user

It usually depends on system softwareClassification

General purpose, Special purpose


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Some types of Software applicationsDesktop applicationsLibrariesCommand line toolsWeb applicationsMobile appsRIA (Rich Internet Applications)Web servicesMashupsEmbedded systemsReal Time systems…

More info: http://en.wikipedia.org/wiki/Application_software


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Classification of Styles


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Parts of a style description

OverviewElements and relationsConstraintsPros & cons (quality attributes)Relations with other stylesExamples


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Classification of stylesAllocation

Building, deployment and distributionModularity

Structure of the system at development timeComponents & connectors: Behavior

Expresses runtime behaviorIntegration

Relationship between software systemsBusiness

Relationship with enterprise environment