SENG4420 - Software Architecture

Architecture is an important part of the design process in many engineering disciplines. In early days of computing, a software system was considered just a combination of Algorithms and Data Structures. As engineers started building large and complex software applications in different domains, they recognized the need for organizing the system into systematic repeatable structures, thus giving birth to Software Architectural styles such as pipelines and filters, client-servers, and component-based styles.
Software Architecture of a program or a software system is the structure of the system, which comprise software components, the externally visible properties of those components, and the relationships among them.


1. Introduction to Software Architecture

Software architecture of a software system is the structure or structures of the system which comprise software components (entities with well-defined interfaces), externally visible properties of those components and the relationships among them.
Software architecture is important because it encourages communication among stakeholders, provides an early design and facilitates a transferable abstraction of a system.
From the same set of requirements two architects may design two entirely different architectures. The architecture of a system is not necessarily tied to the requirements; a number of other factors may influence it. This factors include:

  • Technical
  • Social
  • Business

Stakeholders are individuals with some vested interest in a project. An architect must manage stakeholders by identifying and actively engaging them as well as soliciting and managing their needs and expectations.
There are a number of activities involved in creating an architecture. These are:

  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

Architecture style refers to a description of component types and a pattern of their runtime control and/or data transfer.
A Reference model is a division of functionality together with data flow between the pieces.
A Reference architecture is a reference model mapped onto software components to implement functionality and links to implement data flow.
Architectural structures (aka architectural views) represnt the system from different perspectives.


2. Architecture and System Quality

'Qualities' of software can be broken down into three categories. System qualities, Business qualities and Architectural qualities.
System qualities can be divided further into two categories; those that are observable via execution (or runtime) and those that are not observable via execuation (or non-runtime).
Software qualities include:

  • Runtime system quality attributes. Things such as performance, security, availability, functionality and usability.
  • Non-runtime system quality attributes. Things such as modifiability, portability, reusability, integrability and testability.

Business qualities include

  • Time to market
  • Cost
  • Projected lifespan
  • Target market
  • Rollout schedule
  • Extense of legacy system use

Architecture qualities include

  • Conceptual integrity
  • Correctness and completeness
  • Buildability

We typically use different architectural 'views' when designing a system. These allow us to enforce separation of concerns and employ complexity management as well as addressing concerns at different levels of abstraction.
Typically we use:

  • Conceptual view; shows how functionality required of the system is mapped on to architecture elements called conceptual components and connectors.
  • Model view; concerns the decomposition of the system and partitioning of modules into layers.
  • Execution view; shows how modules are mapped to elements provided by the runtime platform.
  • Code view; shows the mapping between Module view and source components.

3. Architecture Design: Global Analysis

Global analysis complements requirements analysis and risk analysis. The goal of global analysis is firstly to analyse factors that affect the architecture design. We then need to develop strategies to accommodate the factors.
The factors can be divided into 3 categories:

  • Organisational factors
  • Technological factors
  • Product factors

There are 3 steps involved in performing a global analysis:

  1. Indentify and describe factors
  2. Characterise the flexibility and changeability of the factors
  3. Analyse the impact of the factors

Factor tables and issue cards are created as a result of the global analysis.


4. Architecture Design: Conceptual Architectural View

The Conceptual view is the closest to the application domain. Activities in the creation of the conceptual view include:

  • (Ongoing) Global analysis
  • Central design tasks
      • Identification of conceptual components & connectors, conceptual configuration
    • Evaluation of the architecture using Issue cards
  • Final design task
    • Resource budgeting (initial budgeting only, may need to be re-visited in execution view)

5. Architecture Design: Module View

The Module View focuses on how functionality is mapped to implementation. The central design tasks in creating the module view are based on the strategies from global analysis, experience with prior products and general software engineering knowledge. These tasks include:

  • Mapping conceptual elements from conceptual model to modules
  • Creating layers and assigning modules to layers
  • Determining the interface of the modules & layers

6. Architectural Styles

An architectural style defines a class of architectures determined by: a set of component types, a layout of those components, component constraints and a set of connectors.
An architectural style does not define the number of components involved, the mechanisms for component interaction or the function of the system.
Architectural styles include:

  • Independent component architecture (event or communication based)
  • Data centred architectures (using either repository or blackboard stores)
  • Data flow architectures (either batch sequential or pipe-and-filter)
  • Virtual machine architectures
  • Call-and-return architectures
  • Layered architectures
  • Three-tiered architectures
  • Heterogeneous architectures

A number of software-patterns can be exploited to increase the effectiveness of our architectures or make architecture-casting easier. These include the Façade and AbstractFactory patterns.

There are three primary concerns in the organisation of an architectural style. These include;

  • The Constituent parts: organisation of components & connectors
  • Control issues: concerns the control-flow topology and synchronicity
  • Data issues: concern data-flow topology and mode.

7. Software Architecture Analysis Method (SAAM)

SAAM is a method to determine the degree to which an architecture meets its goals. It is used for:

  • Validation during development / testing
  • A benchmark when acquiring software
  • Comparing architectures

A assessment is completed using scenarios. A scenario is a brief description of a single interaction of a stakeholder with a system.
SAAM Steps include:

  1. Develop scenarios
  2. Classify scenarios
  3. Perform scenario evaluations
  4. Reveal scenario interaction
  5. Overall evaluation

8. Introduction to Software Metrics

Measurement is a process via which numbers or symbols are assigned to attributes of entities in the real world in order to describe them according to some set of rules.

  • An entity is an object or event in the real world
  • Attributes are features or properties of entities

The representational theory of measurement seeks to formalise our intuition about the way the world works. It states that:

  • Data we obtain as measures should represent attributes of the entities we observe
  • Manipulation of the data should preserve relationships that we observe among the entities
  • Our intuition is the starting point for all measurement

An empirical relation is one for which there is a reasonable consensus about which entities are in the relation. For example, "taller than" is a relation defined on the set of pairs of people - we say that "taller than" is an empirical relation for height.

Direct measurement of an attribute of an entity involves no other attribute or entity. Indirect measurement of an attribute of an entity involves other attributes or entities.

The purpose of measurement (ie: performing the mapping between an empirical relation and a numerical system) is to:

  • Be able to manipulate the data
  • Draw conclusions about the attribute in the empirical system

There are five major types of measurement scales:

  • Nominal: entities are grouped into different classes / categories based on some attribute (there is no magnitude relationship between the classes). The class of admissible transformations for a nominal scale measure is the set of all one-to-one mappings.
  • Ordinal: similar to nominal but the classes are ordered with respect to the magnitude of the attribute. Any mapping preserving this order (any monotonic function) is acceptable.
  • Interval: the interval scale is similar to the ordinal scale but also preserves differences (but not ratios). The transformation M = aM' + b is allowable and addition/substraction are applicable.
  • Ratio: preserve interval size and ratios. The mapping M = aM' is allowable and all arithmetic can be meaningfully applied.
  • Absolute: measurement is made by counting the number of elements in an entity set. There is only one possible measurement mapping (counting) and all arithmetic operations are applicable.

Gibb's principle states: "Projects without clear goals will not achieve their goals clearly".

Objectives of Software Measurement include:

  • Understanding: can make aspects of the process and product more visible
  • Control: can make changes to processes and products to help us meet our goals
  • Improvement: helps us to improve our future processes / products

9. Meaningfulness in Measurement

Understanding scale types help us to decide when statements about measurement make sense.
A statement involving measurement is meaningful if its truth value is invariant of the transformations of allowable scales
The scale type of a measure affects the types of operations and statistical analyses that can be sensibly applied to the data.
A measure of central tendency tells us something about where the middle of the set is likely to be.
When performing some statistical analysis we strive to keep measurements objective. This is because subjective measures are likely to vary depending on the person(s) measuring.
When taking multiple attributes into consideration when making a decision we need to assign weights for the sub-attributes.
Goal-Question-Metric (GQM) framework is an effective approach for selecting and implementing metrics. It consists of:

  1. Classifing the entities to be examined
  2. Expressing the overall goals of your organisation
  3. Generating the questions whose answers you must know to determine if your goals are met
  4. Analysing each question to determine what measurements you need to do in order to answer it
  5. Checking whether it is possible to do those measurements

10. Software Size


11. Measuring External Product Attributes


12. Review


IS2000: A Case Study

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