Metodyka strukturalna dla każdego (cz. 3)

W ramach naszego mini-kursu projektowania systemów informatycznych pisaliśmy o cyklu projektowym, narzucającym kolejność etapom specyfikacji systemu. Pisaliśmy również o technice modelowania danych, stanowiącej podstawowe narzędzie w analizie struktury danych przetwarzanych przez system oraz pozwalającej na generację schematu bazy danych. Schemat ten opisuje za pomocą specjalnego języka DDL (tzw. języka definicji danych - Data Definition Language) poszczególne tablice, rodzaje pól, zależności między tablicami, a także procedury obsługi niektórych zdarzeń zachodzących w bazie danych. Modelowanie danych stosowane jest na niemal wszystkich etapach opisu i konstrukcji systemu.

W ramach naszego mini-kursu projektowania systemów informatycznych pisaliśmy o cyklu projektowym, narzucającym kolejność etapom specyfikacji systemu. Pisaliśmy również o technice modelowania danych, stanowiącej podstawowe narzędzie w analizie struktury danych przetwarzanych przez system oraz pozwalającej na generację schematu bazy danych. Schemat ten opisuje za pomocą specjalnego języka DDL (tzw. języka definicji danych - Data Definition Language) poszczególne tablice, rodzaje pól, zależności między tablicami, a także procedury obsługi niektórych zdarzeń zachodzących w bazie danych. Modelowanie danych stosowane jest na niemal wszystkich etapach opisu i konstrukcji systemu.

Kolejny, trzeci już odcinek cyklu poświęcamy technikom pozwalającym na opis dynamiki tworzonego systemu informatycznego. W odróżnieniu od modelu danych, stanowiącego dobry materiał zarówno przy ustalaniu wymagań użytkownika, jak i przy generacji ostatecznej postaci bazy danych, techniki stosowane do opisu procesów przetwarzania danych w systemie nie dadzą się tak jednolicie użyć w ciągu całego cyklu projektowego. Proces projektowania strony dynamicznej systemu polega zatem na stopniowym przechodzeniu między różnego rodzaju opisami - od koncepcyjnego, najczęściej w postaci różnego rodzaju diagramów przepływu danych, aż do implementacyjnego, w postaci specyfikacji modułów. Chyba właśnie techniki modelowania procesów dają najlepszy obraz stopniowego przejścia od koncepcji i opisu systemu w kategoriach dogodnych dla użytkownika, do opisu stanowiącego specyfikację czytelną dla programisty lub akceptowaną przez generator kodu. Przekształcenie to prowadzi od informacji w formie doskonale zrozumiałej dla użytkownika i reprezentującej przede wszystkim jego wiedzę, do opisu przydatnego przy implementacji, ale za to niezrozumiałego dla większości użytkowników. Techniki modelowania procesów pomyślane są tak, aby w kolejnych przekształceniach informacja projektowa nie była gubiona i zniekształcana.

Diagramy Przepływu Danych

W celu określenia struktury danych systemu analityk rozmawia z użytkownikiem o zawartości dokumentów przetwarzanych w danej organizacji, rysuje modele danych, wyodrębnia encje, ich atrybuty i związki jakie muszą być uwzględnione przez tworzony system. Równie ważne jest pytanie, JAK owe dane są przetwarzane? Co się dzieje, kiedy do komputeryzowanej przez nas firmy szkoleniowej przychodzi klient i chce zapisać się na wakacyjne kursy języka angielskiego? Co dzieje się z wypełnionym przez niego formularzem? Czy jego dane przechowywane są nawet jeśli nie ma wolnego miejsca na kursach? Czy mamy możliwość zawiadomienia go, gdy wolne miejsce się znajdzie? Co dzieje się z wpłaconą przez niego zaliczką, jeśli kurs z jakichś powodów zostaje odwołany?

Setki podobnych pytań padają w czasie pracy zespołu projektowego, grupującego analityków i przedstawicieli użytkownika. Jedni i drudzy starają się dotrzeć do istoty wykonywanych w firmie operacji. Pozwoli to wyspecyfikować źródła problemów, określić oczekiwany zakres prac i kryteria oceny stworzonego w przyszłości systemu.

Podstawowym dokumentem, nad którym toczą się powyższe deliberacje są diagramy przepływu danych - DPD. Podobnie, jak to zrobiliśmy z modelami danych, przyjrzymy się na początku diagramowi reprezentującemu działalność firmy szkoleniowej.

Diagram DPD (rys. 1) zawiera cztery rodzaje obiektów. Duże prostokąty (o 3 polach) to procesy przetwarzające dane. Mniejsze prostokąty symbolizują miejsca, w których dane są przechowywane (a więc nie dokonuje się tam ich modyfikacji). Prostokątna ramka System Overview reprezentuje system jako całość. Elipsy umieszczone poza nią to obiekty zewnętrzne. Stanowią one źródło albo ujście danych. Wreszcie fakt przepływu danych zaznaczony jest przez połączenie strzałką obiektów, pomiędzy którymi następuje.

Zamieszczony rysunek pokazuje jedynie podstawowe procesy wykonywane w naszej hipotetycznej firmie szkoleniowej, podkreślając za pomocą przepływów zależności, jakie między nimi zachodzą. To jednak często okazuje się mało dokładnym opisem systemu. Analitycy zaczynają więc zadawać kolejne pytania - na czym właściwie polega proces obsługi faktur? Czy jest on jednorodny, czy może da się w nim wyodrębnić różne czynności? Czy jest wykonywany w całości, czy jest rozłożony w czasie? Podobne pytania można zadać w stosunku do pozostałych procesów na diagramie. Dochodzimy więc do momentu, kiedy część wyodrębnionych w pierwszym ruchu operacji przetwarzania danych (a być może wszystkie) zaczynamy opisywać za pomocą... tego samego rodzaju diagramów. Ta właśnie strukturalna właściwość diagramów przepływu danych czyni je niezwyke pożytecznym narzędziem w procesie analizy. DPD pozwalają na opis systemu na różnych poziomach szczegółowości - od koncepcyjnego, wyodrębniającego podstawowe funkcje organizacji, aż po "techniczny", opisujący np. szczegóły realizacji zapisu klienta na kurs.

Tworzenie DPD

Diagramy można tworzyć na dwa sposoby. Po pierwsze, analiza procesów może być "napędzana" rozpoznaniem głównych funkcji realizowanych w organizacji. Dla linii lotniczych mogą to być np. sprzedaż biletów, rezerwacja lotów, odprawa na lotnisku, księgowość, marketing, współpraca z biurami podróży. Tego typu analiza jest szczególnie przydatna w studiach strategicznych, kiedy próbujemy określić potrzeby informacyjne przedsiębiorstwa oraz naszkicować koncepcję informatyzacji.

Drugie możliwe podejście - wstępujące - bazuje na analizie zachodzących w organizacji zdarzeń, takich jak złożenie zamówienia, zamknięcie okresu finansowego, dostawa produktów do magazynu. Dla każdego zdarzenia, które wymusza na organizacji podjęcie pewnych działań, łączących się z przetwarzaniem informacji, możemy starać się modelować procesy i przepływy z nim związane. Powstające diagramy następnie łączymy grupując procesy w logiczne całości i na tej podstawie tworząc opis na coraz wyższym poziomie. Kryterium scalania procesów może być np. istnienie wspólnych magazynów danych, z którymi się komunikują. Przykład analizy zdarzeń i scalania procesów ilustrują rys. 2, 3, 4.

Budowanie opisu systemu za pomocą analizy zdarzeń pozwala na rozbicie modelu na niewielkie spójne fragmenty. Wraz z diagramem przepływów możemy tworzyć również fragment modelu danych związany z każdym zdarzeniem.

Analiza zstępująca pozwala na szczegółową analizę koncepcji systemu - od zarysu (klasyfikacji), jego funkcji aż do ich szczegółowego rozpoznania. Taki sposób analizy najlepiej stosować przy współpracy z użytkownikami "wysokiego" szczebla, świadomymi strategii organizacji i posiadającymi ogólną wizję jej działania.

Analiza funkcyjna

Pierwszym zadaniem technik modelowania procesów jest stworzenie wspólnego języka dla analityka i użytkownika. Diagramy przepływu danych mają notację na tyle prostą, że mogą być efektywnie weryfikowane (a nawet tworzone!) przez użytkownika. Nie nadają się, niestety do implementacji. Nie są bowiem na tyle jednoznaczne, by służyć jako specyfikacja dla programisty, a tym bardziej - akceptowana przez generator kodu. Notacja nie mówi bowiem nic o wzajemnych zależnościach między procesami, takich jak np. ich kolejność czy hierarchia wywołań. Zadanie DPD, to uzyskanie specyfikacji na poziomie użytkownika, ustalenie zakresu informatyzacji i stworzenie bazowego modelu pozwalającego na weryfikację wyników dalszych etapów projektu.

Tradycyjna metodyka projektowania strukturalnego prowadzi dekompozycję DPD aż do poziomu tzw. funkcji elementarnych, tzn. do momentu, kiedy każdy proces jest spójny funkcjonalnie i daje się prosto wyspecyfikować za pomocą pseudokodu. Podejścia bardziej nowoczesne i nastawione na efektywność procesu projektowego ograniczają rolę DPD do reprezentacji koncepcji systemu i narzędzia służącego do komunikacji z użytkownikiem (Systems Engineering) albo redukują je do technik drugorzędnych i opcjonalnych (Oracle CASE*Method, Information Engineering).

Podstawowym produktem wykorzystywanym przez programistę lub generator kodu są specyfikacje modułów, tworzone przez projektantów w postaci grafów struktury (structure charts) i pseudokodu stanowiącego szkic algorytmu. Analiza funkcyjna jest techniką pozwalającą na stworzenie zbioru modułów realizujących wszystkie wymagane funkcje systemu. Przejście od diagramów DPD do kompletnego i spójnego zbioru modułów realizowane jest na różne sposoby. Możliwe jest np. następujące przejście:

1. Analizując katalog zdarzeń i specyfikę systemu, tworzymy katalog funkcji które muszą być wykonywane przez system. Kompletność katalogu sprawdzamy weryfikując, czy każda funkcja jest reprezentowana przez procesy na diagramach DPD (rys. 5).

2. Dla każdej funkcji analizujemy przepływy komunikujące się z magazynami danych, tworząc w ten sposób katalog transakcji. Ten z kolei weryfikujemy z modelem danych. Badamy czy model danych zawiera dane dla każdej transakcji i czy każdy jego element ma kompletny zbiór "obsługujących go" transakcji. Następnie dla każdej transakcji projektujemy moduł lub zbiór modułów systemu. Pozostaje teraz zaprojektowanie struktury modułów i specyfikacja ich algorytmów (rys. 6 i 7).

Powyższy przykład analizy funkcyjnej (zaczerpnięty z metodyki Systems Engineering firmy LBMS) daje obraz złożoności procesu projektowania za pomocą metod strukturalnych. Oczywiście nie zawsze potrzebny jest pełny proces analizy funkcyjnej. Możemy go przeprowadzać np. tylko dla wyjątkowo skomplikowanych fragmentów systemu. Warto jednak pamiętać o tym, że im bardziej kompletny będzie nasz cykl projektowy, tym większa szansa na uzyskanie wysokiej jakości produktu realizującego wymagania użytkowników.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200