Rysunek 2 Model perspektyw architektonicznych “4 + 1”
 

Scenariusze (ang. scenarios) działania systemu opisują funkcjonalności, jakie będzie udostępniał docelowy system w postaci spisu poszczególnych kroków realizowanych w systemie. Scenariusze są o tyle wygodne w zbieraniu wymagań na przyszły system, że na podstawie prostych sekwencji czynności wykonywanych w Systemie, wszystkie osoby, biorące udział w projekcie, mogą prześledzić zachowanie się Systemu. Scenariusze znakomicie zastępują potrzebę tworzenia prototypu systemu, czy modelowanie interfejsu graficznego użytkownika (graficzne przedstawianie formularzy). Innymi słowy scenariusze są opisem funkcji udostępnianych użytkownikowi przez system. Często są również obrazowane w postaci modelu przypadków użycia. Jednocześnie należy zauważyć, że scenariusze opisują jedynie zachowanie systemu jak czarną skrzynkę. Scenariusze nie opisują jak dane akcje użytkownika przetwarzane są przez konkretne elementy (komponenty) wewnętrzne samego systemu, a jedynie opisują reakcję systemu na poszczególne akcje użytkownika. Perspektywa przypadków użycia opisywana jest przede wszystkim za pomocą modelu przypadków użycia, które to przypadki użycia wizualizują hierarchię i powiązania poszczególnych scenariuszy. Scenariusze zaś, oprócz stosownych sekwencji czynności, wzbogaca się często o dodatkowe informacje zbierane w trakcie ich opisywania (np. aktorzy, stan początkowy, końcowy, zakres przetwarzanych danych, reguły biznesowe itp.). Początkowo scenariusze służą poznaniu możliwości systemu i projektowania jego architektury (biznesowe przypadki użycia), ale w kolejnych iteracjach używane są do sprawdzania i kontroli poprawności pozostałych perspektyw (systemowe przypadki użycia), a także ich uszczegóławiania. Zatem perspektywa przypadków użycia może się składać z dwóch części: poziomu biznesowego (biznesowe przypadki użycia) oraz systemowego (systemowe przypadki użycia). W trakcie opisywania perspektywy przypadków użycia tworzone są również pozostałe perspektywy na podstawie informacji zbieranych w trakcie opisywania scenariuszy. 

Perspektywa logiczna (ang. logical view, również design view) przeznaczona jest przede wszystkim do modelowania wymagań funkcjonalnych docelowego systemu (udostępniane przez system funkcje, czy usługi). Najczęściej perspektywa ta opisywana jest za pomocą modelu klas (ewentualnie obiektów) oraz za pomocą modelu stanów dla najważniejszych klas (obiektów). Jednocześnie perspektywa logiczna zawiera opis realizacji przypadków użycia w formie diagramów aktywności, bądź sekwencji. Perspektywa logiczna może się składać z dwóch części: poziomu biznesowego (obiekty biznesowe oraz realizacje biznesowych przypadków użycia) oraz systemowego (obiekty analityczne oraz realizacje systemowych przypadków użycia). Perspektywa logiczna tworzona jest w trakcie opisywania perspektywy przypadków użycia. Na podstawie perspektywy logicznej powinna być opisana perspektywa implementacyjna (organizacja komponentów programistycznych). Modele perspektywy logicznej opisywane są przez analityków na podstawie wymagań użytkowników zbieranych w trakcie budowy scenariuszy.

W perspektywie procesowej (ang. process view) bierze się pod uwagę pozafunkcjonalne wymagania na docelowy system takie jak wydajność, czy dostępność. Odpowiednie oszacowanie tych wymagań realizuje się poprzez zamodelowanie współbieżności i rozproszenia elementów systemu, a także jego integralność, czy odporność na awarie. Innymi słowy w perspektywie procesowej modeluje się pewne aspekty docelowego systemu związane ze współbieżnością, czy wydajnością (m.in. synchronizacja, replikacja, podnoszeniem systemu, zatrzymywanie systemu, tworzenie kopii zapasowych itd.) pomiędzy głównymi obiektami (zidentyfikowanymi w perspektywie logicznej). Przy czym perspektywa ta może być podzielona na warstwy poczynając od warstwy abstrakcyjnej, uwzględniającej przede wszystkim obiekty zidentyfikowane w perspektywie logicznej, a kończąc na warstwie związanej z modelowaniem użycia procesorów na poszczególnych maszynach. Modelowanie tych aspektów projektowanego systemu zazwyczaj mocno wpływa na rozwiązania przedstawiane w perspektywie fizycznej (wdrożeniowej). W większości projektów informatycznych w związanych z nowoczesnymi technologiami programistycznymi nie ma potrzeby rozważania niższych warstw perspektywy procesowej, aniżeli warstwa najwyższa (abstrakcyjna), gdyż wszystkie niższe warstwy zostały już wcześniej zaprojektowane, zrealizowane i dostarczone wraz z całym środowiskiem programistycznym. Jednakże dla celów poglądowych perspektywę tą można opisywać za pomocą diagramów sekwencji, a także diagramów komunikacji. Czasami wygodnie opisywać pewne aspekty związane z wymaganiami pozafunkcjonalnymi za pomocą diagramu komponentów, zwłaszcza, gdy perspektywę procesową opisuje się wraz z perspektywą fizyczną (wdrożeniową). Modele perspektywy procesowej opisywane są przez integratorów systemu.

Perspektywa implementacyjna (ang. implementation view, też development view) opisuje podział oprogramowania na podsystemy, moduły, pakiety, biblioteki i inne fragmenty, w których znajduje się kod źródłowy. Perspektywa ta może być podzielona na wiele warstw (np. warstwy związane ze specyfiką docelowego systemu, jak i warstwy specyficzne dla użytej platformy) takie jak sposób kompilacji poszczególnych jednostek programistycznych, współpraca w rozproszonym środowisku (np. interfejsy pobierające dane, interfejsy udostępniające dane), współpraca z systemami zewnętrznymi, czy też obsługa interfejsów graficznych dla użytkowników, współpraca elementów programistycznych itp. Najczęściej perspektywę implementacyjną opisuje się za pomocą diagramu komponentów, które udostępniają, bądź pobierają określone usługi, a także wskazują wykorzystywane biblioteki, czy inne zasoby programistyczne. Zidentyfikowane komponenty w perspektywie implementacyjnej używane są w perspektywie wdrożeniowej do pokazania rozmieszczenia tych komponentów w poszczególnych węzłach, hostach, czy serwerach środowiska działania systemu. Dla projektów realizowanych w nowoczesnych środowiskach programistycznych perspektywa implementacyjna jest już zaprojektowana i ustalona, natomiast zasadniczą pracę programistyczną realizuje się poprzez modyfikacje istniejącego kodu źródłowego poszczególnych pakietów, a także poprzez konfigurację i parametryzowanie określonych elementów danej platformy programistycznej. Modele perspektywy implementacyjnej opisywane są przez programistów.

Perspektywa fizyczna (ang. physical view, też deployment view) opisuje fizyczną konfigurację oprogramowania oraz sprzętu w środowisku, w którym pracuje docelowy system (również powinne być opisane środowisko testowe, czy też środowisko związane z rozwojem oprogramowania) z uwzględnieniem zastosowanych platform systemowych oraz węzłów sieci. Perspektywa ta opisuje pozafunkcjonalne wymagania systemu takie jak dostępność, odporność na awarie, wydajność, a także skalowalność. Z tego względu perspektywa wdrożeniowa powinna w odpowiedni sposób pokazać rozmieszczenie różnych elementów zdefiniowanych zarówno w perspektywie procesowej jak i w perspektywie implementacyjnej. Te elementy z odpowiednich perspektyw powinny być tak zaprojektowane, by planowanie ich rozmieszczenia nie miało zbytniego wpływu na kod źródłowy jednostek programistycznych. Najczęściej perspektywę wdrożeniową opisuje się za pomocą modelu wdrożenia, gdzie pokazane są odpowiednie hosty, czy serwery, na których wdrożono stosowne komponenty, które z kolei wymieniają odpowiednie dane ze sobą za pomocą odpowiednich usług, czy protokołów. Perspektywę wdrożeniową opisuje się za pomocą diagramów wdrożenia (UML) jak też za pomocą diagramów wykorzystujących piktogramy reprezentujące poszczególne elementy infrastruktury IT (np. wzorniki Microsoft Visio). Modele perspektywy wdrożeniowej opisywane są przez inżynierów systemowych.

Nie wszystkie opisy architektur wymagają stosowania wszystkich, wymienionych wyżej perspektyw. Przykładowo dla bardzo małych projektów można opisać jedynie perspektywę logiczną (bądź tylko implementacyjną) bez potrzeby opisywania fizycznej, czy procesowej (np. aplikacje tworzone w Eclipse dla jednego użytkownika). Natomiast scenariusze są użyteczne dla wszystkich rodzajów projektów. Dlatego też model perspektyw architektonicznych zalicza się do rozwiązań opartych na scenariuszach (przypadkach użycia). Rozwiązania takie uwzględniają iteracyjny proces zbierania wymagań w formie scenariuszy (przypadków użycia). Poniżej przedstawiono schemat tworzenia opisu architektury docelowego systemu.

-        wybór najważniejszych scenariuszy

-        na podstawie zidentyfikowanych klas, mechanizmów, procesów, podsystemów utworzenie szkicu pozostałych czterech perspektyw

-        przegląd zaprojektowanej architektury (również implementacja prototypu i jego przetestowanie)

-        wyciągnięcie wniosków na przyszłość

-        zrewidowanie ryzyk

-        rozszerzenie listy scenariuszy

-        wybranie kilku scenariuszy zezwalających na ograniczenie ryzyka, bądź mających duży wpływ na zwiększenie zawartości architektury

-        identyfikacja dodatkowych elementów architektury i aktualizacja pozostałych 4 perspektyw

-        zrewidowanie pozostałych scenariuszy

-        aktualizacja prototypu, testowanie, pomiary działania systemu

-        przegląd wszystkich pięciu perspektyw pod kątem ich uproszczenia (ponowne użycie poszczególnych elementów, identyfikacja wspólnych elementów itd.)

-        aktualizacja założeń projektowych i uzasadnień decyzji projektowych

-        wyciągnięcie wniosków na przyszłość

Powyższy proces iteracyjny jest dość ogólny i praktycznie dla projektów wykorzystujących nowoczesne platformy programistyczne nie będzie miał zbyt dużego zastosowania. Jednakże należy zwrócić uwagę na kolejność prac nad architekturą systemu, gdzie wskazuje się, że na podstawie opisywanych scenariuszy identyfikuje się główne elementy pozostałych czterech perspektyw, stąd rozwiązanie powyższe nazywa się rozwiązaniem iteracyjnym (ang. iterative development process) opartym na scenariuszach (ang. scenario-driven). Główną zaś korzyścią stosowania przedstawionego rozwiązania jest opis odpowiedniego „mapowania” elementów z poszczególnych perspektyw tak, by można było określić moment zakończenia prac w poszczególnych etapach tworzenia opisu architektury. Wspomniane „mapowanie” jest bardzo mocno zależne od zastosowanej platformy programistycznej a opracowywane jest w kolejnych projektach informatycznych w oparciu o wiedzę i doświadczenie poszczególnych osób biorących udział w tego typu projektach. W dalszej części dokumentu zaproponowano ogólną metodę opisującą „mapowanie (odwzorowanie) elementów z poszczególnych perspektyw pomocną przy tworzeniu kompletnego i spójnego opisu architektury.