Software is very important to computing, and software architecture, as an aspect of software engineering and the design and construction of working computer systems, is a central concern to computer science and information technology. However, there unfortunately is not a single universally accepted definition for what software architecture itself is! Authors have used the term in various related but distinct ways. An important definition among these is that by Booch, Rumbaugh, and Jacobson, the "Three Amigos" of software engineering: "An architecture is the set of significant decisions about the organization of a software system, the selection of the structural elements and their interfaces by which the system is composed, together with their behavior as specified in the collaborations among those elements, the composition of these structural and behavioral elements into progressively larger subsystems, and the architectural style that guides this organization--these elements and their interfaces, their collaborations, and their composition." (The UML Modeling Language User Guide, Addison-Wesley, 1999)
Just as building architectures are best envisioned in terms of a number of styles or building models, so also with software architectures, which are split along a few major styles. Structural perspectives help document and communicate the details of the architecture in terms of the structure of the system--the specific components and their functional inter-relationships. This type of perspective is most useful in assessing structural qualities such as extensibility. Behavioral perspectives are useful in considering component interactions, the effect of component malfunctions, and so on. Execution perspectives help in communicating distribution options, and in documenting the system.
The importance of software architecture is summarized in a well-known quote from Barry Boehm, one of the renowned gurus of software engineering: "If a project has not achieved a system architecture, including its rationale, the project should not proceed to full-scale system development. Specifying the architecture as a deliverable enables its use throughout the development and maintenance process."
In defining a system's architecture, it is necessary for the designers to define the rationale of the proposed system--what it will be and what it will achieve--and to determine who the stakeholders of the system are going to be. The stakeholders of a system are, simply put, any parties who have a stake in the construction and running of the system--these include entities such as the corporate customer, the maintenance subcontractor, the human users (possibly the customer's employees), the programmers who may have to write patches, upgrades, or special local features for the system, the social group or community served by the customer, any political pressure groups or individuals associated with or interested in the proposed system in some way, and so on. Each stakeholder in the system has a specific perspective of the system, and to a certain extent does not care a great deal about other perspectives. The architecture should, at the outset, allow the system to be successful in the eyes of all its stakeholders, or at least to achieve a reasonable degree of compromise that allows for the system to be at least passable from as many perspectives as possible. The software architect may have to give greater weightage to perspectives felt to be more important--for example, a political stakeholder may be regarded more highly than others.
The concept of modularity is widely applied in software architecture—the grand task is broken up into components or modules, each of which is designed separately. The breakup of the total system into components must be done in accordance with accepted principles of modularity such as information hiding. The modular structure of the system prescribes the structure of the system being developed. That structure also determines the allocation of the system development work and hence the organization structure of the project development effort.
Software architecture is a highly iterative process, requiring prototyping, testing, measurement, and analysis. The architecture should be specified in a manner that is unambiguous and clearly specifies the working of the proposed system. The architecture must also be clear to all the stakeholders of the system, to prevent future trouble due to misunderstandings. The software development team must clearly understand the work that is required, and must be able to share tasks specifically among individuals and groups. The management of the software development team must have a clear grasp of the scheduling implications and the like.
The UML (Unified Modeling Language) proposed by the Three Amigos (Booch, Jacobsen, and Rumbaugh) is widely applied as a tool of software architecture.
This is the complete article, containing 730 words
(approx. 2 pages at 300 words per page).
