Software Architecture

University of Nantes — LS2N, France

https://sunye-g.univ-nantes.io

Gerson Sunyé gerson.sunye@univ-nantes.fr

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 granularity):

  • 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 Views

Development, Physical, and Process Views

Development view

Describes the internal organization of the software packages. Represented as UML Package Diagrams

Physical/Deployment view

depicts how the major processes and components are mapped on to the applications hardware. Represented as UML Deployment Diagrams

Process view

describes the concurrency and communications elements of an architecture. Represented as UML Activity Diagrams or UML Interaction Diagrams

Logical, Operational, and Information Views

Logical view

Describes architecturally significant elements of the architecture and the relationships between them. Represented as UML Component Diagrams

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.

Assertion View and Use Cases

Assertion view

describes how the system should be tested and evaluated.

Use Cases

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

Philippe Kruchten. «The 4+1 View Model of Architecture». In IEEE Software, vol. 12, no. 6, November 1995, pp. 42-50.

Christine Hofmeister et al. «A general model of software architecture design derived from five industrial approaches».
In The Journal of Systems and Software 80 (2007), pp. 106-126.

Rozanski, Nick & Woods, Eoin. «Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives».
In Addison-Wesley, October 2011.

Development View

Development View

  • Describes how programmers should organize the software source code:

    • Dependencies, versioning, code generation, build, etc.

  • Sometimes called «Application» or «Module» view.

Development View Notation

  • UML Package diagrams show package organization and dependencies between packages.

packages

Package Dependencies

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.

Diagram

Example: NeoEMF Development View

Diagram

https://github.com/atlanmod/NeoEMF

Package Coupling Principles

  1. Acyclic Dependency

  2. Stable Dependencies

  3. Stable Abstractions


If the SOLID principles tell us how to arrange the bricks into walls and rooms, then the component principles tell us how to arrange the rooms into buildings.
— Robert C. Martin

Robert C. Martin, «Clean Architecture: A Craftsman’s Guide to Software Structure and Design»

Acyclic Dependency Principle

Circular dependencies between packages are forbidden and should be eliminated.

Cyclic Dependency between two Packages
Figure 1. Cyclic Dependency between two Packages

Stable Dependencies Principle

All the dependencies should be directed from less stable modules that change often to more stable modules that change less often.



Diagram

Stable Abstractions Principle

The stability of any component must be proportional to its abstraction level.


Diagram

Common Reuse Principle

  • Clients should not depend on functionalities they do not need

  • Classes that tend to be reused together belong in the same component


Diagram

Layered Architecture Pattern

Hierarchical organization. Each layer:

  • provides service to the layer above it and

  • serves as a client to the layer below it.

Mark Richards, «Software Architecture Patterns, 2nd Edition». In O’Reilly Media, Inc. August 2022.

layred architecture pattern

Clean Architecture Layers

clean architecture

Source code dependencies must point only inward, toward higher-level policies.

Physical View

Physical View

  • 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.).

UML Specification Level Deployment Diagram
Figure 2. UML Specification Level Deployment Diagram
UML Manifestation
Figure 3. UML Manifestation

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

Client-Server Architecture

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

UML Specification Level Deployment Diagram
Figure 4. UML Specification Level Deployment Diagram

Client-Server Architecture (Instances)

Instance Level Deployment Diagram
Figure 5. Instance Level Deployment Diagram

Release/Reuse Equivalence Principle

  • The unit of reuse is the unit of release.

  • Classes and modules that are formed into a component must belong to a cohesive group and should be released together.

UML Manifestation
Figure 6. UML Manifestation

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.

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 objects: 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

Pipes and Filters Pattern

  • Function-Oriented Pipelining

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

pipes and filters

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.)

Blackboard Pattern

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

blackboard

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

Architecture Examples

Architectural Style and Pattern

An architectural style is 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
An architectural pattern is a general, reusable resolution to a commonly occurring problem in software architecture within a given context
— R.N. Taylor

Most Known Architectural Styles and Patterns

  • Microservices

  • Blackboard

  • Client-server (2-tier, 3-tier, n-tier)

  • 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

  • Space-based

  • Persistence Free

  • Cloud Computing

Further Readings