Inżynieria oprogramowania - k.bartecki.po.opole.pl · Diagram Przepływu Danych (ang. Data Flow...

prowadzący: dr hab. inż. Krzysztof Bartecki, prof. PO

Inżynieria oprogramowania

wykład VI

Faza analizy

Analiza strukturalna – modelowanie procesów, słownik danych

Faza analizy systemowej – c.d.

Przypomnienie:

Celem tej fazy jest udzielenie odpowiedzi na pytanie: jak system ma

działać?

W wyniku fazy analizy otrzymujemy logiczny model systemu, opisujący

sposób realizacji przez system postawionych wymagań, lecz abstrahujący

jeszcze od szczegółów implementacyjnych.

K. Bartecki, Inżynieria oprogramowania, VI/2

Wymagania Projektowanie Implementacja Testowanie Konserwacja

Strategiczna Analiza Instalacja

Dokumentacja


Modelowanie procesów

Diagram Przepływu Danych

(ang. Data Flow Diagram, DFD)

● pokazuje, w jaki sposób dane przepływają w systemie oraz opisuje

procesy służące do przetwarzania tych danych,

● opisany jest za pomocą określonej notacji,

● zbudowany jest przy użyciu odpowiednich narzędzi CASE,

● bazuje na hierarchicznej dekompozycji funkcji systemu,

● używany jest do wnioskowania o przyszłym oprogramowaniu, .

● unika terminologii implementacyjnej.


Składniki diagramu DFD

● terminatory (obiekty zewnętrzne),

● procesy,

● magazyny (składnice) danych,

● przepływy danych.

Uwaga: w wykładzie przedstawiono notację graficzną Yourdona-

DeMarco (istnieją również inne notacje).


Terminator (ang. Terminator),

inna nazwa: Encja zewnętrzna (ang. External Entity)

● reprezentuje źródło lub miejsce przeznaczenia informacji, które jest

zewnętrzne w stosunku do sytemu,

● może być to np. osoba, dział urzędu, firma, inny system komputerowy,

maszyna, lub inny obiekt znajdujący się na zewnątrz systemu,

● nazwa terminatora, to rzeczownik w liczbie pojedynczej, np. KLIENT,

DZIAŁ SPRZEDAŻY, URZĄD SKARBOWY, DOSTAWCA.

TERMINATOR


Inne właściwości terminatora

● Jest obiektem generującym lub przyjmującym strumienie danych,

● przepływy łączące terminatory z różnymi składowymi modelu

reprezentują interfejsy pomiędzy systemem a światem zewnętrznym,

● leży poza zakresem odpowiedzialności projektowanego systemu,

● analityk/projektant systemu nie może zmieniać zawartości terminatora,

● w modelu DFD nie pokazuje się przepływów danych między

terminatorami, nawet jeśli takie w rzeczywistości istnieją.


Proces (ang. Process)

● realizuje transformację danych wejściowych w dane wynikowe –

odpowiada tym składnikom systemu, które przetwarzają dane,

● otrzymuje i przesyła dane za pośrednictwem przepływów danych,

● kojarzy się z procedurą, której specyfikacja może być przedstawiona

przy użyciu innych technik strukturalnych,

● nazwa procesu, to rzeczownik odczasownikowy + dopełnienie, np.

WYSTAWIENIE FAKTURY, PRZYJĘCIE TOWARU, OBLICZENIE

PŁAC,

● dla celów porządkowych proces może być oznaczony numerem.

PROCES


Magazyn danych (ang. Data store)

● reprezentuje miejsce, w którym przez pewien czas określone dane są

przechowywane,

● jest dostępny tylko dla procesów, tzn. nie może być połączony

bezpośrednio z terminatorem lub z innym magazynem,

● istnienie magazynu danych w diagramie ma sens, gdy

przechowywane dane służą do realizacji co najmniej dwóch procesów,

z których jeden zapisuje w magazynie dane, a drugi je odczytuje,

● nazwa magazynu danych to rzeczownik w liczbie mnogiej, np.

klienci, faktury, towary, studenci, grupy, pracownicy,

● nazwy magazynów, takie jak rejestr faktur, archiwum zleceń, baza

pojazdów nie są zalecane, lepiej po prostu: faktury, zlecenia, pojazdy.

● dla celów porządkowych magazyn danych może być oznaczony

numerem.

magazyn

danych


Cel istnienia magazynu

Umożliwienie przechowywania danych w sytuacji, gdy:

● dane są używane nie od razu po wytworzeniu,

● dana jest kilkakrotnie odczytywana,

● dane są używane w innej kolejności niż były wytworzone.

Przykład:

podania

SKŁADANIE

PODAŃ

ROZPATRYWANIE

PODAŃ


Inne właściwości magazynu danych

● Przepływ wychodzący z magazynu interpretowany jest jako odczyt (R)

zawartej w nim informacji,

● przepływ do magazynu interpretowany jest jako zapis (C), modyfikacja

(U) lub usunięcie (D) danych z magazynu,

zamówienie

zamówienia

Realizacja

najstarszego

zamówienia

klient

klienci

Rejestracja

klienta


Inne właściwości magazynu danych – c.d.

● jeśli przepływ reprezentujący operację na magazynie nie ma

etykiety, oznacza to, że operacja ta dotyczy wielu/wszystkich pakietów

danych (np. odczytywane są wszystkie rekordy zapisane w magazynie),

● jeśli etykieta na przepływie jest taka sama jak na magazynie, ale w

liczbie pojedynczej, oznacza to, że operacja dotyczy pojedynczego

wystąpienia pakietu (jednego rekordu),

zamówienia

Sortuj

zamówienia

zamówienie

zamówienia

Realizacja

najstarszego

zamówienia


Inne właściwości magazynu danych – c.d.

● jeśli etykieta (etykiety) przepływu jest inna niż nazwa magazynu,

oznacza to, że pobierany jest jeden (lub więcej) fragmentów jednego lub

większej liczby pakietów:

● zawartość magazynu nie ulega zmianie w wyniku odczytu – z magazynu

pobierana jest kopia pakietu, a stan magazynu pozostaje bez zmiany.

zrealizowane

zamówienia

zmiana

statusu

zamówienia

data zamówienia

zamówienia

policz

dzisiejsze

zamówienia


Przepływ danych (ang. Data flow)

● opisuje strumień danych o określonej zawartości, przepływający

pomiędzy dwoma składnikami DFD:

– terminatorem a procesem (lub odwrotnie),

– procesem a innym procesem,

– procesem a magazynem danych (lub odwrotnie).

● nazwa przepływu to rzeczownik w liczbie pojedynczej – np.

kwestionariusz osobowy, umowa, faktura dla klienta, potwierdzenie

transakcji.

przepływ

danych


Inne właściwości przepływu danych

● Przepływ danych nie odpowiada na wiele pytań proceduralnych, np.:

– kiedy wchodzi do procesu,

– czy jest wynikiem zapytania systemu,

– czy istnieje jakaś współzależność pomiędzy przepływem

wchodzącym a wychodzącym,

● jeśli przekazywana jest informacja zwrotna, można używać kolejnych

linii lub strzałek dwukierunkowych.

PRZYJMOWANIE

WNIOSKÓW

wniosek

potwierdzenie

PRZYJMOWANIE

WNIOSKÓW

wniosek

potwierdzenie


PRZYJĘCIE

ZAMÓWIENIA

zamówienie

nazwisko

i adres klienta

potwierdzenie

zamówienia

błędne

zamówienie

przepływy

wejściowe przepływy

wyjściowe

proces

adres dostawy

prośba o

potwierdzenie

zamówienie

do realizacji


Przykład przepływu rozbieżnego

(te same dane dostarczane są do kilku różnych procesów)


Przykład przepływu rozbieżnego

(pakiet danych dzielony jest na kilka różnych składowych)


Przykłady różnych notacji stosowanych na diagramach DFD

nazwa Yourdon-

DeMarco Gane-

Sarson SSADM

terminator

przepływ

danych

KLIENT KLIENT

KLIENT

KLIENT

terminator

powtórzony

faktura faktura faktura


proces

magazyn

danych

1

KALKULACJA

CEN

KALKULACJA

CEN KALKULACJA

CEN

1

KALKULACJA

CEN

1

KALKULACJA

CEN *

faktury faktury

faktury D1

faktury D1

magazyn

powtórzony

proces elementarny

proces wielokrotny


Błędne konstrukcje na diagramach DFD

Typowe błędy przy tworzeniu diagramów DFD wynikają z:

● użycia niewłaściwych nazw dla składników diagramu,

● niewłaściwego łączenia komponentów,

● użycia procesów „duchów” i procesów „studni”,

● niewłaściwego bilansowania przepływów w przypadku dekompozycji,

● niezgodności diagramu przepływu danych z diagramem związków

encji.


Błędne nazwy składników diagramu

Cel

drukowanie

raporu

rocznego

raport roczny Szef

drukowanie

raporu

rocznego

raport roczny

Klient rejestracja

danych wprowadzanie danych Klient

rejestracja

danych infomacja o kliencie

Niewłaściwa nazwa terminatora

Niewłaściwa nazwa przepływu danych


Kontrahent Kowalski dane kontrahenta Kontrahent przygotowanie

umowy dane kontrahenta

rejestracja

p łatności FV 345/2004 termin zap łaty

rejestracja

p łatności faktury termin zap łaty

Niewłaściwa nazwa procesu

Niewłaściwa nazwa magazynu danych


Niewłaściwe łączenie komponentów

Niedopuszczalne połączenie

dwóch terminatorów

Niedopuszczalne połączenie dwóch magazynów

Dostawca Klient

Niedopuszczalne połączenie

terminatora z magazynem

Kontrahent Towary faktura zakupu

faktury klienci


Procesy „duchy” i procesy „studnie”

rejestracja

zam ówień zamówienie klienta

oferta

tworzenie rejestru

sprzeda ży

rejestr sprzeda ży

Proces bez przepływów

wyjściowych („studnia”)

Proces bez przepływów

wejściowych („duch”)


Dekompozycja procesów – diagramy hierarchiczne

Umieszczenie na jednym poziomie wszystkich procesów skutkowałoby

powstaniem nieczytelnego diagramu ze zbyt dużą liczbą procesów,

przepływów, magazynów danych.

Z tego względu modelowanie przepływów danych polega zazwyczaj na

stworzeniu hierarchicznej, wielopoziomowej grupy diagramów DFD.


W skład hierarchicznego DFD wchodzą

następujące poziomy diagramów:

● diagram kontekstowy – definiujący zakres i granice systemu,

● diagram systemowy (diagram poziomu zerowego) – pokazujący

główne funkcje systemu,

● diagramy szczegółowe (procesów elementarnych) – ukazujący

podział głównych procesów systemu, rozłożonych na podprocesy:

– diagramy poziomu 1,

– ew. diagramy poziomu 2,

itd.


Diagram kontekstowy

● to szczególny przypadek DFD, na którym cały modelowany system

reprezentowany jest przez pojedynczy proces,

● diagram ten ma na celu przedstawienie powiązań systemu ze

środowiskiem zewnętrznym (terminatorami),

● system powiązany jest z terminatorami za pomocą przepływów

danych,

● z lub do danego terminatora może wypływać/wpływać bardzo wiele

różnych przepływów, dlatego dla większej czytelności diagramu,

dopuszcza się powielanie terminatorów.


Przykładowy diagram kontekstowy


Diagram systemowy (zerowego poziomu)

● przedstawia główne funkcje, kluczowe dla modelowanego systemu,

● stanowi najbardziej ogólne spojrzenie na „wnętrze” systemu,

● zawiera kilka procesów (2-8), terminatory oraz magazyny danych.


Przykładowy diagram kontekstowy (po lewej)

oraz odpowiadający mu diagram systemowy (po prawej)


Przykładowy diagram kontekstowy (u góry)

oraz odpowiadający mu diagram systemowy (na dole)


Przykładowy diagram systemowy


Diagramy szczegółowe

● przedstawiają procesy, na które dekomponowany („rozkładany”) jest

każdy z procesów diagramu systemowego,

● proces o numerze 1. z diagramu systemowego dekomponowany jest

na podprocesy o numerach 1.1, 1.2, 1.3, itd., proces 2. – na

podprocesy 2.1, 2.2, 2.3, itd.,

● na kolejnym poziomie dekompozycji proces 1.1 może być rozłożony na

podprocesy 1.1.1, 1.1.2, itd.,

● dekompozycję prowadzi się tak długo, aż otrzymamy procesy

elementarne.


DK

1 2 3

1.1 1.2 3.1 3.2 3.3

1.2.1 1.2.2

Przykładowa hierarchia diagramów przepływu danych


Przykładowy diagram systemowy (po lewej)

oraz diagram pierwszego poziomu dla procesu 1.0 (po prawej)


Zasady tworzenia diagramów wielopoziomowych

● Prosty system powinien mieć nie więcej niż 2-3 poziomy, średni 3-5

poziomów, duży do 8 poziomów,

● liczba procesów na jednym diagramie nie powinna być większa

niż 6-8,

● nie wszystkie procesy muszą być rozwijane do tej samej liczby

poziomów (różny stopień złożoności),

● obiekty, które łączą się z dekomponowanym procesem za pomocą

przepływów (terminatory, magazyny, inne procesy) muszą wystąpić

na poziomie niższym,

● diagramy powinny być zbalansowane (zrównoważone).


Metody rozwijania hierarchicznych DFD

są analogiczne, jak w przypadku tworzenia hierarchii wymagań

funkcjonalnych (patrz wykład 4):

● „z góry na dół” (top-down),

● „z dołu do góry” (bottom-up),

● mieszane.

W metodzie „z góry na dół” rozpoczynamy budowę od diagramu

kontekstowego i drogą kolejnych uszczegółowień (dekompozycji)

procesów dochodzimy do rozwiązania końcowego w postaci procesów

atomowych (elementarnych).

W metodzie „z dołu do góry” najpierw tworzy się listę niezależnych

procesów, które nie będą dalej dekomponowane. Następnie grupuje się je

do postaci procesów wyższego rzędu, aż do otrzymania diagramu

kontekstowego.


Bilansowanie (równoważenie) diagramów DFD

● Hierarchiczne diagramy DFD powinny być zbilansowane, czyli

zrównoważone względem kolejnych poziomów dekompozycji,

● wszystkie przepływy, które pojawiły się na diagramie poziomu

wyższego, powinny się znaleźć na diagramie poziomu niższego,

● na niższym poziomie pojawiają się dodatkowe przepływy pomiędzy

pomiędzy nowymi procesami, które pojawiły się w wyniku

dekompozycji procesów wyższego poziomu, ewentualnie także

między procesami i lokalnymi magazynami danych danego

procesu.


Równoważenie diagramu DFD

a b

c

a

b

c

d e

f

d

e f


Równoważenie diagramu DFD


Równoważenie diagramu przepływu danych (DFD)

względem diagramu związków encji (ERD)

● Każdy magazyn danych na DFD musi odpowiadać encji na ERD,

● nazwy encji na ERD oraz nazwy magazynów danych na DFD muszą

sobie odpowiadać (np. encja: KLIENT, magazyn danych: KLIENCI),

● jeżeli są na diagramie DFD magazyny danych nie mające swojego

odpowiednika na diagramie ERD, model należy poprawić.

● jeżeli są na diagramie ERD encje nie mające swojego odpowiednika

na diagramie DFD, model należy poprawić,

● na diagramie DFD powinny istnieć procesy, realizujące operacje

tworzenia, odczytu oraz usuwania instancji każdej z encji (rekordu,

elementu magazynu danych).


Specyfikacja procesów

● stanowi algorytmiczną definicję procesu, czyli opisuje, co dzieje się

wewnątrz procesu w celu przekształcenia danych wejściowych

w dane wyjściowe,

● tworzona jest dla procesów elementarnych (atomowych), czyli dla

procesów na najniższym poziomie diagramu przepływu danych,

● stanowi możliwie precyzyjny i jednoznaczny opis czynności

wykonywanych przez proces,

● istnieje wiele sposobów specyfikowania procesów, np.

– opis w języku strukturalnym (tzw. pseudokod),

– opis warunków zachodzących przed i po wykonaniu procesu,

– drzewo lub tablica decyzyjna,

– wzory matematyczne.


Przykład specyfikacji procesu w formie pseudokodu



GET potwierdzenie wykonania FROM TERMINATOR Serwisanci AS potwierdzenie

IF (potwierdzenie)

{

SEND wysłanie rachunku TO TERMINATOR Klienci

SET data ostatniego przeglądu AS aktualna data

SAVE data ostatniego przeglądu TO STORE Przeglądy

SET status wykonania AS wykonane

SAVE status wykonania TO STORE Zlecenia

}

1.3

POTWIERDZENIE

WYKONANIA

SERWISANCI

KLIENCI

Zlecenia

Przeglądy

potwierdzenie

wykonania

wysłanie

rachunku

status

wykonania

data ostatniego

przeglądu



IF (data systemowa > 27 danego miesiąca)

{

FOR Serwisanci

{

DO

{

FIND (Serwisant, data realizacji, status) FROM STORE Zlecenia

IF (data realizacji = bieżący miesiąc AND status = wykonane)

}

WHILE TRUE

}

SEND raport TO TERMINATOR Kierownictwo

1.5

TWORZENIE

RAPORTÓW

KIEROWNICTWO

Zlecenia raport


Przykład specyfikacji procesu w formie opisu warunków

zachodzących przed i po wykonaniu procesu


Przykład specyfikacji procesu w formie tablicy i drzewa


Macierz CRUD

jest tabelą, odwzorowującą związki pomiędzy procesami a magazynami

danych lub pomiędzy procesami a danymi elementarnymi.

Nazwa macierzy pochodzi od pierwszych liter operacji wykonywanych

przez procesy na magazynach lub elementach danych:

C – Create, w przypadku zapisu danych,

R – Read, w przypadku odczytu danych,

U – Update, w przypadku modyfikacji danych,

D – Delete, w przypadku usuwania danych.


● Nagłówkami kolumn macierzy CRUD są nazwy procesów,

a nagłówkami wierszy – nazwy magazynów lub elementów danych,

natomiast na przecięciu kolumn i wierszy występują odpowiednie

litery oznaczające wykonywaną operację.

● Analizując zawartość macierzy można przeprowadzić dodatkową

kontrolę modelu pod kątem wykorzystania magazynów danych.

● Możliwe jest zarówno stworzenie jednej macierzy CRUD dla

wszystkich procesów (na wszystkich poziomach dekompozycji), jak

również oddzielnych macierzy dla poszczególnych poziomów.

● W praktyce magazyny danych najczęściej oznaczają tablice

relacyjnej bazy danych, w odniesieniu do których wykonywane są

standardowe instrukcje języka SQL:

– zapis (INSERT),

– odczyt (SELECT),

– aktualizacja (UPDATE),

– kasowanie (DELETE).


Przykładowa macierz CRUD


Przykładowy diagram DFD – System rejestracji studentów

Diagram kontekstowy


Diagram systemowy (zerowego poziomu)


Diagram szczegółowy (pierwszego poziomu) dla procesu 4.


Przykładowy diagram DFD – diagram systemowy


Diagram pierwszego poziomu dla procesu 1.1


Słownik danych

Nie jest możliwe zamodelowanie wymagań użytkownika bez

zdefiniowania danych występujących w systemie.

Dlatego oprócz diagramu związków encji (ERD) oraz diagramu

przepływu danych (DFD), w skład modelu strukturalnego wchodzi

również słownik danych (ang. data dictionary).

Słownik danych to szczegółowy, uporządkowany wykaz wszystkich

danych, występujących w projektowanym systemie.


Zawartość słownika danych

W słowniku danych opisywane są:

● pakiety danych przenoszonych przez przepływy na diagramach DFD,

● pakiety danych zawartych w magazynach na diagramach DFD,

odpowiadających encjom z diagramu ERD, wraz i ich atrybutami.


Pełna definicja elementu danych powinna określać:

● znaczenie elementu danych w kontekście aplikacji użytkownika, na

ogół w formie komentarza,

● budowę elementu danych,

● zbiór wartości, jakie może przyjmować element danych, w przypadku

danych elementarnych, czyli niepodlegających dekompozycji.

Słownik danych powstaje na etapie analizy wymagań dotyczących

systemu, nie zaś na etapie projektowania fizycznej implementacji.

Dlatego uwzględnia on istnienie elementów danych, a nie ich postać

fizyczną – np. pensja to siedem cyfr dziesiętnych z dwoma miejscami

po przecinku.


Notacja słownika danych

Istnieje wiele różnych notacji słownika danych, ale jednym

z najprostszych i najpopularniejszych jest schemat składający się

z następujących operatorów:

= jest złożony z

+ i

() element opcjonalny

{} element powtarzalny (iteracja)

[ ] wybór z możliwości alternatywnych

| rozdzielenie możliwości alternatywnych

** początek i zakończenie komentarza

(tzw. minispecyfikacji elementu danych)

@ identyfikator


Fragment przykładowego słownika danych

cyfra = [ 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 ]

litera = [a...z | A...Z]

znak = [! | @ | # | $ | % | & | * | ( | ) | _ | + | - | = | { | } | [ | ] | „

| ; | ‘ | < | > | , | . | ? | / | ^ ]

Dostawca = @Id_dostawcy + Nazwa + Adres + (e-mail) + Telefon +

Osoba kontaktowa

@Id_dostawcy = 1{cyfra}8

** Nazwa = Nazwa firmy **

Nazwa = {litera}

** Adres = Adres firmy **

Adres = Ulica + Numer budynku + (Numer lokalu) + Kod + Miejscowość

Ulica = {litera}

Numer budynku = {cyfra} + (litera)

Numer lokalu = {cyfra} + (litera)


Fragment przykładowego słownika danych – c.d.

** Kod = Kod pocztowy **

Kod = cyfra + cyfra + znak - + cyfra + cyfra + cyfra

Miejscowość = {litera}

e-mail = {litera + (znak . | znak _)} + znak @ + {litera + (znak . | znak _)}

Telefon = (znak ( + {cyfra} + znak )) + {cyfra}

** Osoba kontaktowa = Osoba odpowiedzialna za kontakty z obsługą systemu **

Osoba kontaktowa = Imię + (Drugie imię) + Nazwisko

Imię = {litera}

Drugie imię = {litera}

Nazwisko = {litera}

Cena towaru = Id towaru + Cena netto + VAT + Ilość dla upustu + Upust + Data

ważności

** Id towaru = Identyfikator towaru, którego dotyczy kalkulacja ceny **

Id towaru = {cyfra}

Cena netto = {cyfra} + znak , + cyfra + cyfra


Fragment przykładowego słownika danych – c.d.

** VAT = Wielkość podatku VAT naliczanego dla danego towaru **

VAT = {cyfra}

**Ilość dla upustu = Minimalna liczba sztuk towaru gwarantująca upust cenowy**

Ilość dla upustu = {cyfra}

** Upust = Wartość określająca, o ile procent zmniejszy się cena w przypadku

upustu **

Upust = {cyfra}

** Data ważności = Data końcowa obowiązywania kalkulacji cenowej dla danego

towaru w formacie dd-mm-rrrr **

Data ważności = cyfra + cyfra + znak - + cyfra + cyfra + znak - + cyfra +

cyfra + cyfra + cyfra


Przykładowa lista elementów danych modelu encji w programie PowerDesigner

Inżynieria oprogramowania - k.bartecki.po.opole.pl · Diagram Przepływu Danych (ang. Data Flow...

Documents

Transcript of Inżynieria oprogramowania - k.bartecki.po.opole.pl · Diagram Przepływu Danych (ang. Data Flow...