W tekście Specyfikacja wymagań na system opowiedziałem o przygotowaniu specyfikacji systemu. W tym modelu przybliżę fazę analizy i projektowania, która skończy się przygotowaniem projektu systemu.
Wprowadzenie
Po fazie określenia i specyfikacji wymagań następuje faza analizy i projektowania, która kończy się przygotowaniem projektu systemu. To kluczowy etap, w którym wymagania biznesowe i systemowe przekształcane są w konkretne modele i struktury, stanowiące podstawę do implementacji. W niniejszym tekście przedstawimy kompleksowe podejście do tej fazy, rozszerzając wcześniejsze informacje o specyfikacji wymagań.
Zasady modelowania analizy
Przed przystąpieniem do prac nad każdym niebanalnym systemem, warto zapoznać się z czterema głównymi zasadami modelowania, które określają najważniejsze kwestie związane z projektowaniem i których znajomość znacząco ułatwi ten proces.
Zasada pierwsza: Dobór modelu ma istotny wpływ na końcowy produkt
Oznacza ona, że projektant powinien dokładnie przemyśleć, jakie modele będą potrzebne przy pracach nad systemem. Jeśli będą dobrze dobrane, można będzie poradzić sobie nawet z najtrudniejszymi i najbardziej złożonymi problemami.
Należy pamiętać, że różne sposoby postrzegania problemu mogą prowadzić do odmiennych rozwiązań systemu, a co za tym idzie – do różnych kosztów implementacji i różnych korzyści biznesowych. Wybór odpowiedniego podejścia modelowego na wczesnym etapie może zaoszczędzić wiele pracy i problemów w późniejszych fazach projektu.
Zasada druga: Każdy model można przedstawić na różnym poziomie szczegółowości
Ustalenie odpowiedniego poziomu szczegółowości zależy od tego, dla jakiego celu budujemy model. Dla przykładu:
- Model analityczny koncentruje się na tym, co ma powstać
- Model projektowy skupia się na tym, jak to zrobić
Każdy z nich będzie przedstawiać system na innym poziomie szczegółowości. Zbyt duża szczegółowość na wczesnych etapach może prowadzić do przedwczesnych decyzji implementacyjnych, natomiast zbyt mała szczegółowość na późniejszych etapach może nie dostarczyć programistom wystarczających informacji do implementacji.
Zasada trzecia: Model powinien być zgodny z rzeczywistością, choć stanowi jej uproszczenie
Należy stosować modele powiązane z rzeczywistością, a w przypadku gdy powiązanie to jest słabe, należy zdawać sobie sprawę ze stopnia rozbieżności. Każdy model upraszcza rzeczywistość – to jego istota. Najważniejsze jest jednak, żeby mieć pewność, że uproszczenie nie dotyczy istoty rzeczy i nie zmienia fundamentalnie obrazu świata rzeczywistego.
Brak zgodności modelu z rzeczywistością może prowadzić do tworzenia systemów, które nie spełniają rzeczywistych potrzeb użytkowników lub nie uwzględniają istotnych uwarunkowań biznesowych i technicznych.
Zasada czwarta: System powinien być opisany przez zbiór spójnych, wzajemnie uzupełniających się modeli
Ze względu na różne potrzeby i różne poziomy abstrakcji, jeden model systemu rzadko spełnia wszystkie stawiane przed nim zadania i nie jest wystarczająco przydatny. Potrzebne jest wiele modeli, które wspólnie tworzą kompletny obraz systemu.
Ponieważ jednak wszystkie modele dotyczą tego samego systemu, muszą się uzupełniać i przenikać. Tak dzieje się na przykład w modelach architektonicznych, gdzie przed zbudowaniem domu opracowuje się różne jego modele (zwane projektami): ogólny projekt architektoniczny, projekt budowlany, projekt instalacji elektrycznej, projekt instalacji sanitarnej itd.
W przypadku systemów informatycznych, mogą to być modele:
- Strukturalne (diagramy klas, komponentów)
- Behawioralne (diagramy przypadków użycia, sekwencji, aktywności)
- Architektoniczne (diagramy wdrożenia, pakietów)
- Danych (modele encji-związków, schematy baz danych)
Model analityczny a model projektowy
Model analityczny
Model analityczny budowany jest w czasie fazy zwanej fazą analizy. Przedstawia on sposób realizacji przez system postawionych wymagań, lecz abstrahuje od szczegółów implementacyjnych. Model ten odpowiada na pytanie „CO system ma robić?”, nie zagłębiając się w „JAK ma to robić?”.
Model analityczny często wykracza poza zakres odpowiedzialności samego systemu z kilku powodów:
- Kontekst i pełniejsze zrozumienie – Ujęcie w modelu pewnych elementów dziedziny problemu niebędących częścią systemu czyni model bardziej zrozumiałym. Przykładem jest uwzględnienie w modelu systemów zewnętrznych, z którymi system ma współpracować.
- Niejednoznaczność granic systemu – Na etapie modelowania może nie być jasne, które elementy modelu będą realizowane przez oprogramowanie, a które w sposób sprzętowy lub manualnie.
- Optymalizacja zakresu – Dostępne środki mogą nie pozwolić na realizację systemu w całości. Celem analizy może być wykrycie tych fragmentów dziedziny problemu, których wspomaganie za pomocą oprogramowania będzie szczególnie przydatne.
Model analityczny koncentruje się na:
- Identyfikacji głównych klas biznesowych i ich powiązań
- Zdefiniowaniu operacji wysokiego poziomu
- Zrozumieniu procesów biznesowych
- Określeniu interakcji z użytkownikami i systemami zewnętrznymi
Model projektowy
Celem fazy projektowania jest opracowanie modelu projektowego, czyli szczegółowego opisu implementacji systemu. W odróżnieniu od analizy, w projektowaniu dużą rolę odgrywa środowisko implementacji. Projektanci muszą więc posiadać dobrą znajomość języków programowania, bibliotek, frameworków i narzędzi stosowanych w trakcie implementacji.
W trakcie projektowania dąży się do tego, aby struktura projektu zachowała ogólną strukturę modelu stworzonego w fazie analizy. Niewielkie zmiany w dziedzinie problemu powinny implikować niewielkie zmiany w projekcie – co jest wyrazem dobrego i elastycznego zaprojektowania systemu.
W fazie projektowania następuje dalsze uszczegółowienie wyników analizy. Projekt musi być wystarczająco szczegółowy, aby mógł być podstawą implementacji. Jego stopień szczegółowości zależy od poziomu zaawansowania programistów – bardziej doświadczeni programiści mogą potrzebować mniej szczegółów niż początkujący.
W czasie projektowania dokonuje się również projektowania składowych systemu niezwiązanych bezpośrednio z dziedziną problemu oraz proponuje się optymalizację systemu, uwzględniając wymagania niefunkcjonalne.
Model projektowy koncentruje się na:
- Szczegółowej strukturze klas, włączając wszystkie atrybuty i metody
- Wzorcach projektowych i architektonicznych
- Konkretnych algorytmach i strukturach danych
- Mechanizmach obsługi błędów i wyjątków
- Szczegółach integracji z innymi systemami
- Aspektach bezpieczeństwa, wydajności i skalowalności
Rola wymagań niefunkcjonalnych w projektowaniu
W czasie projektowania szczególnie ważną rolę odgrywają wymagania niefunkcjonalne, które powinny być zidentyfikowane już w czasie wykonywania analizy systemu. W fazie projektowania wymagania te są uszczegóławiane i przekładane na konkretne rozwiązania projektowe.
Najważniejsze grupy wymagań niefunkcjonalnych, które powinny być uwzględnione w fazie projektowania, to:
- Wymagania odnośnie wydajności:
- Czas odpowiedzi systemu
- Przepustowość
- Wykorzystanie zasobów (CPU, pamięć, dysk)
- Skalowalność
- Wymagania odnośnie interfejsu:
- Protokoły komunikacyjne
- Formaty wymiany danych
- Standardy integracyjne
- Formaty plików
- Wymagania odnośnie dokumentacji:
- Konieczne dokumenty techniczne
- Format i struktura dokumentacji
- Poziom szczegółowości opisów
- Wymagania odnośnie bezpieczeństwa:
- Autoryzacja i uwierzytelnianie
- Poufność danych
- Integralność danych
- Śledzenie działań użytkowników
- Ochrona przed atakami
- Inne istotne wymagania niefunkcjonalne:
- Dostępność i niezawodność
- Testowalność
- Łatwość konserwacji i rozbudowy
- Przenośność
- Zgodność z regulacjami prawnymi
- Odtwarzalność po awarii
Projektowanie przy uwzględnieniu wymagań niefunkcjonalnych często wymaga kompromisów. Na przykład, wysoka wydajność może stać w sprzeczności z łatwością konserwacji kodu. Rolą architekta i projektanta jest znalezienie optymalnego balansu między różnymi, czasem konkurującymi ze sobą, wymaganiami.
Proces analizy i projektowania
Proces analizy i projektowania można podzielić na kilka kluczowych kroków:
Krok 1: Analiza specyfikacji wymagań
Cel: Dogłębne zrozumienie specyfikacji wymagań i przełożenie ich na działania projektowe.
Działania:
- Szczegółowa analiza wszystkich wymagań funkcjonalnych i niefunkcjonalnych
- Identyfikacja potencjalnych luk lub niespójności w wymaganiach
- Mapowanie wymagań na poszczególne elementy projektu
- Określenie priorytetów implementacyjnych
- Weryfikacja kompletności wymagań z punktu widzenia projektu
Wynik: Uszczegółowiona lista wymagań z przypisaniem do elementów projektu.
Krok 2: Opracowanie logicznej architektury dla integracji (opcjonalnie)
Cel: Identyfikacja komponentów i interfejsów wraz z metodami, które w wyniku realizowanego przedsięwzięcia będą musiały ulec zmianie.
Działania:
- Analiza istniejącej architektury systemu
- Identyfikacja komponentów, które będą podlegały zmianom
- Określenie interfejsów między komponentami
- Projektowanie nowych interfejsów, jeśli to konieczne
- Analiza wpływu zmian na istniejące integracje
Wynik: Model architektury logicznej systemu z zaznaczeniem elementów podlegających zmianom.
Krok 3: Udoskonalenie projektu systemu
Cel: Opracowanie szczegółowego projektu systemu z uwzględnieniem wszystkich aspektów technicznych.
Działania:
- Przygotowanie detalicznej listy zmian w poszczególnych komponentach
- Definiowanie struktury klas/obiektów
- Projektowanie algorytmów i procesów
- Określenie szczegółów implementacyjnych
- Aktualizacja dokumentacji technicznej
- Przygotowanie zadań programistycznych
Wynik: Szczegółowy projekt systemu gotowy do implementacji, wraz z listą zadań programistycznych.
Krok 4: Udoskonalenie modeli danych
Cel: Aktualizacja logicznego modelu danych na podstawie zidentyfikowanych zmian.
Działania:
- Analiza istniejącego modelu danych
- Identyfikacja zmian wymaganych w strukturach danych
- Projektowanie nowych struktur danych
- Definiowanie relacji między danymi
- Optymalizacja modelu danych pod kątem wydajności i integralności
Wynik: Zaktualizowany logiczny model danych.
Krok 5: Wygenerowanie dokumentacji projektowej systemów
Cel: Przygotowanie kompletnej dokumentacji projektowej, która będzie służyć jako przewodnik dla implementacji.
Działania:
- Kompilacja wszystkich artefaktów projektowych
- Weryfikacja spójności dokumentacji
- Przygotowanie diagramów UML (klasy, sekwencje, komponenty, wdrożenia)
- Dokumentacja decyzji projektowych
- Przygotowanie instrukcji dla programistów
Wynik: Kompletna dokumentacja projektowa systemu.
Krok 6: Przegląd i walidacja projektu (dodatkowy krok)
Cel: Zapewnienie jakości i zgodności projektu z wymaganiami.
Działania:
- Przeprowadzenie wewnętrznych przeglądów projektu
- Weryfikacja zgodności z wymaganiami
- Analiza potencjalnych ryzyk technicznych
- Ocena wydajności i bezpieczeństwa proponowanego rozwiązania
- Walidacja projektu z udziałem kluczowych interesariuszy
Wynik: Zwalidowany projekt z listą ewentualnych korekt i usprawnień.
Narzędzia i techniki stosowane w analizie i projektowaniu
Języki modelowania
- UML (Unified Modeling Language) – standardowy język modelowania w inżynierii oprogramowania, obejmujący szereg diagramów:
- Diagram klas – przedstawia strukturę systemu
- Diagram przypadków użycia – pokazuje funkcjonalności z perspektywy użytkownika
- Diagram sekwencji – przedstawia interakcje między obiektami w czasie
- Diagram aktywności – modeluje przepływ pracy
- Diagram stanów – pokazuje stany obiektów i przejścia między nimi
- Diagram komponentów – przedstawia fizyczne komponenty systemu
- Diagram wdrożenia – pokazuje środowisko uruchomieniowe
- BPMN (Business Process Model and Notation) – standard dla modelowania procesów biznesowych
- SysML – język modelowania systemów, rozszerzenie UML dla inżynierii systemów
Wzorce projektowe
Wzorce projektowe to sprawdzone rozwiązania typowych problemów projektowych. Ich stosowanie znacząco podnosi jakość projektu i ułatwia późniejsze utrzymanie systemu. Główne kategorie wzorców to:
- Wzorce kreacyjne – dotyczące procesów tworzenia obiektów
- Singleton, Factory Method, Abstract Factory, Builder, Prototype
- Wzorce strukturalne – określające relacje między klasami i obiektami
- Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy
- Wzorce behawioralne – definiujące komunikację między obiektami
- Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method, Visitor
Wzorce architektoniczne
- Model-View-Controller (MVC) – oddziela dane od prezentacji i logiki biznesowej
- Mikrousługi – system jako zbiór luźno powiązanych, niezależnych usług
- Architektura warstwowa – organizuje system w hierarchiczne warstwy
- Event-driven architecture – bazuje na produkcji, wykrywaniu i konsumpcji zdarzeń
- Domain-Driven Design (DDD) – koncentruje się na modelowaniu domeny biznesowej
Narzędzia CASE
Narzędzia CASE (Computer-Aided Software Engineering) wspierają proces analizy i projektowania poprzez:
- Tworzenie i edycję diagramów
- Generowanie kodu z modeli
- Inżynierię wsteczną (tworzenie modeli z kodu)
- Zarządzanie wymaganiami
- Śledzenie powiązań między artefaktami
Popularne narzędzia CASE to:
- Enterprise Architect
- Visual Paradigm
- IBM Rational Software Architect
- StarUML
- Lucidchart
- Draw.io
Jakość modelu projektowego
Sukces i odpowiednia jakość fazy projektowania zależą w dużej mierze, poza merytorycznym przygotowaniem projektantów i programistów, od przestrzegania zaleceń dotyczących jakości modelu projektowego. Kluczowe aspekty jakości modelu projektowego to:
- Zgodność z wymaganiami – model musi odzwierciedlać wszystkie wymagania funkcjonalne i niefunkcjonalne
- Spójność – wszystkie elementy modelu muszą być ze sobą spójne, bez wewnętrznych sprzeczności
- Kompletność – model powinien obejmować wszystkie istotne aspekty systemu
- Przejrzystość – model powinien być zrozumiały dla wszystkich zainteresowanych stron
- Modularność – system powinien być podzielony na logiczne, niezależne moduły
- Utrzymywalność – projekt powinien umożliwiać łatwe wprowadzanie zmian
- Testowalność – projekt powinien uwzględniać łatwość testowania systemu
- Zgodność ze standardami – konsekwentne stosowanie notacji i formularzy
- Adekwatność do środowiska implementacji – projekt musi uwzględniać możliwości i ograniczenia wybranej technologii
Podsumowanie
Faza analizy i projektowania stanowi pomost między określeniem wymagań a implementacją systemu. Dobrze przeprowadzona analiza i projektowanie znacząco zwiększają szanse na powodzenie projektu informatycznego. Kluczowe jest przestrzeganie podstawowych zasad modelowania, uwzględnienie zarówno modelu analitycznego, jak i projektowego, oraz odpowiednie podejście do wymagań niefunkcjonalnych.
Warto pamiętać, że opisane kroki są przykładowe. W zależności od środowiska pracy, doświadczenia analityków i projektantów, metodyki wytwarzania oprogramowania oraz specyfiki projektu, prace te mogą być zorganizowane w inny sposób.
Najważniejsze jest, aby w języku UML doprecyzować architekturę, interfejsy systemów oraz, korzystając z diagramu sekwencji, narysować sekwencje komunikatów pomiędzy komponentami. W ten sposób udokumentowane zostaną podjęte decyzje projektowe. Taka dokumentacja może posłużyć do szybszego odświeżenia wiedzy o sposobie działania rozwiązania i tym samym przyczynić się do podjęcia trafniejszych decyzji przy kolejnych modyfikacjach.
Spis treści:
