The architecture of software systems should be well documented and up to date. Knowledge about the software architecture of a software system enables reasoning regarding the software’s qualities such as modifiability, extensibility, security, etc.
- Software architecture is the central design problem of a complex software system in the same way architecture is the software system design.
- The ultimate goal of the engineering stage is to converge on a stable architecture baseline.
- Architecture is not a paper document. It is a collection of information across all the engineering sets.
- Architectures are described by extracting the essential information from the design models.
- A model is a relatively independent abstraction of a system.
- A view is a subset of a model that abstracts a specific, relevant perspective.
A management perspective
- The most critical and technical production of a software project is its architecture
- If a software development team is to be successful, the inter-project communications, as captured in software architecture, must be accurate and precise.
From the management point of view, three different aspects of architecture
- An architecture ( the intangible design concept) is the design of software system it includes all engineering necessary to specify a complete bill of materials. Significant make or buy decisions are resolved, and all custom components are elaborated so that individual component costs and construction/assembly costs can be determined with confidence.
- An architecture baseline (the tangible artifacts) is a slice of information across the engineering artifact sets sufficient to satisfy all stakeholders that the vision (function and quality) can be achieved within the parameters of the business case (cost, profit, time, technology, people).
- An architectural description is an organized subset of information extracted from the design set model’s. It explains how the intangible concept is realized in the tangible artifacts.
The number of views and level of detail in each view can vary widely. For example the architecture of the software architecture of a small development tool.
There is a close relationship between software architecture and the modern software development process because of the following reasons:
- A stable software architecture is nothing but a project milestone where critical make/buy decisions should have been resolved. The life-cycle represents a transition from the engineering stage of a project to the production stage.
- Architecture representation provides a basis for balancing the trade-offs between the problem space (requirements and constraints) and the solution space (the operational product).
- The architecture and process encapsulate many of the important communications among individuals, teams, organizations, and stakeholders.
- Poor architecture and immature process are often given as reasons for project failure.
- In order to proper planning, a mature process, understanding the primary requirements and demonstrable architecture are important fundamentals.
- Architecture development and process definition are the intellectual steps that map the problem to a solution without violating the constraints; they require human innovation and cannot be automated.
A technical perspective
- Software architecture includes the structure of software systems, their behavior, and the patterns that guide these elements, their collaborations, and their composition.
- An architecture framework is defined in terms of views is the abstraction of the UML models in the design set. Whereas an architecture view is an abstraction of the design model, include full breadth and depth of information.
Most real-world systems require four types of views:
1) Design: describes architecturally significant structures and functions of the design model.
2) Process: describes concurrency and control thread relationships among the design, component, and deployment views.
3) Component: describes the structure of the implementation set.
4) Deployment: describes the structure of the deployment set.
- The design view is probably necessary for every system; the other three views can be added to deal with the complexity of the system at hand.
- The requirements set may include UML models describing the problem space.
- The design set includes all UML design models describing the solution space.
- The design, process, and use case models provide for visualization of the logical and behavioral aspect of the design.
- The component model provides for visualization of the implementation set.
- The deployment model provides for visualization of the deployment set.
- The use case view describes how the system’s critical use cases are realized by elements of the design model. It is modeled statistically by using use case diagrams, and dynamically by using any of the UML behavioral diagrams.
- The design view describes the architecturally significant elements of the design model. It is modeled statistically by using class and object diagrams and dynamically using any of the UML behavioral diagrams.
- The process view addresses the run-time collaboration issues involved in executing the architecture on a distributed deployment model, including logical software topology, inter-process communication, and state mgmt. it is modeled statistically using deployment diagrams, and dynamically using any of the UML behavioral diagrams.
- The component view describes the architecturally significant elements of the implementation set. It is modeled statistically using component diagrams, and dynamically using any of the UML behavioral diagrams.
The deployment view addresses the executable realization of the system, including the allocation of logical processes in the distributed view to physical resources of the deployment network. It is modeled statistically using deployment diagrams, and dynamically using any of UML behavioral diagrams.