Architecture and System Quality

System quality

There are two broad classes of system quality; observable via execution (or runtime) and not observable via execuation (or non-runtime).
The architecture of a software system is of critical importance in realizing many qualities of interest in a system. These qualities should then be designed-in / evaluated at the architectural level. On the other hand some are not architecturally sensitive and trying to achieve them via architectural design is pointless.

Runtime system quality attributes include:

  • Performance; refers to the responsiveness of the system (either time in responding to events or number of events processed in some time interval). Performance can be a functino of how much communication & interaction there is between components of the system.
  • Security; a measure of the system's ability to resist unauthorized access attempts / DoS attacks. Architectural security strategies include authentication servers, network monitors / firewalls…
  • Availability; measures the proportion of time the system is up and running. It is measured by the length of time between failures as well as how quickly the system recovers in the event of a failure. Architectural strategies include: installing redundancy, reducing code-errors, implementing error reporting/handling and desing easily modifiable components.
  • Functionality; is the ability of the system to do the work for which it was intended. Is largely non-architectural in nature.
  • Usability; can be broken down into: learnability, efficiency, memorability, error avoidance, error handling and satisfaction. The only typically architecture-dependent usability features are efficiency and error handling. Architectural strategies involve supplying the "right information at the right time" and ensuring user instructions are routed to the correct component .

Non-runtime system quality attributes include:

  • Modifiability; (possibly the most closely aligned characteristic with architecture) refers to the ease of: extending/changing capabilities, deleting unwanted capabilities, adapting to new operating environments and restructuring. Modifiability is largely a function of the locality of any change; since architecture defines the components & responsibilities of a system it also defines circumstances under which each component will have to change.
  • Portability; the ability of the system to run under different computing environments. A portable system means all assumptions about any particular computing environment are confined to a single component. Typically a portability layer is used to encapsulate low-level computing-environment dependent considerations.
  • Reusability; means designing a system so that the system's structure or some of its components can be reused again in future applications. It is related to architecture in that reusable components are loosely coupled with other components. Reusability can said to be a special case of modifiability.
  • Integrability; the ability to make separately developed components of a system function together. It depends on the external complexity of components, their interaction mechanisms, the degree of separation of concerns and the interfaces to components.
  • Testability; is the ease with which software can be made to demonstrate its faults via testing. This depends on architectural documentation, separation of concerns and the degree to which information hiding is employed.

Business quality

  • Time to market; will influence whether pre-built components or reusable components are utilised.
  • Cost; different architectures will yield different costs
  • Projected lifespan; will determine the degree to which modifiability / extensibility is important.
  • Target market; specifies whether a general-purpose software product (portable and functional) or domain-specific (product-line) approach should be employed.
  • Rollout schedule
  • Extense of legacy system use

Architecture quality

  • Conceptual integrity is the underlying theme or vision that unifies the design of the system at all levels.
  • Correctness and completeness are essential for the architecture to allow the satisfaction of all the system's requirements and run time resource constraints.
  • Buildability is the quality of the architecture tha allows the system to be completed by the available team in a timely manner.

Architectural means for achieving quality

When choosing a software architecture we should look for one that accomodates changes. The goal is to produce a system structure such that each anticipated change will only affect a small number of system components. It must handle:

  • Modifications introducing new environment
  • New platform deployments
  • New operating interfaces
  • Addition of new devices

As an architecture one should aim to capture possible changes that could occur in the design:

  • Changes anticipated for this system or experienced by similar systems
  • Changes anticipated by mining the requirements for areas of uncertainty
  • Decrease in functionality brought about because of a management decision to field a subset of the system

Architecture design


Architectural views include:

  • Conceptual view; shows how functionality required of the system is mapped on to architecture elements called conceptual components and connectors. Concerns how the system fulfills requirements; including COTS component integration, incorporation of domain specific hardware/software, etc..

Cv = R → {Cm , Cn}
Where… R = requirements, Cm = components, Cn = connectors

  • Model view; concerns the decomposition of the system and partitioning of modules into layers. Concerns how the product is mapped onto a software-platform. Primary concerned with reducing dependencies between modules and maximising reuse.

Mv = Cv → {Sm , M}
Where… Sm = subsystems, M = modules

  • Execution view; shows how modules are mapped to elements provided by the runtime platform. Defines runtime entities such as memory usage, execution flow of control. With the execution view we can start to look at performance requirements, resource usage, concurrency, etc.

Ev = Mv → H
H = Hardware architecture

  • Code view; shows the mapping between Module view and source components. Also deals with how deployment components are produced from source components. Is concerned with reducing time/effort for product upgrades, managing versions/releases, reducing build time, supporting tools for development, integration/testing, etc…

Kv = Mv → {Cs} → {Cd}

Why different views?

We use different architectural views for a number of reasons.

  • Separation of concerns
  • Complexity management
  • Address concerns at different levels of abstraction
  • Address high priority decisions first and more easily analyze design trade-offs.

Conceptual view


Module view


Code view


Execution view

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License