Projektowanie systemu

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.  

Zasady modelowania analizy
Przed przystąpieniem do każdego niebanalnego systemu powinno się zapoznać z czterema głównymi zasadami modelowania, które określają najważniejsze kwestie z projektowaniem a których znajomość ułatwi ten proces.

Zasada pierwsza: Dobór modelu ma istotny wpływ na końcowy produkt.
Oznacza ona, że projektant powinien zastanowić się, jakie modele bryłą potrzebne przy pracach nad systemem. Jeśli będą dobrze dobrane, można wtedy poradzić sobie z najtrudniejszymi i złożonymi problemami. Należy pamiętać, Że różny sposób postrzegania problemu może prowadzić do innych rozwiązań systemu, a co za tym idzie z innymi kosztami i korzyściami.

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ć, a projektowy na tym, jak to zrobić. Każdy z nich będzie przedstawiać system na różnym poziomie szczegółowości.

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ść. Najważniejsze jest  jednak, żeby mieć pewność, że uproszczenie nie dotyczy istoty rzeczy
i nie zmienia świata rzeczywistego.

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 nie spełniałby stawianych przed nim zadań i nie byłby przydatny. Potrzebne jest wiele modeli. Ponieważ jednak wszystkie 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.

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 analityczny wykracza z reguły poza zakres odpowiedzialności systemu. Dzieje się tak dlatego, że:

  • Ujęcie w modelu pewnych elementów dziedziny problemu nie częścią systemu czyni model bardziej zrozumiałym. Przykładem jest  w modelu systemów zewnętrznych, z którymi system ma współpracować
  • Na etapie modelowania może też nie być jasne, które elementy modelu będą realizowane przez oprogramowanie, a które w sposób sprzętowy lub ręcznie.
  • 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.

Celem fazy projektowania jest opracowanie modelu projektowego, czyli szczegółowego opisu implementacji systemu. odróżnieniu od analizy, w projektowaniu dużą rolę odgrywa środowisko implementacji. Projektanci muszą więc posiadać dobrą znajomość języków, bibliotek 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 poprzednich fazach (analizie). Niewielkie zmiany w dziedzinie problemu powinny implikować niewielkie zmiany w projekcie.

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.
W czasie projektowania dokonuje się również projektowania składowych systemu niezwiązanych z dziedziną problemu oraz proponuje się optymalizację systemu.

W czasie projektowanie ważna rolę odgrywają wymagania niefunkcjonalne.
Wymagania niefunkcjonalne powinny być zidentyfikowane w czasie wykonywania analizy systemu. W fazie projektowania wymagania te są uszczegóławiane i przekładane na konkretne rozwiązania projektowe.

Dla przypomnienia podajemy listę najważniejszych grup wymagań niefunkcjonalnych, które powinny być uwzględnione w fazie projektowania:

  • wymagania odnośnie wydajności
  • wymagania odnośnie interfejsu (protokoły, formaty plików,..
  • wymagania odnośnie dokumentacji
  • wymagania odnośnie bezpieczeństwa

Mając to wszystko na uwadze pierwszym krokiem fazy analizy i projektowanie jest

Krok 1 Analiza specyfikacji wymagań
Celem jest analiza specyfikacji wymagań. Opracowane wymagania są mapowane na poszczególne działania projektowe. 

Krok 2. Opracowanie logicznej architektury dla integracji (opcja)
W tym kroku identyfikowane są komponenty i interfejsy warz z metodami, które w wyniku realizowanego przedsięwzięcia będą musiały ile zmianie. 

Krok 3 Udoskonalenie projektu systemu
W kroku tym powstaje detaliczna lista zmian w poszczególnych komponentach. Poza przygotowanie zadań programistycznych w tym kroku warto jest zaktualizować dokumentację

Krok 4 Udoskonalenie modeli danych
Celem tego działania jest, na podstawie zidentyfikowane zmiany, aktualizacja logicznego model danych.

Krok 5. Wygenerowanie dokumentacji projektowej systemów

Reasumując. Sukces i odpowiednia jakość fazy projektowania zależą w dużej mierze, poza merytorycznym przygotowaniem projektantów i programistów, zależy od przestrzegania zaleceń dotyczących jakości modelu projektowego, w tym zachowanie przyjętych standardów, np. konsekwentne stosowanie notacji i formularzy, oraz od dobrej znajomości przez projektanta środowiska implementacji.

Ponadto podane kroki są przykładowe. W zależności od środowiska pracy doświadczenia analityków i projektantów prace te mogą być zorganizowane w inny sposób. Ważne jest to, by w języku UML doprecyzować architekturę, interfejsy systemów oraz korzystając z diagramu sekwencji narysować sekwencje komunikatów pomiędzy komponentami. W ten oto sposób udokumentowane zostaną podjęte decyzje projektowe. Posłużyć ona może 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:

Scroll to Top