20 KiB
PYTANIE 13/27: Modelowanie architektury systemów informatycznych (AIS)
Cele i metody modelowania architektury.
Tło pojęciowe — słowniczek
Architektura systemu informatycznego (software/system architecture) — fundamentalne decyzje projektowe dotyczące struktury systemu: jakie komponenty, jak się komunikują, jakie technologie. Jak plan architektoniczny budynku — definiuje „kształt" systemu przed budową.
Modelowanie architektury — tworzenie uproszczonych reprezentacji (diagramów, opisów) systemu na różnych poziomach abstrakcji. Cele: komunikacja w zespole, dokumentacja, analiza jakości (czy system będzie wydajny? skalowalny?), planowanie rozwoju.
Framework architektoniczny (architecture framework) — ustrukturyzowane podejście do opisywania architektury. Definiuje: jakie widoki (views) tworzyć, jakie aspekty uwzględnić, w jakiej kolejności pracować.
TOGAF (The Open Group Architecture Framework) — najpopularniejszy framework enterprise architecture. Definiuje metodykę ADM (Architecture Development Method) — cykliczny proces tworzenia architektury. 4 domeny:
- Business — procesy organizacji
- Data — struktury danych
- Application — aplikacje i ich interakcje
- Technology — infrastruktura (serwery, sieci)
ADM (Architecture Development Method) — cykliczny proces TOGAF: Preliminary → Vision → Business Arch → IS Arch → Technology Arch → Opportunities → Migration → Governance. Iteracyjny — można wracać do wcześniejszych faz.
4+1 View Model (Kruchten) — model pięciu perspektyw architektury:
-
Logical View — funkcjonalność (klasy, moduły)
-
Process View — współbieżność, przepływ danych
-
Development View — organizacja kodu (pakiety, warstwy)
-
Physical View — wdrożenie na sprzęt (serwery, kontenery)
-
+1 Scenarios — use cases łączące wszystkie widoki
Dlaczego 4+1? Bo różni interesariusze patrzą na system inaczej: programista → Development View, admin → Physical View, użytkownik → Scenarios, architekt → Logical View
Zachman Framework — taksonomia 6×6: pytania CO/JAK/GDZIE/KTO/KIEDY/DLACZEGO × poziomy abstrakcji (kontekst → logiczny → fizyczny → ...). Nie mówi JAK modelować — mówi CO należy udokumentować. Kompletny, ale złożony.
C4 Model (Simon Brown) — pragmatyczny model: 4 poziomy zoomu diagramów:
- Context — system w otoczeniu (kto go używa, z czym się integruje)
- Container — kontenery techniczne (app server, DB, SPA, API)
- Component — moduły wewnątrz kontenera
- Code — klasy, interfejsy (opcjonalnie, np. UML)
Zaleta: prosty, zrozumiały dla nie-architektów. Zaczynasz od „big picture" i zanurzasz się głębiej.
ArchiMate — język modelowania The Open Group. 3 warstwy (Business, Application, Technology) × 3 aspekty (Active Structure — kto?, Behavior — co robi?, Passive Structure — na czym?). Komplementarny z TOGAF.
UML (Unified Modeling Language) — uniwersalny język modelowania. W kontekście architektury: Component Diagram (moduły i zależności), Deployment Diagram (mapowanie na sprzęt), Sequence Diagram (interakcje w czasie).
ADR (Architecture Decision Records) — lekka dokumentacja: każda kluczowa decyzja architektoniczna zapisana jako plik z: kontekstem, decyzją, konsekwencjami. Wersjonowane w repo. Format: „Zdecydowaliśmy X, bo Y. Konsekwencje: Z."
ATAM (Architecture Tradeoff Analysis Method) — metoda oceny architektury przez scenariusze jakościowe. Identyfikuje tradeoffs: „ta decyzja poprawia wydajność kosztem modyfikowalności". Opracowana przez SEI (Carnegie Mellon).
Quality Attributes (atrybuty jakości, ISO 25010) — mierzalne cechy systemu: Performance, Security, Scalability, Maintainability, Reliability, Usability, Portability, Compatibility. Architektura determinuje osiągalne atrybuty jakości.
Diagramy — wizualizacja modeli architektonicznych
Poniższe diagramy ilustrują kluczowe frameworki i modele omówione w pytaniu. Wszystkie modelują architekturę systemu, ale z różnych perspektyw i na różnych poziomach abstrakcji.
TOGAF ADM — cykl iteracyjny:
4+1 View Model (Kruchten) — 5 perspektyw:
C4 Model — 4 poziomy zoomu (Context → Container → Component → Code):
Zachman Framework — taksonomia 6×6 (pytania × perspektywy):
ArchiMate — 3 warstwy × 3 aspekty:
Cele: komunikacja, dokumentacja, analiza jakości, planowanie, zarządzanie złożonością
Frameworki
TOGAF — metodyka ADM (Architecture Development Method), 4 domeny: Business, Data, Application, Technology.
4+1 View Model (Kruchten):
- Logical (funkcjonalność), Process (współbieżność), Development (organizacja kodu), Physical (wdrożenie), + Scenarios (use cases)
Zachman Framework — taksonomia 6×6: What/How/Where/Who/When/Why × poziomy abstrakcji.
C4 Model (Simon Brown):
- Level 1: System Context → Level 2: Container → Level 3: Component → Level 4: Code
ArchiMate — 3 warstwy: Business, Application, Technology × 3 aspekty: Active, Behavior, Passive.
Notacje: UML (Component, Deployment, Sequence), ArchiMate, C4, ADR (Architecture Decision Records)
Analiza: ATAM (Architecture Tradeoff Analysis Method), Quality Attributes (ISO 25010: Performance, Security, Scalability, Maintainability, Reliability)
Etymologia
TOGAF — The Open Group Architecture Framework. Zachman — John Zachman (IBM, 1987); framework nazwany od twórcy. C4 — 4 × C: Context, Container, Component, Code (Simon Brown, 2006). ArchiMate — „Architecture" + „animate" (The Open Group). ATAM — Architecture Tradeoff Analysis Method (SEI, Carnegie Mellon). Kruchten — Philippe Kruchten (Rational/IBM, 1995); 4+1 View Model. ISO 25010 — międzynarodowy standard atrybutów jakości oprogramowania.
Jak zapamiętać
0. LISTA WSZYSTKICH 5 FRAMEWORKÓW
TOGAF, Zachman, C4, 4+1, ArchiMate
Mnemonic: „Tomek Zachował Cztery Ciastka Archimedesowi"
T → TOGAF (metodyka — JAK budować)
Z → Zachman (taksonomia — CO dokumentować)
C4 → C4 Model (4 poziomy zoomu diagramów)
C → Cztery+1 (4+1) (5 perspektyw Kruchtena)
A → ArchiMate (język/notacja modelowania)
Podział ról — kto robi co:
TOGAF = PROCES (jak budować architekturę krok po kroku)
Zachman = TAKSONOMIA (co dokumentować — siatka pytań)
4+1 = PERSPEKTYWY (kto patrzy na system — 5 widoków)
C4 = ZOOM (jak głęboko patrzysz — 4 poziomy)
ArchiMate = JĘZYK (jakim językiem rysujesz diagramy)
Mnemonic ról: „PTZJZ" — „Proces, Taksonomia, Zoom, Jakby-pięć-oczu, Żargon"
1. TOGAF — 4 domeny: Business, Data, Application, Technology
Mnemonic: „BDAT" → „Buduj Domy Ale Tanio"
B → Business (procesy organizacji — CO firma robi)
D → Data (struktury danych — JAKIE dane)
A → Application (aplikacje — CZYM realizujemy)
T → Technology (infrastruktura — NA CZYM to stoi)
Kolejność = od abstrakcji do konkretu: firma → dane → apki → serwery
2. TOGAF ADM — 8 faz cyklu
Preliminary → Vision → Business → IS → Technology → Opportunities → Migration → Governance
Mnemonic: „PVB-IT-OMG!"
P → Preliminary (przygotowanie)
V → Vision (wizja architektury)
B → Business Arch (architektura biznesowa)
I → IS Arch (Information Systems — dane + aplikacje)
T → Technology Arch (infrastruktura)
O → Opportunities (szanse i rozwiązania)
M → Migration (plan migracji)
G → Governance (nadzór/zarządzanie)
Wyobraź sobie: Planujesz wizję biznesu, IT daje możliwości, migrujesz i zarządzasz — „PVB-IT-OMG!" (jakbyś krzyknął „OMG!" na koniec projektu)
3. 4+1 View Model (Kruchten) — 5 widoków
Logical, Development, Process, Physical + Scenarios
Mnemonic: „LoDeProFi + Scenariusz" albo „LDPP+S"
L → Logical (klasy, moduły — CO system robi)
D → Development (pakiety, warstwy — JAK kod zorganizowany)
P → Process (współbieżność — JAK przepływają dane)
P → Physical (serwery, kontenery — GDZIE wdrożony)
S → Scenarios (+1 — use cases łączące wszystko)
Mnemonic-historia: „Logik Deweloper Procesuje Fizycznie Scenę"
Kto patrzy na który widok — mnemonic par:
Architekt → Logical „Architekt LOGICZNIE myśli"
Programista → Development „Programista DEVELOPUJE"
Integrator → Process „Integrator scala PROCESY"
Admin → Physical „Admin zarządza FIZYCZNYMI serwerami"
Użytkownik → Scenarios „Użytkownik ma SCENARIUSZ użycia"
4. Zachman — 6 pytań
What, How, Where, Who, When, Why
Mnemonic: „Co Jak Gdzie Kto Kiedy Dlaczego" → „CJGKKD"
→ „Co Jan Gotuje? Kurczaka, Kiełbasę i Dynię"
Co → What (dane, encje)
Jak → How (procesy, funkcje)
Gdzie → Where (lokalizacje, sieci)
Kto → Who (ludzie, role)
Kiedy → When (zdarzenia, cykl)
Dlaczego → Why (cele, motywacje)
Zachman vs TOGAF — klucz: „Zachman = MAPA (co dokumentować), TOGAF = GPS (jak dojść)"
5. C4 Model — 4 poziomy zoomu
Context → Container → Component → Code
Mnemonic: „4 × C = Coraz Ciekawsze Części Codu"
C1 → Context (cały system z lotu ptaka — KTO go używa)
C2 → Container (zoom: kontenery techniczne — API, DB, SPA)
C3 → Component (zoom: moduły wewnątrz kontenera)
C4 → Code (zoom: klasy, interfejsy — opcjonalny)
Wyobraź sobie Google Maps:
Context = widok kontynentu (cały system w otoczeniu)
Container = widok miasta (budynki = kontenery techniczne)
Component = widok ulicy (pokoje wewnątrz budynku)
Code = widok mebli (detale — klasy, metody)
6. ArchiMate — 3 warstwy × 3 aspekty
Warstwy: Business, Application, Technology → BAT → „BATman jest architektem"
B → Business (procesy biznesowe)
A → Application (aplikacje)
T → Technology (infrastruktura)
Aspekty: Active Structure, Behavior, Passive Structure → ABP → „Aktor Biega Pasywnie"
A → Active Structure (KTO działa — aktorzy, komponenty)
B → Behavior (CO robi — procesy, usługi)
P → Passive Structure (NA CZYM — obiekty danych, artefakty)
Siatka 3×3 — wyobraź sobie tabelkę:
Aspekt → Active (KTO) Behavior (CO) Passive (NA CZYM)
───────────────────────────────────────────────────────────────
Business aktor bizn. proces bizn. obiekt bizn.
Application komponent usługa obiekt danych
Technology węzeł/serwer infrastruktura artefakt
7. UML — 3 diagramy architektoniczne
Component, Deployment, Sequence → CDS → „Co Dzień Sekwencja"
C → Component (moduły i zależności między nimi)
D → Deployment (mapowanie modułów → serwery/sprzęt)
S → Sequence (kto do kogo wysyła komunikaty w czasie)
Mnemonic-historia: „Komponent Deploy'ujesz i Sekwencyjnie testujesz"
8. Quality Attributes (ISO 25010) — 8 atrybutów
Performance, Security, Scalability, Maintainability, Reliability, Usability, Portability, Compatibility
Mnemonic: „PS SM RUPC" → „Pan Stefan Spotkał Małą Rudą Uczącą Polskiego Codziennie"
P → Performance (wydajność — jak szybko)
S → Security (bezpieczeństwo — jak chroniony)
S → Scalability (skalowalność — jak rośnie)
M → Maintainability (utrzymywalność — jak łatwo zmienić)
R → Reliability (niezawodność — jak rzadko pada)
U → Usability (użyteczność — jak łatwy w użyciu)
P → Portability (przenośność — jak łatwo przenieść)
C → Compatibility (kompatybilność — jak współpracuje)
Alternatywny podział na pary:
„Szybki i Bezpieczny" → Performance + Security
„Rośnie i Zmienia się" → Scalability + Maintainability
„Niezawodny i Łatwy" → Reliability + Usability
„Przenośny i Zgodny" → Portability + Compatibility
9. Cele modelowania — 5 celów
Komunikacja, Dokumentacja, Analiza jakości, Planowanie, Zarządzanie złożonością
Mnemonic: „KDAPZ" → „Każdy Dobry Architekt Planuje Złożoność"
K → Komunikacja (zespół się rozumie)
D → Dokumentacja (wiedza nie ginie)
A → Analiza jakości (czy będzie wydajne?)
P → Planowanie (co budować dalej)
Z → Zarządzanie złożonością (okiełznać chaos)
10. ADR — struktura
Kontekst → Decyzja → Konsekwencje → KDK
Mnemonic: „Kanapka: Kromka – Dżem – Kromka"
K → Kontekst (DLACZEGO decydujemy — sytuacja)
D → Decyzja (CO zdecydowaliśmy)
K → Konsekwencje (CO z tego wynika — plusy i minusy)
11. ATAM — co robi
„ATAM = ATakuj Architekturę Metodycznie"
→ Szukasz tradeoffs: „ta decyzja poprawia X kosztem Y" → Metoda scenariuszowa: wymyślasz scenariusze jakościowe i sprawdzasz, jak architektura sobie z nimi radzi
12. MASTER MNEMONIC — cały pytanie w jednym zdaniu
„Tomek (TOGAF) Zachował (Zachman) Cztery Ciastka (C4) i 4+1 Archimedesowi (ArchiMate), rysując UML-em ADR-y, a ATAM sprawdził jakość ISO."
Rozbicie:
Tomek → TOGAF (proces ADM: PVB-IT-OMG!, domeny BDAT)
Zachował → Zachman (siatka 6×6: CJGKKD × abstrakcje)
Cztery Ciastka → C4 (4×C: Context→Container→Component→Code)
4+1 → Kruchten (LDPP+S: Logical, Dev, Process, Physical + Scenarios)
Archimedesowi → ArchiMate (BAT × ABP)
UML → 3 diagramy: CDS (Component, Deployment, Sequence)
ADR → KDK (Kontekst, Decyzja, Konsekwencje)
ATAM → ATakuj Architekturę Metodycznie
ISO 25010 → 8 atrybutów: PS SM RUPC
🎮 Mostek do pracy magisterskiej — architektura silników gier
Moja praca porównuje architekturę Unity i Unreal Engine — to gotowy case study dla modelowania C4, 4+1, ADR.
C4 Model zastosowany do silnika gry
| Poziom C4 | Unity | Unreal Engine |
|---|---|---|
| Context | Gracz → Gra ← Twórca (edytor) | Gracz → Gra ← Twórca (edytor) |
| Container | Mono Runtime + IL2CPP, URP/HDRP Renderer, PhysX, FMOD | Unreal Runtime (C++), Nanite/Lumen Renderer, Chaos Physics, MetaSounds |
| Component | MonoBehaviour, ScriptableObject, Job System |
UActorComponent, USubsystem, TaskGraph |
| Code | C# klasy: BulletPool.cs, GameDirector.cs |
C++ klasy: ABullet, AGameMode |
4+1 Kruchten — mapowanie na silnik
| Widok Kruchtena | Silnik gry |
|---|---|
| Logiczny | Component Pattern, ECS, Scene Graph |
| Procesowy | Game Loop (Update→Physics→Render), wątki |
| Fizyczny | PC / PS5 / Xbox / Switch — deployment |
| Rozwojowy | Edytor Unity/UE, pakiety, pluginy |
| +1 Scenariusze | Gameplay: gracz strzela → bullet spawn → collision → damage |
ADR (Architecture Decision Records) z mojej pracy
Przykładowe decyzje architektoniczne, które mogę opisać językiem ADR:
-
ADR-001: Wybór Object Pooling zamiast Instantiate/Destroy
Kontekst: 500 pocisków/sekundę powoduje GC spikes
Decyzja: Pre-alokacja puli 500 obiektów
Konsekwencja: Frame time σ z 8ms → 2ms -
ADR-002: Singleton GameDirector zamiast static class
Kontekst: Potrzeba globalnego stanu gry z lifecycle
Decyzja: MonoBehaviour Singleton zDontDestroyOnLoad
Konsekwencja: Testowalne, ale tight coupling -
ADR-003: Unity URP zamiast Built-in RP
Kontekst: SRP Batcher zmniejsza draw calls o ~40%
Decyzja: Universal Render Pipeline
Konsekwencja: Lepszy batching, ale ograniczenie custom shaderów
Mnemonik — „SPRM" = Silnik Porównuję Rysując Modele
- Scena jako Context (C4 Level 1)
- Podsystemy jako Containers (Renderer, Physics, Audio)
- Rejestr decyzji ADR (dlaczego Pool, Singleton, URP)
- Moduły jako Components (MonoBehaviour, UActorComponent)
Na obronie: „W mojej pracy porównuję architekturę Unity i Unreal — to idealny case study dla modelowania C4. Na poziomie Container widzimy fundamentalne różnice: Unity opiera się na Mono/.NET runtime z GC, a Unreal na natywnym C++ z ręcznym zarządzaniem pamięcią. Decyzje architektoniczne (ADR) w mojej implementacji — jak wybór Object Pooling — bezpośrednio odnoszą się do ADR rationales z publikacji Borowej."
📚 Odniesienia do publikacji z Katedry
Poniższe notatki pochodzą z publikacji promotorów/recenzentów i mogą być przydatne jako dodatkowy kontekst na obronie.
Borowa, Zalewski, Kijas — „What rationales drive architectural decisions? An empirical inquiry" (ECSA 2023):
- Badanie empiryczne (46 uczestników) identyfikujące TOP rationales stojące za decyzjami architektonicznymi
- Najczęstsze uzasadnienia decyzji: łatwość użycia dla programisty, utrzymywalność (maintainability), wydajność (performance), wcześniejsza wiedza/doświadczenie, ograniczenia czasowe/deadlines
- Wniosek: decyzje architektoniczne są silnie napędzane czynnikami ludzkimi (doświadczenie, presja czasu), nie tylko technicznymi
Borowa — „Cognitive Biases in Architectural Decision-Making: Impact and Debiasing Strategies" (rozprawa doktorska, PW 2024):
- Zidentyfikowano 11 błędów poznawczych (cognitive biases) wpływających na ADM: efekt ramowania (framing), potwierdzenia (confirmation bias), efekt IKEA, prawo trywialności Parkinsona, zakotwiczenie (anchoring), klątwa wiedzy, pro-innovation bias, planistyczny optymizm, efekt owczego pędu (bandwagon), irracjonalna eskalacja, prawo instrumentu, optymizm
- „Wicked Triad" — zakotwiczenie → potwierdzenie → optymizm: łańcuchowa reakcja prowadząca do źle uzasadnionych decyzji architektonicznych
- Podstawa teoretyczna: Dual Process Theory (Kahneman) — System 1 (szybki, intuicyjny) vs System 2 (wolny, analityczny); biasy wynikają z nadmiernego polegania na System 1
- ADR-y (Architecture Decision Records) mogą częściowo łagodzić biasy, wymuszając jawne zapisanie kontekstu i konsekwencji
- Debiasing: interwencja C-level Fischhoffa — 3 techniki: (1) rozważ wiele opcji, (2) wypisz wady wybranego rozwiązania, (3) wypisz ryzyka
- Eksperyment z 18 praktykami (Polska, Niemcy, Brazylia): statystycznie istotny wzrost kontrargumentów nie-biasowych (p=0.0449)
Borowa, Zalewski — „The influence of cognitive biases on architectural technical debt" (ICSA 2021):
- Zakotwiczenie + optymizm → „Architectural Lock-in" (zamknięcie się w architekturze)
- Confirmation bias → „Re-inventing the wheel" (wymyślanie koła na nowo zamiast reuse)
- Biasy poznawcze są bezpośrednią przyczyną powstawania architektonicznego długu technicznego (ATD)
Szlenk — „Formal Semantics of Architectural Decision Models":
- Formalizacja semantyki modeli decyzji architektonicznych — umożliwia formalne rozumowanie o poprawności i spójności decyzji
- Związek z ADR: formalne podejście do walidacji decyzji architektonicznych
Szlenk — „Modelling architectural decisions under changing requirements":
- Jak zmieniające się wymagania wpływają na decyzje architektoniczne
- Metoda śledzenia wpływu zmian wymagań na podjęte wcześniej decyzje (traceability)