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