Inżynieria oprogramowania wykład VI Faza analizy Analiza strukturalna modelowanie procesów, słownik danych

Inżynieria oprogramowania wykład VI Faza analizy Analiza strukturalna modelowanie procesów, słownik danych prowadzący: dr hab. inż. Krzysztof Bartecki, prof. PO

Faza analizy systemowej c.d. Wymagania Projektowanie Implementacja Testowanie Konserwacja Strategiczna Analiza Instalacja Dokumentacja 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

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. K. Bartecki, Inżynieria oprogramowania, VI/3

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). K. Bartecki, Inżynieria oprogramowania, VI/4

TERMINATOR 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. K. Bartecki, Inżynieria oprogramowania, VI/5

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ą. K. Bartecki, Inżynieria oprogramowania, VI/6

PROCES 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. K. Bartecki, Inżynieria oprogramowania, VI/7

Magazyn danych (ang. Data store) magazyn danych 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. K. Bartecki, Inżynieria oprogramowania, VI/8

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: SKŁADANIE PODAŃ ROZPATRYWANIE PODAŃ podania K. Bartecki, Inżynieria oprogramowania, VI/9

Inne właściwości magazynu danych Przepływ wychodzący z magazynu interpretowany jest jako odczyt (R) zawartej w nim informacji, zamówienie Realizacja najstarszego zamówienia zamówienia przepływ do magazynu interpretowany jest jako zapis (C), modyfikacja (U) lub usunięcie (D) danych z magazynu, klient Rejestracja klienta klienci K. Bartecki, Inżynieria oprogramowania, VI/10

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ówienie Sortuj zamówienia zamówienia Realizacja najstarszego zamówienia zamówienia K. Bartecki, Inżynieria oprogramowania, VI/11

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: zrealizowane data zamówienia zmiana statusu zamówienia zamówienia policz dzisiejsze zamówienia zamówienia zawartość magazynu nie ulega zmianie w wyniku odczytu z magazynu pobierana jest kopia pakietu, a stan magazynu pozostaje bez zmiany. K. Bartecki, Inżynieria oprogramowania, VI/12

przepływ danych 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. K. Bartecki, Inżynieria oprogramowania, VI/13

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. wniosek wniosek PRZYJMOWANIE WNIOSKÓW potwierdzenie PRZYJMOWANIE WNIOSKÓW potwierdzenie K. Bartecki, Inżynieria oprogramowania, VI/14

zamówienie nazwisko i adres klienta adres dostawy potwierdzenie zamówienia PRZYJĘCIE ZAMÓWIENIA błędne zamówienie prośba o potwierdzenie zamówienie do realizacji przepływy wejściowe proces przepływy wyjściowe K. Bartecki, Inżynieria oprogramowania, VI/15

Przykład przepływu rozbieżnego (te same dane dostarczane są do kilku różnych procesów) K. Bartecki, Inżynieria oprogramowania, VI/16

Przykład przepływu rozbieżnego (pakiet danych dzielony jest na kilka różnych składowych) K. Bartecki, Inżynieria oprogramowania, VI/17

Przykłady różnych notacji stosowanych na diagramach DFD nazwa Yourdon- DeMarco Gane- Sarson SSADM KLIENT terminator KLIENT KLIENT KLIENT terminator powtórzony przepływ danych faktura faktura faktura K. Bartecki, Inżynieria oprogramowania, VI/18

1 KALKULACJA CEN 1 proces KALKULACJA CEN KALKULACJA CEN KALKULACJA CEN * proces elementarny 1 KALKULACJA CEN proces wielokrotny magazyn danych faktury faktury D1 D1 faktury faktury magazyn powtórzony K. Bartecki, Inżynieria oprogramowania, VI/19

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. K. Bartecki, Inżynieria oprogramowania, VI/20

Błędne nazwy składników diagramu Cel raport roczny drukowanie raporu rocznego Szef raport roczny drukowanie raporu rocznego Niewłaściwa nazwa terminatora Klient wprowadzanie danych rejestracja danych Klient infomacja o kliencie rejestracja danych Niewłaściwa nazwa przepływu danych K. Bartecki, Inżynieria oprogramowania, VI/21

Kontrahent dane kontrahenta Kowalski Kontrahent dane kontrahenta przygotowanie umowy Niewłaściwa nazwa procesu rejestracja p łatności termin zap łaty FV 345/2004 rejestracja p łatności termin zap łaty faktury Niewłaściwa nazwa magazynu danych K. Bartecki, Inżynieria oprogramowania, VI/22

Niewłaściwe łączenie komponentów Dostawca Klient Kontrahent faktura zakupu Towary Niedopuszczalne połączenie dwóch terminatorów Niedopuszczalne połączenie terminatora z magazynem faktury klienci Niedopuszczalne połączenie dwóch magazynów K. Bartecki, Inżynieria oprogramowania, VI/23

Procesy duchy i procesy studnie oferta tworzenie rejestru sprzeda ży zamówienie klienta rejestracja zam ówień rejestr sprzeda ży Proces bez przepływów wyjściowych ( studnia ) Proces bez przepływów wejściowych ( duch ) K. Bartecki, Inżynieria oprogramowania, VI/24

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. K. Bartecki, Inżynieria oprogramowania, VI/25

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. K. Bartecki, Inżynieria oprogramowania, VI/26

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. K. Bartecki, Inżynieria oprogramowania, VI/27

Przykładowy diagram kontekstowy K. Bartecki, Inżynieria oprogramowania, VI/28

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. K. Bartecki, Inżynieria oprogramowania, VI/31

Przykładowy diagram kontekstowy (po lewej) oraz odpowiadający mu diagram systemowy (po prawej) K. Bartecki, Inżynieria oprogramowania, VI/32

Przykładowy diagram kontekstowy (u góry) oraz odpowiadający mu diagram systemowy (na dole) K. Bartecki, Inżynieria oprogramowania, VI/33

Przykładowy diagram systemowy K. Bartecki, Inżynieria oprogramowania, VI/34

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. K. Bartecki, Inżynieria oprogramowania, VI/35

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 K. Bartecki, Inżynieria oprogramowania, VI/36

Przykładowy diagram systemowy (po lewej) oraz diagram pierwszego poziomu dla procesu 1.0 (po prawej) K. Bartecki, Inżynieria oprogramowania, VI/37

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). K. Bartecki, Inżynieria oprogramowania, VI/38

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. K. Bartecki, Inżynieria oprogramowania, VI/39

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. K. Bartecki, Inżynieria oprogramowania, VI/40

a b c a d e f b d c f e Równoważenie diagramu DFD K. Bartecki, Inżynieria oprogramowania, VI/41

Równoważenie diagramu DFD K. Bartecki, Inżynieria oprogramowania, VI/42

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). K. Bartecki, Inżynieria oprogramowania, VI/43

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. K. Bartecki, Inżynieria oprogramowania, VI/44

Przykład specyfikacji procesu w formie pseudokodu K. Bartecki, Inżynieria oprogramowania, VI/45

Przykład specyfikacji procesu w formie pseudokodu SERWISANCI potwierdzenie wykonania 1.3 POTWIERDZENIE WYKONANIA status wykonania Zlecenia data ostatniego przeglądu wysłanie rachunku Przeglądy KLIENCI 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 } K. Bartecki, Inżynieria oprogramowania, VI/46

Przykład specyfikacji procesu w formie pseudokodu KIEROWNICTWO raport 1.5 TWORZENIE RAPORTÓW Zlecenia 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 K. Bartecki, Inżynieria oprogramowania, VI/47

Przykład specyfikacji procesu w formie opisu warunków zachodzących przed i po wykonaniu procesu K. Bartecki, Inżynieria oprogramowania, VI/48

Przykład specyfikacji procesu w formie tablicy i drzewa K. Bartecki, Inżynieria oprogramowania, VI/49

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. K. Bartecki, Inżynieria oprogramowania, VI/50

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). K. Bartecki, Inżynieria oprogramowania, VI/51

Przykładowa macierz CRUD K. Bartecki, Inżynieria oprogramowania, VI/52

Przykładowa macierz CRUD K. Bartecki, Inżynieria oprogramowania, VI/53

Przykładowy diagram DFD System rejestracji studentów Diagram kontekstowy K. Bartecki, Inżynieria oprogramowania, VI/54

Diagram systemowy (zerowego poziomu) K. Bartecki, Inżynieria oprogramowania, VI/55

Diagram szczegółowy (pierwszego poziomu) dla procesu 4. K. Bartecki, Inżynieria oprogramowania, VI/56

Przykładowy diagram DFD diagram systemowy K. Bartecki, Inżynieria oprogramowania, VI/57

Diagram pierwszego poziomu dla procesu 1.1 K. Bartecki, Inżynieria oprogramowania, VI/58

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. K. Bartecki, Inżynieria oprogramowania, VI/62

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. K. Bartecki, Inżynieria oprogramowania, VI/63

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. K. Bartecki, Inżynieria oprogramowania, VI/64

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 K. Bartecki, Inżynieria oprogramowania, VI/65

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) K. Bartecki, Inżynieria oprogramowania, VI/66

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 K. Bartecki, Inżynieria oprogramowania, VI/67

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 K. Bartecki, Inżynieria oprogramowania, VI/68

Przykładowa lista elementów danych modelu encji w programie PowerDesigner K. Bartecki, Inżynieria oprogramowania, VI/69