Architektura systemów informatycznych

Na ścianach, tablicach i innych powierzchniach nie jeden raz można zobaczyć kwadraty, prostokąty połączone ze sobą liniami. Obok znajdują się treści co te „kwadraty robią ze sobą”. Tak oto tworzy się architektura. W wielu przypadkach rysunki zostają przykrywane innymi rysunkami i tak idea architektury ginie. Dziś wielu organizacjach myśli się o procesach (i bardzo dobrze) a zapomina się o architekturze systemów ( lub jednej aplikacji). Architektura aplikacji jest dla zespołu tworzącego aplikację tym, czym projekt budynku dla budowniczych. Architektura systemów to jak małe osiedle. Zanim zaprojektujemy osiedle zastanówmy się czym jest architektura

Architektura określa podział oprogramowania na komponenty oraz definiuje funkcje tych komponentów i występujące między nimi relacje. Opis architektury oprogramowania pełni w projekcie rolę schematu jego budowy. Poza zakresem projektu architektury oprogramowania pozostaje określenie sposobu realizacji komponentów, nazywane niekiedy projektowaniem szczegółowym. Opracowanie architektury oprogramowania jest zadaniem twórczym, którego treścią jest definiowanie komponentów, których współdziałanie zapewni realizację wymaganego zachowania systemu.” – K.Sacha Inżynieria oprogramowania.

Architektura systemów jest ważna.  Booch, Rumbaugh, Jacobson w „UML przewodnik użytkownika” nakładają na architekturę dużą odpowiedzialność. Ich zdaniem:

Architektura to zbiór znaczących decyzji dotyczących:

  • organizacji systemu komputerowego
  • wyboru elementów strukturalnych i ich interfejsów, z których system jest zbudowany
  • zachowania tych elementów opisanego w kooperacjach
  • składania elementów strukturalnych i czynnościowych w coraz to większe podsystemy
  • stylu architektonicznego, według którego tworzy się konstrukcję
  • systemu, to znaczy charakterystycznych elementów statycznych i dynamicznych oraz ich interfejsów, kooperacji i składania.

Architektura oprogramowania dotyczy nie tylko jego struktury i zachowania ale także stosowania go, jego funkcjonalności, efektywności, odporności, możliwości ponownego użycia, ograniczeń ekonomicznych i technologicznych oraz estetyki.”

Dla mnie najważniejsze jest to, że architektura jest niewielkim, możliwym do objęcia umysłem modelem struktury systemu i sposobu współdziałania jego elementów. Technicznie bardzo dobrze sprawdzają się UML-owe diagramy komponentów i diagramy sekwencji. Pierwsze odpowiadają za przedstawienie struktury, drugie opisują kooperację komponentów.

Architektura to wysokopoziomowy opis systemu. Z tego też powodu warto by była zbudowana  pojedynczego architekta lub niewielkiego zespołu architektów z ustalonym kierownikiem. Tworząc architekturę architekt (lub zespół architektów) powinien dysponować wymaganiami funkcjonalnymi wobec systemu, a także wyraźnie określonym wykazem oczekiwanych od systemu atrybutów jakościowych (takich jak przykładowo bezpieczeństwo) z przypisanymi priorytetami.

Architektura po utworzeniu, jak każdy artefakt projektowy, powinna być rozesłana do wszystkich udziałowców systemu, którzy powinni być czynnie zaangażowani w jej recenzowanie – weryfikację. Warto przeanalizować ją pod kątem  stosownych miar jakościowych (takich jak przykładowo wydajność) oraz formalnie oceniona pod kątem atrybutów jakościowych, zanim będzie za późno, aby wprowadzać do niej zmiany.

W idealnym świecie architektura systemu powinna być tak podzielona na komponenty by implementacja kilku z nich pozwoliła na uzyskanie minimum funkcji. Dobrze zdefiniowane interfejsy i zakres odpowiedzialności poszczególnych komponentów pozwalają na przyrostowy rozwój systemu. Ułatwia to też testy i retesty.

Wspomniana odpowiedzialność poszczególnych komponentów to taki podział aplikacji by poszczególne komponenty mogły rozwijać się niemal autonomicznie.  Przykładowo komponenty tworzące dane powinny być oddzielone od komponentów używających danych. Komponenty odpowiedzialne za komunikację z otoczeniem powinny być oddzielnie zdefiniowane dla użytkownika oraz oddzielnie dla innych systemów.

Na koniec warto też jest zauważyć, że samo utworzenie architektury systemu to dopiero początek. Warto jest pielęgnować ją, poprzez aktualizację i świadome decyzje architekta, który przy nowych funkcjach lub zmianach identyfikuje komponenty i interfejsy, które powinny zostać zmodyfikowane.

Podobne wpisy

  • AJAX Processing w Rational Software Architect Któż w dzisiejszych czasach nie słyszał o AJAX?ie?  AJAX, łączący w sobie możliwości języków JavaScript i XML, jest świetnym narzędziem do tworzenia interaktywnych witryn […]
  • Z nowym rokiem Z nowym rokiem uzupełniłem kilka wpisów, które były niedokończone a które miały się ukazać w grudniu. Pierwsze dwa tygodnie były dość pracowite dla mnie.  Jedno z zadań z jakiego […]
  • Dokumentacja wymagań oparta na modelu Poza opisem słownym warto jest dokumentować wymagania w oparciu o model. Definicja: Model Model to abstrakcyjna reprezentacja istniejącej rzeczywistości lub rzeczywistości, która będzie […]
  • Niemoralna propozycja Prowadzenie takiego bloga, jak ten daje sprawia mi frajdę, gdyż przy okazji nawiązuję kontakty z ciekawymi ludźmi, z którymi prowadzę w interesującą dyskusję mailową.  Rozmawiamy […]
  • Przypadki użycia ułatwiają określenie celu i zakresu projektu Wiele mówi się o tym co dają przypadki użycia dla wymagań na system. Warto jest tez wiedzieć iż przypadki użycia pozwalają, zwłaszcza w projektach agile, na określenie celu  i zakresu […]
Reklama
MODESTO - licencje Enterprise Architect

Zostaw komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Przewiń do góry