Software Architecture

University of Nantes – LS2N, France

Gerson Sunyé

Definition of Software Architecture

Software architecture is the high level structure of a software system, the discipline of creating such structures, and the documentation of these structures.

It is the set of structures needed to reason about the software system, and comprises the software elements, the relations between them, and the properties of both elements and relations.

— Clements et al. 2010

A set of Decisions and Tradeoffs

Strategical choices for system design and implementation.

Some examples (with different granularities):
  • Use a n-tiers architecture.

  • Use REST for remote procedure call.

  • Use the MVC framework for partitioning business classes and user interfaces.

  • Respect the Google Java Style for source code.

  • Access methods should start with get and set.

  • Use a graph database for persisting data.

An Orthogonal Activity

  • Architectural design may be independent from the domain analysis.

  • The same architecture may be used on different projects.

architecture process overview

Architectural Viewpoints

architectural viewpoints
Figure 1. RUP 4+1 Views

Architectural Viewpoints

Logical view

describes architecturally significant elements of the architecture and the relationships between them.

Process view

describes the concurrency and communications elements of an architecture.

Physical view

depicts how the major processes and components are mapped on to the applications hardware.

Development view

captures the internal organization of the software components as held in e.g. a configuration management tool.

Architecture use cases

capture the requirements for the architecture; related to more than one particular view

Additional Viewpoints

Operational view

Describes how the system will be operated, administered, and supported when it is running in its production environment.

Information view

Describes the way that the architecture stores, manipulates, manages, and distributes information.

Other Views

Deployment view

describes how the system will be deployed and updated in its production environment.

Assertion view

describes how the system should be tested and evaluated.

Development View

Development View

Viewpoints
Describes how programmers should organize the software source code:
  • Dependencies, versioning, code generation, build, etc.

Development View

  • UML Package diagram

  • Dependencies between packages.

packages

Dependencies between Packages

UML Dependency relations:
«import»

elements are imported from one namespace to another.

«access»

elements from the target namespace are simply used.

«merge»

defines how a package extends another.

Example: NeoEMF Development View

Physical View

Physical View

Viewpoints
  • Describes how system engineers should deploy software artifacts on logical nodes.

  • Defines the network topology (node organization) and communication paths.

  • Specify deployment constraints for artifacts: required hardware, libraries, resources, etc.).

Diagram

Artifacts

Artifacts are physical pieces, used during the software development process:
  • source files, models, scripts, binaries, documents, configuration files, etc.

artifact order

Nodes

  • Nodes are logical resources, on which artifacts are deployed.

  • Nodes are connected through communication paths.

  • Node instances may also be represented.

deployment zope

Process View

Process View

  • Describes the process flow of control mode and process concurrency for each executable unit (processes, threads).

  • If each component executes in its own process, detailed information should be provided.

  • Related quality factors: performance and scalability.

architectural viewpoints

Flow of Control

Sequential

there is a single flow of control. i.e, one thing, and one thing only, can take place at a time.

Concurrent

there are multiple simultaneous flow of control i.e, more than one thing can take place at a time.

Other modes

procedural, event-driven, batch, etc.

Synchronization

Synchronization means arranging the flow of controls of objects so that mutual exclusion is guaranteed.

cd buffer
UML Synchronization Approaches:
  1. Sequential

  2. Guarded

  3. Concurrent

Approaches to handle synchronization: Sequential

Sequential

Clients must coordinate outside the object so that only one flow is in the object at a time



Diagram

Approaches to handle synchronization: Guarded

Guarded

Multiple flow of control is sequentialized with the help of object’s guarded operations. In effect it becomes sequential.



Diagram

Approaches to handle synchronization: Concurrent

Concurrent

Multiple flow of control is guaranteed by treating each operation as atomic



Diagram

Concurrency

  • May be intrinsic, imposed by the environment: multiples user interfaces, etc. For instance:

    • Swing creates a separate thread for the user interface.

    • Remote Procedure Call (RPC) middleware creates a thread for processing calls: e.g. Java RMI or Apache Thrift.

  • Or a design choice:

    • Parallel processing

    • Redundancy

Active Classes

  • Active classes are just classes which represents an independent flow of control

  • When an active object is created, the associated flow of control is started; when the active object is destroyed, the associated flow of control is terminated

  • Standard stereotypes that apply to active classes are:

    «process»

    specifies a heavyweight flow that can execute concurrently with other processes.

    «thread»

    specifies a lightweight flow that can execute concurrently with other threads within the same process.

cd active classes

Active Class Implementation

  • Naive approach:

    • Assign a process/thread for each active objet.

  • Consequences:

    • Context Switching Overhead

    • Wasted system resources: inactive processes waiting for new events.

Other Approaches

  • Concurrency design patterns:

    • Proactor.

    • Reactor.

    • Thread pool

  • Actors (Scala, Erlang).

Concurrent Data Structures

  • Atomic objets: Integer, String, etc.

  • Priority queue.

  • Blocking queue.

  • Concurrent associative array.

Concurrency patterns [Douglass02]

  • Concurrency

  • Interrupt

  • Guarded Call

  • Rendezvous

  • Cyclic Executive

  • Round Robin

  • Static Priority

  • Dynamic Priority

Logical View

Logical View

  • Use a component diagram to show components and their provided and required interfaces.

  • Describe component responsibilities

  • Other important information, e.g.,

    • Dependencies

    • Non-functional properties (e.g., maximum memory usage, reliability, required test coverage, etc.)

    • Mandated implementation technology (e.g., EJB, COM, etc.)

Reliability View

Reliability View

  • Redundancy specification

  • Limit conditions forecast:

    • Initializations

    • Finalization

  • Failure management and restart.

Failure Management

Typically:
  • Retry operation

  • Use redundant information to correct failure

  • Go to a fail-safe state

  • Alert someone

  • Restart the system

Reliability Patterns [Douglass02]

  • Watchdog: a simple polling process.

  • Protected Single Channel

  • Homogeneous Redundancy

  • Triple Modular Redundancy

  • Heterogeneous Redundancy

  • Monitor-Actuator

  • Sanity Check

  • Safety Executive

Architectural Perspectives

Architectural Perspectives

  • Collection of activities, tactics, and guidelines.

  • Used to ensure that a system exhibits a particular set of related quality properties that require consideration across a number of the system’s architectural views.

architectural perspectives

Perspectives

Accessibility

The ability of the system to be used by people with disabilities

Availability and Resilience

The ability of the system to be fully or partly operational as and when required and to effectively handle failures that could affect system availability

Development Resource

The ability of the system to be designed, built, deployed, and operated within known constraints around people, budget, time, and materials

Evolution

The ability of the system to be flexible in the face of the inevitable change that all systems experience after deployment, balanced against the costs of providing such flexibility

Internationalization

The ability of the system to be independent from any particular language, country, or cultural group

Location

The ability of the system to overcome problems brought about by the absolute location of its elements and the distances between them

Performance and Scalability

The ability of the system to predictably execute within its mandated performance profile and to handle increased processing volumes

Regulation

The ability of the system to conform to local and international laws, quasi-legal regulations, company policies, and other rules and standards

Security

The ability of the system to reliably control, monitor, and audit who can perform what actions on what resources and to detect and recover from failures in security mechanisms

Usability

The ease with which people who interact with the system can work effectively

Architectural Styles

Architectural Style

A set of design rules that identify the kinds of components and connectors that may be used to compose a system or subsystem, together with local or global constraints on the way the composition is done
— Shaw and Clements 1996

Most Known Architectural Styles

  • Blackboard

  • Client-server (2-tier, 3-tier, n-tier, cloud computing exhibit this style)

  • Component-based

  • Data-centric

  • Event-driven (or Implicit invocation)

  • Layered

  • Monolithic application

  • Peer-to-peer (P2P)

  • Pipes and filters

  • Plug-ins

  • Representational state transfer (REST)

  • Rule-based

  • Service-oriented

  • Shared nothing architecture

  • Space-based architecture

  • Persistence Free architecture

Blackboard Style

All shared data is held in a central database that can be accessed by all subsystems.

blackboard

Client-Server Style

The system is organized as a set of services and their associated servers and clients that access and use those services.

client server

Layered Style

Hierarchical organization. Each layer:
  • provides service to the layer above it and

  • serves as a client to the layer below it.

  • See also: Layered Application

layered

Pipes and Filters Style

  • Function-Oriented Pipelining

  • A sequence of filters that transform (filter) data before passing it on via pipes to other filters.

pipes and filters

Further Readings