Introduction to Software Architecture

What is Software Architecture?

Software architecture of a software system is the structure or structures of the system which comprise:

  • Software components
  • Externally visible properties of those components
  • The relationships among them

Another definition of software architecture may constitute:

A collection of computational components shared across a series of products or systems together with a description of the interactions between the components and constraints on how they can be combined.

Software architecture is important for number of reasons…

  • It encourages communication among stakeholders
  • Provides the early design decisions which will be built upon
  • Provides a transferable abstraction of a system (among applications within a similar domain)

What is a component?

From an architectural point of view a component is an entity with a well-defined interface.
It could be an object, package, database, process, library or even another software system.


Influencing factors

From the same set of requirements two architects may design two entirely different architectures.
This implies that architecture is not necessarily tied to the requirements. There are other influences which may affect the outcome of a architecture design;

  • Technical; for example, the development operating system features
  • Social; for example, a development house with several client-server architectural experts
  • Business; for example, the defence industry's concern with security

Stakeholders in a system are individuals with some vested interest in the system. These can include management, marketing, maintenance, the customer and/or the end-user. Stakeholders typically influence the software architecture.
An architect must manage stakeholders by:

  • identifying and actively engaging them
  • soliciting and managing their needs and expectations

This can be achieved via the use of architecture reviews and iterative prototyping.


Trade-offs

Architecture is the earliest artefact of the design process that allows competing concerns to be analysed (ie: performance VS. reliability, cost of current project VS. long-term cost of software development).


Architecture Business Cycle (ABC)

This presents us with two important insights.

  • The environment influences the architecture
  • The architecture influences the environment
    • Determines organisational structure ('teams' implement components)
    • Redefines enterprise goals of the organisation (may lead to development of similar projects with the same architecture)
    • Affects customers (and their requirements for next system(s))
    • Gives new experience to the architect(s)
    • Legacy components for new systems
sescabc.jpg

Activities in creating an Architecture

These include:

  1. Creating the business-case
  2. Requirements elicitation
  3. Designing/selecting the architecture
  4. Representing/communicating the architecture to stakeholders
  5. Evaluating the architecture
  6. Implementing based on the architecture and ensuring conformance

Creating the business-case

This involves not only identifying the market need for a system, but is also an important step in creating and constraining any future requirements such as cost, target market, time constraints and interfaces with other systems.

Requirements elicitation

This occurs in conjunction with customers AND end-users. The typical deliverables include use-cases/scenarios, finite state machine models and formal-specifications.
Also the stage that domain analysis occurs, including research into old systems and prototypes.

Designing / Selecting the Architecture

Design typically involves the use of architectural styles and/or design patterns. In any design process multiple candidate designs should be considered.

Representing and Communicating the Architecture to Stakeholders

This can be done using formal languages (ADL), but regardless of whether this is used or not the medium should be informative, unambiguous and readable.
The architecture must be communicated to all the stakeholders.

Evaluating the Architecture

Using ADL we can assess the runtime properties of the system (performance, behaviour, communication patterns) while scenario-based evaluation is used to judge the non-runtime properties (portability, reusability, adaptability).

Implementing the Architecture and Ensuring Conformance

This involves keeping the developers faithful to the structure and interaction protocols constrained by the architecture.
This requires:

  • Well-communication architecture
  • Environment/infrastructure to assist in maintaining the architecture

Architecture Style

A style consists of a description of component types and a pattern of their runtime control and/or data transfer. It can be thought of as a set of constraints on the architecture elements.
An example of this is a pipeline architecture:

  • The output of each component is the input of another
  • Computation involves transformations on streams of data

Reference model

A reference model is a division of functionality together with data flow between the pieces. For example, a compiler's functionality can be expressed as: lexical analysis, syntactic analysis, code generation, etc.
The existence of a reference model shows the maturity of a domain.


Reference Architecture

A reference architecture is a reference model mapped onto software components to implement functionality and links to implement data flow.


Architectural structures

Also known as architectural views, these represent the system from different perspectives. These include: conceptual/logical structure, module/subsystem structure, process/coordination structure, physical structure, uses structure, calls structure, data flow, control flow, class structure, execution structure and code structure.

Conceptual/Logical view

Within this the units are abstractions of the system's functional requirements (reference model is an example of this).
Units are linked via a shares-data-with relation. It is useful for understanding the interactions between entities in the problem space.

Module view

The units are work assignments. The module view has deliverable products (such as interface specification, code, test plays) associated with it.
Units are linked via is-a-subsystem-of relations. This is useful for allocating labour and other resources.

Physical view

The physical view depicts the mapping of software onto hardware. The units are hardware entities and the links are communication pathways. Relations between processors are communicates-with.
Provides insight into performance, availability and security.

Uses view

Units are modules or procedures. These are linked with the assumes-the-correct-presence-of relation. It helps in facilitating incremental builds and gives insight into reusability and extendibility.

Using multiple views

Often a system's structure is considered in terms of its functionality. However, there are other properties such as physical distribution and process communication. Each view provides reasoning about some quality attributes.

Relating views to each other provides a different perspective and design-angle on a system. Note that these views are not independent; changes in one view may influence the others.

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