1

Metody strukturalne

Opr. na podstawie : Krzysztof Sacha „Inżynieria oprogramowania” PWN 2010

Podstawą procesu wytwórczego, wykształconego przez metodykę strukturalną, jest
dostrzeżenie i uznanie potrzeby zbudowania przed implementacją dwóch różnych
modeli oprogramowania:



abstrakcyjnego modelu analitycznego (essential model), opisującego przebieg
przetwarzania danych w sposób niezależny od technologii realizacyjnej,



oraz konkretnego modelu projektowego (implementation model),
pokazującego sposób wykonania tego przetwarzania w wybranej technologii
realizacyjnej.

Dopiero następnym krokiem procesu wytwórczego jest implementacja programów
oraz integracja całości oprogramowania, dokonywana w sposób opisany w modelu
projektowym.

Takie wieloetapowe podejście ułatwia zapanowanie nad złożonością problemu dzięki
rozdzieleniu zagadnień rozważanych na różnych etapach przedsięwzięcia.
Opracowanie kolejnych modeli, opisujących budowane programy z coraz większą
dokładnością, wyznacza podział całości prac na sekwencyjne, kolejno wykonywane
fazy, wpisujące się w kaskadowy model wytwarzania oprogramowania !!!!

Najważniejsze elementy metodyki strukturalnej określają zestaw modeli
przedstawiających istotne cechy oprogramowania na różnych poziomach
szczegółowości, techniki modelowania wskazujące sposób i kolejność budowania
modeli oraz metody weryfikacji poprawności i spójności kolejno powstających modeli.
Wspólną cechą modeli strukturalnych jest sposób opisywania przetwarzania,
wyraźnie rozróżniający pasywne dane i aktywne działania, opisywane zgodnie z
zasadą dekompozycji funkcjonalnej. Tak zorganizowany model dobrze odpowiada
naturze strukturalnych języków programowania (C, Fortran, Cobol itp), w których
podstawowymi jednostkami syntaktycznymi są definicje danych (zmiennych) i
działające na tych danych podprogramy.

2

1. Narzędzia modelowania

Koncepcyjne narzędzia modelowania strukturalnego obejmują szereg diagramów
odwzorowujących strukturę i relacje zachodzące między jednostkami danych oraz
zależności zachodzące między procesami realizującymi wymagane przez
użytkownika przetwarzanie. Podstawowymi rodzajami modeli, budowanymi w
kolejnych krokach procesu wytwarzania oprogramowania, są:



hierarchia funkcji, przedstawiająca wymagania użytkownika zapisane w
postaci listy funkcji do wykonania;



diagram przepływu danych, pokazujący funkcje oprogramowania oraz dane
przepływające między tymi funkcjami w czasie realizacji przetwarzania;



diagram encji, obrazujący najważniejsze struktury danych podlegające
przetwarzaniu oraz relacje istniejące między tymi strukturami;



schemat struktury programu, pokazujący podprogramy realizujące funkcje oraz
definiujący sposób wywoływania i przekazywania danych między
podprogramami.

Wszystkie budowane modele mają czytelną postać graficzną i dobrze określone
znaczenie odwołujące się do formalnych koncepcji matematycznych.

1.1. Hierarchia funkcji
Każdy, nawet bardzo złożony, proces przetwarzania danych można przedstawić w
postaci zestawu funkcji, wykonywanych na opisujących ten proces danych. Jeżeli
funkcje wchodzące w skład tego zestawu są nadal złożone, to można je dalej rozbić
na kolejny zbiór funkcji prostszych. Na przykład, działanie dużej firmy
ubezpieczeniowej można opisać jako złożenie funkcji wykonywanych przez
poszczególne jej działy:

1. Prowadzenie działalności ubezpieczeniowej
2. Prowadzenie działalności ekonomicznej
3. Zarządzanie
4. ...

3

Każdą z tych funkcji można opisać dokładniej w postaci złożenia prostszych funkcji
wykonywanych przez różne komórki działu. Na przykład, prowadzenie działalności
ekonomicznej zawiera w sobie kilka rodzajów działań:

1. Obsługa inwestycji
2. Obsługa inwestycji kapitałowych
3. Obsługa finansowo-księgowa

Dekompozycję funkcji można kontynuować dowolnie długo, opisując działanie
przedsiębiorstwa w coraz drobniejszych szczegółach. Na przykład, obsługa inwestycji
kapitałowych może się składać z następujących elementów:

1. Przegląd możliwości inwestowania
2. Przygotowanie zleceń inwestycyjnych
3. Okresowa ocena wyników inwestowania
4. ...

Kresem dekompozycji staje się osiągnięcie poziomu funkcji elementarnych, tzn.
takich, których wykonanie jest czynnością niepodzielną. Inaczej mówiąc, funkcja
elementarna może być wykonana lub nie, ale nie może być wykonana częściowo. Na
przykład, zlecenie inwestycyjne może być prawie przygotowane - przygotowanie
zleceń nie jest więc funkcją elementarną. Ale gotowe zlecenie zakupu akcji może być
albo złożone na giełdzie, albo nie. Nie można go złożyć częściowo. Złożenie zlecenia
na giełdzie jest więc funkcją elementarną.

Wynikiem takiej systematycznej, zstępującej coraz niżej, dekompozycji działań jest
hierarchia funkcji (hierarchy of functions), przedstawiająca rozważany proces
przetwarzania danych na wybranym poziomie szczegółowości. Hierarchię funkcji
można zapisać w sposób tekstowy, w formie przypominającej spis treści książki, albo
graficznie, w postaci schematycznego rysunku (rys. 1). Zaletą opisu tekstowego jest
brak ograniczeń na rozmiar modelu oraz możliwość uzupełnienia nazw funkcji
krótkimi, jednozdaniowymi komentarzami wyjaśniającymi ich zakres i przeznaczenie.
Zaletą modelu graficznego jest możliwość zwartego przedstawienia całości
przetwarzania na jednej kartce, możliwej do ogarnięcia jednym spojrzeniem. Na ogół
wygodnie jest przygotować obydwie formy modelu.

4

Rysunek 1. Hierarchia funkcji firmy ubezpieczeniowej

Warto podkreślić, że hierarchia funkcji jest modelem przedsiębiorstwa, a nie menu
systemu informatycznego. Model powstaje w fazie strategicznej, gdy nie jest jeszcze
przesądzone, które funkcje będą w przyszłości wykonywane automatycznie, a które
pozostaną przy realizacji ręcznej. Kluczowe decyzje dotyczące zakresu
funkcjonalności budowanego oprogramowania wyraża się w tym modelu przez
dodanie lub usunięcie wybranych funkcji. Podstawowe dane, na których mają działać
funkcje, można opisać osobno, w formie tekstowej lub w postaci diagramu encji. Po
podjęciu decyzji o realizacji systemu i jego zakresie hierarchia funkcji staje się
naturalną częścią umowy realizacyjnej, opisującą wymagania funkcjonalne.

Zaletami hierarchii funkcji są prostota, czytelność i przydatność podczas
formułowania zapisów umowy. Ze względu na swą prostotę model ma też
ograniczenia, którymi są: brak pokazania zależności między funkcjami oraz brak
pokazania danych, na których działają funkcje.


1.2. Diagram przepływu danych
Diagram przepływu danych (data flow diagram) jest znacznie dokładniejszym
modelem przetwarzania, pokazującym nie tylko funkcje, ale także dane, które muszą
przepływać w określonym porządku między funkcjami w celu wytworzenia
pożądanych wyników. Model ma postać grafu (rys. 2), którego węzły reprezentują
procesy przetwarzające (funkcje) oraz magazyny danych (zbiory), a łuki skierowane

5

pokazują przepływy danych między procesami i magazynami danych. Procesy,
rysowane na diagramie w postaci okręgów, są elementami aktywnymi, które mogą
pobierać dane z magazynów lub odbierać je od innych procesów, przetwarzać i
przekazywać wyniki do magazynów lub do innych procesów. Magazyny, rysowane
jako niedomknięte prostokąty, są elementami pasywnymi, które mogą tylko
przechowywać dane.

Rys 2. Diagram przepływu danych

Przetwarzanie obrazowane przez diagram zaczyna się w chwili pojawienia się danych
przenoszonych przez przepływy wejściowe. Dostępność danych wejściowych
umożliwia wykonanie procesu, który realizuje przypisaną do niego funkcję i wytwarza
wyniki przenoszone przez przepływy wyjściowe do magazynów lub do kolejnych
procesów. W ten sposób kolejne porcje danych przepływają przez diagram aż do
momentu, w którym opuszczą system w postaci finalnych wyników przetwarzania.

Semantyka diagramu nie określa kolejności wykonania procesów, które mogą
wykonać się natychmiast, gdy tylko otrzymają wszystkie niezbędne do ich wykonania
dane wejściowe. Na przykład, proces

Rejestracja zamówienia na rys. 2 wykonuje się

w chwili pojawienia się przepływu wejściowego

Zamówienie. Wynikiem wykonania

procesu jest zapisanie zarejestrowanego zamówienia w magazynie

Zamówienia do

realizacji. Ponieważ dane znajdujące się w magazynach są zawsze dostępne dla
sięgających po nie procesów, więc proces

Planowanie wykonania może wykonać się

w dowolnej chwili, niezwiązanej z tempem zapełniania magazynu. Procesy
Wykonanie produktu i Wystawienie faktury mogą wykonać się dopiero po pojawieniu
się wyników procesu

Planowanie wykonania, ale porządek ich wykonania -

6

równolegle lub jeden po drugim w dowolnej kolejności - pozostaje nieokreślony.
Nieokreślony jest także mechanizm realizacji przepływów danych.

Procesy występujące na diagramie przepływu danych mogą realizować funkcje proste
lub złożone, podobnie jak funkcje występujące w hierarchii funkcji. Istotnym
elementem opisu, którego diagram nie zawiera, jest specyfikacja przetwarzania
procesu, czyli określenie sposobu przekształcania danych wejściowych w dane
wyjściowe. Koniecznego uzupełnienia tego braku można dokonać na dwa sposoby:
przez dekompozycję złożonego procesu i pokazanie jego wewnętrznej struktury na
bardziej szczegółowym diagramie przepływu danych, przez opisanie działania
prostego procesu w języku naturalnym (np. polskim), w postaci graficznej (np. sieci
działań), w pseudokodzie lub w notacji matematycznej.

elementów

czynności

Rysunek 3. Diagram 2: Planowanie wykonania

Przykładem dekompozycji może być rozbicie procesu Planowanie wykonania z rys. 2
na bardziej szczegółowe czynności opisane za pomocą diagramu pokazanego na rys.
3. Warto zauważyć, że na diagramie obrazującym strukturę procesu mogą pojawić się
nie tylko procesy składowe, ale także wewnętrzne magazyny danych. Elementarnym
warunkiem poprawności takiej dekompozycji jest zgodność przepływów wejściowych i
wyjściowych dekomponowanego procesu z przepływami wejściowymi i wyjściowymi
opisującego ten proces diagramu.

Dekompozycję procesów można powtórzyć wielokrotnie, budując wielopoziomową
hierarchię diagramów, w której na najwyższym poziomie znajduje się diagram numer
0, przedstawiający całość przetwarzania (w naszym przykładzie jest to rys. 2), a na
niższych poziomach występują diagramy modelujące poszczególne procesy z
rysunku wyższego poziomu (rys. 4). Numer diagramu niższego poziomu odpowiada

7

zawsze numerowi procesu na diagramie wyższego poziomu. Rozwijając hierarchię
diagramów, należy dbać o spójność tego rozwinięcia - wszystkie przepływy łączące
się z procesem na diagramie wyższego poziomu muszą mieć swoje odpowiedniki w
przepływach wchodzących lub wychodzących z diagramu rozwijającego ten proces
na niższym poziomie. Proces dekompozycji można kontynuować dowolnie długo, aż
do osiągnięcia takiego poziomu szczegółowości, na którym bez trudu można opisać
działanie wszystkich procesów składowych. Opisy procesów znajdujących się na
diagramach najniższego poziomu, zwykle zajmujące co najwyżej jedną stronę
papieru, nazywa się minispecyfikacjami.

Rysunek 4. Hierarchiczna organizacja diagramów przepływu danych

Diagram przepływu danych jest modelem analitycznym, niezależnym od technologii
realizacji przetwarzania. Można go wykorzystać do modelowania zarówno działań
przedsiębiorstwa, jak i oprogramowania. Zasadniczą wartością modelu jest
dekompozycja całości przetwarzania na dobrze określone jednostki (procesy i
magazyny danych) oraz pokazanie wzajemnych powiązań tych jednostek. Model jest
intuicyjny i zrozumiały dla czytelnika bez specjalistycznego przygotowania.

1.3. Diagram encji
Funkcje realizowane przez oprogramowanie systemu informatycznego działają na
danych, które opisują fragmenty świata objęte działaniem systemu. W tym świecie
występują rozmaite obiekty, np. klienci, towary i zamówienia w przedsiębiorstwie
handlowym, które można opisać według pewnego schematu. Na przykład, każdy

8

klient przedsiębiorstwa ma nazwę i adres, każdy towar jest charakteryzowany przez
nazwę, nazwę producenta i cenę, a każde zamówienie ma datę wystawienia i adres
dostawy. Pojedyncze elementy opisu, takie jak nazwa, adres lub cena, są nazywane
atrybutami obiektu. Kategoria obiektów opisywanych za pomocą tego samego zbioru
atrybutów jest nazywana encją (entity).

W ten sposób każda encja opisuje pewien rodzaj obiektów, charakteryzowanych w
dziedzinie zastosowania przez ustalony zestaw atrybutów. Obiekty różnego rodzaju
są na ogół opisywane przez różne zestawy atrybutów (tzn. tworzą różne encje),
natomiast obiekty tego samego rodzaju są opisywane przez te same atrybuty. Zbiór
atrybutów obiektu powinien być tak dobrany, aby różnym obiektom danego rodzaju
odpowiadały różne wartości atrybutów - obiekty o tych samych wartościach atrybutów
są niemożliwe do odróżnienia. Przykładowy opis towarów sprzedawanych w sklepie z
oponami samochodowymi jest pokazany na rys. 5.

Można zauważyć, że wartości atrybutów nie pokrywają się dla żadnych dwóch
rodzajów opon. Mimo to żaden atrybut nie identyfikuje jednoznacznie towaru i aby
wskazać pożądany typ opony, trzeba podać wartości trzech różnych atrybutów. Nie
jest to wygodne w praktyce, dlatego w tabeli opon dodany został dodatkowy atrybut -
numer katalogowy, który jednoznacznie identyfikuje konkretny typ opony. Atrybut,
którego wartość jednoznacznie wskazuje obiekt encji, jest nazywany kluczem.

Numer Producent Nazwa

Rozmiar

Cena

1

Michelin Alpin A3

175/65 R14 315,00

2

Michelin Alpin A3

195/60 R15 416,00

3

Kleber

Krisalp Hp

195/65 R15 315,00

4

Pirelli

W190 Snowsport 195/60 R15 392,84

5

Uniroyal MS Plus 55

215/65 R15 424,56

Rysunek 5. Lista towarów sklepu i model opisu tych danych w postaci encji Towar

Opisanie sposobu działania, a później zbudowanie oprogramowania wymaga
zdefiniowania nie tylko wszystkich encji i ich atrybutów, lecz także zależności
istniejących między obiektami poszczególnych encji. We wspomnianym wyżej

9

przedsiębiorstwie handlowym zamówienia nie biorą się z powietrza, lecz są składane
przez konkretnych klientów. Z kolei celem złożenia zamówienia jest wskazanie
pewnych towarów, które dany klient ma zamiar zakupić. Między klientami,
zamówieniami i towarami istnieją więc zależności, które nadają sens ich istnieniu.

Modelem danych obrazującym encje i ich powiązania jest diagram encji (entity-
-relationship diagram), zwany też diagramem encja-związek bądź diagramem
związków encji, pokazany przykładowo na rys. 6. Podstawowymi elementami
diagramu są encje, rysowane w postaci prostokątów z wpisaną wewnątrz nazwą encji
i listą atrybutów, oraz związki (relacje) występujące między encjami, przedstawiane
jako linie łączące encje. Fakt istnienia związku między dwoma encjami oznacza, że
pewne obiekty jednej encji są w jakiś sposób powiązane z pewnymi obiektami drugiej
encji. Na przykład, każde zamówienie zostało wystawione przez jakiegoś klienta - tym
samym każde konkretne zamówienie (każdy obiekt encji Zamówienie) jest
jednoznacznie związane z konkretnym klientem, który to zamówienie wystawił.
Podobnie, każde zamówienie jest jednoznacznie związane z zestawem towarów,
których to zamówienie dotyczy.

Rysunek 6. Diagram encji przedstawiający związki łączące różne obiekty w systemie
sprzedaży

Charakter związku łączącego dwie encje można opisać na diagramie za pomocą
nazwy, wyjaśniającej rolę tego związku w rzeczywistym świecie. Nazwę umieszcza
się na ogół w pobliżu encji (blisko końca linii) i interpretuje z jej punktu widzenia. Taka
konwencja zapisu umożliwia opisywanie zależności między danymi w zrozumiałym
języku naturalnym, np.: Klient składa Zamówienie, Zamówienie wskazuje Towar, co
bardzo ułatwia analitykom komunikację z użytkownikami i znacząco podnosi
wiarygodność dokonywanej przez nich weryfikacji modelu. Niektóre narzędzia
wspomagające proces opracowania oprogramowania mogą generować opisy w
języku naturalnym automatycznie, na podstawie diagramu encji.

10

Inne symbole, jakie mogą wystąpić przy końcach linii oznaczającej związek, tzn.
poprzeczna kreska, „kurza łapka" i kółko, określają liczbę obiektów danej encji, które
mogą być związane z każdym obiektem encji znajdującej się na drugim końcu linii. W
większości przypadków na końcu linii występują dwa symbole, określające
najmniejszą i największą dozwoloną liczbę obiektów. W przyjętej konwencji oznaczeń
kółko oznacza 0, poprzeczna kreska 1, a „kurza łapka" wskazuje, że w związku może
uczestniczyć wiele obiektów. W ten sposób, zgodnie z modelem przedstawionym na
rys. 6, każde

Zamówienie jest złożone przez jednego Klienta. Nie ma zamówień,

których nikt nie złożył, nie ma też zamówień złożonych łącznie przez kilku klientów.
Natomiast każdy klient mógł złożyć wiele zamówień, ale mógł też jeszcze nie złożyć
żadnego. Z kolei każde

Zamówienie może wskazywać wiele Towarów, jednak nie

mniej niż jeden (nie ma zamówień, które nie wskazują żadnego towaru). Podobnie,
każdy

Towar może być wskazany w wielu Zamówieniach. Natomiast tego, czy mogą

istnieć towary, które nie są wskazane w żadnym zamówieniu, model nie mówi - być
może na tym etapie prac jeszcze tego nie wiemy.

Podczas budowy modelu danych mogą pojawić się encje, które nie są zupełnie
jednorodne. Na przykład, wśród towarów sklepu motoryzacyjnego -
charakteryzowanych zawsze przez nazwę, nazwę producenta i cenę - mogą się
znaleźć opony charakteryzowane dodatkowo przez rozmiar, foteliki dziecięce
charakteryzowane przez wagę dziecka i dodatkowy opis oraz różne drobne
akcesoria, takie jak kamizelki odblaskowe, które poza opisem tekstowym żadnych
innych atrybutów nie mają. Różne listy atrybutów oznaczają, że w istocie mamy do
czynienia z różnymi encjami, które opisują różne szczególne przypadki Towaru:
Opony, Foteliki, Pokrowce itd. Takie sytuacje opisuje się w modelu za pomocą
specjalnej notacji pokazanej na rys. 7. Łatwo zauważyć, że encja Towar grupuje
atrybuty wspólne dla całej kategorii produktów, podczas gdy pozostałe encje
zawierają wyłącznie atrybuty wyróżniające produkty konkretnego rodzaju. W ten
sposób encja Towar jest uogólnieniem wszystkich konkretnych rodzajów towaru.
Semantyka związku uogólnienia zawiera w sobie regułę dziedziczenia: każdy obiekt
typu szczegółowego, np. Opona lub Fotelik, jest szczególnym przypadkiem typu
ogólnego, po którym dziedziczy wszystkie atrybuty i wszystkie związki. Zatem,

11

zgodnie z rys. 6 i 7, każda opona i każdy fotelik mogą być wskazane w zamówieniu
jakiegoś klienta.

Rysunek 7. Modelowanie związku uogólnienia (towar i jego szczególne przykłady)

Diagram encji nie ma reprezentacji hierarchicznej. Jeżeli rysunek staje się zbyt duży,
można go po prostu podzielić na części, tworząc np. odrębne diagramy danych
wykorzystywanych przez różne działy przedsiębiorstwa. Bardzo często dla
oszczędności miejsca pokazuje się na diagramie tylko nazwy encji, bez wyliczania ich
atrybutów (które w takim przypadku trzeba udokumentować osobno).


1.4. Schemat struktury
Analityczne modele przetwarzania, takie jak hierarchia funkcji i diagram przepływu
danych, opisują dokładnie, co ma być zrobione, nie wyjaśniają jednak wcale, jak ma
być zbudowany program, który to przetwarzanie wykona. Schemat struktury
programu (structure chart) jest modelem projektowym, który przedstawia budowę
programu. Najważniejszymi elementami modelu są: podprogramy, rysowane jako
prostokąty; wywołania podprogramów, rysowane jako strzałki z zaznaczonymi obok
argumentami i wynikami wywołań; zbiory i wspólne struktury danych, rysowane jako
skośne równoległoboki lub prostokąty przylegające do podprogramów. Przykładowy
schemat struktury programu ustawiającego przebieg wjazdowy (tzn. drogę wjazdu
pociągu) na komputerowo sterowanej stacji kolejowej jest pokazany na rys. 8.
Widoczny na rysunku łącznik ERR umożliwia kontynuowanie schematu na innym
rysunku.

12

Rysunek 8. Schemat struktury programu ustawiającego drogę wjazdu pociągu na
stację

Nietrudno zauważyć, że postać schematu struktury jest dopasowana do składni
strukturalnych języków programowania, takich jak C, Pascal lub Fortran, których
podstawowe jednostki syntaktyczne odpowiadają bezpośrednio elementom modelu.
Zgodnie ze schematem program

Ustawienie przebiegu wjazdowego wywołuje trzy

podprogramy:

Odczytanie położenia pociągu, Odczytanie rozkładu jazdy i Ustawienie

przebiegu. Pierwszy z tych podprogramów zwraca w wyniku numer i pozycję
wjeżdżającego pociągu, drugi odczytuje ze zbioru

Rozkład jazdy numer przebiegu

przewidzianego dla pociągu o podanym numerze, a trzeci ustawia zwrotnice
wchodzące w skład wybranego przebiegu.

Argumenty i wyniki wywołań, wyróżnione zaczernionym kółeczkiem, pełnią rolę
sterującą - od ich wartości zależy rodzaj działań, które będą dalej podjęte. Na
przykład, błąd weryfikacji położenia pociągu może spowodować wywołanie przez
podprogram

Odczytanie położenia pociągu jakichś funkcji korekcyjnych (opisanych

na odrębnym schemacie wskazanym przez łącznik ERR).

Warto zauważyć, że chociaż podprogram

Przestawienie zwrotnicy może być

wielokrotnie wywołany wewnątrz programu

Ustawienie przebiegu, to na schemacie

rysuje się tylko jedną strzałkę wywołania. Niektóre metody przewidują jednak

13

umieszczanie na schematach struktury dodatkowych wyróżnień oznaczających
wywołania warunkowe lub wielokrotne.

Schemat struktury jest modelem graficznym obrazującym najważniejsze jednostki
programowe oraz sposób ich wzajemnej współpracy. Koniecznym uzupełnieniem
schematu, niezbędnym dla implementacji programu, jest opis algorytmów działania
podprogramów, tzn. opis sposobu przekształcania danych wejściowych,
otrzymywanych podczas wywołania podprogramu, w wyniki. Źródłem informacji
niezbędnych do opracowania takich specyfikacji jednostek są minispecyfikacje
procesów przeniesione tu z modelu analitycznego.

2. Techniki analizy strategicznej

Pierwszym krokiem prac, poprzedzającym przystąpienie do opracowania
oprogramowania systemu informatycznego, jest określenie roli i zakresu działania
systemu, zdefiniowanie zadań, jakie ma on wypełniać na rzecz otoczenia, oraz
określenie wielkości i wydajności przetwarzania. Zebranie i udokumentowanie tych
informacji umożliwia ocenę kosztów opracowania systemu, analizę opłacalności i
podjęcie decyzji o realizacji przedsięwzięcia (podpisanie umowy) lub jego
zaniechaniu.

W większości przypadków, z jakimi mamy do czynienia w biznesie, administracji i
innych dziedzinach działalności człowieka, systemy informatyczne są budowane w
celu usprawnienia, rozszerzenia lub zastąpienia części działań wykonywanych
dotychczas w inny sposób. Taka sytuacja występuje podczas informatyzacji banków,
przedsiębiorstw produkcyjnych, organów administracji publicznej, a także przy
opracowaniu np. kolejnych wersji gier fabularnych, w które można grać z komputerem
albo z innymi osobami. Dokładny zakres działań systemu w nowej strukturze
organizacji nie jest często na początku prac przesądzony. Racjonalne podejście
analizy strategicznej polega na ustaleniu wszystkich czynności, jakie występują w
organizacji, a następnie określeniu, które z nich mają znaleźć się w zakresie działania
nowego systemu, a które mają pozostać na zewnątrz. Odpowiedź na tak postawione
pytanie wyznacza granice przyszłej aplikacji i wskazuje wymagane funkcje

14

oprogramowania. Kolejnym krokiem może być określenie niezbędnej wydajności
przetwarzania oraz innych wymagań niefunkcjonalnych i na tej podstawie
oszacowanie pracochłonności oraz kosztu opracowania oprogramowania
spełniającego wszystkie tak określone wymagania.

Podstawowe modele tworzone podczas analizy strategicznej obejmują hierarchię
funkcji, opisującą wymagany zakres przetwarzania, oraz diagramy encji,
przedstawiające strukturę przetwarzanych danych. Hierarchia funkcji powstaje w
wyniku dekompozycji opisu całości przetwarzania i wyodrębnienia poszczególnych
funkcji. Diagram encji jest wynikiem ustalenia najważniejszych rodzajów danych oraz
opisania ich struktury wewnętrznej i istniejących między nimi powiązań. Obydwa
modele powstają stopniowo i na każdym etapie pracy odzwierciedlają bieżącą wiedzę
analityków na temat sposobu rozwiązania problemu.

Dalsza część rozdziału opisuje sposób tworzenia i wykorzystania modeli
strukturalnych w kolejnych fazach procesu wytwarzania oprogramowania dla
przykładowego przedsiębiorstwa handlowego, którym jest firma zajmująca się
wysyłkową sprzedażą akcesoriów samochodowych, takich jak opony, felgi, bagażniki
itp. Pełny katalog oferowanych towarów jest dostępny w witrynie internetowej. Firma
przyjmuje zamówienia klientów nadsyłane pocztą elektroniczną i wysyła zamówione
towary pocztą kurierską. Każde przyjęte zamówienie jest potwierdzane e-mailem,
którego treść określa również formę płatności. Zamówienia o wartości
nieprzekraczającej pewnej sumy są opłacane przez klienta przy odbiorze.
Zamówienia o większej wartości klient opłaca przelewem, przed wysłaniem towaru,
na podstawie wystawionej przez firmę faktury pro forma. W przypadku zamówień
małych, lecz dotyczących towarów nietypowych wymagane jest wpłacenie zaliczki.
Firma ma nowy i wydajny system księgowy oraz starą aplikację magazynową. Cały
proces obsługi zamówień jest realizowany ręcznie. Ogromny wzrost sprzedaży zmusił
kierownictwo firmy do unowocześnienia jej struktury i wsparcia działań pracowników
narzędziami informatycznymi. Przy okazji postanowiono dopuścić możliwość
składania zamówień na formularzach internetowych, choć nie zdecydowano się na
prowadzenie typowej sprzedaży przez Internet - dla zmniejszenia ryzyka reklamacji
sklep zachęca do podawania w zamówieniu typu pojazdu klienta, co umożliwia

15

pracownikom weryfikację zgodności zamówienia Z intencjami klienta. Biznesowym
celem przedsięwzięcia jest redukcja kosztów (spadek zatrudnienia i wzrost
wydajności pracy) oraz zwiększenie obrotów dzięki ułatwieniu komunikacji z klientami.

2.1. Modelowanie przetwarzania
Głównym problemem analizy strategicznej jest pozyskanie i uporządkowanie wiedzy
na temat dziedziny zastosowania i wymagań przyszłych użytkowników
oprogramowania. Podstawowe metody pozyskiwania wiedzy obejmują lekturę
dostępnych dokumentów oraz rozmowy z użytkownikami i sponsorami projektu.
Sposobem porządkowania stopniowo gromadzonej wiedzy jest modelowanie
wymagań w postaci hierarchii funkcji.

Dobra hierarchia funkcji nie powstaje od razu. Wręcz przeciwnie, model jest rozwijany
stopniowo i doskonalony w miarę postępów analizy i wzrostu wiedzy o rozważanym
zadaniu. Przykład wstępnego, jeszcze niekompletnego, modelu działania
przedsiębiorstwa sprzedaży wysyłkowej przedstawia rys. 9. Całość działań
związanych z prowadzeniem przedsiębiorstwa wysyłkowego jest tu rozbita na pięć
głównych funkcji, wykonywanych przez różne działy firmy: reklamy, zaopatrzenia,
obsługi magazynu towarów, sprzedaży i zarządzania finansami. Ta ostatnia funkcja
obejmuje ważne czynności rozliczenia z dostawcami i klientami.

Rysunek 9. Wstępna hierarchia funkcji przedsiębiorstwa sprzedaży wysyłkowej

Taki model może powstać już pierwszego dnia analizy, po zapoznaniu się ze
schematem organizacyjnym przedsiębiorstwa i rozmowie z jego szefem. Model nie
jest jeszcze kompletny - przerywane linie na diagramie sugerują potrzebę dalszej

16

dekompozycji funkcji - jednak tworzy dobrą podstawę do dalszych działań. Hierarchia
funkcji jest modelem bardzo intuicyjnym i zrozumiałym dla każdego, bez wielu
dodatkowych wyjaśnień. Przystępując do przeprowadzenia kolejnych wywiadów,
można posłużyć się tym modelem w celu uściślenia rozmowy i uzyskania od
rozmówcy potwierdzenia swojej wizji przedsiębiorstwa.

Kolejne wywiady z użytkownikiem i obserwacja przedsiębiorstwa mogą korygować
pierwotne wyobrażenia o jego funkcjonowaniu. Co więcej, może się okazać, że wbrew
dotychczasowej tradycji i organizacji przedsiębiorstwa pewne funkcje są tak
powiązane, że nie ma powodu, by traktować je oddzielnie. W takim przypadku można
zmodyfikować model, łącząc ze sobą pokrewne funkcje - końcowym celem analizy nie
jest przecież wierne odwzorowanie istniejącego systemu przetwarzania, lecz
zbudowanie takiego systemu, który najlepiej pasuje do profilu działania
przedsiębiorstwa. Podobnie, może się też okazać, że nie od razu dostrzeżemy
wszystkie funkcje przedsiębiorstwa i obecność oraz znaczenie niektórych funkcji
odkryjemy dopiero po pewnym czasie. Na przykład, w modelu z rys. 9 brakuje
zapewne funkcji związanych z zarządzaniem personelem - rekrutacją pracowników,
rozliczaniem wynagrodzeń, planowaniem urlopów i dni wolnych itp.

Po zebraniu większej liczby danych, pochodzących z obserwacji i wywiadów
przeprowadzonych z kierownikami działów firmy, można zbudować kolejny model
przetwarzania, zawierający dokładniejszą hierarchię funkcji. W tym miejscu trzeba
jednak podkreślić, że budowany model nie powinien stać się nadmiernie
szczegółowy. Celem analizy strategicznej nie jest zebranie i opisanie wszystkich
szczegółów przetwarzania, lecz uchwycenie i skonstruowanie syntetycznego obrazu,
który umożliwi zdefiniowanie zakresu pracy oraz oszacowanie jej pracochłonności i
kosztu. Nie ma sztywnych reguł, ale w większości przypadków wystarczy rozwinięcie
hierarchii funkcji do trzech lub co najwyżej czterech poziomów. Model trzeba jednak
uzupełnić opisem słownym określającym sposób wykonania funkcji. W tym celu dla
każdej funkcji na najniższym poziomie hierarchii można podać np.:



zdarzenie inicjujące i szacunkową częstość wykonania funkcji,



słowny opis sposobu wykonania,



kluczowe dane wprowadzane lub wytwarzane przez tę funkcję.

17

Rysunek 10. Ostateczna hierarchia funkcji przedsiębiorstwa sprzedaży wysyłkowej

Hierarchia funkcji przedstawiona na rys. 10 modeluje działanie przedsiębiorstwa
wystarczająco dokładnie, aby na jej podstawie sformułować strategię działania.
Można w tym celu nałożyć na tę hierarchię obszary objęte działaniem już istniejących
systemów i w ten sposób znaleźć istniejące między nimi luki i ewentualne
redundancje. Porównując wyniki tej analizy z priorytetami i możliwościami firmy,
można podjąć decyzję o pozostawieniu pewnych czynności do realizacji ręcznej i -
ostatecznie - wytyczyć zakres nowego projektu. Na przykład, jeśli w rozważanym
przedsiębiorstwie sprzedaży wysyłkowej istnieje dobrze działająca aplikacja
księgowa, to kierownictwo firmy prawdopodobnie nie uzna tego obszaru działania za
priorytetowy kierunek zmian. Również ręczna organizacja załatwiania spraw
pracowniczych może - zdaniem kierownictwa firmy - nie wymagać jakichkolwiek
udoskonaleń, podobnie jak proces wybierania nowych towarów i wyszukiwania
dostawców. Priorytetowym polem działania firmy jest sprzedaż i jej najbliższe
otoczenie, które wymagają pilnego unowocześnienia. Zakres zmian obejmie więc
pełną automatyzację obiegu związanych z tym procesem dokumentów oraz
wprowadzenie możliwości przyjmowania zamówień składanych przez Internet. Ze
względu na niską stopę zwrotów i reklamacji zdecydowano także o wyłączeniu

18

obsługi tego procesu z zasięgu planowanego systemu. Wynikający z tych decyzji
zakres budowanego systemu jest pokazany na rys.10.

Podjęcie decyzji dotyczących zakresu działań przedsiębiorstwa objętych działaniem
systemu umożliwia sformułowanie wymagań funkcjonalnych, które zostaną zapisane
w umowie na opracowanie oprogramowania:

1. Obsługa przepływu towarów

a. Zamawianie towarów u dostawców
b. Przyjmowanie dostaw towarów
c. Składowanie towarów
d. Wysyłanie towarów klientom

2. Obsługa klientów

a. Przyjmowanie zamówień
b. Określenie sposobu płatności

2.2. Modelowanie danych
Funkcje są elementami procesu przetwarzania danych. Równie ważnym elementem
tego procesu są dane, których wartości - ustalone w wyniku działania funkcji - opisują
stan dziedziny zastosowania: banku, przedsiębiorstwa produkcyjnego albo gry
komputerowej. Dlatego podczas analizy strategicznej nie należy koncentrować się
tylko na definiowaniu funkcji, ale równolegle z odkrywaniem funkcji starać się
odnajdywać i klasyfikować dane oraz dokumentować istniejące między tymi danymi
powiązania. Sposobem porządkowania stopniowo gromadzonej wiedzy jest
modelowanie danych w postaci diagramów encji.

Odnalezienie najważniejszych encji następuje często podczas analizy obiegu
dokumentów w realnym świecie. Niektóre encje wprost odpowiadają dokumentom
krążącym w przedsiębiorstwie. Mogą to być np. zamówienia, faktury, noty
magazynowe, opisy klientów i dostawców. Inne ważne encje można znaleźć,
analizując treść wywiadów, przeprowadzonych z użytkownikami, zgodnie z prostą
zasadą: rzeczowniki pojawiające się w opisach działania mogą okazać się nazwami
encji, a czasowniki odnoszące się do encji mogą okazać się nazwami związków encji.

19

Podobnie jak hierarchia funkcji, diagram encji nie powstaje od razu. Jest rozwijany
stopniowo i doskonalony w miarę postępów analizy i odkrywania nowych encji i
nowych związków. Trzeba jednak pamiętać, że osiągnięcie celów analizy
strategicznej nie wymaga zbudowania diagramu encji pokazującego strukturę
wszystkich przetwarzanych danych. Przeciwnie, model powinien pokazać tylko
najważniejsze encje, których obecność jest niezbędna dla zrozumienia logiki działania
systemu i które w największym stopniu wpływają na ilość danych gromadzonych i
przetwarzanych przez oprogramowanie. Model może nie uwzględniać części
atrybutów, a niektóre encje mogą być narysowane w ogóle bez wyliczenia atrybutów.
Na tym etapie pracy nie ma też potrzeby budowania jednego spójnego diagramu
obejmującego wszystkie znalezione encje. Bardzo często buduje się odrębne modele
danych funkcjonujących w różnych działach przedsiębiorstwa. Takie podejście może
ułatwić proces weryfikacji, gdyż użytkownicy pracujący w różnych działach najlepiej
znają te rodzaje danych, z którymi mają do czynienia w swojej codziennej pracy.

Przykładowy diagram encji, opisujący dane podlegające przetwarzaniu w
przedsiębiorstwie sprzedaży wysyłkowej, jest przedstawiony na rys. 11. Model jest
dość zgrubny, ale obrazuje strukturę danych wystarczająco dokładnie, aby na jego
podstawie ocenić stopień złożoności oraz rozmiar danych niezbędnych dla
prawidłowego wykonania funkcji wchodzących w skład procesu obsługi sprzedaży. W
tym celu trzeba jednak uzupełnić diagram dodatkowym opisem słownym,
określającym przeznaczenie i rozmiar poszczególnych encji. Dla każdej encji można
podać np.:

20

Rysunek 3.11. Diagram encji obrazujący dane funkcji obsługi magazynu i sprzedaży
(model fazy strategicznej)



spodziewaną liczbę obiektów encji, jakie mogą pojawić się w systemie, oraz
rozmiar pojedynczego obiektu;



wymagany okres przechowywania obiektów oraz dodatkowe wymagania
dotyczące archiwizacji obiektów historycznych;



tempo napływu obiektów encji do systemu, mierzone liczbą obiektów w
jednostce czasu (średnie, maksymalne).

Hierarchia funkcji i diagram encji opisują dwa aspekty oprogramowania - wykonywane
działania i przetwarzane dane. Obydwa modele odnoszą się do tego samego systemu
i powinny być ze sobą zgodne. Weryfikacja zgodności, możliwa na tym etapie prac,
polega na sprawdzeniu, czy funkcje występujące w hierarchii realizują wszystkie
podstawowe operacje dotyczące danych, tzn.:



tworzenie obiektów encji (create),



odczytywanie wartości atrybutów (read),



zmienianie wartości atrybutów (update) i



usuwanie obiektów encji (delete).

Wygodnym narzędziem takiej weryfikacji jest macierz koincydencji, której wiersze
odpowiadają encjom, kolumny funkcjom, a kratki - odpowiadające parom złożonym z
funkcji i encji - pokazują operacje wykonywane przez tę funkcję na danej encji.
Weryfikacja polega na sprawdzeniu, czy każda encja jest potrzebna do wykonania
jakiejś funkcji, czy każda funkcja przetwarza dane zapisane w jakiejś encji oraz czy

21

łączny zbiór operacji wpisanych w każdym wierszu zawiera wszystkie cztery operacje
realizujące pełny cykl życia encji. Ponieważ do kratek macierzy koincydencji wpisuje
się zazwyczaj pierwsze litery angielskich nazw operacji, macierz ta jest często
nazywana macierzą CRUD.

Macierz CRUD modelu przedsiębiorstwa sprzedaży wysyłkowej jest pokazana w tab.
1. Jak wynika z tabeli, model nie spełnia wszystkich kryteriów weryfikacji, gdyż nie ma
w nim żadnej funkcji usuwającej opisy klientów, żadnej funkcji usuwającej opisy
dostaw ani funkcji tworzącej i usuwającej opisy dostawców. Nie znaczy to jeszcze, że
model jest błędny - jednak każda z tych sytuacji wymaga wyjaśnienia. W tym
przykładzie wszystkie wymienione braki można łatwo wyjaśnić, gdyż operacje
usunięcia opisu klienta oraz utworzenia i usunięcia opisu dostawcy mogą być
wykonane wyłącznie w trybie operacji ręcznej, natomiast opisy dostaw są tworzone w
chwili przyjęcia dostawy, nigdy nie podlegają modyfikacji, a ich usunięcie następuje w
innym trybie, po upływie 2 lat od daty przyjęcia dostawy.
Zweryfikowane i uzgodnione z użytkownikiem modele hierarchii funkcji i diagramów
encji określają łącznie zakres przetwarzania wymaganego od budowanego
oprogramowania. Zawarta w tych modelach informacja, uzupełniona opisem rozmiaru
danych i sposobu wykonania funkcji, umożliwia oszacowanie rozmiarów przyszłego
systemu, zaproponowanie jego architektury sprzętowej i określenie pracochłonności
wykonania. W większości przypadków taki zestaw danych pozwala na podjęcie
decyzji o rozpoczęciu lub zaniechaniu przedsięwzięcia.

Tabela 3.1. Macierz CRUD kojarząca funkcje z encjami modelu danych

Zamawianie
towarów

Przyjmowanie
dostaw

Składowanie
towarów

Wysyłanie
towarów

Przyjmowani
e zamówień

Określanie
płatności

Towar

CRD

RU

RU

RU

R

Katalog

CRUD

R

R

R

R

Zamówienie

RUD

CR

RU

Przesyłka

CRUD

Klient

R

CRU

Zamówienie
zaopatrzeniowe

CRUD

R

Dostawa

CR

R

Dostawca

RU

R

22

2.3. Schemat kontekstu
Określenie funkcji i danych przetwarzanych przez oprogramowanie pozwala
wyznaczyć granicę oddzielającą to, co dzieje się wewnątrz budowanego systemu, od
zewnętrznego otoczenia, w którym znajdują się użytkownicy oraz inne systemy
współpracujące. Wyraźne zdefiniowanie tej granicy i wyjaśnienie, jakie dane wpływają
do budowanego systemu i w jaki sposób system ma na te dane odpowiadać, jest
ważnym czynnikiem określenia wymagań wyznaczających sposób działania
oprogramowania.

Graficznym modelem opisującym zewnętrzne otoczenie systemu jest schemat
kontekstu (context diagram). Elementami modelu są:



cały budowany system, przedstawiany na ogół w postaci okręgu;



obiekty współpracujące, tzn. ludzie i inne systemy, przedstawiane w postaci
prostokątnych terminatorów (nazywanych też encjami zewnętrznymi);



przepływy danych przekraczające granicę systemu, przedstawiane za pomocą
strzałek łączących system z terminatorami.

Kierunki strzałek obrazujących przepływy danych między systemem a terminatorami
pokazują relację producent-konsument, przy czym zakłada się, że konsument jest
zawsze gotowy do przyjęcia danych - nie ma ukrytych magazynów związanych ze
strzałkami.
Mimo koncepcyjnej prostoty modelu jego budowa - w tym zwłaszcza wybór
terminatorów - nie zawsze jest oczywista. System budowany dla przykładowego
przedsiębiorstwa sprzedaży wysyłkowej na pewno musi obsługiwać klientów.
Niektórzy z nich będą składać zamówienia przez Internet. Czy właściwym
terminatorem systemu będzie w tym wypadku Klient, czy raczej Przeglądarka
internetowa, która jest urządzeniem bezpośrednio współpracującym z systemem? W
większości przypadków lepszym wyborem jest pokazanie w modelu użytkownika
końcowego, tzn. człowieka, a nie urządzenia lub programu sprzęgającego system z
tym użytkownikiem. Wyeksponowanie urządzenia uzależnia model od konkretnej
techniki realizacji sprzęgu systemu z otoczeniem. Odsunięcie tych szczegółów
realizacyjnych prowadzi do stabilnego modelu analitycznego, niewrażliwego na
zmiany technologii realizacyjnej.

23

Kolejna wątpliwość dotyczy operatorów systemu. Klienci przysyłający zamówienia
pocztą elektroniczną nie mają bezpośredniego kontaktu z systemem. W komunikacji
pośredniczy Operator, który odbiera e-maile i wpisuje zamówienia do systemu. Czy
należy uwzględnić jego obecność w modelu? Odpowiedź na to pytanie jest podobna
do poprzedniej. Model analizy strategicznej reprezentuje biznesowy punkt widzenia
budowanego systemu. Z tej perspektywy operator systemu jest tylko elementem
realizacji sprzęgu systemu z użytkownikiem biznesowym. Jego obecność w modelu
analitycznym uzależniłaby ten model od konkretnej organizacji sprzęgu.

Dzięki przyjęciu takich reguł budowy modelu schemat kontekstu może stać się
całkowicie niezależny od konkretnej techniki realizacji sprzęgu systemu z otoczeniem.
Rzeczywista technologia realizacji sprzęgu zostanie pokazana dopiero na
późniejszych etapach projektu.
W przykładowym przedsiębiorstwie sprzedaży wysyłkowej można wyróżnić dwa
terminatory: Klient i Dostawca. Schemat kontekstu systemu jest pokazany na rys. 12.

Rysunek 3.12. Schemat kontekstu przedsiębiorstwa sprzedaży wysyłkowej

Podobnie jak w przypadku diagramów encji, niezbędnym uzupełnieniem schematu
kontekstu jest opis tekstowy obejmujący przede wszystkim:



narracyjny opis przeznaczenia i celu budowy systemu;



opis przepływów danych, z podaniem wszystkich znanych szczegółów
struktury danych i oszacowań ich rozmiaru;



lista atrybutów systemu (wymagań niefunkcjonalnych), takich jak szybkość
działania, wydajność i niezawodność.

Jeżeli schemat kontekstu jest bardzo duży, to można go podzielić na fragmenty
zawierające segmenty koła obrazującego opisywany system. Notację schematu
kontekstu można też wykorzystać do przedstawienia przepływów materiału, energii
lub informacji. Rysunek taki może stanowić pierwszy krok analizy, ułatwiający budowę
modelu przetwarzania.

24

Schemat kontekstu można uważać za dodatkowy poziom modelu diagramów
przepływu danych, usytuowany powyżej całej hierarchii diagramów.

3. Techniki analizy strukturalnej

Zakończenie analizy strategicznej, podjęcie decyzji i podpisanie umowy rozpoczyna
realizację przedsięwzięcia. Przedmiotem prac w fazie analizy (szczegółowej) jest ten
fragment przedsiębiorstwa, który znajduje się w zakresie działania budowanego
systemu. Głównym zadaniem jest teraz dokładne opisanie sposobu działania
oprogramowania. Analiza strukturalna dostarcza w tym celu dwa rodzaje modeli.



Logikę działania opisuje diagram przepływu danych.



Modelem struktury danych pozostaje diagram encji, który podlega jednak
daleko idącym zmianom.

Obydwie czynności - budowa diagramu przepływu danych i przebudowa diagramu
encji - mogą być wykonywane równolegle.

Warunkiem powodzenia pracy jest zebranie i udokumentowanie dokładniejszych
danych na temat zakresu i sposobu działania oprogramowania. Metody pozyskiwania
informacji pozostają podobne do metod z poprzedniej fazy prac i obejmują
studiowanie dokumentów opisujących dziedzinę zastosowania oraz przeprowadzanie
wywiadów z użytkownikami. Na tym etapie analizy wywiady muszą stać się bardziej
szczegółowe, co wymaga zejścia w dół, z poziomu kierownictwa przedsiębiorstwa do
poziomu szeregowych pracowników wykonujących zadania na stanowiskach pracy.
Celem tych działań jest stworzenie modelu analitycznego, który obrazuje sposób
działania oprogramowania, ale nie określa jego budowy.

Podstawowymi narzędziami modelowania wykorzystywanymi w fazie analizy są
diagramy przepływu danych, obrazujące procesy przetwarzania danych i występujące
między nimi sprzężenia, oraz diagramy encji, opisujące strukturę przetwarzanych
danych. Model jest budowany stopniowo w kilku krokach, których rezultaty są
przedstawiane klientowi celem uzgodnienia sposobu rozumienia problemu i
uzyskania aprobaty dla proponowanych rozwiązań.

25

W większości przypadków systemy informatyczne powstają w celu usprawnienia
działania przedsiębiorstw lub innych organizacji, które już mają zorganizowany jakiś
system przetwarzania danych (np. ręczny). Istniejący system odzwierciedla potrzeby
firmy, a jednocześnie ma ograniczenia wynikające z dotychczasowej technologii
realizacji. Zamodelowanie istniejącego systemu jest dobrym punktem wyjścia do
dalszej analizy, której celem będzie zachowanie potrzebnych działań, z
jednoczesnym uwolnieniem się od ograniczeń technologicznych. Dodatkową zaletą
takiego podejścia jest łatwość uzyskania od użytkowników informacji o sposobie
działania systemu, który znają i którego używają na co dzień, oraz możliwość
wiarygodnej weryfikacji sposobu rozumienia problemu przez obie strony umowy.
Dlatego typowy przebieg procesu modelowania zachowania obejmuje następujące
kroki:



Budowę modelu fizycznego, który przedstawia sposób przetwarzania danych
w obecnie działającym systemie.



Budowę modelu logicznego, który usuwa ograniczenia dotychczas stosowanej
technologii realizacyjnej i obrazuje sposób przetwarzania w „idealnej"
technologii.



Budowę nowego modelu fizycznego, który przedstawia sposób działania
oprogramowania nowego systemu.

Dotychczasowy model fizyczny pokazuje sposób realizacji procesów biznesowych
przedsiębiorstwa. Przekształcenie modelu fizycznego w model logiczny może
oznaczać zmianę tych procesów, prowadzącą do zmiany sposobu działania firmy. W
tym miejscu metodyka strukturalna wykracza poza obszar inżynierii oprogramowania,
a nawet poza obszar techniki, i staje się narzędziem znanej w naukach o zarządzaniu
koncepcji restrukturyzacji procesów biznesowych {Business Process Re-engineering
- BPR) w celu poprawy wydajności działania przedsiębiorstwa.

Trzeba jednak zaznaczyć, że budowa dotychczasowego modelu fizycznego jest
krokiem opcjonalnym, który może być pominięty ze względu na koszty lub w
przypadku budowania całkiem nowego systemu, który nie miał żadnego poprzednika.
Taka sytuacja występuje często podczas wytwarzania oprogramowania systemów
sterujących, które otwierają nowe możliwości lub zastępują wcześniejsze urządzenia

26

oparte na zupełnie innych zasadach działania. Dlatego metody zorientowane na
projektowanie oprogramowania sterującego nie obejmują na ogół tego kroku.

3.1. Budowa modelu fizycznego
Podstawowymi źródłami informacji są dla analityków wywiady z użytkownikami oraz
bieżące dokumenty firmy, takie jak statut, opis struktury organizacyjnej, regulamin,
instrukcje stanowiskowe. Wszystkie te źródła opisują stan bieżący, a nie przyszły,
który powstanie po zbudowaniu nowego systemu informatycznego. Dlatego pierwszy
model zbudowany przez analityków niemal zawsze w większym lub mniejszym
stopniu odzwierciedla obecną strukturę i organizację pracy, które - być może - ulegną
zmianie w wyniku wprowadzenia nowego systemu.

Powróćmy do przykładu przedsiębiorstwa sprzedaży wysyłkowej. Punktem wyjścia
analizy jest hierarchia funkcji (rys. 10), opisująca zadania do wykonania, oraz
schemat kontekstu (rys. 12), pokazujący granice systemu i zewnętrzne obiekty
współpracujące. Pierwszy krok, obejmujący wywiady z pracownikami oraz obserwację
obiegu dokumentów i sposobu działania przedsiębiorstwa, może prowadzić do
zbudowania modelu pokazującego zasadnicze procesy systemu oraz przepływy
danych między tymi procesami (rys. 13). Łatwo zauważyć, że procesy odpowiadają
dość dobrze funkcjom znajdującym się na najwyższym poziomie hierarchii funkcji. Nie
powinno to być zaskoczeniem, gdyż zarówno funkcje hierarchii, jak i procesy modelu
fizycznego odpowiadają często komórkom organizacyjnym przedsiębiorstwa.

27

Rysunek 13. Diagram 0: System sprzedaży wysyłkowej

Diagram przepływu danych opisuje wymagane przetwarzanie znacznie dokładniej niż
hierarchia funkcji. Przepływy łączące funkcje umożliwiają pokazanie ich
współdziałania oraz wymiany danych następującej podczas realizacji procesów
biznesowych.

Najważniejszy proces biznesowy przedsiębiorstwa sprzedaży wysyłkowej, jakim jest
obsługa zamówień klientów, rozpoczyna się w chwili wpłynięcia zamówienia od
klienta (1). Pracownicy działu sprzedaży rejestrują wpływające zamówienia i dzielą je
na dwie grupy:



zamówienia, które powinny zostać opłacone przelewem przed realizacją, są
odkładane na stos zamówień czekających (2a);



zamówienia płatne przy odbiorze są odkładane na stos zamówień do realizacji
(2).

Realizację przelewów kontroluje dział księgowości, którego pracownicy przenoszą
opłacone zamówienia ze stosu zamówień czekających na stos zamówień do realizacji
(2b, 2c). Wykonaniem zamówień (3) zajmuje się dział obsługi magazynu. Jeżeli
wszystkie towary wymienione w zamówieniu są dostępne w magazynie, to są one

28

pakowane i przygotowywane do wysłania do klienta, a druk zamówienia jest
odkładany na stos zamówień wykonanych (4). Stos tych zamówień jest kilka razy
dziennie zanoszony do działu księgowości (4a), którego pracownicy wystawiają
faktury i odkładają je na stos faktur klientów (5). Pod koniec dnia faktury są dołączane
do przygotowanych przesyłek (5a) i wysyłane do klientów (6).

Jeżeli zamówionych towarów w magazynie nie ma, to niemożliwe do zrealizowania
zamówienia są odkładane na stos zamówień zaległych (7). Po odebraniu nowej
dostawy pracownicy magazynu przeglądają stos zamówień zaległych i realizują je w
normalny sposób.

W podobny sposób można opisać przebieg procesu zakupu towarów od dostawców.
Stos zamówień zaległych jest regularnie przeglądany przez pracowników działu
zaopatrzenia (8), którzy zamawiają brakujące towary u dostawców (9), pozostawiając
zaległe zamówienia na stosie. Kopie zamówień złożonych u dostawców oczekują na
stosie zamówień zaopatrzeniowych do chwili, w której obsługa magazynu potwierdzi
odebranie dostawy (10). Potwierdzone zamówienia zaopatrzeniowe są przekazywane
do działu księgowości (11), który opłaca związane z tymi zamówieniami faktury
dostawców (12).

Opis przetwarzania, jaki można przedstawić na pojedynczym diagramie, jest z
konieczności dość ogólny. Podstawowym ograniczeniem jest rozmiar i stopień
skomplikowania rysunku - pokazanie wszystkich szczegółów działania
przedsiębiorstwa wymagałoby zbudowania bardzo dużego diagramu, zagmatwanego
i trudnego do objęcia ludzkim umysłem. Taki sposób postępowania stanowiłby
zaprzeczenie idei posługiwania się modelami graficznymi, które są tworzone dla
uzyskania przejrzystości i zrozumiałości opisu większej, niż jest to możliwe do
uzyskania za pomocą opisów tekstowych. Badania psychofizyczne wykonane jeszcze
w latach pięćdziesiątych XX wieku pokazały, że optymalną dla naszej zdolności
pojmowania jest dekompozycja problemu na ok. 7 elementów. Stąd zwykle przyjmuje
się tę wartość jako wskazanie zalecanej liczby procesów na diagramie.

29

Bardziej szczegółowy opis przetwarzania wymaga zbudowania hierarchii diagramów,
w której struktura poszczególnych procesów diagramu wyższego poziomu jest
przedstawiona na odrębnych diagramach niższego poziomu. Na przykład, proces 1:
Obsługa zamówień można opisać za pomocą diagramu pokazanego na rys. 14, a
proces 2: Obsługa magazynu - przy użyciu diagramu pokazanego na rys. 15.

Końcowa hierarchia diagramów opisuje całość przetwarzania zgodnie z zasadą
zstępującej dekompozycji funkcji. Nie znaczy to jednak, że tak właśnie przebiega
proces budowania modelu przez analityka. W rzeczywistości częstym punktem
startowym jest zgrubny, jednopoziomowy model obrazujący tę część przetwarzania,
która jest najlepiej rozumiana przez analityka na danym etapie pracy. W miarę
postępów analizy diagram zaczyna przekraczać rozsądne rozmiary, co zmusza

30

analityka do uporządkowania modelu i przejścia na opis hierarchiczny - powiązane
grupy procesów są łączone w pojedyncze procesy wyższego poziomu, a drobne
szczegóły przetwarzania są przenoszone na diagramy poziomu niższego. Na ogół
budowę hierarchii diagramów przepływu danych prowadzi się do takiego poziomu, na
którym procesy staną się na tyle proste, aby ich specyfikacje mieściły się na jednej
stronie. Przykład takiej minispecyfikacji, zapisanej w pseudokodzie, jest pokazany na
rys. 16.

Proces 2.1: Sprawdzenie stanu magazynu
Dla każdego wybranego zamówienia wykonaj

Przeglądaj pozycje zamówienia i dla każdej pozycji wykonaj

Znajdź opis towaru w magazynie

Jeśli towar dostępny, to

Zaznacz pobranie towaru
Zaznacz pozycję zrealizowaną

w przeciwnym przypadku

Przerwij przeglądanie pozycji zamówienia

Jeśli wszystkie pozycje zrealizowane, to

Przekaż zamówienie do wysyłki

W przeciwnym przypadku

Dla każdej pozycji zamówienia

Cofnij pobranie towaru

Przekaż zamówienie do zbioru zamówień zaległych

Koniec obsługi zamówienia

Rysunek 16. Specyfikacja procesu 2.1: Sprawdzenie stanu magazynu

3.2. Budowa modelu logicznego
Model fizyczny pokazuje przebieg procesów przetwarzania danych, realizowanych w
konkretnej technologii implementacyjnej. W systemie ręcznego przetwarzania danych
przepływy w modelu obrazują ruch fizycznie istniejących obiektów. Na przykład,
widoczny na rys. 13 zbiór

Zamówienia czekające może mieć postać segregatora, z

którego część dokumentów jest przenoszona przez pracowników działu księgowości
do innego segregatora

Zamówień do realizacji. Fizyczne przemieszczenie zamówień

31

do osobnego zbioru jest niezbędne dla ułatwienia pracy ludzi obsługujących magazyn
i uniknięcia pomyłek polegających na realizacji zamówień, które nie zostały właściwie
opłacone.

Odrębne segregatory

Zamówień czekających i Zamówień do realizacji oraz

konieczność przekładania kartek zamówień z jednego segregatora do drugiego są
przykładami zależności procesu przetwarzania od technologii realizacyjnej (realizacja
ręczna). W innej technologii realizacyjnej - takiej, w której nie grozi pomylenie
zamówień różnego rodzaju - odrębne segregatory stają się zbędne. Zamiast nich
wystarczy jeden wspólny zbiór zamówień, rozróżnianych za pomocą dodatkowego
oznaczenia czekające, do realizacji lub wykonane. Każda zmiana technologii
realizacyjnej, np. wprowadzenie komputerów, skanerów dokumentów, oznakowanie
zamówień kodem kreskowym itp. może prowadzić do daleko idących zmian modelu.
W rezultacie model fizyczny jest niestabilny i podlega częstym zmianom.

Celem budowy modelu logicznego jest pokazanie wewnętrznej logiki procesów
przetwarzania danych, nieobarczonych naleciałościami konkretnej technologii
implementacyjnej. Niezależność od zmieniającej się technologii zapewnia stabilność
modelu, który powinien zachować aktualność pomimo nieuchronnych zmian
technologicznych.

Hierarchiczna struktura modelu fizycznego odzwierciedla na ogół obecną strukturę
organizacyjną przedsiębiorstwa, którego działy odpowiadają procesom pokazanym
na diagramie najwyższego poziomu. Dlatego przekształcenie modelu fizycznego w
model logiczny rozpoczyna się zwykle od usunięcia hierarchii i połączenia diagramów
przepływu danych znajdujących się na niższym poziomie. Procesy występujące na
diagramach niższego poziomu odzwierciedlają czynności, które muszą być wykonane
niezależnie od przypisania ich do tego czy innego działu firmy. Połączony, zwykle
bardzo duży, model przedstawia przebieg obecnych procesów przetwarzania,
oderwany od konkretnej struktury organizacyjnej przedsiębiorstwa.
Dalszym krokiem budowania modelu logicznego jest usunięcie wszystkich elementów
modelu fizycznego wynikających z obecnie stosowanej technologii realizacyjnej.
Należą do nich:

32



procesy transportowe (przenoszenie danych, zmiana nośnika, kontrola błędów,
...),



procesy wsadowe (gromadzenie danych),



przepływy przemieszczające fizyczne obiekty,



wsadowe magazyny danych,



magazyny bez wejść lub wyjść.

Powróćmy do przykładu przedsiębiorstwa sprzedaży wysyłkowej. Diagram 0,
pokazany na rys. 13, przedstawia całość przetwarzania danych wykonywanego w
przedsiębiorstwie, diagramy 1 i 2, pokazane na rys. 14 i 15, przedstawiają dokładniej
interesujące nas procesy Obsługa zamówień i Obsługa magazynu. Usunięcie
hierarchizacji polega na połączeniu diagramów 1 i 2, co prowadzi do zbiorczego
modelu przetwarzania pokazanego na rys. 17.

Analizując połączony model fizyczny, można zauważyć, że elementami ściśle
związanymi z obecną (ręczną) technologią realizacji przetwarzania są w nim:



wsadowe magazyny danych:

Zamówienia czekające, Zamówienia do

realizacji., Zamówienia zaległe i Zamówienia wykonane, które można połączyć
w jeden magazyn

Zamówienia;



procesy i magazyny opisujące fizyczne przemieszczenia towarów:

Pakowanie

przesyłki i Składowanie towarów, które zostaną z modelu usunięte.

Wynikiem tych zmian jest model logiczny aplikacji obsługi sprzedaży pokazany na rys.
18. Łatwo zauważyć znaczne uproszczenie modelu, w którym wyraźnie wyodrębniają
się drogi przepływu zamówień i towarów.

33

Rysunek 3.17. Połączony model fizyczny

Rysunek 3.18. Model logiczny aplikacji obsługi sprzedaży

Budowanie modelu logicznego wymagało szeregu działań, podczas których istniała
możliwość popełnienia błędu, np. pominięcia jakiejś funkcji lub jakiegoś połączenia
funkcji z magazynem danych. Dlatego opracowany model logiczny powinien być
przed zatwierdzeniem poddany weryfikacji polegającej na próbie odnalezienia wśród
procesów modelu wszystkich funkcji elementarnych, które występują w hierarchii

34

funkcji i w modelu fizycznym, oraz zbudowaniu macierzy CRUD, sprawdzającej
korelację modelu zachowania z modelem danych.

3.3. Modelowanie danych
Model danych utworzony podczas analizy strategicznej nie jest zbyt szczegółowy. Nie
ma on przecież opisywać całości danych podlegających przetwarzaniu, a jedynie
wyjaśniać sposób działania funkcji wymienionych w hierarchii funkcji. Dlatego model
ten zawiera tylko najważniejsze encje, których obecność jest oczywista,
najważniejsze atrybuty, które są niezbędne do scharakteryzowania encji, oraz
podstawowe związki między encjami.
Celem prac wykonywanych w fazie analizy szczegółowej jest zbudowanie modelu
dokładnego. Metody pracy analityka oraz źródła wykorzystywanej przez niego
informacji nie ulegają zasadniczej zmianie, jednak poziom szczegółowości opisu
wzrasta, a praca obejmuje swym zasięgiem wszystkie obszary dziedziny problemu, a
nie tylko te najważniejsze. Konieczność poznania szczegółów wymaganego
przetwarzania zmienia zakres wywiadów - obejmują one teraz pracowników niższych
szczebli, którzy wiedzą, jak pracuje firma, a w przyszłości będą bezpośrednimi
użytkownikami tworzonego oprogramowania.

Istotnym elementem budowania kompletnego modelu danych jest uzupełnianie i
porządkowanie atrybutów encji, nazywane normalizacją modelu. Celem tego procesu
jest uniknięcie redundancji danych i doprowadzenie modelu do postaci, która jest
wymagana do utworzenia tabel relacyjnej bazy danych. Proces normalizacji
przebiega w kilku krokach, których wynikiem są kolejno numerowane „postacie
normalne". Na ogół wymaga się normalizacji sięgającej trzeciej postaci normalnej.

1. Pierwsza postać normalna - atrybuty encji są wartościami niepodzielnymi. Na

przykład, jeśli w czasie przetwarzania danych klienta pojawia się potrzeba
wyodrębniania z jego adresu nazwy miejscowości, to adres nie będzie
prawidłowym atrybutem encji Klient. Normalizacja wymaga rozbicia adresu na
części składowe.

35

2. Druga postać normalna - każda wartość klucza jednoznacznie wyznacza

wartości wszystkich atrybutów encji. Na przykład, atrybut nazwisko nie będzie
poprawnym kluczem encji Klient, ponieważ może pojawić się kilku klientów o
tym samym nazwisku. Rozwiązaniem problemu może być nadanie klientom
unikalnych identyfikatorów lub posłużenie się numerami PESEL.

3. Trzecia postać normalna - atrybut, który nie jest kluczem, nie wyznacza

jednoznacznie wartości innych atrybutów encji. Na przykład, gdyby encja
Zamówienie zawierała identyfikator klienta i adres klienta, to atrybut
identyfikator

klienta

jednoznacznie

wyznaczałby

adres

klienta.

Przechowywanie adresu w tej encji byłoby nadmiarowe, gdyż znając
identyfikator klienta, można zawsze odszukać jego adres w treści encji Klient.

Dokładny opis wszystkich postaci normalnych oraz sformalizowanego procesu ich
osiągania można znaleźć w podręcznikach projektowania baz danych. Rozwijając
wstępny diagram encji, opracowany podczas analizy strategicznej, trzeba poświęcić
szczególną uwagę takim związkom, które po obu stronach mogą dotyczyć wielu
obiektów. Tego typu związki wiele-do-wielu, których przykładem może być związek
łączący encje Towar i Zamówienie na rys. 6, utrudniają człowiekowi uchwycenie
natury powiązań istniejących między konkretnymi obiektami w dziedzinie
zastosowania. Dlatego w większości praktycznie realizowanych systemów
przetwarzania danych wprowadza się jakieś encje pośredniczące, których obecność
umożliwia zdefiniowanie powiązań między przetwarzanymi obiektami za pomocą
bardziej jednoznacznych związków typu jeden-do-wielu. Na przykład, w niemal
wszystkich systemach przetwarzających zamówienia występuje pojęcie „pozycji
zamówienia", czyli samodzielnej części zamówienia określającej zapotrzebowanie na
jeden konkretny towar. W ogromnej większości przypadków każda pozycja
zamówienia może być przedmiotem odrębnej dostawy i księgowania, niezależnie od
losu pozostałych pozycji tego samego zamówienia. Sposób powiązania wielu
obiektów jednego rodzaju z wieloma obiektami innego rodzaju poprzez encję
pośredniczącą jest pokazany na rys. 19.

36

Rysunek 19. Jednoznaczne powiązanie towarów i zamówień poprzez pozycje
zamówienia

Obecność związku wiele-do-wielu w modelu danych wskazuje najczęściej na
pominięcie jakiegoś ważnego pojęcia występującego w realnym świecie i konieczność
przeprowadzenia bardziej wnikliwej analizy tego fragmentu dziedziny zastosowania.
Przykładowy model uporządkowanego modelu danych przedsiębiorstwa sprzedaży
wysyłkowej, pozbawiony związków wiele-do-wielu, jest pokazany na rys. 20.

Rysunek 3.20. Diagram encji obrazujący dane funkcji obsługi magazynu i sprzedaży
(model analizy szczegółowej)

3.4. Budowa nowego modelu fizycznego
Celem działania na tym etapie pracy jest określenie mechanizmów realizacji
przetwarzania opisanego w modelu logicznym. Na razie nie wiadomo nawet, jak będą
wprowadzane do systemu zamówienia nadsyłane pocztą elektroniczną, jak będzie
wyglądać współpraca systemu z pracownikami pakującymi towary i wysyłającymi
przesyłki ani jak będą przyjmowane nowe dostawy.

37

Zajmijmy się tym ostatnim problemem. Przenoszenie towarów i rozmieszczanie ich w
magazynie będzie zapewne wykonywane ręcznie. System komputerowy może jednak
wspomagać ten proces, odnajdując zamówienia odpowiadające zawartości dostawy,
sprawdzając zgodność dokumentów dostawy z treścią zamówienia, aktualizując
automatycznie opis stanu magazynu i drukując dokumenty przyjęcia towarów do
magazynu (dokument PZ). Dalsze możliwości automatyzacji procesu przyjmowania
dostaw zależą istotnie od wyposażenia magazynu. Jeśli dostarczane towary mają
oznaczenia w postaci kodu kreskowego, a magazyn zostanie wyposażony w
odpowiednie czytniki, to komputer może automatycznie sprawdzać zawartość i
kompletność przyjmowanej dostawy. Całość związanego z tym procesem
przetwarzania jest pokazana na rys. 21.

Przyjęcie dostawy rozpoczyna się od skanowania czytnikiem wszystkich
dostarczonych towarów. System rozpoznaje odczytany kod towaru (proces 5.1),
zlicza poszczególne pozycje towarowe i znajduje odpowiadające im zamówienia w
zbiorze Zamówienia zaopatrzeniowe (proces 5.2). Pracownik magazynu widzi na
terminalu treść zamówienia oraz liczbę dostarczonych sztuk towaru i na tej podstawie
podejmuje decyzję o przyjęciu lub odrzuceniu każdej pozycji dostawy. Pozycje
odrzucone są zwracane dostawcy. Pozycje przyjęte są wciągane na stan magazynu
(proces 5.3), a ich opis jest zapisywany w zbiorze Pozycje przyjęte. Po zakończeniu
procesu przyjmowania dostawy system drukuje dokument przyjęcia zewnętrznego
(PZ) potwierdzający przyjęcie towarów do magazynu.

Rysunek 21. Diagram 5: Przyjęcie dostawy

38

W rzeczywistości nowy model fizyczny nie jest wynikiem decyzji podjętych arbitralnie
przez analityków. Decyzja co do sposobu wprowadzania i wyprowadzania danych
wiąże się ściśle z opracowaniem nowych procedur biznesowych, zgodnie z którymi
będzie działać przedsiębiorstwo, i jest podejmowana zawsze w ścisłej współpracy z
użytkownikiem, który ma w tym względzie głos decydujący. Opracowanie tych
procedur wymaga oceny wielu czynników biznesowych, takich jak zakres
koniecznego szkolenia personelu, możliwość wystąpienia zakłóceń pracy firmy na
etapie wdrożenia oraz niezbędne wydatki inwestycyjne (np. na zakup czytników kodu
kreskowego). Dlatego wynikiem analizy szczegółowej jest nie tylko model systemu
docelowego, ale także plan przejścia na nowy system, obejmujący co najmniej trzy
elementy:



plan testowania akceptacyjnego, określający czas, miejsce i zakres
odpowiedzialności stron podczas zatwierdzania systemu (np. kto dostarczy
środowisko testowe, jaką metodą będą sprawdzane wymagania, jak będą
zgłaszane błędy, jak będzie przebiegał proces poprawiania błędów itp.);



plan szkoleń, określający czas, miejsce i zakres szkoleń niezbędnych dla
poszczególnych stanowisk pracy (także: metodę szkolenia, liczebność grup
treningowych, dostępność systemu szkoleniowego i podręczników) oraz
sposób zapewnienia ciągłości pracy firmy podczas szkolenia części
pracowników;



plan wdrożenia, określający m.in. sposób przenoszenia danych między starym
a nowym systemem, kolejność włączania do eksploatacji modułów nowego
systemu i wyłączania starego (może obydwa systemy będą przez pewien czas
pracować równolegle) oraz liczbę pracowników niezbędnych na
poszczególnych stanowiskach pracy.

4. Techniki projektowania aplikacji

Model analityczny, w skład którego wchodzi hierarchia diagramów przepływu danych i
diagram encji, opisuje reguły przetwarzania oraz zakres danych niezbędnych do
realizacji tego przetwarzania. Jednocześnie model ten nie zawiera szczegółów
technologii realizacyjnej ani nie określa budowy programu. Te właśnie elementy są
dodawane podczas budowania modelu projektowego.

39

Pierwszą decyzją, jaką musi podjąć projektant, jest podział całego systemu na
odrębne programy (aplikacje), wykonywane niezależnie - i być może równolegle z
pozostałymi programami. Z punktu widzenia użytkownika program może odpowiadać
funkcji w głównym menu systemu. Na poziomie wielozadaniowego systemu
operacyjnego program może być odrębnym procesem wykonywanym równolegle z
innymi procesami. Na przykład, w systemie wspomagającym pracę przedsiębiorstwa
jednym programem może być funkcja realizacji zamówienia, a drugim - funkcja
przyjmowania dostawy towarów do magazynu. Obie funkcje nie są całkiem
niezależne, gdyż współdzielą zbiór (encję) opisujący stan magazynu. Mogą jednak
być wykonywane niezależnie przez dwóch lub więcej użytkowników (kilku
pracowników może w tym samym czasie realizować różne zamówienia). Innym
przykładem może być system pokładowy samolotu, w którym jeden program może
obliczać pozycję i prędkość samolotu na podstawie wskazań inercyjnego systemu
pomiarowego (żyroskopu), drugi okresowo korygować położenie na podstawie
wskazań GPS, a trzeci - wyświetlać obliczone wartości dla pilota. Wszystkie te
programy działają równolegle i permanentnie, współdziałając z sobą za pomocą usług
udostępnianych przez system operacyjny komputera pokładowego.

Określenie granic programów polega na logicznym pogrupowaniu funkcji pokazanych
na diagramie przepływu danych. Kryteria, jakie można zastosować podczas tej
czynności, łatwiej podać, niż stosować w praktyce:



łączyć razem funkcje powiązane przepływami bezpośrednimi - wykonanie
jednej z tych funkcji niejako wymusza wykonanie drugiej; powstający program
stanie się dla użytkownika narzędziem umożliwiającym łatwą realizację obu
zadań;



łączyć razem funkcje sięgające do ściśle powiązanych encji - jest wysoce
prawdopodobne, że modyfikacja jednej encji będzie wymagała jednoczesnej
zmiany drugiej;



łączyć razem funkcje wykonywane w tym samym miejscu i czasie - zapewne
będzie je wykonywał ten sam użytkownik.

Stosując te reguły do przykładu pokazanego na rys. 18, można wyodrębnić trzy
programy: przyjmowanie zamówień, realizacja zamówienia i przyjęcie nowej dostawy.

40

Programy te mogą stać się niezależnymi aplikacjami, wywoływanymi oddzielnie przez
różnych pracowników przedsiębiorstwa, albo mogą być zintegrowane w jednej
aplikacji, w której staną się funkcjami dostępnymi w głównym menu aplikacji.

Po zdefiniowaniu granic programów kolejnym krokiem jest określenie sposobu
budowy każdego programu i zaprojektowanie bazy danych. Działania te wymagają
użycia różnych technologii implementacyjnych i są często wykonywane przez różnych
ludzi. Trzeba też zaprojektować interfejs użytkownika, obejmujący raporty i formularze
ekranowe. Działania te, zwłaszcza implementacja bazy danych i interfejsu
użytkownika, są bardzo silnie wspierane przez dostępne narzędzia wspomagające.

4.1. Projektowanie struktury programu
Zaprojektowanie programu wymaga wskazania podstawowych modułów tego
programu (podprogramów, funkcji, struktur danych), określenia sposobu współpracy
każdego modułu z innymi modułami, zbiorami danych i urządzeniami oraz
zdefiniowania algorytmów działania wszystkich modułów. Punktem wyjścia tego etapu
budowy oprogramowania są diagramy przepływu danych, pokazujące podstawowe
funkcje do wykonania i występujące między nimi zależności, oraz diagramy encji,
określające strukturę danych trwałych. Wynikiem powinien być schemat struktury
programu oraz algorytmiczne specyfikacje pokazanych na schemacie podprogramów.
Oczywistym kryterium poprawności projektu jest wierne odwzorowanie całości
przetwarzania, przedstawionego w modelu analitycznym, w strukturze programu.
Dobrym sposobem zapewnienia zgodności modeli jest budowanie schematu struktury
przez stopniowe przekształcanie diagramu przepływu danych tak, aby możliwe było
wskazanie odpowiadających sobie elementów obydwu modeli. Jedna z najczęściej
stosowanych metod tego przekształcania polega na hierarchicznym budowaniu
kolejnych pięter schematu struktury, poczynając od programu głównego, poprzez
bezpośrednio wywoływane podprogramy, aż do podprogramów i zbiorów
znajdujących się na najniższym poziomie hierarchii wywołań. Procedura
przekształcania zaczyna się od wybrania centralnej funkcji diagramu, realizującej
zasadniczą część przetwarzania aplikacji i położonej zazwyczaj w centralnym miejscu
diagramu. Wybór tej funkcji jest dość subiektywny i zależy od punktu widzenia
projektanta. W następnym kroku powstaje górna część schematu struktury, złożona z

41

programu głównego aplikacji oraz podprogramów odpowiadających kolejno:
przepływom doprowadzającym dane wejściowe do funkcji centralnej, samej funkcji
centralnej i przepływom wyprowadzającym wyniki wykonania funkcji centralnej.

Prześledźmy ten proces na przykładzie aplikacji przyjęcia dostawy, pokazanej na rys.
21. Centralne miejsce diagramu zajmuje funkcja

Sprawdzenie pozycji dostawy, która

przetwarza opisy kolejnych

Pozycji dostawy dostarczane z czytnika kodu kreskowego

przez funkcję

Rozpoznanie tekstu i przekazuje opisy Pozycji przyjętych do funkcji

Aktualizacja stanu magazynu. Pozostałe działania, polegające na odczytaniu
zamówienia z magazynu

Zamówień zaopatrzeniowych i zatwierdzeniu przyjęcia

pozycji przez pracownika na

Terminalu magazynu, można uznać za wewnętrzne

operacje funkcji centralnej. W ten sposób powstaje górne piętro schematu struktury
programu, zawierające podprogramy:

Odczytanie pozycji dostawy, Sprawdzenie

pozycji dostawy i Obsługa pozycji przyjętej (rys. 22). Dodatkowa strzałka, obejmująca
na rysunku wywołania tych trzech podprogramów, symbolizuje wielokrotne wywołania
w pętli przetwarzania kolejnych pozycji dostawy. Romb u nasady wywołania ostatniej
funkcji podkreśla warunkowość tego wywołania, dokonywanego nie dla wszystkich
pozycji dostawy, a jedynie dla pozycji przyjętych. Czwarta funkcja diagramu
przepływu danych, tzn.

Drukowanie dokumentu PZ, nie jest bezpośrednio związana z

wykonaniem funkcji centralnej. Funkcja ta przetwarza zbiór wyników powstały po
sprawdzeniu wszystkich pozycji dostawy - jest więc wykonywana w innym momencie i
w innym rytmie czasowym aniżeli funkcja centralna. W tej sytuacji funkcja ta może być
wyodrębniona jako oddzielna aplikacja lub dołączona jako dodatkowy podprogram
wywoływany z menu modułu

Przyjęcia dostawy.

W kolejnych krokach procedury przekształcania diagramu przepływu danych w
schemat struktury programu powstają niższe warstwy schematu. Operacje uznane za
wewnętrzne w funkcji centralnej stają się podprogramami wywoływanymi przez tę
funkcję. W ten sposób na rys. 22 pojawiają się podprogramy:

Znalezienie

zamówienia, Potwierdzenie pozycji i Akceptacja pozycji.

Funkcje dostarczające przepływy do funkcji centralnej, takie jak

Rozpoznanie tekstu

na rys. 21, są przekształcane na podprogramy niższej warstwy. Funkcja i jej

42

przepływy wejściowe stają się podprogramami wywoływanymi przez podprogram
odpowiadający w górnej warstwie schematu przepływowi wejściowemu funkcji
centralnej. W ten sposób na rys. 22 pojawiają się podprogramy:

Odczyt kodu

kreskowego i Rozpoznanie tekstu. Gdyby na diagramie przepływu danych istniały
dalsze funkcje dostarczające przepływy do funkcji

Rozpoznanie tekstu, to zostałyby

przekształcone na kolejną, jeszcze niższą warstwę.

Rysunek 3.22. Schemat struktury modułu Przyjęcie dostawy

W analogiczny sposób są przekształcane funkcje odbierające wyniki funkcji
centralnej, takie jak

Aktualizacja stanu magazynu na rys. 21. Funkcje te oraz ich

przepływy wyjściowe stają się podprogramami wywoływanymi przez podprogramy
odpowiadające w górnej warstwie schematu przepływom wyjściowym funkcji
centralnej. W ten sposób na rys. 22 powstały podprogramy

Aktualizacja magazynu i

Zapis pozycji przyjętej.

Schemat struktury dokładnie przedstawia budowę programu, pokazując wszystkie
zasadnicze podprogramy, hierarchię wywołań wraz z argumentami przekazywanymi
podczas wywołania oraz wspólne struktury danych, takie jak Pozycje przyjęte na rys.
22. Brakującym elementem projektu są algorytmy przetwarzania, których jednak nie
trzeba wymyślać od nowa, lecz które są niemal bez zmian przejmowane z
minispecyfikacji procesów diagramu przepływu danych. Przeniesienie specyfikacji

43

algorytmów działania między obydwoma modelami wydatnie pomaga w zapewnieniu
zgodności projektu z wynikami analizy.

Drugą zaletą sformalizowanej procedury przekształcania diagramu przepływu danych
w schemat struktury jest możliwość łatwej weryfikacji kompletności projektu. W tym
celu należy zestawić tabelę, której wiersze zawierają w pierwszej kolumnie elementy
diagramu przepływu danych, tzn. funkcje, magazyny i przepływy, a w drugiej -
realizujące te elementy podprogramy, zbiory i urządzenia ze schematu struktury.
Przykład takiego odwzorowania jest pokazany w tab. 3.2. Niemożliwość wskazania
realizacji jakichkolwiek elementów modelu analitycznego świadczy o niekompletności
projektu.

Tabela 2. Tabela powiązań diagramu Przyjęcie dostawy (rys. 21) ze schematem
struktury programu (rys. 22)

Lp- Diagram przepływu danych

Schemat struktury

1 Funkcja - Rozpoznanie tekstu

Podprogram - Rozpoznanie tekstu

2 Funkcja - Sprawdzenie pozycji

dostawy

Podprogram - Sprawdzenie pozycji
dostawy

3 Funkcja - Aktualizacja stanu

magazynu

Podprogram - Aktualizacja
magazynu

4 Funkcja - Drukowanie dokumentu PZ Podprogram - Drukowanie

dokumentu PZ

5 Przepływ - Kod kreskowy

Podprogram - Odczyt kodu
kreskowego

6 Przepływ - Zamówienie + pozycja

dostawy

Podprogram - Akceptacja pozycji

7 Przepływ - Decyzja

Podprogram - Akceptacja pozycji

8 Magazyn - Zamówienia

zaopatrzeniowe

Tabela - Zamówienia
zaopatrzeniowe

W wielu przypadkach przydatna jest również tabela pokazująca odwzorowanie
odwrotne, tzn. przyporządkowująca elementom schematu struktury realizowane przez
nie elementy diagramu przepływu danych. Zawartość takiej tabeli wskazuje źródła

44

pochodzenia wszystkich elementów projektu i dowodzi, że projekt realizuje tylko te
zachowania, które zostały zatwierdzone podczas analizy.

Posiadanie obydwu rodzajów tabel może znacząco ułatwić przyszłą konserwację
programu. Po zmianie wymagań użytkownika można łatwo wskazać elementy
diagramu przepływu danych opisujące tę część wymagań, których zmiana dotyczy, a
następnie zlokalizować moduły programu odpowiadające za ich realizację. Co więcej,
po określeniu obszaru zmian w kodzie można znaleźć wszystkie elementy diagramu
przepływu danych, które ten fragment programu realizuje, i w ten sposób ocenić
potencjalny wpływ zmian na inne zachowania aplikacji.

4.2. Projektowanie bazy danych
Zaprojektowanie bazy danych wymaga zdefiniowania tabel przechowujących encje
modelu danych, określenia dla każdej tabeli zestawu indeksów gwarantujących
szybkie wyszukiwanie potrzebnych danych w tabeli oraz wskazania sposobu
rozmieszczenia tabel i indeksów w plikach systemu operacyjnego. Na ogół konieczne
jest też opracowanie planów archiwizacji i odtwarzania danych po awarii. Punktem
wyjścia tego etapu projektu są diagramy encji, określające strukturę danych i
występujące między nimi zależności, oraz wymagania użytkownika dotyczące
wydajności przetwarzania i niezawodności przechowywania danych. Wynikiem jest
dokumentacja umożliwiająca wcielenie projektu w życie - tzn. utworzenie potrzebnych
plików oraz dostarczenie elementarnych operacji zapisania, odczytania i wyszukania
danych w tabeli przez dostępne na rynku systemy relacyjnych baz danych (Relational
Data-base Management System - RDBMS), takie jak Oracle, MS SQL, DB2, MySQL
lub podobne.

Operacja przekształcenia diagramu encji w projekt tabel jest na ogół bezpośrednia:
każda encja staje się tabelą, której wiersze przechowują dane opisujące pojedynczy
obiekt encji, a kolumny odpowiadają atrybutom encji. Przykład odwzorowania encji
pokazanych na rys. 19 na tabele ilustruje rys. 23. Kolumny tabel wyróżnione
pogrubionym drukiem zawierają klucze własne, jednoznacznie identyfikujące
poszczególne obiekty encji, a kolumny wyróżnione kursywą zawierają klucze obce,
wskazujące powiązane obiekty innej encji.

45

Rysunek 3.23. Schemat tabel odpowiadających diagramowi encji pokazanemu na rys.
19.

Niektóre konstrukcje występujące na diagramach encji łamią jednak zasadę
bezpośredniości przekształcenia i wymagają większego namysłu. Przykładem może
być odwzorowanie relacji uogólnienia pokazanej na rys. 7. Przekształcenie każdej
encji modelu w odrębną tabelę bazy danych prowadzi do sytuacji, w której znalezienie
wszystkich atrybutów jakiegoś towaru, np. opony, wymaga przeszukania dwóch tabel:
Towar i Opona, co zajmuje znacznie więcej czasu niż przeszukanie jednej tabeli.
Innym rozwiązaniem jest odwzorowanie wszystkich encji w jedną tabelę, zawierającą
kolumny dla atrybutów wszystkich encji - w tym przykładzie byłyby to kolumny: nazwa,
producent, cena, rozmiar, waga_dziecka, opis, kolor. Ujemną stroną takiego
odwzorowania jest jednak nieekonomiczne wykorzystanie pamięci, gdyż część
każdego wiersza tabeli pozostałaby niewykorzystana (np. waga_dziecka w wierszu
opisującym oponę). Jeszcze innym wariantem jest zaniechanie wyodrębniania
atrybutów wspólnych i wprowadzenie odrębnych tabel dla każdego rodzaju towaru.
To rozwiązanie jest pozbawione wad dwóch poprzednich, jednak utrzymanie
możliwości jednolitego traktowania wszystkich towarów wymaga utrzymania
identycznego układu kolumn odpowiadających wspólnym atrybutom we wszystkich
tabelach, co może utrudnić późniejsze modyfikacje systemu.

Nie ma jednoznacznie najlepszego rozwiązania przedstawionego problemu. Ocena
zależy od charakteru aplikacji i postawionych jej wymagań, liczby uogólnionych encji

46

oraz liczby atrybutów wspólnych i atrybutów specyficznych. Wybór wariantu jest
decyzją projektową, która musi być podjęta przez projektanta na podstawie jego
wiedzy i doświadczenia.

W praktyce wytwarzania oprogramowania przekształcenie diagramu encji w schemat
tabel bazy danych jest zwykle wykonywane automatycznie przez odpowiednie
narzędzia CASE. W przypadkach wątpliwych, takich jak opisany w poprzednim
akapicie przypadek relacji uogólnienia, projektant ma na ogół możliwość wyboru
odpowiedniego wariantu przekształcenia. Wraz z utworzeniem tabel narzędzie
wspomagające tworzy automatycznie potrzebne indeksy - przeważnie potrzebne są
co najmniej indeksy dla każdego klucza własnego tabeli i dla każdego klucza obcego.
W razie potrzeby specyficznego przeszukiwania tabel projektant może utworzyć
indeksy dodatkowe, których obecność przyspieszy najczęściej występujące operacje.
Projektowanie tabel i indeksów, nazywane często projektowaniem logicznym, jest
zwykle pierwszym etapem projektu bazy danych. Drugi etap, nazywany
projektowaniem implementacji fizycznej, obejmuje rozmieszczenie tabel na dyskach i
opracowanie planów archiwizacji i odtwarzania po awarii.

Zasadniczym elementem projektu implementacji fizycznej jest określenie przestrzeni
tabel. W najprostszym ujęciu pojedyncza przestrzeń tabel obejmuje obszar jednego
lub grupy fizycznych dysków systemu. Tabele przypisane do tej samej przestrzeni
tabel będą więc przechowywane w plikach znajdujących się na tym samym dysku, a
tabele przypisane do różnych przestrzeni tabel będą przechowywane w plikach
znajdujących się na różnych dyskach systemu. Konsekwencje wyboru przestrzeni
tabel są wielorakie.



Różne dyski systemu mogą pracować równolegle - oznacza to, że operacje
dostępu do tabel przypisanych do różnych przestrzeni mogą przebiegać
równocześnie, co może znacznie poprawić wydajność.



Awarie sprzętu dotykają na ogół pojedynczych urządzeń - ewentualna awaria
dysku wyłączy więc z użycia tylko tabele przypisane do tej właśnie przestrzeni.
Odpowiednie przypisane przestrzeni tabel może pozwolić na utrzymanie pracy

47

części aplikacji niekorzystającej z utraconych tabel, pomimo wystąpienia
awarii.



Przestrzenie tabel mogą być zwykle niezależnie dołączane i wyłączane z
systemu - dzięki temu operacje archiwizacji i konserwacji mogą być
wykonywane bez wyłączania z użytku całości pracującej aplikacji.

Zaprojektowanie dużej i wydajnej bazy danych jest zadaniem skomplikowanym.
Dokładniejszy opis naszkicowanych tu zagadnień można znaleźć w podręcznikach
projektowania baz danych.

4.3. Projektowanie interfejsu użytkownika
Większość programów jest tworzona z myślą o bezpośrednim wykorzystaniu przez
człowieka w pracy, przy załatwianiu spraw finansowych lub urzędowych, albo po
prostu dla rozrywki. Dlatego znaczną część każdego oprogramowania stanowi
interfejs użytkownika, czyli ta jego część, która odpowiada za komunikację z
człowiekiem. We współczesnych systemach komputerowych używany interfejs ma
najczęściej postać graficzną (Graphical User Interface - GUI) i obejmuje formularze
ekranowe, za pośrednictwem których użytkownik wprowadza dane i odczytuje wyniki,
okienka dialogowe oraz raporty - wyświetlane, drukowane na papierze lub wysyłane
do innych systemów w postaci plików tekstowych.

Zaprojektowanie interfejsu użytkownika wymaga określenia dwóch różnych
elementów. Pierwszym jest sekwencja komunikacji, czyli treść i kolejność
wyświetlania następujących po sobie ekranów i okienek dialogowych. Drugim jest
format danych oraz kształt graficzny wszystkich widocznych dla człowieka elementów
interfejsu.
Sekwencję komunikacji można wyrazić słownie, np. w postaci scenariusza
opisującego punkt po punkcie wszystkie kolejno wyświetlane ekrany. Dla każdego
ekranu trzeba zdefiniować jego treść oraz wyliczyć zdarzenia powodujące przejście
do następnych ekranów. Takim zdarzeniem jest zazwyczaj naciśnięcie klawisza
Enter, naciśnięcie przycisku wyboru lub wskazanie kursorem i kliknięcie kreślonego
elementu ekranu. Na przykład, podczas wyświetlania na ekranie listy zamówień, jakie
nadeszły od rana do sklepu sprzedaży wysyłkowej, kliknięcie numeru zamówienia w
jednym z wierszy może prowadzić do nowego ekranu pokazującego to wybrane

48

zamówienie. Zbiór scenariuszy można zorganizować wokół typowych procedur
biznesowych wykonywanych na ogół przez użytkowników.

Alternatywnym sposobem opisania sekwencji komunikacji może być narysowanie
diagramu stanów, na którym każdy stan określa treść ekranu, a każde przejście
odpowiada zmianie treści wyświetlonej na ekranie.

Graficzną formę elementów interfejsu można przedstawić w postaci makiety
(prototypu). W najprostszym przypadku może to być rysunek symulujący zrzuty z
ekranu, w bardziej złożonym - działający prototyp interfejsu użytkownika. Działający
prototyp jest oczywiście rozwiązaniem lepszym, które może pokazać nie tylko wygląd
interfejsu, ale także sekwencję komunikacji. Opracowanie prototypu interfejsu
użytkownika jest przykładem zastosowania techniki prototypowania.

Raporty i moduły raportujące
Typową częścią niemal każdej aplikacji biznesowej jest moduł tworzący raporty,
których treść opisuje wyniki już wykonanego przetwarzania. Dane wchodzące w skład
raportu są wybierane z bazy danych i po sformatowaniu prezentowane użytkownikowi
w czytelnej postaci na ekranie, drukowane w postaci trwałego dokumentu
papierowego lub udostępniane na portalu informacyjnym w Internecie.
Przeznaczeniem modułów raportujących jest wyłącznie informowanie użytkownika -
zawartość bazy danych nie ulega w czasie tworzenia raportu żadnej zmianie.

Przykładem modułu raportującego w aplikacji obsługującej wysyłkową sprzedaż
towarów może być podprogram

Drukowanie dokumentu PZ na rys. 22. Treść tego

dokumentu jest typowym raportem, potwierdzającym dostawę i wyliczającym przyjęte
do magazynu towary. Ani treść zamówień, ani stan magazynu nie ulegają podczas
tworzenia dokumentu PZ żadnym zmianom. Postać dokumentu PZ, pokazana na rys.
24, jest przykładem raportu tabelarycznego, którego kolejne wiersze odpowiadają
zawartości kolejnych wierszy wybranych z jednej lub kilku tabel bazy danych. Oprócz
wartości odczytanych z bazy danych raport zawiera stały nagłówek, napisany przez
użytkownika podczas definiowania raportu, oraz wartość ogólną obliczoną podczas

49

generowania raportu zgodnie z algorytmem określonym podczas definiowania
raportu.

Rysunek 24. Przykład raportu tabelarycznego

Inną, często spotykaną postacią raportu jest raport macierzowy, w którym zarówno
wiersze, jak i kolumny odpowiadają różnym kategoriom obiektów, a komórki opisują
relacje łączące te obiekty. Przykładem takiego raportu mógłby być raport sprzedaży,
którego kratki pokazują sprzedaż różnych rodzajów opon (kolumny) w różnych
województwach kraju (wiersze).

Formularze ekranowe
Przeważająca większość aplikacji biznesowych umożliwia interaktywną komunikację
z użytkownikiem, który wprowadza do systemu dane (np. zamówienia, zapytania
stan pozycji magazynowych) i na bieżąco otrzymuje odpowiedzi systemu (np.
określenie dostępności towaru). Zasadniczym narzędziem takiej komunikacji są
formularze ekranowe zawierające pola danych do wprowadzenia, przyciski wyboru,
pola danych pokazujące obliczone wyniki, stałe objaśnienia itd. Specyfikacja
formularzy obejmuje zdefiniowanie pól danych i innych elementów, wskazanie
rozmieszczenia tych elementów na powierzchni ekranu, określenie menu operacji
dostępnych w formularzu i zdefiniowanie reguł nawigacji między ekranami.

Przykładem prostego dialogu z użytkownikiem może być podprogram

Akceptacja

pozycji na rys. 22, który przyjmuje decyzję użytkownika dotyczącą przyjęcia lub
odrzucenia pozycji dostawy. W tym celu podprogram wyświetli formularz zawierający:
pole danych zamówienia, wyszukanego wcześniej w tabeli

Zamówienia

50

zaopatrzeniowe, pole danych pozycji dostawy, która została zeskanowana czytnikiem
kodu kreskowego, oraz pole wyboru decyzji o akceptacji lub odrzuceniu. Wiersz
zamówienia odpowiadający przyjmowanej pozycji zostanie zapewne podświetlony.

4.4. Technologie wspomagające
Metody strukturalne dostarczają narzędzi koncepcyjnych (modeli) umożliwiających
analizę problemu oraz przekształcenie modelu analitycznego w model projektowy,
pokazujący budowę programu i bazy danych. Metody są wspierane przez
technologie, które dostarczają narzędzi fizycznych (oprogramowanie wspomagające)
umożliwiających

automatyzację

znacznej

części

prac

projektowych

i

implementacyjnych. Prace analityczne, które wymagają twórczego wysiłku człowieka,
są znacznie mniej podatne na automatyzację. Podstawowe technologie
implementacyjne obejmują relacyjne bazy danych (RDBMS), systemy wspomagające
projektowanie (CASE) oraz języki czwartej generacji (4GL).
Nośnikiem automatyzacji projektowania są języki czwartej generacji, które można
określić jako języki problemowe, zorientowane na niezwykle wydajne programowanie
komercyjnych aplikacji biznesowych. Charakterystyczną cechą tego obszaru
zastosowań jest konieczność gromadzenia i manipulowania dużymi zbiorami danych,
przy jednoczesnej prostocie wymaganych obliczeń. Podstawowe zadania aplikacji
ograniczają się tu często do komunikacji z użytkownikiem, zapisywania i
wyszukiwania potrzebnych danych oraz przygotowania wymaganych przez
użytkownika raportów.

Powróćmy raz jeszcze do przykładu aplikacji przyjęcia dostawy, pokazanej na rys. 24.
Przestawione tam rozwiązanie, w którym interfejs użytkownika reprezentuje
podprogram Akceptacja pozycji, jest mocno uproszczone. Implementacja interfejsu
użytkownika jest złożona i rzadko udaje się skupić te funkcje w jednym podprogramie.
W tym przykładzie w skład interfejsu użytkownika wejdzie zapewne dosyć dużo
ekranów obsługujących sytuacje wyjątkowe, np. takie, w których nie uda się
rozpoznać etykiety towaru i konieczne będzie wprowadzenie tych danych ręcznie
(ekran wprowadzania towaru), lub takie, w których okaże się, że brakuje zamówienia,
gdyż towary dostarczono na zamówienie telefoniczne (ekran edycji zamówienia). W
rezultacie struktura aplikacji zostanie zdominowana przez układ interfejsu

51

użytkownika, z instrukcjami sięgającymi do tabel bazy danych lub modyfikującymi
zawartość tych tabel, wplecionymi wprost w obsługę poszczególnych pól danych i
przycisków wyboru.

Program aplikacji biznesowej, realizujący zarówno funkcje interfejsu użytkownika, jak
i dostępu do danych, można zaprogramować ręcznie w wybranym języku
programowania, np. C. Alternatywą ręcznego budowania programu jest sięgnięcie do
technologii wspomagających projektowanie i wykorzystanie narzędzi automatycznego
generowania aplikacji, dostarczonych przez producenta bazy danych lub innego,
niezależnego wytwórcę oprogramowania.

Drugie rozwiązanie jest szybsze i mniej narażone na błędy. Wygenerowanie aplikacji
wymaga zdefiniowania interfejsu (formularze i raporty), wskazania tabel bazy danych,
z lub do których mają być przesłane wartości, podania kryteriów wybierania danych
oraz określenia algorytmów obliczania wartości pochodnych. Program w języku
czwartej generacji zostanie wygenerowany automatycznie, a jego interpretator
(run-time module) może być włączony w skład aplikacji jako jeden z jej
podprogramów.

Technologia języków 4GL jest w pełni dojrzała. Generatory formularzy i generatory
raportów, wchodzące w skład systemów wspomagających CASE, umożliwiają
definiowanie różnych wariantów interfejsu, różnych typów dostępu do baz danych
oraz prostych obliczeń. Z kolei narzędzia interpretujące programy 4GL mogą nie tylko
współpracować z różnymi bazami danych, ale także oferują możliwość zdalnego
dostępu wielu stacji roboczych użytkownika do odległych baz danych poprzez łącza
sieciowe.

5. Uwagi bibliograficzne

Dobry opis dojrzałego już stanu rozwoju metodyki strukturalnej podają monografie
[49, 45]. Przegląd konkretnych metod strukturalnych, pokazujący zarówno ich cechy
wspólne, jak i dzielące je różnice, można znaleźć w książce [39].

52

Metodyka strukturalna. Metodyka strukturalna opiera się na zasadzie modelowania i
systematycznego dekomponowania problemu w dwóch wymiarach: w dziedzinie
funkcji (procesów przetwarzania) oraz w dziedzinie danych. W ramach tej metodyki
powstało szereg metod przypisujących różne znaczenie działaniom podejmowanym
w obu tych dziedzinach. Klasyczne metody strukturalne, których rozwój
zapoczątkowały prace Yourdona i DeMarco [50, 40, 46], przypisywały większe
znaczenie dekompozycji i modelowaniu w dziedzinie funkcji. Odmienne podejście
przyjmowały rozwijające się równolegle metody uznające strukturę danych za
najbardziej stabilny element problemu, do którego powinna zostać dopasowana
struktura powstającego programu [48, 44]. W ten nurt wpisywały się też prace nad
modelami danych [211, 210], których trwałym wynikiem koncepcyjnym był diagram
encji oraz rozwój relacyjnych baz danych, które na długie lata określiły sposób
przechowywania dużych ilości danych w systemach komputerowych.
Wraz z rozwojem metod powstawały komputerowe narzędzia wspomagające,
oferujące możliwość tworzenia diagramów i sprawdzania ich spójności, prowadzenia
słownika projektu, a z czasem także generowania prototypów. Rozwój tych narzędzi
oraz języków 4GL [14] doprowadził do powstania systemów wspomagających
zdolnych do wygenerowania z modelu niemal gotowej aplikacji biznesowej. Ten nurt
rozwoju zyskał nieco później nazwę RAD (Rapid Application Development) i
wykroczył daleko poza metodykę strukturalną.

Metodyka strukturalna dojrzała i począwszy od lat dziewięćdziesiątych XX wieku nie
rozwija się dalej. Intensywnie rozwijają się natomiast związane z tą metodyką
technologie - systemy relacyjnych baz danych (RDBMS) i narzędzia wspomagające
(CASE). Dzięki temu metodyka strukturalna wciąż utrzymuje dominujący udział w
rynku IT. Drugim segmentem rynku, który stanowi domenę zastosowania metod
strukturalnych, jest wytwarzanie systemów wbudowanych.

Metody strukturalne. Rozwojowi koncepcji związanych z modelowaniem i
projektowaniem oprogramowania towarzyszył wymuszany potrzebami praktycznymi
rozwój metod prowadzenia wielkich projektów informatycznych. Na przecięciu tych
dwóch nurtów rozwojowych powstały kompletne metody projektowe, oferujące

53

modele, narzędzia i techniki zarządzania projektami. Przykładami takich metod -
stosowanych z powodzeniem do dnia dzisiejszego - mogą być:



klasyczne metody Yourdona [50, 40,49],



metoda SSADM (Structured Systems Analysis and Design Method) [41]
opracowana i promowana przez brytyjskie agendy rządowe,



metoda CDM (Custom Development Method), znana wcześniej jako
CASE*Method [203], opracowana i promowana przez firmę Oracle.

W Polsce szczególnie popularna jest metoda CDM (Oracle) i jej mutacje, silnie
wspierana przez potężne narzędzia wspomagające oferowane przez dominującego w
naszym kraju producenta baz danych. Bardzo dobry opis technik analizy i
projektowania strukturalnego, stosowanych w tej metodzie, można znaleźć w [207].

Relacyjne bazy danych – patrz odpowiedni wykład