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
Software ArchitectureS
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
Software ArchitectureS
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
Software ArchitectureS
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
Software ArchitectureS
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
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Proposed in 70s
Waterfall
Requirements
Design
Implementation
Verification
Maintenance
Software ArchitectureS
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
Software ArchitectureS
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
Software ArchitectureS
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
Software ArchitectureS
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
Software ArchitectureS
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). . .
Software ArchitectureS
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
Software ArchitectureS
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
Software ArchitectureS
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
Software ArchitectureS
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
Software ArchitectureS
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
Software ArchitectureS
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
Software ArchitectureS
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
Software ArchitectureS
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
Software ArchitectureS
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
Software ArchitectureS
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
Software ArchitectureS
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
Software ArchitectureS
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
Software ArchitectureS
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
Software ArchitectureS
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
Software ArchitectureS
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
Software ArchitectureS
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
Software ArchitectureS
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
Software ArchitectureS
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
Software ArchitectureS
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
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Configuration Management
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Configuration Management
Different software versionsNew or different functionalitiesIssues and bugs managementNew execution environments
Configuration management = Manage evolution of softwareSystem changes = team activitiesNecessary cost and effort
Software ArchitectureS
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.
Software ArchitectureS
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
Software ArchitectureS
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
Software ArchitectureS
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
Software ArchitectureS
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,...
Software ArchitectureS
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
Software ArchitectureS
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
Software ArchitectureS
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
Software ArchitectureS
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
Software ArchitectureS
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
Software ArchitectureS
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)
Software ArchitectureS
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
Software ArchitectureS
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
Software ArchitectureS
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
Software ArchitectureS
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
Software ArchitectureS
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!
Software ArchitectureS
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)
Software ArchitectureS
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
Software ArchitectureS
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
Software ArchitectureS
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.
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Automate building
ant: Java PlatformTask orientedXML syntax (build.xml)
Software ArchitectureS
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)
Software ArchitectureS
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)…
Software ArchitectureS
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
Software ArchitectureS
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
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Social coding
Public repositories of source codeDifferent policiesExamples:
SourceforgeGoogle projectsBitbucketGithub
Software ArchitectureS
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.
Software ArchitectureS
ch
ool
of
Com
pu
ter
Scie
nce
Un
ivers
ity
of
Ovi
edo
Distribution modelsProduct linesDistribution channels
Software ArchitectureS
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
Software ArchitectureS
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
Software ArchitectureS
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