CSC 5361 Notes –
Bass, Chapter 1-2
Software Architecture
Software Architecture
• Preliminary definition:
The software
architecture of a program or computing system is
the structure or structures of the system, which
comprise software elements, the externally visible
properties of those elements, and the relationships
among them.
• What is the relationship of a system's software
architecture to the environment in which the
system will be constructed and will exist?
Architecture Business Cycle
Software architecture is a
result of technical,
business, and social
influences.
(see
sidebar,
p.
4-5,
Vasa)
Architecture Business Cycle
• The existence of the software architecture
affects these aspects of the environment
(structure of business system, enterprise
goals via success, customer requirements
for next system, architect's experience,
maybe even software engineering culture),
which in turn affect architecture.
Architecture Business Cycle
• How do organizational goals influence
requirements and development strategy?
• How do requirements lead to an
architecture?
• How are architectures analyzed?
• How do architectures yield systems that
suggest future new organizational
capabilities and requirements?
Stakeholders
The stakeholders are those interested in the construction
of a software system: customer, end users, developer,
organization, maintainers, etc.
The software
architecture of a system is the earliest artifact that
enables the priorities among competing concerns to be
analyzed, and it is the artifact that manifests the
concerns as system qualities. The system's response
to these qualities is the result of structural trade-offs
made and probably not documented by the original
designers. The relative costs of different concerns, and
the architectural alternatives that support these concerns,
become more concrete when design begins.
Technical and organizational
influences (Figure 1.3, p. 10)
• Stakeholder
• Developing
organization
Requirements
(qualities)
Architect(s)
architecture
• Technical environment
• Architect's experience
system
Software Architects
• Architects must identify and actively
engage the stakeholders to solicit their
needs and expectations. Early engagement
allows the architects to understand the
constraints of the task (their nature, source,
and priority), to manage expectations, and
to negotiate priorities.
Architect activities
•
•
•
•
•
•
•
Creating the business case for a system (cost,
target market, time to market, interface with other
systems…)
Understanding requirements
Creating/selecting architecture (conceptual
integrity; small number of minds)
Documenting/communicating architecture
Analyzing/evaluating architecture
Implementing system based on architecture
Ensuring that the implementation conforms to
the architecture
A good architecture:
process recommendations
• The architecture should be the product of a single
architect or a small group of architects with an identified
leader.
• The architect (team) should have the functional
requirements for the system and an articulated,
prioritized list of qualitative attributes (such as
portability) that the architecture must satisfy.
• The architecture should be well documented, (at least
one static view and one dynamic view) using an agreedon notation that all stakeholders can understand with a
minimum of effort
A good architecture:
process recommendations
• The architecture should be circulated to the
system's stakeholders, who should be actively
involved in its review.
• The architecture should be analyzed for applicable
quantitative measures (eg maximum throughput)
and formally reviewed for qualitative properties
(eg modifiability) before it is too late to make
changes.
A good architecture:
process recommendations
• The architecture should lend itself to incremental
implementation via the creation of a "skeletal"
system in which the communication paths are
exercised but which at first has minimal
functionality. (incremental prototype)
• The architecture should result in a specific (and
small) set of resource contention areas, the
resolution of which are clearly specified,
circulated, and maintained.
(eg, network
utilization: enforce guidelines to minimize
network traffic; performance: enforce time
budgets for major threads.
A good architecture:
structural recommendations
• The architecture should feature well-made
modules whose functional responsibilities are
allocated on the principles of information hiding
and separation of concerns.
Well defined
interfaces, data hiding.
• The modules should reflect a separation of
concerns (well-defined interface) that allows their
respective development teams to work largely
independent of each other.
• Quality attributes should be achieved using wellknown architectural tactics. (Chapter 5)
A good architecture:
structural recommendations
• The architecture should never depend on a
particular version of a commercial product or tool.
Structure for straightforward, inexpensive
retargeting.
• Modules that produce data should be separate
from modules that consume data. Increases
modifiability – changes often confined to
production/consumption sides.
• For parallel-processing systems, the architecture
should feature well-defined processes or tasks that
do not necessarily mirror the module structure.
A good architecture:
structural recommendations
• Processes may thread through more than one
module.
• Every task or process should be written so that its
assignment to a specific processor can be easily
changed, even at runtime.
• The architecture should feature a small number of
simple interaction patterns.
Software Architecture
• Preliminary definition: The software architecture of a
program or computing system is the structure or
structures of the system, which comprise software
elements, the externally visible properties of those
elements, and the relationships among them.
• architecture defines software elements
• systems can and do comprise more than one structure
• every computing system with software has a software
architecture
• the behavior of each element is part of the architecture
• the architecture for a system is a good one or a bad one
• An architectural style/pattern is a description of
element and relation types and a set of
constraints on how they may be used.
• A reference model is a division of functionality
together with data flow between the pieces. e.g.,
parts of a DBMS or a compiler. (standard
decomposition of a known problem)
• A reference architecture is a reference model
mapped onto specific software elements and the
data flows between them.
Three critical benefits of focus on
architecture:
• 1.
Communication among stakeholders.
(see sidebar, p. 27)
• 2.
Early design decisions. (constraints,
organizational structure, quality attributes,
manage change, cost/schedule estimation)
• 3.
Transferable, reusable abstraction of
a system. (less is more: restrict the
alternatives)
Architectural structures
(Figure 2.3, p. 37)
• Module structures (units of implementation):
decomposition, class, uses/layered
• Component and Connector (runtime components):
client-server, concurrency, process, shared data
• Allocation (software elements and external
environments): work assignment, deployment,
implementation
Architectural Structures of a System
(Modules)
Software
Structure
Relations
Useful for
Decomposition
Is a submodule
of; shares secret
with
Resource allocation and project
structuring and planning; information
hiding, encapsulation; configuration
control
Uses
Requires the
correct presence
of
Engineering subsets; engineering
extensions
Layered
Requires the
correct presence
of; uses the
services of;
provides
abstraction to
Incremental development; implementing
systems on top of "virtual machines";
portability
Class
Is an instance of; In OO systems, producing rapid almostshares access
alike implementations from a common
methods of
template
Architectural Structures of a System (C&C)
Software
Structure Relations
Useful for
Client-Server
Communicates
with;
depends on
Distributed operation; separation of
concerns; performance analysis;
load balancing
Process
Runs
concurrently
with;
excludes;
precedes; …
Scheduling analysis; performance
analysis
Concurrency
Runs on the
same logical
thread
Identifying locations where resource
contention exists, where threads
may fork/join/be created/killed
Shared Data
Produces data;
consumes
data
Performance; data integrity;
modifiability
Architectural Structures of a System
(Allocation)
Software
Structure Relations Useful for
Deployment
Implementation
Work assignment
Allocated to;
Performance; availability; security
migrates to
analysis
Stored in (file)
Configuration control; integration; test
activities
Assigned to
Project management; best use of
expertise; management of
commonality
Which views to choose?
• Krutchen’s 4 views:
–
–
–
–
–
Logical (module),
Process (component-and-connector),
Development (allocation),
Physical (deployment)
+ scenarios/use cases to clarify
• (used in Rational Unified Process)
A-7E example (1977-87)
• Goal: techniques of analysis and information
hiding applied to a critical embedded real-time
system.
– Rigid timing requirements
– 32K memory, “esoteric” hardware devices
• Decomposition structure (Hardware-hiding
module, Behavior-hiding module, Software
decision module; Fig 3.4, p. 59),
• Uses structure (how the software interacts;
layering; Table 3.3, p. 61)
• Process structure (timing constraints, p. 64)
• Commercial failure, research success