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:

1. wybranie zdarzeń oddziaływujących na dane encje z tablicy krzyżowej

2. ustalanie sekwencji zdarzeń na danym poziomie drzewa historii życia encji

3. sprawdzenie czy pewne zdarzenia mają zachodzić warunkowo ( czy możliwa jest selekcja zdarzeń )

4. sprawdzenie czy zdarzenia mogą być iteracyjne ( zachodzące wielokrotnie )

5. jeśli iteracje występują to czy przypadkiem nie zmieniają one sekwencji zdarzeń

6. czy system traktuje jednakowo wszystkie iteracje zdarzeń jednego, danego typu

Konto klienta encja ( dla niej 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 to 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

1. Klient zrezygnował z pożyczki

2. 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

1. 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

2. 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

1. DFD

2. Listy zdarzeń ( zdarzenia zewnętrzne i wewnętrzne )

3. Określanie przeznaczenia i celu systemu

4. Kompletny zbiór zrównoważonych DFD ( bilanse pionowe ) - dotyczy to również diagramów ERD, STD i ELH

5. Kompletny diagram ERD ( związków encji )

6. Kompletny zbiór diagramów STD

7. Zbiór diagramów ELH

8. Kompletny słownik danych dla fazy analizy

9. Kompletny zbiór specyfikacji procesów

1 - 4 : Model Środowiskowy

5 - 9 : Model Zachowań

Specyfikacje

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

1. Dostępne narzędzia

2. Dostępne środowisko systemowe ( system operacyjny )

3. ś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 )

---