PSI (2B - Metodyka Strukturalna)

Projektowanie
systemw
informatycznych
Strukturalna metodyka TSI
Istota projektowania strukturalnego
Z metod projektowania systemw informatycznych obecnie najczciej
stosowanych w praktyce zdecydowanie wci wyrnia si metody oparte na
podejciu strukturalnym, chocia za nowoczeniejsze uwaa si podejcie obiektowe.
Istot metod projektowania strukturalnego jest upraszczanie zoonego

systemu poprzez systematyczne rozkadanie go na prostsze elementy skadowe
wraz z koncentracj uwagi na coraz drobniejszych szczegach, przy czym
okrela si w postaci strumieni informacyjnych relacje wice te wyrnione
elementy skadowe.
Metody projektowania strukturalnego przedstawiaj podejcie formalne

oparte na tworzeniu systemu caociowego, skadajcego si z wydzielonych
elementw podrzdnych, o hierarchicznej strukturze zstpujcej, powizanych
dobrze zdefiniowanymi moduami relacji i funkcji.
W projektowaniu strukturalnym zakada si naprzemienne etapy: analizy,
syntezy (projektowanie) i oceny (wdroenia testowe).
GK (ProjSI(2) - 2016) 2
Strukturalne podejcie do projektowania systemw wie si z
projektowaniem ukierunkowanym na cel:
GK (ProjSI(2) - 2016) 3
Podstawowe koncepcje projektowania strukturalnego:

zasada ucilania krokowego (faza analizy),
zasada modularyzacji (faza projektowania).
Obowizuj dwa zasadnicze kryteria:

kryterium spjnoci moduw (cohesion)- moduy musz
wsppracowa ze sob, nie mog by sprzeczne, musz
komplementarnie si uzupenia,
kryterium wizi midzymoduowych (coupling) - integrowanie
wynikw pracy innych moduw, wsppraca midzy moduami a
systemem.
GK (ProjSI(2) - 2016) 4
Najczciej wystpujce etapy modelowania i projektowania
strukturalnego:
1. Budowa modelu rodowiska:
definicja funkcji systemu,
identyfikacja otoczenia tworzonego systemu,
definicja komunikacji systemu z otoczeniem (przepyw danych,
zdarzenia),
budowa diagramu kontekstowego.
2. Budowa koncepcyjnego (konceptualnego) modelu systemu:
model funkcji,
model danych,
model zmian stanw systemu.
3. Budowa fizycznego modelu systemu.
GK (ProjSI(2) - 2016) 5
Metoda projektowania strukturalnego
DEFINICJA
W procesie projektowania
strukturalnego najczciej
ANALIZA stosuje si kaskadowy model
cyklu ycia systemu
informatycznego w rnych
PROJEKT odmianach. Jedn z czciej
wystpujcych odmian tego
modelu jest pokazana na
schemacie, ktra stanowi
BUDOWA DOKUMENTACJA podstaw metodyki CDM
(Custom Development
Method) firmy Oracle. Jest to
metodyka przystosowana do
WDROENIE stosowania narzdzi CASE
do wspomagania procesu
TSI.
EKSPLOATACJA
GK (ProjSI(2) - 2016) 6
Przyjta strukturalna metoda TSI obejmuje nastpujce fazy tworzenia
systemu:
Definicji,
Analizy,
Projektu,
Budowy,
Wdroenia,
Eksploatacji.
W ramach kadej z tych faz realizowanych jest z rnym nasileniem 11
nastpujcych procesw tworzenia systemu informatycznego:
Definicji wymaga,
Badania istniejcych systemw,
Architektury technicznej,
Projektu i budowy bazy danych,
Projektu i budowy moduw,
Konwersji danych,
Dokumentowania,
Testowania,
Szkolenia,
Wdroenia,
Asysty po wdroeniu.
GK (ProjSI(2) - 2016) 7
fazy tworzenia systemu
Charakterystyka faz tworzenia systemu informatycznego
Definicja
Celem fazy jest okrelenie funkcji zarzdzania najwyszego poziomu zarzdzania oraz
wymaga systemu informacyjnego, niezbdnych do ujcia w tworzonym systemie
informatycznym. Faza definicji koczy si okreleniem obszaru funkcjonalnego tworzonego
systemu informatycznego, ktry podlega akceptacji zarzdu organizacji i jest podstaw do
rozpoczcia fazy analizy.
Analiza
Celem fazy analizy jest sformuowanie szczegowych wymaga do systemu. S one
formuowane na podstawie badania obszaru organizacji, zdefiniowanego w fazie definicji.
Wyniki analizy przyjmuj form modeli funkcji, realizujcych je procesw i danych,
niezbdnych do tych realizacji. W fazie analizy jest take definiowana architektura techniczn
tworzonego systemu oraz zostaje opracowana strategia testowania, wdraania systemu i jego
powizania z systemami ju istniejcymi w organizacji.
GK (ProjSI(2) - 2016) 8
Projekt
Celem tej fazy jest przeksztacenie wymaga do systemu wytworzonych w fazie
analizy w postaci m.in. modeli funkcji, procesw oraz danych na elementy
konstrukcyjne systemu, biorc pod uwag architektur techniczn i dostpn
technologi.
Budowanie
Celem fazy budowy jest zakodowanie i przetestowanie oprogramowania uytkowego
systemu oraz implementacja jego i bazy danych wedug rozwiza przyjtych w fazie
projektu.
Wdroenie
Celem fazy wdroenia jest instalacja utworzonego systemu, przygotowanie personelu
uytkownika do korzystania z funkcjonalnoci systemu i administratora do
zarzdzania eksploatacj systemu. Wdraanie nie powinno generowa nowej
dokumentacji lub kodu, ale by faz, w ktrej istniejcy kod, dokumentacja i baza
danych s przygotowywane do uycia.
GK (ProjSI(2) - 2016) 9
Eksploatacja
Celem fazy jest wykonywanie przez suby administratora systemu nastpujcych
przedsiwzi:
dbanie o eksploatowanie systemu zgodnie z jego przeznaczeniem,
zapewnianie wymaganego poziomu bezpieczestwa gromadzonych,
przechowywanych, przetwarzanych i udostpnianych danych,
zapewnianie uytkownikowi pomocy w uytkowaniu systemu,
cige monitorowanie funkcjonowania systemu w celu uzyskanie odpowiedzi na
nastpujce zasadnicze pytania:
czy system jest sprawny, skuteczny i ekonomiczny,
czy zachodzi potrzeba usprawnienia funkcjonowania systemu, bd rozszerzenia
jego funkcjonalnoci i czy bdzie to uzasadnione organizacyjnie oraz
ekonomicznie.
Jeeli usprawnienie systemu bd rozszerzenie jego funkcjonalnoci okae si
konieczne i opacalne, administrator uczestniczy w przygotowaniu plan modernizacji
systemu, ktry moe uwzgldnia jako gwne dziaania:
usuwanie bdw (corrective maintenance, 18%),
dopasowania funkcjonalnoci systemu do zmieniajcych si warunkw jego
eksploatacji (adaptive maintenance, 20%),
rozszerzania funkcjonalnoci systemu (perfective maintenance, 32%).
GK (ProjSI(2) - 2016) 10
procesy tworzenia systemu
Charakterystyka procesw tworzenia systemu informatycznego
Definicja wymaga
Proces definicji wymaga identyfikuje potrzeby organizacji dotyczce tworzonego
systemu. Budowany jest model procesw organizacji, stanowicy wymagania
funkcjonalne do systemu. Model ten obejmuje wszystkie przewidziane do
informatyzacji procesy organizacji, zdarzenia je inicjujce i wyniki ich realizacji.
Jest on nastpnie uzupeniany o wymagania niefunkcjonalne m.in. takie, jak:
interfejs uytkownika, czas reakcji, bezpieczestwo danych etc.
Badanie istniejcych systemw

W wielu przypadkach klient da, aby tworzony system zastpi funkcjonalnoci ju
istniejcego i eksploatowanego systemu oraz/lub by w czci lub caoci
zaimplementowany w istniejcym ju u uytkownika rodowisku sprztowym i
programowym. Proces badania istniejcych systemw prowadzi do zidentyfikowania
tych potrzeb. Proces moe by pominity, jeli istnieje aktualna szczegowa
dokumentacja funkcjonalnych i technicznych istniejcych rozwiza
informatycznych.
GK (ProjSI(2) - 2016) 11
Architektura techniczna
Proces ten specyfikuje elementy technicznej podstawy tworzonego systemu. Proces jest
realizowany przy zaoe3niu, e uytkownik dysponuje docelow strategi technicznego
wyposaenia swojej organizacji i e elementy architektury okrelone w ramach omawianego
procesu s niesprzeczne z t strategi. Analitycy opracowuj wstpn techniczn architektur,
niezbdn dla funkcjonowania tworzonego systemu, ktra jest w miar przyrostu wiedzy o
szczegach systemu rozwijana w dwch kierunkach: okrelenia rodowiska programowego
(oprogramowanie systemowe) oraz architektury technicznej (sprzt i jego konfiguracja).
W ramach omawianego procesu formuuje si rwnie strategie zapewniania bezpieczestwa i
prowadzenia audytu systemu oraz interfejsu uytkownika. Jednym z istotnych celw tego
procesu jest okrelenie kocowej wielkoci systemu, ktra bdzie wykorzystywana do
aktualizacji oszacowa wielkoci prac projektowo-wdroeniowych i kosztu systemu oraz
terminu jego realizacji.
Projekt i budowa bazy danych

Proces obejmuje dziaania od opracowania projektu logicznej bazy danych na podstawie
modelu danych systemu (ERD) poprzez opis (skrypt) tej bazy w DDL, a do projektu fizycznej
bazy danych, uwzgldniajcego projektowane rozwizania w zakresie architektury systemu
(wyniki procesu Architektura techniczna).
GK (ProjSI(2) - 2016) 12
Projekt i budowa moduw
Proces ten jest jdrem omawianej metodyki. Projektanci wykorzystujc model przepywu
danych (procesw, DFD), model danych (ERD) i model hierarchii funkcji (FHD+FDD)
cznie z projektem architektury technicznej, tworz najpierw architektur moduw
oprogramowania uytkowego systemu, a nastpnie specyfikacj szczegw funkcjonalnych i
technicznych kadego moduu. Na podstawie tych specyfikacji programici tworz kod
poszczeglnych moduw, korzystajc np. z prototypw. Realizacja omawianego procesu moe
znaczco si rni w zalenoci od przyjtej przez projektanta strategii projektowania i
wykonania oprogramowania oraz od sposobu zarzdzania tym procesem. Inaczej bdzie
przebiega realizacja w przypadku, gdy zesp projektantw i programistw jest dostpny
fizycznie, a inaczej, gdy jest on tworem wirtualnym (komunikacja czonkw zespou tylko
poprzez np. Internet).
Konwersja danych
Celem procesu konwersji danych jest opracowanie strategii pozyskania danych niezbdnych do
testowania i do eksploatacji tworzonego systemu. Precyzyjnie s okrelane niezbdne dane oraz
miejsca ich aktualnego przechowywania (rda). Nastpnie s okrelane wymagania
dotyczce tradycyjnych (rcznych) i zautomatyzowanych metod pozyskiwania danych oraz
wymagane konwersje tych danych wraz ze wskazaniem metod i narzdzi ich realizacji (moe
zaj konieczno opracowania odrbnego oprogramowania konwersji danych).
GK (ProjSI(2) - 2016) 13
Dokumentowanie
Proces ten jest ukierunkowany na wytworzenie wysokiej jakoci caej tekstowej dokumentacji
uytkownika, technicznej i szkolenia. Szczeglne znaczenie ma dokumentacja zorientowana na
uytkownika, tj. Przewodnik Uytkownika i Referencja Uytkownika. Pierwszy dokument
stanowi przewodnik dla kadego typu uytkownika, w ktrym wskazuje si jak i w jakim
zakresie naley korzysta z tworzonego systemu dla realizacji procesw organizacji
uytkownika. Drugi dokument specyfikuje (dokadnie okrela) funkcjonalnoci kadego
moduu oprogramowania uytkowego systemu.
Testowanie
Proces ten jest zintegrowanym podejciem do testowania jakoci wszystkich elementw
tworzonego systemu. Zawiera w sobie testowanie indywidualne moduw oprogramowania
uytkowego oraz testowanie integracyjne wszystkich moduw tworzcych oprogramowanie.
Kocowym testem dopuszczajcym system do eksploatacji jest test akceptacyjny, weryfikujcy
funkcjonalnoci caego systemu.
Szkolenie
Celem procesu szkolenia jest przygotowanie przyszych uytkownikw i administratorw
systemu do wykonywania zada uruchamiania i eksploatacji systemu. Przeszkoleniem moe
by rwnie objty przyszy personel obsugi systemu i zesp testowania.
GK (ProjSI(2) - 2016) 14
Wdroenie
Proces wdraania systemu rozpoczyna si we wczesnej fazie projektu przez
definiowanie swoistych wymaga dotyczcych dopasowania organizacji do
funkcjonowania w warunkach eksploatacji tworzonego systemu. Realizacja tego
procesu obejmuje opracowanie planu przygotowania rodowiska uytkownika do
pracy z systemem, instalowania (implementowania) systemu oraz jego kalibrowania
(parametryzowania) dostosowujcego parametry systemu do wymaga organizacji.
Asysta po wdroeniu
Cztery cele procesu:
monitorowa prac systemu i pomaga rozwizywa przypadki wadliwego jego
funkcjonowania,
aktualizowa oprogramowanie uytkowe w celu eliminowania wykrytych bdw,
doskonali funkcjonalnoci systemu,
wspuczestniczy w planowaniu rozwoju systemu.
GK (ProjSI(2) - 2016) 15
podsumowanie
DEFINICJA ANALIZA PROJEKT BUDOWA WDROENIE EKSPLOATACJA Suma
Definicja wymaga 2,9% 5,6% 8%
Procentowy udzia Badanie

istniejcych 1% 1,6% 3%
poszczeglnych systemw
Architektura
procesw w Techniczna
0,3% 1,5% 0,3% 2%
realizacji faz Projekt i budowa

0,9% 0,4% 1%
bazy danych
Projekt i budowa
moduw
17,5% 19,8% 37%
Konwersja danych 0,4% 1,2% 1,8% 3,2% 0,7% 7%
Dokumentacja 0,1% 0,1% 2,2% 1,8% 4%
Testowanie 0,1% 1,8% 13,6% 0,8% 16%
Szkolenie 0,3% 0,4% 0,6% 0,6% 2%
Wdroenie 0,1% 0,1% 0,2% 0,5% 1%
Asysta po
wdroeniu
3,4% 3%
Zarzdzanie
projektem
0,8% 1,7% 4,1% 6,6% 0,4% 0,6% 14%
Suma 6% 12% 29% 46% 3% 4% 100%
GK (ProjSI(2) - 2016) 16
Narzdzia modelowania i projektowania
strukturalnego
Jzyk modelowania wykorzystywany w fazie analizy (w metodzie
Yourdona) jest jzykiem graficznym i obejmuje:
diagram hierarchii funkcji (function hierarchy diagram, FHD),
diagramw zalenoci funkcji (function dependency diagram - FDD),
diagramy przepywu danych (data flow diagrams, DFD),
diagramy zwizkw encji (entity relationship diagrams, ERD),
sownik danych (data dictionary, DD),
diagramy przej stanw (state-transition diagrams, STD),
diagram ycia obiektw (entity life history, ELH).
GK (ProjSI(2) - 2016) 17
Modelowanie funkcji
Cele modelowania funkcji:
opracowanie szczegowego modelu potrzeb informacyjnych uytkownika,
opracowanie takiego modelu, ktry byby niezaleny od metod realizacji SI.
Modelowanie funkcji mona stosowa na poziomie:
biznesowym,
systemowym,
oprogramowania.
Modelowanie funkcji na poziomie biznesowym suy opisaniu czym zajmuje si
organizacja. Tworzenie biznesowego modelu funkcji ma na celu opis potrzeb
funkcjonalnych organizacji jako podstawa do opracowania wymaga
dotyczcych informatyzacji, ktre mog przyj posta wymaga modernizacji
istniejcych w organizacji systemw lub tworzenia nowych systemw.
Biznesowy model funkcji stanowi wsplny jzyk dziki, ktremu uytkownicy,
analitycy i inynierowie systemowi (projektanci) mog uzgodni wymagania do
informatyzacji.
Modelowanie funkcji na poziomie systemowym suy opisaniu jakie funkcje
realizuje system. Modelowanie funkcji na poziomie oprogramowania suy
opisaniu jakie funkcje realizuj elementy oprogramowania systemu.
GK (ProjSI(2) - 2016) 18
Modelowanie funkcji
Modelowanie funkcji obejmuje okrelenie:
jakie dziaania wykonuje obiekt modelowania (organizacja, system, modu
oprogramowania zalenie od poziomu modelowania) (funkcje),
co powoduje rozpoczcie tych dziaa (zdarzenia),
na jakie znaczce rzeczy (encje) lub wasnoci tych rzeczy (atrybuty)
funkcje maj wpyw.
Metody modelowania funkcji :
hierarchia funkcji,
zaleno funkcji,
logika funkcji,
czas rzeczywisty.
Metoda Poziom modelowania
modelowania biznesowe systemowe oprogramowania
Hierarchia
podstawowa podstawowa podstawowa
funkcji
Zaleno
opcjonalna podstawowa opcjonalna
funkcji
Czas
podstawowa podstawowa
rzeczywisty
Logika
podstawowa podstawowa opcjonalna
funkcji
GK (ProjSI(2) - 2016) 19
Modelowanie funkcji - FHD
Tworzenie Diagram Hierarchii Funkcji (FHD) polega na opisie kadej funkcji
za pomoc prostego wyraenia, przy czym tworzone jest drzewo, w ktrym
funkcja-rodzic jest opisywana szczegowo przez funkcje-dzieci.
Zasady tworzenia FHD
kada funkcja na diagramie okrela, co system ma robi, a nie w jaki sposb,
funkcje tworz hierarchi - pierwsza funkcja oglna opisuje gwn funkcj
systemu, dzieli si nastpnie na funkcje bardziej szczegowe, dochodzc a do
funkcji elementarnych,
kada funkcja nadrzdna powinna cakowicie opisywa funkcje szczegowe oraz
wszystkie funkcje szczegowe musz opisywa funkcj nadrzdn,
do utworzenia hierarchii funkcji wykorzystuje si metody tzw. od ogu do szczegu
lub inaczej z gry na d (top-down),
do weryfikacji diagramu FHD wykorzystuje si metody tzw. od dou do gry lub
inaczej od szczegu do ogu (bottom-up),
kada funkcja powinna by opisana w jzyku naturalnym (nazwa funkcji i jej
przeznaczenie); bardziej szczegowy opis funkcji powstaje na etapie modelowania
logiki funkcji.
GK (ProjSI(2) - 2016) 20
Zasady graficznej notacji FHD
graficzny znak funkcji - prostokt (o ostrych lub zaokrglonych
rogach), proces - prostokt o citych rogach,
kada funkcja jest identyfikowana nazw (a nie skrtem); nazwa to
czasownik lub rzeczownik odczasownikowy,
kada funkcja powinna mie swoj etykiet (w lewym grnym rogu nad
graficznym znakiem funkcji),
FHD powinien mieci si na jednej kartce (jeli nie, to stawia
wielokropek, ktry oznacza rozwinicie funkcji w innym miejscu, na
nowej stronie).
Weryfikacja
Naley doprowadzi do tego, aby FHD by:
dokadny i spjny,
kompletny (obejmowa wszystkie funkcje przewidziane do ujcia),
atwy w modyfikacji,
zwizy i jednoznaczny w nazewnictwie,
czytelny.
GK (ProjSI(2) - 2016) 21
Graficzny obraz hierarchii funkcji (FHD):
Funkcja gwna (na samej grze)
Wszystkie funkcje
tego poziomu
hierarchii s
wystarczajce i
niezbdne i do
realizacji funkcji
bezporednio
nadrzdnej
Hierarchia moe by
dalej tworzona, a do
osignicia danego
poziomu
szczegowoci
GK (ProjSI(2) - 2016) 22
Diagram FHD tworz
funkcje nastpujcych
typw:
gwna (podstawowa, kolor
czerwony) - na szczycie
hierarchii, nie posiada
nadrzdnej, jest tylko jedna
na diagramie,
pena (kolor rowy) - ma
funkcj nadrzdn i
przynajmniej jedn
podrzdn,
atomowa (kolor zielony) -
dalej nie dekomponowana.
GK (ProjSI(2) - 2016) 23
Przykad dekompozycji funkcji Naprawa pojazdu
Naprawa pojazdu
Przyjcie pojazdu do warsztatu
Badanie pojazdu
Diagnozowanie usterki
Lokalizacja czci
Zlecenie naprawy innej firmie
Naprawa
Rejestracja kosztw Naprawa pojazdu wasnymi

siami
Przygotowanie pojazdu do oddania
GK (ProjSI(2) - 2016) 24
Przykad: Rezerwacja miejsc w samolocie
Zaoenia:
Podrny telefonuje do biura rezerwacji linii lotniczej AIF w celu
zarezerwowania miejsca.
Pracownik biura prosi o szczegy trasy.
Dowiaduje si, e podrny chce polecie z Warszawy do Tokio tak, aby
zdy na spotkanie w poniedziaek 12 listopada o godz. 10.30.
Pracownik wprowadza zapytanie do komputera i znajduje poczenia:
lot AIF 135 w Tokio w niedziel, 11 listopada o godz. 20.30,
lot AIF 250 w Tokio w niedziel, 11 listopada o godz. 21.00 z
midzyldowaniem w Irkucku.
Podrnemu odpowiada lot AIF 135.
Pracownik biura rezerwacji sprawdza czy s wolne miejsca.
AIF135 War 11.06. 08.00 Tokio 11.11 20.30.

AIF250 War11.06. 07.00 Tokio 11.11 21.00 m.ld.
GK (ProjSI(2) - 2016) 25
Przykad dekompozycji funkcji: Rezerwacja miejsc w samolocie (pierwsza
iteracja)
REZERWACJA
Rezerwowanie miejsc na loty dane

lub alternatywne, najlepiej pasujce do trasy podrnego
R1
Zebranie szczegw dotyczcych podry

(kierunek, numer lotu, czas odlotu i przylotu)
R2
Ustalenie lotw najlepiej speniajcych
wymagania pasaera
R3
Sprawdzenie dostpnoci miejsc na
wybranych lotach
GK (ProjSI(2) - 2016) 26
Przykad dekompozycji funkcji: Rezerwacja miejsc w samolocie (druga iteracja
uszczegowienie 1)
Zaoenia 2:
Na wybrany lot (AIF 135) w danej klasie busines miejsc nie ma.
S miejsca na lot z midzyldowaniem (AIF 250).
Podrny woli pierwsz moliwo.
Umieszczony zostaje na licie oczekujcych (rezerwowej) na lot AIF 135,
natomiast staa rezerwacja zostaje wykonana na lot AIF 250.
Pracownik biura rezerwacji wie ze sob oba zgoszenia, aby mc
przydzieli rezerwacj na lot AIF 250 komu innemu, jeli zwolni si
miejsce na licie oczekujcych lotu AIF 135.
Pracownik biura rezerwacji zbiera rwnie szczegowe wymagania
podrnego (rodzaj miejsca - dla palcych/dla niepalcych, rodzaj
posiku - wegetariaski/misny) i rezerwacja jest zakoczona.
Bilety zostan wysane na 2 tygodnie przed odlotem.
GK (ProjSI(2) - 2016) 27
uszczegowienie 1)
REZERWACJA
Rezerwowanie miejsc na loty dane
lub alternatywne, najlepiej pasujce do trasy podrnego
R1
Zebranie szczegw dotyczcych podry
(kierunek, numer lotu, czas odlotu i przylotu)
R2
wymagania pasaera
R3
Sprawdzenie dostpnoci miejsc na
wybranych lotach
R4
Rezerwacja miejsc (wstpna-umieszczenie na licie
oczekujcych i potwierdzenie), w razie koniecznoci
zapewnienia alternatywnej trasy, powizanie
rezerwacji na listach oczekujcych z rezerwacjami
wstpnymi i potwierdzonymi
R5
Przekazanie informacji i potwierdzenie szczegw
rezerwacji z podrnym
GK (ProjSI(2) - 2016) 28
Przykad dekompozycji funkcji: Rezerwacja miejsc w samolocie (druga
iteracja uszczegowienie 2)
R2
wymagania pasaera
R2.1
Okrelenie moliwoci lotw bezporednich
w dopuszczalnych granicach czasowych
R2.2
Okrelenie moliwoci alternatywnych pocze
(np. uwzgldnienie midzyldowania)
R2.3
Wybranie alternatywnych miejsc startu lub ldowania
w pobliu zgoszonych lotnisk
R2.4
Wybranie najlepszej trasy i okrelenie informacji

o locie (tj. numery lotw, czasy, szczegy
midzyldowania, itp.)
GK (ProjSI(2) - 2016) 29
uszczegowienie 2)
REZERWACJA
Rezerwowanie miejsc na loty dane lub alternatywne, najlepiej pasujce
do trasy podrnego
R1 Zebranie szczegw dotyczcych podry (kierunek, numer lotu, czas odlotu
i przylotu)
R2
Ustalenie lotw najlepiej speniajcych wymagania pasaera
R2.1
Okrelenie moliwoci lotw bezporednich w dopuszczalnych
granicach czasowych
R2.2
Okrelenie moliwoci alternatywnych pocze (np. uwzgldnienie
midzyldowania)
R2.3
Wybranie alternatywnych miejsc startu lub ldowania w pobliu
zgoszonych lotnisk
R2.4
Wybranie najlepszej trasy i okrelenie informacji o locie (tj. numery lotw,
R3 czasy, szczegy midzyldowania, itp.)
Sprawdzenie dostpnoci miejsc na wybranych lotach

R4
Rezerwacja miejsc (wstpna-umieszczenie na licie oczekujcych i potwierdzenie),
w razie koniecznoci zapewnienia alternatywnej trasy, powizanie rezerwacji
na listach oczekujcych z rezerwacjami wstpnymi i potwierdzonymi
R5
Przekazanie informacji i potwierdzenie szczegw rezerwacji z podrnym
GK (ProjSI(2) - 2016) 30
Przykad dekompozycji funkcji: Rezerwacja miejsc w samolocie (trzecia iteracja
uszczegowienie 3)
Zaoenia 3:
Pasaer przybywa do stanowiska odpraw, gdzie realizuje si przydzia
miejsca.
Posiada bilet potwierdzony, wic firma lotnicza wie, e liczba miejsc w
samolocie bdzie wystarczajca i naley przydzieli pasaerowi
okrelone, numerowane miejsce.
Pracownik stanowiska sprawdza zajto miejsc i widzi, e pasaer
zgosi ju swoje preferencje w wyborze miejsca.
Uzyskuje potwierdzenie przez sprawdzenie czy pasaer chciaby zaj
ustalone wczeniej miejsce.
Miejsce zostaje wybrane przez pasaera (zewntrzna dla niepalcych).
Pracownik stanowiska zauwaa rwnie odnotowane preferencje w
stosunku do posiku i potwierdza aktualno tego wymagania.
Nr miejsca: 33D
Nazwisko: J. Abacki
Klasa: busines
Preferencje: dla niepalcych
Rodz. posiku: dieta owocowa
Uwagi:
GK (ProjSI(2) - 2016) 31
Przykad dekompozycji funkcji: Rezerwacja miejsc w samolocie (trzecia iteracja
uszczegowienie 3)
A1
Przydzielenie pasaerowi miejsca speniajcego w miar
moliwoci zgoszone wymagania
A1.1
Sprawdzenie dostpnoci miejsca w klasie okrelonej
na rezerwacji, z uwzgldnieniem specjalnych
wymaga, np. miejsce dla palcych/niepalcych
A1.2
Okrelenie preferencji dotyczcych miejsca na podstawie
wczeniejszych zapisw lub uzyskanie informacji
bezporednio od pasaera, jeli istnieje wybr miejsc
A1.3
Wybranie wolnego miejsca najbardziej zgodnego
z wymogami pasaera
A1.4
Przydzielenie miejsca pasaerowi i poinformowanie
go o tym
GK (ProjSI(2) - 2016) 32
Rezerwowanie miejsc na loty, przydzielanie miejsc wedug
REZERWACJA numerw i przydzielanie kart wstpu na pokad
Rezerwowanie miejsc na loty dane lub alternatywne, A1 Przydzielenie pasaerowi miejsca speniajcego
najlepiej pasujce do trasy podrnego w miar moliwoci zgoszone wymagania
R1 R2 R3 R4 R5 Sprawdzenie
dostpnoci
A1.1
Zebranie Ustalenie lotw najlepiej Sprawdze- Rezerwacja miejsca w klasie
miejsc (wstpna- Przekazanie okrelonej na rezerwacji,
szczegw speniajcych wymagania nie informacji i z uwzgldnieniem
dotyczcych pasaera dostpno- umieszczenie na specjalnych wymaga,
licie oczekujcych potwierdzenie
podry ci
np. miejsce
szczegw dla palcych/niepalcych
R2.1
(kierunek, Okrelenie moliwoci miejsc na i potwierdzenie),

rezerwacji
numer lotu, lotw bezporednich wybranych w razie
z podrnym
A1.2
czas odlotu w dopuszczalnych
lotach koniecznoci Okrelenie preferencji
i przylotu) granicach czasowych zapewnienia dotyczcych miejsca
na podstawie
R2.2
alternatywnej trasy, wczeniejszych

Okrelenie moliwoci powizanie zapisw lub uzyskanie
alternatywnych pocze rezerwacji na informacji bezporednio
(np. uwzgldnienie listach od pasaera, jeli istnieje
midzyldowania) wybr miejsc
oczekujcych
A1.3
R2.3
z rezerwacjami Wybranie wolnego

Wybranie alternatywnych wstpnymi miejsca najbardziej
miejsc startu lub i potwierdzonymi zgodnego z wymogami
ldowania w pobliu pasaera
zgoszonych lotnisk
A1.4
Przykad dekompozycji
R2.4
Przydzielenie miejsca
Wybranie najlepszej trasy funkcji: Rezerwacja miejsc w pasaerowi
i okrelenie informacji i poinformowanie
o locie (tj. numery samolocie (cao) go o tym
lotw, czasy, szczegy
midzyldowania, itp.) GK (ProjSI(2) - 2016) 33
Modelowanie funkcji - FDD
Pomidzy funkcjami zachodz zwykle rnorodne zalenoci, ktrych nie
uwzgldnia FHD:
informacyjna (jedna funkcja dostarcza informacji niezbdnych dla
innej),
prawna (jedna funkcja musi si wykona przed drug)
polityczna (zalenoci okrelone przez kierownictwo, wytyczne; np.
pace).
Diagram zaleno funkcji (FDD) suy do obrazowania wzajemnych relacji
midzy funkcjami i zdarzeniami wywoujcymi powodujcymi rozpoczcie
realizacji kadej funkcji. Jest to przydatne przy modelowaniu przyczyn i
skutkw jakiego zdarzenia.
Zdarzenie wywoujce (wyzwalacz, trigger) jest obrazowane w postaci
szerokiej strzaki z wpisan w rodku nazw zdarzenia.
Rezultat kluczowy to wynik, ktry powinien zosta osignity przez
analizowany obiekt (np. przedsibiorstwo) po wystpieniu zdarzenia
wywoujcego i zrealizowaniu zaktywizowanych przez nie funkcji.
GK (ProjSI(2) - 2016) 34
Rozpoczcie wykonywania si kadej funkcji jest powodowane
wystpieniem (zaistnieniem) odpowiedniego zdarzenia, a wic wystpieniem
przyczyny wyzwalajcej wykonywanie si funkcji. Zdarzenia, o ktrych
mowa, grupuje si zwykle w nastpujce 4 (cztery) kategorie:
zdarzenia zewntrzne - zdarzenia na og losowe, na ktre organizacja
(przedsibiorstwo) nie ma bezporedniego wpywu (np. pogoda, strajki,
przybycie klienta),
zdarzenia zmiany - zdarzenia wywoujce funkcje, ktre powodujc
zmiany stanw organizacji powoduj jednoczenie wytwarzanie lub
usuwanie instancji (wystpie encji), zmian wartoci atrybutw lub
zwizkw midzy encjami,
zdarzenia systemowe - zdarzenia powstajce wewntrz organizacji,
zwizane zwykle z zakoczeniem wykonywania jednej lub kilku funkcji,
wzgldnie ze spenieniem okrelonego warunku,
zdarzenia w czasie rzeczywistym - zdarzenia wystpujce w okrelonym
terminie (np. w kady drugi poniedziaek o godz. 16.00, 25 listopada o
godz. 12.00).
Graficzna prezentacja Rezerwacja miejsca na lot
zdarzenia wywoujcego
GK (ProjSI(2) - 2016) 35
W diagramach zalenoci funkcji (FDD) stosowane s nastpujce notacje
graficzne
Oznaczenie Znaczenie
Funkcja (poziom systemu)
Zdarzenie wywoujce (wyzwalacz,

trigger) lub rezultat
Funkcja B moe by zrealizowana

dopiero po realizacji funkcji A (musi
A B
czeka na wyniki jej realizacji)
Alternatywny wynik realizacji

A funkcji
GK (ProjSI(2) - 2016) 36
Wyczno
Czasami funkcja moe powodowa wytworzenie kilku rnych rezultatw lub
zrealizowanie kilku rnych zalenoci, albo te jednego i drugiego. Jeli wynik jest
albo jedynym rezultatem, albo realizacj jednej zalenoci, na diagramie jest to
obrazowane za pomoc uku. Przykady:
W wyniku wykonania
a
W wyniku wykonania b
funkcji jedna z
funkcji powstan c zalenoci a lub b oraz
wszystkie rezultaty. d jedna z zalenoci d lub e
e i zaleno c zostan
zrealizowane.
W wyniku wykonania a
funkcji wszystkie W wyniku
zalenoci zostan b
wykonania funkcji
zrealizowane. c zostanie
zrealizowana
zaleno a albo
W wyniku wykonania zalenoci b i c.
funkcji zaleno
zostanie zrealizowana i
powstanie rezultat.
GK (PED(02) - 2011) 37
Przykad diagramu FDD dla funkcji Naprawa pojazdu
Przyjcie
Przyjazd Badanie Diagnozowanie
pojazdu
pojazdu
pojazdu usterki
do warsztatu
Zlecenie Naprawa
pojazdu
naprawy wasnymi
innej firmie siami
GK (ProjSI(2) - 2016) 38
Przykad diagramu FDD dla realizacji funkcji Rezerwacja miejsc na loty dane
Niezadowolony
Ustalenie wymaga, pasaer
ktre pasaer
moe zmieni
Zgoszenie
zapotrzebowania na
miejsce
Ustalenie lotw Sprawdzenie
Zebranie szczegw dostpnoci miejsc
dotyczcych podry najlepiej speniajcych
wymagania pasaera na wybranych
lotach
Rezerwacja miejsc
lub Rezerwacja
umieszczenie pasaera
na licie oczekujcych
Lista oczekujcych
GK (ProjSI(2) - 2016) 39
Weryfikacja diagramu FDD
W tym celu weryfikacji powinno si postpowa wedug kolejnych krokw:
Dla funkcji:
czy ta funkcja jest zawsze potrzebna do osignicia danych rezultatw?
jakie inne zdarzenie mogoby wywoywa te funkcj?
czy pokazane s tylko zdarzenia lub zalenoci potrzebne do wywoania tej
funkcji i czy niektre z nich mog by usunite jako niepotrzebne?
Dla kadej zalenoci:
czy ta zaleno musi by zawsze speniona zanim moe si rozpocz nastpna
funkcja?
czy funkcje na obu kocach zalenoci mog by kiedykolwiek wykonywane
rwnoczenie lub w innej kolejnoci?
czy po wykonaniu danej funkcji zaleno ta jest zawsze rozwizywana? Jeeli
nie, to powinien istnie uk z inn zalenoci lub rezultatem, wskazujcy na
wyczno.
Dla caego diagramu:
czy s pokazane wszystkie kluczowe rezultaty, czy ktrego brakuje?
czy kada ptla jest zakoczona?
czy s jakie inne zdarzenia, ktre mog powodowa tworzenie tych rezultatw
kluczowych?
GK (ProjSI(2) - 2016) 40
Modelowanie funkcji logika funkcji
Modelowanie logiki funkcji stosuje si do szczegowego i jednoznacznego opisu
czynnoci wykonywanych przez funkcje (algorytm realizacji funkcji). Okrela
ona krok po kroku stan procesu i moe by konstruowana poprzez specyfikacj
wymaganych rezultatw i warunkw ich osigania. Jest stosowana w przypadku,
gdy rozpatrywana funkcja jest zoona lub wymaga arbitralnego algorytmu.
Logika funkcji (algorytm jej realizacji) moe by przedstawiona w dowolnej
formie graficznej
Z logik funkcji zwizane s formularze opisu wymaga dla funkcji.
Zawieraj one:
nazw funkcji,
opis funkcji,
dane wejciowe,
rdo danych wejciowych,
wynik,
warunek wstpny dla funkcji,
warunek kocowy dla funkcji,
powd,
uwagi.
GK (ProjSI(2) - 2016) 41
Modelowanie funkcji logika funkcji
Przykad formularza opisu wymaga dla funkcji:
NAZWA FUNKCJI 2.1.1 Dopisywanie raportw z produkcji.
Funkcja pozwala wpisywa dzienn produkcj poszczeglnych wyrobw na

OPIS
podstawie Raportw z wykonania produkcji.
DANE WEJCIOWE Kartoteka wyrobw oraz Raport z wykonania produkcji.
Kartoteka wyrobw jest zbiorem zaoonym w systemie Techniczne

RDO DANYCH przygotowanie produkcji.
WEJCIOWYCH Raporty z wykonania produkcji dostarczane s z wydziaw produkcyjnych
przedsibiorstwa.
WYNIK Utworzenie Kartoteki wykonania produkcji.

Wczeniej naley utworzy Kartotek wyrobw w module Techniczne
WARUNEK WSTPNY
przygotowanie wyrobw.
Kartoteka wykonanie produkcji stanowi podstaw do oceny realizacji

WARUNEK KOCOWY
wykonania produkcji.
Funkcja umoliwia ewidencj wykonania produkcji, zmniejsza ilo

POWD
popenianych bdw podczas tej ewidencji.
Nie jest moliwe zarejestrowanie wykonania wyrobu, ktry nie jest wpisany do
UWAGI
Kartoteki wyrobw. Taka sytuacja moe by wynikiem bdu w kodzie wyrobu.
GK (ProjSI(2) - 2016) 42
Modelowanie przepywu danych DFD
Diagram przepywu danych (DFD) podstawowe narzdzie do o
prezentacji modelu strukturalnego systemu powstaego w wyniku
funkcjonalnej dekompozycji systemu na procesy. Diagramy przepywu
danych uporzdkowane s w hierarchi:
diagram kontekstowy,
diagram zerowy (systemowy),
procesy elementarne.
GK (ProjSI(2) - 2016) 43
Proces przetwarza (transformuje) dane wejciowe w wynikowe. Z punktu
widzenia DFD, procesy mog by zoonymi zestawami rnych elementarnych
funkcji, z ktrych pewne mog by realizowane rwnolegle, mog mie uboczne
efekty polegajce na zmianie niektrych danych lub stanw, oraz mog produkowa
zoone wyniki.
DFD specyfikuj wycznie podstawowe przeznaczenie lub funkcj procesu,
w postaci jego lakonicznej nazwy oraz (niekiedy) krtkiego opisu, natomiast nie
informuj o kolejnoci wykonywania procesw. Istotne jest, jakie dane wpywaj do
procesu i jakie s wytwarzane (produkowane) przez proces.
Diagram procesu pokazuje

tylko jego nazw, wejcie i
wyjcie
.
GK (ProjSI(2) - 2016) 44
Przepyw danych czy wyjcie jednego procesu z wejciem innego procesu
(kierunek strzaki) i przedstawia grup przesyanych danych. Moe take czy
proces (wejcie lub wyjcie) z terminatorem lub skadnic danych. Ta sama dana
moe by przesana do wielu procesw, interfejsw lub skadnic przy czym
niedopuszczalne s bezporednie przepywy danych pomidzy skadnicami lub
pomidzy skadnicami a terminatorami. Niekiedy zagregowana dana moe by
rozdzielona na kilka czci, z ktrych kada jest kierowana do innych procesw.
GK (ProjSI(2) - 2016) 45
Terminator (interfejs, aktor) to aktywny obiekt zewntrzny w stosunku do
systemu, ktry uruchamia DFD poprzez dostarczenie danych inicjujcych
dziaalno procesw przedstawionych na diagramie. Jest nim rwnie obiekt
zewntrzny, ktry wykorzystuje dane wytworzone przez procesy systemu. W
diagramach przepywu danych nie przedstawia si dowolnych, faktycznie
istniejcych zwizkw pomidzy terminatorami. Wszystkie dane wprowadzane od i
do terminatorw podlegaj przetwarzaniu w procesach.
Przykady terminatora: uytkownik programu, czujnik temperatury, sprzedawca,
bank, zarzd firmy.
DFD nie zajmuje si opisywaniem tego, w jaki sposb terminator generuje

dane wejciowe, ani te w jaki sposb wykorzystuje dostarczone mu dane wynikowe.
Terminator moe by zastpiony przez proces lub diagram dynamiczny, z

ewentualnym powoaniem bardziej elementarnych terminatorw komunikujcych si
z procesem zastpujcym terminatora.
GK (ProjSI(2) - 2016) 46
Skadnic danych (magazynem) jest pasywny obiekt, ktry suy jako nazwana
przechowalnia danych w postaci jednorodnych kolekcji i grup danych, ktre istniej z
zaoenia, lub ktre s porednikami w przepywie danych pomidzy poszczeglnymi
procesami. Skadnica nie ma charakteru kolejki lub stosu. Nie jest te aktywnym
obiektem, ktry wymusza przepyw danych. Skadnica danych moe zawiera wiele
obiektw rnego typu, przy czym w wikszoci przypadkw, opis tych obiektw
ogranicza si do lakonicznego okrelenia ich charakteru lub przeznaczenia.
DFD nie zajmuje si ani
organizacj skadnic danych,
ani te kolejnoci w jakiej
dane s wkadane lub
wyjmowane ze skadnicy.
Skadnica na DFD ma sens,
gdy przechowywane tam dane
su realizacji co najmniej
dwu procesw. Skadnice
danych bior udzia w
operacjach wyszukiwania,
wprowadzania, usuwania i
aktualizacji.
GK (ProjSI(2) - 2016) 47
Przepyw sterowania w diagramach DFD powinien wystpowa sporadycznie,
poniewa jest to funkcja diagramw dynamicznych (stanw). Przepyw sterowania
wyznacza zaleno czasow lub przyczynowo-skutkow pomidzy procesami
reprezentowanymi na DFD, co najczciej zaciemnia obraz pojciowy analizowanego
problemu.
Przepyw sterowania mona zaznaczy wtedy, gdy ta informacja jest wana
dla zrozumienia istoty analizowanego problemu.
GK (ProjSI(2) - 2016) 48
Zasady tworzenia i dekompozycji DFD:
1. Poziomy dekomponowania diagramw przepywu danych (DFD) i zasady
oznaczania procesw umoliwiaj opis systemu na rnych, wymaganych
wzgldami projektowymi, poziomach szczegowoci.
2. Ze wzgldu na zapewnienie czytelnoci diagramu DFD mona na nim
umieci nie wicej ni siedem procesw (zasada 72) oraz zwizanych z nimi
przepyww danych, skadnic i terminatorw.
3. Proces dekompozycji przebiega w ukadzie hierarchicznym, poczwszy od
najbardziej oglnego diagramu kontekstowego poprzez diagram poziomu
zerowego, a do specyfikacji procesw elementarnych (atomowych), dalej
niedekomponowanych. Okrelanie, ktre procesy naley uzna za atomowe
(elementarne) pozostaje w gestii projektanta systemu.
4. Jeden diagram DFD moe zawiera procesy o rnym stopniu
zdekomponowania.
5. Diagramy pozwalaj na opis systemw o rnym stopniu zoonoci. I tak:
- system prosty wymaga od 2 do 3 poziomw dekompozycji DFD,
- system rednio zoony wymaga od 3 do 5 poziomw dekompozycji DFD,
- system zoony wymaga powyej 5 poziomw dekompozycji DFD.
GK (ProjSI(2) - 2016) 49
6. Wszystkie kategorie wystpujce na poziomie hierarchicznie wyszym (o
mniejszej szczegowoci, o mniejszym zdekomponowaniu) musz by
pokazane na poziomie bezporednio bardziej szczegowym, rwnie w
postaci zdekomponowanej.
7. Nazwy kategorii w okrelonej hierarchii diagramw s unikalne.
8. Nie nadaje si nazw przepywom do i ze skadnicy danych .
9. Niedopuszczalne s przepywy midzy skadnicami i pomidzy
terminatorami.
10. Skadnica winna by uytkowana przez co najmniej dwa procesy.
11. Strzaka do skadnicy oznacza, e dokonuje si konkretnych zmian
(wprowadzanie, aktualizacja, usuwanie).
12. Strzaka ze skadnicy danych oznacza, e dane s czytane.
13. Diagram zawiera zarwno tradycyjne (rczne), jak i zautomatyzowane
procesy.
14. Pojedynczy diagram nie powinien by wikszy ni format A4.
GK (ProjSI(2) - 2016) 50
Zasady dekompozycji DFD i oznaczania (numerowania,

identyfikowania) hierarchicznie rozwijanych procesw:
GK (ProjSI(2) - 2016) 51
Poziomy dekompozycji diagramw DFD:
1. Diagram kontekstowy pokazuje
kontekst, w ktrym s wszystkie procesy,
wszystkie procesy jako jeden proces,
byty, ktre wymieniaj dane z procesami.
2. Diagram poziomu 0 pokazuje
gwne procesy, ktre pokrywaj cay biznes,
gwne magazyny.
przepyw danych.
3. Diagram poziomu 1, 2, 3, ... pokazuje
procesy wchodzce w skad kadego procesu wyszego poziomu (ale nie
musz opisywa kadego),
magazyny,
przepyw danych.
GK (ProjSI(2) - 2016) 52
Zalenoci midzy diagramami rnych poziomw:
GK (ProjSI(2) - 2016) 53
Diagram kontekstowy (context diagram, CD) definiuje zakres i granice systemu i
przedstawia powizania (interakcje) tworzonego systemu z jego otoczeniem, tj. kontekstem,
w ktrym system funkcjonuje. Diagram CD jest diagramem DFD, od ktrego rozpoczyna si
dekompozycj funkcjonaln systemu.
Podstawowe zasady tworzenia diagramu kontekstowego:
przedstawienie tworzonego systemu w postaci jednego procesu, a na jego obwodzie
przedstawia si terminatory i, w szczeglnych przypadkach zewntrzne skadnice danych,
powizane bezporednio przepywami danych. Ze wzgldw technicznych czsto znajduje
tu zastosowanie zasada kilkakrotnego umieszczania tych samych terminatorw,
ustalenie wsplnie z uytkownikami, zorientowanymi w specyfice dziedziny
przedmiotowej, listy podstawowych zdarze - zapyta (operacji wejciowych) i
zwizanych z nimi odpowiedzi (operacji wynikowych), ktre bd interpretowane jako
odpowiadajce im przepywy danych wice system z otoczeniem,
okrelenie rde i przeznaczenia danych - odpowiadaj im terminatory oraz zewntrzne
skadnice danych.
GK (ProjSI(2) - 2016) 54
Diagram poziomu zerowego (DFD 0)
1. Diagram zerowy wynika bezporednio z diagramu kontekstowego.
2. Decydujca jest tu dekompozycja jednego procesu z diagramu kontekstowego
na kilka procesw, ktre s agregatami dekomponowanymi dalej, a do
procesw elementarnych (atomowych).
3. Na poziomie zerowym wprowadza si wewntrzne skadnice danych oraz
przenosi terminatory z diagramu kontekstowego.
4. Procesy, skadnice danych oraz terminatory powizane s przepywami
danych z diagramu kontekstowego.
GK (ProjSI(2) - 2016) 55
Diagram poziomu 1 (DFD 1)
GK (ProjSI(2) - 2016) 56
Zasady weryfikacji diagramw DFD:
1. Kontrola stosowanych nazw poszczeglnych elementw DFD musz by
unikalne i semantycznie zwizane z opisywanym elementem.
2. Eliminowa tzw. czarne dziury, tj. procesy, ktre maj tylko same wejcia, a
nie maj wyj, np.:
3. Eliminowa tzw. procesy magiczne, tj. procesy, ktre maj tylko same
wyjcia, a nie maj wej, np.:
GK (ProjSI(2) - 2016) 57
4. Przeprowadzi bilans poziomy procesw, ktry polega na porwnaniu
zawartoci przepyww danych wychodzcych z procesu z zawartoci
przepyww danych do niego wchodzcych oraz regu przetwarzania,
okrelajcych, ktre dane z przepyww wchodzcych s pochaniane
bezpowrotnie przez proces, a ktre przez ten proces s przetwarzane w dane
wychodzce (dane nowe), np.:
GK (ProjSI(2) - 2016) 58
5. Przeprowadzi bilans poziomy magazynw, ktry polega na potwierdzeniu
przestrzegania zasady, e suma przepyww danych wchodzcych do
magazynu musi by rwna sumie przepyww danych z niego wychodzcych,
np.:
6. Przeprowadzi bilans pionowy procesw. Bilans ten powinien by

przeprowadzany dla kadego zdekomponowanego (uszczegowionego)
procesu i powinien obejmowa wszystkie przepywy danych zwizane z
dekomponowanym procesem (rodzicem) oraz z powstaymi z niego
procesami szczegowymi (potomkami). Zasada bilansu: suma przepyww
danych wchodzcych do procesu, ktre podlega dekompozycji musi by
rwna sumie wszystkich przepyww danych wychodzcych z jego
potomkw.
GK (ProjSI(2) - 2016) 59
DFD strukturalnej metodyki tworzenia systemw informatycznych
GK (ProjSI(2) - 2016) 60
przykad
Przykad
CD
GK (ProjSI(2) - 2016) 61
przykad
Przykad
DFD 0
(cz)
GK (ProjSI(2) - 2016) 62
przykad
Przykad
DFD 1
GK (ProjSI(2) - 2016) 63
przykad
Przykad
DFD 2
GK (ProjSI(2) - 2016) 64
przykad
Przykad
DFD 3
GK (ProjSI(2) - 2016) 65
Specyfikacja procesw jest wykonywana dla kadego najniszego procesu
ujtego w diagramie DFD. Jest ona szczegowym opisem regu dziaania podanych
przez uytkownika, ktre realizuje dany proces, tzn. definiuje co naley robi w celu
przeksztacenia danych wejciowych w wynikowe. Specyfikacja procesw musi
spenia dwa podstawowe wymagania:
musi mie tak posta, aby bya moliwa jej weryfikacja przez uytkownika i
analityka,
musi mie posta pozwalajca na efektywn komunikacj midzy
wspuczestnikami procesu tworzenia systemu informatycznego.
Narzdzia specyfikacji procesw mog by rne, ale jednakowe dla wszystkich
etapw projektu. Mog to by: strukturalny jzyk, warunki pocztkowe/kocowe,
tablice decyzyjne, diagramy blokowe, jzyk naturalny.
Przykad:
GK (ProjSI(2) - 2016) 66
Przykad specyfikacji procesu generowanie raportu stanu pojazdw:
DO
GET ID_pojazdu, kmPrzejechane, StanPojazdu, maxLiczbaPalet,
nrRejestracyjny FROM
TERMINATOR DYSPOZYTORNIA AS statystykiPojazdow
noweStatystyki = statystykiPojazdu
SAVE statystykiPojazdow TO STORE POJAZDY
WHILE dane wszystkich pojazdw zostan zaktualizowane
GET * FROM STORE POJAZDY AS aktualneDanePojazdow
formatuj aktualneDanePojazdow
SAVE aktualneDanePojazdow TO STORE RAPORTSTANUPOJAZDOW
GET * FROM STORE RAPORTSTANUPOJAZDOW AS danePojazdow
SEND danePojazdow TO TERMINATOR KIEROWNICTWO
GK (ProjSI(2) - 2016) 67
Modelowanie zwizkw encji ERD
Diagram zwizkw encji (ERD) jest to rodzaj graficznego

przedstawienia zwizkw pomidzy encjami uywany w projektowaniu
systemw informatycznych do przedstawienia konceptualnych modeli
danych wykorzystywanych w systemie.
Diagram pokazuje logiczne zwizki pomidzy rnymi encjami,
zwizki te maj dwie cechy:
opcjonalno, ktra mwi o tym, czy kada encja musi czy te moe
wystpi rwnoczenie z inn. Np. POJAZD musi by kierowany przez
OSOB, ktra jest kierowc, natomiast OSOBA nie musi, ale moe by
kierowc,
krotno (1:1, 1:N, M:N).
GK (ProjSI(2) - 2016) 68
Modelowanie zwizkw encji ERD
Przykad diagramu ERD:
GK (ProjSI(2) - 2016) 69
Sownik danych DD
Sownik danych (DD). Sownik jest repozytorium wszystkich terminw
(skadnikw modeli: wej, wyj, obiektw itd.) uywanych w projekcie, w
szczeglnoci zawiera definicje wszystkich atrybutw uytych w opisach typw
obiektw i relacji.
Notacja stosowana w zapisach sownika:
= - skada si,
+ - spjnik i,
() - jest opcjonalne, tzn. moe wystpi lub nie,
{} - iteracja (wielokrotne wystpienie elementu),
[] - alternatywa (wybr jednej z kilku opcji),
| - separator,
** - komentarz,
@ - identyfikator.
Przykady:
zamwienie = nazwa_klienta + adres_klienta + {towar}
pe = {MK}
pytanie_o_oferty = [nazwa_oferty, numer_oferty, towar] + [cena]
informacja_o_ofertach = id_oferty + nazwa_oferty + cena
GK (ProjSI(2) - 2016) 70
Sownik danych DD
Przykad sownika danych:
Faktura
-ID_faktury = @rok + miesiac + numerporzadkowy
rok = [2000-2100]
miesiac = [1-12]
numerporzadkowy = [0-9]
- ID_zlecenia
-dataWystawienia = rok + miesiac + dzien
rok = [2000-2100]
miesiac = [1-12]
dzien = [1-31]
-dataPlatnosci = rok + miesiac + dzien
rok = [2000-2100]
miesiac = [1-12]
dzien = [1-31]
- oplacono = [True | False]
- cenaZaKm = [{0-9} | . ]
GK (ProjSI(2) - 2016) 71
Modelowanie przej stanw - STD
Diagram przej stanw (STD) pokazuje zachowanie si systemu w czasie.
Przede wszystkim jest stosowany przy tworzeniu systemw czasu rzeczywistego, ale
ze wzgldu na swoj elastyczno moe te suy do prezentowania sposobu
realizacji funkcji systemu nie uwarunkowanego czasowo.
Stanem obiektu jest zestaw wszystkich wartoci atrybutw tego obiektu
oraz jego aktualnych powiza z innymi obiektami w danej chwili czasowej. Stan
obiektu trwa do momentu zajcia zdarzenia lub operacji, ktre zmienia stan na inny.
Przejcie midzy stanami zachodzi natychmiastowo po zaistnieniu
zdarzenia i nieskoczenie krtko (w ramach sensownego przyblienia) oraz moe
by uwarunkowane spenieniem dodatkowych warunkw.
Zdarzeniem jest co, co nastpuje w jednej chwili czasu (z punktu
widzenia naszej percepcji czasu) i warte jest analizowania z punktu widzenia celw
projektowanego systemu informatycznego. Samo zdarzenie nie trwa w czasie, ale
fakt zaistnienia zdarzenia jest zarejestrowany i trwa do momentu, gdy jaki podmiot
go skonsumuje. Mog wystpowa zdarzenia zewntrzne (zachodzce poza
systemem) i wewntrzne (majce rdo w systemie). W momencie zajcia zdarzenia
realizowana jest pewna czynno okrelana jako akcja.
GK (ProjSI(2) - 2016) 72
Modelowanie przej stanw - STD
Diagram przej stanw jest prezentowany w formie graficznej.

Wystpuje wiele rnych notacji. Jedna (stosunkowo czsto stosowana) jest oparta
na nastpujcym zestawie znakw graficznych:
Przykad diagramu STD

dla sklepu:
GK (ProjSI(2) - 2016) 73
Narzdzia modelowania i projektowania
strukturalnego - STD
Przykad innej notacji diagramu STD:
Notacja
Przykad diagramu
STD dla
bankomatu
GK (ProjSI(2) - 2016) 74
Modelowanie historii ycia obiektw ELH
Celem badania i modelowania historii ycia obiektw jest analiza
zakresu, przyczyn i rodzaju zmian, ktre mog zaj w danych przechowywanych
w systemie, Wyniki tej analizy s dokumentowane w postaci diagramw ELH.
Diagram ELH ukazuje zmiany stanu danych w czasie poprzez histori
ycia encji (patrz diagram ERD) w czasie eksploatacji systemu.
Diagram ELH tworzony jest dla kadej encji oddzielnie i przedstawia jej
losy od powstania a do usunicia z systemu.
Diagram ELH jest powizany z diagramami DFD i ERD w sposb
nastpujcy:
ERD opisuje statyczn struktur danych i relacji midzy nimi,
DFD opisuje drogi przepywu danych w systemie i do jego otoczenia,
ELH opisuje zmiany stanu encji w czasie ycia systemu.
GK (ProjSI(2) - 2016) 75
Diagramu ELH ma struktur drzewa, w ktrym wierzchoki s oznaczane
opisanymi wewntrz prostoktami. Korze drzewa oznacza modelowan encj, a pozostae
wierzchoki zdarzenia. Wierzchoek majcy dzieci (ojciec) nie reprezentuje zdarzenia, ale
zmian danych wywoan realizacj zdarze hierarchicznie mu podlegych jego dzieci.
Zdarzenia s syntetycznym opisem wszystkiego tego, co si zdarzyo w systemie
lub jego otoczeniu w czasie ycia systemu i co miao wpyw na zmiany stanu encji.
Zdarzenia zachodz w pewnych warunkach i mog si powtarza. Zdarzenia dotycz encji
opisanych w ERD. Wywouj one realizacj pewnych procesw, opisanych w DFD. W
wyniku realizacji tych procesw nastpuje aktualizacja, bd modyfikacja danych w
skadnicach (przepyw danych na DFD skierowany do skadnicy). Zatem diagram EHL
uzupenia diagramy DFD i ERD o informacj o zmianach danych w wyniku wystpienia
zdarze.
Diagram ELH (rysunek) jest interpretowany z gry do dou i zlewa na prawo: zdarzenia
zostan zrealizowane w kolejnoci A, B i C.
GK (ProjSI(2) - 2016) 76
Diagram EHL postaci
powinien by odczytywana w sposb nastpujcy: poniewa wze B nie

reprezentuje zdarzenia, wic owizujc sekwencj realizacji zdarze jest
sekwencja A, D, E i C.
Zatem obowizujc sekwencj zdarze interpretowan z diagramu EHL
jest sekwencja jego lici odczytywana z lewa na prawo.
GK (ProjSI(2) - 2016) 77
Konstrukcje zdarze wystpujce na diagramie EHL mog by trzech
nastpujcych typw:
sekwencji zdarze (zdarzenie A poprzedza zdarzenie B),
selekcji (alternatywy) zdarze (z kilku zdarze zachodzi tylko i tylko jedno) -
symbol O w prawym grnym rogu prostokta reprezentujcego zdarzenie,
iteracji zdarze (zdarzenie A moe nie zaj w ogle, noe si powtrzy 1 raz, 2
razy itd.) - symbol * w prawym grnym rogu prostokta reprezentujcego
zdarzenie.
Przykad selekcji zdarze:
GK (ProjSI(2) - 2016) 78
Przykad iteracji zdarze:
GK (ProjSI(2) - 2016) 79
Na tym samym poziomie hierarchicznym rozwinicia zdarze naley unika
mieszania typw zdarze. Przykad z wykorzystaniem tzw. zdarzenia
porzdkujcego (bez nastpstw realizacji):
GK (ProjSI(2) - 2016) 80
Przykad poprawnej i niepoprawnej konstrukcji diagramu EHL:
GK (ProjSI(2) - 2016) 81
GK (ProjSI(2) - 2016) 82
GK (ProjSI(2) - 2016) 83
Oprcz wymienionych typw konstrukcji zdarze dopuszcza si
zdarzenie puste, tzw. opcj zerow (null option, null event), oznaczane na diagramie
znakiem - zamiast nazwy. Zdarzenie to jest zawsze liciem. Realizacja tego
zdarzenia oznacza przejcie do kolejnego stadium ycia encji.
GK (ProjSI(2) - 2016) 84
Kada encja powinna mie zawsze dwa zdarzenia graniczne: powoujce
j do ycia i jej mier. W przestrzeni midzy tymi zdarzeniami jest modelowane
ycie encji. Przykad:
GK (ProjSI(2) - 2016) 85
Na diagramie EHL mog wystpi tzw. wskaniki statusu (status
indicators) pozwalajce ledzi prawidow kolejno (sekwencj) zdarze.
Wskaniki te w postaci n/m s umieszczane pod prostoktem oznaczajcym
zdarzenie. Przykad:
GK (ProjSI(2) - 2016) 86
Dane studenta pojawiaj si w bazie w momencie jego zapisania do szkoy i s aktualizowane
przy kadej zmianie. Usunicia danych studenta dokonuje si po piciu latach od
zaprzestania przez niego nauki w szkole.
Student, bdc ju zapisanym w szkole, moe zapisywa si do konkretnych grup i na zajcia
dodatkowe, korzysta z materiaw zgromadzonych w szkolnej bibliotece i wideotece oraz
zgosi si po wydanie zawiadczenia. Za przekraczanie terminw patnoci oraz ze
zachowanie studentowi udzielane s upomnienia.
Zakoczenie kursu moe nastpi po ukoczeniu przez studenta nauki na okrelonym
poziomie lub na skutek jego rezygnacji.
GK (ProjSI(2) - 2016) 87
Rwnowaenie modeli
Wszystkie modele musz do siebie pasowa:
GK (ProjSI(2) - 2016) 88
Podsumowanie podejcia strukturalnego
Niewystarczajco wspomagaj rozpoznawanie i modelowanie

niefunkcjonalnych wymaga systemowych.
S oglne, gdy zwykle nie zawieraj wskazwek pomagajcych
uytkownikom w podjciu decyzji, czy konkretna metoda jest
odpowiednia dla okrelonego problemu, czy nie.
Czsto nie obejmuj porad, jak przystosowa wybran metod
do ustalonego rodowiska.
Prowadz zwykle do utworzenia zbyt obszernej dokumentacji,
wic istota wymaga systemowych moe by ukryta w masie
zapisanych szczegw.
Opracowane modele s bardzo szczegowe i uytkownikom
trudno jest je zrozumie. Tacy uytkownicy nie mog
autentycznie sprawdzi realizmu tych modeli.
GK (ProjSI(2) - 2016) 89
GK (ProjSI(2) - 2016) 90

PSI (2B - Metodyka Strukturalna)

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

PSI (2B - Metodyka Strukturalna)

Uploaded by

Copyright:

Available Formats

Projektowanie

Istot metod projektowania strukturalnego jest upraszczanie zoonego

Metody projektowania strukturalnego przedstawiaj podejcie formalne

Podstawowe koncepcje projektowania strukturalnego:

Obowizuj dwa zasadnicze kryteria:

Badanie istniejcych systemw

Projekt i budowa bazy danych

Definicja wymaga 2,9% 5,6% 8%

Procentowy udzia Badanie

realizacji faz Projekt i budowa

Konwersja danych 0,4% 1,2% 1,8% 3,2% 0,7% 7%

Dokumentacja 0,1% 0,1% 2,2% 1,8% 4%

Testowanie 0,1% 1,8% 13,6% 0,8% 16%

Szkolenie 0,3% 0,4% 0,6% 0,6% 2%

Wdroenie 0,1% 0,1% 0,2% 0,5% 1%

Suma 6% 12% 29% 46% 3% 4% 100%

Przykad dekompozycji funkcji Naprawa pojazdu

Przyjcie pojazdu do warsztatu

Rejestracja kosztw Naprawa pojazdu wasnymi

Przygotowanie pojazdu do oddania

AIF135 War 11.06. 08.00 Tokio 11.11 20.30.

Rezerwowanie miejsc na loty dane

Zebranie szczegw dotyczcych podry

Wybranie najlepszej trasy i okrelenie informacji

Sprawdzenie dostpnoci miejsc na wybranych lotach

(kierunek, Okrelenie moliwoci miejsc na i potwierdzenie),

alternatywnej trasy, wczeniejszych

z rezerwacjami Wybranie wolnego

Funkcja (poziom systemu)

Zdarzenie wywoujce (wyzwalacz,

Funkcja B moe by zrealizowana

Alternatywny wynik realizacji

Funkcja pozwala wpisywa dzienn produkcj poszczeglnych wyrobw na

DANE WEJCIOWE Kartoteka wyrobw oraz Raport z wykonania produkcji.

Kartoteka wyrobw jest zbiorem zaoonym w systemie Techniczne

WYNIK Utworzenie Kartoteki wykonania produkcji.

Kartoteka wykonanie produkcji stanowi podstaw do oceny realizacji

Funkcja umoliwia ewidencj wykonania produkcji, zmniejsza ilo

Diagram procesu pokazuje

DFD nie zajmuje si opisywaniem tego, w jaki sposb terminator generuje

Terminator moe by zastpiony przez proces lub diagram dynamiczny, z

Zasady dekompozycji DFD i oznaczania (numerowania,

6. Przeprowadzi bilans pionowy procesw. Bilans ten powinien by

Diagram zwizkw encji (ERD) jest to rodzaj graficznego

Przykad diagramu ERD:

Diagram przej stanw jest prezentowany w formie graficznej.

Przykad diagramu STD

powinien by odczytywana w sposb nastpujcy: poniewa wze B nie

Niewystarczajco wspomagaj rozpoznawanie i modelowanie

You might also like