Architektura oprogramowania

W latach 1968–1969 odbyły się dwie znaczące konferencje sponsorowane przez NATO^[5][6], gdzie dyskutowano o roli i znaczeniu informatyki (ang. computer science) oraz inżynierii oprogramowania (ang. software engineering). W szczególności dyskusje uczestników dotyczyły braku związków pomiędzy informatyką (jako nauką zorientowaną na teorie), a inżynierią oprogramowania (jako nauką zorientowaną na praktykę). Jedną z ciekawych propozycji wypełnienia tej luki i wyjścia z ówczesnego „kryzysu w wytwarzaniu oprogramowania” (ang. software crisis) była koncepcja Iana Sharpa dotycząca modelowania systemów oprogramowania w postaci tzw. architektury oprogramowania. Od tego czasu architektura oprogramowania zaczęła mieć coraz większe znaczenie w projektach systemów informatycznych przyjmując wpierw kierunek rozwoju zakreślony znanym równaniem Perry’ego i Wolfa (Software Architecture = {Elements, Form, Rationale}), po czym przyoblekając się w style wyspecyfikowane przez D. Garlana i M. Shaw, a następnie osiągając stabilność w postulowanym przez Philippe Kruchtena modelu perspektyw architektonicznych 4+1. Obecnie zaś architektura oprogramowania przybrała formę modelu koncepcyjnego opisu architektury jako standard SEI i zdaje się dążyć w kierunku rozwiązań Model Driven Architecture (MDA).

Peter J. Denning w swoim artykule o Informatyce^[7] zaproponował podział tej dziedziny nauki stawiając architekturę oprogramowania na podobnym poziomie co takie obszary jak:

• algorytmy i struktury danych,
• języki oprogramowania,
• architektura komputerów i oprogramowania,
• systemy operacyjne i sieci,
• inżynieria oprogramowania,
• bazy danych i wyszukiwanie informacji,
• sztuczna inteligencja i robotyka,
• grafika komputerowa,
• interakcja człowiek–komputer,
• symulacje komputerowe i obliczenia numeryczne
• informatyka ekonomiczna,
• bioinformatyka.

Jednocześnie dla każdego z tych obszarów zaproponował podział na trzy zakresy (procesy) dotyczące strony teoretycznej, abstrakcyjnej (eksperymentalnej) oraz strony praktycznej. Z kolei Ian Sommerville widzi informatykę i inżynierię oprogramowania jako dwie oddzielne dyscypliny (informatyka zorientowana na teorie, inżynieria oprogramowania zorientowana na praktykę), natomiast architekturę oprogramowania określa jako wynik procesu zdefiniowanego wewnątrz inżynierii oprogramowania^[8]. Podobnie uważają Bass, Clements i Kazman^[9] twierdząc wręcz, że architektura wyłoniła się jako zasadnicza część procesu projektowania systemów informatycznych. Ponadto istnieją źródła, które umiejscawiają architekturę oprogramowania jako dział inżynierii oprogramowania.

Jedną z pierwszych definicji podali Brookes i Iverson^[10] w 1969 roku: „architektura to pojęciowa struktura komputera w postaci widzianej przez programistę”. Jednakże kilka lat później Fred Brookes zrewidował tę definicję twierdząc, że architektura to „pełne i szczegółowe przedstawienie interfejsu użytkownika. (…) Podczas gdy architektura mówi nam, co się dzieje, implementacja mówi, jak to się ma dziać”^[11]. Należy przy tym zauważyć, że Brooks odróżnia architekturę oprogramowania od implementacji systemu informatycznego, co często ma miejsce i w obecnych czasach.

Definicję architektury jako pewnej abstrakcji systemu informatycznego podał Schwanke w 1989 roku twierdząc, że „struktura oprogramowania to lista komponentów i połączenia pomiędzy nimi”^[12]. Definicja ta została wzbogacona przez Perry’ego i Wolfa o ograniczenia i interakcje pomiędzy komponentami w roku 1992: „Architektura opisuje wybrane elementy architektoniczne, połączenia między nimi oraz ograniczenia tych elementów architektonicznych i ich wzajemnych związków niezbędnych do zdefiniowania modelu spełniającego wymagania i będącego podstawą dla projektu systemu informatycznego”, aczkolwiek o wiele bardziej popularna jest formuła Perry’ego: Software Architecture = {Elements, Form, Rationale}.

Z kolei Garlan i Shaw skłaniają się do bardziej uproszczonej definicji w swoim artykule ogłoszonym rok później^[13]: “Architektura oprogramowania danego systemu można traktować jako kolekcję komponentów obliczeniowych – lub prościej komponentów – wraz z opisem interakcji pomiędzy tymi komponentami”. Przełomową definicję architektury oprogramowania podał Philippe Kruchten w 1995 roku, która to definicja uwzględniała abstrakcję architektury oraz potrzebę spełnianie pewnych wymagań w stosunku do projektowanego systemu informatycznego^[14]: “Architektura oprogramowania dotyczy projektu i implementacji w aspekcie przedstawiania struktury oprogramowania na ich wysokim poziomie abstrakcji. Jest rezultatem łączenia pewnej liczby elementów architektonicznych w pewną odpowiednio dobraną formę tak, by spełnić główne funkcjonalności oraz wymagania wydajności takie jak skalowalność i dostępność. Architektura związana jest z abstrakcją, dekompozycją i ponowną kompozycją, stylem i estetyką systemu informatycznego.”. A więc architektura oprogramowania to nie tylko opis połączonych ze sobą komponentów, ale też i całe spectrum zagadnień związanych z budową oprogramowania. Definicję tę Kruchten podparł modelem perspektyw architektonicznych 4+1, a następnie rozwinął dla potrzeb metodyki RUP w 1999 roku^[15]: „Architektura to zbiór istotnych decyzji dotyczących:

• organizacji systemu oprogramowania;
• wyboru elementów strukturalnych i ich interfejsów, z których system jest zbudowany, razem z ich zachowaniami wyspecyfikowanymi w ich kooperacjach;
• składania tych elementów w coraz większe podsystemy;
• stylu architektonicznego, według którego tworzy się konstrukcję systemu, to znaczy charakterystyczne elementy i ich interfejsy, od którego zależy kooperacja i składanie.

Natomiast Bass, Clements i Kazman podali bardziej zwartą definicję architektury oprogramowania w 2003 roku: “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.”. Przy czym w tej definicji termin struktura jest zbieżny z perspektywą. Między innymi na wspomnianej wyżej definicji oparli się autorzy standardu ISO/IEC 42010:2007 wprowadzając następującą definicję: „Architektura systemu informatycznego jest to podstawowa organizacja systemu wraz z jego komponentami, wzajemnymi powiązaniami, środowiskiem pracy i regułami ustanawiającymi sposób jej budowy i rozwoju.”. Więcej definicji architektury oprogramowania można przestudiować na stronie Instytutu Inżynierii Oprogramowania SEI, zwłaszcza, że od dłuższego czasu SEI postanowiło rejestrować różnorodne definicje architektury oprogramowania.

W celu poprawnego zbudowania systemu informatycznego należy wpierw stworzyć jego plan, czy inaczej abstrakcyjny model^[16]. Taki model umożliwia wspólne prace nad docelowym systemem wszystkim zainteresowanym osobom biorącym udział w projekcie poprzez utworzenie odpowiedniego wyobrażenia docelowego systemu, bądź jego części. Wynika stąd, że model projektowanego systemu informatycznego jest podstawowym elementem architektury oprogramowania.Koncepcje opisu architektury oprogramowania:

• siatka Zachmana
• Software Architecture = {Elements, Form, Rationale – koncepcja Perry’ego i Wolfa^[17]
• Style architektoniczne – koncepcja Mary Shaw i Davida Garlana
• wzorce architektoniczne^[18]
• wzorce GoF
• Model perspektyw architektonicznych 4+1
• ISO/IEC 42010 – standard opisu architektury (IEEE Std 1471-2000)
• Model Driven Architecture – architektura sterowana modelem
• Model 4 perspektyw Siemensa^[19].

Istnieją też i inne koncepcje opisu architektury jak RM-ODP, TOGAF, DODAF, ARIS.

Zbieranie wymagań na system informatyczny może odbywać się na wiele sposobów i dotyczyć np. tylko wybranych aspektów opisu docelowego systemu. Częstym sposobem opisu takich wymagań jest opis tekstowy docelowego systemu. Jednakże w większości projektów zaleca się stosowanie do opisu projektowanego systemu takiego opisu architektury, który umożliwiałby pokazanie uzasadnionego ciągu powiązanych modeli od momentu zbierania wymagań, aż po zakres wdrożenia systemu.
Metodyki budowy systemów informatycznych:

• Active Design Review – ADR^[20]
• Software Architecture Analysis Method – SAAM^[21]
• Architecture Tradeoff Analysis Method – ATAM^[22]
• Active Reviews for Intermediate Designs – ARID^[23]
• Cost Benefis Analysis Method – CBAM^[24]
• Quality Attribute Workshops – QAW^[25]
• Attribute-Driven Design – ADD
• Rational Unified Process – RUP

Wiele metod i technik projektowania, analizy, czy szacowania architektury oprogramowania opracowano przez Software Engineering Institute i przedstawiono na stronie internetowej organizacji^[26].

Język opisu architektury oprogramowania (ang. Architecture Description Language – ADL) z jednej strony musi posiadać prostą, zrozumiałą i możliwie graficzną notację, bez zbyt rozbudowanej semantyki, co pozwoliłoby wizualizować, a jednocześnie zwiększałoby zrozumiałość architektury, a także możliwe byłoby przeprowadzanie prostych analiz architektury oprogramowania. Z drugiej zaś strony ADL powinien posiadać odpowiednie reguły syntaktyczne i semantyczne, co umożliwiłoby przeprowadzanie przeróżnych skomplikowanych analiz, weryfikacji modeli, parsowania, kompilowania i generowania kodu wspomagając budowę systemów informatycznych^[27].

Języki opisu architektury:

• Unified Modeling Language – UML
• Architecture Analysis & Design Language – AADL^[28]
• Architecture Description Interchange Language – ACME^[29]

Istnieją również inne języki opisu architektury oprogramowania jak xADL, Koala, Wright, Darwin.