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