• Software systems are constructed to satisfy organizations’ business goals.
  • The architecture is a bridge between those (often abstract) business goals and the final (concrete) resulting system.
  • The topics:
    • Design
    • Analysis
    • Documentation
    • Implementation

    of architectures.

1. 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.

1.1 Architecture Is a Set of Software Structures

  • Module Structures: Some structures partition systems into implementation units.

    • Modules are assigned specific computational responsibilities, and are the basis of work assignments for programming teams.
    • Another kind of module structure emerges as an output of object-oriented analysis and design—class diagrams.
    • Module structures are static structures, in that they focus on the way the system’s functionality is divided up and assigned to implementation teams.

  • Component-and-Connector Structures (C&C): Other structures are dynamic, meaning that they focus on the way the elements interact with each other at runtime to carry out the system’s functions.

  • Allocation Structures: The mapping from software structures to the system’s:
    • Organizational
    • Developmental
    • Installation
    • Execution

    environments. 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.
  • The reasoning should be about an attribute of the system that is important to some stakeholder.

1.2 Architecture Is an Abstraction

  • Architecture is foremost an abstraction of a system that selects certain details and suppresses others.

2. Architectural Structures and Views

2.1 Structures 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.
  • Architects design structures. They document views of those structures.

2.2 Three Kinds of Structures

  1. Module structures embody decisions as to how the system is to be structured as a set of code or data units that have to be constructed or procured. Module structures allow us to answer questions such as these:

    • What is the primary functional responsibility assigned to each module?
    • What other software elements is a module allowed to use?
    • What other software does it actually use and depend on?
    • What modules are related to other modules by generalization or specialization (i.e., inheritance) relationships?

  2. Component-and-connector structures embody decisions as to how the system is to be structured as a set of elements that have runtime behavior (components) and interactions (connectors). Component-and-connector views help us answer questions such as these:

    • 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 change as it executes and, if so, how?

  3. Allocation structures embody decisions as to how the system will relate to nonsoftware structures in its environment. These structures show the relationship between the software elements and elements in one or more external environments in which the software is created and executed. Allocation views help us answer questions such as these:

    • What processor does each software element execute on?
    • In what directories or files is each element stored during development, testing, and system building?
    • What is the assignment of each software element to development teams?


Useful Structures

2.3 Some Useful Module Structures

  • Decomposition structure.
    • The units are modules that are related to each other by the is-a-submodule-of relation, showing how modules are decomposed into smaller modules recursively until the modules are small enough to be easily understood.
  • Uses structure.
    • The units are related by the uses relation, a specialized form of dependency.
    • A unit of software uses another if the correctness of the first requires the presence of a correctly functioning version of the second.

  • Layer structure. The modules in this structure are called layers. A layer is an abstract virtual machine that provides a cohesive set of services through a managed interface.

  • Class (or generalization) structure.
    • The module units in this structure are called classes.
    • The relation is inherits from or is an instance of.
    • This view supports reasoning about collections of similar behaviour or capability and parameterized behavior or capability and parameterized differences.
  • Data model.
    • The data model describes the static information structure in terms of data entities and their relationships.

2.4 Some Useful C&C Structures

  • Service structure.
    • The units here are services that interoperate with each other by service coordination mechanisms.
    • The service structure is an important structure to help engineer a system composed of components that may have been developed anonymously and independently of each other.
  • Concurrency structure.
    • This component-and-connector structure allows the architect to determine opportunities for parallelism and the locations where resource contention may occur.
    • The units are components and the connectors are their communication mechanisms.
    • The components are arranged into logical threads; a logical thread is a sequence of computations that could be allocated to a separate physical thread later in the design process.
    • The concurrency structure is used early in the design process to identify the requirements to manage the issues associated with concurrent execution.

2.5 Some Useful Allocation Structures

  • Deployment structure.
    • The deployment structure shows how software is assigned to hardware processing and communication elements.
    • The elements are software elements (usually a process from a C&C view), hardware entities (processors), and communication pathways.
    • Relations are allocated-to, showing on which physical units the software elements reside
    • migrates-to if the allocation is dynamic.
  • Implementation structure.
    • This structure shows how software elements (usually modules) are mapped to the file structure(s) in the system’s development, integration, or configuration control environments. This is critical for the management of development activities and build processes.
  • Work assignment structure.
    • This structure assigns responsibility for implementing and integrating the modules to the teams who will carry it out.

3. Common Architectural Patterns

3.1 Common Module Type Patterns

  • Layered pattern.
    • When the uses relation among software elements is strictly unidirectional, a system of layers emerges.
    • A layer is a coherent set of related functionality.
    • In a strictly layered structure, a layer can only use the services of the layer immediately below it.
    • Layers are often designed as abstractions (virtual machines) that hide implementation specifics below from the layers above, engendering portability.

3.2 Common Component-and-Connector Type Patterns

  • Shared-data (or repository) pattern.
    • The pattern comprises components and connectors that create, store, and access persistent data.
    • The repository usually takes the form of a (commercial) database.
  • Client-server pattern.
    • The components are the clients and the servers, and the connectors are protocols and messages they share among each other to carry out the system’s work.

3.3 Common Allocation Patterns

  • Multi-tier pattern.
    • Describes how to distribute and allocate the components of a system in distinct subsets of hardware and software, connected by some communication medium.
    • This pattern specializes the generic deployment (software-to-hardware allocation) structure.
  • Competence center and platform.
    • The 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.
    • In platform, one site is tasked with developing reusable core assets of a software product line and other sites develop applications that use the core assets.

4. What Makes a “Good” Architecture?

4.1 Process Recommendations

  1. The architecture should be the product of a single architect or a small group of architects with an identified technical leader.

  2. The architect (or architecture team) should, on an ongoing basis, base the architecture on a prioritized list of well-specified quality attribute requirements.

  3. The architecture should be documented using views. The views should address the concerns of the most important stakeholders in support of the project timeline.

  4. The architecture should be evaluated for its ability to deliver the system’s important quality attributes.

  5. The architecture should lend itself to incremental implementation, to avoid having to integrate everything at once (which almost never works) as well as to discover problems early.

4.2 Structural Recommendations

  1. The architecture should feature well-defined modules whose functional responsibilities are assigned on the principles of information hiding and separation of concerns.

    • The information-hiding modules should encapsulate things likely to change, thus insulating the software from the effects of those changes.
    • Each module should have a well-defined interface that encapsulates or “hides” the changeable aspects from other software that uses its facilities.
    • These interfaces should allow their respective development teams to work largely independently of each other.

  2. Unless your requirements are unprecedented—possible, but unlikely—your quality attributes should be achieved using well-known architectural patterns and tactics specific to each attribute.

  3. The architecture should never depend on a particular version of a commercial product or tool. If it must, it should be structured so that changing to a different version is straightforward and inexpensive.

  4. Modules that produce data should be separate from modules that consume data.

  5. Don’t expect a one-to-one correspondence between modules and components.

  6. Every process should be written so that its assignment to a specific processor can be easily changed, perhaps even at runtime.

  7. The architecture should feature a small number of ways for components to interact. That is, the system should do the same things in the same way throughout.

  8. The architecture should contain a specific (and small) set of resource contention areas, the resolution of which is clearly specified and maintained.


Reference Book: Software Architecture in Practice (3rd Edition)