This article is part of a summary for the very excellent book “Software Architecture in Practice Book Third Edition ” , the article summarize the chapter one ,and i will summarize each chapter and publish one by one.
What is software architecture?
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.
System Structures Categories:
- Modules Structures partition systems into implementation units (e.g. Database Module “or modules in huge projects” , user interface module , etc..)
- Components and Connectors Structures focus on the way the elements interact with each other at runtime to carry out the system’s function , component is always a run time entity.
- Allocation Structures describes the mapping from software structures to the system’s organizational , development , installation , and execution environments(e.g. 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)
A structure is architectural if it supports reasoning about the system and the system’s properties.
Elements interact with each other by means of
interfaces that partition details about an element into public and private parts . Architecture is concerned with the public side of this division. Private details of the element having to do solely with internal implementation.
Every software system has software architecture: in most trivial case, a system is itself a single element –an uninteresting and probably non-useful architecture, but an architecture nevertheless.
Architecture includes behavior: the behavior of each element is part of the architecture insofar as that behavior can be used to reason about the system. This behavior embodies how elements interact with each other. This is clearly part of our definition of architecture.
Not all architectures are good architecture: an architecture may permit or preclude a system’s achievement of its behavioral, quality attribute, and life-cycle requirements.
is a representation of the software architecture, as it is mapped to hardware and networking components, a mapping of the software architecture onto the hardware architecture, and a concern for the human interaction with these components. This is , system architecture is concerned with a total system, including hardware , software ,and humans.
is concerned with how an enterprise’s software systems support the business processes and goals of the enterprise. Typically included in this set of concerns is a process for deciding which systems with which functionality should be supported by an enterprise. Software in only one concern of enterprise architecture. Two other common concerns addressed by enterprise architecture are how the software is used by humans to perform business processes, and the standards that determine the computational .
Structure and Views:
- A view is a representation of a coherent set of architectural elements , as written by and read by system stakeholders. It consists of a representation of a set of elements and the relations among them.
- A structure is the set of elements itself , as they exist in software or hardware.
Questions that module structure answer:
- What is the primary functional responsibility assigned to each module?
- What other software elements is a module allowed to us?
- What other software does it actually use and depend on?
- What modules are related to other modules by generalization or specializing (i.e. inheritance) relationships?
Questions that component and connector structure answer:
- What are the major executing components and how do they interact at runtime?
- What are the major shared data stores?
- Which parts of the system are replicated?
- How does data progress through the system?
- What parts of the system can run in parallel?
- Can the system’s structure changes as it executes and, if so, how?
Questions that allocation structure answer:
- What processor does each software element execute on?
- In what directories or files is each element stored during development, testing, and system buildings?
- What is the assignment of each software element to development teams?
Fewer is better: in general ,design and document a structure only if doing so brings a positive return on the investment, usually in terms of decreased development or maintenance costs.
Which structure to choose: you should think about how the various structures available to you provide insight and leverage into the system’s most important quality attributes, and then choose the ones that will play the best role in delivering those attributes.
Architectural patterns: provide packaged strategies for solving some of the problems facing a system, a common module type pattern is this:
- Layered pattern: a layer is a coherent set of related functionality.
- Shared data (for repository) pattern: this pattern comprises components and connectors that create, store, and access persistent data, the repository usually takes the form of a (commercial) database. The connectors are protocols for managing the data. Such as SQL.
- Client Server pattern: the components are the client and the server.
- Multi-tier pattern: which describes how to distribute and allocate the components of a system in distinct subset.
- Competence center and platform: which are patterns that specialize a software system’s work assignment structure in competence center, work is allocated to sites depending on the technical or domain expertise located at a site.
Follow articles under “Software Architecture” category at this blog later for the next chapter.
The book link on Amazon: http://www.amazon.com/Software-Architecture-Practice-Edition-Engineering/dp/0321815734/ref=sr_1_1?ie=UTF8&qid=1360939916&sr=8-1&keywords=software+architecture+in+practice+3rd+edition