Software Architecture - Allocation taxonomies: building, deployment and distribution channels

Software ArchitectureS

ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Software ArchitecturePart II. Software architecture taxonomies2: Allocation and Building

Jose Emilio Labra Gayo

2014

University of Oviedo

ENEnglish


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Allocation & Building

Relationship between software and its environment

Building, development and distribution


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Contents

BuildingBuilding styles and methodologies

Traditional, iterative, agileConfiguration Management

Version controlDependency management

Deployment Continuous integration

DistribuciónCanales de distribución


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Building styles & methodologies

Note: This is just a selection. A more extended list can be found at:http://en.wikipedia.org/wiki/List_of_software_development_philosophies


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Incremental piecemeal

Development by needCodification without following the

architectureThrow-away softwareBudget constraints


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Proposed in 70s

Waterfall

Requirements

Design

Implementation

Verification

Maintenance


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Big Design Up Front

Antipattern of traditional modelsToo much documentation that nobody readsDocumentation different from developed

systemArchitecture degradationSoftware artifacts implemented but unused


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

V Model

Requirements

Analysis

Design

ObjectDesign

UnitTesting

Integration

Testing

SystemTesting

Aceptance

Testing

Time

DetailLevel

Low

HighImplementatio

n

Project Definition

Project Test and

Integration


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Iterative Models

Based on PrototypesRisk assessment after each iteration

InitialPlanning

Planning

Requirements Analysis & Design

Implementation

Deployment

TestingEvaluation


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

RUP (Rational Unified Process)

Fuente: Wikipedia. http://es.wikipedia.org/wiki/Archivo:Rup_espanol.gif

Very popularIterative

process

Inception Elaboration Construction TransitionProcess Workflow

Requirements

Analysis

Design

Implementation

Test

Deployment

I1 I2 T2T1E1 E2 C1 C2 C3 C4

Inception Elaboration Construction TransitionSupport workflow

Configuration Management

Project Management

Environment

Iterations


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Agile methodologies

Lots of variantsRAD (www.dsdm.org, 95)SCRUM (Sutherland & Schwaber, 95)XP - eXtreme Programming (Beck, 99)Feature driven development (DeLuca, 99)Adaptive software development (Highsmith, 00)Lean Development (Poppendieck, 03)Crystal Clear (Cockburn, 04)Agile Unified Process (Ambler, 05). . .


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Agile methods

Agile Manifesto (www.agilemanifesto.org)

Individuals and interactions

over Process and Tools

Working Software

ComprehensiveDocumentation

over

CustomerCollaboration

over ContractNegotiation

Respondingto change

over Following aPlan


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Agile methods

FeedbackChanges of code are ok during development

Minimize riskSoftware in short intervalsIterations of daysEach iteration takes all the development

cycle


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Agile methods

Some practices (eXtreme Programming)1. Short-time planifications2. Testing3. Pair programming (revisiones de código)4. Refactoring5. Simple design6. Collective code ownership7. Continuous integration8. On-site customer9. Small releases10. Sustainable pace11. Coding standards


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Agile methods

1. Short time planificationAfter each iteration, update planificationRequirements through user stories

Short descriptions (size of a card)Goals ordered by usnig according to priorityRisk and resources estimated by developers

User stories = acceptance testingAdopt change

Original plan

Current plan


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Agile methods

2.- Testing: types of testing

Functional Acceptance Testing

ShowcasesUsability testing

Exploratory testing

Nonfunctional Acceptance testing

(capacity, security,…)

Unit testingIntegration testing

System testing

Automated Manual

Automated Manual/ AutomatedSu

pp

ort

pro

gra

mm

ing Critiq

ue p

roje

ct

Business facing

Technology facing

Source: Continuous delivery, J Humble, D. Farley, 2010


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Agile methods

2. TestingTest driven development

Write a test before codingInitially, code will failGoal: pass the testResult:

Automated set of testsEasier refactoring


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Agile methods

2. Testing: Acceptance testingBehaviour-driven development (BDD)

Tests come from user storiesThey can be written collaboratively with the

clientTools: Cucumber, JBehave, Specs2,...

Tests act as contractsCan also be used to measure progress


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Agile methods

2. Testing: FIRST principlesF - Fast

Execution of (subsets of) tests must be quickI - Independent:

No tests depend on othersR - Repeatable:

If tests are run N times, the result is the sameS - Self-checking

Test can automatically detect if passedT - Timely

Tests are written at the same time (or before) code


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Agile methods

2. Testing: test doublesDummy objects: objects that are passed but

not usedFake objects: Contain a partial

implementation. Can be:Stubs: contain specific answers to some

requestsSpies: stubs that record information for

debuggingMocks: mimic the behaviour of the real object

Mocks may contain assertions about the order/number of times methods are called


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Agile methods

3. Pair programming2 software engineers work together

Driver manages keyboard and creates implementation

Observador identifies failures and gives ideasRoles are exchanged after some time


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Agile methods

4. Simple designReaction to Big Design Up FrontObtain the simpler design that works

Automated documentationJavaDoc and similar tools

CRC cards


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Agile methods

5. RefactoringImprove design without changing

functionalitySimplify code (eliminate redundant code)Search new opportunities for abstraction

Regression testingBased on the set of tests


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Agile Methods

6. Collective ownership of codeCode belongs to the project, not to some

engineerEngineers must be able to browse and

modify any part of the codeEven if they didn't wrote itAvoid code fragments that only one person can

modify


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Agile Methods

7. Continuous integrationDevelop test cases and work to pass them

Pass 100% test casesIntegrate

That process can be repeated 1 or 2 times/dayGoal: avoid integration hell


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Agile methods

8. On-place customerCustomer available to clarify user stories

and help taking critical business decisionsAdvantages

Developers don't do guessesDevelopers don't have to wait for decisionsImproves communication


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Agile methods

9. Small releasesSmall enough while offering value to the

userReleases are not, for example, implement DBObtain feedback soon from client

Plan next release after each iterationTry to release something every week


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Agile methods

10. Sustainable pace40h/week = 40h/week

Avoid extra-work loadsTired programmers write bad code

It will slow the development at long time


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Agile methods

11. Clean codeFacilitate code refactoring by other peopleUse good practices

Code styles and guidelinesAvoid code smells

software craftmanship manifestClean Code (Robert C. Martin)

Fuente: Clean Code. Robert Martin


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Agile methods

VariantsScrum

Project/people managment

Divide work in sprints15' daily meetingsProduct Backlog

KanbanLean model

Just in Time DevelopmentLimit workloads


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo



ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo


Different software versionsNew or different functionalitiesIssues and bugs managementNew execution environments

Configuration management = Manage evolution of softwareSystem changes = team activitiesNecessary cost and effort


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Version control

Systems that manage different code versionsBe able to Access all the system versions

Easy to rollbackDifferences between versions

Collaborative developmentBranch managementMetadata

Author of a versión, update date, who to blame, etc.


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Baseline

Baselines (Reference line): Software that is subject to configuration management

Version1.0

Windows

Version1.5Sun

Version1.5

Linux

Version2.0

Windows

Version2.5 Desktop

Linux

Version2.5 Desktop

Server


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Releases and versions

Version: instance of a system which has a different functionality to other instances

Release (deliverable): instance of a system which is distributed to external people outside to development team.It could be considered a final product at

some point of time


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Version naming - some conventionsPre-alfa

Before testingAlfa

During testingBeta (or prototype)

Testing made by some usersBeta-tester: user that does the testing

Release-candidateBeta versión that could become final product


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Other schema namingsSimple numbering

1.1, 1.1-alphaUsing attributes

Date, creator, language, client, state,...Recognizable Names

Ganimede, Galileo, Helios, Indigo, Juno,...

Precise Pangolin, Quantal Quetzal,...


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Deliverables publication

A release implies functionality changesPlanning

Publishing a release has costsUsually, current users don't want new

releasesExternal factors:

Marketing, clients, hardware, ...Agile model: frequent releases

Continuous integration minimizes risk


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Deliverables publication

A release is more than just softwareConfiguration filesSome needed data filesInstallation programsDocumentationPublicity and packaging

Distribution channels: Physical (CDs, DVDs), Web (download),

stores


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Version control

DefinitionsRepository: where changes

are storedBaseline: Initial versionDelta: changes from one

version to otherTrunk (master): Main branch

in a systemBranch: deviation from main

branchTag: Marks a line of versions

1

Baseline

4

Trunk

2

3Branchs

5

6

9

7

T1

T2

8

10

Tags merge


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Version control

DefinitionsCheckout: Working Local copy

from a given branchCommit: Introduce current

changes in the control version system.

Merge: Combine two sets of changes

Branching styles: by feature, by team, by version

1

Baseline

4

Trunk

2

3Branchs

5

6

9

7

T1

T2

8

10

Tagsmerge


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Version control

2 typesCentralized

Centralized repository for all the codeCentralized administrationCVS, Subversion, ...

DistributedEach user has its own repositoryGit, Mercurial


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Git

Designed by Linus Torvalds (Linux), 2005Goals:

Applications with large number of source code files

EfficiencyDistributed workEcach development has its own repository

Local copy of all the changes historyIt is posible to do commits even without internet

connection

Support for non-lineal development (branching)


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Local components

3 local components:Local working directoryIndex (stage area). Also called cacheProject history: Stores versions or commitsHEAD (most recent version)

ProjectHistoryCommit

s

commitadd

rm

HEADLocal

workingdirectory

Indexstage area


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Branches

Git facilitates branch managementmaster = initial branch

Operations:Create branches (branch)Change branch (checkout)Combine (merge)Tag branches (tag)

Multiple branching styles

masterdevelop hotfix-1feature-1feature-2

0.1

1.0

0.2

tags

Branches


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Remote repositories

Local workingdirectory

HistoryCommit

s

Indexstage area

Remoterepositoryorigin

push

clonefetchpull

commitadd

rm

Local Machine

HEAD

Connect with remote repositoriesorigin = initial


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Git - usual commands

init: inicialize repositoryclone: clone a repositoryadd: add contents to indexcommit: record changesstatus: check state of repositorypull: get changes from an external repositorypush: put changes in an external repositorybranch: manage branches (list, create, delete)merge: combine two branchescheckout: recover a given branchrm: delete filesmv: move files

.gitignore file indicates which files are not going to be tacked by version control system


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Git typical workflowLocal

workstation

Development

Build

Central repository

Build

pull

pushBuild

Done!


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Dependency managementLibrary: Collection of functionalities used

by the system that is being developedSystem depends on that library

Library can depend on other librariesLibrary can evolve

Incompatible versions appear

Dependency graph

Mozilla Firefox dependency graphSource: The purely functional deployment model. E. Dolstra (PhdThesis, 2006)


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Dependency management

Different modelsLocal installation: libraries are installed for all the

systemExample: Ruby Gems

Embed external libraries in the system (version control)Ensures a correct version

External linkExternal repository that contains the librariesDepends on Internet and on library evolution


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Automated building

Tools to automate building and deploymentOrganize different tasks

Dependencies between tasksThey have to ensure that:

Execute all prerequisitesExecute them only once Inicialize

Prepare testingdata

Compilesourcecode

Compile testing

code

Runtesting


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Automate building

make: Included in UnixProduct orientedDeclarative language based on rules

When the Project is complex, configuration files can be difficult to manage/debug

Several versions: BSD, GNU, Microsoft

Very popular in C, C++, etc.


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Automate building

ant: Java PlatformTask orientedXML syntax (build.xml)


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Automate building

maven: Java PlatformConvention over configurationManage Project lifecycleDependency managementXML syntax (pom.xml)


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Automate building

Embedded languagesDomain specific languages embedded in higher

level onesGreat versatilityExamples: gradle (Groovy)sbt (Scala)rake (Ruby)Buildr (Ruby)…


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Execution environtments

A staging environment is also used

Developmentenvironment

Testing Environments

ProductionEnvironment

TestingServer

IntegrationServer

VersionControl

ProductionServer

Server farm


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Continuous integration

Continuous integration toolsHudson, Jenkins, Travis, Bamboo

ContinuousIntegration

WebInterface

Reports

checkout/commit

Central Coderepository

DevelopmentTeam


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Social coding

Public repositories of source codeDifferent policiesExamples:

SourceforgeGoogle projectsBitbucketGithub


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Tools in the cloud

Several tools to help development in the cloud

Examples:IaaS: Infrastructure

Amazon ECSPaaS: Platform

Google AppEngine, HerokuSaaS: Software

GMail, GDocs, etc.


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Distribution modelsProduct linesDistribution channels


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Product lines

Product line: products that share a set of functionalities to satisfy some given market segmentGoal:

Reduce development effortImprove productivityEvolve from a single product to a product line


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Product lines

RequirementsIdentify generic solutions to common

problemsComponent based developmentGeneric Platforms

Software reuseAutomatic system generation


ch

ool

of

Com

pu

ter

Scie

nce

Un

ivers

ity

of

Ovi

edo

Distribution channels

Traditional distributionCDs, DVDs, ...

Web basedDownloads, FTP, ...

Application marketsLinux packagesApp stores:

AppStore, Google Play, Windows Store

Engineering

Software Architecture - Allocation taxonomies: building, deployment and distribution channels