Architektura Systemu

„Architecture starts when you carefully put two bricks together” - Ludwig Mies von der Rohe

Pierwsze definicje architektury systemu

Nie ma jednoznacznej definicji architektury systemu. Zmieniała się ona wielokrotnie na przestrzeni wielu lat ewoluując od pierwszych stosunkowo prostych po dość złożone definicje.

Pierwsze definicje, które udało mi się wyszukać:

  • 1969 – Fred Brooks, Ken Iverson - ”struktura koncepcyjna komputera widziana oczami programisty”

  • 1975 – Fred Brooks, G. Blaauwa - ”pełna i szczegółowa specyfikacja inferfejsu użytkownika”

  • 1982 – Schwanke - ”lista komponentów i połączenia pomiędzy nimi”

  • 1992 – Perry, Wolf – Reguła Perry’ego: Software Architecture = {Elements, Form, Rationale}

  • 1999 – Philippe Kruchten - ”zbiór istotnych decyzji dotyczących organizacji systemu, wyboru elementów strukturalnych, ich kooperacji, składania tych elementów w coraz większe podsystemy, oraz stylu architektonicznego”

Definicja architektury systemu

Aby usystematyzować wszystkie definicje Instytut SEI stworzył ich listę, dzieląc je na kilka grup:

* [nowoczesne](http://www.sei.cmu.edu/architecture/start/moderndefs.cfm) - dotyczące praktycznych problemów architektonicznych


* [klasyczne](http://www.sei.cmu.edu/architecture/start/classicdefs.cfm) - przytoczone w bardziej znaczących książkach i publikacjach naukowych dotyczących architektury systemów


* [bibliograficzne](http://www.sei.cmu.edu/architecture/start/bibliographicdefs.cfm) - przytoczone w mniej znaczących pozycjach


* [społecznościowe](http://www.sei.cmu.edu/architecture/start/community.cfm) - kilkaset definicji zebranych ze stron i serwisów internetowych

Skala ta pokazuje z jak rozmytym pojęciem mamy do czynienia. Wg mnie najlepsza jest definicja architektury wg Bass’a, Clements’a, Kazman’a, autorów książki Software Architecture in Practice

**_”Architektura oprogramowania programu lub systemu informatycznego jest strukturą lub zbiorem struktur tego systemu, obejmującym elementy oprogramowania, widoczne dla pozostałych elementów oprogramowania oraz zależności między nimi”_**

Co to właściwie oznacza?

Powyższa definicja oznacza mniej więcej tyle, że architektura definiuje elementy oprogramowania pomijając charakterystykę ich zachowania, chyba że zachowanie to wpływa na działanie innych wyszczególnionych elementów. Oprócz tego z definicji tej wynika fakt, że pojedynczy system może być przedstawiony z kilku perspektyw (struktur) i o żadnej z nich nie jesteśmy w stanie powiedzieć, że jest architekturą systemu.

Dlaczego architektura jest ważna?

W książce [1] przedstawiono kilka kluczowych powodów, dla których architektura systemu jest bardzo ważna. Nie sposób się z nimi nie zgodzić:

* Jest **platformą komunikacyjną** pomiędzy udziałowcami systemu - umożliwia komunikację pomiędzy programistami, architektami, administratorami czy klientami. Jest także podstawą do negocjacji i wspólnych ustaleń ww grup.


* Przedstawia **wczesne decyzje konstrukcyjne** - narzuca pewne ramy implementacji, umożliwia osiągnięcie określonych w wymaganiach atrybutów jakościowych oraz definiuje organizację zespołu projektowego


* Jest **powtarzalnym modelem** - na jej podstawie mogą być w przyszłości budowane inne architektury, może być także wykorzystywana w szkoleniach przyszłych architektów

Ja ze swojego doświadczenia mogę powiedzieć, że wszystkie te powody nie są wyssane z palca i mają swoje konkretne, praktyczne uzasadnienie.

Bibliografia

  * [1] [Software Architecture in Practice](http://www.sei.cmu.edu/library/abstracts/books/0321154959.cfm)

Comments