Chapter 7

Model-Based software
Architectures
Notes taken from Walker Royce’s
textbook on Software Project
Management
 Introductory Comments
• Software Architecture – essential to building
software systems, as is ALL architecture.
– When we speak about Architecture (not software)
• can apply stable laws of physics and mathematics.
– Software Architecture
• not governed by complete laws of math;
• no irrefutable first principles.
• At best, many heuristics and vague guidelines
• Goodness measurable only in certain situations
 Introductory Comments
• So, what do practitioners do??
• With no established theory, software architects
must rely on experiences and trial and error in
formulating software architectures.
• We recognize that the transition to an iterative
process, where the early stages emphasize and
promote architecture through evolution through
prototyping and demonstration has proven to be
the way to proceed.
 Introductory Comments
• Years ago, early systems had a very simple architecture.
had informal software architectures.
– Block diagrams; Hierarchy charts; Structure charts; IPO charts;
Many tools at the detail level – for program design; not much at
the architectural level…
• Nowadays, with the complexity of modern systems, we
have many models and views to explain the many
viewpoints of many different perspectives of modern
software development.
– Need to show higher level views from different perspectives of
different stakeholders – since there are now soooo many.
 “A ‘model’ is a relatively independent abstraction of a
system. A view is a subset of a model that abstracts a
specific, relevant perspective. “ (p. 110)
 Architecture: A Management
Perspective
• “The most critical technical product of a software
project is its architecture: the infrastructure,
control, and data interfaces that permit software
components to cooperate as a system and software
designers to cooperate efficiently as a team.”
• With the complexity of modern systems, a basis of
communications is essential, and ‘inter-project
communications’ (different groups; different
viewpoints) must be established and precise.
 7.1 Management Perspective
• Three different aspects of an architecture:
• 1. An architecture – that is, the design of a software
system as opposed to a component. (intangible
design concept)
– Includes all engineering necessary to specify the materials
needed (buy, reuse, custom, costs of construction…)
• 2. An architecture baseline – (tangible artifacts) – a
slice of information across engineering artifacts
sufficient to satisfy all stakeholders that the vision
(function and quality) can be achieved with in the
parameters of the business case (cost, profit, time,
people, technology, …)
– Note: an architecture baseline contains more than just an
architecture description (next slide)
 7.1 Management Perspective
• 3. An architecture description – human-
readable representation of the architecture,
which is one of the components of an
architecture baseline.
– Is an organized subset of information extracted
from the design set model(s).
– More detailed; contains additional info in the
models.
– Indicates how the intangible concept is realized
via the tangible artifacts.
• Note that architecture takes on different
meanings in different domains!
• Levels of granularity can vary widely and
depend largely on what is needed by
stakeholders at that ‘level’ and what
concerns they need to resolve.
Importance of Software Architecture
• “Achieving a stable architecture represents
a significant project milestone at which the
critical make/buy decisions should have
been resolved. This life-cycle event
represents a transition from the
engineering stage of a project,
characterized by discovery and resolution
of numerous unknowns, to the production
stage, characterized by management to a
predictable development plan.”
Importance of Software Architecture
• Architecture and process encapsulate many of the important
(high payoff or high risk) communications among individuals,
teams, organizations and stakeholders.
• Poorly conceived architectures (and hence poor inter-process
communications) and a process that is not a mature one (not
well defined, taught, supported by management, and
implemented by development teams, especially with
established histories…) are often reasons for project failure.
• A process that is mature, a good understanding of all the
primary requirements, and the development of an
architecture that is demonstratable are essential
requirements predictable planning – fundamental to
management.
• Architecture development and process definition are the
intellectual steps that map the problem to a solution without
violating the constraints; they require human intervention
and cannot be automated.
7.2 Architecture: A Technical Perspective.
• Although progress has been made, there is still a
lack of agreement on definitions and principles.
• From Kruchten:
• “Software architecture encompasses the structure
of software systems (the selection of elements and
the composition of elements into progressively
larger subsystems), their behavior (collaborations
among elements), and the patterns that guide
these elements, their collaborations, and their
composition.” (underlining and bold is mine).
• An architectural framework is defined in terms of views
that are abstractions of the UML models in the design
set.
– (Think of the 4+1 Architectural View of the RUP)
• The Design Model includes the full breadth and depth of
information.
 An architectural view (again, think of the five in the
4+1 architectural views of RUP) is an abstraction of the
design model;
– That is, a higher-level view of more detailed artifacts/activities…
– it contains only the architecturally significant information.
• Most real-world systems require four views:
– Design, process, component, and deployment.
• RUP added the Use Case View as ‘driving’ all the views and overall
architecture.
– Let’s look at the purposes of these views…
 Models and Views – again
• To keep our terminology straight:
• A ‘model’ is a relatively independent abstraction of a
system. (We can thus develop models – in general
depicting / describing whatever it is we need to describe.)
BUT a VIEW:
• A view is a subset of a model that abstracts a specific,
relevant perspective. “ (p. 110)
• Remember, a view is developed to support a specific
viewpoint or perspective or to support certain needs that
certain groups of stakeholder have.
– As stated, it is a tailored subset of a model – to capture a relevant
perspective.
– We have logical views, component views, deployment views,…
 Views and their Purposes
• Design View (logical view in RUP) describes the architecturally
significant structures and functions of the design model.
• Process View: describes concurrency and control thread
relationships among the design, component, and deployment
views.
• Component View: describes the structure of the
implementation set (Implementation View in RUP)
• Deployment View: describes the structure of the deployment
set.
• Recall: each of these views is developed to support certain
needs of stakeholders.
– Design View (logical view in RUP) is developed to support
analysts, programmers, architects, etc. Component View
(Implementation View in RUP) is developed to support
construction (programming and test) etc.
 The Necessity of Views
• Design view is clearly essential. All systems
need this view.
– Others are needed as necessary…
– Distributed systems need a process view and a
deployment view;
– Large systems that might have custom and
commercial components probably also need a
component view.
 The Design Set
• The design set will include all UML design models
describing the solution space. (Big Cookie!!
• Depending on the complexity of a system itself,
several models or partitions of other models (views)
may need to be developed.
– Use case, design (logical), and process models provide
for visualization of the logical and behavioral aspects of
the system.
– Component view provides visualization of the
implementation set; deployment model provides
visualization of the deployment set.
 The Design Set
• Note that ‘architecture’ is an organized and abstracted view into
design models…..
• An architecture is captured through many views, which are
extracts of design models and capture the significant structures,
collaborations, and behaviors.
• The architectural description, then, of a system is captured
via portions of each model;
– Part of the design model (design view) addresses architecture;
– Part of the process model (process view) addresses architecture (as
needed)
– Part of the component model (implementation view) is part of the
architectural view, etc.
– The views are extracts of design models that capture significant
structures, collaborations, and behaviors.
 Architecture
• The architectural descriptions are always
kept electronically, but also maintained in a
printable version. These engineering and
architectural views are defined as collections
of UML diagrams unlike text and basic
graphics models of years past.

• (Be careful: management may still want

these. Educate them where possible…)
 Architecture – Many Faces
• Descriptions of an architecture is many things to
many people in different application domains.
• And, these take on many different forms.
• Ideally, they can remain electronic, but …
• So, given all this, and recognizing that the
descriptions can vary a great deal, what constitutes
a good architecture baseline?
– That is, what is a good ‘critical mass’ of models / views in
general?
– Remember, we are after content that is architecturally-
significant….
 Heuristics for an Architectural
Baseline
• “Requirements: critical use cases, system-level quality
objectives, and priority relationships among features and
qualities.
• “Design: names, attributes, structures, behaviors,
groupings, and relationships of significant classes and
components.
• “Implementation: source component inventory and bill of
materials (number name, purpose, cost) of all primitive
components
• “Deployment: executable components sufficient to
demonstrate the critical use cases and the risk
associated with achieving the system qualities.” p.114
 Architectural Baseline – Comments
• Project success is often dependent upon a
architectural description in an architectural-
first approach (like RUP).
• Essential to the question of ‘balance.’
– (what is ‘in’ the architecture and what is not)
– Key word: ‘balance.’
• Note that the architectural baseline is a
subset of the architectural description, which
is totally contained in the Design Set.
 The Old and the New
• Conventional systems did not distinguish between the
two (architectural description and architectural baseline)
– No rigorous notations (normally block diagrams and text)
– Little tie in to other engineering artifact sets for validation
• Iterative development – an “architecture baseline is a
partial realization of the architecture description that is
sufficient to provide tangible evidence that the
architecture is valid in the context of the requirements
and plans.”
• This is, thus, thee major ‘deliverable’ of the Elaboration
phase, and hopefully we can readily see why this is so.
 Architectural Baseline
• Degree of detail and forms depends many
factors.
• Very skilled people developing a limited
application may need only UML diagrams
whereas a command-and-control system
that is large scale and highly distributed
will clearly require more details to validate
a solid baseline!
 Concluding Remarks
• Note that the transition from engineering into
production should not take place unless a stable
architecture baseline is established.
• Thus relevant stakeholders must agree that the
original vision (supported by the requirements
and and architecture) and represented in the
design set and partially implemented in the
implementation and deployment sets) can be
achieved with a highly predictable cost and
schedule.
• Verification requires briefings and executable
prototypes that demonstrate the evolving
capabilities.
• These will show the maturity of the process.