Projektowanie systemów informatycznych jest ważną częścią każdego procesu budowy oprogramowania systemów IT. Od niego zależy kształt i działanie tworzonego systemu informatycznego. Dlatego warto uzmysłowić sobie fakt, że niezależnie od przyjętego modelu tworzenia oprogramowania (zwinne/agile lub kaskadowego/waterfall) istnieje potrzeba a nawet bezwzględnie należy poświęcić odpowiednie środki i czas aby projekt systemu był odpowiednio opracowany i udokumentowany. Dzięki temu będziemy pewni, że nasz system – jego oprogramowanie będzie posiadało solidną architekturę, która nie runie jak domek z kart pod naporem problemów i błędów działania.

Jakie są podstawy projektowania oprogramowania?

Celem procesu analizy i projektowania jest:

• przekształcenie wymagań w projekt przyszłego systemu,
• opracowanie solidnej architektury systemu,
• dostosowanie projektu do środowiska wdrożeniowego ze szczególnym uwzględnieniem wydajności działania.

Warto również zaznaczyć, że jakość opracowanych i zebranych wymagań jakie stawiamy przed systemem IT ma bardzo duży wpływ na wyniki projektu a w konsekwencji na kształt budowanego systemu. Dlatego nadanie odpowiedniej struktury stawianym wymaganiom pomaga w projektowaniu systemów.

Przeczytaj też: Specyfikacja Wymagań Projektu Informatycznego – Jak Napisać Ją Prawidłowo?

W jaki sposób przedstawiana jest projektowana architektura?

Aby mówić i myśleć na temat architektury oprogramowania, należy najpierw zdefiniować reprezentację architektoniczną, sposób opisu ważnych aspektów architektury. Opis ten zazwyczaj znajduje się w dokumencie architektury oprogramowania (Software Architecture Document).

Widoki architektoniczne

Architektura oprogramowania przedstawiana jest często w postaci wielu widoków architektonicznych. Każdy widok architektoniczny odnosi się do określonego zestawu problemów, specyficznych dla interesariuszy w procesie rozwoju oprogramowania: użytkowników końcowych, projektantów, menedżerów, inżynierów systemowych, wdrożeniowców itd.

Widoki wychwytują najważniejsze decyzje projektowe dotyczące konstrukcji, pokazując, w jaki sposób architektura oprogramowania jest rozłożona na komponenty oraz w jaki sposób komponenty te są ze sobą połączone. Oczywiście te wybory projektowe muszą być powiązane z wymaganiami, ograniczeniami funkcjonalnymi i niefunkcjonalnymi oraz innymi ograniczeniami. Te wybory z kolei nakładają dalsze ograniczenia na wymagania i przyszłe decyzje projektowe na niższym poziomie.

Typowy zestaw widoków architektonicznych

Jednym z możliwych do przedstawienia elementów architektury systemów IT jest  zestawów widoków zwany „modelami widoku 4+1”.

Modele ten składa się z następujących widoków:

• widoku przypadków użycia –  zawiera przypadki użycia i scenariusze, które obejmują ważne architektonicznie zachowania, klasy lub ryzyka techniczne,
• widok logiczny, który zawiera najważniejsze klasy projektowe i ich organizację w pakiety i podsystemy oraz organizację tych pakietów i podsystemów w warstwy. Zawiera również niektóre realizacje przypadków użycia,
• widok implementacji – zawiera przegląd modelu implementacji i jego organizacji pod względem modułów w pakiety i warstwy systemu. Również powiązanie pakietów i klas (z Widoku logicznego) do pakietów i modułów Widoku implementacji,
• widok procesu – zawiera opis zadań (procesu i wątków), ich interakcje i konfiguracje oraz przypisanie obiektów i klas projektowych do zadań. Tego widoku należy używać tylko wtedy, gdy system ma znaczny stopień współbieżności,
• widok wdrażania – zawiera opis różnych węzłów fizycznych dla najbardziej typowych konfiguracji platformy oraz przydział zadań (z widoku procesu) do węzłów fizycznych.

Widoki architektoniczne są udokumentowane w dokumencie architektury oprogramowania. W razie potrzeby w dokumentacji projektowej umieszcza się dodatkowe widoki, aby przedstawić inne aspekty architektury: widok interfejsu użytkownika, widok bezpieczeństwa, widok danych i tak dalej. W przypadku prostych systemów można pominąć niektóre widoki zawarte w modelu widoku 4 + 1.

Główne elementy architektury

Chociaż powyższe widoki mogą przedstawiać cały projekt systemu, architektura systemów zajmuje się tylko niektórymi konkretnymi aspektami:

• struktura modelu – wzorce organizacyjne, na przykład warstwy,
• podstawowe elementy – krytyczne przypadki użycia, główne klasy, wspólne mechanizmy,
• kilka kluczowych scenariuszy przedstawiających główne przepływy sterowania w całym systemie,
• usługi, aby uchwycić modułowość, opcjonalne funkcje, aspekty linii produktów.

W istocie widoki architektoniczne to abstrakcje lub uproszczenia całego projektu, w którym ważne cechy są lepiej widoczne, pozostawiając szczegóły na boku. Te cechy są ważne podczas:

• ewolucji systemu – przejście do następnego cyklu rozwoju,
• ponowne wykorzystanie architektury lub jej części w kontekście rozwoju linii produktów,
• ocena dodatkowych cech, takich jak wydajność, dostępność, przenośność i bezpieczeństwo,
• przydzielanie prac rozwojowych do zespołów lub podwykonawców,
• decyzje o włączeniu gotowych komponentów,
• osadzanie w większym systemie.

Wzorce architektoniczne

Podczas budowy architektury systemu wykorzystuje się tzw. wzorce architektoniczne. To gotowe elementy rozwiązujące powtarzające się problemy architektoniczne. Szkielet architektoniczny lub infrastruktura architektoniczna (middleware) to zestaw komponentów, na których można zbudować określony rodzaj architektury.  Wiele z głównych problemów architektonicznych powinno zostać rozwiązanych dzięki zastosowaniu odpowiednich wzorców architektonicznych.

Plany architektoniczne

Graficzne przedstawienie widoku architektonicznego nazywa się planem architektonicznym. Dla różnych widoków opisanych powyżej plany składają się z następujących diagramów z języka Unified Modeling Language:

• widok logiczny – diagramy klas, diagramy stanu i diagramy obiektów,
• widok procesu – diagramy klas i diagramy obiektów (obejmujące zadania – procesy i wątki),
• widok implementacji – schematy komponentów,
• widok wdrożenia – diagramy rozmieszczenia,
• widok przypadków użycia – diagramy przypadków użycia przedstawiające przypadki użycia, aktorów i zwykłe klasy projektowe; diagramy sekwencji przedstawiające obiekty projektowe i ich współpracę.

Proces analizy i projektowania

W fazie początkowej analiza i projektowanie skupia się na ustaleniu, czy system zgodnie z przewidywaniami jest wykonalny oraz oceny potencjalnych rozwiązań technologicznych (Perform Architectural Synthesis). Jeśli wydaje się, że rozwój wiąże się z niewielkim ryzykiem (ponieważ na przykład domena jest dobrze zrozumiana, system nie jest nowy itd.), ten szczegół przepływu pracy można pominąć.

Wczesna faza opracowywania skupia się na stworzeniu początkowej architektury systemu, aby zapewnić punkt wyjścia do głównych prac analitycznych. Jeśli architektura już istnieje (ponieważ została wyprodukowana w poprzednich iteracjach lub w poprzednich projektach), skupia się na udoskonaleniu architektury (Refine the Architecture), analizie zachowania i tworzeniu wstępnego zestawu elementów zapewniających odpowiednie zachowanie systemu (Analyze Behavior).

Po zidentyfikowaniu początkowych elementów są one dalej udoskonalane. Komponenty projektowe tworzą zestaw komponentów, które zapewniają odpowiednie zachowanie, aby spełnić wymagania systemu. Równolegle z tymi działaniami problemy z trwałością są rozwiązywane w programie Projektowanie bazy danych. Rezultatem jest początkowy zestaw komponentów, które są w dalszej kolejności rozwijane w fazie implementacji.

Prototyp architektury

Prototypy są używane w sposób ukierunkowany, aby zmniejszyć ryzyko. Prototypy mogą zmniejszyć niepewność co do:

• rentowności opracowywanego produktu,
• stabilności lub wydajność kluczowej technologii,
• zaangażowania lub finansowanie projektu,
• zrozumienia wymagań,
• wyglądu i działanie produktu oraz jego użyteczności.

Prototyp może pomóc w budowaniu wsparcia dla produktu, pokazując użytkownikom, klientom i menedżerom coś konkretnego i wykonalnego.

Charakter i cel prototypu muszą jednak pozostać jasne przez cały okres jego użytkowania. Z reguły nie można zakładać, że skoro prototyp działa, powinien on stać się produktem końcowym. Przykładowo eksploracyjny, behawioralny prototyp, mający na celu bardzo szybkie wypróbowanie interfejsu użytkownika, rzadko przekształca się w silny, odporny produkt.

Możesz patrzeć na prototypy na dwa sposoby: co badają; i jak ewoluują lub jaki jest ich wynik.

W kontekście pierwszego widoku – tego, co badają – istnieją dwa główne rodzaje prototypów:

• prototyp behawioralny, który koncentruje się na badaniu określonego zachowania systemu,
• prototyp strukturalny, który bada pewne problemy architektoniczne lub technologiczne.

W kontekście drugiego spojrzenia – ich wyniku – istnieją również dwa rodzaje prototypów:

• prototyp badawczy, który nie jest bezpośrednio wykorzystywany do budowy rzeczywistego systemu,
• ewolucyjny prototyp, który stopniowo ewoluuje, aby stać się prawdziwym systemem.

Analiza architektoniczna

Analiza architektoniczna skupia się na zdefiniowaniu potencjalnej architektury i ograniczeniu technik architektonicznych, które mają być użyte w systemie. Polega na gromadzeniu doświadczeń zdobytych w podobnych systemach lub dziedzinach problemowych, tak aby wysiłek nie został zmarnowany na „ponowne odkrywanie architektury”. W systemach, w których istnieje już dobrze zdefiniowana architektura, pomija się ten etap. Analiza architektoniczna przynosi korzyści przede wszystkim podczas opracowywania nowych i innowacyjnych systemów.

Analiza zachowania systemu

Celem tego etapu jest przekształcenie opisów behawioralnych dostarczone przez przypadki użycia zdefiniowane na etapie zbierania wymagań w zestaw elementów, na których można oprzeć projekt systemu.

Projektowanie komponentów systemu

Projekt przypadków użycia

Ten etap procesu analizy i projektowania systemów skupia się na następujących aspektach:

• projekt realizacji przypadków użycia pod względem interakcji,
• projekt wymagań dotyczących działania klas projektowych,
• realizacja wymagań dotyczących działania podsystemów i / lub ich interfejsów.

Zachowanie systemu można opisać i udokumentować za pomocą wielu technik i metod – współpracy lub interakcji. Ta aktywność opisuje użycie interakcji, w szczególności diagramów sekwencji, do opisania zachowania systemu. Diagramy sekwencji są najbardziej przydatne, gdy zachowanie systemu lub podsystemu można przede wszystkim opisać za pomocą synchronicznej wymiany komunikatów. Asynchroniczne przesyłanie wiadomości, zwłaszcza w systemach sterowanych zdarzeniami, jest często łatwiejsze do opisania w kategoriach automatów stanu i współpracy, co pozwala na zwarty sposób definiowania możliwych interakcji między obiektami.

Projekt klas

Ten etap projektu systemu skupia się na tym aby:

• projektowane elementy systemu (klasy) zapewniały zachowanie wymagane przez realizacje przypadków użycia,
• ustalić wystarczające informacje do jednoznacznego zaimplementowania klas w późniejszych etapach budowy systemu,
• obsługa niefunkcjonalnych wymagań związanych z klasą,
• uwzględnienie mechanizmów projektowania używanych przez klasę.

Klasy są podstawowym elementem budowy systemów i odzwierciedlają prawdziwą pracę systemu. Pozostałe elementy projektu – podsystemy, pakiety i współpraca opisują po prostu sposób grupowania klas lub ich współdziałania.

Projekt podsystemu

Celem tego etapu są następujące działania projektowe:

• zdefiniowanie zachowań określonych w interfejsach podsystemu w zakresie współpracy w zawartych pomiędzy nimi klasami,
• udokumentowanie wewnętrznej struktury podsystemu,
• definiowanie realizacji między interfejsami podsystemu a zawartymi w nim klasami,
• określenie zależności od innych podsystemów.

Projektowanie bazy danych

W tym etapie projektu skupia się na następujących pracach projektowych:

• identyfikacja “trwałych” klasy (danych) w projekcie,
• projektowanie odpowiednich struktur bazy danych do przechowywania danych,
• określanie mechanizmów i strategii przechowywania i wyszukiwania danych w taki sposób, aby spełnione były kryteria wydajności systemu.

Rezultatem powyższych działań jest utworzenie modelu danych. Model danych służy do opisu logicznej i możliwie fizycznej struktury trwałych informacji zarządzanych przez system. Model danych jest szczególnie potrzebny, gdy trwała struktura danych nie może być automatycznie wyprowadzona ze struktury trwałych klas w modelu projektowym. Służy do definiowania mapowania między trwałymi klasami projektowymi a trwałymi strukturami danych oraz do definiowania samych trwałych struktur danych. Jest to najczęściej potrzebne, gdy model projektowy jest modelem obiektowym, a mechanizm trwałego przechowywania jest oparty na relacyjnej bazie danych.

Projektowanie systemów informatycznych jest ważne

Nie można przecenić wartości jaką niesie dobry projekt systemu informatycznego. Jak widać faza projektowania jest bardzo istotnym i ważnym etapem a jednocześnie trudnym i skomplikowanym procesem. Dlatego należy docenić pracę i doświadczenie zespołów projektowych firmy. Udokumentowanie tego etapu realizacji budowy systemu IT to dobre podejście i daje możliwość sprawnej wymiany informacji pomiędzy członkami zespołu projektowego oraz klienta końcowego. Dobry projekt daje duże gwarancje sprawnego działania realizowanych systemów. To z kolei przekłada się na satysfakcję naszych klientów.