Software Architecture

Definitions of 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. ²

Architecture is concerned with the public side of this division; private details of elements details having to do solely with internal implementation are not architectural. ²

Every system can be shown to comprise elements and relations among them to support some type of reasoning ... Even though every system has an architecture, it does not necessarily follow that the architecture is known to anyone. ²

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

Why sofware architecture is important

Sources: ²

1. An architecture will inhibit or enable a system's driving quality attributes
2. The decision made in an architecture allow you to reason about and manage changes as the system evolves
3. The analysis of an architecture enables early prediction of a system's qualities
4. A documented architecture enhances communication among stakeholders
5. The architecture is a carrier of the earliest and hence most fundamental, hardest-to-change design decisions
6. An architecture defines a set of constraints on subsequent implementation
7. The architecture dictates the structure of an organization, or vice versa
8. An architecture can provide the basis for evolutionary prototyping
9. An architecture is the key artifact that allows the architect and project manager to reason about cost and schedule
10. An architecture can be created as a transferable, reusable model that forms the heart of a product line
11. Architecture-based development focuses attention on the assembly of components, rather than simply on their creation.
12. By restricting design alternatives, architecture channels the creativity of developers, reducing design and system complexity
13. An architecture can be the foundation for training new team member.

Related concepts

A system's architecture is a representation of a system in which there is a mapping of functionality onto hardware and software components, a mapping of the software architecture onto the hardware architecture, and a concern for the human interaction with these components. ²

Enterprise architecture is a description of the structure and behavior of an organization's processes, information flow, personnel, and organizational subunits, aligned with the organization's core goals and strategic direction. ²

On Structures in Software Architecture

A structure is architectural if it supports reasoning about the system and the system's properties.

A structure is simply a set of elements held together by a relation ²

• Module structures: partitioning systems into implementation units called modules
  • Modules are implementation units. Each is assigned with a specific computational responsibilities and is the basis of work assignment for programming teams².
  • Module structures are helpful in reasoning about properties such as modifiability
  • Questions that Module Structures can answer:
    • 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 specialisation relationships?
• Component-and-Connector (C&C) structures: capturing how the system is to be structured as a set of elements that have runtime behaviour (compnoents) and interactions (connectors).
  • Components are runtime entities².
  • C&C structures help reasoning about system's runtime properties such as performance, security, availability, etc.
  • Questions that C&C structures can answer:
    • What are the major exeucting 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?
• Allocation structures: capturing how the system will relate to nonsoftware structures in its environment, such as CPUs, file systems, networks, development teams.
  • Questions that allocation structures can answer:
    • 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?

Structure vs View²:

• A view is a representation of a coherent set of architectural elements, as written by and read by system stakeholders
• A structure is the set of elements itself, as they exist in software or hardware.

Architects design structures. They document views of those structures.

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.

Useful types of structures

Module Structures

• Decomposition structure: showing how modules are decomposed into smaller modules recursively.
  • Elements in this structure are modules.
  • Relations are "is-a-submodule-of" relation.
• Uses structure: showing how modules or classes use others.
  • Elements in this structure are modules.
  • Relations are "uses" relation.
  • A module uses other modules if its correctness depends on the presence of a correctly functioning version of the others.
• Layer structure:
  • A layer is an abstract virtual machine that provides a cohesive set of services through a managed interface.
  • Layers are allowed to use other layers in strictly managed fashion.
  • This structure imbue a system with portability - the ability to change the underlying computing infrastructure
• Class (or generalization) structure:
  • Elements in this structure are classes
  • Relations are "inherits-from" or "is-an-instance-of"
• Data Model: capturing the static information structure in terms of data entities and their relationships.
  • Think of this as the entity-relationship models

C&C Structures

Relation in all C&C structures is attachment, showing how the components and connectors are hooked together ²

• Service structure:
  • Components are services that interoperate with each other by service coordination mechanisms such as SOAP
  • Help engineering a system composed of components that may have been developed anonymously and independently from each other.
• Concurrency structure:
  • Components are components
  • Connectors are communication mechanisms that connect components
  • Components are arranged into logical threads, which are sequences of computations that could be allocated to a separated physical thread later in the design process.

Allocation Structures

• Deployment structure: showing how software is assigned to hardware processing and communication elements
  • Elements:
    • Software elements, usually a process from a C&C view
    • Hardware entities (processors)
    • Communication pathways.
  • Relations:
    • "Allocated-to": showing which physical units the software elements reside
    • "migrated-to": if the allocation is dynamic
  • This structure supports reasoning about performance, data integrity, security, and availability
• Implementation structure: showing how software elements (usually modules) are mapped to the file structures in the system's development, integration, or configuration control environment.
  • In practice, screenshot of the development tool, showing the implementation environment is often useful and adequate.
• Work assignment structure

How to do Architecture

Given a design candidate for a software system, software engineers may use qualitative, analytical, or simulation-based tools to evaluate the design for its predicted ability to achieve a non-functional requirement ¹.

An important part of software architecture as a practice is to document the design for a system, including the rationale for why specific design options were chosen¹.

Categories of Design Decisions

There are seven categories of design decisions²:

• Allocation of responsibilities
  • Identifying the important responsibilities, including basic system functions, architectural infrastructure, and satisfaction of quality attributes
  • Determining how these responsibilities are allocated to modules, components, and connectors
• Coordination model
  • Identifying elements of the system that must coordinate, or are prohibited from coordinating
  • Determining the properties of the coordination, such as timeliness, currency, completeness, correctness, and consistency
  • Choosing the communication mechanisms
• Data model
  • Determining how the data items are created, initialized, accessed, persisted, manipulated, translated, and destroyed.
  • Compiling the metadata needed for consistent interpretation of the data
  • Organizing the data, such as determining how and where the data is going to be kept
• Management of resources (CPU, memory, battery, hardware buffers, system clock, I/O ports, system locks, software buffers, thread pools, and non-thread-safe code)
  • Identifying the resources that must be managed and determining the limits for each
  • Determining which system elements manage each resource
  • Determining how resources are shared and the arbitration strategies employed when there is contention
  • Determining the impact of saturation on different resources.
• Mapping among architectural elements
  • Modules to runtime elements
  • Runtime elements to processors
  • Items in the data model to data stores
  • Modules and runtime elements to units of delivery
• Binding time decisions
• Choice of technology
  • Deciding which technologies are available to realize the decisions made in the other categories
  • Determining whether the available tools to support this technology choice
  • Determining the extent of internal familiarity as well as the degree of external support available for the technology
  • Determining the side effects of choosing a technology
  • Determining whether a new technology is compatible with the existing technology stack

Rules of thumbs when designing architecutre

Process recommendations

Sources: ²

1. The architecture should be the product of single architect or a small group of architects with an identified technical leader.
2. The architects 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
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

Structural recommendation

Sources: ²

1. The architecture should feature well-defined modules whose functional responsibilities are assigned on the principles of information hiding and separation of concerns
2. Quality attributes should be achieved using well-known architectural patterns and tactics
3. The architecture should never depend on a particular version of a commercial product or tool
4. Modules that produce data should be separated 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 structure should feature a small number of ways for components to interact
8. The architecture should contain a specific and small set of resource contention areas, the resolution of which is clearly specified and maintained.