Projektowanie systemów informatycznych

część 2

Sebastian Wyrwał

W poprzednim artykule przedstawiono projektowanie, pobieżnie
charakteryzując jego cele oraz miejsce w procesie wytwarzania oprogramowania.
Określono grupy osób uczestniczące w przedsięwzięciu informatycznym.
Przedstawiono popularne modele życia oprogramowania i ich wpływ na
projektowanie. Punktem wyjścia do rozważań jest model kaskadowy zakładający
przechodzenie do kolejnych etapów przedsięwzięcia bez możliwości powrotu.
Alternatywą dla starannego projektowania jest model odkrywczy, który zakłada
wytworzenie systemu bez jakiegokolwiek projektu, a następnie modyfikowanie tego
systemu „aż do skutku”, czyli do osiągnięcia pożądanej funkcjonalności.
Wskazano na kluczową rolę analizy wymagań użytkowania (lub wymagań określonych
przez ekspertów dla systemu „z półki”) dla powodzenia przedsięwzięcia
informatycznego. Dokonano podziału wymagań stawianych systemowi na:
funkcjonalne (co system robi) oraz nie funkcjonalne (jak „to” robi).
Dokonano również podziału metod projektowania pod względem sformalizowania
(nieformalne, półformalne, formalne) i paradygmatu (strukturalne, obiektowe,
hybrydowe). Przedstawiono podejście do wytwarzania systemów informatycznych,
oparte o koncepcje rodzin produktów z wykorzystaniem procesu FAST.

W niniejszym artykule przedstawiono zagadnienia związane z
przeprowadzeniem studium wykonywalności projektu oraz modelowaniem systemu.
Czynności te powinny poprzedzić powstanie każdego, niebanalnego systemu. Następnie
rozpoczęto omówienie strukturalnych metod projektowania systemów
informatycznych (ang. structured design). Aby rozważania nie były czysto
teoretyczne, zaprezentowano opis systemu do obsługi przychodni – który posłuży
do prezentacji przykładów związanych z projektowaniem w tym i następnych
artykułach.

Studium wykonalności i modelowanie systemu

Studium wykonalności całego projektu, zwane fazą
strategiczną, poprzedza analizę i projektowanie. Można więc powiedzieć, że
ma mało z nimi wspólnego. Twierdzenie takie jest prawdziwe, gdy studium
wykonalności dotyczy całego projektu. Na powyższe zagadnienie można jednak
spojrzeć z nieco innej strony. Przypomnijmy, że w zaprezentowanym w poprzednim
odcinku modelu spiralnym, wyróżnia się cztery fazy:

  • planowanie,
  • analizę ryzyka,
  • wytworzenie systemu,
  • ocenę przez użytkownika.

Bardzo istotną cechą tego modelu jest analiza ryzyka.
Analiza ta może być rozumiana nieco szerzej i może obejmować całość
zagadnień związanych z oceną wykonywalności. Pisząc program w domu lub w małej
firmie, najczęściej zapomina się o analizie ryzyka i przeprowadzeniu studium
wykonywalności w odniesieniu do całego projektu, jak i w odniesieniu do ważnych
decyzji projektowych. Okazuje się jednak, że koszty niezrealizowanych projektów
sięgają milionów dolarów, a błędne decyzje projektowe skutecznie „umilają
życie” osobom realizującym projekt. Pytanie „Czy realizować projekt?”
można więc zastąpić pytaniem „Jak realizować projekt?”, co jest z
pozoru pogwałceniem zasad projektowania, które mówią, że projekt powinien
jak najdłużej abstrahować od implementacji i technologii implementacji.
Teoretycznie jest to stwierdzenie prawdziwe, praktyka jest jednak bardziej
skomplikowana, zwłaszcza gdy w pewien sposób jesteśmy skazani na realizację
danego projektu. W dużych firmach, projektant lub analityk nie decyduję o tym,
czy projekt będzie realizowany – takie decyzje zapadają na wyższym szczeblu.
Dobrze jest, jeśli może on dokonywać wyboru technologii, a jeszcze lepiej,
gdy może decydować o metodologii projektowania. Pewne technologie i
metodologie ułatwiają realizację pewnych przedsięwzięć, inne zdecydowanie
utrudniają. Sprawa komplikuje się jeszcze bardziej, gdy weźmie się pod uwagę
koszty związane z użyciem określonych technologii. Wybór konkretnej
technologii jest najczęściej kompromisem pomiędzy wymaganiami, a możliwościami
finansowymi. Sprawę komplikuje fakt, że cały system nie musi być wykonany
przy użyciu jednej technologii. Te same uwagi odnoszą się do ważnych decyzji
projektowych – studium wykonalności i analizę ryzyka można więc (zgodnie z
modelem spiralnym) odnieść do ważnych decyzji projektowych oraz
implementacyjnych (poza fazą strategiczną), pozostawiając studium wykonalności
całego przedsięwzięcia kierownictwu. (Właściciele niewielkich firm sformułują
zapewne powyższe pytanie: „Jak realizować projekt aby się opłacało” zwłaszcza,
gdy sytuacja na rynku zleceń nie jest zbyt ciekawa, przy założeniu, że nie
starają się o zlecenia, których nie są w stanie zrealizować).

Z tak pojętym studium wykonywalności wiąże się
modelowanie systemu1oraz badania operacyjne. Trzeba zdać sobie sprawę,
że postępowanie takie wiąże się w większym stopniu z wymaganiami
niefunkcjonalnymi, zwłaszcza trudnymi do określenia, niż z wymaganiami
funkcjonalnymi. Dla prostego systemu służącego do sprawdzania „online”
billingu (przez internet) wymagania funkcjonalne można wyspecyfikować
natychmiast, a wygląd interfejsu użytkownika w ciągu kilku lub, co najwyżej,
kilkunastu minut. Projekt cechuje bardzo prosta funkcjonalność systemu, prosty
opis rzeczywistości i banalny słownik systemu. Doświadczony developer poda
zapewne kilka możliwości implementacji. Czy to wystarczy? Z pozoru tak. Jak
jednak przewidzieć, znając liczbę użytkowników telefonów, ilu w danej
chwili będzie chciało sprawdzić ów billing, czyli mówiąc bardziej
formalnie jakie będzie obciążenie systemu. Obciążenie systemu będzie miało
znaczący wpływ na czas odpowiedzi systemu na żądanie użytkownika. Można
postawić następne pytanie: czy bardziej zasadne jest przetwarzanie żądań
klientów centralnie np. w Warszawie, czy może w każdym większym mieście lub
w czterech miastach? Tak postawione pytanie dotyczy struktury systemu
informatycznego. Zagadnienie to leży na granicy ekonomii i informatyki i
pozornie niewiele ma wspólnego z projektowaniem, szczególnie na wysokim
poziomie abstrakcji. Okazuje się jednak, że model może być szkieletem przyszłego
systemu. Wiadomo, że zarówno szybkość transmisji danych w sieci jak i obciążenie
systemu są zmiennymi losowymi. Można więc zbudować szkielet systemu wyodrębniając
właściwe klasy-encje w ten sam sposób, jak przy projektowaniu właściwego
systemu. Można więc zapytać, czym różni się taki szkielet od prototypu?
Odpowiedź jest bardzo prosta: prototyp posiada pewną funkcjonalność
docelowego (rzeczywistego) systemu – model zaś nie posiada żadnej
funkcjonalności oraz nie posiada właściwego dla systemu interfejsu użytkownika.
Może zaś posiadać interfejs, służący do konfiguracji modelu i prezentacji
wyników. Model systemu działa lokalnie tzn. nie ma w nim jakiegokolwiek
rozproszenia i decentralizacja jest symulowana.

Pozostaje tylko zapytać: po co taki model skoro nic nie
robi? W szkieletowych funkcjach można wprowadzić opóźnienia generowane
losowo (banalne) lub obliczane na podstawie obciążeń (bardziej rozsądne).
Drugim ważnym powodem jest możliwość przetestowania projektu-modelu2 ,
zwłaszcza w kategoriach interreakcji między obiektami klas. Szkielet systemu
może być również użyty do testowania (w warunkach jakby laboratoryjnych)
pewnych algorytmów, które będą użyte w docelowym systemie np. algorytmów
przydziału zadań. Model można znacznie uprościć nie wprowadzając encji
występujących w opisie rzeczywistości, a jedynie węzły (miejsca gdzie
przetwarzane są informacje). Zaletą takiego podejścia jest to, że budowa
modelu jest bardzo prosta, a symulacja może być wykonana np. przy użyciu narzędzia
matlab; wadą natomiast to, że model ma bardzo mało wspólnego z
docelowym systemem. Uciążliwe i niecelowe jest testowanie algorytmów ponieważ
mogą być inaczej realizowane w języku skryptów matlaba a inaczej np.
w C++. (Złożoność teoretyczna pozostaje ta sama – ale nie chodzi tu
przecież o dobrze zbadane algorytmy sortowania). Autor uważa, iż celowe jest
zbudowanie modelu, który umożliwia przeprowadzenie symulacji (na pewnym
stopniu badań operacyjnych), będąc jednocześnie szkieletem docelowego
systemu. Zauważmy, że pozwala to na nałożenie na siebie projektowania i
implementacji. Uwagi zgłaszane przez programistów mogą być cennym materiałem
dla projektantów. W systemie billingowym mogą występować encje: klient,
konto itp. Do symulacji można więc użyć systemu o następującej strukturze:


Rys. 1. Model systemu bilingowego

Innym przykładem do modelowania jest zastosowanie klastra
serwerów WWW zamiast pojedynczego serwera w celu przyśpieszenia obsługi żądań
klientów. Użycie kilku serwerów bezsprzecznie skraca czas oczekiwania na
odpowiedź. Z rozwiązaniem takim wiążą się jednak pewne problemy – tutaj
zostaną wymienione tylko dwa:

  • dobór rozmiaru klastra,
  • wybór algorytmu przydziału zadań.

Doświadczalne badanie wpływu rozmiaru klastra jest dość
uciążliwe – sensowne może być zbudowanie modelu systemu. Po zbudowaniu
model taki mógłby zostać użyty do testowania różnych algorytmów przydziału
zadań. Schemat takiego systemu przedstawiono poniżej:


Rys. 2. Model do badania klastra serwerów WWW

Cały model działa lokalnie. Liczba klientów, wielkości i
rodzaje pobieranych przez nich plików, są generowane losowo. Kanały
transmisyjne wprowadzają pewne opóźnienie w transmisji danych. Charakteryzuje
je pewna przepustowość. Algorytm przydziału żądań, przydziela nadchodzące
żądania do serwerów WWW. Algorytm ten jest jedyną częścią modelu, która
posiada rzeczywistą funkcjonalność. Model serwera WWW wylicza czas obsługi
żądania na podstawie bieżącego obciążenia lub generuje go losowo. Model
bazy danych wylicza opóźnienia związane z wykonaniem zapytania przez motor
bazy danych. Należy podkreślić, że wszystkie inne elementy modelu nie mają żadnej
rzeczywistej funkcjonalności – wprowadzają jedynie opóźnienia i pozwalają
na monitorowanie obciążenia. Aby zbudować model, należy zastanowić się,
jak – w miarę prosto – zrealizować wielowątkowość serwera WWW. Należy
ponadto zrealizować lub symulować współbieżność pracy serwerów. Modele serwera
WWW
oraz kanału transmisyjnego mogą być kolejkami, do których
wstawia się pewne zadania, zadania zostają „wyjęte” z kolejki po upływie
pewnego czasu – odpowiednio czasu transmisji lub obsługi przez serwer WWW.
Oczywiście stopień skomplikowania modeli będzie tym większy, im bardziej mają
one odzwierciedlać rzeczywistość. Opcjonalnie można uwzględnić możliwość
awarii lub wyłączenia jednego lub kilku serwerów na pewien czas. (W
rzeczywistych systemach trzeba dokonywać pewnych prac, do przeprowadzenia których
niezbędne jest wyłączenie serwera z użycia – dobry model powinien uwzględniać
taką sytuację).

Należy jeszcze wspomnieć o języku Simula, który został
zaprojektowany w latach sześćdziesiątych jako narzędzie do symulacji. Powstały
różne jego wersje, tak że w końcu stał się on językiem ogólnego użycia.
Choć nie stał się powszechnie stosowany, wywarł jednak wpływ na rozwój
innych języków programowania.

Opis rzeczywistości przykładowego systemu

W tabeli 1 zaprezentowano opis rzeczywistości, który posłuży
jako przykład dla omawianych obecnie metod strukturalnych, jak również dla
metod obiektowych, które będą omawiane w przyszłości. Przedstawienie
konkretnych projektów pozwoli na uchwycenie różnic pomiędzy różnymi
metodami oraz pozwoli na zidentyfikowanie problemów, które pojawiają się
przy zastosowaniu różnych metod. Oczywiście należy pamiętać, że opis nie
jest opisem systemu, który ma być wdrożony. Opis takiego systemu zająłby
wiele stron, a jego stworzenie wymagałoby konsultacji z ekspertami
dziedzinowymi z zakresu medycyny.

Tabela 1. Opis rzeczywistości – przykład dla omawianych
obecnie metod strukturalnych jak również dla metod obiektowych.

System do obsługi przychodni lekarskiej

1. Opis rzeczywistości:

W przychodni usługi świadczą lekarze różnych specjalności.
System ma umożliwiać rejestrację pacjentów, prowadzenie całej
dokumentacji medycznej oraz wystawianie recept, rachunków, skierowań, zaleceń
itp.

Oprócz ww. świadczone są inne usługi takie, jak
podstawowe badania laboratoryjne, USG itd. Lekarze podzieleni są na zespoły
specjalistyczne tj. lekarze ogólni, kardiolodzy, stomatolodzy itp. Każdy
zespół lekarzy posiada kierownika, który poza funkcją administracyjną,
konsultuje trudniejsze decyzje merytoryczne dotyczące leczenia pacjentów.
Monitoruje on także okresowo dokumentację medyczną pacjentów. Pracownie
laboratoryjne mają również kierowników. Terminy wizyt muszą być wcześniej
ustalane, również za pośrednictwem telefonu. Konieczność rezerwacji
wizyty nie dotyczy nagłych przypadków zachorowań, bólu zęba itp. Pacjenci
za leczenie rozliczani są całościowo w recepcji. Specjalista (w obrębie
przychodni) dysponuje całą dokumentacją medyczną pacjenta, który został
do niego skierowany. System ma pozwalać na konfigurację wzorów dokumentacji
medycznej, druków, badań, specjalności lekarzy.

2. Słownik systemu

Osoba – Ma: imię, nazwisko, NIP, PESEL, numer
telefonu, numer telefonu komórkowego, adres.

Pracownik – osoba zatrudniona w przychodni na
podstawie umowy o pracę.

Lekarz – pracownik posiadający uprawnienia do
wykonywania zawodu lekarza na terytorium RP, zgodnie z ustawą. Lekarz ma:
numer statystyczny i kierownika. Lekarz może posiadać pewne dodatkowe
uprawnienia np. do badania kierowców.

Lekarz specjalista – lekarz posiadający II
stopień specjalizacji w danej dziedzinie lub/i tytuł doktora nauk
medycznych.

Pacjent – osoba korzystająca z usług
medycznych. (Na poziomie sytemu informatycznego: osoba korzystająca z usług
medycznych, która jest zarejestrowana w systemie).

Kierownik – pracownik zatrudniony na stanowisku
kierownika lub pełniący funkcję kierownika.

Pielęgniarka (pielęgniarz) – pracownik
zatrudniony na wymienionym stanowisku.

Laborant(ka) – pracownik wykonujący analizy
medyczne.

Personel biurowy – pracownicy dokonujący
pozamedycznej obsługi (np. rejestracji) pacjenta.

Dokumentacja medyczna – informacje i dane opisujące
wyniki badań, wywiadów z pacjentem itp.

Druk – skierowanie do innego lekarza (lekarza
specjalisty), na badania lub do szpitala, recepta, zalecenia dla pacjenta.
Drukiem są również wyniki badań, konsultacji. Druki są generowane na
podstawie zarejestrowanych w systemie wzorców druków.

Wizyta – konsultacja z lekarzem (lub lekarzem
specjalistą). Wizyta ma być odnotowana w dokumentacji medycznej. Wizyta ma
datę, godzinę, lekarza, oraz opcjonalnie druki. Wizyta skutkuje powstaniem płatności.

Płatność – kwota obciążająca pacjenta w związku
z wykonanymi usługami medycznymi. Płatność określana jest zgodnie z
cennikiem opłat za usługi medyczne.

Rachunek – druk poświadczający wpłacenie
pewnej kwoty za otrzymane świadczenia medyczne.

Rezerwacja wizyty – ustne, pisemne lub
telefoniczne zarezerwowanie terminu wizyty. Lekarz nie może mieć dwóch
wizyt jednocześnie.

Wzór druku – definicja druku w systemie, określa
jakie dane mają się znajdować na danym druku oraz sposób ich prezentacji.

Cennik usług medycznych – określa ceny za poszczególne usługi
medyczne świadczone przez przychodnie. Każda świadczona usługa musi znajdować
się w cenniku.

Metody strukturalne

Z perspektywy historycznej, metody strukturalne są starsze
od metod obiektowych. W metodach tych system widziany jest w dwóch aspektach.
Pierwszy opisuje dane, drugi zaś procesy, operujące na tych danych; który
aspekt jest ważniejszy, zależy od typu projektowanego systemu [1]. Należy
zauważyć, że idea projektowania strukturalnego jest pochodną paradygmatu
programowania strukturalnego który mówi, iż programy to algorytmy i dane (na
których operują te algorytmy). Patrząc na system informatyczny w kategoriach
projektowania strukturalnego wystarczy zbudować dwa modele systemu:

  • model procesów,
  • model danych.

Owo rozdzielenie systemu na procesy i dane stanowi zasadniczą
różnicę między metodami strukturalnymi i obiektowymi. Należy pamiętać, iż
metody obiektowe pozwalają spojrzeć na system całościowo. Ceną za to płaconą
jest większa trudność metodologii obiektowej. W podejściu strukturalnym,
podobnie jak i w innych metodach, należy wyróżnić modelowanie i właściwe
projektowanie. Należy jednak, o czym była już mowa, zdać sobie sprawę z
tego, że znaczna część projektów jest realizowana hybrydowo. Oznacza to, że
sam system jest projektowany obiektowo (być może z użyciem modelowania procesów
biznesowych), ale ze względu na zastosowanie relacyjnej bazy danych, na pewnym
etapie konieczne jest zastosowanie metod strukturalnych, co rodzi poważne
konsekwencje dla całego projektu. Należy jeszcze zaznaczyć, że w literaturze
[1] modelowanie jest określane mianem analizy strukturalnej. Autor będzie
jednak konsekwentnie używał terminu modelowanie w odniesieniu do projektu, który
abstrahuje od szczegółów rozwiązań technicznych. Istnieją dwa podejścia
do projektowania:

  • Top-down
  • Bottom-up.

W pierwszym wychodzi się od bardziej złożonej funkcjonalności
dokonując jej stopniowej dekompozycji, czyli schodząc w dół. Drugie podejście
zakłada zaprojektowanie pewnych funkcji-prymitywów, które będą realizowały
podstawowe funkcje, a następnie przy ich użyciu realizowanie bardziej złożonych
zadań, aż do uzyskania pełnej funkcjonalności systemu. Poniżej
zaprezentowano podejście pierwsze – opierające się o dekompozycję systemu.
Podejście drugie będzie bardziej właściwe przy projektowaniu systemu
operacyjnego. Projektowanie rozpocznie się, z dużym prawdopodobieństwem, od
zdefiniowania funkcji realizujących podstawowe operacje wejścia – wyjścia.
Dopiero na samym końcu zaprojektuje się polecenia systemowe. Podobnie może
wyglądać projektowanie motoru bazy danych, który sam (bez pośrednictwa
systemu plików) zarządza całym dyskiem. Podejście drugie będzie stosowanie
tam, gdzie system działa „blisko” sprzętu i sprzęt determinuje działanie
systemu. Często stosuje się oba podejścia „idąc z projektem jednocześnie
od góry i od dołu”.

Modelowanie procesów – diagramy przepływu danych

Diagramy przepływu danych pozwalają na modelowanie procesów
w systemie informatycznym lub przedsiębiorstwie. Diagramy DFD (ang. Data
Flow Diagram
) pozwalają na zobrazowanie funkcjonalnego aspektu systemu. W
skład diagramów DFD [za 1] wchodzą:

  • procesy,
  • przepływy,
  • magazyny,
  • terminatory.

Procesy (będące odpowiednikami funkcji)1produkują,
na podstawie otrzymanych danych, pewne wyniki. Innymi słowy, proces dokonuje
pewnej operacji na danych. Przykładowy proces, sprawdzający czy pacjent jest
zarejestrowany w systemie pokazano na rysunku 2.


Rys. 3. Przykładowy proces

Przepływy służą do modelowania wymiany danych między
procesami. Przepływ symbolizuje strzałka. Może on posiadać nazwę.

Magazyny służą do modelowania trwałych danych. Mogą
to być pliki lub bazy danych, jeśli modelowanym systemem jest system
informatyczny [1]. Magazyn symbolizują dwa równoległe poziome odcinki.

Terminatory służą do reprezentowania bytów znajdujących
się poza modelowanym systemem informatycznym. Terminatory są reprezentowane w
postaci prostokątów. Trzeba pamiętać, że ani analitycy, ani projektanci nie
mają na nie żadnego wpływu. Przykład procesu, który rejestruje nowego
pacjenta w systemie pokazano na rysunku 3. Terminatorem jest ‘Pacjent’,
magazynem ‘Rejestr Pacjentów’, proces nosi zaś nazwę ‘Dodaj Dane
Pacjenta Do Rejestru’. Na rysunku są dwa przepływy etykietowane ‘Dane
Pacjenta’.


Rys. 4. Rejestracja Pacjenta

Diagramy DFD są hierarchiczne, co oznacza, że można dokonać
dekompozycji danego procesu. Diagramy powinno się tak rysować aby były
czytelne. W pracy [1], podano, iż nie powinno się na jednym diagramie
umieszczać więcej niż 6 procesów i powiązanych z nimi magazynów, przepływów
i terminatorów ze względu na to, że diagram powinien być łatwo czytelny dla
człowieka. Badania psychologiczne dowodzą, iż człowiek może bez trudu objąć
uwagą właśnie taką ilość detali na rysunku. Diagram może być ponadto
prezentowany klientowi lub kierownictwu, a więc osobom nie mającym z reguły
wykształcenia informatycznego – czytelność jest więc tu sprawą kluczową.
Należy zdać sobie sprawę z tego, że dla różnych osób zarówno po stronie
klienta, jak i po stronie firmy wytwarzającej system, istotne będą diagramy
na różnych poziomach w hierarchii. Kierownictwo nie jest z reguły
zainteresowane zbyt dużą ilością szczegółów, a jedynie dość ogólnym
modelem systemu.

Opis procesów

Jak powiedziano, diagramy DFD mogą być wielopoziomowe –
tworząc strukturę hierarchiczną. Dla procesów znajdujących się na najniższym
poziomie tej struktury trzeba określić, co dany proces robi. W literaturze [1]
podano, iż specyfikacja procesu powinna być tak skonstruowana, aby była
czytelna dla człowieka. Autor jest zdania, że nie jest to wymaganie, które
musi być bezwzględnie spełnione. Opis tego co robią procesy, zdaniem autora,
powinien wynikać z opisu rzeczywistości. Może więc zachodzić sytuacja, w której
klientowi nie pokazuje się nawet diagramów DFD. Jedynym dokumentem, który
stanowi „pomost” pomiędzy klientem i analitykami jest opis słowny. Trzeba
pamiętać, że w metodach obiektowych nie prezentuje się klientowi diagramu
klas czy interakcji, a jedynie opis słowny lub diagramy przypadków użycia.
Opis procesów może więc być:

  • zupełnie nieformalny – słowny,
  • sformalizowany – podobny do strukturalnego języka
    programowania.

Dla klienta, czytelnym będzie w zasadzie, tylko nieformalny
opis słowny. Jest on jednak często dość niejednoznaczny. Jednoznaczny jest
za to opis sformalizowany – ale nie jest on z kolei czytelny dla klienta. Oczywiście
język opisu procesów zależy w dużej mierze od misji systemu. Aby problem
uczynić bardziej widocznym, zostaną przedstawione dwa przykłady:

  • program do obsługi przychodni,
  • program matematyczny do obliczeń numerycznych.

Proces rejestracji pacjenta w systemie można bardzo łatwo
opisać w języku polskim np.

  1. Pobierz dane o pacjencie,
  2. Sprawdź, czy pacjent istnieje,
  3. Jeśli pacjent istnieje to wyświetl komunikat ‘Taki pacjent już
    istnieje w systemie’ a następnie zakończ.
  4. Jeśli pacjent nie istnieje, dodaj go do rejestru i zakończ.

Opis taki jest prosty i czytelny. Jest on pomimo użycia języka
naturalnego jednoznaczny. (To, jakie dane są pobierane, można ustalić na
podstawie słownika systemu, który został wcześniej podany). Co jednak stanie
się, gdy przedmiotem opisu ma być proces obliczania numerycznego całki
oznaczonej? Opis słowny będzie dla matematyków śmieszny. Czytelnym będzie
dla nich zapis w postaci równania. Uzasadnione wydaje się być twierdzenie, iż
opis procesów nie powinien wynikać ze zwyczajów panujących w danej firmie, a
od misji tworzonego systemu. Pewnym potwierdzeniem tego faktu może być idea
wytwarzania oprogramowania, oparta o koncepcje rodzin – gdzie, jak już
powiedziano, definiuje się język opisu systemów danego typu.

Aktywności w obrębie procesów, mogą być również
zapisane w postaci diagramów. Dla zapisu dowolnego algorytmu wystarczy możliwość
zapisu: sekwencji, instrukcji warunkowej oraz instrukcji iteracyjnej. Mówi o
tym twierdzenie Bohem-Jacopini. (Warto dodać, iż wynikają z niego bardzo
znamienne skutki w dziedzinie języków programowania – aby zapisać dowolny
algorytm, wystarczą instrukcje: przypisania, warunkowa, iteracyjna. Tak więc,
przy pomocy języka oferującego tak ubogi zestaw instrukcji, można napisać
dowolny program. Co więcej, można udowodnić, iż instrukcja warunkowa nie
jest konieczna, albowiem da się ją zastąpić instrukcją iteracyjną).
Instrukcja zapisana jest w formie prostokąta, instrukcja warunkowa zaś w
postaci rombu.


Rys. 5. Przykładowy diagram opisujący proces

Na rysunku 5 przedstawiono przykładowy diagram opisujący
pewien proces, można go „natychmiast” przekształcić
w kod np. w języku C:

if ( x > 5)
y = 0;
else
y = 1;

Wadą takich diagramów [2] jest ich zbytnia elastyczność
– nie wymuszają one modularności programu. Praktycznie każda struktura może
być reprezentowana w postaci takiego grafu. Pozostaje jeszcze zapytać, czy dla
systemu – nazwijmy to „ogólnego przeznaczenia” – ktoś będzie tak dokładnie
chciał specyfikować procesy. Autor nie spotkał się z projektami o takiej
szczegółowości, aczkolwiek była by ona właściwa dla takich systemów, od
których poprawnego działania zależy życie ludzkie. Tu jednak pojawi się
pytanie, czy metodologia strukturalna jest odpowiednia dla takich systemów –
czy nie należy zastosować metod formalnych?

Inną metodą opisu procesów są diagramy Nassi-Schneiderana,
które zostały zastosowanie w dużej ilości projektów. Jeden diagram NS
odpowiada procesowi lub procedurze. Przykładowa procedura mogłaby wyglądać
jak na rysunku 6.


Rys. 6. Przykładowy diagram NS

Procedura nazywa się Oblicz, poniżej nazwy znajduje
się instrukcja warunkowa. Jeśli warunek jest spełniony, to wykonywany jest
blok w lewym kwadracie, w wypadku przeciwnym wykonywany jest blok w prawym
kwadracie. Diagram NS może być przetłumaczony na następujący kod w języku
C:

void Oblicz(){
if (x>5)
y=0;
else
y=1;
}

Zmiennych nie zadeklarowano, zakładając że są globalne.
Procedurę zapisano w języku C++ w postaci funkcji, która nie zwraca żadnej
wartości. W [2] podano następujące zalety diagramów NS:

  • procedura ma dokładnie jeden punkt wejścia i jeden punkt
    wyjścia,
  • nie ma odniesień do innych stron w dokumentacji, nie da
    się reprezentować „dużych procedur”. Wymusza to modularyzację sytemu.
    (Procedura zapisania w języku programowania powinna mieścić się na jednym
    ekranie),
  • Trudno jest rysować mocno zagnieżdżone instrukcje.
  • Nie ma instrukcji skoku.
  • Zastosowanie diagramów NS powoduje, że kod jest zwięzły
    i czytelny.

Należy jeszcze podkreślić, że zastosowanie procesów nie
jest aż tak bardzo charakterystyczne dla metod strukturalnych, jak się
powszechnie uważa. W metodologiach obiektowych można również modelować
procesy tak, aby w graficzny sposób przedstawić działanie firmy. Diagramy są
inne niż w przypadku prezentowanych diagramów DFD, ale idea jest dość
podobna. Ponadto należy zdać sobie sprawę,
że diagramy procesów abstrahują od postaci danych.

Modelowanie danych

Dane można modelować przy pomocy diagramów związków
encji, które są nazywane diagramami ERD. Trzeba podkreślić, że dane są w
metodologiach strukturalnych bierne (nie wykonują żadnych operacji). Operacje
są wykonywane na danych. Diagramy ERD opisują same dane i relacje pomiędzy
tymi danymi. Jeśli chodzi o dane, to różnica pomiędzy modelowaniem a
projektowaniem polega przede wszystkim na różnej szczegółowości modeli oraz
na pominięciu
w modelu encji, nie reprezentujących bytów świata rzeczywistego, a związanych
z rozwiązaniami technicznymi. (Podobnie jak w metodach obiektowych, dobrym
przykładem mogą być różnego rodzaju słowniki). Na poziomie modelowania można
abstrahować od atrybutów danych, skupiając się jedynie na związkach pomiędzy
nimi. Na rysunku 5 przedstawiono prosty diagram ERD. Występują na nim dwie
encje: Pacjent oraz Lekarz. Pomiędzy encjami zachodzi relacja
Leczy, typu wiele do wielu – oznacza to, że lekarz leczy wielu pacjentów,
a pacjent może być leczony przez wielu lekarzy.


Rys. 7. Prosty diagram ERD

Proces znajdowania encji na podstawie opisu rzeczywistości i
wywiadów z klientem, jest oczywiście iteracyjny.

W kolejnych wersjach pojawiają się pewne nowe encje
i relacje – inne są z modelu usuwane. Nie musi on oczywiście odpowiadać
modelowi danych w bazie danych lub systemie. Model danych może być podzielony
na moduły,
w celu zwiększenia jego czytelności. Kandydatami na encje są z reguły
rzeczowniki występujące w opisie rzeczywistości. Modelując dane (aczkolwiek,
jak powiedziano, model nie musi odpowiadać rzeczywistej strukturze w bazie
danych czy systemie) należy, przynajmniej pobieżnie, zastanowić się nad ich
wielkością. Wybiegając w rozważaniach trochę naprzód, warto wspomnieć, iż
wielu doświadczonych projektantów baz danych nie zastanawia się przy
projektowaniu nad czasem realizacji zapytań przez motor bazy danych dla przyjętego
modelu danych. Często należałoby być w tej kwestii pragmatykiem. W większości
projektowanych systemów, encje w pewnym momencie ‘staną się’ tabelami w
bazie danych. Załóżmy, że encji Pacjent w modelu odpowiadają dwie
tabele w bazie danych. Dla ustalenia uwagi, niech będą to encje: Osoba
oraz Pacjet z zaprezentowanego opisu rzeczywistości. Niech w tabeli Osoba
przechowywane będą: id, imię, nazwisko, NIP, PESEL, numer telefonu, numer
telefonu komórkowego, adres
, w tabeli Pacjent natomiast: id_osoby,
data_rejestracji, płatność
. Chcąc uzyskać informacje na temat danego
pacjenta możemy użyć (w SQL) podzapytania – potrzebne są dane z tabeli Osoba
oraz Pacjent. Wszystko jest w porządku, jeśli baza zawiera setki lub
tysiące rekordów. Co stanie się jednak, gdy nasza przychodnia jest bardzo duża
i ma 30 000 000 pacjentów, których obsługuje 30 000 tysięcy lekarzy (tak więc
liczba osób w systemie jest większa niż 30 000 000)? Pamiętamy, że
podzapytanie jest realizowane w ten sposób, iż tworzone jest złączenie dwóch
tabel (każdy rekord jednej z każdym rekordem z drugiej), a następnie
wybierane są rekordy spełniające określony warunek. Łatwo można sobie
wyobrazić, jak duża ilość danych musi zostać przetworzona w celu
zrealizowania takiego zapytania. Formalnie wszystko jest w porządku: na
podstawie opisu rzeczywistości analitycy stwierdzili że: Pacjent jest osobą.
Następnie projektanci zaaprobowali taką decyzję, tworząc bazę danych o
strukturze takiej jak opisano powyżej. Podjęte decyzje są w pełni zgodne ze
sztuką projektowania. Nikt nie uwzględnił jednak ilości danych. Jest to
przykład na to, iż projektując system trzeba zdawać sobie sprawę nie tylko
z wymagań funkcjonalnych ale też w wymagań niefunkcjonalnych (czas
oczekiwania na odpowiedź). Następnie należy przeprowadzić studia nad strukturą
systemu, wielkością przetwarzanych danych itp., nie tylko jeśli chodzi o
fizyczne rozmieszczenie urządzeń ale i w zakresie modelu danych.

c.d.n.

Literatura

[1] E. Yourdon Analiza strukturalna WNT

[2] The Sobers Group Structured Design with Nassi_Schneideran Charts