@Taylor2008 analyze architecture by dividing it into the following parts.
- Goals
- Scope
- Concerns (Structural, Behavioral, Interaction, Non-Func-tional)
- Models (Informal, Semi-formal, Formal)
- Type (Static, Dynamic, Scenario-based)
- Automation Level (Manual, Partially Automated, Automated)
- Stakeholders
Success of any project is measured using goals and finding ways to determine how and to what extent they have been met. @Taylor2008 posit the following goals as the four Cs.
- Completeness
- Consistency (elements do not contradict each other)
- Compatibility
- Correctness
How may each of these be measured? What do they mean?
Wikipedia offers a good survey on scope definitions, roughly including (among others)
- whatever is important
- whatever is hard to change
- whatever decisions are made and their rationale
- whatever is fundamental to understanding the software\linebreak structure in its environment
Non-functional concerns include efficiency, complexity, scalability, adaptability, and dependability.
Interaction concerns include interconnection within the system, communication with external elements, coordination of elements, and mediation of conflicts.
Behavioral concerns are functionality or processing concerns. This can include the flow of control as well as the flow of data.
Structural concerns occur at a possibly more abstract level, incorporating the other concerns. Structural concerns may include inheritance, part-whole relationships, and adherence to paradigms or design patterns.
The easiest and first way to analyze architecture is to think about the stakeholders in architecture. These may include the following groups.
- Architects, most concerned with correctness
- Developers, most concerned with correctness
- Managers, most concerned with completeness
- Customers, most concerned with correctness
- Vendors, most concerned with compatibility
The figure shows the utility tree from ATAM, the Architecture Tradeoff Analysis Method, developed by the Software Engineering Institute at Carnegie Mellon for the United States Department of Defense. The items in blue (X,Y) are added after the tree is developed according to a complex, heavily documented process. They stand for different things in scenarios but in this one they are X: business priority, importance to the business outcome, and Y: technical priority, the technical difficulty or risk involved in doing them.
\begin{center} \includegraphics[width=10cm]{fiUtilityTree.png} \end{center}
@Amirat2014 distinguish four paradigms in software architecture: object-oriented, component-based, agent-oriented, and service-oriented. Elements of these four paradigms are typically combined in hybrid approaches in the field rather than as pure expressions of the four paradigms. The following paragraphs summarize their descriptions.
The object-oriented paradigm established the principles of object encapsulation, inheritance, messages, typing, and polymorphism. The object-oriented paradigm was the first software engineering paradigm with widespread acceptance. It forms a reference model for all later paradigms.
The component-based paradigm arose as a response to the lack of reuse in object-oriented practice. This approach stresses the use of simple components connected together in pipelines to perform large tasks. The independently developed, well-under-stood simple components are exposed and their reliability is enhanced by their ubiquity.
The agent-oriented paradigm is distinguished by software components able to cooperate, coordinate, and negotiate with each other. Autonomy and high-level interactions mark this paradigm as distinct from the others. An agent encapsulates code, state, and invocation initiative. An agent obeys explicitly defined rules in the service of explicitly defined goals.
The service-oriented paradigm emerges from the need to withstand volatile, heterogeneous environments. This paradigm emphasizes productivity and responsiveness of a service supplier by exposing APIs to services, with exactly one instance of a service available. A service has the following characteristics. A service is coarse-grained in comparison with component-based software, operating on more varied data and encapsulating conglomerated (possibly dissimilar) functions. A service has the flexibility to offer different interfaces and to offer interfaces in common with other services. A service is described by an API enabling a customer to understand what it does and how and at what price and with what non-functional properties. A service is discoverable. A service is a single instance, corresponding to the singleton design pattern.