Projektowanie Systemów Informatycznych
Mgr Inż. Irena Fila
UML - Unified Modeling Language
Obecne standardy modelowania obiektowego - UML 1.5 lub 2.0(nie wiadomo czy został już wprowadzony).
System Informacyjny <> System Informatyczny
Informatyka - to dziedzina wiedzy o ruchu i przetwarzaniu informacji.
Informacja - zinterpretowane dane, fakty.
System Informacyjny - usystematyzowana i uporządkowana sieć powiązań informacyjnych między takimi elementami jak człowiek, dane(zinterpretowane dane), metody(sposób łączenia) oraz urządzenia do zbierania, przesyłania oraz przetwarzania informacji mających na celu zaspokojenie potrzeb informacyjnych zainteresowanych ogniw.
Podstawowymi funkcjami Systemu Informacyjnego są:
gromadzenie informacji,
opracowywanie informacji,
przechowywanie informacji,
przetwarzanie i wyszukiwanie informacji,
udostępnianie informacji.
System informacyjny musi te funkcję spełniać aby być systemem informacyjnym !!!
W projektowaniu Systemów Informatycznych bardzo ważną rolę odgrywają założenia początkowe.
Podstawowa cecha systemu informacyjnego to hierarchiczna (modułowa ) budowa
Konstruując system informatyczny musimy pamiętać aby miał budowę hierarchiczną i modułową. Po co ??
aby był łatwiejszy w projektowaniu
kolejne moduły podsystemu powinny być luźno ze sobą powiązane - nie mogą być całkowicie zależne od siebie
Metoda - sposób wykonania czegoś, system procedur w celu wykonania czegoś, powtarzalność, uporządkowanie czynności
Metodyka - zespół metod którymi się posługujemy ( pojęcie szersze niż metoda ). Zbiór powiązanych ze sobą metod opartych na pewnych wspólnych podstawach. Metodykę postępowania dostosowujemy do zadania
Metodyka projektowa Systemu Informatycznego:
opisuje, uwzględnia wszystkie kolejne fazy od powstania Systemu Informatycznego aż do jego wycofania,
jest to zbiór powiązanych ze sobą metod opartych na wspólnych podstawach.
Metoda projektowa Systemu Informatycznego - uporządkowanie czynności - obejmuje fragment życia SI.
Metoda i metodyki dotyczą cyklu życia systemu informatycznego ( czyli to wszystko co dzieje się z systemem informatycznym od momentu jego powstania (pomysłu) aż do jego śmierci ( wycofania ) )
Technika projektowa Systemu Informatycznego - Specyficzne podejście do tworzonego produktu przy opracowywaniu SI.
Metodyki
Strukturalna
osobne modelowanie funkcji i zadań - elementy aktywne (to co system wykonuje )
osobne modelowanie struktur danych
potem łączenie tych dwój rzeczy
Obiektowa
tożsamość, stan i zachowanie ( to są trzy stany obiektu )
Szkolenie pracowników odbywa się podczas m.in. projektowania i testowania
Model logiczny - odpowiada na pytanie co system ma robić - bez odwoływania się do rozwiązań implementacyjnych
Model fizyczny - w jaki sposób ma zostać zrealizowany powyższy model
Model liniowy - cykl życia Systemu Informatycznego(powyższy rysunek).
CASE:
Computer Assistent - Aide Software - System Engineering
WYKŁAD II (23.02.05)
Testowanie
- weryfikacja systemu (czy system testowany spełnia wszystkie założenia systemu)
- walidacja (ocena systemu przez użytkownika końcowego)
Wady modelu liniowego:
- długa przerwa w kontaktach użytkownik - projektant wynikająca z tego że użytkownik ma
kontakt z projektantem w fazie określania wymagań a potem widzi już gotowy produkt
- zakłada się że wymagania które ustalamy w fazie określania wymagań są stałe, ustalone
i niezmienne
Zauważono ogromny wpływ na jakość zaprojektowanego systemu ustaleń początkowych (podczas określania wymagań)
1. Jakie są źródła błędów w poszczególnych fazach projektowania SI.
2. Model z prototypem - model cyklu życia SI
Zgodnie z definicją R. Barker'a - prototypowanie jest metodą szybkiej prezentacji pojęć, w celu uzyskania akceptacji użytkownika i sprawdzenie wykonywalności.
Model z prototypem jest polecany kiedy istnieją trudności ze sformułowaniem wymagań użytkownika do końcowego projektu.
Tworzenie prototypu ma na celu przede wszystkim doprecyzowanie tych założeń użyt. które są trudne do założenia.
Zalety modelu z prototypem |
Wady modelu z prototypem |
1. Minimalizacja ryzyka związanego z niemożnością określenia wymagań przez użytkownika
2. Szybka demonstracja użytkownikowi działającej wersji systemu (wersja beta)
3. Szybkie wykrycie nieporozumień pomiędzy użytkownikiem a projektantem, które mogłyby powstać w fazie określania wymagań.
4. Możliwość wykrycia brakujących funkcji systemu lub trudnych usług.
5. Redukcja czasu oczekiwania na kolejne etapy.
6. Stały kontakt pomiędzy użytkownikiem a projektantem. |
1. Dodatkowe koszty budowania prototypu.
2. Długie oczekiwanie na ostateczny etap. |
Istnieją dwa rodzaje narzędzi:
RAD - Rapid Application Development
CASE - Computer Assisted/Aided Software/System Engineering
2 ISTNIEJĄ DWA RODZAJE PROTOTYPOWANIA
1. SZYBKIE PROTOTYPOWANIE
2. PROTOTYPOWANIE STRUKTURALNE
Ad. 1)
Jest tu sprzężenie zwrotne - modyfikacja wymagań według wskazówek użytkownika
Ad. 2)
W prototypowaniu strukturalnym tworzony jest tylko i wyłącznie w celu bardziej precyzyjnego sformułowania wymagań przez użytkownika (stosować w przypadku złożonych systemów)
MODEL SPIRALNY
Kalkulacja kosztów
1987 Barry Boehm
Kolejna wersja systemu Informatycznego
Model spiralny opisuje cykl życia SI w kolejnych wersjach.
Według Andrzeja Kaczora
METODYKI PROJEKTOWANIA SYSTEMU INFORMATYCZNEGO
Techniczne podejście Podejście społeczne
Strukturalne podejście ( lata 60 ) obiektowe podejście (lata 80)
Obiekt - pojęcie wyjściowe. Ma
tożsamość, rozróżnialny byt, stan w danej
chwili i posiada zachowanie (w obiekcie
elementy aktywne elementy bierne jest aktywność
czyli procesy czyli dane
Osobno projektowane
elementy aktywne
i elementy bierne
a potem następuje
ich złożenie
Podejście strukturalne
Równoważenie
Powstaje spójna klasyczna analiza współczesna analiza
i niesprzeczna całość strukturalna strukturalna
(De Marco) (Edward Yourdon)
Według Przemysława Kubisy
1997 UML - Rambaugh, Booch, Jacobson
WYKŁAD III
Istotą projektu strukturalnego jest osobne modelowanie struktur danych, osobne modelowanie procesów oraz mechanizmy równoważenia ( a jak się to w szczegółach dzieje to zależy od narzędzia CASE'owego )
DeMarco - twórca klasycznej analizy strukturalnej
TOP - DOWN - „od ogółu do szczegółu” rozbijanie problemu na mniejsze
Problem ogólny, bardzo złożony musimy podzielić na problemy mniejsze, prostsze do rozwiązania(Diykstry).
Podział systemu informatycznego na podsystemy, na procesy potomne => dekompozycja systemowa.
7 kroków metodyki DeMarco:
zbudowanie modelu fizycznego istniejącego systemu informacyjnego(opis systemu informacyjnego)
Stworzenie modelu logicznego systemu informacyjnego
zbudowanie modelu logicznego docelowego systemu
zbudowanie modelu fizycznego docelowego systemu
szacowanie kosztów dla zaprezentowanych modeli z punktu 4
wybór odpowiednich właściwości modelu
specyfikacja systemu uwzględniająca podział całości na podsystemy
Wady:
powód - analiza sytuacji w celu stworzenia modelu ( niechęć do ujawniania niektórych mechanizmów firmy a analityk drąży jak najgłębiej aby ocenić sytuację jak najlepiej
sztywno narzucona technika TOP - DOWN, trudności podziału na mniejsze problemy tego jednego wielkiego problemu
E. Yourdan
Metodyka Yourdana - zwana współczesną analizą strukturalną
oderwanie się od systemu aktualnie działającego i tworzenie założeń dla nowego systemu ( patrzenie na system jak na system który ma powstać a nie na system który istnieje)
zdefiniowanie podstawowej listy funkcji ( nie wiążemy się z istniejącym systemem tylko definiujemy wymagania funkcjonalne nowo tworzonego systemu w przyszłości )
metoda TOP - DOWN
Funkcje można wyliczyć na podstawie zdarzeń zachodzących w systemie oraz na które system reaguje.
Metodyka Yourdana
Model środowiskowy stanowi idealny model wymagań systemu.
musi być krótki opis celu działania systemu,
lista zdarzeń, które pobudzają system do działania,
wyznaczona granica systemu (wewnątrz granicy jest system a na zewnątrz użytkownicy czyli obiekty zewnętrzne )
Diagram kontekstowy
Diagram przepływu danych na poziomie kontekstowym - jest to kolejny element modelu środowiskowego
Strzałki - przepływ danych ( strzałki muszą przecinać granice systemu )
Kółko w środku - proces o numerze 0, proces najbardziej złożony, reprezentuje cały system
(dla całego systemu informatycznego jest tylko jeden taki proces )
Wymagania funkcjonalne systemu przedstawiamy za pomocą diagramu przepływu danych i najbardziej ogólne wymagania funkcjonalne przedstawiamy na za pomocą diagramu kontekstowego.
Zawartość słownika dotyczących danych elementarnych ( atrybutów zawartych w we/wy ) związanych z przepływem we/wy.
Podmodel zachowań - opisuje wewnętrzną architekturę projektu systemu informatycznego zarówno pod względem składników statycznych i składników dynamicznych.
Aby stworzyć pełny podmodel zachowań wykorzystujemy różne techniki, a te techniki to działania opisujące interesujący nas system.
W podejściu Yourdanowskim zbiór diagramów DFD tworzony jest techniką mieszaną.
Diagram DFD pokazuje hierarchię funkcji, powstaje drzewo funkcji.
ERD diagram - (statyczny model struktur danych) na tym diagramie nie ma uwarunkowań czasowych ( dlatego statyczny, opisuje bierne elementy).
Zbiór diagramów DFD - zbiór diagramów przepływu danych. Uzyskamy w wyniku kroków dekompozycji diagramu kontekstowego DFD na którym był tylko jeden proces
( kolejne poziomy potomne DFD w stosunku do diagramu kontekstowego )
Statyczne diagramy: ERD, DFD(Data Flow Diagram)
Dynamiczne diagramy: ELH(Entity Life History - Diagram życia encji), STD(State Transition Diagram - diagram przejść stanów)
WYKŁAD IV
Podstawowe pytania związane z Systemem Informatycznym niezależnie od metodyki:
określenie wymagań użytkownika
statyczne struktury danych
- elementy bierne
aspekty dynamiczne systemu ( zamiany systemu w czasie, reakcja elementów na zdarzenia w systemie
- oddziaływają na system i wymuszają zmianę stanu w czasie
Te dwa pojęcia są równoważne: Zadanie Systemu = Funkcja Systemu
Zadania wykonywane przez System = Funkcje wykonywane przez System
Lista Funkcji wymaganych przez System = wymagania Funkcjonale Systemu
Te zadania modelowane są za pomocą procesu :
Zadanie = Funkcja = Proces
Oznaczenie Procesu:
nazwa lub nr nazwa (procesu)
nr
To oznaczenie
W metodyce Yourdona
Lista zdarzeń budowana w ramach modelu środowiskowego stanowi punkt wyjścia do rozpoczęcia budowy diagramu przepływu danych (DFD - Data Flow Diagram)
Można go budować od dowolnego poziomu w całej hierarchii danych
Zbiór diagramów przepływu danych uzyskamy poprzez Dekompozycję .
Lista Zdarzeń Funkcje (Zadania)
1. 1.
2. Kolejne 2. Funkcje które System wykonuje
3. zdarzenia 3. aby obsłużyć dane Zadanie
4. 4. (hierarchiczna zależność)
Funkcje układamy w drzewo funkcji w którym można powiedzieć o najbardziej złożonej funkcji
PRZYKŁADOWA LISTA ZDARZEŃ DLA SYSTEMU BIBLIOTECZNEGO
Zdarzenia zachodzące w Systemie Funkcje
1.Zgłoszenie osoby po raz pierwszy 1. Obsługa nowego użytkownika
zapisującej się do biblioteki 1.1. Pobranie danych nowego użytkownika
1.2. Dodanie rekordu czytelnika do bazy
czytelników
1.3. Wygenerowanie karty czytelnika
2.Zgłoszenie w celu wypożyczenia 2. Obsługa wypożyczenia
książki 2.1. Sprawdzenie stanu książki
2.2. Sprawdzenie konta użytkownika
2.3. Sprawdzenie ewentualnych opłat
2.4. Właściwa transakcja wypożyczenia
3.Zwrot książki 3. Obsługa zwrotu książki
3.1. Sprawdzenie terminu zwrotu i ewentualne
naliczenie kary
3.2. Właściwa transakcja zwrotu książki poprzez
aktualizację konta użytkownika oraz
aktualizację stanu książki w bazie danych
DRZEWNO PROCESÓW (FUNKCJI)
0 - System Informatyczny - BIBLIOTEKA
1 - Obsługa nowego czytelnika
- Pobranie danych nowego użytkownika
- Dodanie rekordu czytelnika do bazy danych
- Wygenerowanie karty czytelnika
2 - Obsługa wypożyczenia
2.1 - Sprawdzenie stanu książki
2.2 - Sprawdzenie konta użytkownika
2.3 - Sprawdzenie ewentualnych opłat
2.4 - Właściwa transakcja wypożyczania
3 - Obsługa zwrotu książki
3.1 - Sprawdzenie terminu i ewentualne naliczenie kary
3.2 - Właściwa transakcja zwrotu oraz aktualizacja bazy i konta danego użytkownika
3.3 - Zwrot ewentualnej kaucji wcześniej zapłaconej
3.4 - Obsługa sytuacji nadzwyczajnej
Tu widać hierarchię funkcji .
To drzewo procesów jest w modelu zachowań ( modelu który pokazuje wewnętrzną strukturę)
DIAGRAM KONTEKSTOWY - pokazuje system informatyczny jako jeden proces ( czyli poziom 0 - system informatyczny BIBLIOTEKA )
9 b
Czytelnik Czytelnik
8
11
7
BIBLIOTEKA
Proces 0
4 5
3 2
6
Czytelnik
1
Pracownik (bibliotekarz)
1. Transakcja zwrotu
2. Transakcja wypożyczenia
3. Akceptacja danych nowego czytelnika i wpis do bazy czytelników
4. Dane nowego czytelnika
5. Zapłata kaucji
6. Wygenerowanie nowego konta użytkownika
7. Identyfikator czytelnika, identyfikator książki
8. Wydanie książki
9. Informacja o niemożliwości wypożyczenia książki
10. Zwrot książki
11. Informacje o stanie konta
0 - jest to proces główny ( reszta jest w środku, nie widzimy tego ponieważ patrzymy
z punktu widzenia użytkownika czyli jako obiekty zewnętrzne.)
0 - proces
- obiekt zewnętrzny
- przepływ danych
- synonim obiektu
Proces jest to graficzna reprezentacja funkcji systemowej, może mieć charakter procesu złożonego lub elementarnego ( na diagramie kontekstowym ten jeden jedyny proces jest zawsze złożony ).
Proces złożony - proces który ma podprocesy ( procesy potomnie generowane )
Proces elementarny - proces nie posiadający procesów potomnych ( nie posiada
podprocesów ). jest to proces najniższego poziomu
Obiekty zewnętrzne - uogólniony użytkownik systemu informatycznego występujący wobec systemu w określonej roli. Obiektem zewnętrznym może być inny system informatyczny współpracujący z naszym. Mogą być też obiektami jakieś zewnętrzne bazy danych do których mamy dostęp.
Przepływ danych - strumień informacji między obiektami zewnętrznymi a jednym jedynym procesem ( , , - takie strzałkowanie / operacje wejścia/wyjścia )
Strumień danych składa się z atrybutów
Zdarzenia powodują przepływ danych
Zdarzenie zewnętrzne - czytelnik zapisujący się
Zdarzenie wewnętrzne - generowanie karty czytelnika
Diagram kontekstowy, który jest zbudowany z punktu widzenia użytkowników zewnętrznych pokazuje przepływ we/wy w wyniku zdarzeń. Przepływ we/wy zawiera niezbędne dane przekazywane do systemu lub z systemu do otoczenia. W celu prawidłowej realizacji funkcji systemowych obsługujących zdarzenia wymienione w liście zdarzeń zatem diagram kontekstowy jest graficzną prezentacją wymagań funkcjonalnych systemu projektowanego metodami strukturalnymi
DFD powstaje w wyniku działań techniki w celu budowania kontekstowych diagramów.
ZASADA DEKOMPOZYCJI
y
x z
Obiekt 1 1 2
w
Obiekt 2
- magazyn danych ( składnica danych )
Delete, Update, Create
- przepływ aktualizujący dane. Może dopisywać nowy element do
magazynu, nowy obiekt. Modyfikować zawartość obiektu, modyfikowanie
cech obiektu i usuwać dane z magazynu
czytanie danych z magazynu
tylko przepływ aktualizujący może cokolwiek zmieniać w magazynie danych.
Dokonujemy Dekompozycji nr. 1
Generuje diagram potomny względem procesu 1
Zasada tworzenia diagramu DFD potomnego. Do procesu 1 bierzemy wszystkie przepływy wychodzące i wchodzące do prcesu
Obiekt 1 x
w
z Obiekt 2
2
Tworzenie potomnego DFD odbywa się zgodnie z zasadą bilansu pionowego procesu.
Bilans pionowy mówi: wszystkie przepływy we/wy z procesu macierzystego są przenoszone do procesu potomnego.
Teraz generujemy podprocesy i do nich podłączamy przepływy
Magazyn x
1.1
Obiekt 1 x
1.2 magazyn y
w
obiekt 2
z
2
Na diagramie muszą powstać co najmniej dwa procesy
Procesy muszą być zbilansowane w pionie. Mają być zbilansowane pomiędzy kolejnymi diagramami DFD.
Bilans pionowy - mówi nam że zawartość wszystkich danych w przepływach danych we/wy procesu macierzystego musi być taka sama jak zawartość przepływów we lub wy, które są zaznaczone dla procesów potomnych uzyskanych w wyniku dekompozycji procesu macierzystego. Sprawdzenie jest na poziomie danych elementarnych a informacja o tym czerpiemy ze słownika dołączonego do narzędzia CASE'owego którym wykonujemy dekompozycję
Tylko element aktywny potrafi coś zmieniać w systemie. Proces pobiera i wysyła informacje z zewnętrz i od wewnątrz. Tak samo zmienia zawartość magazynu
Obiekt zewnętrzny może łączyć się tylko przepływem danych z procesem lub do procesu ( czyli obiekt łączy się z danymi które są przesyłane poprzez wywołanie np.
procesu wysyłania )
Bilans poziomy procesu - wszystkie dane wchodzące do procesu muszą być równie danym wychodzącym z procesu z uwzględnieniem jakiegoś algorytmu w procesie 0 który te dane zmienia ( może ale nie musi )
Bilans poziomy magazynu danych.
a b
a + b = c + d
d c
WYKŁAD V
Uwagi dotyczące modelu zachowań ( model Yourdona )
wymagania funkcjonalne
statyczne struktury danych ( diagram ERD, konceptualny CDM )
Dynamika Systemu
Diagram historii życia encji (ELH) Diagram przejść stanów
(jak w czasie zmienia się każda z encji (opisuje zmianę w czasie)
występująca w modelu logicznym)
Istnieją 4 diagramy:
DFD
CDM + PDM
ELH
STD
Uwagi na temat DFD:
w metodyce Yourdona nie jest wymagana metoda „TOP - DOWN” (budowa DFD od dowolnego poziomu jako odpowiedź tego poziomu na listę zdarzeń)
generowanie kompletnego zbioru DFD techniką mieszaną - ta technika umożliwia:
1) zgrupowanie podobnych procesów w agregaty będące procesami nadrzędnymi
2) to chyba chodzi o ten rysunek
agregacja z
1.1
y x y
1.2
1.1.1
x
1.1.3
z
grupowanie procesów - sposób - reguła Mullera - nie więcej obiektów niż 7
(od 5 do 9 ) na jednym poziomie. To samo z magazynami danych i obiektami. Gdy się nie da tej liczby Mullera zastosować to robimy wielopoziomową dekompozycję
specyfikacja procesu:
złożony: jest drzewo procesów potomnych.
elementarny: jest to podanie w sposób słowny algorytmu realizowanego wewnątrz
procesu elementarnego
Cały czas równocześnie z budowanymi poziomami uzupełniamy słownik danych. Pojawiają się nowe składniki danych, procesy, przepływy.
Robimy specyfikację procesów jak już mamy wszystkie poziomy DFD
równoważenie
aktywne pasywne
składniki ERD
projektu SI (model konceptualny CDM)
( zbiór SI )
Jaki jest związek między DFD a ERD ???
DFD |
ERD |
procesy |
encje |
przepływy danych |
związki |
obiekty zewnętrzne |
|
Składnica danych |
|
Tutaj składnica danych odpowiada encji. - to jest ten związek.
Na czym polega równoważenie DFD z diagramem struktur danych (ERD) ?
Możemy zacząć od budowy dowolnego z nich najlepiej jeżeli będziemy budować obydwa równocześnie. To równoważenie jest na poziomie logicznym.
W Sybase istnieje funkcja import/export. Przekazuje ona jedne wartości z jednego diagramu do drugiego. Przenosić możemy elementy, atrybuty, encje, jako magazyn, reguły biznesowe. Dane można przenosić w jedną i drugą stronę.
Jednemu magazynowi danych odpowiada jedna encja ( o tych samych nazwach )
Ogólna zasada równoważenia:
Dana encja powinna być przechowywana tylko w jednym miejscu w systemie ( nie powinno być dublowania )
Spis haseł z budowy DFD ( czyli to co musimy umieć )
model konceptualny struktur danych (diagram związków encji ERD)
definicja encji, definicja związku
właściwości encji (nazwy, atrybuty, atrybut identyfikujący)
związki (właściwości związków - liczności [1-n, n-1, n-n], problem likwidacji związków n-n poprzez wprowadzenie encji asocjacyjnej połączonej dwoma związkami 1-n.
Opis związków (nazwa, nazwa ról, liczność, opcjonalność lub obligatoryjność)
// Każda struktura związków n-n przekształcona do związków 1-n to 3 postać znormalizowana
Przejście z modelu logicznego na fizyczny dla wybranego docelowego środowiska bazodanowego
Każdej encji odpowiada tablica encji:
nadrzędna - (po stronie wiele [n]) przechodzi w tablice podrzędną
podrzędna - (po stronie 1 ) przechodzi w tablice nadrzędną
Mechanizm generowania kluczy obcych.
Z tabelek nadrzędnych pobierane są klucze do podrzędnych tabel.
DIAGRAM PRZEJŚĆ STANU SYSTEMU
Komponenty diagramu przejść stanu
START
przejście
A1
C1
Stan i-ty stan
C5 przejście C3
C2 - warunek A3
A2 - akcja
Stan j-ty
C4
STOP
Dlaczego system przechodzi z jednego stanu do drugiego?
Stan systemu opisuje co dzieje się z systemem w danej chwili czasu, który to czas zazwyczaj trwa niepomijalny kawałek czasu. Samo przejście zwane zmianą stanu jest opisane dwojako. Poprzez warunek (przyczynę), druga rzecz to akcja - czynność powzięta przez system która spowoduje zmianę stanu.
Zasady diagramu przejść stanu:
system w każdej chwili czasu jest w jakimś stanie
na tym Diagramie może być tylko jeden START i jeden STOP
każdy stan pośredni powinien być dostępny ze stanu początkowego ( pośrednio lub bezpośrednio )
stan końcowy musi być dostępny dla każdego stanu ( pośrednio lub bezpośrendio)
dany warunek musi powodować przejście danego stanu tylko do jednego jedynego stanu następnego
Diagram przejść stanów jest bardzo dobrą techniką opisu współpracy (dialogu) użytkownika z systemem a ten dialog to poruszanie się po całym menu jakie oferuje system.
RÓWNOWAŻENIE DFD Z DIAGRAMEM STD ( DIAGRAMEM PRZEJŚĆ STANU)
Odbywa się to przy udziale procesu sterującego. DFD wzbogacamy o proces sterujący który rozdziela zadania na procesy wykonawcze.
Przepływ sterujące nie ma w sobie danych w przeciwieństwie do przepływu danych.
DFD x Proces sterujący Mój komputer
r
y
z w
1
a
2 b
3 c
x - proces sterujący, jest konsekwencją
wyboru konkretnego dysku.
r, y, w, z - procesy sterujące.
1 - wyświetlenie listy dysków a - nazwa wybranego dysku
2 - wyświetlenie zawartości wybranego dysku b - przekazanie nazwy folderu
3 - proces przetwarzania danych c - nawa pliku
STD
A: r
C: mój komputer
Stan 1 Wyświetla listę dysków
C: x
A: y
Stan 2 Wyświetla listę folderów dla
wybranego dysku
C: z
A: w
Stan 3 Wyświetla zawartość danego
Folderu
Akcja - odpowiada pojawieniu się przepływu wyjściowego sterującego r
Mój komputer - komputer który spowodował to że doszło do uruchomienia procesu 1.
Diagram STD jest specyfikacją procesu sterującego.
Specyfikacją procesu sterującego jest diagram STD (diagram przejść stanów ) opisuje on algorytm działania zaszyty w procesie sterującym
Przepływy sterujące wejściowe dla procesu sterującego są warunkami dla przejścia na diagramie STD
Przepływy sterujące wyjściowe z procesu sterującego są akcjami podanymi przy przejściach pomiędzy stanami.
Pojęcia z ćwiczeń. (Przetłumaczone)
BPM ( Bisnes modeling process - Biznesowe modelowanie procesów ) - konceptualny model zawierający krótki opis logiki biznesowej i zasad z punktu widzenia klienta używającego diagramów które pokazują interakcję między procesami, przepływami, wiadomościami, kolaboracyjne protokoły z jednego lub wielu punktów do paru potencjalnych punktów startowych. Jest niezupełnym odpowiednikiem DFD
Data - (dane) definiuje typ informacji wymienianej pomiędzy procesami biznesowymi
Process - (proces ) inicjacja manualnej lub automatycznej akcji
Resource - (zasób ) podobny do magazynu danych, może być danymi, dokumentami, bazą danych, komponentami lub wykonywalnym zasobem
Resource Flow - (przepływ zasobów) pozwala procesowi na dostęp do zasobu, informacje w zasobie mogą być tworzone, aktualizowane, kasowane albo czytane przez proces
Flow - (przepływ) interakcja pomiędzy dwoma obiektami z potencjalną wymianą danych
Start - punkt startowy całego procesu reprezentowany w diagramie procesu biznesowego
End - reprezentuje punkt końcowy procesów opisanych w diagramie procesów biznesowych
Organization Unit - (obiekt zewnętrzny, jednostka organizacyjna) element który pozwala definiować która organizacja jest odpowiedzialna za który proces. Może reprezentować kompanię/system, usługę, organizację, użytkownika albo role. Jest adekwatna do oznaczenia komponentu w języku UML.
Wykład VI
Bilans poziomy obejmuje jeden poziom dekompozycji. Bilans pionowy obejmuje dwa kolejne poziomy dekompozycji
Diagram Historii Życia Encji ( ELH - Entity Life History )
(ERD - statyczna struktura danych, diagram związków encji)
ELH - pokazuje zmiany w encjach w czasie a te zmiany są wymuszone zdarzeniami które oddziaływają na encję. To jest diagram dynamiczny.
ELH < = > ERD po to aby z ERD wychwycić te encje które wybierzemy.
równoważenie Aby dla każdej encji zbudować Diagram historii życia encji.
ERD < = > DFD
Znajdujemy encje w składnicach danych.
Oddziaływają na procesy w DFD
Zdarzenia Procesy
Przepływy
DFD
Przepływy wyjściowe do składnic danych
Aktualizacja
Składnic
Danych
Encje podlegają
W składnicach są encje zmianie stanu
( zmiana stanu encji )
co się dzieje ?
z encją jest pokazane
na diagramie ELH
z ERD ELH
ELH - służy aby w jawny sposób pokazać wszystkie zdarzenia zachodzące w systemie, zarówno zdarzenia typowe (normalne) oraz zdarzenia nietypowe (nadzwyczajne, błędne, wskazujące na sytuację awaryjną - jest ich więcej niż normalnych i powodują dużo więcej błędów niż normalne)
Fragment DFD który posłuży do budowy ELH.
Problem:
wybór encji nas interesującej ( wybieramy to z ERD - tutaj encją jest konto klienta )
na DFD szukamy tej encji ( w postaci magazynu danych )
teraz przepływy aktualizujące
Ustalenie limitu funkcje wstrzymania
Dezaktywacja konta
2 3
nowy
rekord
Konto klienta
Obciążenie konta Spłaty
4 7
przepływ typu R R - read ( przepływ czytający )
A tu jest ta encja Konto Klienta
Konto klienta z ERD ( CPM )
- atrybut 1
- atrybut 2
- atrybut 3
Odpowiada encji na ERD (skojarzenie)
DFD Procesy generujące przepływy aktualizujące |
DFD Magazyny danych
|
DFD Przepływ aktualizujący |
DFD Rodzaj aktualizacji |
Zdarzenie |
Proces 2 Ustalenie konta |
Konto Klienta (D1) |
Nowy rekord |
Utwórz nowy wpis w magazynie, przepływ typu C C - create (stwórz) |
Założenie konta |
Proces 4 Utworzenie rekordu pożyczki |
Konto Klienta (D1) |
Obciążenie konta |
Modyfikacja zawartości magazynu, przepływ typu U U - Update (aktualizuj) |
Uzyskanie pożyczki, przyznanie pożyczki |
Proces 7 Obsługa spłat |
Konto Klienta (D1) |
Spłaty |
Modyfikacja, przepływ typu U U - Update (aktualizuj) |
Każdorazowe dokonanie spłaty kolejnej raty pożyczki |
Proces 3 Funkcje utrzymania |
Konto Klienta (D1) |
Dezaktywacja |
Usunięcie wpisu w magazynie, przepływ typu D D - Delete (skasuj) |
Likwidacja konta |
C, U, D i R - ta notacja występuje też w SyBase.
MATRIX CRUD - macierz( tablica krzyżowa) pokazuje zależności między procesami a magazynami danych, pokazuje rodzaje przepływów między nimi
( C - create (utwórz), D - Delete (skasuj), U - Update (aktualizuj), R - Read (czytaj) )
Komponenty diagramu ELH
Diagram acykliczny ( typu drzewo, hierarchiczny )
Nazwa encji
Zdarzenie Zdarzenie Zdarzenie Zdarzenie
Sekwencyjne złożone złożone złożone
Na danym poziomie naszego drzewa
odczytujemy w umowny sposób kolejność
zdarzeń. Zdarzenie na lewo jest
wcześniejsze od zdarzenia na prawo itd.
Zdarzenie * Zdarzenia
Zdarzenia
Zdarzenia
Iteracyjne selektywne selektywne selektywne
Sekwencja zdarzeń jest odczytywana na danym poziomie od lewej do prawej. Zdarzenia iteracyjne to zdarzenia które powtarzają się pewną ilość razy (np. spłata kredytu), może być też 0 powtórzeń (brak wystąpienia zdarzenia). Zdarzenia selektywne zależą od spełnienia warunków ( coś ala „if” lub „switch” w C++ )
Teraz nasz diagram ELH
Konto klienta
Założenie konta przyznanie pożyczki spłacanie pożyczki likwidacja konta
Dwa etapy tworzenia diagramu ELH.
1 etap - utworzenie pomocniczej tablicy krzyżowej dla encji [magazynu danych] poprzez wybranie encji z diagramu związków encji, poprzez identyfikację zdarzeń dotyczących danej encji na podstawie przepływów aktualizujących ten magazyn danych na DFD w którym to magazynie znajduje się aktualizowana encja.
2 etap - rozwarzenie dla każdej encji wziętej z ERD następujących kwestii
normalnego, typowego cyklu życia
rozważenie zdarzeń specjalnych (wyjątkowych)
rozważenie sytuacji błędnych, awaryjnych
WYKŁAD VIII
Równoważenie ELH z DFD
Po co z ELH ??
Weryfikacja poprawności DFD
Czy mogą obsłużyć sytuacje awaryjne itp.
Analiza zdarzeń na ELH powoduje:
które zdarzenia powodują że dane encje pojawiają się w systemie( zdarzenie powoduje zaistnienie encji w systemie ( jej utworzenie ))
zdarzenie wykasowania encji
które zdarzenie powoduje że encja powoduje zmianę atrybutów ( aktualizacja )
tworzenie ELH w prawidłowym cyklu życia encji odbywa się według harmonogramu:
wybranie zdarzeń oddziaływujących na dane encje z tablicy krzyżowej
ustalanie sekwencji zdarzeń na danym poziomie drzewa historii życia encji
sprawdzenie czy pewne zdarzenia mają zachodzić warunkowo ( czy możliwa jest selekcja zdarzeń )
sprawdzenie czy zdarzenia mogą być iteracyjne ( zachodzące wielokrotnie )
jeśli iteracje występują to czy przypadkiem nie zmieniają one sekwencji zdarzeń
czy system traktuje jednakowo wszystkie iteracje zdarzeń jednego, danego typu
Konto klienta encja ( dla nie robimy ELH )
Założenie pożyczka spłata zamknięcie konta
Te prostokąty to zdarzenia
Kolejna
Pożyczka
Jeśli założymy że pożyczka musi być spłacona zanim będzie można wziąć drugą pożyczkę, zakładając że spłata pożyczki może następować w kilku kolejnych ratach. Ostatnią spłatę kiedy konto klienta jest czyste należy wyróżnić w postaci osobnego zdarzenia w celu podjęcia przez system specjalnych akcji
Modyfikujemy nasze ELH ( co do tekstu powyżej )
Konto klienta
Założenia Zmiany na koncie Zamknięcie konta
Cykl
Otrzymanie pożyczki cykl spłaty ostatnia spłata
Splata
Identyfikacja sytuacji błędnych oraz warunków wyjątkowych w życiu encji
Klient zrezygnował z pożyczki
Klient stał się bankrutem ( przedwczesne zakończenie życia encji )
AD 2.
po założeniu konta
po całkowitej spłacie pożyczki
w trakcie spłacania pożyczki
po udzieleniu pożyczki
Konto klienta
Założenie 1 zmiany zamknięcie
Cykl * po to aby system mógł zlikwidować konto
Klienta w sposób nietypowy
Normalny
Nadzwyczajny
Pożyczka cykl spłaty * ostatnia spłata odrzucenie unieważnienie
3 2 3 4
zdarzenia wyjątkowe
W sytuacji 3 i 4 zamknięcie konta odbywa się w sposób nienormalny ( nadzwyczajny )
Wniosek: Weryfikacja ELH względem DFD
Czy dla każdego zdarzenia na ELH istnieje przynajmniej jeden przepływ aktualizujący składnicę danych na DFD aktualizujący omawianą encję w składnicy danych i ten przepływ jest równocześnie odpowiedzią na zaistniałe zdarzenie
Zdarzenia zewnętrzne ( dzieje się w otoczeniu systemu z udziałem obiektów ) są wcześniej zwykle zaznaczone na DFD, ale zapomina się często o zdarzeniach wewnętrznych ( dziejących się wewnątrz systemu ) i powodują przepływy pomiędzy procesami a te procesy oddziaływają procesami aktualizującymi na składnice danych.
PODSUMOWANIE MODELU PODSTAWOWEGO METODYKI YOURDONA
Co w modelu podstawowym musi się znajdować?
Tworzymy go po to aby opisać i wyrazić wymagania użytkownika
DFD
Listy zdarzeń ( zdarzenia zewnętrzne i wewnętrzne )
Określanie przeznaczenia i celu systemu
Kompletny zbiór zrównoważonych DFD ( bilanse pionowe ) - dotyczy to również diagramów ERD, STD i ELH
Kompletny diagram ERD ( związków encji )
Kompletny zbiór diagramów STD
Zbiór diagramów ELH
Kompletny słownik danych dla fazy analizy
Kompletny zbiór specyfikacji procesów
1 - 4 : Model Środowiskowy
5 - 9 : Model Zachowań
Dla procesów złożonych - lista procesów potomnych
Dla procesów elementarnych - opisy algorytmów działania realizowane przez procesy elementarne
Dla procesów sterujących - wybrane diagramy STD
RÓWNOWAŻENIE
DFD z ELH
Muszą im odpowiadać ( w drugą stronę też )
zdarzenia
DFD ELH
Procesy z przepływami
aktualizującymi składnicę
DFD z ERD
Każdej encji odpowiada jeden magazyn danych
Encja
W której składnicy danych jest ta encja ( powinna być jedna encja w jednej składnicy danych )
Funkcja IMPORT w SyBase: ( czyli co można importować )
encje
domeny
dane
składnice danych
procesy biznesowe
istota projektowania strukturalnego: !!!!!!!!!!!!!!!!!
osobno modelujemy elementy aktywne ( procesy ) a osobno modelujemy elementy bierne ( struktury danych )
podejście strukturalne jest dobre wtedy gdy któreś elementy dominują ( np. elementy aktywne ) ( złożone procesy, proste struktury danych )
gdy wszystko jest skomplikowane ( elementy bierne i elementy aktywne ) to lepsze jest podejście obiektowe
MODEL IMPLEMENTACYJNY ( FIZYCZNY )
Określa w jaki sposób system ma zostać zrealizowany przy użyciu dostępnych środków technologicznych
Dostępne narzędzia
Dostępne środowisko systemowe ( system operacyjny )
środowisko sprzętowe
Model implementacyjny według metodyki Yourdona składa się z 3 modeli:
1. Model organizacji kodu
COM CODE ( STC ( w CASE dla ludzi )
( structure Chart - schemat struktury - jak wygląda struktura
oprogramowania)
2. Model Środowiska oprogramowania
3. Model Środowiska sprzętowego nimi się nie zajmujemy
co przedstawia model organizacji kodu ??
- przedstawia hierarchiczną strukturę budowy oprogramowania. Na czym to polega ?
Model logiczny ( podstawowoy )
DFD
Dane Wejście Przetworzenie Wyjście Wyniki
INPUT PROCESS OUTPUT
Transformacja ( przekształcenie )
Model fizyczny ( implementacyjny ) jest to model
oprogramowania
Sterowanie
Dane Wejście Przetwarzanie Wyjście Wyniki
Strzałki oznaczają hierarchię, zależność hierarchiczną ( te strzałki bez kółek )
Model fizyczny uwzględnia składniki sterująco - koordynujące które powodują zwrot przepływu danych pomiędzy odpowiednimi modułami. Moduły są komponentami
Strzałki ( bez kółek ) łączą moduły pokazując hierarchiczną zależność między modułami ( grot wskazuje moduł podrzędny )
Strukturalna
Obiektowa
użytkownik ma kontakt z twórcami systemu w tych momentach
Model fizyczny
Instalacja (wdrażanie)
Model logiczny
Testowanie
Projektowanie
Określanie wymagań
Konserwacja (eksploatacja)
Implementacja
(Pisanie kodu).
Faza strategiczna
(rozważania za i przeciw systemowi)
Analiza
(Rozeznać dziedzinę
systemu)
Dokumentowanie - narzędzia CASE
Projektowanie Strukturalne
Składniki bierne:
- struktury danych
Składniki aktywne:
- procesy (przetwarzające dane)
współpraca
równoważenie
Model implementacyjny (fizyczny) - czyli jak zrealizować to co zostało ustalone w modelu logicznym
Model podstawowy (logiczny) - czyli odpowiedzi na pytania co system ma robić
Podmodel środowiskowy
Model zachowań:
- ERD(DCM) - statyczny model struktur danych
- zbiór diagramów DFD - uzyskany w wyniku kroków dekompozycji diagramu kontekstowego DFD
SI0
U1
U2
U3
we
we
We/wy
wy
Obiekty zewnętrzne
Granica SI