METODY MODELOWANIA
PROCESÓW
Elementy analizy
cz. II
systemowej
Analiza systemowa Analiza systemowa
Analiza systemowa to sztuka dochodzenia do
Aspekty to umowne uproszczenia otaczającej
zrozumienia systemu za pomocą tworzenia modeli
nas rzeczywistości
Dzisiejsze systemy są duże i złożone
Stosując aspekty analitycy mogą budować
Chociaż jest wymagana dokładność
modele zawierające tylko tyle informacji, ile ich
w modelowaniu, trzeba unikać olbrzymich
w danej chwili potrzebują
i skomplikowanych modeli, nawet jeżeli
Nie oznacza to, że modele są fałszywym
reprezentują duże systemy
odzwierciedleniem systemu
Sposobem na uporanie się z problemem wielkości i
To oznacza większą przydatność modeli,
złożoności systemów jest stosowanie aspektów
ponieważ jest na nich pokazane tylko to, czego
w danej chwili potrzebuje analityk
Analiza systemowa
Analiza systemowa
filtrowanie informacji
W miarę rozrastania się systemów
Wyzwaniem dla dzisiejszej analizy
i rozszerzania na większe obszary biznesu
systemowej jest tworzenie złożonych
wzrasta liczba użytkowników znających
systemów spełniających oczekiwania
jedynie część systemu
użytkowników
Zwiększenie liczby użytkowników oznacza,
Pomocą może okazać się mechanizm
że analitycy stają naprzeciw:
filtrowania, jako obrona przed zalewem
większego zróżnicowania podejść
informacji
większego zróżnicowania umiejętności
szerszych zainteresowań
Analiza systemowa Analiza systemowa
Aby sprostać kontaktom ze wzrastającą liczbą
użytkowników, analitycy tworzą modele systemu,
Aspekty, które są najistotniejsze, to:
ukazujące aspekty cieszące się największym
aspekt fizyczny istniejącego systemu
zainteresowaniem lub najbardziej istotne dla
każdej grupy użytkowników
aspekt istotny
Analitycy muszą także eliminować to, co
aspekt danych
w danym momencie nie jest potrzebne
aspekt fizyczny nowego systemu
Analizując duży system muszą upraszczać
rzeczywistość modelując te aspekty, które najlepiej
przyczynią się do zrozumienia systemu
Aspekt fizyczny istniejącego
Aspekt istotny
systemu
Jest uważany za  idealny obraz systemu;
Aspekt fizyczny istniejącego systemu stosujemy
pokazuje jedynie wymagania i celowo pomija
na początku projektu, by określić kontekst
wszystko, co wynika ze sposobu
badanego systemu i dać użytkownikom czytelny
zaprojektowania i zaimplementowania systemu
model
Odfiltrowanie aktualnej technologii systemu jest
Początkowo użytkownicy wolą zobaczyć modele
celowe wówczas, gdy wybiera się rozwiązanie
przedstawiające ludzi i maszyny aktualnie
najlepsze z możliwych
działające
Aspekt istotny jest potrzebny w każdym
Model fizyczny pomaga analitykom projekcie, jako najbardziej użyteczny, a zarazem
najczęściej używany aspekt modelowania
w zidentyfikowaniu:
obszarów problemowych
z
ródeł informacji o systemie
oraz w szacowaniu działania przyszłego systemu
Aspekt fizyczny nowego systemu
Aspekt danych
Aspektu fizycznego nowego systemu
Koncentruje się na informacjach
używamy do ilustrowania, negocjowania i
występujących w systemie
definiowania implementacji nowego
Aspekt ten, reprezentowany przez model systemu z wykorzystaniem komputerów,
danych, ignoruje sposób przetwarzania w ludzi i maszyn
systemie
Aspekt ten jest również znany jako model
implementacyjny lub wstępny model
projektu
Stosowanie aspektów Stosowanie aspektów
Użyteczność każdego z tych czterech aspektów
Informacje niezbędne dla każdego aspektu
zależy od odbiorców oraz od sytuacji
oraz użytkownicy, od których pochodzą
Niestety rzeczywistość nie jest na tyle prosta,
informacje, pojawiają się w
aby analitykom mogło udać się:
przypadkowych chwilach
zbudowanie pełnego modelu danego aspektu
Analityk w projekcie nie może spodziewać
sprawdzenie poprawności modelu
się, że uzyska wszystkie informacje
a następnie przejście do następnego aspektu
wówczas, gdy ich potrzebuje
Stosowanie aspektów
Analityk musi być przygotowany na
zdobywanie informacji różnymi sposobami
Ogólne metody analizy
Najczęściej jest kilka modeli wykonywanych
dla różnych aspektów, w różnym stopniu
systemowej
zaawansowania
Nie można jednak porzucić pracy
analitycznej; modele, chociaż niekompletne,
pomagają określać wymagania systemu
Analiza systemowa Analiza systemowa
Pełna analiza systemowa problemu obejmuje
Analiza systemowa jest formalnym następujące cztery czynności:
i jawnym badaniem wspomagającym działanie
Zbadanie celów rozważanej akcji czy linii
postępowania
osób odpowiedzialnych za decyzje lub linię
postępowania w określonej sytuacji Zbadanie możliwych sposobów osiągnięcia tych
celów, z uwzględnieniem propozycji i projektów
charakteryzującej się niepewnością
nowych rozwiązań
Ma ona na celu określenie pożądanego działania
Ocenę pozytywnych i negatywnych skutków każdego
lub linii postępowania przez rozpoznanie i
z możliwych wariantów postępowania, uwzględniającą
rozważenie dostępnych wariantów oraz
niepewność przyszłości
porównanie ich przewidywanych następstw
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 Ogólne metody analizy
systemowej systemowej
Podczas analizy ustala się potrzeby
Analiza jest studium dziedziny problemu
prowadzącym do specyfikacji obserwowalnego systemu - tzn. co system ma robić, aby
zachowania systemu zaspokoić wymagania użytkownika
W wyniku analizy otrzymujemy kompletne, spójne
Nie powinna ona natomiast zawierać
i prawdopodobne wyspecyfikowanie potrzeb,
szczegółów implementacyjnych tzn. jak
z podaniem zarówno ilościowych, jak
system ma realizować te zadania
i funkcjonalnych charakterystyk operacyjnych
Dokumentem, który jest wynikiem analizy,
(niezawodności, dostępności, wydajności)
jest dokument zawierający wymagania
systemu
Ogólne metody analizy Ogólne metody analizy
systemowej systemowej
Na wymagania systemu składają się:
W praktyce analizy systemowej
funkcje - charakterystyki operacyjne,
wykształciły się następujące metody
interfejsy (z którymi ma współpracować
analizy i projektowania:
oprogramowanie)
rozkład funkcjonalny
ograniczenia projektowe
metoda przepływu danych
Dokument formułujący wymagania ma
modelowanie informacji (danych)
następujące cele:
podejście obiektowe
formalizuje potrzeby użytkownika
ustala listę zadań
Rozkład funkcjonalny
Rozkład funkcjonalny
Rozkłady na funkcje i podfunkcje są trudne
Rozkład funkcjonalny wymaga w konstrukcji i bardzo nietrwałe
odwzorowania dziedziny problemu na
Jako wynik otrzymuje się następujące
funkcje i podfunkcje, które ma zapewniać poziomy:
system systemu
podsystemu
W tym sensie, wymagania systemu muszą
funkcji
być odwzorowane na funkcje, które
podfunkcji
wykonują to co powinien system robić
Model funkcjonalny - metoda Model funkcjonalny - metoda
przepływu danych przepływu danych
Przepływ danych można przedstawić jako zestaw
Metodą odwzorowania dziedziny problemu
elementów:
na opis systemu jest przepływ danych
przepływ danych i przepływy sterujące
(Data Flow Diagram), często nazywany
przekształcenia danych (inaczej zwane
analizą strukturalną
procesami)
W analizie strukturalnej wykorzystuje się
magazyny danych
metodykę opracowaną przez Yourdona
obiekty zewnętrzne (inaczej - terminatory)
opisy procesu
słownik danych
Modelowanie informacji (danych) Modelowanie informacji (danych)
Kolejność postępowania w modelowaniu danych
Podstawowym narzędziem modelowania jest następująca:
znalezienie obiektów w rzeczywistym świecie (lista
danych jest diagram powiązań danych
obiektów)
(Entity Relationship Diagram)
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
Droga do analizy strukturalnej
Aż do końca lat siedemdziesiątych
olbrzymia większość projektów budowy
Analiza
systemu rozpoczynała się od stworzenia
 powieściowego określenia wymagań
i projektowanie
użytkownika
strukturalne
Analityk dokumentował swoje zrozumienie
potrzeb w masywnym dokumencie,
głównie w postaci narracyjnej, często
nazywanym specyfikacją funkcjonalną
Droga do analizy strukturalnej Droga do analizy strukturalnej
Takie dokumenty miały szereg wad:
Takie dokumenty miały szereg wad (cd.):
Były monolityczne. Aby je zrozumieć
Były wieloznaczne. Szczegółowe określenie
należało przeczytać je od początku do końca
wymagań użytkownika mogło i często było,
Były nadmiarowe. Ta sama informacja była
inaczej interpretowane przez użytkownika,
często powtarzana w dokumencie w kilku
analityka, projektanta i programistę
miejscach. Problemy polegały na tym, że gdy
Ich konserwacja była niemożliwa.
jakiś aspekt wymagań użytkownika uległ
Z opisanych powodów, specyfikacja funkcjonalna
zmianie podczas fazy analizy, to zmiana
była niemal zawsze przestarzała w chwili
musiała być uwzględniona w kilku różnych
częściach dokumentu zakończenia budowy systemu, tzn. w momencie
jego wdrożenia
Wprowadzenie Wprowadzenie
Większość systemów wymaga wielu modeli
Model buduje się z trzech powodów:
Każdy model koncentruje się na ograniczonej
aby skoncentrować się na ważnych cechach
liczbie aspektów systemu, ograniczając (lub wręcz
systemu, pomijając mniej istotne
pomijając) pozostałe
aby móc niewielkim kosztem i minimalnym
ryzykiem wprowadzać zmiany i poprawki do
Jest to prawda zwłaszcza dla wielu systemów
wymagań użytkownika
budowanych obecnie, ponieważ mają złożoną
aby sprawdzić, czy rozumiemy środowisko
charakterystykę funkcjonalną, złożone struktury
użytkownika i udokumentować to w taki
danych oraz złożone zależności czasowe
sposób, aby projektanci i programiści mogli
zbudować system
Wymagania dla narzędzi Wymagania dla narzędzi
modelowania modelowania
Narzędzia modelowania powinny umożliwiać
Narzędzia modelowania powinny być
oglądanie systemu od góry, ze schodzeniem
graficzne, z tekstowym wspomaganiem
według określonych podziałów
odpowiednich szczegółów
Narzędzia modelowania muszą umożliwiać
W zasadzie grafiki używa się do określenia
osobne odwzorowanie poszczególnych części
składników systemu i interfejsów między nimi;
systemu, wraz z prostym sposobem
przechodzenia od jednej części modelu do
wszystkie szczegóły umieszcza się
innej
w pomocniczych dokumentach tekstowych
Przykładem mogą być mapy, pokazujące kraj
(np. specyfikacja procesu i słownik danych)
na różnych poziomach szczegółowości
Wymagania dla narzędzi Wymagania dla narzędzi
modelowania modelowania
Narzędzia modelowania powinny mieć minimalną
Narzędzia modelowania powinny:
nadmiarowość
Modele stanowią reprezentację pewnego systemu z
Pomagać przewidzieć zachowanie się
rzeczywistego świata, przy czym sam system może
systemu
być statyczny lub dynamiczny
Być przejrzyste
Jeśli system zmienia się, zmianie musi także ulec
model, aby pozostać aktualnym
Dobry model powinien być przejrzysty,
Oczywiście jeżeli zmienia się tylko jeden lokalny
aby czytelnik uświadamiał sobie, że
aspekt systemu, wolelibyśmy dokonać tylko jednej
lokalnej zmiany w odpowiadającym aspekcie modelu,
ogląda reprezentację systemu, a nie zaś
niż być zmuszonym do zmiany wielu innych aspektów
sam system
Diagramy przepływu danych (DFD)
DFD to tylko jedno z narzędzi modelowania
używanych przez analityka i dostarcza ono tylko
Diagramy przepływu
jednego spojrzenia na system  spojrzenia
funkcyjnego
danych
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 Składniki DFD
Jeżeli natomiast charakterystyka czasowa Diagramy przepływu danych buduje się z
zachowania systemu dominuje nad czterech podstawowych elementów:
wszystkimi innymi zagadnieniami, możemy
Proces
skupić się na diagramie sieci przejść
Przepływ
Magazyn
Terminator
Składniki DFD  proces Składniki DFD  proces
Graficznie proces reprezentuje się
Pierwszy składnik DFD nazywa się
okręgiem
procesem
Niektórzy analitycy wolą elipsę lub
Popularne synonimy to: bąbel, funkcja lub
prostokąt z zaokrąglonymi rogami, jeszcze
transformacja
inni prostokąt
Proces pokazuje pewien fragment systemu
Różnice są czysto kosmetyczne, choć
przekształcający dane na wyniki, tzn.
oczywiście należy używać takiego samego
sposób w jaki dane zmieniają się w pewne
kształtu do reprezentowania wszystkich
wyniki
funkcji systemu
Składniki DFD  proces Składniki DFD  przepływ
Przepływ reprezentuje się graficznie strzałką do
Proces jest nazywany pojedynczym
lub z procesu
słowem, frazą lub prostym zdaniem
Służy on do opisania przenoszenia jednostek lub
Nazwa procesu powinna opisywać co robi
pakietów informacji z jednego fragmentu
proces
systemu do innego
Przedstawia więc dane w ruchu, podczas gdy
magazyny reprezentują dane w spoczynku
Składniki DFD  przepływ Składniki DFD  przepływ
Przepływy również są nazywane
Dla większości systemów przepływy będą
reprezentować dane, tzn. bity, znaki, Nazwa reprezentuje znaczenie pakietu
poruszającego się wzdłuż przepływu
komunikaty itp.
Przepływ przenosi tylko jeden rodzaj
DFD mogą jednak również służyć do
pakietów, wskazywany jego nazwą
modelowania innych systemów, np. taśmy
Czasami dopuszczalne jest połączenie
montażowe
kilku elementarnych przepływów danych w
Wtedy pakiety lub jednostki przenoszone
jeden skonsolidowany
przepływami będą materiałem fizycznym
Składniki DFD  przepływ Składniki DFD  przepływ
Dane poruszające się wzdłuż przepływu
Należy pamiętać, że ta sama zawartość wędrują albo do innego procesu (jako
wejściowe) albo do magazynu, albo do
może mieć różne znaczenie dla różnych
terminatora
części systemu
Przepływ z dwoma grotami to dialog,
Przepływy określają kierunek: grot strzałki
umieszczenie dwóch pakietów danych
na końcu (lub być może na obu końcach)
(zapytania i odpowiedzi) na tym samym
wskazuje, czy dane (lub materiał)
przepływie
poruszają się do czy z procesu (lub w obu
W przypadku dialogu pakiety na obu
kierunkach)
końcach strzałki muszą być nazwane
Składniki DFD  przepływ 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
W przypadku, gdy jest kilka przepływów
Przepływ nie odpowiada na wiele pytań wejściowych i wyjściowych, nie jest określone
w jakiej kolejności przychodzą pakiety danych i w
proceduralnych, które nasuwają się
jakiej kolejności są generowane pakiety wynikowe
podczas oglądania DFD, np. nie udzielają
czy jednemu zestawowi pakietów wejściowych
odpowiedzi na pytania o sposób
odpowiada dokładnie jeden zestaw pakietów
pobierania informacji
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 Składniki DFD  magazyn
Magazyn służy do modelowania zbioru danych
Dla projektów informatycznych obserwuje
w bezruchu
się tendencję nazywania magazynów
Oznacza się go dwoma równoległymi liniami, są też inne
plikami lub bazami danych
alternatywne symbole graficzne
Magazyny rzeczywiście implementuje się
Zwykle nazwa wybrana dla magazynu to liczba mnoga od
w ten sposób w systemach
nazwy pakietów przenoszonych przepływami do i z
magazynu skomputeryzowanych
Ale mogą być też inne formy, np.
w przypadku modelowania przepływów
produkcji
Składniki DFD  magazyn Składniki DFD  magazyn
Magazyny są połączone przepływami
Pomijając fizyczną postać magazynu, można
z procesami
zapytać o jego przeznaczenie
Przepływ z magazynu interpretuje się zwykle jako
Czy jego istnienie wynika z podstawowych
odczyt lub dostęp do informacji w magazynie
wymagań użytkownika, czy też jest to wygodny
Przepływ do magazynu opisuje się często jako
aspekt implementacji sytemu
zapis, aktualizację lub być może usuwanie
W pierwszym przypadku magazyn służy do
We wszystkich przypadkach jest oczywiste, że
czasowego buforowania informacji między
stan magazynu ulega zmianie w wyniku
dwoma procesami, działającymi w różnym czasie
wchodzącego przepływu
Magazyny tworzy się też w przewidywaniu
przyszłych potrzeb użytkownika
Składniki DFD  magazyn Składniki DFD
Badając przepływy wchodzące i wychodzące dla
magazynu, pojawia się wiele pytań
Diagramy przepływu danych buduje się z
proceduralnych, np. czy przepływ reprezentuje
czterech podstawowych elementów:
pojedynczy pakiet, wiele pakietów, fragment
pakietu itp.
Proces
Czasem można udzielić odpowiedzi na podstawie
etykiety przepływu
Przepływ
Aby dowiedzieć się wszystkiego, co może być
Magazyn
potrzebne na temat przepływu wychodzącego z
magazynu, będziemy musieli poznać szczegóły
Terminator
procesu (jego specyfikację), do którego jest
przyłączony przepływ
Składniki DFD  magazyn Składniki DFD  terminator
Jednego szczegółu proceduralnego możemy być pewni:
Graficznie przedstawia się go za pomocą prostokąta
magazyn jest bierny, dane nie wychodzą z magazynu
Terminatory reprezentują zewnętrzne obiekty,
wzdłuż przepływu, dopóki jakiś proces jawnie tego nie
z którymi komunikuje się system
zażąda
Może to być grupa osób, firma zewnętrzna, inny dział w
Czyni się jeszcze jedno szczegółowe założenie
tej samej firmie czy inny system
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 Składniki DFD  terminator
Należy pamiętać: Żaden istniejący związek między terminatorami
nie będzie pokazany w modelu DFD
Terminatory znajdują się na zewnątrz
modelowanego systemu; przepływy łączące je
Może być nawet kilka takich związków, lecz
z różnymi procesami (lub magazynami)
z definicji nie wchodzą one w skład
systemu stanowią interfejs między systemem
modelowanego systemu
a otaczającym światem
Odwrotnie, jeśli związki występujące między
W konsekwencji jest oczywiste, że ani
terminatorami są istotne dla analityka
analityk, ani projektant nie mogą zmienić
i powinny być modelowane, aby poprawnie
terminatora ani wpłynąć na sposób jego
udokumentować wpływ na system, to
działania
z definicji terminatory wchodzą w skład systemu
i należy je modelować jako procesy
Wskazówki dotyczące
Nazwy
poprawne
konstruowania DFD
zamówienia
Wybieraj znaczące nazwy dla procesów,
zamówienia
przepływów, magazynów i terminatorów
KOWALSKI błędne
zamówienia
Numeruj procesy
Przerysuj DFD, ilekroć jest to niezbędne z
poprawne
przyczyn estetycznych
zamówienia
Unikaj nadmiernie złożonych DFD
zamówienia
Sprawdz

błędne
Upewnij się, że DFD jest wewnętrznie
zamówienia
zamówienia
niesprzeczny oraz niesprzeczny
z innymi spokrewnionymi DFD
Niesprzeczność
c
a
Nadmiernie
Przetwarzaj
złożone DFD
materiał
d
b
wg.
Przykład nieskończonej
J. Roszkowski
c
studni
a
Analiza i projektowanie
strukturalne
Przetwarzaj
materiał
d
b
Przykład procesu bez wejść
Zrównoważone DFD
Zrównoważone DFD
B
A
SYSTEM
Należy unikać diagramów zbyt złożonych
C
Realizuje się to przez podział całego
A
DIAGRAM KONTEKSTOWY
diagramu na szereg poziomów,
1 2
B
z których każdy dostarcza więcej
Y
X
X
szczegółów o wyższym poziomie
Z
3.1 3.2 3 4
C
DIAGRAM 0
3.3
3.4
Z
Y
DIAGRAM 3
Zrównoważone DFD Zrównoważone DFD
DFD najwyższego poziomu składa się tylko
DFD bezpośrednio poniżej diagramu
z jednego procesu reprezentującego cały
kontekstowego nazywa się Diagramem 0
system
Przedstawia najwyższy poziom widzenia
Przepływy danych pokazują interfejsy
głównych funkcji systemu oraz głównych
między systemem i terminatorami
interfejsów między tymi funkcjami
zewnętrznymi (wraz z ewentualnymi
magazynami zewnętrznymi)
Każdy z tych procesów dla wygody
powinien być numerowany
Ten specjalny DFD nazywa się
diagramem kontekstowym
Zrównoważone DFD
Zrównoważone DFD
B
A
SYSTEM
Numeracja służy również jako wygodny
C
sposób powiązania procesu z DFD
A
bezpośrednio niższego poziomu, opisującym
DIAGRAM KONTEKSTOWY
1 2
B
pełniej ten proces, na przykład:
Y
proces z Diagramu 0 jest związany
X
X
z DFD niższego poziomu nazywanym Diagram 3
Z
3.1 3.2 3 4
procesy wewnątrz Diagramu 3 numeruje się
C
3.1, 3.2, 3.3 itd.
DIAGRAM 0
3.3
3.4
Z
Y
DIAGRAM 3
Zrównoważone DFD Zrównoważone DFD
Jak określić, ile poziomów powinien
Jest to w miarę prosty sposób organizacji mieć DFD?
potencjalnie olbrzymiego diagramu
Żaden DFD nie powinien zawierać więcej
przepływu danych w grupę poręcznych niż 6-7 procesów
fragmentów
Jeśli specyfikacji pewnego procesu nie da
się zapisać na jednej stronie, to jest on
Warto jednak dodać parę uwag do tego
prawdopodobnie zbyt złożony i należy go
opisu:
rozbić na DFD niższego poziomu przed
napisaniem specyfikacji
Zrównoważone DFD Zrównoważone DFD
Jakiej liczby poziomów należy oczekiwać
po typowym systemie? Czy wszystkie części systemu
powinny być rozbite do tego samego
W prostym systemie pojawią się 2 lub 3
poziomy, w dużym 5 do 8
poziomu?
Całkowita liczba procesów rośnie wykładniczo,
Nie muszą
wraz ze wzrostem poziomów
Niektóre części systemu mogą być bardziej
Jeśli na każdym diagramie występuje
złożone niż inne i mogą wymagać jednego
7 procesów, to trzeci poziom będzie zawierać
lub dwóch dodatkowych poziomów
343 procesy, piąty 16 807,
a dziewiąty 40 353 607
Zrównoważone DFD Zrównoważone DFD
W jaki sposób pokazywać poziomy
Jak upewnić się, że poziomy DFD są ze
użytkownikowi?
sobą zgodne?
Wielu użytkowników chce patrzeć tylko na jeden
Dla zapewnienia zgodności każdego diagramu z
diagram
diagramem nadrzędnym stosuje się prostą
Członek kierownictwa obejrzy tylko diagram
kontekstowy lub ewentualnie Diagram 0 regułę
Użytkownik operacyjny zechce zapoznać się z
Przepływy danych wchodzące i wychodzące z
diagramem obejmującym fragment systemu,
procesu na danym poziomie powinny
który go dotyczy
odpowiadać przepływom danych wchodzących
Prezentacja całości powinna odbywać się od
i wychodzących z całego diagramu niższego
góry
poziomu opisującego ten proces
Zrównoważone DFD
Zrównoważone DFD
B
Jak pokazywać magazyny na różnych
A
SYSTEM
poziomach?
C
Jest to miejsce świadomego wprowadzania
A
nadmiarowości do modelu
DIAGRAM KONTEKSTOWY
1 2
B
Pokaż magazyn na najwyższym poziomie, na
Y
X
X którym po raz pierwszy służy jako interfejs
Z
między procesami
3.1 3.2 3 4
Następnie pokaż go na każdym diagramie
C
DIAGRAM 0
niższego poziomu, który szerzej opisuje te
3.3
3.4
procesy
Z
Y
DIAGRAM 3
Magazyny na różnych poziomach
Słowniki danych
Drugim ważnym narzędziem modelowania
A
jest słownik danych
X
Jest to uporządkowany wykaz wszystkich
elementów danych mających związek z
B
systemem, wraz z ich precyzyjnym
określeniem
A.1 B.1
Gwarantuje to, że użytkownik
i analityk będą jednakowo rozumieli
X X
wszystkie wejścia, wyjścia, składniki
magazynów i obliczenia pośrednie
A.2 B.2
Słowniki danych Słowniki danych
Słownik danych definiuje elementy danych w
Słownik danych definiuje elementy danych
następujący sposób:
w następujący sposób (cd.):
opisując znaczenie przepływów
opisując budowę pakietów danych w
i magazynów pokazanych na diagramach
magazynach
przepływu danych
określając właściwe wartości i jednostki
opisując budowę złożonych pakietów danych
transmitowanych wzdłuż przepływów, tzn. elementarnych porcji informacji dla
pakietów (takich jak adres klienta), które
przepływów i magazynów danych
można rozbić na bardziej elementarne
opisując szczegóły związków między
jednostki (takie jak miasto, województwo, kod
magazynami, pokazanymi na diagramie
pocztowy itd.)
związków encji
Notacja słownika danych Słowniki danych
Przykładowo, moglibyśmy zdefiniować
Następująca notacja należy do
pełne-nazwisko następująco:
najpopularniejszych i korzysta
*definicja pełnego nazwiska*
z niewielu prostych symboli:
pełne-nazwisko = tytuł + imię + (drugie imię) +
= składa się z
nazwisko
+ i
tytuł [Pan | Pani | Dr | Profesor]
() opcjonalnie (może wystąpić lub nie)
imię {dozwolony-znak}
{} iteracja
drugie-imię {dozwolony-znak}
[] wybór jednej z kilku alternatywnych możliwości
nazwisko {dozwolony-znak}
** komentarz
dozwolony-znak [A-Z|a-z|0-9| |-| |]
| rozdziela alternatywne możliwości w konstrukcji []
Elementarne elementy danych Słowniki danych
Elementarne elementy danych to takie, dla
których nie istnieje znacząca dekompozycja w
Budowa słownika to jeden z
kontekście środowiska użytkownika
najważniejszych aspektów tworzenia
Po zidentyfikowaniu elementarnych jednostek
modelu
danych należy je wprowadzić do słownika
danych
Bez formalnego słownika, definiującego
Słownik danych powinien zawierać krótki
znaczenie wszystkich terminów, nie ma
komentarz, otoczony znakami *, podający
szans na precyzję
znaczenie terminu w kontekście użytkownika
Specyfikacja procesu Specyfikacja procesu
Jest to opis tego co dzieje się wewnątrz każdego
Do utworzenia specyfikacji procesu można
elementarnego procesu na najniższym poziomie
użyć wielu narzędzi:
DFD
tablic decyzyjnych
Przeznaczenie specyfikacji procesu definiuje, co
strukturalnego języka polskiego
należy zrobić w celu przekształcenia wejść w
warunków początkowych i końcowych
wyjścia
diagramów przepływu sterowania
Stanowi szczegółowy opis reguł działania
diagramów Nassi-Shneidermana
podanych przez użytkownika, które realizuje
dany proces
Podstawowe wymagania Podstawowe wymagania
Specyfikacja procesu musi mieć taką Specyfikacja procesu musi być wyrażona w
postaci pozwalającej na efektywną komunikację
postać, aby możliwa była jej weryfikacja
z różnymi kręgami słuchaczy
przez użytkownika i analityka
Jakkolwiek pisze ją zwykle analityk, tej lektury
Właśnie z tego powodu unika się
musi dokonać szeroki krąg użytkowników,
stosowania opisowego języka polskiego,
menedżerów, audytorów, pracowników itp.
gdyż jest wieloznaczny, zwłaszcza przy
opisywaniu alternatywnych akcji (decyzji) Większość analityków preferuje jako metodę
i akcji powtarzających się (cykli) zapisu specyfikacji procesów strukturalny język
polski
Podstawowe wymagania Strukturalny język polski
Dobre narzędzie do specyfikacji procesów nie Strukturalny język polski, jak wskazuje nazwa, to
powinno wymuszać (lub narzucać) arbitralnych  polski ze strukturą
decyzji projektowych i implementacyjnych
Jest to podzbiór języka polskiego z istotnymi
Jest to często bardzo trudne, ponieważ ograniczeniami na postać używanych zdań i
użytkownik, który określa reguły działania dla sposób ich łączenia
poszczególnych procesów w DFD, ma skłonność
Jest też znany pod nazwami PDL (Program
do opisywania ich w terminach wynikających z
Design Language) lub PSL (Problem Statement
ich obecnej realizacji
Language lub Problem Specification Language)
Zadaniem analityka, jest wydobycie z opisu
Jego celem jest osiągnięcie rozsądnego
istoty tego, co jest robione, nie zaś tego jak się
kompromisu między pozycją formalnego języka
to obecnie odbywa
programowania a swobodą i czytelnością języka
polskiego
Strukturalny język polski Strukturalny język polski
Zdanie w strukturalnym języku polskim może
być równaniem algebraicznym, np.
Inne przykłady zapisane w strukturalnym
X = (Y*Z)/(Q+14)
języku polskim :
lub prostym zdaniem rozkazującym, składającym
USTAW STOPA_PODATKOWA NA 30
się z czasownika i dopełnienia
DODAJ 3 DO X
Zdania opisujące obliczenia mogą być
poprzedzone czasownikami OBLICZ, DODAJ,
POMNÓŻ CENA_JEDNOSTKOWA PRZEZ
USTAW itp.
ILOŚĆ
Poprzedni przykład można więc zapisać jako
OBLICZ X = (Y*Z)/(Q+14)
Strukturalny język polski Strukturalny język polski
Czasowniki należy dobierać z niewielkiej grupy
Obiekty występujące w dopełnieniach prostych
czasowników odpowiadających akcjom, takich
zdań rozkazujących powinny składać się z
jak:
elementów danych zdefiniowanych w słowniku
WEy
albo WCZYTAJ albo POBIERZ
lub być terminami lokalnymi
UMIEŚĆ albo WYŚWIETL albo WPISZ
Terminy lokalne to słowa wprost zdefiniowane w
ZNAJDy
albo SZUKAJ
danej specyfikacji procesu; są one znane i
DODAJ, ODEJMIJ, POMNÓŻ, PODZIEL
znaczące jedynie wewnątrz tej specyfikacji
OBLICZ, USUC
, SPRAWDy
, PRZENIEŚ
Typowy przykład terminu lokalnego to obliczenie
ZAST
P, USTAW, SORTUJ pośrednie, służące do wyprodukowania
ostatecznych wyników procesu
W większości przypadków 40-50 czasowników
wystarcza do zapisania wszystkich specyfikacji
procesów
Strukturalny język polski Strukturalny język polski
suma_dzienna = 0
DO WHILE istnieją zamówienia w ZAMÓWIENIA z
Następująca specyfikacja procesu
data_faktury = obecnej dacie
w strukturalnym języku polskim bada ciąg
CZYTAJ następne zamówienie z ZAMÓWIENIA z
rekordów zamówień w magazynie
data_faktury = obecnej dacie
ZAMÓWIENIA, aby obliczyć sumę dzienną:
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
Entity Ralationship Diagram ERD to model
sieciowy opisujący na wysokim poziomie
abstrakcji układ danych przechowywanych w
Diagramy związków
systemie
Różni się więc od diagramu przepływu danych,
encji
modelującego funkcje realizowane przez system,
oraz od diagramu sieci przejść, modelującego
czasową charakterystykę zachowania systemu
Diagramy związków encji Diagramy związków encji
Model danych jest istotny przede wszystkim
Takich użytkowników bardziej interesuje:
dlatego, że struktury danych i ich powiązania
mogą być tak złożone, że będziemy chcieli je
jakich danych potrzebujemy do
obejrzeć i zbadać niezależnie od ich
prowadzenia naszej działalności,
przetwarzania
jak są one powiązane między sobą
Jest tak zwłaszcza wtedy, gdy pokazujemy
model systemu kierownictwu wysokiego kto jest ich właścicielem
szczebla, którzy nie są zainteresowani
kto ma do nich dostęp
szczegółami operacyjnymi codziennej pracy
systemu
Diagramy związków encji Diagramy związków encji
ERD ma również wielką zaletę dla analityka: uwypukla
Diagram związków encji to wydajne narzędzie
związki między magazynami danych na DFD, które w
modelowania do komunikacji z grupą
przeciwnym razie byłyby widoczne tylko w specyfikacji
zarządzającą bazą danych
procesu
Opierając się na informacji umieszczonej na
Typowy ERD pokazany jest na rysunku
ERD, grupa zarządzającą bazą danych może
Każdy z prostokątów odpowiada magazynowi danych na
ustalić jakie rodzaje kluczy, indeksów lub
DFD, widać też związki (połączenia), zazwyczaj nie
wskaz
ników będą niezbędne do zapewnienia pokazywane na DFD
skutecznego dostępu do rekordów bazy danych
Diagramy związków encji Typy obiektów
Istnieją cztery podstawowe składniki Na diagramie związków encji typ obiektu
diagramu związków encji: jest przedstawiany prostokątem
typy obiektów Reprezentuje on populację lub zbiór
obiektów w świecie rzeczywistym, którego
związki
poszczególne elementy (lub egzemplarze)
wskaz
niki asocjowanych typów obiektów
mają następujące cechy:
wskaz
niki nadtypów/podtypów
Typy obiektów - cechy Typy obiektów - cechy
Każdy odgrywa jakąś rolę w budowanym
Każdy z nich można w jakiś sposób
systemie
zidentyfikować
Inaczej mówiąc, aby typ obiektu był uzasadniony, musi
Istnieje sposób odróżniania poszczególnych egzemplarzy
być możliwość stwierdzenia, że system nie mógłby
typu obiektu
działać bez dostępu do jego elementów
Jeśli mamy typ obiektu KLIENT, musimy jakoś
Budując system przyjmowania zamówień dla sklepu,
odróżniać jednego klienta od drugiego (być może po
można przyjąć, że oprócz klientów w sklepie są również
numerze konta, nazwisku lub numerze ewidencyjnym)
dozorcy, z których każdy jest identyfikowany nazwiskiem
Gdyby wszyscy byli tacy sami (jeśli prowadzimy firmę, Chociaż dozorcy pełnią w sklepie pożyteczną funkcję, to
system przyjmowania zamówień może funkcjonować bez
dla której klienci to bezimienne postacie wchodzące po
nich, dlatego nie powinni być typem obiektu w modelu
zakupy do naszego sklepu), wówczas KLIENT nie byłby
systemu
sensownym typem obiektu
Oczywiście takie rzeczy należy zweryfikować
z użytkownikami podczas budowy modelu
Typy obiektów - cechy Typy obiektów
Każdy może być opisany jednym lub
W wielu budowanych systemach typy obiektów
więcej elementami danych
będą systemową reprezentacją materialnych
KLIENT może być opisany takimi elementami
obiektów świata rzeczywistego
danych, jak: nazwisko, adres, limit kredytowy i
Typowe obiekty to: klienci, pozycje inwentarza,
numer telefonu
pracownicy, produkowane części itp.
Nazywa się to przypisywaniem atrybutów
Obiekt istnieje materialnie w rzeczywistym
danych typowi obiektu
świecie, a typ obiektu jest jego systemową
Atrybuty powinny odnosić się do każdego
reprezentacją
egzemplarza typu obiektu, np. każdy klient
Obiekt może być jednak również czymś
powinien mieć nazwisko, adres, limit kredytowy,
niematerialnym, np. harmonogramem, planem,
numer telefonu itp.
standardem, strategią, mapą
Typy obiektów Typy obiektów
Zazwyczaj posługujemy się formą
W systemie często typami obiektów są ludzie,
pojedynczą rzeczownika, np. pracownik,
dlatego może być taka sytuacja, że ta sama
klient itp.
osoba (a także dowolny inny obiekt materialny)
może odpowiadać kilku różnym typom obiektów
Nie jest to konieczne ale jest wygodne
w różnych modelach danych lub nawet w tym
Istnieje odpowiedniość między obiektami
samym modelu danych
na ERD i magazynami na DFD
Jan Kowalski może być PRACOWNIKIEM w
jednym modelu i KLIENTEM w innym
Jeśli KLIENT jest obiektem na ERD to
Może także być PRACOWNIKIEM
powinien istnieć magazyn KLIENCI na
i KLIENTEM w tym samym modelu danych
DFD
Związki Związki
Obiekty są ze sobą połączone związkami
Należy pamiętać, że związek reprezentuje
Związki jest to zbiór powiązań między obiektami i
zbiór powiązań
jest przedstawiany rombem
Na rysunku przedstawiony jest prosty związek
Każdy egzemplarz związku jest
między dwoma obiektami
powiązaniem między zerem lub większą
Związki mogą istnieć między więcej niż dwoma
liczbą wystąpień jednego obiektu i zerem
obiektami
lub większą liczbą wystąpień drugiego
Związki Związki
Jak widać związek może łączyć dwa lub większą
Związek KUPUJE przedstawiony na rysunku
liczbę egzemplarzy tego samego obiektu
może zawierać więc następujące konkretne
Związek reprezentuje coś, co musi być
egzemplarze:
pamiętane przez system  nie może być
egzemplarz 1: klient 1 kupuje towar 1
obliczone ani wprowadzone mechanicznie
egzemplarz 2: klient 2 kupuje towar 2 i 3
Model danych przedstawiony na rysunku
wskazuje więc, że istnieje pewna istotna
egzemplarz 3: klient 3 kupuje towar 4
przyczyna, dla której użytkownik chce pamiętać,
egzemplarz 4: klient 4 kupuje towar 5,6,7
że klient 1 kupił towar 1 itd.
egzemplarz 5: klient 5 nie kupuje towarów
Wskazuje też, że nie istnieją żadne przesłanki,
egzemplarz 6: klienci 6 i 7 kupują towar 8
pozwalające stwierdzić a priori, że klient 1 kupił
egzemplarz 7: klienci 8,9,10 kupują towary 9, 10, 11 towar 1 i nic więcej
Związki
Związki
Może okazać się, że
istnieje kilka różnych
Związek reprezentuje pamięć systemu
egzemplarzy  leczenia
Oczywiście obiekt także reprezentuje pamięć
między lekarzem i tym
systemu
samym pacjentem (tzn.
wizyta początkowa,
Między dwoma obiektami może istnieć więcej niż
wizyty kontrolne, itp.)
jeden związek
Na kolejnym rysunku przedstawiono związki
między PACJENTEM a LEKARZEM
Z rysunku wynika również, że związek płacenia jest
Na pierwszy rzut oka może to wyglądać na
oddzielony od związku leczenia
niepotrzebny podział: ilekroć lekarz przyjmuje
Być może niektórzy pacjenci płacą tylko za pierwszą
pacjenta, wystawia mu rachunek
wizytę, inni za wszystkie wizyty a jeszcze inni nie płacą
wcale
Związki Związki
Dla złożonych
diagramów (jak na
Częstsza sytuacja to wiele związków
rysunku) związek
i połączone nim
między wieloma obiektami
obiekty należy czytać
Kolejny rysunek pokazuje związek zwykle
jako całość
Związek można opisać
istniejący między nabywcą, sprzedawcą,
z perspektywy
agentem nieruchomości, adwokatem
dowolnego
występującego typu
nabywcy i adwokatem sprzedawcy, w celu
obiektu, wszystkie
sprzedaży i zakupu domu
perspektywy są
poprawne
Związki Związki
Właśnie zbiór tych perspektyw poprawnie
Alternatywna notacja dla związków
opisuje związek
Związki w diagramie E-R są
Na rysunku związek NEGOCJUJE CEN
można
wielokierunkowe, można je czytać
odczytać w następujący sposób:
w dowolnym kierunku
Agent nieruchomości negocjuje cenę między
Diagramy E-R nie pokazują liczności, tzn.
nabywcą i sprzedawcą
nie pokazują liczby obiektów biorących
Nabywca za pośrednictwem agenta
nieruchomości negocjuje cenę ze sprzedawcą
udział w związku
Sprzedawca za pośrednictwem agenta
Jest to całkowicie świadome i przemyślane:
nieruchomości negocjuje cenę z nabywcą
takie szczegóły znajdują się w słowniku
danych
Związki
Związki
N
1
Niektórzy analitycy używają alternatywnej notacji,
podającej liczność i kierunek
Inną popularną notację przedstawiono na
Związek między KLIENTEM i TOWAREM
kolejnym rysunku; strzałka z podwójnym
Dodatkowa notacja pokazuje, że:
KLIENT to punkt zaczepienia, podstawowy obiekt, grotem służy do pokazania związku jeden-do-
z którego perspektywy należy odczytywać związek
wielu, natomiast strzałka z pojedynczym grotem
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
oznacza związek jeden-do-jednego między
związek wskazuje, że tylko jeden klient wystąpi w każdym
egzemplarzu związku obiektami
Wyklucza to przypadki, gdy kilku klientów jest związanych z
zakupem jednego towaru
Wskaz
niki asocjowanych typów
Wskaz
niki asocjowanych typów
obiektów
obiektów
Specjalną notacją na diagramie E-R jest
wskaz
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ą
Rozważmy prosty przypadek klienta kupującego
informację
towar (lub towary) pokazany na rysunku
Wskaz
niki asocjowanych typów Wskaz
niki asocjowanych typów
obiektów obiektów
Istotą sprawy jest, że związek ZAKUPU to nic ZAKUP zapisujemy teraz w prostokącie
więcej tylko powiązanie KLIENTA z jednym lub z i łączymy strzałką z rombem anonimowego
większą liczbą TOWARÓW związku
Załóżmy jednak, że istnieją pewne dane, które Ma to wskazywać, że ZAKUP ma tutaj dwa
chcemy zapamiętać dla każdego egzemplarza znaczenia
zakupu (np. porę dnia)
Typ obiektu, czyli coś o czym chcemy
Gdzie przechowywać te informacje?  Pora dnia przechowywać informacje. Tutaj chcemy
to na pewno nie atrybut KLIENTA, ani też pamiętać porę, kiedy klient dokonał zakupu i
TOWARU zaoferowany upust
Wobec tego przypisujemy  porę dnia samemu Związek łączący dwa typy obiektów KLIENT
zakupowi i umieszczamy na diagramie w sposób i TOWAR. Istotną sprawą jest, że KLIENT
pokazany na rysunku i TOWAR są całkowicie odrębne. Istnieją
niezależnie od tego, czy dokonano jakiegoś
zakupu
Wskaz
niki asocjowanych typów
Wskaz
niki nadtypu/podtypu
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
Typy obiektów nadtyp/podtyp obejmują typ
pozostawiono anonimowym, ponieważ wskaz
nik
obiektu i jedną lub więcej podkategorii,
asocjowanego typu obiektu (ZAKUP) jest
połączonych związkiem
jednocześnie nazwą związku
Rysunek pokazuje typowy nadtyp/podtyp
Kategorią ogólną jest PRACOWNIK,
podkategoriami zaś są PRACOWNIK ETATOWY
i PRACOWNIK GODZINOWY
Wskaz
niki nadtypu/podtypu Wskaz
niki nadtypu/podtypu
Możemy sobie wyobrazić, że wszyscy pracownicy
Poddtypy są połączone z nadtypem
są opisani za pomocą następujących danych:
anonimowym związkiem, a nadtyp jest
nazwisko
połączony ze związkiem przekreśloną linią
staż pracy
W tej notacji nadtyp określa się
adres domowy
elementami danych odnoszącymi się do
nazwisko kierownika
wszystkich podtypów
Natomiast każdy podtyp jest określany różnymi
elementami danych, w przeciwnym razie nie
miałoby sensu wyróżnianie ich
Wskazówki do konstruowania
Wskaz
niki nadtypu/podtypu
diagramów związków encji
Wobec tego PRACOWNIK ETATOWY jest
Ważne jest w jaki sposób należy wykrywać
opisany takimi informacjami jak:
obiekty i związki
pensja miesięczna
Początkowy model typów obiektów i związków
procent premii rocznej
będzie zwykle oparty na:
zakres korzystania z samochodu firmy
znajomości aplikacji użytkownika
a PRACOWNIK GODZINOWY takimi jak:
wywiadach z użytkownikami
stawka godzinowa
wszelkich innych sposobach zbierania informacji, z
dopłata za nadgodziny
jakich można skorzystać
czas rozpoczęcia
Diagramy związków encji zmienia się
i poprawia wielokrotnie
Dołączanie dodatkowych typów Dołączanie dodatkowych typów
obiektów obiektów
Początkowy ERD tworzy się na podstawie Można to osiągnąć w różny sposób:
wywiadów z użytkownikami i wiedzy na temat
Jeśli model procesów DFD jest już
dziedziny klienta sporządzony lub jest budowany równolegle z
modelem danych, wówczas będzie już istniał
Powinno to wskazać główne obiekty
słownik danych
i związki
Jeśli model procesów jeszcze nie istnieje to
Po sporządzeniu wstępnego ERD następny krok
należy rozpocząć od wywiadów ze wszystkimi
to przypisanie typom obiektów atrybutów 
użytkownikami, aby zbudować wyczerpującą
elementów danych
listę (definicji) elementów danych
Dołączanie dodatkowych typów Dołączanie dodatkowych typów
obiektów obiektów
W wyniku przypisywania atrybutów mogą
Jeśli podczas przypisywania atrybutów
wystąpić trzy powody tworzenia nowych
typom obiektów okaże się, że pewne
obiektów:
elementy danych nie mogą być przypisane
Można odkryć elementy danych, które można
wszystkim egzemplarzom pewnego typu
przypisać tylko do niektórych egzemplarzy typu
obiektu, należy utworzyć zbiór podtypów
obiektu
Można wykryć, że pewne elementy danych mają
dla danego typu i przypisać elementy
zastosowanie do wszystkich egzemplarzy dwóch
danych odpowiednim podtypom
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
Dołączanie dodatkowych typów
obiektów
obiektów
Przypuśćmy, że budujemy system obsługi
klienta i zidentyfikowano typ obiektu
nazwany KLIENT
Przeglądając istniejące elementy danych
Jednakże są elementy danych, które występują dla części
stwierdzamy, że wiele z nich (NIP, adres,
egzemplarzy a nie występują dla innej
nazwa firmy, itp.) ma zastosowanie do
Na przykład KLIENT KRAJOWY i KLIENT ZAGRANICZNY,
wszystkich egzemplarzy klienta dla których w firmie są inne procedury obsługi
W takiej sytuacji należy utworzyć podtypy
Dołączanie dodatkowych typów
Dołączanie dodatkowych typów
obiektó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
A
atwo stwierdzić, że są takie elementy danych jak
tworzyliśmy ERD dla systemu przyjmowania
nazwisko, adres itp., które opisują w ten sam sposób oba
zamówień (być może kierując się informacją od
te typy; sugerowałoby to utworzenie nadtypu, co ilustruje
użytkownika, że są to dwie różne kategorie)
rysunek
Dołączanie dodatkowych typów
Dołączanie dodatkowych typów
obiektó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
Jeżeli element danych opisuje interakcję między dwoma lub
Sugeruje to, że należy zastąpić związek KUPUJE
więcej typami obiektów, należy zastąpić  czysty związek
asocjowanym typem obiektu, pokazanym na rysunku
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 Dołączanie dodatkowych typów
obiektów obiektów
Czasami początkowy diagram E-R będzie zawierał typ Podczas przypisywania atrybutów różnym
obiektu, który przy dokładniejszej analizie okaże się
obiektom stwierdziliśmy, że data_dostawy
asocjowanym typem obiektu
najbardziej pasuje do obiektu ZAMÓWIENIE
Rysunek przedstawia diagram E-R z trzema powiązanymi (w końcu klienci nie są dostarczani, towary zaś są
obiektami: KLIENTEM, ZAMÓWIENIEM i TOWAREM 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
Powtarzające się grupy
obiektów
Rozważmy typ obiektu PRACOWNIK, z takimi
oczywistymi elementami danych jak nazwisko i
adres
Załóżmy, że znalez
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
Powtarzające się grupy
Można także dostrzec, że istnieje wiele
B
A
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 Usuwanie typów obiektów
Często modyfikacja ERD polega na usunięciu
Taki proces usuwania obiektów zagnieżdżonych
nadmiarowych lub błędnych typów obiektów i
stanowi część szerszej czynności modyfikacji
związków.
zwanej normalizacją
Są cztery typowe sytuacje:
Celem normalizacji jest otrzymanie typów
Typy obiektów składające się jedynie z
obiektów, w których każdy egzemplarz (lub
identyfikatora
element) składa się z wartości klucza
Typy obiektów mające tylko jeden egzemplarz
pierwotnego, identyfikującej pewną encję, wraz
Zawieszone asocjowane typy obiektów
ze zbiorem wzajemnie niezależnych wartości
Związki wyprowadzalne
atrybutów, opisujących w jakiś sposób encję
Usuwanie typów obiektów Usuwanie typów obiektów
Podczas przypisywania
Jeśli mamy diagram E-R, na którym
atrybutów rozmaitym
pewien typ obiektu jako jedyny element
obiektom stwierdziliśmy,
danych ma przypisany identyfikator,
że jedyną informacją,
jaką o współmałżonku
możliwe jest wyeliminowanie tego typu
przechowuje system
obiektu i przypisanie identyfikatora jako
kadrowy, jest nazwisko
elementu danych spokrewnionemu typowi
(tzn. identyfikator
odróżniający od siebie
obiektu
poszczególnych
Ilustruje to przykład fragmentu systemu
współmałżonków w
systemie)
kadrowego
Usuwanie typów obiektów Usuwanie typów obiektów
Oczywistą modyfikacją jest wówczas eliminacja
Jeszcze większej redukcji
WSPÓA
MAA
ŻONKA jako typu obiektu oraz dołączenie
można dokonać wówczas,
nazwiska_współmałżonka jako elementu danych do
gdy początkowy diagram
obiektu PRACOWNIK
E-R zawiera obiekt, który
ma tylko identyfikator i
Takie ulepszenie ma sens jedynie wtedy, gdy istnieje
tylko jeden egzemplarz
wzajemnie jednoznaczna odpowiedniość między
egzemplarzami właśnie usuwanego obiektu i
Rozważmy początkowy
egzemplarzami spokrewnionego obiektu
diagram E-R
Podany przykład ma sens, ponieważ we przedstawiony na rysunku
współczesnych społeczeństwach zakłada się, że
można mieć co najwyżej jednego współmałżonka
Usuwanie typów obiektów Usuwanie typów obiektów
Na pierwszy rzut oka wydaje się rozsądne
Z tego powodu mogą pojawić się zawieszone
pokazanie związku między pacjentami i lekami w
asocjowane typy obiektów
szpitalu
Rozważmy wariant poprzedniego przykładu
Przypuśćmy jednak, że jedyną informacją
szpitalnego, pokazany na rysunku
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 Usuwanie typów obiektów
Jeśli okaże się, że LEK ma jedynie identyfikator i
pojedynczy egzemplarz, wówczas będzie
Po modyfikacji TERAPIA jest wciąż
usunięty
asocjowanym typem obiektu, mimo że jest
Doprowadzi to do diagramu
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
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
Prowadzi to do diagramu, na którym typy obiektów nie
PRAWEM JAZDY może być wyprowadzony (na są połączone
podstawie daty urodzenia, czy w inny sposób Jest to poprawne, ponieważ nie jest konieczne, aby
każdy typ obiektu był połączony z innym
stosowany przez wydziały komunikacyjne),
wówczas należy go wyeliminować
Rozszerzenia słownika danych Rozszerzenia słownika danych
Słownik danych należy rozszerzyć na potrzeby
Definicja KLIENTA obejmuje specyfikację pola
notacji ERD
klucza, który jest elementem danych (lub
W zasadzie obiekty na ERD odpowiadają
atrybutem) odróżniającym poszczególne
magazynom na DFD
egzemplarze klienta. Znak  at @ służy do
Oznacza to, że w definicji w słowniku danych,
wskazania pól klucza
KLIENT to zarówno definicja typu obiektu, jak i
Inny sposób wskazania klucza to podkreślenie
egzemplarz magazynu KLIENCI:
KLIENT =
KLIENCI = {KLIENT}
nazwisko_klienta+adres+numer_telefonu
KLIENT =
@nazwisko_klienta+adres+numer_telefonu
Rozszerzenia słownika danych
Rozszerzenia słownika danych
Do słownika danych musimy również dołączyć
definicje wszystkich związków pokazanych na
ERD
Związek kupuje, pokazany na rysunku można
Definicja związku powinna obejmować opis
zdefiniować w słowniku danych następująco:
znaczenia związku w kontekście aplikacji i
kupuje = *powiązanie klienta i jednego lub
wskazywać obiekty tworzące związek
więcej towarów*
Mogą być określone odpowiednie ograniczenia
@id_klienta + {@id_towaru + zakupiona_ilość}
dolne i górne, aby wskazać, czy związek
jeden-do-jednego, jeden-do-wielu
czy też wiele-do-wielu
Podsumowanie
Podsumowanie
Pytanie czy najpierw należy budować model DFD, a
dopiero potem ERD, czy też lepiej rozpocząć od
ERD?
Dla każdego systemu z wieloma
Niektórzy pytają nawet, czy rzeczywiście należy
magazynami (obiektami) i złożonymi
sporządzić oba modele, skoro zarówno DFD jak i
strukturami danych ERD stanowi
ERD dostarczają tak wiele interesującej informacji
wartościowe narzędzie
Odpowiedz
na pierwsze pytanie jest łatwa: nie ma
znaczenia, który model będzie zbudowany pierwszy
Koncentruje się ono całkowicie na
Zależnie od własnych preferencji, preferencji
związkach między danymi, pomijając
użytkownika lub natury samego systemu (tzn. czy
funkcje tworzące lub korzystające
jest on bogaty w funkcje czy w dane) jeden
z modeli wyda się na początek łatwiejszy
z tych danych
Niekiedy może okazać się, że oba modele będą
budowane jednocześnie
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ć
Diagramy sieci przejść
Obecnie omówimy trzeci rodzaj narzędzi
modelowania, diagram sieci przejść (STD -
State Transition Diagram), pokazujący
zachowania systemu w czasie
Diagramy sieci przejść Diagramy sieci przejść
Do niedawna modele zachowania systemu w czasie
Wiele z nich to systemy bierne w tym
były istotne tylko dla specjalnej kategorii systemów
sensie, że nie sterują otaczającym
zwanych systemami czasu rzeczywistego
środowiskiem, lecz jedynie reagują na nie
Przykładami takich systemów są:
i gromadzą o nim informacje
systemy sterowania procesami
telefoniczne systemy przełączające Do tej kategorii należy wiele systemów
szybkiego gromadzenia danych
systemy szybkiego gromadzenia danych
(np. system gromadzenia danych
wojskowe systemy nadzoru i sterowania
naukowych z satelity)
Diagramy sieci przejść Diagramy sieci przejść
Dla systemów handlowych zagadnienie to
Inne systemy czasu rzeczywistego są bardziej
w zasadzie nie było istotne
aktywne, mogą sterować niektórymi aspektami
Dane mogą napływać z wielu różnych z
ródeł
otaczającego środowiska
z dość dużą szybkością, lecz ich przetwarzanie może
Do tej kategorii należą systemy sterowania
być zwykle odroczone, jeśli system zajmuje się
procesami
czymś innym
Systemy tego rodzaju mają do czynienia
Obecnie jednak zaczynają się pojawiać wielkie,
z bardzo szybkimi zewnętrznymi z
ródłami danych,
złożone systemy handlowe, w których występują
muszą udzielać odpowiedzi i dostarczać danych aspekty czasu rzeczywistego
wynikowych dostatecznie szybko dla zewnętrznego
Jeśli system otrzymuje dane z tysięcy terminali, jak
środowiska też szybkie dane z innych systemów komputerowych
lub urządzeń do komunikacji satelitarnej, wówczas
Ważną częścią ich specyfikacji jest określenie, co ma
pojawiają się te same problemy, co w klasycznym
kiedy nastąpić
systemie czasu rzeczywistego
Notacja diagramu sieci przejść
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
Typowy diagram sieci przejść pokazany jest na
rysunku
Przedstawia on zachowanie typowej
automatycznej sekretarki telefonicznej
Stany systemu Stany systemu
Przykłady typowych stanów systemu:
Każdy prostokąt reprezentuje stan, w
oczekiwanie, aby użytkownik wprowadził
hasło
jakim może znajdować się system
podgrzewanie mieszaniny chemicznej
New World Dictionary Webstera podaje
oczekiwanie na następne polecenie
następującą definicję stanu:
przyspieszanie silnika
Zbiór okoliczności lub cech
mieszanie składników
charakteryzujących osobę lub rzecz w
oczekiwanie na dane pomiarowe
danej chwili; sposób lub forma istnienia;
napełnianie zbiornika
warunek
bezczynny
Stany systemu Zmiany stanów
Wiele z tych przykładów obejmuje czekanie
System, który miałby tylko jeden stan
systemu na jakieś zdarzenie, nie opisuje zaś
byłby statyczny
żadnych działań
Zwykle systemy informacyjne, które
Dlatego dowolny obserwowalny stan systemu
odpowiada tylko okresom gdy modelujemy, mogą mieć dziesiątki różnych
(1) czeka on na jakieś zdarzenie w otaczającym
stanów
środowisku lub
W jaki sposób zmienia się stan systemu?
(2) czeka, aby obecną czynność otoczenia
Jeśli system podlega regułom rządzącym
(mieszanie, pranie, napełnianie, przyśpieszanie
itp.) zastąpiono inną
jego zachowaniem, tylko niektóre przejścia
Stan przedstawia więc zachowanie systemu,
między stanami będą sensowne i
które jest obserwowalne i trwa przez jakiś
dozwolone
skończony odcinek czasu
Zmiany stanów
Zmiany stanów
Dozwolone zmiany stanów
przedstawiamy na STD łącząc
odpowiednie pary stanów
Na rysunku znajduje się wiele interesujących
strzałkami
informacji o zachowaniu systemu, ale nie ma na
Ilustruje to kolejny rysunek
nim pewnej, być może bardzo istotnej rzeczy:
System może przejść ze stanu 1
jaki jest początkowy i końcowy stan systemu
do stanu 2, oraz że gdy system
Kolejny rysunek jest stabilnym modelem
jest w stanie 2, może przejść do
systemu, który był zawsze aktywny i zawsze
stanu 3 lub z powrotem
do stanu 1
pozostanie aktywny
System nie może przejść
Większość systemów ma wyróżnione stany
bezpośrednio ze stanu 1 do stanu
początkowe i końcowe; pokazane na rysunku
3, ale może przejść bezpośrednio
ze stanu 3 z powrotem do stanu 1
Stan 2 ma dwa następniki
Zmiany stanów Zmiany stanów
Stan początkowy rysuje się z
reguły u góry diagramu, tym co
Zdrowy rozsądek podpowiada, że system może
naprawdę wyróżnia stan 1 na
mieć tylko jeden stan początkowy, ale może
rysunku jako początkowy, jest
mieć wiele stanów końcowych
,,naga strzałka, która nie jest
Stany końcowe wzajemnie wykluczają się, tzn.
połączona z żadnym innym stanem
tylko jeden z nich może wystąpić podczas
Podobnie stan końcowy jest często
działania systemu
rysowany u dołu diagramu, tym co
identyfikuje stan 5 jako końcowy, Kolejny rysunek zawiera przykład, w którym
jest brak strzałki wychodzącej ze
możliwymi stanami końcowymi są stany 4 i 6
stanu 5
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 Warunki i akcje
Aby diagram sieci przejść był
STAN 1
Warunek to pewne zdarzenie w otaczającym
kompletny, należy dodać
Warunek
środowisku, które system może wykryć
jeszcze dwa składniki:
Akcja
warunki, powodujące zmianę
Zwykle będzie to sygnał, nadejście pakietu
stanu, oraz
danych itp.
STAN 2
akcje, które wykonuje system
Powoduje to zwykle przejście systemu ze stanu
zmieniając stan
oczekiwania na X do nowego stanu oczekiwania
Warunki i akcje zaznacza się
na Y lub z wykonywania akcji X do wykonywania
obok strzałki łączącej dwa
akcji Y
sąsiednie stany
Warunki i akcje Diagramy podzielone
Podczas zmiany stanu system zwykle wykonuje
jedną lub więcej akcji: W złożonym systemie mogą występować
dziesiątki różnych stanów; pokazanie ich na
produkuje wyniki
pojedynczym diagramie byłoby trudne, a może
wyświetla komunikat na terminalu użytkownika
nawet niemożliwe
wykonuje obliczenie itd.
Podobnie jak równoważyliśmy (dzieliliśmy)
Akcje pokazane na STD są więc odpowiedziami,
diagramy przepływu danych, można również
wysłanymi z powrotem do środowiska, lub
dokonywać podziału STD
obliczeniami, których wyniki są zapamiętywane
przez system (zwykle w magazynie danych
Kolejny rysunek zawiera przykład dwóch
pokazanym na diagramie przepływu), aby w
poziomów diagramu sieci przejść dla złożonego
razie potrzeby zareagować na jakieś przyszłe
systemu
zdarzenie
Diagramy podzielone
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
Wg Współczesna analiza
poziomu
strukturalna
E. Yourdon
WNT, Warszawa 1996
Diagramy podzielone
Budowa diagramu sieci przejść
Istnieją dwa podejścia:
Przykładem
wymagającym Można rozpocząć od zidentyfikowania
wszystkich możliwych stanów systemu,
podzielonego
reprezentując każdy z nich na rysunku
diagramu sieci przejść
oddzielnym prostokątem. Następnie można
może być bankomat
badać wszystkie sensowne połączenia (czyli
STD dla tej aplikacji
zmiany stanów) między prostokątami.
pokazano na rysunku
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ść Budowa diagramu sieci przejść
Wybór podejścia może być określony przez
Po zakończeniu budowy wstępnego STD należy
użytkownika, zwłaszcza gdy jest on jedyną
sprawdzić następujące warunki:
osobą dobrze znającą zachowanie systemu
Czy zdefiniowano wszystkie stany? Przyjrzyj się
Do wykonania akcji system może potrzebować
dokładnie systemowi, aby stwierdzić, czy istnieje jakieś
dodatkowych wejść ze środowiska zewnętrznego
obserwowalne zachowanie lub inny stan, w jakim może
znajdować się system, poza zidentyfikowanymi
Można więc stwierdzić, że każdy warunek
Czy wszystkie stany są osiągalne? Czy nie zdefiniowałeś
odpowiada zdarzeniu zewnętrznemu, na które
stanów, do których nie prowadzą żadne drogi?
system musi zareagować, zdarzenia te zaś będą
zwykle dostrzeżone przez system dzięki
Czy istnieją wyjścia ze wszystkich stanów? Jak
nadejściu wchodzącego przepływu danych 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ść Budowa diagramu sieci przejść
Czy w każdym stanie system odpowiada poprawnie na Co stanie się, jeśli użytkownik
wszystkie warunki? naciśnie ten sam klawisz
funkcyjny dwa razy z rzędu?
Jest to najczęstszy błąd przy budowie diagramu sieci
Albo inny klawisz? Jeśli
przejść
zachowanie systemu nie jest
Analityk identyfikuje zmiany stanów w warunkach
określone, istnieje duża
normalnych, lecz zapomina określić zachowanie systemu
szansa, że projektanci i
dla nieoczekiwanych zdarzeń
programiści również nie
Załóżmy, że analityk wymodelował zachowanie systemu
zaprogramują tego i system
w sposób pokazany na kolejnym rysunku
będzie się w rozmaitych
Oczekuje on, że użytkownik naciśnie pewien klawisz
okolicznościach zachowywał w
funkcyjny na swoim terminalu, aby spowodować
sposób nieprzewidziany
przejście ze stanu 1 do stanu 2 oraz inny klawisz
funkcyjny, aby przejść ze stanu 2 do stanu 3
Związek z innymi składowymi
Związek z innymi składowymi
modelu
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
Warunki na STD odpowiadają wejściowym przepływom
sterującym na DFD, a akcje na STD wyjściowym
diagramie przepływu danych
przepływom sterującym na DFD
Ilustruje to kolejny rysunek
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
Równoważenie modeli
rzeczywistego, jak też części interfejsu
użytkowego wielu systemów
interakcyjnych
Równoważenie modeli Równoważenie modeli
Każde z tych narzędzi koncentruje się na jednym
Najważniejsze narzędzia modelowania w krytycznym aspekcie modelowanego systemu
analizie strukturalnej:
Oznacza to, że osoba oglądająca model także
koncentruje się na jednym aspekcie, tzn. na
diagram przepływu danych
tym, na które narzędzie modelowania ma
słownik danych
zwrócić jej uwagę
specyfikacja procesu
Ponieważ rzeczywisty system może mieć wiele
diagram związków encji
kierunków złożoności, chcemy, aby diagram
diagram sieci przejść
przepływu danych skupił uwagę czytelnika na
funkcjach systemu, a nie na związkach między
danymi
Równoważenie modeli Równoważenie modeli
Przychodzi jednak czas połączenia
wszystkich narzędzi modelowania
Diagram związków encji ma uwypuklać
związki między danymi bez zajmowania się
Sytuacja modelującego system
przypomina starą indyjską bajkę o trzech
funkcjonalną charakterystyką systemu
ślepych mędrcach, którzy natknęli się na
Diagram sieci przejść zaś służy do
słonia
skupienia uwagi na zagadnieniach
Po dotknięciu różnych części jego ciała
synchronizacji systemu, bez rozważania
doszli do zupełnie innych wniosków o
funkcji lub danych
,,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 Równoważenie modeli
Podobnie modelując trzy różne aspekty systemu
Jest jeszcze jedna przyczyna zajmowania się
(funkcje, dane i synchronizację), jak też
spójnością modelu: istniejące błędy zostaną w
szczegółową charakterystykę systemu w słowniku
końcu wykryte, lecz staje się to znacznie
danych i w zbiorze specyfikacji procesów, łatwo
trudniejsze i bardziej kosztowne w póz
niejszych
sporządzić kilka sprzecznych interpretacji tej samej
rzeczywistości fazach projektu
Jest to szczególnie niebezpieczne w dużych
Błędy wprowadzone podczas analizy systemowej
projektach, gdy w pracach biorą udział różne osoby i
do modelu wymagań zwykle rozrastają się w
grupy o różnych zainteresowaniach
fazie projektowania i implementacji
Niebezpieczeństwo istnieje też wówczas, gdy zespół
Jest to poważne niebezpieczeństwo zwłaszcza w
projektowy obejmuje osoby o bardzo różnym
przygotowaniu wielkich systemach, w których analizy dokonują
inne osoby niż projektowania i implementacji
Równoważenie modeli Równoważenie modeli
Niektóre z błędów to oczywiście proste błędy
w pojedynczym modelu (np. diagram przepływu
50% błędów wykrywanych w systemie i 75%
danych z nieskończoną studnią)
kosztów ich usuwania jest związane z błędami
Niektóre z nich można określić jako błędną
popełnionymi podczas fazy analizy systemu
interpretację prawdziwych oczekiwań użytkownika
Koszt poprawiania błędów rośnie wykładniczo w
Jednak wiele z trudniejszych i bardziej zdradliwych
póz
niejszych etapach projektu; jest dziesięć razy
błędów to błędy między modelami, tzn. niezgodności
taniej poprawić błąd podczas analizy systemu w
jednego modelu z innym
fazie analizy niż poprawiać ten sam błąd w fazie
Specyfikację strukturalną, w której sprawdzono
projektowania
niesprzeczność wszystkich narzędzi modelowania z
innymi, nazywamy zrównoważoną
Równoważenie modeli Równoważenie modeli
Najczęstszy błąd zrównoważenia to brakująca
definicja
Równoważenie dotyczy:
Coś zdefiniowanego (lub opisanego) w jednym
diagramu przepływu danych ze słownikiem
modelu nie jest odpowiednio zdefiniowane w
danych
innym
diagramu przepływu danych ze specyfikacją
Np. magazyn danych pokazany na DFD, lecz nie
procesu
zdefiniowany w słowniku danych, lub obiekt na
specyfikacji procesu ze słownikiem danych
ERD, nie mający odpowiadającego magazynu
ERD z DFD i specyfikacjami procesów
danych na DFD)
ERD ze słownikiem danych
Drugi częsty typ błędu to niespójność: ta sama
DFD z diagramem sieci przejść
,,rzeczywistość" jest opisana różnymi, wzajemnie
sprzecznymi sposobami w różnych modelach
Równoważenie DFD ze słownikiem Równoważenie DFD ze słownikiem
danych danych
Odwrotnie, każdy element danych i każdy magazyn
danych zdefiniowany w słowniku danych musi
Reguły równoważenia diagramu przepływu
wystąpić gdzieś na DFD
danych ze słownikiem danych są
Jeśli nie występuje, wadliwy element danych lub
następujące:
magazyn danych jest "duchem" - czymś
Każdy przepływ danych (tzn. strzałka na DFD)
zdefiniowanym lecz nie "używanym" w systemie
i każdy magazyn danych musi być
Może się tak zdarzyć, gdy zdefiniowane elementy
zdefiniowany w słowniku danych. Jeśli brak go danych odpowiadają wcześniejszej wersji DFD
w słowniku danych, przepływ danych lub
Niebezpieczeństwo polega na dokonanej zmianie DFD
(np. mógł zostać usunięty przepływ danych lub
magazyn danych uznaje się za
magazyn danych) bez odpowiadającej jej zmiany w
niezdefiniowany
słowniku danych
Równoważenie DFD ze słownikiem Równoważenie DFD ze specyfikacją
danych procesu
Oznacza to, oczywiście, że analityk systemów Reguły równoważenia DFD ze specyfikacjami
musi wnikliwie przejrzeć zarówno DFD, jak i procesów:
słownik danych, aby upewnić się, że są
Dla każdego procesu na DFD musi istnieć DFD
niższego poziomu albo specyfikacja procesu, lecz nie
zrównoważone ze sobą
obie te rzeczy. Jeśli DFD zawiera proces oznaczony
Nie ma znaczenia, który model bada się
1.4.2, musi albo istnieć diagram oznaczony Diagram
najpierw, lecz większość analityków rozpoczyna
1.4.2 z procesami 1.4.2.1, 1.4.2.2 itd., albo
od sprawdzenia, czy wszystkie elementy DFD są
specyfikacja strukturalna musi zawierać specyfikację
zdefiniowane w słowniku danych procesu 1.4.2. Jeśli istnieją obie te rzeczy, model jest
niepotrzebnie (i niebezpiecznie) nadmiarowy
Równoważenie DFD ze specyfikacją Równoważenie DFD ze specyfikacją
procesu procesu
Wejścia i wyjścia muszą pasować
Z każdą specyfikacją procesu musi być związany
DFD pokazuje wchodzące i wychodzące
proces najniższego poziomu na DFD
przepływy dla każdego procesu, jak też
Ponieważ specyfikacje procesów wymagają wiele
połączenia z magazynami
pracy, wydaje się mało realne, aby w modelu
Powinno to być widoczne także w specyfikacji
znajdowały się "bezdomne" specyfikacje
procesu. Oczekujemy więc zdań CZYTAJ (WEy
,
procesów
POBIERZ lub innych podobnych czasowników)
Tak jednak może się zdarzyć wówczas, gdy
odpowiadających każdemu wchodzącemu
specyfikacja procesu była napisana dla wstępnej
przepływowi oraz ZAPISZ (lub WA
ÓŻ,
wersji DFD, a podczas jego ulepszania
WYŚWIETL itp.) dla każdego wychodzącego
wyeliminowano niektóre procesy z DFD
przepływu
Równoważenie specyfikacji procesów Równoważenie specyfikacji procesów
z DFD i słownikiem danych z DFD i słownikiem danych
pasuje do nazwy przepływu lub magazynu
Reguły równoważenia specyfikacji
danych połączonego z procesem
procesów z diagramem przepływu danych
opisywanym specyfikacją, lub
i słownikiem danych można opisać
jest terminem lokalnym, jawnie
następująco:
zdefiniowanym w specyfikacji procesu, lub
Każde odwołanie do danych w specyfikacji
występuje jako składnik w pozycji
procesu musi spełniać jedną z
słownika danych dla przepływu lub
następujących reguł:
magazynu danych połączonego z
procesem
Równoważenie specyfikacji procesów
Przykład
z DFD i słownikiem danych
Fragment specyfikacji procesu
Elementy danych X i Y pojawiają się w
SPECYFIKACJA PROCESU 3.5:
specyfikacji procesu pokazanej na poprzednim
OBLICZ WSPÓA
CZYNNIK G
slajdzie, ale nie występują jako dołączony
*P i Q S
LOKALNYMI TERMINAMI NA WYNIKI POŚREDNIE*
przepływ na DFD przedstawionym na rysunku
P = 3.14156 * X
& &
Jednak słownik danych, którego fragment
Q = 2.78128 * Y -13
ilustruje kolejny slajd, wskazuje, że X i Y są
& &
składnikami Z, a na rysunku widzimy, że Z jest
WSPÓA
CZYNNIK-G = P * Q + 2
rzeczywiście przepływem danych połączonym z
procesem, możemy więc stwierdzić, że model
OBLICZ
Z jest zrównoważony
Współczynnik G
WSPÓA
CZYNNIK
G
Równoważenie specyfikacji procesów
Równoważenie słownika danych
z DFD i słownikiem danych
z DFD i specyfikacjami procesów
Słownik danych jest spójny z resztą modelu, jeśli
Fragment słownika danych spełnia następującą regułę:
Do każdej pozycji ze słownika danych musi istnieć
X = * poziomy składnik czynnika frammis *
odwołanie ze specyfikacji procesu, DFD lub innej
* jednostki: centymetry; zakres: 0 - 100 *
pozycji słownika danych
Y = * pionowy składnik czynnika frammis *
Można wprawdzie argumentować, że słownik
* jednostki: centymetry; zakres: 0 - 10 *
danych powinien być budowany w taki sposób,
Z = * czynnik frammis, zdefiniowany przez
aby umożliwiał póz
niejsze rozszerzenia, tzn.
Dr. Frammisa * X + Y
zawierał elementy zbędne obecnie, lecz które
mogą być przydatne w przyszłości
Równoważenie ERD z DFD Równoważenie ERD z DFD
i specyfikacjami procesów i specyfikacjami procesów
Każdemu magazynowi na DFD musi odpowiadać
Diagram związków encji prezentuje
na ERD typ obiektu, związek lub ich kombinacja
całkiem inny punkt widzenia systemu niż
(tzn. asocjowany typ obiektu)
diagram przepływu danych
Jeśli na DFD występuje magazyn, który nie
pojawia się na ERD, to coś jest z
le; podobnie,
Występują jednak pewne związki, które
jeśli obiekt lub związek z ERD nie występuje na
muszą być zachowane, aby ogólny model
DFD
systemu był kompletny, poprawny i spójny
Nazwy obiektów na ERD i nazwy magazynów
danych na DFD muszą do siebie pasować
Równoważenie ERD z DFD
Równoważenie ERD z DFD
i specyfikacjami procesów
i specyfikacjami procesów
Pozycje słownika danych muszą mieć
zastosowanie zarówno do modelu DFD, jak i
Pozycje słownika danych w liczbie pojedynczej
ERD
(np. KLIENT) muszą opisywać znaczenie i
Dlatego pozycja słownika danych powinna
budowę pojedynczego egzemplarza ze zbioru
obejmować definicję obiektu na ERD i magazynu
obiektów używanego (w liczbie pojedynczej) na
na DFD
ERD i magazynu danych (w liczbie mnogiej) na
Oznacza to definicję słownikową następującej
postaci:
DFD
Pozycje słownika w liczbie mnogiej (np.
KLIENCI = {KLIENT}
KLIENCI) opisują znaczenie i budowę zbioru
KLIENT = nazwisko + adres + numer-telefonu +
egzemplarzy
...
Równoważenie ERD z DFD
Równoważenie ERD z DFD
i specyfikacjami procesów
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
Równoważenie ERD z DFD
i specyfikacjami procesów
i specyfikacjami procesów
Magazyn KLIENCI odpowiada obiektowi KLIENT
Jakiś proces powinien nadawać wartości
Coś musi tworzyć i usuwać egzemplarze klienta, czyli
pewien proces na DFD musi mieć przepływ
każdemu elementowi danych, będącemu
dołączony do magazynu KLIENCI
atrybutem egzemplarza każdego typu
Jednak aktualna czynność zapisu do magazynu (tzn.
obiektu, a jakiś proces powinien używać
tworzenia lub usuwania egzemplarza
(lub odczytywać) wartości każdego
odpowiadającego na ERD obiektowi KLIENT) musi
elementu danych
dokonywać się wewnątrz procesu, co oznacza, że
powinna być udokumentowana w specyfikacji tego
procesu
Równoważenie DFD z diagramem Równoważenie DFD z diagramem
sieci przejść sieci przejść
Każdy warunek na diagramie sieci przejść
Diagram stanów jest zrównoważony z
musi odpowiadać wchodzącemu
diagramem przepływu danych, jeśli są
przepływowi sterującemu procesu
spełnione następujące warunki:
kontrolnego związanego z tym
Każdy proces sterujący na DFD ma jako
diagramem. Podobnie każdemu
specyfikację diagram sieci przejść. Podobnie
wchodzącemu przepływowi sterującemu
każdy diagram sieci przejść w ogólnym
do procesu sterującego musi odpowiadać
modelu systemu musi być powiązany z
określony warunek na właściwym
procesem sterującym na DFD
diagramie sieci przejść
Równoważenie DFD z diagramem Równoważenie DFD z diagramem
sieci przejść sieci przejść
Ilustruje to rysunek
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ść