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.

Zostaw odpowiedź

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

Możesz użyć tych HTML tagów i atrybutów: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Chcę otrzymywać powiadomienia o nowych wpisach na tym blogu

Wyrażam zgodę na przetwarzanie powyższych danych. Potwierdzam zapisanie się na newsletter w celu otrzymywania powiadomień o nowych wpisach. (Mogę wypisać się w dowolnym momencie)

FreshMail.pl
 
Close