lectures.alex.balgavy.eu

Lecture notes from university.
git clone git://git.alex.balgavy.eu/lectures.alex.balgavy.eu.git
Log | Files | Refs | Submodules

commit 2f6af9155ce906fe3b599177be9152acc9a55b70
parent fd4bf671e97ac881af590df032c1ac77c764cc25
Author: Alex Balgavy <alex@balgavy.eu>
Date:   Tue, 10 Nov 2020 17:30:46 +0100

Software arch: new lecture notes + better diagram

Diffstat:
Acontent/software-architecture/Architecture representation/543e94d9807540b59fb5d808ff646387.png | 0
Acontent/software-architecture/Architecture representation/7f091d7ea68f427298f3332e45870d4a.png | 0
Acontent/software-architecture/Architecture representation/index.md | 55+++++++++++++++++++++++++++++++++++++++++++++++++++++++
Acontent/software-architecture/Case Study/7d0ab84b042b48cc80c6bc0b8fc8cc8a.png | 0
Dcontent/software-architecture/Case Study/d3da04e031084587bc44f2b4b737aa84.png | 0
Mcontent/software-architecture/Case Study/index.md | 4++--
Mcontent/software-architecture/_index.md | 1+
7 files changed, 58 insertions(+), 2 deletions(-)

diff --git a/content/software-architecture/Architecture representation/543e94d9807540b59fb5d808ff646387.png b/content/software-architecture/Architecture representation/543e94d9807540b59fb5d808ff646387.png Binary files differ. diff --git a/content/software-architecture/Architecture representation/7f091d7ea68f427298f3332e45870d4a.png b/content/software-architecture/Architecture representation/7f091d7ea68f427298f3332e45870d4a.png Binary files differ. diff --git a/content/software-architecture/Architecture representation/index.md b/content/software-architecture/Architecture representation/index.md @@ -0,0 +1,55 @@ ++++ +title = 'Architecture representation' ++++ +# Architecture representation +Analogy with the architecture of a building: +- overall picture for client +- front view for client and "fine arts" committee +- different view with water supply for plumber +- different view with electrical wiring for electrician +- etc. + +Basically, there are two flavors: +- powerpoint slides, for managers/users/clients +- UML diagrams, for technicians + +## ISO/IEC/IEEE standard for architecture description (ISO 42010) +Defined as architecture views and viewpoints. + +System stakeholder: individual/team/organization with interest in system +View: expresses architecture of system from perspective of specific system concerns (like a map) +Viewpoints: establishes conventions for construction, interpretation, and use of architecture views to frame specific system concerns (like a legend for a map) + +Viewpoint specification: +* Viewpoint name +* Stakeholders addressed +* Concerns addressed +* Language, modelling techniques (including explanation of symbols) + +Viewpoints separate concerns. + +## Kruchten's 4+1 view model + +![Kruchten's view model](7f091d7ea68f427298f3332e45870d4a.png) + +* Scenario viewpoint: small subset of important scenarios to show that elements of four viewpoints work together seamlessly. + * acts as driver to help designers find architectural elements during architecture design + * validates and illustrates architecture design on paper and as starting point for prototype tests +* Logical viewpoint: supports functional requirements (services system should provide to users), shows key abstractions +* Process viewpoint: mapping of functions to runtime elements +* Implementation viewpoint: focuses on organisation of actual software modules (incl. packaging) +* Deployment viewpoint: how various elements from above viewpoints must be mapped onto nodes + +## How to decide on views +What are stakeholders and their concerns? +Which views address the concerns? +Then prioritize and maybe combine views. + +## Documenting a view +* primary representation (graphical/textual) +* element catalog -- refer to every element and relation, propose a definition +* perhaps context diagram, variability guide +* rationale -- why does the view have what it has? + +![View documentation](543e94d9807540b59fb5d808ff646387.png) + diff --git a/content/software-architecture/Case Study/7d0ab84b042b48cc80c6bc0b8fc8cc8a.png b/content/software-architecture/Case Study/7d0ab84b042b48cc80c6bc0b8fc8cc8a.png Binary files differ. diff --git a/content/software-architecture/Case Study/d3da04e031084587bc44f2b4b737aa84.png b/content/software-architecture/Case Study/d3da04e031084587bc44f2b4b737aa84.png Binary files differ. diff --git a/content/software-architecture/Case Study/index.md b/content/software-architecture/Case Study/index.md @@ -2,7 +2,6 @@ title = 'Case Study' +++ # Case Study - ## Overview Connecting consumers of energy directly with renewable energy sources creates a higher certainty that what consumers pay for energy ends up with a renewable producer, and not with a fossil energy plant Challenge: balancing the grid. @@ -77,4 +76,5 @@ Settlements - SO settles payment with the Aggregator based on the delivered flexibility (MW power delivered). - Aggregator settles payment with the prosumer/OEM based on the power delivered from their device -![Case study architecture interaction diagram](d3da04e031084587bc44f2b4b737aa84.png) +![Case study architecture diagram](7d0ab84b042b48cc80c6bc0b8fc8cc8a.png) + diff --git a/content/software-architecture/_index.md b/content/software-architecture/_index.md @@ -5,3 +5,4 @@ title = 'Software Architecture' - [Case Study Overview](case-study/) - [Introduction](introduction/) - [Requirements](requirements/) +- [Architecture representation](architecture-representation/)