IT533 - SOFTWARE ARCHITECTURES - CLASS 1
See text pages 2 thru 4
As the text and some of the assigned readings indicate, there are
a number of attempts to define what is meant by a software architecture.
Given that our interest is in architectures for
enterprise applications, the following
definition from Bass, Clements, and Kazman
may be the most appropriate:
The software architecture of a program or computing system is
the structure or structures of the system, which comprise software
components, the externally visible properties of those components,
and the relationships among them.
"Externally visible" properties refers to those assumptions other
components can make of a component, such as provided services,
performance characteristics, fault handling, shared resource usage,
and so on.
Their definition is followed by a discussion of its implications:
Although our focus is on software architectures, it is almost
impossible to completely automate an enterprise application
One of the early architecture decisions will be to determine
which events should be processed using manual processors (humans)
and which events should be processed using automated processors.
- Architecture defines components
Architecture is an abstraction of the system.
It describes how components interact with each other.
The architecture concentrates on the interfaces between components.
It supresses details that do not affect how a component uses,
is used by, relates to, or interacts with another component.
This means that the private details having to do solely with
internal implementation are not architectural.
Those details are engineering details.
- Systems can comprise more than one structure
- Every software system has an architecture
This is true because every system can be shown to be composed of
components and relations among them.
Although trivial, a system with only one component has an architecture
that satisfies the definition.
- The behavior of each component is part of the architecture
The architecture is concerned with the behaviour that can be
observed or discerned from the point of view of another
Because a graphical model does not fully describe the interfaces and
functionality of the interacting components, graphical models
are not, in themselves, the architecture.
See text pages 10 thru 11
There are three main reasons why architecture is important
- Communication Among Stakeholders
- Represents Early Design Decisions
- Define Constraints on Implementation
- Dictates Organizational Structure
- Inhibits or Enables a System's Quality Attributes
- Permits Prediction of System Qualities
- Makes it Easier to Reason About and Manage Change
- Helps in Evolutionary Prototyping
- Transferable Abstraction of a System
- Product Lines Share a Common Architecture
- Permits Use of Large, Externally Developed Components
- Restricts Vocabulary of Design Alternatives
- Permits Template-Based Component Development
- Basis for Training
See text pages 10 thru 11
Prepared by David L. March -- Last Revised on March 27, 2003
COPYRIGHT © 2003 BY DAVID L. MARCH