Software Architecture
The Architecture Business Cycle
Taken from Chapter 1 of
Len Bass, Paul Clements, and Rick Kazman,
Software Architecture in Practice, 2nd Edition,
Addison Wesley, 2003.
The Role of Architecture
Traditionally,
Requirements beget design, which begets system.
Software Architecture,
encompasses the structures of large software systems.
Preliminary Def.
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 as a Tool
An important tool for:
Communication Reasoning Analysis Growth And, ... Publication!
Influences on the Architecture
Stakeholders
Low Cost Keeping people employed Leveraging existing corporate assets Performance Security Reliability End User
Development Management
Modifiability Neat Features Short time-to-market
Marketing
NAAAH! Low cost Parity with competing products Architect Customer
Not changed very often
Maintenance
Developing Organization
Structure and Nature Staff Skills Schedule and Budget Three Categories:
Immediate Business Long-term Business Organizational Structure
Architect's Experience
Education and training Exposure to successful architectural patterns Exposure to systems that have worked particularly Wish to experiment
Technical Environment
The environment that is current when an architecture is designed will influence that architecture.
It is a brave architect who, in today's environment, does not at least consider a Webbased, object-oriented, middleware-supported design for an information system.
Requirements
Identify and actively engage the stakeholders
Architecture reviews Iterative prototyping
More than just technical skills
Diplomacy Negotiation Communication
Feedbacks
Effects on Dev. Org.
Teams are formed for individual software units Schedules and budgets allocate resources in chunks corresponding to the units Families of similar systems Establish a foothold in a particular market area
Other Effects
The customer may be willing to relax some requirements to gain economy Architect's experience with subsequent systems Change the software engineering culture
Activities Around Architecture
Creating the business case for the system Understanding the requirements Creating or selecting the architecture Documenting and communicating the architecture Analyzing or evaluating the architecture Implementing the system based on the architecture Ensuring that the implementation conforms to the architecture
What Makes a Good Architecture?
There is no absolute good or bad! Architectures are either more or less fit for some stated purpose. Architectures can in fact be evaluated but only in the context of specific goals
Process Recommendations
Single architect (or a small group) Should have
Functional requirements Prioritized list of quality attributes
Well documented Circulation to the system's stakeholders
Process Recommendations
Analysis for applicable quantitative measures Creation of a skeletal system Specific (and small) set of resource contention areas
Structural Guidelines
Information-hiding modules Well-defined interfaces Quality attributes Independent of a particular version of a commercial product or tool Modules that produce data should be separate from modules that consume data.
Structural Guidelines
A small number of simple interaction patterns For parallel processing systems:
Well-defined processes or tasks Assignment to specific processors should be changed