Software Architecture

Hierarchical organisation of software

1. Data and memory

2. Algoritms

3. Objects

4. Modules

5. Componeny

6. System

7. System of systems

System decomposition

process of breaking down a complex system into smaller, more manageable components

Principles of System Decomposition

1. Modularity – divide-and-conquer

2. Abstraction – (Don’t re-invent the wheel) Focus on creative parts; if something already exists, reuse it

3. Encapsulation – Separation of concerns

Software Architecture

set of high-level decisions that determine the structure of the software solution

→Aim to use well-known solutions that are proven to work for similar problems

Key decisions in Software Architecture

1. System decomposition

   • How do we break the system up into parts?

   • What functionality/behavior to include?

   • Do we have all the necessary parts?

   • How do the parts interact?

2. Cross-cutting concerns

   • Broad-scoped qualities or properties of the

   system

   • i.e. non-functional requirements

   • Usually a trade-off between qualities

3. Conceptual integrity

   • Does the system make sense?

Architecture vs Design

1. Architecture focuses on non- functional requirements and on the decomposition of a system

2. Design focuses on implementing functional requirements

Architectural Styles

a general, reusable solution to a commonly occurring problem in software architecture within a given context

→Different from, but related to, design patterns

Architectural Views

Views are different kinds of “blueprints” created for the system-to-be

4+1 Architectural View Model

1. Logical View

2. Development view

3. Process View

4. Physical view

5. Scenario view

Logical view

1. concerned with the functionality provided to users

   →Focuses on the decomposition of the system into a set of key abstractions, namely objects and classes

How is Logical view Represented in UML

1. Class diagram

2. State diagram: give a dynamic view of objects

Development View

concerned with software administration from the point of view of the programmer

Focuses on components: modules of classes that represent independent systems or subsystems with the ability to interface with the rest of the system.

How do we represent Development View in UML

1. Component diagrams: show how different components in a system interact.

Process View

concerned with the dynamic aspects of the system, explaining the system processes and how they communicate

→Focuses on the runtime behaviour of the system

How is Process View represented in UML

1. Activity diagrams : show the workflow of a system

2. Sequence diagrams: show how components/objects in a system interact over time

Physical View

concerned with the physical distribution of the system, as well as the physical connections between distributed parts

→Depicts the system from the system engineer’s POV

Physical View UML Representation

1. Deployment diagrams: model the physical deployment of artifacts (software components) on nodes (hardware components)

Two types of nodes in deployment diagrams

1. Device nodes – physical devices that run software (computer, phone)

2. Execution Environment Node (EEN) – software resource that runs on a device and can execute other software (server, browser)

Scenario view

describe the system’s architecture through use cases– the list defining interactions between a role and a system to achieve some goal

Scenario view UML representation

1. use case diagrams

Drawing tools

1. Draw.io

2. Umbrello

3. Lucidchart