METODY MODELOWANIA

PROCESÓW

cz. II

Elementy analizy

systemowej

Analiza systemowa

Analiza systemowa to sztuka dochodzenia do
zrozumienia systemu za pomocą tworzenia modeli

Dzisiejsze systemy są duże i złożone

Chociaż jest wymagana dokładność
w modelowaniu, trzeba unikać olbrzymich
i skomplikowanych modeli, nawet jeżeli
reprezentują duże systemy

Sposobem na uporanie się z problemem wielkości i
złożoności systemów jest stosowanie aspektów

Analiza systemowa

Aspekty to umowne uproszczenia otaczającej
nas rzeczywistości

Stosując aspekty analitycy mogą budować
modele zawierające tylko tyle informacji, ile ich
w danej chwili potrzebują

Nie oznacza to, że modele są fałszywym
odzwierciedleniem systemu

To oznacza większą przydatność modeli,
ponieważ jest na nich pokazane tylko to, czego
w danej chwili potrzebuje analityk

Analiza systemowa

filtrowanie informacji

Wyzwaniem dla dzisiejszej analizy
systemowej jest tworzenie złożonych
systemów spełniających oczekiwania
użytkowników

Pomocą może okazać się mechanizm
filtrowania, jako obrona przed zalewem
informacji

Analiza systemowa

W miarę rozrastania się systemów
i rozszerzania na większe obszary biznesu
wzrasta liczba użytkowników znających
jedynie część systemu

Zwiększenie liczby użytkowników oznacza,
że analitycy stają naprzeciw:

większego zróżnicowania podejść

większego zróżnicowania umiejętności

szerszych zainteresowań

Analiza systemowa

Aby sprostać kontaktom ze wzrastającą liczbą
użytkowników, analitycy tworzą modele systemu,
ukazujące aspekty cieszące się największym
zainteresowaniem lub najbardziej istotne dla
każdej grupy użytkowników

Analitycy muszą także eliminować to, co
w danym momencie nie jest potrzebne

Analizując duży system muszą upraszczać
rzeczywistość modelując te aspekty, które najlepiej
przyczynią się do zrozumienia systemu

Analiza systemowa

Aspekty, które są najistotniejsze, to:

aspekt fizyczny istniejącego systemu

aspekt istotny

aspekt danych

aspekt fizyczny nowego systemu

Aspekt fizyczny istniejącego

systemu

Aspekt fizyczny istniejącego systemu stosujemy
na początku projektu, by określić kontekst
badanego systemu i dać użytkownikom czytelny
model

Początkowo użytkownicy wolą zobaczyć modele
przedstawiające ludzi i maszyny aktualnie
działające

Model fizyczny pomaga analitykom
w zidentyfikowaniu:

obszarów problemowych

źródeł informacji o systemie

oraz w szacowaniu działania przyszłego systemu

Aspekt istotny

Jest uważany za „idealny” obraz systemu;

pokazuje jedynie wymagania i celowo pomija

wszystko, co wynika ze sposobu

zaprojektowania i zaimplementowania systemu

Odfiltrowanie aktualnej technologii systemu jest

celowe wówczas, gdy wybiera się rozwiązanie

najlepsze z możliwych

Aspekt istotny jest potrzebny w każdym

projekcie, jako najbardziej użyteczny, a zarazem

najczęściej używany aspekt modelowania

Aspekt danych

Koncentruje się na informacjach
występujących w systemie

Aspekt ten, reprezentowany przez model
danych, ignoruje sposób przetwarzania w
systemie

Aspekt fizyczny nowego systemu

Aspektu fizycznego nowego systemu
używamy do ilustrowania, negocjowania i
definiowania implementacji nowego
systemu z wykorzystaniem komputerów,
ludzi i maszyn

Aspekt ten jest również znany jako model
implementacyjny lub wstępny model
projektu

Stosowanie aspektów

Użyteczność każdego z tych czterech aspektów
zależy od odbiorców oraz od sytuacji

Niestety rzeczywistość nie jest na tyle prosta,
aby analitykom mogło udać się:

zbudowanie pełnego modelu danego aspektu

sprawdzenie poprawności modelu

a następnie przejście do następnego aspektu

Stosowanie aspektów

Informacje niezbędne dla każdego aspektu
oraz użytkownicy, od których pochodzą
informacje, pojawiają się w
przypadkowych chwilach

Analityk w projekcie nie może spodziewać
się, że uzyska wszystkie informacje
wówczas, gdy ich potrzebuje

Stosowanie aspektów

Analityk musi być przygotowany na
zdobywanie informacji różnymi sposobami

Najczęściej jest kilka modeli wykonywanych
dla różnych aspektów, w różnym stopniu
zaawansowania

Nie można jednak porzucić pracy
analitycznej; modele, chociaż niekompletne,
pomagają określać wymagania systemu

Ogólne metody analizy

systemowej

Analiza systemowa

Analiza systemowa jest formalnym
i jawnym badaniem wspomagającym działanie
osób odpowiedzialnych za decyzje lub linię
postępowania w określonej sytuacji
charakteryzującej się niepewnością

Ma ona na celu określenie pożądanego działania
lub linii postępowania przez rozpoznanie i
rozważenie dostępnych wariantów oraz
porównanie ich przewidywanych następstw

Analiza systemowa

Pełna analiza systemowa problemu obejmuje
następujące cztery czynności:

Zbadanie celów rozważanej akcji czy linii
postępowania

Zbadanie możliwych sposobów osiągnięcia tych
celów, z uwzględnieniem propozycji i projektów
nowych rozwiązań

Ocenę pozytywnych i negatywnych skutków każdego
z możliwych wariantów postępowania, uwzględniającą
niepewność przyszłości

Porównanie wariantów według różnych kryteriów i
przedstawienie wyników w sposób umożliwiający
wybór

Ogólne metody analizy

systemowej

Analiza jest studium dziedziny problemu
prowadzącym do specyfikacji obserwowalnego
zachowania systemu

W wyniku analizy otrzymujemy kompletne, spójne
i prawdopodobne wyspecyfikowanie potrzeb,
z podaniem zarówno ilościowych, jak
i funkcjonalnych charakterystyk operacyjnych
(niezawodności, dostępności, wydajności)

Ogólne metody analizy

systemowej

Podczas analizy ustala się potrzeby
systemu - tzn. co system ma robić, aby
zaspokoić wymagania użytkownika

Nie powinna ona natomiast zawierać
szczegółów implementacyjnych tzn. jak
system ma realizować te zadania

Dokumentem, który jest wynikiem analizy,
jest dokument zawierający wymagania
systemu

Ogólne metody analizy

systemowej

Na wymagania systemu składają się:

funkcje - charakterystyki operacyjne,

interfejsy (z którymi ma współpracować
oprogramowanie)

ograniczenia projektowe

Dokument formułujący wymagania ma
następujące cele:

formalizuje potrzeby użytkownika

ustala listę zadań

Ogólne metody analizy

systemowej

W praktyce analizy systemowej
wykształciły się następujące metody
analizy i projektowania:

rozkład funkcjonalny

metoda przepływu danych

modelowanie informacji (danych)

podejście obiektowe

Rozkład funkcjonalny

Rozkład funkcjonalny wymaga
odwzorowania dziedziny problemu na
funkcje i podfunkcje, które ma zapewniać
system

W tym sensie, wymagania systemu muszą
być odwzorowane na funkcje, które
wykonują to co powinien system robić

Rozkład funkcjonalny

Rozkłady na funkcje i podfunkcje są trudne
w konstrukcji i bardzo nietrwałe

Jako wynik otrzymuje się następujące
poziomy:

systemu

podsystemu

funkcji

podfunkcji

Model funkcjonalny - metoda

przepływu danych

Metodą odwzorowania dziedziny problemu
na opis systemu jest przepływ danych
(Data Flow Diagram), często nazywany
analizą strukturalną

W analizie strukturalnej wykorzystuje się
metodykę opracowaną przez Yourdona

Model funkcjonalny - metoda

przepływu danych

Przepływ danych można przedstawić jako zestaw
elementów:

przepływ danych i przepływy sterujące

przekształcenia danych (inaczej zwane
procesami)

magazyny danych

obiekty zewnętrzne (inaczej - terminatory)

opisy procesu

słownik danych

Modelowanie informacji (danych)

Podstawowym narzędziem modelowania
danych jest diagram powiązań danych
(Entity Relationship Diagram)

Modelowanie informacji (danych)

Kolejność postępowania w modelowaniu danych
jest następująca:

znalezienie obiektów w rzeczywistym świecie (lista
obiektów)

opisanie obiektów za pomocą atrybutów (lista atrybutów
dla każdego obiektu)

znalezienie powiązań między obiektami (relacje)

etapy normalizacji (wg. reguł normalizacji Codd'a)
redukującej, nadmiarowość danych i stanowiącej
typowe przygotowanie dla implementacji relacyjnej bazy
danych

Analiza

i projektowanie

strukturalne

Droga do analizy strukturalnej

Aż do końca lat siedemdziesiątych
olbrzymia większość projektów budowy
systemu rozpoczynała się od stworzenia
„powieściowego” określenia wymagań
użytkownika

Analityk dokumentował swoje zrozumienie
potrzeb w masywnym dokumencie,
głównie w postaci narracyjnej, często
nazywanym specyfikacją funkcjonalną

Droga do analizy strukturalnej

Takie dokumenty miały szereg wad:

Były monolityczne. Aby je zrozumieć
należało przeczytać je od początku do końca

Były nadmiarowe. Ta sama informacja była
często powtarzana w dokumencie w kilku
miejscach. Problemy polegały na tym, że gdy
jakiś aspekt wymagań użytkownika uległ
zmianie podczas fazy analizy, to zmiana
musiała być uwzględniona w kilku różnych
częściach dokumentu

Droga do analizy strukturalnej

Takie dokumenty miały szereg wad (cd.):

Były wieloznaczne. Szczegółowe określenie
wymagań użytkownika mogło i często było,
inaczej interpretowane przez użytkownika,
analityka, projektanta i programistę

Ich konserwacja była niemożliwa.
Z opisanych powodów, specyfikacja funkcjonalna
była niemal zawsze przestarzała w chwili
zakończenia budowy systemu, tzn. w momencie
jego wdrożenia

Wprowadzenie

Model buduje się z trzech powodów:

aby skoncentrować się na ważnych cechach

systemu, pomijając mniej istotne

aby móc niewielkim kosztem i minimalnym

ryzykiem wprowadzać zmiany i poprawki do

wymagań użytkownika

aby sprawdzić, czy rozumiemy środowisko

użytkownika i udokumentować to w taki

sposób, aby projektanci i programiści mogli

zbudować system

Wprowadzenie

Większość systemów wymaga wielu modeli

Każdy model koncentruje się na ograniczonej
liczbie aspektów systemu, ograniczając (lub wręcz
pomijając) pozostałe

Jest to prawda zwłaszcza dla wielu systemów
budowanych obecnie, ponieważ mają złożoną
charakterystykę funkcjonalną, złożone struktury
danych oraz złożone zależności czasowe

Wymagania dla narzędzi

modelowania

Narzędzia modelowania powinny być
graficzne, z tekstowym wspomaganiem
odpowiednich szczegółów

W zasadzie grafiki używa się do określenia
składników systemu i interfejsów między nimi;
wszystkie szczegóły umieszcza się
w pomocniczych dokumentach tekstowych
(np. specyfikacja procesu i słownik danych)

Wymagania dla narzędzi

modelowania

Narzędzia modelowania powinny umożliwiać
oglądanie systemu od góry, ze schodzeniem
według określonych podziałów

Narzędzia modelowania muszą umożliwiać
osobne odwzorowanie poszczególnych części
systemu, wraz z prostym sposobem
przechodzenia od jednej części modelu do
innej

Przykładem mogą być mapy, pokazujące kraj
na różnych poziomach szczegółowości

Wymagania dla narzędzi

modelowania

Narzędzia modelowania powinny mieć minimalną
nadmiarowość

Modele stanowią reprezentację pewnego systemu z
rzeczywistego świata, przy czym sam system może
być statyczny lub dynamiczny

Jeśli system zmienia się, zmianie musi także ulec
model, aby pozostać aktualnym

Oczywiście jeżeli zmienia się tylko jeden lokalny
aspekt systemu, wolelibyśmy dokonać tylko jednej
lokalnej zmiany w odpowiadającym aspekcie modelu,
niż być zmuszonym do zmiany wielu innych aspektów

Wymagania dla narzędzi

modelowania

Narzędzia modelowania powinny:

Pomagać przewidzieć zachowanie się
systemu

Być przejrzyste

Dobry model powinien być przejrzysty,
aby czytelnik uświadamiał sobie, że
ogląda reprezentację systemu, a nie zaś
sam system

Diagramy przepływu

danych

Diagramy przepływu danych (DFD)

DFD to tylko jedno z narzędzi modelowania
używanych przez analityka i dostarcza ono tylko
jednego spojrzenia na system – spojrzenia
funkcyjnego

Jeśli będziemy budowali system, w którym
związki między danymi są znacznie ważniejsze
niż funkcje, możemy położyć mniejszy nacisk na
DFD, a zamiast tego skoncentrować się na
zbudowaniu zbioru diagramów związków encji

Diagramy przepływu danych

Jeżeli natomiast charakterystyka czasowa
zachowania systemu dominuje nad
wszystkimi innymi zagadnieniami, możemy
skupić się na diagramie sieci przejść

Składniki DFD

Diagramy przepływu danych buduje się z
czterech podstawowych elementów:

Proces

Przepływ

Magazyn

Terminator

Składniki DFD – proces

Pierwszy składnik DFD nazywa się
procesem

Popularne synonimy to: bąbel, funkcja lub
transformacja

Proces pokazuje pewien fragment systemu
przekształcający dane na wyniki, tzn.
sposób w jaki dane zmieniają się w pewne
wyniki

Składniki DFD – proces

Graficznie proces reprezentuje się
okręgiem

Niektórzy analitycy wolą elipsę lub
prostokąt z zaokrąglonymi rogami, jeszcze
inni prostokąt

Różnice są czysto kosmetyczne, choć
oczywiście należy używać takiego samego
kształtu do reprezentowania wszystkich
funkcji systemu

Składniki DFD – proces

Proces jest nazywany pojedynczym
słowem, frazą lub prostym zdaniem

Nazwa procesu powinna opisywać co robi
proces

Składniki DFD – przepływ

Przepływ reprezentuje się graficznie strzałką do
lub z procesu

Służy on do opisania przenoszenia jednostek lub
pakietów informacji z jednego fragmentu
systemu do innego

Przedstawia więc dane w ruchu, podczas gdy
magazyny reprezentują dane w spoczynku

Składniki DFD – przepływ

Dla większości systemów przepływy będą
reprezentować dane, tzn. bity, znaki,
komunikaty itp.

DFD mogą jednak również służyć do
modelowania innych systemów, np. taśmy
montażowe

Wtedy pakiety lub jednostki przenoszone
przepływami będą materiałem fizycznym

Składniki DFD – przepływ

Przepływy również są nazywane

Nazwa reprezentuje znaczenie pakietu
poruszającego się wzdłuż przepływu

Przepływ przenosi tylko jeden rodzaj
pakietów, wskazywany jego nazwą

Czasami dopuszczalne jest połączenie
kilku elementarnych przepływów danych w
jeden skonsolidowany

Składniki DFD – przepływ

Należy pamiętać, że ta sama zawartość
może mieć różne znaczenie dla różnych
części systemu

Przepływy określają kierunek: grot strzałki
na końcu (lub być może na obu końcach)
wskazuje, czy dane (lub materiał)
poruszają się do czy z procesu (lub w obu
kierunkach)

Składniki DFD – przepływ

Dane poruszające się wzdłuż przepływu
wędrują albo do innego procesu (jako
wejściowe) albo do magazynu, albo do
terminatora

Przepływ z dwoma grotami to dialog,
umieszczenie dwóch pakietów danych
(zapytania i odpowiedzi) na tym samym
przepływie

W przypadku dialogu pakiety na obu
końcach strzałki muszą być nazwane

Składniki DFD – przepływ

Przepływy danych na DFD mogą schodzić się i
rozchodzić

Jeżeli przepływ jest rozbieżny, oznacza to
przesyłanie kopii pakietu danych do różnych
części systemu lub rozdzielenie złożonego
pakietu danych na kilka elementarnych, z
których każdy jest przesyłany do innej części
systemu

W przepływie zbieżnym kilka elementarnych
pakietów danych łączy się w bardziej złożone
pakiety danych

Składniki DFD – przepływ

Składniki DFD – przepływ

Przepływ nie odpowiada na wiele pytań
proceduralnych, które nasuwają się
podczas oglądania DFD, np. nie udzielają
odpowiedzi na pytania o sposób
pobierania informacji

Składniki DFD – przepływ

W przypadku, gdy jest kilka przepływów
wejściowych i wyjściowych, nie jest określone

w jakiej kolejności przychodzą pakiety danych i w
jakiej kolejności są generowane pakiety wynikowe

czy jednemu zestawowi pakietów wejściowych
odpowiada dokładnie jeden zestaw pakietów
wyjściowych

Zwykle jest to modelowane diagramem
przepływu sterowania lub innym proceduralnym
narzędziem modelowania

DFD nie odnosi się do takich zagadnień

Składniki DFD – magazyn

Magazyn służy do modelowania zbioru danych
w bezruchu

Oznacza się go dwoma równoległymi liniami, są też inne
alternatywne symbole graficzne

Zwykle nazwa wybrana dla magazynu to liczba mnoga od
nazwy pakietów przenoszonych przepływami do i z
magazynu

Składniki DFD – magazyn

Dla projektów informatycznych obserwuje
się tendencję nazywania magazynów
plikami lub bazami danych

Magazyny rzeczywiście implementuje się
w ten sposób w systemach
skomputeryzowanych

Ale mogą być też inne formy, np.
w przypadku modelowania przepływów
produkcji

Składniki DFD – magazyn

Pomijając fizyczną postać magazynu, można
zapytać o jego przeznaczenie

Czy jego istnienie wynika z podstawowych
wymagań użytkownika, czy też jest to wygodny
aspekt implementacji sytemu

W pierwszym przypadku magazyn służy do
czasowego buforowania informacji między
dwoma procesami, działającymi w różnym czasie

Magazyny tworzy się też w przewidywaniu
przyszłych potrzeb użytkownika

Składniki DFD – magazyn

Magazyny są połączone przepływami
z procesami

Przepływ z magazynu interpretuje się zwykle jako
odczyt lub dostęp do informacji w magazynie

Przepływ do magazynu opisuje się często jako
zapis, aktualizację lub być może usuwanie

We wszystkich przypadkach jest oczywiste, że
stan magazynu ulega zmianie w wyniku
wchodzącego przepływu

Składniki DFD – magazyn

Badając przepływy wchodzące i wychodzące dla

magazynu, pojawia się wiele pytań

proceduralnych, np. czy przepływ reprezentuje

pojedynczy pakiet, wiele pakietów, fragment

pakietu itp.

Czasem można udzielić odpowiedzi na podstawie

etykiety przepływu

Aby dowiedzieć się wszystkiego, co może być

potrzebne na temat przepływu wychodzącego z

magazynu, będziemy musieli poznać szczegóły

procesu (jego specyfikację), do którego jest

przyłączony przepływ

Składniki DFD

Diagramy przepływu danych buduje się z
czterech podstawowych elementów:

Proces

Przepływ

Magazyn

Terminator

Składniki DFD – magazyn

Jednego szczegółu proceduralnego możemy być pewni:
magazyn jest bierny, dane nie wychodzą z magazynu
wzdłuż przepływu, dopóki jakiś proces jawnie tego nie
zażąda

Czyni się jeszcze jedno szczegółowe założenie
proceduralne

Magazyn nie ulega zmianie, gdy pakiet informacji
wychodzi z magazynu przez przepływ

Programista nazywa to odczytem nie niszczącym

Innymi słowy z magazynu jest pobierana kopia pakietu,
a stan magazynu pozostaje bez zmiany

Założenie to nie dotyczy modelowania przepływów
obiektów fizycznych

Składniki DFD – terminator

Graficznie przedstawia się go za pomocą prostokąta

Terminatory reprezentują zewnętrzne obiekty,
z którymi komunikuje się system

Może to być grupa osób, firma zewnętrzna, inny dział w
tej samej firmie czy inny system

Składniki DFD – terminator

Należy pamiętać:

Terminatory znajdują się na zewnątrz
modelowanego systemu; przepływy łączące je
z różnymi procesami (lub magazynami)
systemu stanowią interfejs między systemem
a otaczającym światem

W konsekwencji jest oczywiste, że ani
analityk, ani projektant nie mogą zmienić
terminatora ani wpłynąć na sposób jego
działania

Składniki DFD – terminator

Żaden istniejący związek między terminatorami
nie będzie pokazany w modelu DFD

Może być nawet kilka takich związków, lecz
z definicji nie wchodzą one w skład
modelowanego systemu

Odwrotnie, jeśli związki występujące między
terminatorami są istotne dla analityka
i powinny być modelowane, aby poprawnie
udokumentować wpływ na system, to
z definicji terminatory wchodzą w skład systemu
i należy je modelować jako procesy

Wskazówki dotyczące

konstruowania DFD

Wybieraj znaczące nazwy dla procesów,
przepływów, magazynów i terminatorów

Numeruj procesy

Przerysuj DFD, ilekroć jest to niezbędne z
przyczyn estetycznych

Unikaj nadmiernie złożonych DFD

Upewnij się, że DFD jest wewnętrznie
niesprzeczny oraz niesprzeczny
z innymi spokrewnionymi DFD

Nazwy

KOWALSKI

zamówienia

poprawne
zamówienia

błędne
zamówienia

Sprawdź

zamówienia

zamówienia

poprawne
zamówienia

błędne
zamówienia

Nadmiernie
złożone DFD

wg.
J. Roszkowski
Analiza i projektowanie
strukturalne

Niesprzeczność

Przetwarzaj

materiał

a

c

d

b

Przetwarzaj

materiał

a

c

d

b

Przykład nieskończonej
studni

Przykład procesu bez wejść

Zrównoważone DFD

Należy unikać diagramów zbyt złożonych

Realizuje się to przez podział całego
diagramu na szereg poziomów,
z których każdy dostarcza więcej
szczegółów o wyższym poziomie

Zrównoważone DFD

SYSTEM

DIAGRAM KONTEKSTOWY

A

B

C

1

3

4

2

DIAGRAM 0

A

B

C

X

Y

Z

3.1

3.3

3.4

3.2

DIAGRAM 3

X

Z

Y

Zrównoważone DFD

DFD najwyższego poziomu składa się tylko
z jednego procesu reprezentującego cały
system

Przepływy danych pokazują interfejsy
między systemem i terminatorami
zewnętrznymi (wraz z ewentualnymi
magazynami zewnętrznymi)

Ten specjalny DFD nazywa się
diagramem kontekstowym

Zrównoważone DFD

DFD bezpośrednio poniżej diagramu
kontekstowego nazywa się Diagramem 0

Przedstawia najwyższy poziom widzenia
głównych funkcji systemu oraz głównych
interfejsów między tymi funkcjami

Każdy z tych procesów dla wygody
powinien być numerowany

Zrównoważone DFD

Numeracja służy również jako wygodny
sposób powiązania procesu z DFD
bezpośrednio niższego poziomu, opisującym
pełniej ten proces, na przykład:

proces z Diagramu 0 jest związany
z DFD niższego poziomu nazywanym Diagram 3

procesy wewnątrz Diagramu 3 numeruje się
3.1, 3.2, 3.3 itd.

Zrównoważone DFD

SYSTEM

DIAGRAM KONTEKSTOWY

A

B

C

1

3

4

2

DIAGRAM 0

A

B

C

X

Y

Z

3.1

3.3

3.4

3.2

DIAGRAM 3

X

Z

Y

Zrównoważone DFD

Jest to w miarę prosty sposób organizacji
potencjalnie olbrzymiego diagramu
przepływu danych w grupę poręcznych
fragmentów

Warto jednak dodać parę uwag do tego
opisu:

Zrównoważone DFD

Jak określić, ile poziomów powinien
mieć DFD?

Żaden DFD nie powinien zawierać więcej
niż 6-7 procesów

Jeśli specyfikacji pewnego procesu nie da
się zapisać na jednej stronie, to jest on
prawdopodobnie zbyt złożony i należy go
rozbić na DFD niższego poziomu przed
napisaniem specyfikacji

Zrównoważone DFD

Jakiej liczby poziomów należy oczekiwać
po typowym systemie?

W prostym systemie pojawią się 2 lub 3
poziomy, w dużym 5 do 8

Całkowita liczba procesów rośnie wykładniczo,
wraz ze wzrostem poziomów

Jeśli na każdym diagramie występuje
7 procesów, to trzeci poziom będzie zawierać
343 procesy, piąty 16 807,
a dziewiąty 40 353 607

Zrównoważone DFD

Czy wszystkie części systemu
powinny być rozbite do tego samego
poziomu?

Nie muszą

Niektóre części systemu mogą być bardziej
złożone niż inne i mogą wymagać jednego
lub dwóch dodatkowych poziomów

Zrównoważone DFD

W jaki sposób pokazywać poziomy

użytkownikowi?

Wielu użytkowników chce patrzeć tylko na jeden

diagram

Członek kierownictwa obejrzy tylko diagram

kontekstowy lub ewentualnie Diagram 0

Użytkownik operacyjny zechce zapoznać się z

diagramem obejmującym fragment systemu,

który go dotyczy

Prezentacja całości powinna odbywać się od

góry

Zrównoważone DFD

Jak upewnić się, że poziomy DFD są ze
sobą zgodne?

Dla zapewnienia zgodności każdego diagramu z
diagramem nadrzędnym stosuje się prostą
regułę

Przepływy danych wchodzące i wychodzące z
procesu na danym poziomie powinny
odpowiadać przepływom danych wchodzących
i wychodzących z całego diagramu niższego
poziomu opisującego ten proces

Zrównoważone DFD

SYSTEM

DIAGRAM KONTEKSTOWY

A

B

C

1

3

4

2

DIAGRAM 0

A

B

C

X

Y

Z

3.1

3.3

3.4

3.2

DIAGRAM 3

X

Z

Y

Zrównoważone DFD

Jak pokazywać magazyny na różnych
poziomach?

Jest to miejsce świadomego wprowadzania
nadmiarowości do modelu

Pokaż magazyn na najwyższym poziomie, na
którym po raz pierwszy służy jako interfejs
między procesami

Następnie pokaż go na każdym diagramie
niższego poziomu, który szerzej opisuje te
procesy

Magazyny na różnych poziomach

X

A.1

A.2

X

B.1

B.2

X

A

B

Słowniki danych

Drugim ważnym narzędziem modelowania
jest słownik danych

Jest to uporządkowany wykaz wszystkich
elementów danych mających związek z
systemem, wraz z ich precyzyjnym
określeniem

Gwarantuje to, że użytkownik
i analityk będą jednakowo rozumieli
wszystkie wejścia, wyjścia, składniki
magazynów i obliczenia pośrednie

Słowniki danych

Słownik danych definiuje elementy danych w
następujący sposób:

opisując znaczenie przepływów
i magazynów pokazanych na diagramach
przepływu danych

opisując budowę złożonych pakietów danych
transmitowanych wzdłuż przepływów, tzn.
pakietów (takich jak adres klienta), które
można rozbić na bardziej elementarne
jednostki (takie jak miasto, województwo, kod
pocztowy itd.)

Słowniki danych

Słownik danych definiuje elementy danych
w następujący sposób (cd.):

opisując budowę pakietów danych w
magazynach

określając właściwe wartości i jednostki
elementarnych porcji informacji dla
przepływów i magazynów danych

opisując szczegóły związków między
magazynami, pokazanymi na diagramie
związków encji

Notacja słownika danych

Następująca notacja należy do
najpopularniejszych i korzysta
z niewielu prostych symboli:

=

składa się z

+

i

()

opcjonalnie (może wystąpić lub nie)

{} iteracja
[]

wybór jednej z kilku alternatywnych możliwości

** komentarz
|

rozdziela alternatywne możliwości w konstrukcji []

Słowniki danych

Przykładowo, moglibyśmy zdefiniować

pełne-nazwisko

następująco:

*definicja pełnego nazwiska*
pełne-nazwisko = tytuł + imię + (drugie imię) +

nazwisko

tytuł

[Pan | Pani | Dr | Profesor]

imię

{dozwolony-znak}

drugie-imię

{dozwolony-znak}

nazwisko

{dozwolony-znak}

dozwolony-znak [A-Z|a-z|0-9|’|-| |]

Elementarne elementy danych

Elementarne elementy danych to takie, dla
których nie istnieje znacząca dekompozycja w
kontekście środowiska użytkownika

Po zidentyfikowaniu elementarnych jednostek
danych należy je wprowadzić do słownika
danych

Słownik danych powinien zawierać krótki
komentarz, otoczony znakami *, podający
znaczenie terminu w kontekście użytkownika

Słowniki danych

Budowa słownika to jeden z
najważniejszych aspektów tworzenia
modelu

Bez formalnego słownika, definiującego
znaczenie wszystkich terminów, nie ma
szans na precyzję

Specyfikacja procesu

Jest to opis tego co dzieje się wewnątrz każdego
elementarnego procesu na najniższym poziomie
DFD

Przeznaczenie specyfikacji procesu definiuje, co
należy zrobić w celu przekształcenia wejść w
wyjścia

Stanowi szczegółowy opis reguł działania
podanych przez użytkownika, które realizuje
dany proces

Specyfikacja procesu

Do utworzenia specyfikacji procesu można
użyć wielu narzędzi:

tablic decyzyjnych

strukturalnego języka polskiego

warunków początkowych i końcowych

diagramów przepływu sterowania

diagramów Nassi-Shneidermana

Podstawowe wymagania

Specyfikacja procesu musi mieć taką
postać, aby możliwa była jej weryfikacja
przez użytkownika i analityka

Właśnie z tego powodu unika się
stosowania opisowego języka polskiego,
gdyż jest wieloznaczny, zwłaszcza przy
opisywaniu alternatywnych akcji (decyzji)
i akcji powtarzających się (cykli)

Podstawowe wymagania

Specyfikacja procesu musi być wyrażona w
postaci pozwalającej na efektywną komunikację
z różnymi kręgami słuchaczy

Jakkolwiek pisze ją zwykle analityk, tej lektury
musi dokonać szeroki krąg użytkowników,
menedżerów, audytorów, pracowników itp.

Większość analityków preferuje jako metodę
zapisu specyfikacji procesów strukturalny język
polski

Podstawowe wymagania

Dobre narzędzie do specyfikacji procesów nie

powinno wymuszać (lub narzucać) arbitralnych

decyzji projektowych i implementacyjnych

Jest to często bardzo trudne, ponieważ

użytkownik, który określa reguły działania dla

poszczególnych procesów w DFD, ma skłonność

do opisywania ich w terminach wynikających z

ich obecnej realizacji

Zadaniem analityka, jest wydobycie z opisu

istoty tego, co jest robione, nie zaś tego jak się

to obecnie odbywa

Strukturalny język polski

Strukturalny język polski, jak wskazuje nazwa, to

„polski ze strukturą”

Jest to podzbiór języka polskiego z istotnymi

ograniczeniami na postać używanych zdań i

sposób ich łączenia

Jest też znany pod nazwami PDL (Program

Design Language) lub PSL (Problem Statement

Language lub Problem Specification Language)

Jego celem jest osiągnięcie rozsądnego

kompromisu między pozycją formalnego języka

programowania a swobodą i czytelnością języka

polskiego

Strukturalny język polski

Zdanie w strukturalnym języku polskim może
być równaniem algebraicznym, np.

X = (Y*Z)/(Q+14)

lub prostym zdaniem rozkazującym, składającym
się z czasownika i dopełnienia

Zdania opisujące obliczenia mogą być
poprzedzone czasownikami OBLICZ, DODAJ,
USTAW itp.

Poprzedni przykład można więc zapisać jako

OBLICZ X = (Y*Z)/(Q+14)

Strukturalny język polski

Inne przykłady zapisane w strukturalnym
języku polskim :
USTAW STOPA_PODATKOWA NA 30
DODAJ 3 DO X
POMNÓŻ CENA_JEDNOSTKOWA PRZEZ
ILOŚĆ

Strukturalny język polski

Czasowniki należy dobierać z niewielkiej grupy
czasowników odpowiadających akcjom, takich
jak:

WEŹ albo WCZYTAJ albo POBIERZ
UMIEŚĆ albo WYŚWIETL albo WPISZ
ZNAJDŹ albo SZUKAJ
DODAJ, ODEJMIJ, POMNÓŻ, PODZIEL
OBLICZ, USUŃ, SPRAWDŹ, PRZENIEŚ
ZASTĄP, USTAW, SORTUJ

W większości przypadków 40-50 czasowników
wystarcza do zapisania wszystkich specyfikacji
procesów

Strukturalny język polski

Obiekty występujące w dopełnieniach prostych
zdań rozkazujących powinny składać się z
elementów danych zdefiniowanych w słowniku
lub być terminami lokalnymi

Terminy lokalne to słowa wprost zdefiniowane w

danej specyfikacji procesu; są one znane i

znaczące jedynie wewnątrz tej specyfikacji

Typowy przykład terminu lokalnego to obliczenie

pośrednie, służące do wyprodukowania

ostatecznych wyników procesu

Strukturalny język polski

Następująca specyfikacja procesu
w strukturalnym języku polskim bada ciąg
rekordów zamówień w magazynie
ZAMÓWIENIA, aby obliczyć sumę dzienną:

Strukturalny język polski

suma_dzienna = 0
DO WHILE istnieją zamówienia w ZAMÓWIENIA z

data_faktury = obecnej dacie

CZYTAJ następne zamówienie z ZAMÓWIENIA z

data_faktury = obecnej dacie

WYŚWIETL w Księgowości numer_faktury,

nazwa_klienta, suma_całkowita

suma_dzienna = suma_dzienna+suma_całkowita

ENDDO
WYŚWIETL w Księgowości sumę_dzienną

Diagramy związków

encji

Diagramy związków encji

Entity Ralationship Diagram ERD to model
sieciowy opisujący na wysokim poziomie
abstrakcji układ danych przechowywanych w
systemie

Różni się więc od diagramu przepływu danych,
modelującego funkcje realizowane przez system,
oraz od diagramu sieci przejść, modelującego
czasową charakterystykę zachowania systemu

Diagramy związków encji

Model danych jest istotny przede wszystkim
dlatego, że struktury danych i ich powiązania
mogą być tak złożone, że będziemy chcieli je
obejrzeć i zbadać niezależnie od ich
przetwarzania

Jest tak zwłaszcza wtedy, gdy pokazujemy
model systemu kierownictwu wysokiego
szczebla, którzy nie są zainteresowani
szczegółami operacyjnymi codziennej pracy
systemu

Diagramy związków encji

Takich użytkowników bardziej interesuje:

jakich danych potrzebujemy do
prowadzenia naszej działalności,

jak są one powiązane między sobą

kto jest ich właścicielem

kto ma do nich dostęp

Diagramy związków encji

Diagram związków encji to wydajne narzędzie
modelowania do komunikacji z grupą
zarządzającą bazą danych

Opierając się na informacji umieszczonej na
ERD, grupa zarządzającą bazą danych może
ustalić jakie rodzaje kluczy, indeksów lub
wskaźników będą niezbędne do zapewnienia
skutecznego dostępu do rekordów bazy danych

Diagramy związków encji

ERD ma również wielką zaletę dla analityka: uwypukla
związki między magazynami danych na DFD, które w
przeciwnym razie byłyby widoczne tylko w specyfikacji
procesu

Typowy ERD pokazany jest na rysunku

Każdy z prostokątów odpowiada magazynowi danych na
DFD, widać też związki (połączenia), zazwyczaj nie
pokazywane na DFD

Diagramy związków encji

Istnieją cztery podstawowe składniki
diagramu związków encji:

typy obiektów

związki

wskaźniki asocjowanych typów obiektów

wskaźniki nadtypów/podtypów

Typy obiektów

Na diagramie związków encji typ obiektu
jest przedstawiany prostokątem

Reprezentuje on populację lub zbiór
obiektów w świecie rzeczywistym, którego
poszczególne elementy (lub egzemplarze)
mają następujące cechy:

Typy obiektów - cechy

Każdy z nich można w jakiś sposób
zidentyfikować

Istnieje sposób odróżniania poszczególnych egzemplarzy
typu obiektu

Jeśli mamy typ obiektu KLIENT, musimy jakoś
odróżniać jednego klienta od drugiego (być może po
numerze konta, nazwisku lub numerze ewidencyjnym)

Gdyby wszyscy byli tacy sami (jeśli prowadzimy firmę,
dla której klienci to bezimienne postacie wchodzące po
zakupy do naszego sklepu), wówczas KLIENT nie byłby
sensownym typem obiektu

Typy obiektów - cechy

Każdy odgrywa jakąś rolę w budowanym

systemie

Inaczej mówiąc, aby typ obiektu był uzasadniony, musi

być możliwość stwierdzenia, że system nie mógłby

działać bez dostępu do jego elementów

Budując system przyjmowania zamówień dla sklepu,

można przyjąć, że oprócz klientów w sklepie są również

dozorcy, z których każdy jest identyfikowany nazwiskiem

Chociaż dozorcy pełnią w sklepie pożyteczną funkcję, to

system przyjmowania zamówień może funkcjonować bez

nich, dlatego nie powinni być typem obiektu w modelu

systemu

Oczywiście takie rzeczy należy zweryfikować

z użytkownikami podczas budowy modelu

Typy obiektów - cechy

Każdy może być opisany jednym lub
więcej elementami danych

KLIENT może być opisany takimi elementami
danych, jak: nazwisko, adres, limit kredytowy i
numer telefonu

Nazywa się to przypisywaniem atrybutów
danych typowi obiektu

Atrybuty powinny odnosić się do każdego
egzemplarza typu obiektu, np. każdy klient
powinien mieć nazwisko, adres, limit kredytowy,
numer telefonu itp.

Typy obiektów

W wielu budowanych systemach typy obiektów
będą systemową reprezentacją materialnych
obiektów świata rzeczywistego

Typowe obiekty to: klienci, pozycje inwentarza,
pracownicy, produkowane części itp.

Obiekt istnieje materialnie w rzeczywistym
świecie, a typ obiektu jest jego systemową
reprezentacją

Obiekt może być jednak również czymś
niematerialnym, np. harmonogramem, planem,
standardem, strategią, mapą

Typy obiektów

W systemie często typami obiektów są ludzie,
dlatego może być taka sytuacja, że ta sama
osoba (a także dowolny inny obiekt materialny)
może odpowiadać kilku różnym typom obiektów
w różnych modelach danych lub nawet w tym
samym modelu danych

Jan Kowalski może być PRACOWNIKIEM w
jednym modelu i KLIENTEM w innym

Może także być PRACOWNIKIEM
i KLIENTEM w tym samym modelu danych

Typy obiektów

Zazwyczaj posługujemy się formą
pojedynczą rzeczownika, np. pracownik,
klient itp.
Nie jest to konieczne ale jest wygodne

Istnieje odpowiedniość między obiektami
na ERD i magazynami na DFD

Jeśli KLIENT jest obiektem na ERD to
powinien istnieć magazyn KLIENCI na
DFD

Związki

Obiekty są ze sobą połączone związkami

Związki jest to zbiór powiązań między obiektami i
jest przedstawiany rombem

Na rysunku przedstawiony jest prosty związek
między dwoma obiektami

Związki mogą istnieć między więcej niż dwoma
obiektami

Związki

Należy pamiętać, że związek reprezentuje
zbiór powiązań

Każdy egzemplarz związku jest
powiązaniem między zerem lub większą
liczbą wystąpień jednego obiektu i zerem
lub większą liczbą wystąpień drugiego

Związki

Związek KUPUJE przedstawiony na rysunku
może zawierać więc następujące konkretne
egzemplarze:

egzemplarz 1: klient 1 kupuje towar 1

egzemplarz 2: klient 2 kupuje towar 2 i 3

egzemplarz 3: klient 3 kupuje towar 4

egzemplarz 4: klient 4 kupuje towar 5,6,7

egzemplarz 5: klient 5 nie kupuje towarów

egzemplarz 6: klienci 6 i 7 kupują towar 8

egzemplarz 7: klienci 8,9,10 kupują towary 9, 10, 11

Związki

Jak widać związek może łączyć dwa lub większą

liczbę egzemplarzy tego samego obiektu

Związek reprezentuje coś, co musi być

pamiętane przez system – nie może być

obliczone ani wprowadzone mechanicznie

Model danych przedstawiony na rysunku

wskazuje więc, że istnieje pewna istotna

przyczyna, dla której użytkownik chce pamiętać,

że klient 1 kupił towar 1 itd.

Wskazuje też, że nie istnieją żadne przesłanki,

pozwalające stwierdzić a priori, że klient 1 kupił

towar 1 i nic więcej

Związki

Związek reprezentuje pamięć systemu

Oczywiście obiekt także reprezentuje pamięć
systemu

Między dwoma obiektami może istnieć więcej niż
jeden związek

Na kolejnym rysunku przedstawiono związki
między PACJENTEM a LEKARZEM

Na pierwszy rzut oka może to wyglądać na
niepotrzebny podział: ilekroć lekarz przyjmuje
pacjenta, wystawia mu rachunek

Związki

Z rysunku wynika również, że związek płacenia jest
oddzielony od związku leczenia

Być może niektórzy pacjenci płacą tylko za pierwszą
wizytę, inni za wszystkie wizyty a jeszcze inni nie płacą
wcale

Może okazać się, że
istnieje kilka różnych
egzemplarzy „leczenia”
między lekarzem i tym
samym pacjentem (tzn.
wizyta początkowa,
wizyty kontrolne, itp.)

Związki

Częstsza sytuacja to wiele związków
między wieloma obiektami

Kolejny rysunek pokazuje związek zwykle
istniejący między nabywcą, sprzedawcą,
agentem nieruchomości, adwokatem
nabywcy i adwokatem sprzedawcy, w celu
sprzedaży i zakupu domu

Związki

Dla złożonych
diagramów (jak na
rysunku) związek
i połączone nim
obiekty należy czytać
jako całość

Związek można opisać
z perspektywy
dowolnego
występującego typu
obiektu, wszystkie
perspektywy są
poprawne

Związki

Właśnie zbiór tych perspektyw poprawnie
opisuje związek

Na rysunku związek NEGOCJUJE CENĘ można
odczytać w następujący sposób:

Agent nieruchomości negocjuje cenę między
nabywcą i sprzedawcą

Nabywca za pośrednictwem agenta
nieruchomości negocjuje cenę ze sprzedawcą

Sprzedawca za pośrednictwem agenta
nieruchomości negocjuje cenę z nabywcą

Związki

Alternatywna notacja dla związków

Związki w diagramie E-R są
wielokierunkowe, można je czytać
w dowolnym kierunku

Diagramy E-R nie pokazują liczności, tzn.
nie pokazują liczby obiektów biorących
udział w związku

Jest to całkowicie świadome i przemyślane:
takie szczegóły znajdują się w słowniku
danych

Związki

Niektórzy analitycy używają alternatywnej notacji,

podającej liczność i kierunek

Związek między KLIENTEM i TOWAREM

Dodatkowa notacja pokazuje, że:

KLIENT to punkt zaczepienia, podstawowy obiekt,

z którego perspektywy należy odczytywać związek

Związek składa się z KLIENTA połączonego z N TOWARAMI, tzn.

pojedynczy klient może zakupić 0, 1, 2 ... N towarów. Jednak

związek wskazuje, że tylko jeden klient wystąpi w każdym

egzemplarzu związku

Wyklucza to przypadki, gdy kilku klientów jest związanych z

zakupem jednego towaru

1

N

Związki

Inną popularną notację przedstawiono na
kolejnym rysunku; strzałka z podwójnym
grotem służy do pokazania związku jeden-do-
wielu, natomiast strzałka z pojedynczym grotem
oznacza związek jeden-do-jednego między
obiektami

Wskaźniki asocjowanych typów

obiektów

Specjalną notacją na diagramie E-R jest
wskaźnik asocjowanego obiektu, który
reprezentuje coś funkcjonującego zarówno
jako obiekt, jak i związek

Asocjowany typ obiektu można również
traktować jako reprezentację związku, o
którym chcemy zachować pewną
informację

Wskaźniki asocjowanych typów

obiektów

Rozważmy prosty przypadek klienta kupującego
towar (lub towary) pokazany na rysunku

Wskaźniki asocjowanych typów

obiektów

Istotą sprawy jest, że związek ZAKUPU to nic

więcej tylko powiązanie KLIENTA z jednym lub z

większą liczbą TOWARÓW

Załóżmy jednak, że istnieją pewne dane, które

chcemy zapamiętać dla każdego egzemplarza

zakupu (np. porę dnia)

Gdzie przechowywać te informacje? „Pora dnia”

to na pewno nie atrybut KLIENTA, ani też

TOWARU

Wobec tego przypisujemy „porę dnia” samemu

zakupowi i umieszczamy na diagramie w sposób

pokazany na rysunku

Wskaźniki asocjowanych typów

obiektów

ZAKUP zapisujemy teraz w prostokącie

i łączymy strzałką z rombem anonimowego

związku

Ma to wskazywać, że ZAKUP ma tutaj dwa

znaczenia

Typ obiektu, czyli coś o czym chcemy

przechowywać informacje. Tutaj chcemy

pamiętać porę, kiedy klient dokonał zakupu i

zaoferowany upust

Związek łączący dwa typy obiektów KLIENT

i TOWAR. Istotną sprawą jest, że KLIENT

i TOWAR są całkowicie odrębne. Istnieją

niezależnie od tego, czy dokonano jakiegoś

zakupu

Wskaźniki asocjowanych typów

obiektów

ZAKUP zależy od istnienia KLIENTA i TOWARU

Pojawia się jedynie w wyniku związku między
innymi obiektami, do którego jest dołączony

Związek przedstawiony na rysunku świadomie
pozostawiono anonimowym, ponieważ wskaźnik
asocjowanego typu obiektu (ZAKUP) jest
jednocześnie nazwą związku

Wskaźniki nadtypu/podtypu

Typy obiektów nadtyp/podtyp obejmują typ
obiektu i jedną lub więcej podkategorii,
połączonych związkiem

Rysunek pokazuje typowy nadtyp/podtyp

Kategorią ogólną jest PRACOWNIK,
podkategoriami zaś są PRACOWNIK ETATOWY
i PRACOWNIK GODZINOWY

Wskaźniki nadtypu/podtypu

Poddtypy są połączone z nadtypem
anonimowym związkiem, a nadtyp jest
połączony ze związkiem przekreśloną linią

W tej notacji nadtyp określa się
elementami danych odnoszącymi się do
wszystkich podtypów

Wskaźniki nadtypu/podtypu

Możemy sobie wyobrazić, że wszyscy pracownicy
są opisani za pomocą następujących danych:

nazwisko

staż pracy

adres domowy

nazwisko kierownika

Natomiast każdy podtyp jest określany różnymi
elementami danych, w przeciwnym razie nie
miałoby sensu wyróżnianie ich

Wskaźniki nadtypu/podtypu

Wobec tego PRACOWNIK ETATOWY jest
opisany takimi informacjami jak:

pensja miesięczna

procent premii rocznej

zakres korzystania z samochodu firmy

a PRACOWNIK GODZINOWY takimi jak:

stawka godzinowa

dopłata za nadgodziny

czas rozpoczęcia

Wskazówki do konstruowania

diagramów związków encji

Ważne jest w jaki sposób należy wykrywać
obiekty i związki

Początkowy model typów obiektów i związków
będzie zwykle oparty na:

znajomości aplikacji użytkownika

wywiadach z użytkownikami

wszelkich innych sposobach zbierania informacji, z
jakich można skorzystać

Diagramy związków encji zmienia się
i poprawia wielokrotnie

Dołączanie dodatkowych typów

obiektów

Początkowy ERD tworzy się na podstawie
wywiadów z użytkownikami i wiedzy na temat
dziedziny klienta

Powinno to wskazać główne obiekty
i związki

Po sporządzeniu wstępnego ERD następny krok
to przypisanie typom obiektów atrybutów –
elementów danych

Dołączanie dodatkowych typów

obiektów

Można to osiągnąć w różny sposób:

Jeśli model procesów DFD jest już
sporządzony lub jest budowany równolegle z
modelem danych, wówczas będzie już istniał
słownik danych

Jeśli model procesów jeszcze nie istnieje to
należy rozpocząć od wywiadów ze wszystkimi
użytkownikami, aby zbudować wyczerpującą
listę (definicji) elementów danych

Dołączanie dodatkowych typów

obiektów

W wyniku przypisywania atrybutów mogą
wystąpić trzy powody tworzenia nowych
obiektów:

Można odkryć elementy danych, które można
przypisać tylko do niektórych egzemplarzy typu
obiektu

Można wykryć, że pewne elementy danych mają
zastosowanie do wszystkich egzemplarzy dwóch
różnych typów obiektów

Można odkryć, że pewne elementy danych opisują
związki między innymi typami obiektów

Dołączanie dodatkowych typów

obiektów

Jeśli podczas przypisywania atrybutów
typom obiektów okaże się, że pewne
elementy danych nie mogą być przypisane
wszystkim egzemplarzom pewnego typu
obiektu, należy utworzyć zbiór podtypów
dla danego typu i przypisać elementy
danych odpowiednim podtypom

Dołączanie dodatkowych typów

obiektów

Przypuśćmy, że budujemy system obsługi
klienta i zidentyfikowano typ obiektu
nazwany KLIENT

Przeglądając istniejące elementy danych
stwierdzamy, że wiele z nich (NIP, adres,
nazwa firmy, itp.) ma zastosowanie do
wszystkich egzemplarzy klienta

Dołączanie dodatkowych typów

obiektów

Jednakże są elementy danych, które występują dla części
egzemplarzy a nie występują dla innej

Na przykład KLIENT KRAJOWY i KLIENT ZAGRANICZNY,
dla których w firmie są inne procedury obsługi

W takiej sytuacji należy utworzyć podtypy

Dołączanie dodatkowych typów

obiektów

Może też zajść sytuacja odwrotna: elementy danych
mogą opisywać w ten sam sposób egzemplarze
dwóch (lub więcej) różnych typów obiektów

Jeśli tak się zdarzy należy utworzyć nowy nadtyp i
przypisać wspólne elementy danych do tego
nadtypu

Mogliśmy np. zidentyfikować KLIENTA
GOTÓWKOWEGO i KLIENTA Z KARTĄ KREDYTOWĄ
jako dwa różne typy obiektów, gdy po raz pierwszy
tworzyliśmy ERD dla systemu przyjmowania
zamówień (być może kierując się informacją od
użytkownika, że są to dwie różne kategorie)

Dołączanie dodatkowych typów

obiektów

Łatwo stwierdzić, że są takie elementy danych jak
nazwisko, adres itp., które opisują w ten sam sposób oba
te typy; sugerowałoby to utworzenie nadtypu, co ilustruje
rysunek

Dołączanie dodatkowych typów

obiektów

Jeżeli element danych opisuje interakcję między dwoma lub
więcej typami obiektów, należy zastąpić „czysty” związek
między dwoma obiektami asocjowanym typem obiektu

Popatrzmy na początkowy ERD pokazany na rysunku, na
którym występuje związek KUPUJE między KLIENTEM a
TOWAREM

Dołączanie dodatkowych typów

obiektów

Podczas przypisywania atrybutów może się okazać, że
istnieje element danych data_zakupu, który może
należeć do związku KUPUJE oraz jawnie opisuje, czyli
dostarcza dane o związku miedzy klientem i towarem

Sugeruje to, że należy zastąpić związek KUPUJE
asocjowanym typem obiektu, pokazanym na rysunku

Dołączanie dodatkowych typów

obiektów

Czasami początkowy diagram E-R będzie zawierał typ
obiektu, który przy dokładniejszej analizie okaże się
asocjowanym typem obiektu

Rysunek przedstawia diagram E-R z trzema powiązanymi
obiektami: KLIENTEM, ZAMÓWIENIEM i TOWAREM

Dołączanie dodatkowych typów

obiektów

Podczas przypisywania atrybutów różnym
obiektom stwierdziliśmy, że data_dostawy
najbardziej pasuje do obiektu ZAMÓWIENIE
(w końcu klienci nie są dostarczani, towary zaś są
dostarczane tylko w wyniku zamówienia)

Dalsze przemyślenia ujawniły, że samo
ZAMÓWIENIE to związek między KLIENTEM
i TOWAREM, jak też obiekt, o którym chcemy
zapamiętywać pewne fakty co prowadzi do
modyfikacji diagramu

Dołączanie dodatkowych typów

obiektów

Powtarzające się grupy

Rozważmy typ obiektu PRACOWNIK, z takimi
oczywistymi elementami danych jak nazwisko i
adres

Załóżmy, że znaleźliśmy dodatkowe elementy
danych nazwisko_dziecka, wiek_dziecka i
płeć_dziecka

Oczywiście można uważać, że te elementy
danych to sposób opisania nowego typu obiektu
DZIECKO, który przedtem zawarliśmy w obiekcie
PRACOWNIK

Powtarzające się grupy

Można także dostrzec, że istnieje wiele
egzemplarzy informacji dotyczącej dziecka
związanej z jednym egzemplarzem pracownika

Każdy taki egzemplarz informacji o dziecku jest
jednoznacznie identyfikowany
nazwiskiem_dziecka

Wobec tego typ obiektu początkowo pokazany
na rysunku A należy przekształcić na dwa typy
obiektów, połączone nowym związkiem jak
pokazano na rysunku B

Powtarzające się grupy

A

B

Powtarzające się grupy

Taki proces usuwania obiektów zagnieżdżonych
stanowi część szerszej czynności modyfikacji
zwanej normalizacją

Celem normalizacji jest otrzymanie typów
obiektów, w których każdy egzemplarz (lub
element) składa się z wartości klucza
pierwotnego, identyfikującej pewną encję, wraz
ze zbiorem wzajemnie niezależnych wartości
atrybutów, opisujących w jakiś sposób encję

Usuwanie typów obiektów

Często modyfikacja ERD polega na usunięciu
nadmiarowych lub błędnych typów obiektów i
związków.

Są cztery typowe sytuacje:

Typy obiektów składające się jedynie z
identyfikatora

Typy obiektów mające tylko jeden egzemplarz

Zawieszone asocjowane typy obiektów

Związki wyprowadzalne

Usuwanie typów obiektów

Jeśli mamy diagram E-R, na którym
pewien typ obiektu jako jedyny element
danych ma przypisany identyfikator,
możliwe jest wyeliminowanie tego typu
obiektu i przypisanie identyfikatora jako
elementu danych spokrewnionemu typowi
obiektu

Ilustruje to przykład fragmentu systemu
kadrowego

Usuwanie typów obiektów

Podczas przypisywania
atrybutów rozmaitym
obiektom stwierdziliśmy,
że jedyną informacją,
jaką o współmałżonku
przechowuje system
kadrowy, jest nazwisko
(tzn. identyfikator
odróżniający od siebie
poszczególnych
współmałżonków w
systemie)

Usuwanie typów obiektów

Oczywistą modyfikacją jest wówczas eliminacja
WSPÓŁMAŁŻONKA jako typu obiektu oraz dołączenie
nazwiska_współmałżonka jako elementu danych do
obiektu PRACOWNIK

Takie ulepszenie ma sens jedynie wtedy, gdy istnieje
wzajemnie jednoznaczna odpowiedniość między
egzemplarzami właśnie usuwanego obiektu i
egzemplarzami spokrewnionego obiektu

Podany przykład ma sens, ponieważ we
współczesnych społeczeństwach zakłada się, że
można mieć co najwyżej jednego współmałżonka

Usuwanie typów obiektów

Jeszcze większej redukcji
można dokonać wówczas,
gdy początkowy diagram
E-R zawiera obiekt, który
ma tylko identyfikator i
tylko jeden egzemplarz

Rozważmy początkowy
diagram E-R
przedstawiony na rysunku

Usuwanie typów obiektów

Na pierwszy rzut oka wydaje się rozsądne
pokazanie związku między pacjentami i lekami w
szpitalu

Przypuśćmy jednak, że jedyną informacją
zapisaną o leku jest jego nazwa (identyfikator)
oraz przypuśćmy, że szpital stosuje tylko jeden
typ leku (np. aspirynę)

Wówczas lek jest stałą i nie musi w ogóle
pojawiać się na diagramie

Oznacza to także, że system nie będzie miał
magazynu danych zwanego LEKI

Usuwanie typów obiektów

Z tego powodu mogą pojawić się zawieszone
asocjowane typy obiektów

Rozważmy wariant poprzedniego przykładu
szpitalnego, pokazany na rysunku

Usuwanie typów obiektów

Jeśli okaże się, że LEK ma jedynie identyfikator i
pojedynczy egzemplarz, wówczas będzie
usunięty

Doprowadzi to do diagramu

Usuwanie typów obiektów

Po modyfikacji TERAPIA jest wciąż
asocjowanym typem obiektu, mimo że jest
połączona tylko z jednym innym typem
obiektu

Taka sytuacja na ERD jest określona jako
zawieszony asocjowany typ obiektu i jest
całkowicie poprawna (choć nieco
niezwykła)

Usuwanie typów obiektów

Związki, które mogą być wyprowadzone lub
obliczone, należy usunąć z początkowego
diagramu

Jak wspominaliśmy, ERD powinien przedstawiać
wymagania dotyczące pamiętanych danych

Dlatego jeśli przedstawiony na kolejnym rysunku
związek odnowienia między KIEROWCĄ a
PRAWEM JAZDY może być wyprowadzony (na
podstawie daty urodzenia, czy w inny sposób
stosowany przez wydziały komunikacyjne),
wówczas należy go wyeliminować

Usuwanie typów obiektów

Prowadzi to do diagramu, na którym typy obiektów nie
są połączone

Jest to poprawne, ponieważ nie jest konieczne, aby
każdy typ obiektu był połączony z innym

Rozszerzenia słownika danych

Słownik danych należy rozszerzyć na potrzeby
notacji ERD

W zasadzie obiekty na ERD odpowiadają
magazynom na DFD

Oznacza to, że w definicji w słowniku danych,
KLIENT to zarówno definicja typu obiektu, jak i
egzemplarz magazynu KLIENCI:

KLIENCI = {KLIENT}
KLIENT =

@nazwisko_klienta+adres+numer_telefonu

Rozszerzenia słownika danych

Definicja KLIENTA obejmuje specyfikację pola
klucza, który jest elementem danych (lub
atrybutem) odróżniającym poszczególne
egzemplarze klienta. Znak „at” @ służy do
wskazania pól klucza

Inny sposób wskazania klucza to podkreślenie

KLIENT =

nazwisko_klienta+adres+numer_telefonu

Rozszerzenia słownika danych

Do słownika danych musimy również dołączyć
definicje wszystkich związków pokazanych na
ERD

Definicja związku powinna obejmować opis
znaczenia związku w kontekście aplikacji i
wskazywać obiekty tworzące związek

Mogą być określone odpowiednie ograniczenia
dolne i górne, aby wskazać, czy związek
jeden-do-jednego, jeden-do-wielu
czy też wiele-do-wielu

Rozszerzenia słownika danych

Związek kupuje, pokazany na rysunku można
zdefiniować w słowniku danych następująco:
kupuje = *

powiązanie klienta i jednego lub

więcej towarów

*

@id_klienta + {@id_towaru + zakupiona_ilość}

Podsumowanie

Dla każdego systemu z wieloma
magazynami (obiektami) i złożonymi
strukturami danych ERD stanowi
wartościowe narzędzie

Koncentruje się ono całkowicie na
związkach między danymi, pomijając
funkcje tworzące lub korzystające
z tych danych

Podsumowanie

Pytanie czy najpierw należy budować model DFD, a
dopiero potem ERD, czy też lepiej rozpocząć od
ERD?

Niektórzy pytają nawet, czy rzeczywiście należy
sporządzić oba modele, skoro zarówno DFD jak i
ERD dostarczają tak wiele interesującej informacji

Odpowiedź na pierwsze pytanie jest łatwa: nie ma
znaczenia, który model będzie zbudowany pierwszy

Zależnie od własnych preferencji, preferencji
użytkownika lub natury samego systemu (tzn. czy
jest on bogaty w funkcje czy w dane) jeden
z modeli wyda się na początek łatwiejszy

Niekiedy może okazać się, że oba modele będą
budowane jednocześnie

Diagramy sieci przejść

Diagramy sieci przejść

Przedstawiliśmy już narzędzia modelowania
uwypuklające funkcje realizowane przez system,
jak też pamiętane dane, które system musi
gromadzić

Obecnie omówimy trzeci rodzaj narzędzi
modelowania, diagram sieci przejść (STD -
State Transition Diagram), pokazujący
zachowania systemu w czasie

Diagramy sieci przejść

Do niedawna modele zachowania systemu w czasie
były istotne tylko dla specjalnej kategorii systemów
zwanych systemami czasu rzeczywistego

Przykładami takich systemów są:

systemy sterowania procesami

telefoniczne systemy przełączające

systemy szybkiego gromadzenia danych

wojskowe systemy nadzoru i sterowania

Diagramy sieci przejść

Wiele z nich to systemy bierne w tym
sensie, że nie sterują otaczającym
środowiskiem, lecz jedynie reagują na nie
i gromadzą o nim informacje

Do tej kategorii należy wiele systemów
szybkiego gromadzenia danych
(np. system gromadzenia danych
naukowych z satelity)

Diagramy sieci przejść

Inne systemy czasu rzeczywistego są bardziej
aktywne, mogą sterować niektórymi aspektami
otaczającego środowiska

Do tej kategorii należą systemy sterowania
procesami

Systemy tego rodzaju mają do czynienia
z bardzo szybkimi zewnętrznymi źródłami danych,
muszą udzielać odpowiedzi i dostarczać danych
wynikowych dostatecznie szybko dla zewnętrznego
środowiska

Ważną częścią ich specyfikacji jest określenie, co ma
kiedy nastąpić

Diagramy sieci przejść

Dla systemów handlowych zagadnienie to

w zasadzie nie było istotne

Dane mogą napływać z wielu różnych źródeł

z dość dużą szybkością, lecz ich przetwarzanie może

być zwykle odroczone, jeśli system zajmuje się

czymś innym

Obecnie jednak zaczynają się pojawiać wielkie,

złożone systemy handlowe, w których występują

aspekty czasu rzeczywistego

Jeśli system otrzymuje dane z tysięcy terminali, jak

też szybkie dane z innych systemów komputerowych

lub urządzeń do komunikacji satelitarnej, wówczas

pojawiają się te same problemy, co w klasycznym

systemie czasu rzeczywistego

Notacja diagramu sieci przejść

Typowy diagram sieci przejść pokazany jest na
rysunku

Przedstawia on zachowanie typowej
automatycznej sekretarki telefonicznej

Notacja diagramu sieci przejść

Podstawowymi składnikami są stany i
strzałki reprezentujące przejścia między
stanami

Istnieje wiele różnych notacji dla
diagramów sieci przejść, jedną z nich jest
pokazana na rysunku

Stany systemu

Każdy prostokąt reprezentuje stan, w
jakim może znajdować się system

New World Dictionary Webstera podaje
następującą definicję stanu:
Zbiór okoliczności lub cech
charakteryzujących osobę lub rzecz w
danej chwili; sposób lub forma istnienia;
warunek

Stany systemu

Przykłady typowych stanów systemu:

oczekiwanie, aby użytkownik wprowadził
hasło

podgrzewanie mieszaniny chemicznej

oczekiwanie na następne polecenie

przyspieszanie silnika

mieszanie składników

oczekiwanie na dane pomiarowe

napełnianie zbiornika

bezczynny

Stany systemu

Wiele z tych przykładów obejmuje czekanie

systemu na jakieś zdarzenie, nie opisuje zaś

żadnych działań

Dlatego dowolny obserwowalny stan systemu

odpowiada tylko okresom gdy
(1) czeka on na jakieś zdarzenie w otaczającym

środowisku lub
(2) czeka, aby obecną czynność otoczenia

(mieszanie, pranie, napełnianie, przyśpieszanie

itp.) zastąpiono inną

Stan przedstawia więc zachowanie systemu,

które jest obserwowalne i trwa przez jakiś

skończony odcinek czasu

Zmiany stanów

System, który miałby tylko jeden stan
byłby statyczny

Zwykle systemy informacyjne, które
modelujemy, mogą mieć dziesiątki różnych
stanów

W jaki sposób zmienia się stan systemu?

Jeśli system podlega regułom rządzącym
jego zachowaniem, tylko niektóre przejścia
między stanami będą sensowne i
dozwolone

Zmiany stanów

Dozwolone zmiany stanów
przedstawiamy na STD łącząc
odpowiednie pary stanów
strzałkami

Ilustruje to kolejny rysunek

System może przejść ze stanu 1
do stanu 2, oraz że gdy system
jest w stanie 2, może przejść do
stanu 3 lub z powrotem
do stanu 1

System nie może przejść
bezpośrednio ze stanu 1 do stanu
3, ale może przejść bezpośrednio
ze stanu 3 z powrotem do stanu 1

Stan 2 ma dwa następniki

Zmiany stanów

Na rysunku znajduje się wiele interesujących
informacji o zachowaniu systemu, ale nie ma na
nim pewnej, być może bardzo istotnej rzeczy:
jaki jest początkowy i końcowy stan systemu

Kolejny rysunek jest stabilnym modelem
systemu, który był zawsze aktywny i zawsze
pozostanie aktywny

Większość systemów ma wyróżnione stany
początkowe i końcowe; pokazane na rysunku

Zmiany stanów

Stan początkowy rysuje się z
reguły u góry diagramu, tym co
naprawdę wyróżnia stan 1 na
rysunku jako początkowy, jest
,,naga” strzałka, która nie jest
połączona z żadnym innym stanem

Podobnie stan końcowy jest często
rysowany u dołu diagramu, tym co
identyfikuje stan 5 jako końcowy,
jest brak strzałki wychodzącej ze
stanu 5

Zmiany stanów

Zdrowy rozsądek podpowiada, że system może
mieć tylko jeden stan początkowy, ale może
mieć wiele stanów końcowych

Stany końcowe wzajemnie wykluczają się, tzn.
tylko jeden z nich może wystąpić podczas
działania systemu

Kolejny rysunek zawiera przykład, w którym
możliwymi stanami końcowymi są stany 4 i 6

Zmiany stanów

Zmiany stanów

Ponieważ używamy STD do budowy
modelu podstawowego, zakładamy, że
zmiany stanów zachodzą natychmiast, tzn.
nie jest potrzebny żaden obserwowalny
czas, aby system przeszedł z jednego
stanu do innego

Warunki i akcje

Aby diagram sieci przejść był
kompletny, należy dodać
jeszcze dwa składniki:

warunki, powodujące zmianę
stanu, oraz

akcje, które wykonuje system
zmieniając stan

Warunki i akcje zaznacza się
obok strzałki łączącej dwa
sąsiednie stany

STAN 1

STAN 2

Warunek

Akcja

Warunki i akcje

Warunek to pewne zdarzenie w otaczającym
środowisku, które system może wykryć

Zwykle będzie to sygnał, nadejście pakietu
danych itp.

Powoduje to zwykle przejście systemu ze stanu
oczekiwania na X do nowego stanu oczekiwania
na Y lub z wykonywania akcji X do wykonywania
akcji Y

Warunki i akcje

Podczas zmiany stanu system zwykle wykonuje
jedną lub więcej akcji:

produkuje wyniki

wyświetla komunikat na terminalu użytkownika

wykonuje obliczenie itd.

Akcje pokazane na STD są więc odpowiedziami,
wysłanymi z powrotem do środowiska, lub
obliczeniami, których wyniki są zapamiętywane
przez system (zwykle w magazynie danych
pokazanym na diagramie przepływu), aby w
razie potrzeby zareagować na jakieś przyszłe
zdarzenie

Diagramy podzielone

W złożonym systemie mogą występować
dziesiątki różnych stanów; pokazanie ich na
pojedynczym diagramie byłoby trudne, a może
nawet niemożliwe

Podobnie jak równoważyliśmy (dzieliliśmy)
diagramy przepływu danych, można również
dokonywać podziału STD

Kolejny rysunek zawiera przykład dwóch
poziomów diagramu sieci przejść dla złożonego
systemu

Diagramy podzielone

Wg Współczesna analiza
strukturalna
E. Yourdon
WNT, Warszawa 1996

Diagramy podzielone

Każdy pojedynczy stan na diagramie wyższego

poziomu może być stanem początkowym na

diagramie niższego poziomu, dokładniej

opisującym ten stan

Stany końcowe na diagramie niższego poziomu

odpowiadają warunkom wyjścia

z odpowiedniego stanu wyższego poziomu

W innych przypadkach analityk może jawnie

pokazać, w jaki sposób następuje wyjście z

diagramu STD niższego poziomu do

odpowiedniego miejsca na diagramie wyższego

poziomu

Diagramy podzielone

Przykładem
wymagającym
podzielonego
diagramu sieci przejść
może być bankomat

STD dla tej aplikacji
pokazano na rysunku

Budowa diagramu sieci przejść

Istnieją dwa podejścia:

Można rozpocząć od zidentyfikowania
wszystkich możliwych stanów systemu,
reprezentując każdy z nich na rysunku
oddzielnym prostokątem. Następnie można
badać wszystkie sensowne połączenia (czyli
zmiany stanów) między prostokątami.

Można też rozpocząć od stanu początkowego,
potem metodycznie przechodzić do
następnych stanów, a z nich do kolejnych itd.

Budowa diagramu sieci przejść

Wybór podejścia może być określony przez
użytkownika, zwłaszcza gdy jest on jedyną
osobą dobrze znającą zachowanie systemu

Do wykonania akcji system może potrzebować
dodatkowych wejść ze środowiska zewnętrznego

Można więc stwierdzić, że każdy warunek
odpowiada zdarzeniu zewnętrznemu, na które
system musi zareagować, zdarzenia te zaś będą
zwykle dostrzeżone przez system dzięki
nadejściu wchodzącego przepływu danych

Budowa diagramu sieci przejść

Po zakończeniu budowy wstępnego STD należy
sprawdzić następujące warunki:

Czy zdefiniowano wszystkie stany? Przyjrzyj się
dokładnie systemowi, aby stwierdzić, czy istnieje jakieś
obserwowalne zachowanie lub inny stan, w jakim może
znajdować się system, poza zidentyfikowanymi

Czy wszystkie stany są osiągalne? Czy nie zdefiniowałeś
stanów, do których nie prowadzą żadne drogi?

Czy istnieją wyjścia ze wszystkich stanów? Jak
wspomnieliśmy, system może mieć jeden lub więcej
stanów końcowych z kilkoma wejściami do nich;
wszystkie inne stany powinny mieć następniki

Budowa diagramu sieci przejść

Czy w każdym stanie system odpowiada poprawnie na
wszystkie warunki?

Jest to najczęstszy błąd przy budowie diagramu sieci
przejść

Analityk identyfikuje zmiany stanów w warunkach
normalnych, lecz zapomina określić zachowanie systemu
dla nieoczekiwanych zdarzeń

Załóżmy, że analityk wymodelował zachowanie systemu
w sposób pokazany na kolejnym rysunku

Oczekuje on, że użytkownik naciśnie pewien klawisz
funkcyjny na swoim terminalu, aby spowodować
przejście ze stanu 1 do stanu 2 oraz inny klawisz
funkcyjny, aby przejść ze stanu 2 do stanu 3

Budowa diagramu sieci przejść

Co stanie się, jeśli użytkownik
naciśnie ten sam klawisz
funkcyjny dwa razy z rzędu?
Albo inny klawisz? Jeśli
zachowanie systemu nie jest
określone, istnieje duża
szansa, że projektanci i
programiści również nie
zaprogramują tego i system
będzie się w rozmaitych
okolicznościach zachowywał w
sposób nieprzewidziany

Związek z innymi składowymi

modelu

Diagram sieci przejść jest narzędziem
modelowania, które może być używane
samodzielnie

Może jednak też, i zwykle powinien, być
używany w powiązaniu z innymi narzędziami

Najczęściej diagram sieci przejść reprezentuje
specyfikację procesu dla procesu sterującego na
diagramie przepływu danych

Ilustruje to kolejny rysunek

Związek z innymi składowymi

modelu

Warunki na STD odpowiadają wejściowym przepływom

sterującym na DFD, a akcje na STD wyjściowym

przepływom sterującym na DFD

Jako narzędzie modelowania wysokiego poziomu, diagram

sieci przejść może pełnić rolę specyfikacji procesu dla

całego systemu

Podsumowanie

Diagram sieci przejść to mocne narzędzie
modelowania do opisu wymaganego
zachowania systemów czasu
rzeczywistego, jak też części interfejsu
użytkowego wielu systemów
interakcyjnych

Równoważenie modeli

Równoważenie modeli

Najważniejsze narzędzia modelowania w
analizie strukturalnej:

diagram przepływu danych

słownik danych

specyfikacja procesu

diagram związków encji

diagram sieci przejść

Równoważenie modeli

Każde z tych narzędzi koncentruje się na jednym
krytycznym aspekcie modelowanego systemu

Oznacza to, że osoba oglądająca model także
koncentruje się na jednym aspekcie, tzn. na
tym, na które narzędzie modelowania ma
zwrócić jej uwagę

Ponieważ rzeczywisty system może mieć wiele
kierunków złożoności, chcemy, aby diagram
przepływu danych skupił uwagę czytelnika na
funkcjach systemu, a nie na związkach między
danymi

Równoważenie modeli

Diagram związków encji ma uwypuklać
związki między danymi bez zajmowania się
funkcjonalną charakterystyką systemu

Diagram sieci przejść zaś służy do
skupienia uwagi na zagadnieniach
synchronizacji systemu, bez rozważania
funkcji lub danych

Równoważenie modeli

Przychodzi jednak czas połączenia
wszystkich narzędzi modelowania

Sytuacja modelującego system
przypomina starą indyjską bajkę o trzech
ślepych mędrcach, którzy natknęli się na
słonia

Po dotknięciu różnych części jego ciała
doszli do zupełnie innych wniosków o
,,rzeczywistości”, z którą mają do
czynienia

Równoważenie modeli

Równoważenie modeli

Pierwszy ze ślepców dotknął ostrego końca
jednego z długich kłów. "Aha powiedział - to jest
byk. Czuję jego rogi"

Drugi dotknął szczeciniastej skóry zwierzęcia.
"Bez wątpienia – powiedział - jest to ... co?
Jeżozwierz? Tak, na pewno jeżozwierz"

Trzeci dotknął jednej z grubych nóg słonia i
oświadczył "To z czym mamy do czynienia jest
na pewno drzewem"

Równoważenie modeli

Podobnie modelując trzy różne aspekty systemu
(funkcje, dane i synchronizację), jak też
szczegółową charakterystykę systemu w słowniku
danych i w zbiorze specyfikacji procesów, łatwo
sporządzić kilka sprzecznych interpretacji tej samej
rzeczywistości

Jest to szczególnie niebezpieczne w dużych
projektach, gdy w pracach biorą udział różne osoby i
grupy o różnych zainteresowaniach

Niebezpieczeństwo istnieje też wówczas, gdy zespół
projektowy obejmuje osoby o bardzo różnym
przygotowaniu

Równoważenie modeli

Jest jeszcze jedna przyczyna zajmowania się
spójnością modelu: istniejące błędy zostaną w
końcu wykryte, lecz staje się to znacznie
trudniejsze i bardziej kosztowne w późniejszych
fazach projektu

Błędy wprowadzone podczas analizy systemowej
do modelu wymagań zwykle rozrastają się w
fazie projektowania i implementacji

Jest to poważne niebezpieczeństwo zwłaszcza w
wielkich systemach, w których analizy dokonują
inne osoby niż projektowania i implementacji

Równoważenie modeli

50% błędów wykrywanych w systemie i 75%
kosztów ich usuwania jest związane z błędami
popełnionymi podczas fazy analizy systemu

Koszt poprawiania błędów rośnie wykładniczo w
późniejszych etapach projektu; jest dziesięć razy
taniej poprawić błąd podczas analizy systemu w
fazie analizy niż poprawiać ten sam błąd w fazie
projektowania

Równoważenie modeli

Niektóre z błędów to oczywiście proste błędy
w pojedynczym modelu (np. diagram przepływu
danych z nieskończoną studnią)

Niektóre z nich można określić jako błędną
interpretację prawdziwych oczekiwań użytkownika

Jednak wiele z trudniejszych i bardziej zdradliwych
błędów to błędy między modelami, tzn. niezgodności
jednego modelu z innym

Specyfikację strukturalną, w której sprawdzono
niesprzeczność wszystkich narzędzi modelowania z
innymi, nazywamy zrównoważoną

Równoważenie modeli

Najczęstszy błąd zrównoważenia to brakująca
definicja

Coś zdefiniowanego (lub opisanego) w jednym
modelu nie jest odpowiednio zdefiniowane w
innym

Np. magazyn danych pokazany na DFD, lecz nie
zdefiniowany w słowniku danych, lub obiekt na
ERD, nie mający odpowiadającego magazynu
danych na DFD)

Drugi częsty typ błędu to niespójność: ta sama
,,rzeczywistość" jest opisana różnymi, wzajemnie
sprzecznymi sposobami w różnych modelach

Równoważenie modeli

Równoważenie dotyczy:

diagramu przepływu danych ze słownikiem
danych

diagramu przepływu danych ze specyfikacją
procesu

specyfikacji procesu ze słownikiem danych

ERD z DFD i specyfikacjami procesów

ERD ze słownikiem danych

DFD z diagramem sieci przejść

Równoważenie DFD ze słownikiem

danych

Reguły równoważenia diagramu przepływu
danych ze słownikiem danych są
następujące:

Każdy przepływ danych (tzn. strzałka na DFD)
i każdy magazyn danych musi być
zdefiniowany w słowniku danych. Jeśli brak go
w słowniku danych, przepływ danych lub
magazyn danych uznaje się za
niezdefiniowany

Równoważenie DFD ze słownikiem

danych

Odwrotnie, każdy element danych i każdy magazyn
danych zdefiniowany w słowniku danych musi
wystąpić gdzieś na DFD

Jeśli nie występuje, wadliwy element danych lub
magazyn danych jest "duchem" - czymś
zdefiniowanym lecz nie "używanym" w systemie

Może się tak zdarzyć, gdy zdefiniowane elementy
danych odpowiadają wcześniejszej wersji DFD

Niebezpieczeństwo polega na dokonanej zmianie DFD
(np. mógł zostać usunięty przepływ danych lub
magazyn danych) bez odpowiadającej jej zmiany w
słowniku danych

Równoważenie DFD ze słownikiem

danych

Oznacza to, oczywiście, że analityk systemów
musi wnikliwie przejrzeć zarówno DFD, jak i
słownik danych, aby upewnić się, że są
zrównoważone ze sobą

Nie ma znaczenia, który model bada się
najpierw, lecz większość analityków rozpoczyna
od sprawdzenia, czy wszystkie elementy DFD są
zdefiniowane w słowniku danych

Równoważenie DFD ze specyfikacją

procesu

Reguły równoważenia DFD ze specyfikacjami
procesów:

Dla każdego procesu na DFD musi istnieć DFD
niższego poziomu albo specyfikacja procesu, lecz nie
obie te rzeczy. Jeśli DFD zawiera proces oznaczony
1.4.2, musi albo istnieć diagram oznaczony Diagram
1.4.2 z procesami 1.4.2.1, 1.4.2.2 itd., albo
specyfikacja strukturalna musi zawierać specyfikację
procesu 1.4.2. Jeśli istnieją obie te rzeczy, model jest
niepotrzebnie (i niebezpiecznie) nadmiarowy

Równoważenie DFD ze specyfikacją

procesu

Z każdą specyfikacją procesu musi być związany
proces najniższego poziomu na DFD

Ponieważ specyfikacje procesów wymagają wiele
pracy, wydaje się mało realne, aby w modelu
znajdowały się "bezdomne" specyfikacje
procesów

Tak jednak może się zdarzyć wówczas, gdy
specyfikacja procesu była napisana dla wstępnej
wersji DFD, a podczas jego ulepszania
wyeliminowano niektóre procesy z DFD

Równoważenie DFD ze specyfikacją

procesu

Wejścia i wyjścia muszą pasować

DFD pokazuje wchodzące i wychodzące
przepływy dla każdego procesu, jak też
połączenia z magazynami

Powinno to być widoczne także w specyfikacji
procesu. Oczekujemy więc zdań CZYTAJ (WEŹ,
POBIERZ lub innych podobnych czasowników)
odpowiadających każdemu wchodzącemu
przepływowi oraz ZAPISZ (lub WŁÓŻ,
WYŚWIETL itp.) dla każdego wychodzącego
przepływu

Równoważenie specyfikacji procesów

z DFD i słownikiem danych

Reguły równoważenia specyfikacji
procesów z diagramem przepływu danych
i słownikiem danych można opisać
następująco:

Każde odwołanie do danych w specyfikacji
procesu musi spełniać jedną z
następujących reguł:

Równoważenie specyfikacji procesów

z DFD i słownikiem danych

pasuje do nazwy przepływu lub magazynu
danych połączonego z procesem
opisywanym specyfikacją, lub

jest terminem lokalnym, jawnie
zdefiniowanym w specyfikacji procesu, lub

występuje jako składnik w pozycji
słownika danych dla przepływu lub
magazynu danych połączonego z
procesem

Przykład

Fragment specyfikacji procesu

SPECYFIKACJA PROCESU 3.5:
OBLICZ WSPÓŁCZYNNIK G
*P i Q SĄ LOKALNYMI TERMINAMI NA WYNIKI POŚREDNIE*
P = 3.14156 * X

……

Q = 2.78128 * Y -13

……

WSPÓŁCZYNNIK-G = P * Q + 2

OBLICZ

WSPÓŁCZYNNIK

G

Z

Współczynnik G

Równoważenie specyfikacji procesów

z DFD i słownikiem danych

Elementy danych X i Y pojawiają się w
specyfikacji procesu pokazanej na poprzednim
slajdzie, ale nie występują jako dołączony
przepływ na DFD przedstawionym na rysunku

Jednak słownik danych, którego fragment
ilustruje kolejny slajd, wskazuje, że X i Y są
składnikami Z, a na rysunku widzimy, że Z jest
rzeczywiście przepływem danych połączonym z
procesem, możemy więc stwierdzić, że model
jest zrównoważony

Równoważenie specyfikacji procesów

z DFD i słownikiem danych

Fragment słownika danych

X = * poziomy składnik czynnika frammis *

* jednostki: centymetry; zakres: 0 - 100 *

Y = * pionowy składnik czynnika frammis *

* jednostki: centymetry; zakres: 0 - 10 *

Z = * czynnik frammis, zdefiniowany przez

Dr. Frammisa * X + Y

Równoważenie słownika danych

z DFD i specyfikacjami procesów

Słownik danych jest spójny z resztą modelu, jeśli
spełnia następującą regułę:

Do każdej pozycji ze słownika danych musi istnieć
odwołanie ze specyfikacji procesu, DFD lub innej
pozycji słownika danych

Można wprawdzie argumentować, że słownik
danych powinien być budowany w taki sposób,
aby umożliwiał późniejsze rozszerzenia, tzn.
zawierał elementy zbędne obecnie, lecz które
mogą być przydatne w przyszłości

Równoważenie ERD z DFD

i specyfikacjami procesów

Diagram związków encji prezentuje
całkiem inny punkt widzenia systemu niż
diagram przepływu danych

Występują jednak pewne związki, które
muszą być zachowane, aby ogólny model
systemu był kompletny, poprawny i spójny

Równoważenie ERD z DFD

i specyfikacjami procesów

Każdemu magazynowi na DFD musi odpowiadać
na ERD typ obiektu, związek lub ich kombinacja
(tzn. asocjowany typ obiektu)

Jeśli na DFD występuje magazyn, który nie
pojawia się na ERD, to coś jest źle; podobnie,
jeśli obiekt lub związek z ERD nie występuje na
DFD

Nazwy obiektów na ERD i nazwy magazynów
danych na DFD muszą do siebie pasować

Równoważenie ERD z DFD

i specyfikacjami procesów

Pozycje słownika danych muszą mieć

zastosowanie zarówno do modelu DFD, jak i

ERD

Dlatego pozycja słownika danych powinna

obejmować definicję obiektu na ERD i magazynu

na DFD

Oznacza to definicję słownikową następującej

postaci:

KLIENCI = {KLIENT}
KLIENT = nazwisko + adres + numer-telefonu +

...

Równoważenie ERD z DFD

i specyfikacjami procesów

Pozycje słownika danych w liczbie pojedynczej
(np. KLIENT) muszą opisywać znaczenie i
budowę pojedynczego egzemplarza ze zbioru
obiektów używanego (w liczbie pojedynczej) na
ERD i magazynu danych (w liczbie mnogiej) na
DFD

Pozycje słownika w liczbie mnogiej (np.
KLIENCI) opisują znaczenie i budowę zbioru
egzemplarzy

Równoważenie ERD z DFD

i specyfikacjami procesów

Istnieją również reguły gwarantujące, że ERD
jest spójny ze specyfikacjami procesów z modelu
funkcyjnego

Zbiór specyfikacji jako całość powinien spełniać
następujące wymagania:

Tworzyć i usuwać egzemplarze każdego typu
obiektu i związku, pokazanego na ERD

Ilustracja na DFD z kolejnego rysunku

Równoważenie ERD z DFD

i specyfikacjami procesów

Równoważenie ERD z DFD

i specyfikacjami procesów

Magazyn KLIENCI odpowiada obiektowi KLIENT

Coś musi tworzyć i usuwać egzemplarze klienta, czyli
pewien proces na DFD musi mieć przepływ
dołączony do magazynu KLIENCI

Jednak aktualna czynność zapisu do magazynu (tzn.
tworzenia lub usuwania egzemplarza
odpowiadającego na ERD obiektowi KLIENT) musi
dokonywać się wewnątrz procesu, co oznacza, że
powinna być udokumentowana w specyfikacji tego
procesu

Równoważenie ERD z DFD

i specyfikacjami procesów

Jakiś proces powinien nadawać wartości
każdemu elementowi danych, będącemu
atrybutem egzemplarza każdego typu
obiektu, a jakiś proces powinien używać
(lub odczytywać) wartości każdego
elementu danych

Równoważenie DFD z diagramem

sieci przejść

Diagram stanów jest zrównoważony z
diagramem przepływu danych, jeśli są
spełnione następujące warunki:

Każdy proces sterujący na DFD ma jako
specyfikację diagram sieci przejść. Podobnie
każdy diagram sieci przejść w ogólnym
modelu systemu musi być powiązany z
procesem sterującym na DFD

Równoważenie DFD z diagramem

sieci przejść

Każdy warunek na diagramie sieci przejść
musi odpowiadać wchodzącemu
przepływowi sterującemu procesu
kontrolnego związanego z tym
diagramem. Podobnie każdemu
wchodzącemu przepływowi sterującemu
do procesu sterującego musi odpowiadać
określony warunek na właściwym
diagramie sieci przejść

Równoważenie DFD z diagramem

sieci przejść

Każdej akcji z diagramu sieci przejść musi
odpowiadać wychodzący przepływ
sterujący z procesu sterującego
związanego z tym diagramem. Podobnie
każdy wychodzący z procesu kontrolnego
przepływ sterujący musi być związany z
odpowiednią akcją na diagramie sieci
przejść

Równoważenie DFD z diagramem

sieci przejść

Ilustruje to rysunek