CHAPTER 5

ARCHITECTURE IN THE
LIFE CYCLE
 Contents
2

 Architecture in the agile projects

 Architecture and requirements

 Designing and documentation

 Implementation and testing

 Architecture reconstruction and conformance

ARCHITECTURES IN AGILE
PROJECTS
 Agile Manifesto
4

 The Agile Manifesto (created in 2001 by SW developers) is a foundational document that

outlines the values and principles of the Agile software development
approach.
 The manifesto consists of four core values and twelve principles.
 Twelve Agile Principles
5

1. Early and continuous delivery of valuable software.

2. Embrace change
 Welcome changing requirements, even late in development. Agile
processes harness change for the customer’s competitive advantage.
3. Frequent delivery
 Deliver working software frequently, from a couple of weeks to a couple
of months, with a preference to the shorter timescale.
4. Cooperation
 Business people and developers must work together daily throughout the
project.
5. Autonomy and motivation
 Build projects around motivated individuals. Give them the environment
and support they need, and trust them to get the job done.
 …Cont’d
6
6. Better communication
 The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Stable work environments
 Agile processes promote sustainable development. The sponsors, developers, and users
should be able to maintain a constant pace indefinitely.
9. Quality assurance
 Continuous attention to technical excellence and good design enhances agility.
10. Simplicity:- the art of maximizing the amount of work not done is essential via reuse,
automation,…
11. The best architectures, requirements, and designs emerge from self-organizing teams.
5
12. Reflection and adjustment
 At regular intervals, the team reflects on how to become more effective, then tunes and
adjusts its behavior accordingly.
 How Much Architecting is Enough?
7

 According to Boehm and Turner, there are two activities that can add time to the project schedule:
 Up-front design work on the architecture and up-front risk identification, planning, and
resolution work
 Rework due to fixing defects and addressing modification requests.
 Intuitively, these two trade off against each other.
 The more we invest in planning, the less rework is needed.
 Boehm and Turner plotted these two values against each other for three
hypothetical projects:
 One project of 10 KSLOC (which is a measure of the size or complexity of a software project.):-
relativelysmall.,Itcouldbeasimpleapplication orasmallmodulewithinalargersystem.
 One project of 100 KSLOC:- (complex software systems, such as a medium-sized web application,
adatabasemanagementsystem,orasubstantialcomponentwithinalargersoftwareproduct.)
 One project of 1,000 KSLOC:- (large-scale software system. It could include enterprise-level
applications,operatingsystems,extensivesoftwareframeworks,orcomplexsoftwareproducts.)
 … Cont’d
8
 … Cont’d
9

 These lines show that there is a sweet spot for each project.
 The bigger the software project, the greater the need for investing
resources on upfront architecture and design.
 A project with 10,000 KSLOC(~ 10 million) lines of code should
invest 40% of the development time in architecture.
 For smaller projects (10 KSLOC) you gain little from upfront design.
The diagram suggest 5% of the effort on upfront design
 Upfront design can reduce the rework.
 Agility and Documentation
10

 Write for the reader!

 Understanding who will read the documentation and how they will use it.
 If the reader doesn’t need it, don’t write it (YAGNI principle).
 Help developers to avoid adding functionality or implementing features
until they are actually necessary.
 But remember that the reader may be a maintainer or other
newcomer not yet on the project!
 YAGNI means "you ain't gonna need it”.
 You should only implement or document something when you actually
have the need for it.
 Do not spend time attempting to anticipate all possible needs.
 Agility and Architecture Evaluation
11

 Architecture evaluation work as part of an Agile process.

 Meetingstakeholders’ important concerns is a cornerstone of Agile
philosophy.
 Our approach to architecture evaluation is exemplified by the
Architecture Tradeoff Analysis Method (ATAM).
 ATAMdoes not endeavor to analyze all, or even most, of an architecture.
 The focus is determined by a set of quality attribute scenarios that represent the
“most important” of the concerns of the stakeholders.
 "Most important" is judged by the amount of value the scenario brings to the
architecture's stakeholders, or the amount of risk present in achieving the
scenario.
 Guidelines for the Agile Architect
12

 Barry Boehm and colleagues have developed the Incremental Commitment Model
to blend agility and architecture.
 This model is based upon the following principles:
 Commitment and accountability of success-critical stakeholders.
 Stakeholder “satisficing” (meeting an acceptability threshold) based on success-based
negotiations and tradeoffs.
 Incremental and evolutionary growth of system definition and stakeholder commitment
 Iterative system development and definition
 Interleaved system definition and development allowing early fielding of core capabilities,
continual adaptation to change, and timely growth of complex systems without waiting for
every requirement and subsystem to be defined
 Risk management:- risk-driven anchor point milestones, which are key to synchronizing and
stabilizing all of this concurrent activity.
 An Advice
13

 If you are building a large, complex system with relatively stable and well-
understood requirements and/or distributed development, doing a large
amount of architecture work up front will pay off.
 On larger projects with unstable requirements, start by quickly designing a candidate
architecture even if it leaves out many details.
 Be prepared to change and elaborate this architecture as circumstances dictate, as
you perform your spikes and experiments, and as functional and quality
attribute requirements emerge and solidify.
 On smaller projects with uncertain requirements, at least try to get agreement
on the major patterns to be employed. Don’t spend too much time on
architecture design, documentation, or analysis up front.
ARCHITECTURE AND
REQUIREMENTS
 Requirements
15

 Architectures exist to build systems that satisfy requirements.

 But, to an architect, not all requirements are created equal.
 An architecturally significant requirement (ASR) is a requirement that will have a
profound effect on the architecture.
 It refers to a requirement that drives the design and decision-making
process related to the system's structure, components, interfaces, or
behavior.
 How do we find those?
16
ASRs and Requirements Documents
 An obvious location to look for candidate ASRs is in the requirements
documents or in user stories.
 Requirements should be in requirements documents!
 Unfortunately, this is not usually the case.
 Why?
 Don’t Get Your Hopes Up
17

 Many projects don’t create or maintain the detailed, high-quality

requirements documents.
 Standard requirements pay more attention to functionality than quality attributes.
 Mostof what is in a requirements specification does not affect the
architecture.
 No architect just sits and waits until the requirements are “finished”
before starting work.
 The architect must begin while the requirements are still in flux.
 Systematic means to identifying the ASRs:-
1. Gathering ASRs from requirements documents
2. Gathering ASRs by interviewing stakeholders
3. Gathering ASRs by understanding the business goals
4. Capturing ASR in a utility tree
 Sniffing Out ASRs from Requirements
18
Documents
Early design decisions and requirements that can affect them.
 If a requirement affects the making of a critical architectural design decision,
it is by definition an ASR.
 Gathering ASRs from Stakeholders
19

 Interviewing the relevant stakeholders is the surest way to learn what they know
and need.
 The results of stakeholder interviews should include:
 a list of architectural drivers
 The combination of functional, quality attribute, and business
requirementsthat shape the architecture or the element under
consideration.
 a set of quality attribute scenarios that the stakeholders as a group
prioritized.
 Quality Attribute Workshop (QAW)
20

 The QAW is a facilitated, stakeholder-focused method to generate, prioritize,

and refine quality attribute scenarios before the software architecture is completed.
 The QAW is focused on system-level concerns and specifically the role that
software will play in the system.
21
QAW Steps
 Step 1: QAW Presentation and Introductions.
 QAW facilitators describe the motivation for the QAW and explain each step of the method.
 Step 2: Business/Mission Presentation.
 The stakeholder representing the business concerns behind the system presents the system’s
business context, broad functional requirements, constraints, and known quality attribute
requirements.
 The quality attributes that will be refined in later steps will be derived largely from the
business/mission needs presented in this step.
 Step 3:Architectural Plan Presentation.
 The architect will present the system architectural plans as they stand.
 This lets stakeholders know the current architectural thinking, to the extent that it exists.
 Step 4: Identification of Architectural Drivers.
 The facilitators will share their list of key architectural drivers that they assembled during Steps 2 and 3, and ask
the stakeholders for clarifications, additions, deletions, and corrections.
 The idea is to reach aconsensus on adistilled list of architectural drivers that includes overall requirements, business
drivers, constraints, and quality attributes.
 … Cont’d
22
 Step 5: Scenario Brainstorming.
 Each stakeholder expresses a scenario representing his or her concerns with respect to the system.
 Facilitators ensure that each scenario has an explicit stimulus and response.
 The facilitators ensure that at least one representative scenario exists for each architectural
driver listed in Step 4.
 Step 6: Scenario Consolidation.
 Similar scenarios are consolidated where reasonable.
 Consolidation helps to prevent votes from being spread across several scenarios that are
expressing the same concern.
 Step 7: Scenario Prioritization.
 Prioritization of the scenarios is accomplished by allocating each stakeholder a number
of votes equal to 30 percent of the total number of scenarios
 Step 8: Scenario Refinement.
 The top scenarios are refined and elaborated.
 Facilitators help the stakeholders put the scenarios in the six-part scenario form of
source-stimulus-artifact- environment-response-response measure.
 ASRs from Business Goals
23

 Relate requirements to business goals in a systematic way.

 … Cont’d
24

24
 Business goals  Quality attribute
 Easy to maintain system requirements
 Fast responding system  Maintainability
 Reduce costs  performance
 Architecture drivers  Non-architectural solutions
 Security  Reducing employee’s pension
 Database-driven
 Expressing Business Goals
25

 Business goal scenario, 7 parts

 Goal-source
 The people or written artifacts providing the goal.
 Goal-subject
 The stakeholders who own the goal and wish it to be true.
 Each stakeholder might be an individual or the organization itself
 Goal-object
 The entities to which the goal applies.
 Environment
 The context for this goal
 Environment may be social, legal, competitive, customer, and technological
 …Cont’d
26

 Goal
 Any business goal articulated by the goal-source.
 Goal-measure
 A testable measurement to determine how one would know if the goal has been
achieved. The goal-measure should usually include a time component, stating the
time by which the goal should be achieved.
 Pedigreeand value
 The degree of confidence the person who stated the goal has in it.
 The goal’s volatility and value.
26
 PALM:A Method for Eliciting Business
27
Goals
 PALM(PedidreedAttribute eLicitation Method) is a seven-step method.
 Nominally carried out over a day and a half in a workshop.
 Attended by architect(s) and stakeholders who can speak to the relevant business
goals.
 PALM Steps
28

 PALMoverviewpresentation
 Overview of PALM, the problem it solves, its steps, and its expected outcomes.
 Business drivers presentation.
 Briefing of business drivers by project management.
 What are the goals of the customer organization for this system?
 What are the goals of the development organization?
 Architecture drivers presentation
 Briefing by the architect on the driving business and quality attribute requirements: the ASRs.
 Business goals elicitation
 Business goals are elaborated and expressed as scenarios.
 Consolidate almost-alike business goals to eliminate duplication.
 Participants prioritize the resulting set to identify the most important goals.
 …Cont’d
29

 Identification of potential quality attributes from business goals.

 For each important business goal scenario, participants describe a quality attribute that
(if architected into the system) would help achieve it. If the QA is not already a
requirement, this is recorded as a finding.
 Assignment of pedigree to existing quality attribute drivers.
 For each architectural driver identify which business goals it is there to support.
 If none, that’s recorded as a finding.
 Otherwise, we establish its pedigree byasking for the source of the quantitative part.
 Exercise conclusion
 Review of results, next steps, and participant feedback.
 Capturing ASRs in a Utility Tree
30

 AnASR must have the following characteristics:

 Aprofound impact onthe architecture
 Including this requirement will very likely result in a different
architecture than if it were not included.
 Ahigh businessormissionvalue
 If the architecture is going to satisfy this requirement it must be of high
value to important stakeholders.
 Utility Tree
31

 Away to record ASRs all in one place.

 Establishes priority of eachASR in terms of
 Impact on architecture
 Business or mission value
 ASRs are captured as scenarios.
 Root of tree is placeholder node called “Utility”.
 Second level of tree contains broad QA categories.
 Third level of tree refines those categories.
 Utility Tree Example
32

Utility

Key:
H=high
M=medium
L=low
DESIGNING AN ARCHITECTURE
 Design Strategy
34

 Decomposition
 Architecture determines quality attributes
 Important quality attributes are characteristics of the whole system.
 Design therefore begins with the whole system
 The whole system is decomposed into parts
 Each part may inherit all or part of the quality attribute requirements from the whole
 Designing to Architecturally Significant Requirements
 Generate andTest

Generate Test Generate

Initial hypothesis Next
Hypothesis Hypothesis
 The Attribute-Driven Design Method
35

 An iterative method. At each iteration you:

 Choose a part of the system to design.
 Organize all the architecturally significant requirements for that part.
 Generate and test a design for that part.
 The Steps of ADD
36

Whole System

1. Choose an element of the system to design.

Element 1 Element N
2. Identify the ASRs for the chosen element.
 For whole system- use a utility tree
 For the element down the decomposition tree- generate a utility tree from
the requirements for that element.
3. Generate a design solution for the chosen element.
 Apply generate and test to the chosen element with its ASRs
4. Inventory remaining requirements and select the input for the next iteration.
5. Repeat steps 1–4 until all the ASRs have been satisfied.
DOCUMENTING SOFTWARE
ARCHITECTURES
 Building the Documentation Package
38

 A view is a representation of an entire system from the perspective of a related

set of concerns.
 It is used to describe the system from the viewpoint of different stakeholders
such asend-users, developers, project managers, and testers.
 Views let us divide a software architecture into a number of interesting and
manageable representations of the system.
 Principle of architecture documentation:
 Documenting an architecture is a matter of documenting the relevant views
and then adding documentation that applies to morethan one view.
 Documentation package consists of:-
 Views
 Documentation beyond views
 Documenting a View
39

 Section 1:The Primary Presentation.

 The primary presentation shows the elements and relations of the view.
 Occasionally the primary presentation will be textual, such as a table or a
list.
 If the primary presentation is graphical, make sure to include a key that
explains the notation.
 Section 2:The Element Catalog.
 The element catalog details at least those elements depicted in the
primary presentation.
 … Cont’d
40

 Section 3: Context Diagram.

 A context diagram shows how the system or portion of the system
depicted in this view relates to its environment.
 Depicts the scope of a view.
 Section 4:Variability Guide.
 A variability guide shows how to exercise any variation points that are a part of
the architecture shown in this view.
 Section 5: Rationale.
 Rationale explains why the design reflected in the view came to be.
 Explains why the design is as it is.
 Documenting Information Beyond Views
41

 Section 1: Documentation Roadmap. The documentation map tells the

reader what information is in the documentation and where to find it.
 Section 2: How aView Is Documented.
 Section 3: System Overview.
 Short prose description of the system’s function, its users, and any important background
or constraints.
 Section 4: Mapping Between Views.
⚫Examples
Ω “is implemented by” for mapping from a component-and-connector view to a
module view
Ω “implements” for mapping from a module view to a component-and-connector view
Ω “included in” for mapping from a decomposition view to a layered view
 … Cont’d
42

 Section 5: Rationale.
 Documents the architectural decisions that apply to more than one view.
 Section 6: Directory
 Set of reference material that helps readers find more information quickly.
 Index of terms
 Glossary
 Acronym list.
 ARCHITECTURE,
IMPLEMENTATION, AND
TESTING
 Architecture and Implementation
44

 Four techniques to help keep the code and the architecture consistent:
 Embedding the design in the code
Ω Architecture acts as a blueprint for implementation
 Frameworks
Ω a reusable set of classes organized around a particular theme used as a
support or guide for the building of something.
 Code templates
Ω A code template is collection of prewritten snippets of code
provided by an IDE within which the programmer provides
application specific portions.
 Keeping code and architecture consistent (i.e. avoiding “architecture
erosion”).
 Architecture and Testing
45

 Architecture defines the units that are to be tested. i.e. unit testing.
 They are components or modules.
 The architect should be involved in a wide variety of test activities.
 Test planning
 Test development.
 Test interpretation.
 Test harness creation.
 ARCHITECTURE
RECONSTRUCTION AND
CONFORMANCE
 Architecture Reconstruction
47

 It refers to the process of analyzing and understanding an existing

software system's architecture, often through reverse engineering
techniques (code analysis, documentation review, dynamic analysis, system
observation …).
 It involves extracting information about the system's:-
 structure,
 components,
 relationships,
 and behavior to create a clear representation of its architectural design.
 The goal is to create a clear representation of the system's architectural
design, which can be useful for documentation, understanding, and
future development.
 Architecture Conformance
48

 Conformance refers to ensuring that the reconstructed architecture

aligns with:-
 specific standards,
 guidelines,
 or requirements.
 It involves comparing the reconstructed architecture with the intended
or desired architecture for the system.
 This evaluation helps to identify any gaps or deviations and allows for
adjustments to be made to bring the system into conformance with
the desired architectural principles.
 Both processes are essential for improving the understanding,
maintenance, and further development of software systems.
 Any Question?
49