Inżynieria oprogramowania: Zródła i rola
inżynierii oprogramowania, modele cyklu życia oprogramowania.
Projekt informatyczny - fazy tworzenia projektu projektu
informatycznego, testowanie a uruchamianie programów. Rozwiązywania problemów
za pomocą komputerów:
Modelowanie danych, modelowanie systemów, CASE
Ogólne zagadnienia informatyki: gromadzenie, udostępnianie, przesyłanie i wydawanie informacji
Literatura i materiały pomocnicze:
Przedmiotem inżynierii programowania są różne aspekty rozwijania i eksploatacji oprogramowania, próby racjonalizacji postępowania, metody i narzędzia - ograniczenie wysiłku i czasu, tworzenie oprogramowania bardzo dokładnego.
Przedmiot zainteresowania IP, aspekty:
Obszar zainteresowań: "duże systemy": liczba wykonawców 50-3000; zespół kierujący 1-50; zróżnicowanie kwalifikacji członków zespołu, niestabilność załogi.
Odbiorcy: wykonawcy, menedżerowie (wykorzystanie zasobów ludzkich, wykorzystanie doświadczeń), użytkownicy - koszt, efekty.
Inżynieria oprogramowania jest dziedziną informatyki, która pojawiła się w połowie lat 60-tych. Rozwój inżynierii oprogramowania poprzedziło zwrócenie uwagi na tzw. kryzys oprogramowania. W latach 50 i na początku lat 60-tych tworzono tylko małe programy. Rozwój sprzętu komputerowego oraz języków programowania umożliwił tworzenie znacznie bardziej złożonych systemów. Stało się jasne, że rozwój technik oprogramowania nie nadąża za rozwojem sprzętu i to zjawisko nazwano "kryzysem oprogramowania", który trwa do dziś. W latach 90-tych 90% poważnych firm programistycznych w USA uważa, że często zdarzają się im opóźnienia w realizacji przedsięwzieć programistycznych. Oprogramowanie jest też chyba jedynym produktem technicznym, w którym błędy są powszechnie akceptowane. Przykładem może być wykrycie błędu w pierwszych egzemplarzach PENTIUM. Producenci programów sprzedawanych w milionach egzemplarzy nie dają praktycznie żadnej gwarancji na to, że ich produkt działa zgodnie z opisem.
Przyczyny kryzysu oprogramowania:
Rozmaite propozycje wyjścia z "kryzysu oprogramowania" zaowocowały powstaniem nowego działu oprogramowania - inżynierii oprogramowania.
Inżynieria
oprogramowania
wiedza techniczna dotycząca wszystkich faz cyklu życia
oprogramowania, której celem jest uzyskanie wysokiej jakości produktu -
oprogramowania. Jest wiedzą techniczną a nie teoretyczną nauką choć
wykorzystuje dorobek wielu nauk, np. teorii programowania, sztucznej
inteligencji, badań operacyjnych, psychologii, nauki o zarządzaniu.
Inżynieria oprogramowania traktuje oprogramowanie jako produkt.
Główne cechy oprogramowania
Dobre oprogramowanie powinno być:
Inżynieria oprogramowania obejmuje m. in. takie zagadnienia jak:
Kryzys oprogramowania nie został w pełni zażegnany ale dzięki praktycznemu
zastosowaniu metod inzynierii oprogramowania,
widoczne są wyraźne symptomy postępu w zakresie produkcji oprogramowania.
Realizowane są przedsięwzięcia wymagające pracy nawet ponad tysiąca osób.
Sukces inzynierii oprogramowania wiąże się z rozwojem
metodyki, rozwojem narzędzi, edukacją.
Praktyczne stosowanie metod inzynierii oprogramowania bez wykorzystania specjalizowanych narzędzi, może być bardzo czasochłonne. Narzut niezbędny np. na opracowanie szeregu diagramów i raportów w fazach anlizy i projektowania może zniweczyc potencjalne korzyści. Praktycznym rozwiązaniem tego typu problemów są narzędzia CASE - computer assisted/aided software/system engineering (komputerowo wspomagana inżynieria oprogramowania/systemów.
Narzędzia CASE pełnią w pracy inżyniera oprogramowania podobną rolę jak
narzędzia CAD/CAM w pracy inżynierów innych dziedzin. Dzieli się je na
narzędzia Upper-CASE i Lower-CASE.
Programy Upper-CASE to narzędzia
wysokiego poziomu, które koncentrują się na wstępnych etapach realizacji przesięwzięcia - określaniu wymagań, modelowaniu i
projektowaniu systemu realizującego te wymagania. Narzędzia takie nie
wspomagają bezpośrednio implementacji systemu.
Programy Lower-CASE, czyli narzędzia
niskiego poziomu koncentrują się na fazie implementacji.
Produkacja oraz eksploatacja oprogramoania jest procesem, który powinien być realizowany w sposób systematyczny. Jak powinien wyglądać ten proces określają tzw. modele cyklu życia oprogramowania. Modele te wprowadzają pewne fazy życia oprogramowania, określają czynności wykonywane w poszczególnych fazach oraz ustalają kolejność ich realizacji. Modele cyklu życia oprogramowania pozwalają uporządkować przebieg prac, ułatwiają planowanaie zadań oraz monitorowanie przebiegu ich realizacji.
Cykl życia oprogramowania - model ogólny (ujęcie podstawowe)
W fazie projektowania nie żyłuje się szybkości i efektywności. Efektywność poprawia się w czasie eksploatacji i konserwacji.
Rozkład kosztów:
|
projektowanie |
1/4 |
|
implementacja
(kodowanie) |
1/12 |
|
testowanie |
1/6 |
|
konserwacja
(pielęgnacja) |
1/2 |
Jakość prac projektowych ma być największa.
Produkcja oraz eksploatacja oprogramowania jest pewnym procesem, który powinien być realizowany w sposób systematyczny. Jest szereg tzw. modeli cyklu życia oprogramowania. Modele te wprowadzają pewne fazy życia oprogramowania, określają czynności oraz ustalają kolejność realizacji.
Zwany jest też modelem wodospadu lub liniowym i jest klasycznym modelem cyklu życia oprogramowania. Został zaproponowany przez analogię do sposobu prowadzenia przedsięwzięć w innych dziedzinach inzynierii, np. w budownictwie - określenie głównych zadań, szczegółowe określenie wymagań, wykonanie szczegółowego projektu konstrukcji, faza budowy, faza testowania, faza konserwacji.
Model kaskadowy cyklu życia oprogramowania wprowadza fazy:
W modelu kaskadowym często wyróżnia się pewne dodatkowe fazy:
Zalety modelu kaskadowego: łatwość zarządzania przedsięwzieciem, planowania, harmonogramowania i monitorowania.
W praktyce model wodospadowy nie bardzo sie sprawdza - na jaw wychodzą usterki, konieczność korygowania decyzji. W praktyce pojawiają się sprzężenie zwrotne - iteracje, przez co poprawia się jakość programowania.
Wady modelu kaskadowego:
Interpretacja ścisła traktuje fazy modelu jako nie nakładające się na siebie, interpretacja ogólna zakłada, że poszczególne fazy mają znaczenie bardziej koncepcyjne, poszczególne fragmenty systemu mogą być w tym samym czasie na różnych etapach realizacji, dopuszczalne są iteracje - nawroty do wcześniejszych faz modelu. Także w przypadku interpretacji ścisłej dopuszcza się nawroty w wypadku błędów na etapach wcześniejszych.
Wady modelu kaskadowego stały się przyczyną propozycji innych modeli cyklu życia oprogramowania.
Modele te to:
Projekt informatyczny - do jego realizacji trzeba używać narzędzi informatyki.
Fazy tworzenia projektu informatycznego:
Przeprowadzają realizujący projekt i klient ewentualnie osoba zlecająca. Np. system FK - rozeznać sposoby pracy. Wymagana umiejętność rozmowy z klientem.
Wywiad z klientem: dokładne zdefiniowanie tematu, obieg dokumentów (dla ksiegowej
oczywiste, dla programisty nie), postać wydruku,
ekranu, rodzaje dokumentów, bazy danych (zgromadzone informacje, np.
katalogi na potrzeby książek), przepływ informacji
(diagram przepływu informacji), prawa dostępu
(istotne uprawnienia, ustawa o ochronie danych osobowych)
Inwentaryzacja stanu bieżącego, określenie co
trzeba zmienić.
Projekt rozwiązania problemu (dokumentacja przedstawiana temu, dla kogo tworzymy oprogramowanie), zatwierdzenie projektu (postacie raportów, ekranów, wzorce nowych dokumentów). Powinny wykonywac grupy ludzi - analitycy systemowi, analitycy projektu - osoby niezależne od programisty
1. Wybory - sprzętu, systemu operacyjnego, języka programowania.
Oprogramowanie działa w otoczeniu: sprzęt (w sieci lub nie), SO (systemu operacyjnego), języka programowania
Sprzęt
Trzeba doradzić sprzęt - ograniczenie od góry i dołu. Czy środowisko sieciowe
- typu klient serwer czy system rozproszony
(dane gromadzone tam gdzie powstają). Nie może być sztywnych czynników w oracowaniu (np. dyski, katalogi).
Serwer - dużo pamieci operacyjne, dyski, szybki
procesor, nieistotne multimedia i grafika. Stanowiska klienta - odwrotność
wymagań serwera: ważny monitor, karta wideo, możliwości multimedialne.
System typu Klient-Serwer: programy działający na serwerze i stacji klienta - 2
programy. Program na serwerze udostępnia dane, na stacji klienta pobiera i
przekazuje dane do serwera.
System rozproszony - każdy komputer jest serwerem i klientem. Wymagane
ściągnięcie danych z każdego komputera do jednego. W systemach FK - rozwiązanie
typu klient-serwer.
Wielkości HD i RAM zależą od sytemu operacyjnego - z zapasem, za 2 lata nie
będą wystarczać.
System operacyjny
Moda na grafikę - niepotrzebne do banków - lepsze systemy UNIX-owe, w trybie
tekstowym, w sieci.
System: MS DOS (klient w sieci), W95/98/2000, Windows NT (użytkownicy, hasła),
UNIX/Linux, Novell (sieciowy).
W Windows NT zawieszenie (pad) jednego zadania nie powoduje padu innego. W
Windows 95/98 brak ograniczenia między hardwarem a programami i stąd
zawieszanie systemu.
UNIX - system bardzo stabilny. Był od początku zdefiniowany jako sieciowy. Jego
cechy to sieciowość, wielozadaniowość, wieloużytkowość
(wielu użytkowników). Działanie tekstowe szybsze. Z punktu widzenia użytkownika
trudniejszy, nie wybacza pomyłek.
Novell do poziomu 4 - serwer plików, nie ma telnetu,
usług sieciowych. Nie był pełnym systemem sieciowym. Pozwala zdefiniować prawa
dostępu. Programy ściągane do lokalnego komputera.
Język programowania
Błąd, gdy programista pisze w tym samym języku programowania.
Grupy języków programowania
2. Implementacja (kodowanie)
W fazie implementacji następuje proces kodowania (pisania oprogramowania w konkretnym języku), projekt zostaje zaimplementowany w konkretnym środowisku programistycznym oraz wykonywane są testy poszczególnych modułów
Generatory - generują aplikacje. Duża szybkość ale produkty niedotestowane.
W fazie testowania i uruchaminia następuje integracja poszczególnych modułów połączona z testowaniem poszczególnych podsystemów oraz całego oprogramowania. Zostaje sporządzona na koniec dokumentacja użytkownika, przeprowadza się instalację i szkolenie użytkownika.
1) Definicje z książki "1000 słów o komputerach i informatyce" WMON 1976.
Testowanie
programu
próba eksploatacyjna uruchomionego programu wynikowego
przeprowadzana na danych rzeczywistych lub danych modelowych dla systemu
informatycznego, w skład którego wchodzi testowany program, mający na celu
wykrycie nie ujawnionych błędów w procesie uruchamiania programu
Testowanie
systemu informatycznego
sprawdzenie działania poszczególnych programów połączonych w
określone jednostki przetwarzania na danych modelowych w celu stwierdzenia
poprawności przyjętych rozwiązań organizacyjnych systemu, poprawności działania
programów w systemie oraz poprawności merytorycznej dokumentacji systemu oraz
usunięcie ujawnionych usterek w poszczególnych elementach systemu przetwarzania
danych
Uruchamianie
programu
Działalność programisty, polegająca na sprawdzeniu
prawidłowości działania programu dla danych modelowych, pozwalających na
przetestowanie wszystkich rozwiązań organizacyjnych, informacyjnych i
algorytmicznych zastosowanych w programie oraz obejmująca usunięcie wszystkich
stwierdzonych błędów
2) Testowanie a uruchamianie programów - wg. Materiałów "Laboratorium Inżynierii Programowania" Instytutu Informatyki Politechniki Śląskiej, Gliwice 1998
Każdy program powinien być przede wszystkim niezawodny. Niezawodność łączy sie ściśle z poprawnością programu. Program jest poprawny, jeżeli zawsze działa zgodnie z sensownymi oczekiwaniami użytkownika i intencją programisty. Program prawidłowo zapisany i napisany powinien być zgodny ze swoją specyfikacją.
Testowanie to zbiór czynności wykonywanych z intencją wykrycia w programie jak największej liczby błędów. Jednym z jego głównych składników jest obserwacja zgodności produkowanych przez program wyników z wcześniej przygotowanymi poprawnymi wynikami odniesienia. Celem testowania programu jest upewnienie się, że program rozwiązuje to zadanie, do którego został zaprojektowany, i że w każdych warunkach daje poprawne wyniki. Testowanie jest to proces różny od uruchamiania programu. Program uruchomiony nie zawiera błędów sygnalizowanych przez translator i jawnie niepoprawnych fragmentów kodu oraz daje jakieś wyniki. Czy wyniki te są poprawne, zgodnie z oczekiwaniami ustalonymi w specyfikacji, pozwala ocenić testowanie. Przy testowaniu programu należy dążyć do: sprowokowania błędu, sporządzenia dokładnego opisu okoliczności, które doprowadziły do błędu, co umożliwi przejście do fazy uruchamiania w celu poszukiwania niewłaściwej pracy programu. Ważna jest liczba wykonanych testów. Testowanie gruntowne (dla wszystkich możliwych kombinacji danych wejściowych) jest prawie zawsze niemożliwe. Możliwe są 2 skrajnie odmienne podejścia do testowania: względem struktury wewnętrznej (kodu) i względem specyfikacji zewnętrznej. Wyróżnia się testowanie wstępujące (od modułów najniższego poziomu) i zstępujące (z góry - od programu głównego w dół) przy stosowaniu zaślepek zamiast nie zakodowanych modułów.
Uruchamianie to proces znajdowania i usuwania z programu błędów pierwotnych (w zasadzie tych, które ujawniły się w czasie wykonywania programu). Do uruchamiania przystępujemy zwykle po stwierdzeniu dowodów lub symptomów istnienia błędu. Obecność błędów wykrywana jest zazwyczaj w czasie procesu testowania. Należy dążyć do wykrycia jak największej liczby błędów przed przekazaniem programu użytkownikowi. Ze względu na moment ujawnienia błędy w programach można podzielić na: błędy kompilacji (sygnalizowane przy kompilacji) i błędy wykonania (przy wykonywaniu programu przez sam program lub system operacyjny, np. dzielenie przez 0, nadmiar). Błędne wyniki nie są jawnie sygnalizowane - powinny być dostrzeżone w czasie testowania. Na etapie kodowania (pisania tekstu programu) programista może popełnić najwięcej błędów. Są takie kategorie błędów jak: błędy syntaktyczne (np. brak średnika, nawiasu, nieprawidłowy symbol), błędy semantyczne (np. brak deklaracji, niezgodność typów w wyrazeniu, przekroczenie zakresu, niedozwolona wartość argumentu). Inne błędy zaliczamy do błędów logicznych, np. użycie pętli repeat zamiast while, użycie nieodpowiedniego wzoru, brak inicjalizacji.
Testowanie a uruchamianie
Testowanie i uruchamianie przeplatają się. Testując nie wiemy, czy w programie są jakieś błędy, a uruchamiając wiemy, że błąd jest. Po napisaniu całego programu, gdy kompilator dostarczy kod wynikowy, najczęściej testujemy "na dym", przyjmując proste dane testowe. Wykrywamy wtedy grube błędy i przechodzimy do uruchamiania, kiedy to lokalizujemy błędy i je usuwamy. Z kolei wracamy do testowania, przygotowując bardziej finezyjne dane testowe, co pozwala na ujawnienie drobniejszych lub rzadziej występujących błędów. Wracamy do uruchamiania i w ten sposób testowanie przeplata sie z uruchamianiem, przy czym dane testowe i błędy są coraz bardziej wyrafinowane.
W fazie eksploatacji oprogramowanie jest wykorzystywane przez użytkownika(ów), a producent dokonuje konserwacji oprogramowania - modyfikacje polegające na usuwaniu błędów, zmiany i rozszerzenia funkcji systemu (pielęgnacja systemu).
Program, który nie musi być poprawny można uczynić tak sprawnym, ile dusza zapragnie - Dennie Van Tassel
Powyższa zasada przypomina, że w dążeniu do usprawniania (optymalizacji)
programów musimy mieć na uwadze, że podstawowym wymaganiem jest niezawodność.
Następnie, jeśli program jest pożyteczny można myślec
o optymalizacji.
Optymalizacja programu może być czasowa lub pamieciowa.
Pierwszy krok - logiczna reprezentacja danych w systemie. Najbardziej przyjął się model relacyjny - wykorzystywany w 90%.
Dane przechowywane są w tabelach. Tabela składa się z wierszy i kolumn. Wiersz symbolizuje konkretne wystąpienie obiektu, np. Osoba. W modelowaniu nie stosuje się pojęcia tabela a ENCJA - symbolizuje obiekt występujący w rzeczywistości. Encja - porcja danych n.t. osoby, np. Kowalski. Wystąpienie encji - Entity instance. Fizyczna realizacja to tabela. Atrybuty encji. Każda encja - porcja danych.
Generalizacja - grupowanie różnych encji. Encja bardziej generalna - bazowa, np. Osoba. Podtypy - np. Pracownik Pokrywa się to z dziedziczeniem. W modelu znajduje odzwierciedlenie powiązanie - relacja - model relacyjny.
Graficzna reprezentacja modelu
Diagramy związków i encji: ERD (Entity Relationship Diagram), E-R.
Notacje:
System Engineer
Listy i tabele asocjacji
Data Model Subset - podzbiory.
Wygenerowanie skryptu DDL (database description language). Generatory na różne platformy sprzętowe.
Koncepcja strukturalna - jak całościowo potraktować koncepcję strukturalną. Koncepcja zaproponowana przez twórców pakietu - niezależna praca różnych zespołów. Etapy
Wersja tańsza dla analityków i droższa dla projektantów (patrz niżej).
Inżynieria oprogramowania nie wyróżnia osobnej fazy poświęconej wyłącznie analizie problemu. Fazę analizy traktuje się raczej jako okres łączacy etap formułowania wymagań względem systemu z etapem projektowym. Celem drugiego jest przygotowanie szczegółowych planów i projektów budowy systemu.
Aby dobrze zidentyfikować fazę analizy należy zastanowić się, jaki jest jej zasadniczy cel. Najlepiej to zrobić definiując szczegółowe założenia i cele fazy poprzedzajacej i kończącej fazę analizy.
Zasadniczym celem fazy formułowania wymagań jest udzielenie odpowiedzi na pytanie: co i przy jakich założeniach system ma robić? W fazie tej dokonywana jest zamiana celów klienta na konkretne wymagania zapewniające określenie tych celów. Proces określania wymagań nalezy rozumieć nie jako proste zbieranie informacji o wymaganiach, lecz jako proces, w którym klient samodzielnie (albo wspólnie z przedstawicielami producenta - analitykami) konstruuje zbiór wymagań zgodny z postawionymi celami.
Celem fazy projektowej jest przygotowanie dokumentacji umożliwiajacej stworzenie oprogramowania. Efektem fazy musi być dokumentacja zawierajaca dane szczegółowe projektu stosowanych struktur danych oraz funkcji oprogramowania. Dokumentacja musi być wystarczająco szczegółowa, tzn. opierać się na możliwosciach jakich dostarcza stosowany system implementacyjny oraz stosowane mechanizmy bazodanowe.
Celem fazy analizy jest udzielenie odpowiedzi na pytanie w jaki sposób system ma działać. Wynikiem fazy jest logiczny model systemu opisujący sposób realizacji przez system postawionych wymagań, lecz abstrahujacy od szczegółów implemantacyjnych. Faza ta nosi też nazwę fazy modelowania.
Tworzony model zwykle stanowić będzie fragment dziedziny problemu. Przykłady to działalność firmy budowlanej, obsługa lotniska itp. Fragment dziedziny, który powinien zostać objęty przez system to zakres odpowiedzialności systemu.
Modele stosowane w fazie analizy wykorzystuje sie w tzw. reinżynierii procesów biznesowych. Operacja ta zaczyna się od stworzenia modelu aktualnego sposobu funkcjonowania organizacji, abyn potem dokonać jej modyfikacji służących poprawie sposobu realizowania przez nią swoich głównych funkcji.
Składowe inżynierii oprogramowania w fazie analizy:
Istnieją 2 główne metody analizy.
Tradycyjne metody noszą nazwę strukturalnych. Opierają się na rozłącznym analizowaniu 2 składowych problemu: składowych pasywnych, odzwierciadlających fakt przechowywania w systemie pewnych danych (modele danych) oraz składowych aktywnych, odzwierciadlających wykonywanie w systemie pewnych operacji (modele procesów)
Analiza strukturalna rozpoczyna się od budowy 2 różnych modeli systemu. Pierwszy to model danych (model związków encj) - ERD, drugi model procesów. Te 2 model są następnie integrowane w model przepływów danych - DFD. Metody te wykorzystuje się głównie gdy jedna ze składowych problemów wyraźnie dominuje nad drugą; modele te są ukierunkowane raczej na współpracę z relacyjnymi bazami danych. Nie istnieje prosta odpowiedź na pytanie który z diagramów DFD czy ERD powinien być modelowany jako pierwszy.
Modele obiektowe integrują w sobie składowanie danych i procesy.
Narzędzia CASE pojawiły sie w latach 80-ch. Termina CASE (Computer aided software egineering) oznacza wspomagane komputerowo projektowanie oprogramowania i przyjął się dla oznaczania pakietów oprogramowania ułatwiających prowadzenie projektów na wszystkich etapach projektu, zgodnie z założeniami modelu kaskadowego.
Dwa najważniejsze elementy analizy i modelowania strukturalnego to modele procesów i danych.
Pakiet umożliwia niezależną pracę zespołu zajmującego się sferą modelowania procesów oraz zespołu analizującego dziedzinę danych.
Pakiet wykorzystuje się dwuetapowo:
Rozdzielenie procesu analizy od projektowania znalazło swoje odbicie w ofercie handlowej firmy rozprowadzającej system. Dostępna jest wersja tańsza dla analityków oraz droższa dla projektantów. Wersja dla analityków zawiera elementy projektowania, nie pozwala jednak na automatyczne przeniesienie jego wyników na fizyczną platformę języków programowania baz danych.
W pakiecie System Engineer wprowadzono korzystną
możliwość rozbicia modelowania na 2 poziomy: Logiczny i Fizyczny, co dotyczy
modelu danych jak i modelu procesów.
|
zagadnienie |
|
|
|
| |
|
poziom logiczny |
|
|
|
| |
|
poziom fizyczny |
|
|
|
| |
|
system informatyczny |
|
Na podstawie wyników analizy tworzy się modele logiczne, które oddają strukturę modelowego zagasnienia. Po zakończeniu prac nad modelami logicznymi przechodzi się na poziom fizyczny.
Kontrola spójności modelu danych i procesów
Aby zaradzić powstawaniu rozbieżności pomiędzy modelem danych i procesów, stosuje się wzajemne scalanie elementów jednego i drugiego modelu.
Elementy modeli asocjuje się zgodnie z tabelą:
|
Encja |
Proces |
|
Encja |
Zbiornik |
|
Dana
elementarna |
Zbiornik |
|
Dana
elementarna |
Przepływ |
Dane łączy się z procesami, aby uwidocznić fakt, że istotą procesów w docelowym systemie jest przetwarzanie, zbieranie i gromadzenie danych o odpowiedniej strukturze. Struktura danych wynika z modelu danych, natomiast sposób ich gromadzenia i przetwarzania wynika z modelu procesów.
W pakiecie LBMS modelowanie procesów obejmuje stworzenie diagramów hierarchii procesów (PHD - Process Hierarchy Diagram), diagramu przepływu danych (DFD - Data Flow Diagram) oraz diagramu zależności procesów (PDD - Process Dependency Diagram). Diagram hierarchii procesów przedstawia dekompozycję procesu na podprocesy, diagram DFD przedstawia jakie dane przepływają pomiędzy procesami, a PDD jaka jest wzajemna zależność procesów.
Diagram przepływu danych jest metodą graficznego opisu przepływu danych i operacji wykonywanych w obrębie systemu. Diagramy hierarchii procesów i przepływu danych są ze sobą skorelowane.
Najczęściej stosowaną techniką modelowania przepływów jest technika zstępujaca, polegająca na kolejnym dekomponowaniu podprocesów, wg schematu:
W diagramach stosowanych w pakiecie LBMS stosuje się odpowiednią notację graficzną, w której występują takie pojęcia jak:
|
Proces |
Odzwierciedla
fragment działalnosci modelowego systemu; opisywany
jest przez numer, nazwę, szczegółowy opis oraz lokalizację |
|
Zbiornik danych |
Miejsce,
w którym przechowywane są dane; terminator opisywany jest przez numer, nazwę,
typ (np. w LBMS D - dane permanentne, T - tymczasowe, M - manualne),
szczegółowy opis, zbiór atrybutów, które zbiornik przechowuje |
|
Terminator |
Oznacza
osobę, instytucję lub inny system, który wymienia dane z dekomponowanym
procesem. Terminator opisywany jest przez numer, nazwę oraz szczegółowy opis |
|
Przepływ |
Odpowiada
wymianie informacji pomiędzy terminatorami, procesami i zbiornikowi danych.
Przepływ opisywany jest przez nazwę, numer oraz atrybuty przenoszone w
przepływie |
Do graficznej reprezentacji modeli danych opartych na koncepcji relacyjnej służą tzw. diagramy encji i związków (ERD - Entity-Realtionship Diagram). Na diagramach tych umieszcza się elementy reprezentujące encje i związki oraz ich atrybuty, jak również informacje dotyczące krotności związków i rozbicia encji na podtypy. Stosuje się przy tym różne notacje.
Twórcy pakietu CASE LBMS System Engineer zaproponowali dość rozbudowaną notację, która uwidacznia krotność i obligatoryjność związków. Oddaje również sposób pokrycia dla podtypu.