Wykorzystanie technik i

metod strukturalnych

Istota problemu

Zarządzanie projektem to proces złożony z
pogranicza nauki o zarządzaniu i sztuki. Polega
na definiowaniu celów i ich osiąganiu (zgodnie z
ustalonym czasem i budżetem). Kluczowym
elementem jest więc odpowiednia organizacja
projektu i szukanie odpowiedzi na następujące
pytania:

Co należy robić?

W jakim czasie?

W jakiej kolejności?

Z wykorzystaniem jakich zasobów?

Jaką technologię zastosować?

Metody i techniki strukturalne



Przedstawić pojęcia metod i technik strukturalnych



Powszechnie

stosowane

techniki

strukturalne

(inżynieria informacji, STRADIS, SSDAM)



Powszechnie stosowane metody strukturalne (ERD,

DFD, HPD, ELH)



Przedstawić za pomocą przykładów podstawowe

notacje oraz sposób ich użycia do budowania modeli
systemu;



Przedstawić wnioski wynikające z zastosowania

omawianych metod i technik strukturalnych

Jakich pojęć, notacji, modeli formalnych, języków i
sposobów postępowania służący do analizy
rzeczywistości (stanowiącej przedmiot projektowanego
systemu informatycznego) oraz do projektowania
pojęciowego, logicznego i/lub fizycznego należy użyć
aby skutecznie poradzić sobie z realizacją
projektu informatycznego.

Jak metody i techniki strukturalne pomagają
w osiągnięciu celu jakim jest zrealizowanie
projektu informatycznego.

Sformułowanie problemu

Techniki strukturalne

Technika:

• metoda osiągnięcia celu,

• sposób,

• styl,

• tryb,

• wiersz,

• procedura,

• proces,

• sposób działania.

Opis i charakterystyka

zjawiska

Analiza danych

Celem analizy danych jest

opracowanie trwałej podstawy
systemów aplikacyjnych. Końcowym
wynikiem tej analizy jest zbiór struktur
danych odpowiednich dla pewnych
aplikacji określany mianem modelu
danych.

Diagramy encja-związek (Entity-

Relationship, E-R model)

Modelowanie informacji jest techniką
organizacji przechowywania danych.
Modele danych można opracowywać na
różnych poziomach szczegółowości,
wykorzystując diagram związków encji
Podstawowymi pojęciami tego modelu
są:

• encja

• atrybut

• związek

Encja

Encja - rzecz mająca znaczenie, rzeczywista lub
wymyślona, o której informacje należy znać lub
przechowywać.
Encją może być obiekt fizyczny, np. dom lub
samochód, zdarzenie, np. sprzedaż domu lub
naprawa samochodu, lub pojęcie, np. transakcja
lub zamówienie.

Klient

RachunekBankowy

Oddział

Związek

Związek - znaczący sposób, w jaki mogą być ze
sobą powiązane dwie rzeczy tego samego typu lub
różnych typów

Stanowi naturalne powiązanie pomiędzy dwoma lub
więcej encjami. W identyfikowaniu i modelowaniu
związków encji bierze się pod uwagę stopień
związku i opcjonalność.

Klient

RachunekBankowy

posiada

Klient

RachunekBankowy

posiada

Atrybut

Atrybut - element informacji służący do
klasyfikowania identyfikowania,
kwalifikowania, określania ilości lub wyrażania
stanu encji.
Encja jest agregacją atrybutów. Wartości
przydzielane do atrybutów są używane do
rozróżnienia jednej encji od drugiej.

NrKlienta

NazwaKlienta

Klient

RachnekBankowy

NrRachunku

NazwaRachunku

posiada

Tworzenie schematu

relacyjnego

ERD rysowane są zwykle w celu
zaprojektowania schematu
relacyjnego.
Proces przekształcania ERD w projekt
relacyjnej bazy danych nazywany
jest akomodacją.

Akomodacja

• Rozbicie każdego związku wiele do wielu na

dwa związki jeden do wielu.

• Dla każdej encji na diagramie tworzymy

tabelę, zwykle
zmieniając nazwę encji na rzeczownik w liczbie
mnogiej.

• Atrybut identyfikujący każdej encji staje się

kluczem
głównym tabeli.

• Pozostałe atrybuty encji stają się atrybutami

niekluczowymi tabeli.

• Dla każdego związku jeden do wielu

wstawiamy
klucz główny z końca „jeden” związku do
tabeli
na końcu „wiele” związku.

Notacja nawiasowa

Wydziały (nrWydziału, nazwaWydziału,...)
Pracownicy (nrPracownika, nazwiskoPracownika, nrWydziału,...)
Wykłady (nrWykładu, nazwaWykładu,...)
Studenci (nrStudenta, nazwiskoStudenta,...)
Przydział (nr, pracownika, nrWykładu,...)
Zgłoszenie (nrStudenta, nrWykładu,...)

Przykład ERD po akomodacji

Wnioski

Modelowanie encji, którego przykładem
jest technika diagramów E-R, jest
podstawową techniką projektowania
bazy danych.
Diagram E-R nazywany jest

modelem

koncepcyjnym systemu baz danych

Na jego podstawie otrzymujemy model
logiczny w postaci struktur tablicowych
w trzeciej postaci normalnej.

Analiza procesów

Analiza procesów ujmuje system
informacyjny w sposób dynamiczny.
Metody analizy procesów koncentrują się na
ruchu oraz na przekształcaniu danych w
ramach systemów.
Analiza procesów i analiza danych muszą
być wzajemnie powiązane. Struktura danych
określa funkcje, które mogą być
wykonywane za pomocą danych i odwrotnie.

Analiza procesów

Model procesów jest abstrakcyjną

reprezentacją działań związanych z

aplikacją. Istnieje wiele technik

umożliwiających utworzenie takiego

modelu. Najbardziej znana jest

technika

diagramów przepływu danych

Technika ta jest zwykle wspierana przez

dwie inne: opisy procesów i słowniki

danych. Historie życia encji są

przydatnym zorientowanym na procesy

dodatkiem do modelowania encji.

Diagram przepływu danych

(Data Flow Diagram - DFD)

Przedstawia w jaki sposób dane

przepływają w systemie oraz opisuje

procesy przetwarzające dane. Tworzenie

diagramu DFD opiera się na następujących

kategoriach pojęciowych: proces, przepływ

danych, magazyn danych, encja

zewnętrzna, i odpowiadających im

symbolach graficznych. Szczegółowy opis

wszystkich kategorii występujących na

DFD zawarty jest w słowniku danych.

Proces

Oznacza transformację danych
wejściowych w wynikowe i odpowiada
tym składnikom systemu, które
przetwarzają dane. Procesy otrzymują i
przesyłają dane w postaci przepływów
danych. Nazwa procesu powinna
opisywać czynność wykonywaną na
określonym obiekcie, jak np.:
wystawienie faktury dla odbiorcy.

Wystawienie faktury

dla odbiorcy

Przepływ danych

Opisuje zbiór danych
przepływających pomiędzy dwoma
obiektami w systemie. Przedstawia
się go za pomocą strzałki z etykietą.
Nazwa przepływu to rzeczownik w
liczbie pojedynczej. Przykładowe
przepływy danych to: kwestionariusz
osobowy, umowa, faktura dla klienta.

Faktura dla klienta

Magazyn danych

Służy do przechowywania danych w
postaci jednorodnych kolekcji.
Zaistnienie magazynu danych w
diagramie ma sens, gdy
przechowywane dane służą do
realizacji co najmniej dwóch
procesów. Nazwa magazynu danych
to rzeczownik w liczbie mnogiej np.:
pracownicy, towary, faktury.

Pracownicy

Encja zewnętrzna

(terminator)

Encja zewnętrzna jest czymś (zwykle
osobą, działem lub organizacją) leżącym
na zewnątrz systemu, co jest tylko
nadawcą lub odbiorcą danych systemu.
Na DFD jest przedstawiana za pomocą
koła lub owalu z odpowiednią nazwą
Encje zewnętrzne na DFD nie powinny
być mylone z encjami na diagramach E-
R!

Odbiorca

Bank

Rozszerzenie notacji

Wielopoziomowość

Modelowanie funkcji systemu polega na

stworzeniu hierarchicznej grupy diagramów.
Diagram kontekstowy (diagram DFD

poziomu zerowego) jest specjalnym

graficznym schematem przepływu danych,

który definiuje zakres i granice systemu.
Następnie tworzony jest diagram

systemowy, ukazujący główne funkcje

systemu. Każda funkcja jest przedstawiona

w postaci hierarchicznej grupy diagramów

niższego poziomu.
Diagramy niższych poziomów to diagramy

szczegółowe.

Wnioski

1. DFD składa się z procesów, przepływów danych,

encji zewnętrznych i magazynów danych.

2. DFD jest częścią wielopoziomowego zbioru

diagramów.

3. DFD jest obsługiwany przez słownik danych.

Większość współczesnych metodyk opracowywania

systemów

informacyjnych wykorzystuje w pewien sposób tę

technikę.

DFD jest niezwykle efektywną techniką analizy

procesów,

którą można zastosować w różny sposób na wielu

różnych

etapach standardowego cyklu życia projektu.

Opis procesu

1. Język strukturalny i pseudokod.
2. Sformatowane wykresy i diagramy
3. Tabele decyzyjne i drzewa.

Język strukturalny

ObsługaSprzedaży

BEGIN

Przyjmij paragon
READ rekordKlienta FROM Klienci
READ rekordProduktu FROM Produkty
ogólna Wartość Sprzedaży = sprzedanaIlość *

cenaJednostkowa

KredytKlienta = kredytKlienta + ogólna WartośćSprzedaży
UPDATE kredytKlienta ON rekordKlienta
CREATE rekordSprzedaży
CREATE notaSprzedaży
WRITE rekordKlienta TO Klienci
WRITE rekordSprzedaży TO Sprzedaż
SEND notaSprzedaży TO klient

END

Diagramy sformatowane

Tabele decyzyjne

Drzewa decyzyjne

Wnioski

Omówione techniki dokumentowania
procesów znajdują zastosowanie zarówno
przy projektowaniu, jak i przy analizie. Język
strukturalny lub jego wariant, np. diagram
działań, jest zwykle preferowaną metodą
dokumentowania procesów. Tabele decyzyjne
i drzewa decyzyjne są bardziej przydatne
przy wyborze jednego działania spośród
dużej liczby działań lub przy podejmowaniu
działań zależnych od wielu warunków.

Słowniki danych

Słownik jest repozytorium wszystkich
terminów (składników modeli : wejść,
wyjść, obiektów itd.) używanych w
projekcie, w szczególności zawiera
definicje wszystkich atrybutów
użytych w opisach typów obiektów i
relacji.

Elementy składni:

składa się

( )

opcja

{ }

iteracja

[ ]

wybranie jednej z wielu możliwości



separator alternatyw w formule [ ]

* *

początek/koniec komentarza

identyfikator (pole kluczowe)

Przykład:

zamówienie = nazwa_klienta +

adres_klienta + {towar}

płeć = [MK]

Nazwa przepływu
danych:

faktura

Opis:

informacje dotyczące zamówienia, za które
jest wystawiana faktura dla klienta

Z procesu:

4.1 przygotowanie faktury

Do procesu:

4.2 przydzielenie numeru faktury

Struktury danych:

faktura

Nazwa procesu:

1.0 wprowadzanie zamówienia

Opis:

zamówienie klienta przyjęte i zatwierdzone
do dalszego przetwarzania

Przepływy
wchodzące:

zatwierdzone zamówienie

Przepływy
wychodzące:

informacje zamówienia

Magazyn danych:

zatwierdzone zamówienia

Opis:

lista otrzymanych towarów, koszt każdego
towaru i podpis pracownika przyjmującego

Przepływy
wchodzące:

faktura

Przepływy
wychodzące:

pogrupowane informacje faktury

Opis:

zatwierdzona faktura = faktura + podpis

Ilość:

200 dziennie

Dostęp:

dostępne w partiach. Sekwencyjne
przetwarzanie każdej partii.

Nazwa encji:

odbiorca

Identyfikator:

nrOdbiorcy

Atrybuty:

nazwaOdbiorcy, adres, nrTel

Nazwa związku:

składaZamówienie

Nazwa encji:

odbiorca

Stopień:

Uczestnictwo:

opcjonalne

Stopień:

Uczestnictwo:

wymagane

Wnioski

Oprócz roli uzupełniającej zbiór DPD i/lub model

encji, słownik danych ma wiele innych zastosowań

w procesie tworzenia systemów informacyjnych:

1. Jako środek wymuszający standardowy zbiór

reprezentacji danych dla zespołu podejmującego

zadanie projektowania oprogramowania.

2. Jako środek kontroli spójności i kompletności

reprezentacji systemu informacyjnego.

3. Jeśli, słownik jest dostatecznie obszerny i

rygorystyczny, to możliwe jest na jego podstawie

wygenerowanie czytelnych dla maszyny definicji

danych, a nawet programów.

Historie życia encji

• Historia życia encji (Entity Life History,

ELH) była pierwotnie przeznaczona do

rozszerzenia istniejących technik,

takich jak diagramy E-R. Takie metody

analizy danych koncentrują się głownie

na statycznym ujęciu modelowanego

systemu informacyjnego. W

przeciwieństwie do tego ELH rozwinęła

się jako technika służąca do jawnego

modelowania dynamiki systemu

Cel ELH

• Diagramy ELH pokazują użycie

poszczególnych encji przez procesy
lub zdarzenia składające się na
system informacyjny. Dlatego jej
głównym celem jest oferowanie
środka do połączenia encji
pokazanych szczegółowo na
diagramach E-R z procesami
przedstawionymi na diagramach DFD.

ELH

• rozwój ELH pomaga analitykom lepiej

zrozumieć encje

• jest to pierwszy krok w

dokumentowaniu szczegółowego szkicu
procesów

ELH jest więc bardzo przydatną
techniką sprawdzania poprawności
DPD.

Konwencje rysowania ELH

• Notacja oparta na teorii sieci Petriego
• Notacja podobna do sieci

wyprowadzona z harmonogramu
PERT.

• Konwencja hierarchiczna

Tworzenie ELH

1. Utworzenie listy encji na

podstawie diagramów E-R.

2. Utworzenie listy zdarzeń na

podstawie DPD.

3. Konstrukcja macierzy ELH.
4. Utworzenie ELH dla każdej encji.

Lista encji

• Encje stosowane w zbiorze ELH są

zwykle brane bezpośrednio z
diagramu E-R lub ze zbioru
diagramów E-R. W prostym systemie
bibliotecznym możemy mieć
następujące encje: Książka,
Czytelnik, Rezerwacja,
Wypożyczenie.

Lista zdarzeń

• Zdarzenia pochodzą ze zbioru DPD

dokumentujących system informacyjny.

• zdarzenie zmienia stan encji np..:

Książka z „zakupiona" na „skatalogowana".
Zdarzenia mogą być klasyfikowane ze

względu na efekt, jaki wywierają na życie

encji:

– zdarzenia tworzenia (C)
– zdarzenia odczytu (R)
– zdarzenia zmiany (A)
– zdarzenia usuwania (D)

Lista zdarzeń - przykład

1. Tworzenie czytelnika - zdarzenie C dla encji

Czytelnik.

2. Zakup książki - zdarzenie C dla encji

Książka.

3. Katalogowanie książki - zdarzenie A dla

encji Książka.

4. Wypożyczanie książki - zdarzenie A dla

encji Czytelnik i Książka. Zdarzenie D dla

encji Rezerwacja oraz zdarzenie C dla encji

Wypożyczenie.

5. Sprzedaż książki - zdarzenie D dla encji

Książka.

Tworzenie macierzy ELH

Można utworzyć macierz
dwuwymiarową, w której każda
komórka reprezentuje działanie
zdarzenia na encję.

Książka

Czytelnik

Rezerwacja

Wypożyczenie

Utworzenie czytelnika

Zakup książki

Katalogowanie książki

Wypożyczenie książki

Rezerwacja książki

Sprzedaż książki

Tworzenie ELH

• Najprostszym sposobem tworzenia

ELH jest rozpoczęcie od prostego
życia encji i kolejne dodawanie
złożoności.

Książka

Zakup

Katalog

Wypożyczenie

Sprzedaż

Książka

Zakup

Katalog

Życie biblioteki Sprzedaż

ZamówienieOtrzymanie Zapłata

Wypożyczenie *

Książka

Zakup

Katalog

Życie biblioteki Sprzedaż

ZamówienieOtrzymanie Zapłata

Wypożyczenie *

Rejestracja

informacji

szczegółowych

Stemplowanie

książki

Wydanie

książki

Zwrot

Zwrócona O

książka

Zwrot O

Po terminie

Żądanie zwrotu

Diagram przejść stanów

Stan 1

Stan 2

Stan 3

Zdarzenie[warunek]/akcja

Wnioski

• ELH stanowi uzupełnienie diagramów

E-R, a także DFD.

• ELH mogą być użyte na etapie

studium wykonalności, analizy i
projektowania w wypadku
standardowego cyklu życia projektu.

Metody

Metoda: sposób wykonania czegoś,
system procedur, świadoma
powtarzalność, uporządkowanie.
Stan porządku, zasada, regularność,
dyscyplina.

Metoda a technika

Technika jest specyficznym
podejściem do tworzenia pewnego
produktu przy opracowywaniu
systemów informacyjnych, natomiast
metoda stanowi pewne ramy
organizacyjne dla zastosowania tej
techniki.

Elementy składowe metody

•

Model cyklu życia SI

•

Zbiór technik

•

Metody dokumentacji związane z tymi

technikami
Metody mogą również zawierać:

Strategię określającą sposób kierowania

projektami

Strategię szkolenia nowych użytkowników metod

Strategię określającą zestaw pomocnych

narzędzi i etap na którym należy z nich

skorzystać

Dlaczego warto stosować

standardowe metody?

•

Projektanci nie muszą poświęcać czasu na tworzenie

nowej metody dla każdego nowego projektu.

•

Łatwiej jest szkolić nowych członków zespołów

projektowych w procesie tworzenia systemu.

•

Zastosowanie metody standardowej ułatwia zarządzanie

projektem i oszacowanie czasu jego trwania.

•

Metoda standardowa ułatwia komunikację nie tylko z

projektantami, ale również z użytkownikami końcowymi.

•

Metody standardowe sprzyjają automatyzacji procesu

projektowego.

•

Lepsza specyfikacja systemów oraz tworzenie

szczegółowej dokumentacji związane z zastosowaniem

metody ułatwia pielęgnację i usprawnienie systemów

informacyjnych.

Czynniki charakteryzujące

metodę

• Ogólna filozofia - zbiór zasad leżących u podstaw metody. Na

przykład, czy dana metoda opiera się na obiektywnym czy

subiektywnym spojrzeniu na rzeczywistość.

• Proces opracowania. Ogólny model obsługiwanego procesu

projektowego.

• Techniki. Na przykład diagramy E-R, DFD.
• Zautomatyzowane wsparcie. Miejsce automatycznego

wsparcia w ramach danej metody. Czy istnieją narzędzia

CAISE do obsługi działań danej metody.

• Zakres. Czy obejmuje ona analizę przedsiębiorstwa, jak

również opracowanie systemów informacyjnych.

• Użytkownicy. Spodziewani i aktualni użytkownicy danej

metody.

• Produkt. Główny produkt tworzony przez daną metodę. Na

przykład, czy metoda kończy się na etapie projektowania,

czy też jest oczekiwany działający produkt.

Analiza strukturalna

systemów STRADIS

• Utworzona przez Gane’a i Sarsona

(1977)

• Rozwijana przez wiele lat na

podstawie praktycznych zastosowań

• Zawiera większość klasycznych

elementów podejścia opartego na
procesach

Tworzenie DFD dla aktualnego

systemu fizycznego

Tworzenie DFD dla

aktualnego

systemu logicznego

Określenie dziedziny

zmian

Tworzenie DFD dla

nowego

systemu fizycznego

Tworzenie DFD dla

nowego

systemu logicznego

Tworzenie słownika

danych

Tworzenie opisów

procesów

Normalizacja słownika

danych

Tworzenie schematów

strukturalnych

Tworzenie struktury

plików

Tworzenie pseudokodu

Inżynieria informacji

Inżynieria informacji może być traktowana

jako ewolucyjny rozwój wcześniejszej metody

o nazwie D2S2. W swojej obecnej postaci

inżynieria informacji jest metodą złożoną,

która wykazuje wiele elementów podejścia

integracyjnego. Skonstruowana jest na bazie

zbioru zintegrowanych technik graficznych,

które przyczyniają się do definiowania modelu

danego systemu informacyjnego. Model ten

jest przechowywany w aktywnej encyklopedii.

SSADM (Structured Systems Analysis

and Design Method)

Metoda ta powstała jako efekt realizacji

wspólnego projektu standardowej metody

analizy i projektowania dla organizacji sektora

publicznego.
SSADM jest standardem otwartym, tzn. jest

łatwo dostępna do stosowania w państwowym

i prywatnym sektorze przemysłu. Metoda ta

jest obecnie obowiązkową procedurą dla

większości projektów informatycznych sektora

publicznego. Użytkownikami jej jest też wiele

organizacji gospodarczych.

Kierownictwo

projektu

Moduł 3:

Specyfikacja

wymagań

Moduł 4:

Specyfikacja

systemu

logicznego

Moduł 1:

Studium

zastosowalności

Moduł 2:

Analiza

wymagań

Moduł 5:

Specyfikacja

systemu

fizycznego

Zespół

realizacyjny

Wstępny dokument projektu

Założenia projektu

Raport o

zastosowalności

Opis aktualnego otoczenia przedsiębiorstwa

Katalog wymagań

Wybrane opcje systemu przedsiębiorstwa

Struktury

menu

i poleceń

Raport z

prototypowaniaSpecyfikacja

wymagań

Opis środowiska technicznego

Projektowanie logiczne

Specyfikacja systemu fizycznego

Porównanie metod

Ogólna filozofia: Wszystkie omówione
metody odpowiadają realistycznemu
spojrzeniu na rzeczywistość. Inaczej
mówiąc, zakładają one, że istniejąca
rzeczywistość jest taka sama dla
każdego. Zadaniem projektanta
systemów informacyjnych jest
wydzielenie głównych elementów tej
rzeczywistości w postaci systemu
informacyjnego.

Porównanie metod

Model opracowania: Wszystkie trzy
metody odpowiadają modelowi
kaskadowemu opracowania
systemów informacyjnych. Inżynieria
informacji zachęca do korzystania z
prototypów jako równoległego
strumienia opracowywania, a SSADM
do prototypowania jako narzędzia
objaśniającego wymagania.

Porównanie metod

Techniki: Inżynieria informacji i
SSADM korzystają z wielu podobnych
technik, chociaż pierwsza próbuje
podkreślić znaczenie analizy danych.
STRADIS koncentruje się na
stosowaniu DFD i słowników danych.

Porównanie metod

Narzędzia wspierające: Wszystkie
trzy metody oferują pewien rodzaj
automatyzacji. Wiele zintegrowanych
narzędzi CAISE utworzono specjalnie
dla SSADM. Inżynieria informacji jest
obecnie obsługiwana przez dwa
środowiska CAISE: Information
Engineering Facility oraz Information
Engineering Workbench.