(INDIRA) Call Girl Aurangabad Call Now 8617697112 Aurangabad Escorts 24x7
Software Architecture - Allocation taxonomies: building, deployment and distribution channels
1. Software Architecture
School of Computer Science University of Oviedo
University of Oviedo
Software Architecture
Part II. Software architecture taxonomies
2: Allocation and Building
2014 Jose Emilio Labra Gayo
2. Software Architecture
School of Computer Science University of Oviedo
Allocation & Building
Relationship between software and its environment
Building, development and distribution
3. Software Architecture
School of Computer Science University of Oviedo
Contents
Building
Building styles and methodologies
Traditional, iterative, agile
Configuration Management
Version control
Dependency management
Deployment
Continuous integration
Distribución
Canales de distribución
4. Software Architecture
School of Computer Science University of Oviedo
Note: This is just a selection. A more extended list can be found at:
http://en.wikipedia.org/wiki/List_of_software_development_philosophies
5. Software Architecture
School of Computer Science University of Oviedo
Incremental piecemeal
Development by need
Codification without following the architecture
Throw-away software
Budget constraints
6. Software Architecture
School of Computer Science University of Oviedo
Waterfall
Proposed in 70s
Requirements
Design
Implementation
Verification
Maintenance
7. Software Architecture
School of Computer Science University of Oviedo
Big Design Up Front
Antipattern of traditional models
Too much documentation that nobody reads
Documentation different from developed system
Architecture degradation
Software artifacts implemented but unused
8. Software Architecture
School of Computer Science University of Oviedo
V Model
Requirements
Analysis
Design
Object
Design
Integration
Testing
Unit
Testing
System
Testing
Aceptance
Testing
Time
Detail
Level
Low
Project
Definition
High Implementation
Project
Test and
Integration
9. Software Architecture
School of Computer Science University of Oviedo
Iterative Models
Based on Prototypes
Risk assessment after each iteration
Initial
Planning
Requirements Analysis &
Planning
Design
Implementation
Deployment
Testing
Evaluation
10. Software Architecture
School of Computer Science University of Oviedo
RUP (Rational Unified Process)
Fuente: Wikipedia.
http://es.wikipedia.org/wiki/Archivo:Rup_espanol.gif
Very popular
Iterative process
Inception Elaboration Construction Process Transition
Workflow
Requirements
Analysis
Design
Implementation
Test
Deployment
I1 I2 E1 E2 C1 C2 C3 C4 T1 T2
Iterations
Support Inception Elaboration Construction Transition
workflow
Configuration
Management
Project
Management
Environment
11. Software Architecture
School of Computer Science University of Oviedo
Agile methodologies
Lots of variants
RAD (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)
. . .
12. Software Architecture
School of Computer Science University of Oviedo
Agile methods
Agile Manifesto (www.agilemanifesto.org)
Individuals and
interactions
over Process and Tools
Working
Software
Comprehensive
Documentation
over
Customer
Collaboration
over Contract
Negotiation
Responding
to change
over Following a
Plan
13. Software Architecture
School of Computer Science University of Oviedo
Agile methods
Feedback
Changes of code are ok during development
Minimize risk
Software in short intervals
Iterations of days
Each iteration takes all the development cycle
14. Software Architecture
School of Computer Science University of Oviedo
Agile methods
Some practices (eXtreme Programming)
1. Short-time planifications
2. Testing
3. Pair programming (revisiones de código)
4. Refactoring
5. Simple design
6. Collective code ownership
7. Continuous integration
8. On-site customer
9. Small releases
10. Sustainable pace
11. Coding standards
15. Software Architecture
School of Computer Science University of Oviedo
Agile methods
1. Short time planification
After each iteration, update planification
Requirements through user stories
Short descriptions (size of a card)
Goals ordered by usnig according to priority
Risk and resources estimated by developers
User stories = acceptance testing
Adopt change
Original plan
Current plan
16. Software Architecture
School of Computer Science University of Oviedo
Agile methods
2.- Testing: types of testing
Automated Manual
Functional Acceptance
Testing
Showcases
Usability testing
Exploratory testing
Nonfunctional
Acceptance testing
(capacity, security,…)
Unit testing
Integration testing
System testing
Automated Manual/ Automated
Support programming
Critique project
Business facing
Technology facing
Source: Continuous delivery, J Humble, D. Farley, 2010
17. Software Architecture
School of Computer Science University of Oviedo
Agile methods
2. Testing
Test driven development
Write a test before coding
Initially, code will fail
Goal: pass the test
Result:
Automated set of tests
Easier refactoring
18. Software Architecture
School of Computer Science University of Oviedo
Agile methods
2. Testing: Acceptance testing
Behaviour-driven development (BDD)
Tests come from user stories
They can be written collaboratively with the client
Tools: Cucumber, JBehave, Specs2,...
Tests act as contracts
Can also be used to measure progress
19. Software Architecture
School of Computer Science University of Oviedo
Agile methods
2. Testing: FIRST principles
F - Fast
Execution of (subsets of) tests must be quick
I - Independent:
No tests depend on others
R - Repeatable:
If tests are run N times, the result is the same
S - Self-checking
Test can automatically detect if passed
T - Timely
Tests are written at the same time (or before) code
20. Software Architecture
School of Computer Science University of Oviedo
Agile methods
2. Testing: test doubles
Dummy objects: objects that are passed but not used
Fake objects: Contain a partial implementation.
Can be:
Stubs: contain specific answers to some requests
Spies: stubs that record information for debugging
Mocks: mimic the behaviour of the real object
Mocks may contain assertions about the order/number of
times methods are called
21. Software Architecture
School of Computer Science University of Oviedo
Agile methods
3. Pair programming
2 software engineers work together
Driver manages keyboard and creates implementation
Observador identifies failures and gives ideas
Roles are exchanged after some time
22. Software Architecture
School of Computer Science University of Oviedo
Agile methods
4. Simple design
Reaction to Big Design Up Front
Obtain the simpler design that works
Automated documentation
JavaDoc and similar tools
CRC cards
23. Software Architecture
School of Computer Science University of Oviedo
Agile methods
5. Refactoring
Improve design without changing functionality
Simplify code (eliminate redundant code)
Search new opportunities for abstraction
Regression testing
Based on the set of tests
24. Software Architecture
School of Computer Science University of Oviedo
Agile Methods
6. Collective ownership of code
Code belongs to the project, not to some engineer
Engineers must be able to browse and modify any
part of the code
Even if they didn't wrote it
Avoid code fragments that only one person can modify
25. Software Architecture
School of Computer Science University of Oviedo
Agile Methods
7. Continuous integration
Develop test cases and work to pass them
Pass 100% test cases
Integrate
That process can be repeated 1 or 2 times/day
Goal: avoid integration hell
26. Software Architecture
School of Computer Science University of Oviedo
Agile methods
8. On-place customer
Customer available to clarify user stories and help
taking critical business decisions
Advantages
Developers don't do guesses
Developers don't have to wait for decisions
Improves communication
27. Software Architecture
School of Computer Science University of Oviedo
Agile methods
9. Small releases
Small enough while offering value to the user
Releases are not, for example, implement DB
Obtain feedback soon from client
Plan next release after each iteration
Try to release something every week
28. Software Architecture
School of Computer Science University of Oviedo
Agile methods
10. Sustainable pace
40h/week = 40h/week
Avoid extra-work loads
Tired programmers write bad code
It will slow the development at long time
29. Software Architecture
School of Computer Science University of Oviedo
Agile methods
11. Clean code
Facilitate code refactoring by other people
Use good practices
Code styles and guidelines
Avoid code smells
software craftmanship manifest
Clean Code (Robert C. Martin)
Fuente: Clean Code. Robert Martin
30. Software Architecture
School of Computer Science University of Oviedo
Agile methods
Variants
Scrum
Project/people managment
Divide work in sprints
15' daily meetings
Product Backlog
Kanban
Lean model
Just in Time Development
Limit workloads
32. Software Architecture
School of Computer Science University of Oviedo
Configuration Management
Different software versions
New or different functionalities
Issues and bugs management
New execution environments
Configuration management = Manage evolution of
software
System changes = team activities
Necessary cost and effort
33. Software Architecture
School of Computer Science University of Oviedo
Version control
Systems that manage different code versions
Be able to Access all the system versions
Easy to rollback
Differences between versions
Collaborative development
Branch management
Metadata
Author of a versión, update date, who to blame, etc.
34. Software Architecture
School of Computer Science University of Oviedo
Baseline
Baselines (Reference line): Software that is subject
to configuration management
Version
1.0
Windows
Version
2.0
Windows
Version
1.5
Linux
Version
1.5
Sun
Version
2.5 Desktop
Linux
Version
2.5 Desktop
Server
35. Software Architecture
School of Computer Science University of Oviedo
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
36. Software Architecture
School of Computer Science University of Oviedo
Version naming - some conventions
Pre-alfa
Before testing
Alfa
During testing
Beta (or prototype)
Testing made by some users
Beta-tester: user that does the testing
Release-candidate
Beta versión that could become final product
37. Software Architecture
School of Computer Science University of Oviedo
Other schema namings
Simple numbering
1.1, 1.1-alpha
Using attributes
Date, creator, language, client, state,...
Recognizable Names
Ganimede, Galileo, Helios, Indigo, Juno,...
Precise Pangolin, Quantal Quetzal,...
38. Software Architecture
School of Computer Science University of Oviedo
Deliverables publication
A release implies functionality changes
Planning
Publishing a release has costs
Usually, current users don't want new releases
External factors:
Marketing, clients, hardware, ...
Agile model: frequent releases
Continuous integration minimizes risk
39. Software Architecture
School of Computer Science University of Oviedo
Deliverables publication
A release is more than just software
Configuration files
Some needed data files
Installation programs
Documentation
Publicity and packaging
Distribution channels:
Physical (CDs, DVDs), Web (download), stores
40. Software Architecture
School of Computer Science University of Oviedo
Version control
Definitions
Repository: where changes are
stored
Baseline: Initial version
Delta: changes from one version
to other
Trunk (master): Main branch in a
system
Branch: deviation from main
branch
Tag: Marks a line of versions
Baseline
1
4
Trunk
2
3
Branchs
5
6
9
7
T1
T2
8
10
Tags merge
41. Software Architecture
School of Computer Science University of Oviedo
Version control
Definitions
Checkout: Working Local copy from a
given branch
Commit: Introduce current changes in
the control version system.
Merge: Combine two sets of changes
Branching styles: by feature, by team,
by version
Baseline
1
4
Trunk
2
3
Branchs
5
6
9
7
T1
T2
8
10
Tags
merge
42. Software Architecture
School of Computer Science University of Oviedo
Version control
2 types
Centralized
Centralized repository for all the code
Centralized administration
CVS, Subversion, ...
Distributed
Each user has its own repository
Git, Mercurial
43. Software Architecture
School of Computer Science University of Oviedo
Git
Designed by Linus Torvalds (Linux), 2005
Goals:
Applications with large number of source code files
Efficiency
Distributed work
Ecach development has its own repository
Local copy of all the changes history
It is posible to do commits even without internet connection
Support for non-lineal development (branching)
44. Software Architecture
School of Computer Science University of Oviedo
Local components
3 local components:
Local working directory
Index (stage area). Also called cache
Project history: Stores versions or commits
HEAD (most recent version)
commit
Project
History
Commits
add
rm
HEAD
Local
working
directory
Index
stage
area
45. Software Architecture
School of Computer Science University of Oviedo
Branches
feature-2 feature-1 develop hotfix-1 master
Git facilitates branch management
master = initial branch
Operations:
Create branches (branch)
Change branch (checkout)
Combine (merge)
Tag branches (tag)
Multiple branching styles
tags
0.1
0.2
1.0
Branches
46. Software Architecture
School of Computer Science University of Oviedo
Remote repositories
Connect with remote repositories
origin = initial
Local
working
directory
History
Commits
Index
stage
area
Remote
repository
origin
push
clone
fetch
pull
commit
add
rm
Local
Machine
HEAD
47. Software Architecture
School of Computer Science University of Oviedo
Git - usual commands
init: inicialize repository
clone: clone a repository
add: add contents to index
commit: record changes
status: check state of repository
pull: get changes from an external repository
push: put changes in an external repository
branch: manage branches (list, create, delete)
merge: combine two branches
checkout: recover a given branch
rm: delete files
mv: move files
.gitignore file indicates which files are not going
to be tacked by version control system
48. Software Architecture
School of Computer Science University of Oviedo
Git typical workflow
Local workstation
Development
Build
Central
repository
Build
pull
push
Build
Done!
49. Software Architecture
School of Computer Science University of Oviedo
Dependency management
Library: Collection of functionalities used by the
system that is being developed
System depends on that library
Library can depend on other libraries
Library can evolve
Incompatible versions appear
Dependency graph
Mozilla Firefox dependency graph
Source: The purely functional deployment model. E. Dolstra (PhdThesis, 2006)
50. Software Architecture
School of Computer Science University of Oviedo
Dependency management
Different models
Local installation: libraries are installed for all the system
Example: Ruby Gems
Embed external libraries in the system (version control)
Ensures a correct version
External link
External repository that contains the libraries
Depends on Internet and on library evolution
51. Software Architecture
School of Computer Science University of Oviedo
Automated building
Tools to automate building and deployment
Organize different tasks
Dependencies between tasks
They have to ensure that:
Execute all prerequisites
Execute them only once Inicialize
Prepare
testing
data
Compile
source
code
Compile
testing
code
Run
testing
52. Software Architecture
School of Computer Science University of Oviedo
Automate building
make: Included in Unix
Product oriented
Declarative 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.
53. Software Architecture
School of Computer Science University of Oviedo
Automate building
ant: Java Platform
Task oriented
XML syntax (build.xml)
54. Software Architecture
School of Computer Science University of Oviedo
Automate building
maven: Java Platform
Convention over configuration
Manage Project lifecycle
Dependency management
XML syntax (pom.xml)
55. Software Architecture
School of Computer Science University of Oviedo
Automate building
Embedded languages
Domain specific languages embedded in higher level ones
Great versatility
Examples:
gradle (Groovy)
sbt (Scala)
rake (Ruby)
Buildr (Ruby)
…
56. Software Architecture
School of Computer Science University of Oviedo
Execution environtments
A staging environment is also used
Development
environment
Testing
Environments
Production
Environment
Testing
Server
Integration
Server
Version
Control
Production
Server
Server farm
57. Software Architecture
School of Computer Science University of Oviedo
Continuous integration
Continuous integration tools
Hudson, Jenkins, Travis, Bamboo
Continuous
Integration
Web
Interface
Reports
checkout/commit
Central Code
repository
Development
Team
58. Software Architecture
School of Computer Science University of Oviedo
Social coding
Public repositories of source code
Different policies
Examples:
Sourceforge
Google projects
Bitbucket
Github
59. Software Architecture
School of Computer Science University of Oviedo
Tools in the cloud
Several tools to help development in the cloud
Examples:
IaaS: Infrastructure
Amazon ECS
PaaS: Platform
Google AppEngine, Heroku
SaaS: Software
GMail, GDocs, etc.
61. Software Architecture
School of Computer Science University of Oviedo
Product lines
Product line: products that share a set of
functionalities to satisfy some given market
segment
Goal:
Reduce development effort
Improve productivity
Evolve from a single product to a product line
62. Software Architecture
School of Computer Science University of Oviedo
Product lines
Requirements
Identify generic solutions to common problems
Component based development
Generic Platforms
Software reuse
Automatic system generation
63. Software Architecture
School of Computer Science University of Oviedo
Distribution channels
Traditional distribution
CDs, DVDs, ...
Web based
Downloads, FTP, ...
Application markets
Linux packages
App stores:
AppStore,
Google Play,
Windows Store