BISE2013
Software Architecture & Design
CHAPTER 1
Introduction to Software Architecture
CHAPTER OUTLINE
1. What is Software Architecture
2. Architectural Structures and Views
3. Architectural Patterns
4. What Makes a “Good” Architecture?
5. Summary
What is Software Architecture
The software architecture of a computing system is the set of structures needed to reason
about the system, which comprise software elements, relations among them, and properties of
both.
Shaw and Garlan
Software architecture [is a level of design that] involves
the description of elements from which systems are built,
interactions among those elements,
patterns that guide their composition, and
constraints on these patterns.
A structure is a set of elements held together by a relation.
Software systems are composed of many structures, and no single structure holds claim to being
the architecture.
Architectural Structures and Views
There are three important categories of architectural structures.
1. Module
How is the system to be structured as a set of code units (modules)?
2. Component and Connector
How is the system to be structured as a set of elements that have runtime behaviour
(components) and interactions (connectors)?
3. Allocation
How is the system to relate to non software structures in its environment (i.e., CPUs, file
systems, networks, development teams, etc.)?
Module
1. Some structures partition systems into implementation units, which we call
modules.
2. Modules are assigned specific computational responsibilities, and are the
basis of work assignments for programming teams.
3. In large projects, these elements (modules) are subdivided for assignment
to sub-teams.
4. Module structures allow us to answer questions such as:
- What is the primary functional responsibility assigned to each module?
- What modules are related to other modules
Module View Example
Some Useful Module Structures
A. Class (or generalization) structure
1. The module units in this structure are called classes.
2. The relation is inherits from or is an instance of.
3. This view supports reasoning about collections of similar behavior or
capability. e.g : the classes that other classes inherit from and parameterized
differences
4. The class structure allows one to reason about reuse and the incremental
addition of functionality.
5. If any documentation exists for a project that has followed an object-
oriented analysis and design process, it is typically this structure.
B. Data model
The data model describes the static information structure in terms of data
entities and their relationships.
For example, in a banking system, entities will typically include Account,
Customer, and Loan.
Account has several attributes, such as account number, type (savings
or checking), status, and current balance.
C. Component-and-connector Structures
1. Other structures focus on the way the elements interact with each other at runtime to carry
out the system’s functions.
2. We call runtime structures component-and-connector (C&C) structures.
3. In our use, a component is always a runtime entity.
- Suppose the system is to be built as a set of services.
- These services are made up of (compiled from) the programs in the various
implementation units – modules.
4. Component-and-connector structures help answer questions such as:
- What are the major executing components and how do they interact?
- What are the major shared data stores?
- How does data progress through the system?
- What parts of the system can run in parallel?
- How can the system's structure change as it executes?
Component-and-connector View Example
Allocation Structures
1. Allocation structures describe the mapping from software structures to
the system’s environments
Developmental
Installation
Execution
2. For example:
Modules are assigned to teams to develop, and assigned to places in a file structure for
implementation, integration, and testing.
Components are deployed onto hardware in order to execute.
3. They answer questions such as:
What processor does each software element execute on?
In what files is each element stored during development, testing, and system building?
Deployment Diagram
Some Useful Allocation Structures
Deployment structure
The deployment structure shows how software is assigned to hardware
processing and communication elements.
The elements are software elements, hardware entities (processors), and
communication pathways.
This structure can be used to reason about performance, data integrity,
security, and availability.
It is of particular interest in distributed and parallel systems.
Some Useful Allocation Structures
Work assignment structure
This structure assigns responsibility for implementing and integrating the
modules to the teams who will carry it out.
Having a work assignment structure be part of the architecture makes it clear
that the decision about who does the work has architectural as well as
management implications.
The architect will know the expertise required on each team.
This structure will also determine the major communication pathways among
the teams: regular teleconferences, wikis, email lists, and so forth.
What Makes a “Good” Architecture?
There is no such thing as an inherently good or bad architecture.
Architectures are either more or less fit for some purpose
Architectures can be evaluated but only in the context of specific
stated goals.
There are, however, good rules of thumb.
Rules of Thumb
1. Process Recommendations:
include functional requirements and a prioritized list of quality attributes the
system must satisfy
analyze & formally evaluate before it is too late to change
2. Product Recommendations:
well-defined modules using principles of information hiding & separation of
concerns
separate modules that produce data from those that consume data to increase
modifiability & staged upgrades
write tasks or processes to allow easy reallocation, perhaps at runtime
Stakeholders in a System’s Architecture
1. Architects
2. Developers
3. Testers
4. Managers
5. Customers
6. Users
7. Vendors
Figure 1.2 Influence of stakeholders on the architect
Architectural Influences
Stakeholders
each stakeholder has different concerns & goals, some contradictory
Development Organization
immediate business, long-term business, and organizational (staff skills,
schedule, & budget)
Background & Experience of the Architects
repeat good results, avoid duplicating disasters
The Technical Environment
standard industry practices or common SE techniques
Summary
1. The software architecture of a system is the set of structures
needed to reason about the system, which comprise software
elements, relations among them, and properties of both.
2. A structure is a set of elements and the relations among them.
3. A view is a representation of a coherent set of architectural
elements.
4. A view is a representation of one or more structures.
5. There are three categories of structures:
Module structures show how a system is to be structured as a set of code or data
units that have to be constructed or procured.
Component-and-connector structures show how the system is to be structured as a
set of elements that have runtime behavior (components) and interactions
(connectors).
Allocation structures show how the system will relate to nonsoftware structures in its
environment (such as CPUs, file systems, networks, development teams, etc.).
6. Structures represent the primary engineering leverage points of an
architecture.
Every system has a software architecture, but this architecture may be documented
and disseminated, or it may not be.
There is no such thing as an inherently good or bad architecture. Architectures are
either more or less fit for some purpose.
THE END
