Notatki do APSI - 1999/2000

Notatki do APSI - 1999/2000
________________________________________________
M. Muraszkiewicz
MODUŁ I
Wykład ma charakter propedeutyczny i adresowany jest do osób zainteresowanych
kierowaniem projektami, których celem jest zbudowanie systemów informacyjnych.
Do tej pory studenci głównie zapoznawali się z metodami budowy oprogramowania, a nie
złożonych systemów informacyjnych.
Projektowanie i realizacja systemów informacyjnych są zwykle bardziej złożone niż
projektowanie oprogramowania. Często, choć nie zawsze, projektowanie i realizacja
oprogramowania jest częścią realizacji systemu informacyjnego.
Projektowanie systemów informacyjnych jest najczęściej przedsięwzięciem zespołowym, co
ma znaczny wpływ na sposób jego zorganizowania i realizacji. Kierowanie pracami
projektowymi wymaga kwalifikacji i doświadczenia m.in. w zakresie:
• budowania i funkcjonowania systemów informacyjnych,
• zarządzania projektowymi pracami zespołowymi (w tym umiejętności
rozwiązywania konfliktów),
• dziedziny, której dotyczy projektowany system.
Pomimo znacznych postępów w obszarze metod projektowania systemów informacyjnych
jest to wciąż bardziej "rzemiosło" niż "nauka". Doświadczenie, intuicja i osobowość
członków zespołu projektowego, a szczególnie kierownictwa, maja kluczowe znaczenie dla
powodzenia, lub porażki, przedsięwzięcia.
Terminy podstawowe, didaskalia
Morfologia tytułu wykładu:
Analiza
dekompozycja, opis elementów składowych, określenie i zbadanie
powiązań pomiędzy tymi elementami.
Projektowanie
dwa znaczenia: (i) tworzenie koncepcji, (ii) tworzenie koncepcji i
realizacja.
System informacyjny
nie ma powszechnie przyjętej definicji systemu informacyjnego;
zależy ona od definiującego, jego wiedzy, potrzeb i interesów. Oto
definicja szkieletowa w postaci n-tki uporządkowanej:
komponent
Funkcja celu
Model danych
formalizacja
1
2
Model procesów
Baza danych
Język interakcji (zwłaszcza wyszukiwanie)
Sprzęt
Oprogramowanie
Wydajność
Administracja systemu i utrzymanie go w ruchu
Mechanizmy ochrony danych i praw dostępu
Ludzie (personel, użytkownicy)
Aspekty finansowe
Otoczenie
...
2
3
3
2
3
3
2
3
0
2
0
0 - nie poddaje się formalizacji
1 - w pewnym stopniu
2 - w znacznym stopniu
3 - w bardzo znacznym stopniu
Uwaga:
system informatyczny ⊂ system informacyjny
dość często, acz niesłusznie, oba terminy używane są jako synonimy.
Projektowanie systemu informacyjnego - rozumiane w drugim znaczeniu, a więc jako
czynności przygotowawcze i koncepcyjne oraz implementacja - jest procesem, co oznacza, iż
jest skończonym ciągiem kroków (czynności) powiązanych ze sobą relacjami, które mają
doprowadzić do osiągnięcia zamierzonego celu w postaci systemu spełniającego przyjęte
wymagania. W procesie projektowania możliwe są pętle (ale nie nieskończone).
Określenie zbioru najważniejszych parametrów charakteryzujących proces projektowania i
sam system zależy od tego kto je definiuje. Przykładowa dla zleceniodawcy mogą to być:
• parametry funkcjonalne systemu,
• ergonomiczność systemu,
• nakłady oraz rzeczywisty koszt,
• czas realizacji systemu,
• koszty eksploatacji i rozwoju systemu,
• kompatybilność ze współdziałającymi systemami,
• prestiż.
Zapewne inny zestaw parametrów poda wykonawca systemu.
Metoda projektowania systemów informacyjnych jest zbiorem zasad dotyczących tworzenia
komponentów systemu i łączenia ich relacjami.
Nie istnieje jedna, uniwersalna metoda projektowania; mamy raczej do czynienia z bardzo
wieloma metodami i szkołami. Bez wahania można mówić o inflacji metod, co - w gruncie
rzeczy - oznacza, że żadna metoda nie jest wystarczająco ogólna. W praktyce projektowania
zespoły projektowe zwykle korzystają w ramach jednego projektu z wielu metod, tworząc na
użytek projektu własne, eklektyczne podejście.
Uczestnicy procesu projektowania
Zleceniodawca, czyli podmiot, który zleca projektowanie.
Sponsor, czyli podmiot, który finansuje prace projektowe.
Użytkownik, czyli podmiot, dla który system jest projektowany i który będzie z niego
korzystał.
Wykonawca (zleceniobiorca), czyli podmiot, który projektuje system.
Często zleceniodawca, sponsor i użytkownik są tym samym podmiotem.
Powyższe rozróżnienie ma kapitalne znaczenie z punktu widzenia zarządzania projektem;
inne bowiem są oczekiwania poszczególnych uczestników, a wykonawca powinien w
możliwie jak największym stopniu je wszystkie spełnić.
Metoda projektowania
Systemy informacyjne są obiektami o dużym stopniu złożoności, tak dużym, że ich
projektowanie i implementacja wymagają szczegółowej organizacji i systematyzacji prac.
Obecnie najczęstszym podejściem do organizacji prac jest strukturalizacja systemu, czyli
dekompozycja systemu na mniejsze składniki i przedstawienie go w postaci struktury
hierarchicznie powiązanych komponentów. Proces dekompozycji prowadzony jest tak
głęboko, aż osiągnięty zostanie założony poziom szczegółowości składników.
Z uwagi na to, że dekompozycja jest czynnością o charakterze analitycznym, metody
projektowania oparte na tym podejściu, a wiec na rozbiorze systemu na części składowe,
nazywa się niekiedy analitycznymi metodami projektowania systemów informacyjnych. W
metodach tych korzysta się szeroko z formalnych (abstrakcyjnych) modeli opisujących
składniki systemu informacyjnego.
Wśród metod analitycznych wymieńmy dwie kategorie: metody strukturalne i metody
obiektowe.
Projektowanie systemu
Szkicowo proces projektowania systemu informacyjnego przedstawia się następująco:
0. Definiowanie
• uświadomienie i wyartykułowanie potrzeby posiadania systemu,
• określenie ogólnych celów systemu,
• przygotowanie zapytania ofertowego (ten krok może być pominięty),
• wybranie wykonawcy,
• przygotowanie kontraktu (z opisem zadań, punktów kontrolnych, nakładami i
harmonogramem),
• negocjowanie kontraktu.
1. Analiza
• określenie grup obecnych i przyszłych użytkowników,
• analiza obecnych i przyszłych potrzeb użytkowników,
• określenie wymagań stawianych systemowi,
• opracowanie funkcjonalnego modelu systemu i ogólna specyfikacja systemu
(architektura, oprogramowanie, sprzęt, współdziałanie z innymi systemami,
personel)
• dokładne określenie nakładów i potrzebnych zasobów oraz opracowanie
harmonogramu.
2. Projektowanie
• opracowanie modeli formalnych / logicznych systemu uwzględniających
struktury danych, procesy, ich powiązania i dynamikę,
• opracowanie modeli fizycznych,
• specyfikacja aplikacji,
• wybór oprogramowania aplikacyjnego(pakiety, oprogramowanie własne) i
systemowego oraz sprzętu,
• określenie zasad alokacji oprogramowania i aplikacji w zasobach sprzętowych.
3. Implementacja.
• wykonanie prototypu (nie zawsze),
• wykonanie systemu,
• przygotowanie dokumentacji.
4. Zainstalowanie, testowanie i usuwanie błędów
•
•
•
•
•
•
•
instalacja systemu,
wprowadzenie danych (przynajmniej do testowania)
testowanie poprawności funkcjonalnej,
testowanie parametrów wydajnościowych,
wyszukiwanie "słabych punktów" systemu (troubleshooting),
optymalizacja, poprawki usuwanie błędów,
"strojenie" systemu.
5. Szkolenie i przekazanie systemu użytkownikowi.
Definiując cyklu życia systemu do powyższych kroków dodaje się:
6. Wdrożenie systemu (niekiedy tylko pilotowe)
7. Pielęgnowanie, utrzymanie (administracja) i rozwój systemu
8. Re-inżynieria systemu / zastąpienie systemu innym / zamknięcie systemu
Niniejszy wykład dotyczy przede wszystkim kroków 1 i 2 (w "szkole" anglosaskiej kroki te
należą do fazy opracowania tzw. Feasibility Study).
MODUŁ II
W analizie strukturalnej opartej na popularnej metodzie E. Yourdona [1989] język do
modelowania zawiera następujące elementy:
•
•
•
•
•
diagramy przepływu danych - DFD (data flow diagrams),
specyfikacje procesów - PSPEC (process specifications),
diagramy relacyjne danych - ERD (entity-relationship diagrams),
diagram przejść przez stany - STD (state-transition diagram),
słownik danych - DD (data dictionary).
Diagram Przepływu Danych - DFD (Data Flow Diagram)
Głównymi elementami języka DFD są:
Obiekt zewnętrzny
(external entity)
Przepływ danych
(data flow)
Zbiór danych
(data store)
Proces
Przykład prostego diagramu "Zamówienia"
Inventory
Reques t
Paym ent
Cus tom er
Supplier
1
Statem ent
Order
Proces s ing
Sys tem
Sales Quota
Inventory
Delivery Report
Sales Report
Managem ent
Specyfikacje Procesów - PSPEC (Process Specifications)
Specyfikacji podlegają procesy elementarne tzn. takie, których nie dekomponuje się na
diagramy DFD niższego poziomu.
Istnieje znaczna dowolność co do sposobu specyfikacji procesów. Należy wszak
podać:
•
•
•
nazwę procesu (indeks procesu, np. w konwencji "kropkowej" - 3.5.7)
dane wejściowe
dane wyjściowe
•
opis algorytmu (najczęściej w języku quasi-programowania zmieszanym
z językiem naturalnym)
Diagram Przejść przez Stany - STD (State-Transition Diagram)
Stan 1
Zdarzenie[warunek]/ akcja
Stan 2
Stan 3
Diagramy przejść jako automaty. Zastosowania diagramów przejść
Wszędzie tam gdzie opisujemy aspekty dynamiczne projektowanego systemu
Przykłady
1.
Opis procedur postępowania na różnych poziomach ogólności w informatyzowanej
instytucji, (np. procedur finansowo-księgowych, procedur sądowych, procedur
przygotowania i zatwierdzania planów, procedury zaliczania semestru na uczelni itp.)
Uwaga: (1) Przy najlepiej sformalizowanych procedurach istnieje niebezpieczeństwo
pominięcia istotnych elementów procedury i co za tym idzie
niedopasowania systemu do obowiązujących reguł
(2) W wielu przypadkach obowiązujące reguły zmieniają się tak często,
że bez dobrych narzędzi nie jest możliwe nadążanie ze zmianami w systemie.
2.
Opis dynamicznych reguł integralnościowych, tj. zmian wartości atrybutów, którymi
rządzą pewne reguły);
Przykłady:
zmiany zaszeregowania pracownika,
opis zmian flag w systemie (np. stan zamówienia w magazynie, stan zamówienia książki w
bibliotece, stan płatności faktury, itp.)
3. Opis generowania komunikatów, ostrzeżeń, alarmów
Przykłady:
Ostrzeżenia o stanie zapasów
Alarm w przypadku zaistnienia krytycznej sytuacji w sieci telekomunikacyjnej lub
energetycznej
4.
Opis algorytmów udostępniania danych w procesie przepływu prac (w systemach
workflow)
Przykład
automat przepływu dokumentów, komunikatów w systemach wspomagających
projektowanie,
5. Scenariusze współpracy z użytkownikiem
Przykłady:
Projektowanie interface'u;
Scenariusze dialogu z systemem (słynny przykład AMT (Automated Machine Teller)
6. Wizualizacja stanów węzłowych procesów wspomaganych systemem informacyjnym
Nota bene: Z nowszych trendów w dziedzinie systemów bazodanowych w kontekście
uwzględnienia dynamiki w procesie projektowania wymienia się tzw. aktywne bazy danych.
Ad. 2
Start:
Wprowadzenie
zamówienia
Weryfikacja
Zamówienia
Stan:
zweryfikowane
Wysłanie
Otrzymanie produktu
zrealizowane
Stan:
wysłane
opóżnione
t>10 dni
Próba zmiany pensji
pracownika
oldsalary>new salary or last change_date< 12month ago or …
Komunikat:
niespełniony
warunek 1
Komunikat:
Niespełniony war.2
niepowodzenie
Uwaga: można też stosować znane jeszcz z COBOLu Tablice decyzyjne, które można
postrzegać jak tabelaryczny zapis warunków na przejście od stanu 1 do stanu 2
Atrybut A1
W11
W21
…
…
…
…
Atrybut A2
W12
W22
Atrybut A3
W13
W23
Decyzja
D1
D2
Ważne jest sprawdzenie kompletności i niesprzeczności tabeli
kompletność: czy dla dowolnych wartości rozważanych atrybutów system może podjąć
decyzję o zmianie stanu;
Niesprzeczność: czy zdefiniowana tabela nie jest niesprzeczna
Ad 3 Sygnalizowanie stanu zapasów:
Akceptowany
stan zapasów
Tranzakcja S
Stan sprzedaz<pró
g
Nieakceptowany
stan zapasów alarm
Tranzakcja D
Stan +D <próg
Tranzakcja S
Stan sprzedaż >
próg
Diagramy Relacyjne Danych - ERD (Entity-Relationship Diagrams),
Głównymi elementami języka ERD są:
obiekt
obiekt słaby
relacja wzajemnego relacja
wyłączania się
Możliwe zakończenia relacji:
obiekt asocjacyjny
Podtyp/supertyp
blok tekstowy
Przykład systemu organizacji zamówień.
Order
Cons is ts Of
Handles
Is For
Is For
Ship
Line
Item
Product-Supplier
Contains
Cus tom er
Returns
Return
Related To
Cons is ts Of
Return
Line
Item
Prepay
Cus tom er
Credit
Cus tom er
Dam aged
Return
Wrong
Size
Return
Wrong
Color
Return
Zadanie: Znaleźć nieścisłości w powyższym diagramie
Shipm ent
Stock
Obtained from
As s ociated
With
Sales
Representative
Places
Order
Line
Item
Is Supplier
For
For
Supplier
Słownik Danych - DD (Data Dictionary)
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ę
i
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}
Czym jest podejście obiektowe ?
Wśród specjalistów zainteresowanych podejściem obiektowym nie ma
zgody co do jego definicji i najważniejszych cech.
Trawestując za prof. Heisenbergiem:
podejście obiektowe w informatyce jest po prostu tym - niczym
więcej, niczym mniej - co uprawiają zwolennicy tego podejścia.
King [1989], "My cat is object-oriented":
"Mam kota imieniem Trash. Przy obecnym stanie umysłów,
gdybym chciał sprzedać go informatykowi, nie powinienem
podkreślać jego przyjacielskiego usposobienia i
samowystarczalności w zakresie zdobywania pożywienia, raczej
powinienem powiedzieć, że Trash jest zorientowany obiektowo" i
dalej "jest rzeczą interesująca, że taka właśnie bałamutna reklama i
argumentacja są na porządku dziennym wśród badaczy
zajmujących się bazami danych".
Słownik Webster's New Collegiate Dictionary z 1974 r. gdzie pod hasłem
obiekt napisano:
"(i) coś fizycznego lub mentalnego czego podmiot jest świadom
poznawczo,
(ii) coś, co wywołuje emocje u obserwatora".
A może tak:
"Świat składa się wyłącznie z obiektów, zaś wszystko co nie jest z
tego świata, jest również obiektem". Żarty na bok - o próbach
ustalenia i uporządkowania terminologii powiemy w Nocie
bibliograficznej kończącej ten rozdział
Na użytek naszych rozważań przyjmiemy, że jakakolwiek metodologia
oparta na podejściu obiektowym charakteryzuje się co najmniej pięcioma
cechami, którymi są:
9.
10.
11.
12.
13.
abstrakcja,
enkapsulacja,
dekompozycja,
dziedziczenie,
tożsamość obiektów.
Przykład
Pojazd
producent
nr rejestr.
właściciel
stan licznika
podaj_stan_licznika()
podaj_właściciela()
...
Samochód
marka
liczba pasażerów
kolor
rok produkcji
podaj_markę()
...
Ciężarówka
marka
ładowność
rok produkcji
podaj_ładowność()
...
Obiekt
Obiektem (ang. object) nazywamy pewną, podporządkowaną ustalonym i
niezmiennym regułom (w ramach danego języka programowania lub
języka modelowania świata rzeczywistego) reprezentacje przedmiotów,
zjawisk, idei, które występują w świecie rzeczywistym. Reprezentacja ta
obejmuje dwa aspekty:
- stan (ang. state, instance variable),
- zachowanie się (ang. behavior).
Ważniejsze cechy podejścia obiektowego
Abstrakcja
Istotą abstrakcji jako metody tworzenia reprezentacji świata
rzeczywistego, lub mówiąc inaczej - budowania modeli tego świata, jest
w gruncie rzeczy wykonanie dwóch niezwykle trudnych operacji:
wyodrębnienie ze świata rzeczywistego istotnych elementów,
powiązań pomiędzy nimi i ich sposobów zachowania, następnie
- ustalenie ich ważnych cech oraz nazwanie wszystkich
wyabstrahowanych w ten sposób aspektów tego świata,
•
pominiecie lub ukrycie (!) tych elementów tego świata, które
uważamy za nieistotne lub mniej ważne.
•
Enkapsulacja
• obiekty wykazujące wspólne cechy i zachowania zgrupowane są w
tzw. klasę obiektów (ang. object class), przy czym każdy obiekt musi
należeć do jakiejś, ale tylko jednej, klasy. Obiekt należący do danej
klasy nazywany jest także wystąpieniem tej klasy (ang. instance of the
class);
7.
wewnętrzna struktura i funkcjonowanie obiektu są dla innych obiektów
niewidoczne (ang. information hiding); obiekt jest dla nich dostępny
jedynie za pośrednictwem komunikatów aktywizujących zewnętrznie
dostępne procedury, jednakowych dla wszystkich obiektów danej
klasy. Inaczej można to wyrazić w ten sposób, że dostęp do obiektu
ma charakter "publiczny" (w żargonie, mimo że brzmi to okropnie,
mówi się o publicznym interfejsie), zaś reprezentacja danych i sposób
wykonywania na nich operacji maja charakter "prywatny".
Modularyzacja
Dziedziczenie
Dziedziczenie (ang. inheritance) polega na tworzeniu nowych klas,
nazywanych podklasami z klas już istniejących. Nowe klasy przejmują
struktury danych i metody klas, z których zostały utworzone, a ponadto
dołączają do nich swe własne struktury i procedury. Staja się przez to
bardziej "wyspecjalizowane" od swych pierwowzorów, nazywanych takie
nadklasami.
Tożsamość obiektu
Przez tożsamość obiektu (ang. object identity) rozumie się taką jego
własność, która pozwala odróżnić ten obiekt od każdego innego obiektu
jaki istnieje lub może się pojawić w rozważanym systemie.
Metoda - Komunikat
Metody napisane są zwykle w
tym samym języku co otoczenie
obiektów.
Obiekt X
komunikat
X.Mi (p1,...,pn)
Istnieje dość dobra analogia
pomiędzy wywołaniem
procedury , a komunikatem, ale
uwaga:
odpowiedź
metody
M1, M2, ...
1. Dla procedury
nazwa_procedury(nazwa_obiektu_adresata, parametry) ,
np. zapisz_ocenę(Jabłoński, 4+)
wybór metody jest tu statyczny, czyli jest okreslany podczas kompliacji.
2. Dla metody
nazwa_obiektu_adresata.nazwa_metody(parametry)
np. Jabłoński. zapisz_ocenę(4+)
wybór metody jest dynamiczny; dokonuje się w trakcie wykonania
programu.
Różnica ta ma istotne znaczenie w fazie modelowania konceptualnego i
ponownego użycia.
Kilka cech języka programowania metod
•
polimorfizm (późne wiązanie); wybór metody zachodzi dynamicznie, w
metoda jest wybierana z tych, które znajdują się w obiekcie będącym
adresatem komunikatu.
(wiązaniem nazywa się zamianę nazwy na wartość fizyczną)
•
przesłanianie (overriding); spośród metod o tej samej nazwie
występujących w klasach powiązanych dziedziczeniem wybiera się
metodę z klasy najniższej (metoda ta przesłania metody z klasy
wyższych).
•
przeciążanie (overloading); znaczenie symbolu, funkcji, metody
zależy od kontekstu.
Dyskusja wybranych aspektów podejścia obiektowego
Złożoność obiektów; Uniwersalizm obiektowy
Wizja idealna:
Każdy obiekt jest złożony z innych obiektów ("sub-obiektów") lub jest
obiektem atomowym.
A zatem m.in. atrybuty, metody oraz powiązania też są obiektami.
Takie założenie upraszcza i unifikuje środki opisu modelu danych, język
zapytań, interfejs programistyczny itp.
A. Kay - jeden z współtwórców podejścia obiektowego - dopuszczał
asynchroniczny sposób komunikowania się z obiektami.
Stan rzeczywisty:
W praktyce uniwersalizm nie jest spełniony, np. UML odróżnia obiekty od
atrybutów.
Zasada identyfikacji (ZI)
Wszystkie konstrukty, na których można prowadzić operacje (wiązanie,
wyszukiwanie, aktualizowanie, usuwanie, autoryzowanie, indeksowanie,
zabezpieczanie itd.) musi posiadać swój unikalny identyfikator (uwaga:
ten sam konstrukt może mieć wiele nazw, ale tylko jeden identyfikator).
Przykład:
• każde wystąpienie atrybutu powtarzalnego ma swój identyfikator,
• relacje (powiązania) pomiędzy obiektami muszą mieć identyfikatory,
gdyż one także mogą podlegać aktualizacji, ochronie, itp.
Dzięki ZI można konstruować odsyłacze (ref), co niezwykle ułatwia
definiowanie i rozumienie semantyki modeli i ich implementacji.
Klasa
Spojrzenie formalne - klasa równoważności/abstrakcji; zbiór obiektów
(ekstensja)
Klasa (wg. K. Subiety) jest zestawem niezmienników obiektów (cechy
"wyciągnięte przed nawias")
• typ,
• metody,
• inne niezmienniki, np.
* specyfikacja powiązań,
* interfejs ("co jest widziane z zewnątrz"),
* więzy integralności,
* reakcja na zdarzenia
Hierarchia klas - klasy abstrakcyjne, klasy konkretne
(stereotyp: tylko drzewo; można dopuścić - pojedyncze obiekty,
wiele korzeni, wielokrotne dziedziczenie, inne konstrukty, np. role)
Typy
Typ jest wyrażeniem pewnego języka (o określonej semantyce)
związanym z obiektem (np. atrybutem, zmienna, metodą) w celu
przypisania mu jakieś cechy, czy rodzaju wartości.
Typizacja pomaga kontrolować poprawność konstruktów, zwłaszcza
programów (szczególnie w wariancie strong typing, np. Modula-2,
Pascal).
Typizacja nie jest warunkiem koniecznym obiektowości !
Typy masowe (kolekcje - ODMG) - ważne w systemach informacyjnych
• zbiory,
• wielozbiory (elementy mogą występować wielokrotnie),
• sekwencje (uporządkowane kolekcje elementów dowolnego,
ustalonego typu),
• tablice decyzyjne,
• słowniki (pary tag, value).
Trwałość obiektów
Konstrukt żyje dłużej niż czas wykonywania programu (ważne dla baz
danych).
Powiązania
Są przedmiotem niejasności koncepcyjnych i terminologicznych.
Trzy główne modele:
asocjacje (np. E-R),
− relacje,
− wskaźniki.
−
Asocjacje (raczej do
modelowania pojęciowego) najczęściej trzy rodzaje
powiązań: ogólnyszczegółowy, cześć-całość,
jakieś powiązanie (UML)
0..*
0..1
uczeń
nauczyciel
Osoba
rodzic
1..*
Asocjacje są obiektami.
Wywiadówka
Można dekomponować
związki n-arne na binarne.
Relacje - Codda model relacyjny (powtarzanie atrybutów w tabelach).
Wskaźniki (ponters, reference, links, ...) są silnie krytykowane za "utratę
niezależności danych", za "wiszące" wskaźniki, modelowanie tylko
związków binarnych, niemożność dołączenia atrybutów, naruszenie
enkapsulacji.
Zalety: "naturalna" semantyka, wzrost szybkości nawigacji (nie ma
JOIN).
Moduł IV
Obiektowe Bazy Danych
Obiektowe bazy danych są rezultatem połączenia koncepcji opracowanych na gruncie:
baz danych, obiektowych języków programowania i ogólnych rozważań na temat
"obiektowego" postrzegania świata.
Ważna uwaga wstępna:
Nie ma obecnie żadnej teorii, czy choćby powszechnie akceptowanego zbioru
zasad praktycznych w dziedzinie konstruowania obiektowych systemów
zarządzania bazami danych (OSZBD); nie istnieje ogólnie przyjęta metoda
projektowania baz obiektowych; nie ma też jednolitej terminologii w tej
materii: dziedzina baz obiektowych znajduje się in statu nascendi. Mimo
wysiłków OMG i ODMG nie wypracowano standardu w zakresie
systemów/baz obiektowych.
Kierunki i tempo prace nad bazami obiektowymi wyznaczają różne czynniki, w tym
m.in. obecny i przewidywany rozwój sprzętu komputerowego (moc obliczeniowa,
pojemności pamięci, sieci), naciski projektantów, użytkowników i programistów na
udostępnianie coraz silniejszych semantycznie i łatwiejszych w użyciu narzędzi do
budowania i użytkowania systemów informacyjnych oraz - czego nie można pominąć
- interesy firm komputerowych produkujących systemy zarządzania bazami danych i
firm wytwarzających aplikacje oparte na bazach danych.
W kontekście systemów zarządzania bazami danych, w tym systemami obiektowymi
rozważa się:
• architekturę, która określa ogólną organizację systemu podając jego strukturę
przez wymienienie składników i funkcji oraz wzajemnych powiązań,
• model danych, czyli sposób w jak postrzegane i opisywane są struktury danych;
w modelu obiektowym podstawowym pojęciem jest obiekt (z atrybutami i
związkami z innymi obiektami), klasa, enkapsulacja, dziedziczenie, metody itd.
• Język Opisu Danych (DDL, Data Description Language), który służy do
zapisania modelu danych (na poziomie logicznym). Model taki nazywany jest
schematem danych.
• Język Manipulacji Danymi (DML, Data Manipulation Language), którego
głównym użytkownikiem jest programista bazy danych; DML służy do
programowania aplikacji, wyszukiwania i przetwarzania danych; "języki 4GL są
usamodzielnionymi DML",
• Język zapytań, język kwerend (QL, Query Language), który służy do
formułowania zapytań i prostych poleceń dotyczących operacji na danych; QL
często wykorzystywany jest przez użytkowników do interakcyjnego tworzenia
kwerend; QL niekiedy traktowany jest jako część DML; obserwuje się tendencję
do rozszerzania QL w kierunku silnego języka programowania (patrz SQL3), co
nosi nazwę seamless integration.
Architektura OSZDB
Nie ma ani jednolitego poglądu na to czym jest architektura OSZBD i jak ją
przedstawiać. Wydaje się, że na najwyższym poziomie ogólności wciąż przydatny jest
trzywarstwowy model (poziom fizyczny, pojęciowy i zewnętrzny) ANSI SPARC.
Według ODMG dostęp do i wykorzystanie systemu obiektowego mogą być
następujące:
•
można przygotować i wykonać program w języku obiektowym, ew. z
dodatkami zaczerpniętymi z QL,
•
można opracować aplikację w języku wysokiego poziomu, np. typu 4GL
lub narzędzi RAP/RAD,
•
korzystać interakcyjnie z systemu za pomocą QL.
Niezależnie od sposobu współpracy z systemem dostęp do bazy danych ma miejsce za
pośrednictwem mechanizmu przetwarzania transakcji, ochrony danych,
bezpieczeństwa itd.
Środowisko
4GL/RAP/RAD
Program
* Pre-procesor
* Kompilator
* Moduły do
konsolidacji
Konsolidacja
Wykonanie
programu
Biblioteki klas i moduły
run-time dla
języka programowania
i OSZBD
Wykonanie
zapytań
transakcje,
autoryzacja,
bezpieczeństwo
itd.
Zbiory bazy danych
* dane
* indeksy, katalogi
* perspektywy, itd.
Manifest (M. Atkinson, F. Bancihon, D. DeWitt, K. Dittrich, D. Maier, S. Zdonik,
1989)
Zawiera złożenia dotyczące obiektowych baz danych:
Obligatoryjne (złożone obiekty, klasy, tożsamość, enkapsulacja, dziedziczenie, ...)
Opcjonalne (kontrola typu, wielokrotne dziedziczenie, wersje, ...)
• Otwarte
•
•
Kompletność obliczeniowa
Język zapytań - obliczenie dowolnej funkcji rekurencyjnej.
Zwykle QL są niekompletne i dlatego zanurzone są w język programowania. Pojawia
się tu niebezpieczeństwo impedance mismatch.
Lepiej mówić o kompletności pragmatycznej (za K. Subietą):
− możliwość definiowania wszystkich potrzebnych struktur danych,
− kompletne wyszukiwanie (brak "czarnych dziur") i obliczania
− możliwość dowolnych dynamicznych zmian danych,
− dostęp do katalogów, zmiennych środowiskowych itp.,
− możliwość utworzenia aplikacji,
− współdziałanie z innymi językami, np. Java
Zasada korespondencji: po włączeniu do języka nowego mechanizmu/cechy należy
dokładne określić jak "koresponduje' on ze wszystkimi innymi cechami
Zarządzanie pamięcią: postulowany rozdział poziomu aplikacyjnego od poziomu
fizycznego nie jest w praktyce spełniany - programista wciąż operuje zajmuje się
indeksami, ścieżkami dostępu, zarządza indeksami itp.
Zapytania: dwa typy QL - interakcyjny (przeglądanie, menu, grafika) i "zanurzony,
np. SQL3.
Kryteria wyboru produktu OSZBD
6. funkcjonalność (functionality)
• wydajność (performance)
• "dziedziczenie" stanu (legacy)
14.
skalowalność (scaleability)
• wspomaganie i perspektywa rozwoju
(maintenance, after sale service)
• środowisko (platform independence)
1. otwartość i współdziałanie
(interoperability)
• referencje (reference list)
• prostota użycia (user friendliness)
*0
• niezawodność (realiability)
Niektóre aspekty funkcjonalność
8. moda (fashion)
cena (price)
• struktury danych
• język zapytań
• programowanie aplikacji
• mechanizmy dostępu i ochrony, bezpieczeństwo, niezawodność
• przetwarzanie rozproszone/sieciowe
• dodatki (wersje, temporalność, archiwa, reguły aktywne,
procedury/metody wraz przechowywane z danymi w bazie)
• standardy
Systemy relacyjno-obiektowe (tzw. universal server) - pros i cons.
Uwaga na ekspertów i ekspertyzy - wysoki koszt, powierzchowność i brak
dostatecznego zrozumienia przypadku, konserwatyzm i ostrożność ekspertów,
przesadna wiara w możliwość zaimplementowania dowolnego pomysłu.
Moduł V. Nowe tendencje w systemach informacyjnych
• eksploracja danych (data mining)
• hurtownie danych (data warehousing)
• kultywacja danych (web farming)
Eksploracja danych
świat
“The purpose of computing is
insight, not numbers.”
Richard Hamming
statystyka
bazy
EDW
danych
sztuczna inteligencja
Tutaj przez eksplorację danych/
wiedzy rozumiemy proces
automatycznego odkrywania
znaczącej, pożytecznej, dotychczas nieznanej i możliwie pełnej wiedzy
zawartej w dużych bazach danych, wiedzy ujawniającej ukryte własności
badanego przedmiotu.
Wiedza ta przyjmuje postać reguł, prawidłowości, tendencji i korelacji, i jest
następnie przedstawiana przygotowanemu do jej spożytkowania
użytkownikowi w celu rozwiązania stojących przed nią/nim problemów i
podjęcia istotnych decyzji.
“Eksploracja danych polega na torturowaniu danych tak długo, aż zaczną zeznawać”
Najczęściej eksploracja oparta jest na następujących typach działań:
klasyfikowanie
classification)
•
regresja
regression)
•
grupowanie
clustering)
•
kojarzenie
association)
•
(ang.
(ang.
(ang.
(ang.
Odkrywanie wiedzy
Dane surowe
Przetwarzanie
wstępne
Eksploracja
danych
• Zdefiniować problem/zadanie i
Przetwarzanie
końcowe
zanalizować otoczenie.
• Wybrać zbiór danych do eksploracji i
wiedza
atrybuty.
• Zdecydować jak przygotować dane do przetwarzania.
• Wybrać algorytm (lub ich kombinację) eksploracji i wykonać program
realizujący ten algorytm.
• Zanalizować wyniki wykonania programu i wybrać te,
które uznajemy za rezultat pracy.
•
Przedłożyć wyniki kierownictwu organizacji i zasugerować
sposób ich wykorzystania.
Hurtownie danych
Potrzeby
•
•
•
scalenie danych z różnych źródeł,
efektywne udostępnianie aktualnych danych do analiz,
przechowywanie danych historycznych.
Hurtownia danych (magazyn danych, data warehouse) jest wydzieloną
centralną bazą danych zbierającą informacje, które służą do zarządzania
organizacją.
Cechy hurtowni danych:
• jest scentralizowaną bazą danych, oddzieloną od baz operacyjnych,
• łączy/scala informacje z wielu źródeł (ujednolicony model i format),
• jest zorientowana tematycznie (zbiera tylko informacje przydatne do
analiz w zakresie przewidzianym dla hurtowni),
• przechowuje dane historyczne (głęboka retrospekcja),
• utrzymuje wielką ilość informacji pochodzących z wielu źródeł,
• pozwala wykonywać OLAP (On-Line Analytical Processing) oraz
agreguje dane, przechowując tzw. zmaterializowane agregaty, które są
niezwykle cenne dla wszelkich analiz.
Architektura hurtowni danych (źródło: dr T. Traczyk)
Klient
Hurtownia
danych
Integracja
Konwersja
Konwersja
OLTP
OLTP
Składnica
danych
Składnica
danych
Klient
Klient
Uwaga:
•
Hurtownia danych jest systemem typu mission critical !
(na podstawie danych z hurtowni podejmuje się istotne, strategiczne decyzje błędy w hurtowni mogą drogo kosztować organizację),
•
Hurtowni nie można kupić - trzeba ją zbudować (najczęściej outsourcing),
•
Budowa hurtowni jest projektem obciążonym dużym ryzykiem porażki,
•
Budowa i utrzymywanie hurtowni jest przedsięwzięciem długotrwałym
(zwłaszcza przygotowania, kosztownym, angażującym zasoby ludzkie)
Warunki powodzenia projektu (źródło: dr T. Traczyk)
• Zakres i cele projektu
– dobrze określone
– zrozumiane i akceptowane przez użytkowników
• Dane źródłowe
– dostępne i dobrej jakości
– udokumentowane
• Organizacja
– dojrzała do użytkowania systemu wspomagania decyzji
– zapewniająca poparcie dla projektu ze strony kierownictwa i
pracowników
• Technologia
– adekwatna do zadań
– opanowana przez twórców systemu
Typowe koszty budowy hurtowni
• Koszty początkowe (USA) ok. 3 mln $
•
Koszty całkowite rzędu 10 mln $
Składniki kosztów hurtowni danych wg Gartner Group
•
•
•
•
robocizna
sprzęt
oprogramowanie
administrowanie
35 %
31 %
24 %
10 %
Metodologia projektowania - podobnie jak systemy baz danych
Kultywacja danych (Web Farming)
In a Pricewaterhouse Coopers survey of more than 400 CEOs of fast-growing
companies, the Web was cited as a major source of business intelligence (BI).
•
82 % use the Web as a “source of competitor information,”
•
73 % use the Web as “a statistical or data resource.”
In addition,
•
68 % use the Web to “obtain new sales leads” as compared to
only
•
27 % who use it to “provide direct sales of products.”
Surprising conclusion: It would seem that these fast-growing companies use
the Web more for BI than for e-commerce!
Web farming is defined
as the systematic
refining of Web-based
information for business
intelligence. For the IT
professional, the term
systematic should imply
secure data centers and
managed data
warehouses.
The objective of web
farming is to enhance
the data warehouse by
integrating externally
derived information with
data derived from internal operational systems.
Although this approach has similarities to data warehousing today, it requires
some new skills and several new technologies, including XML structuring,
linguistic analysis, and information visualization.
What are the business benefits of web farming? The information farmed can,
inter alia:
9. improve the performance of a business activity, such as having
better information that will enable you to service a customer faster
and more effectively.
10. change the workflow of a business activity, such as redesigning the
customer call center.
11.
can lead to the creation of new activities, such as initiating a frequent
customer program.
Most of this critical information exists outside of your enterprise, for instance
the information on:
• Customer relationships
• Supply-chain management — managing your value chain from
suppliers through distributors to end customers
• Competitive analysis
• Technology trends
• Deregulation
• Global economics and politics
The process of refining Web information
Moduł VI. Przykładowa struktura Studium Możliwości
I. Cel i przeznaczenie
1.1. Ogólne sformułowanie dziedziny i celów stawianych projektowi.
1.2. Zwięzła charakterystyka przedsięwzięcia (cel systemu).
1.3. Kryteria i warunki powodzenia realizacji systemu.
1.4. Charakterystyka użytkowników, ich kategoryzacja, ich wymagania oraz ich
metody i tryby pracy.
1.5. Charakterystyka środowiska i warunków (organizacyjnych, kadrowych,
fizycznych) działania systemu.
Uwaga: Ten rozdział do pewnego stopnia spełnia funkcje założeń do systemy
II. Projekt funkcjonalny
2.1. Funkcjonalna charakterystyka systemu.
2.2. Analiza danych (typy i rodzaje danych i wiążących je relacji) wraz z
przepływem informacji.
2.3. Formalny (ścisły) opis funkcji systemu zawierający model danych, przepływ
danych i poleceń oraz wyszczególnienie operacji wykonywanych na danych
(schematy E-R, DFD). Opracowanie wzorów dokumentów systemu.
2.4. Ścisła specyfikacja procedur systemu, w tym specyfikacja dialogu z
poszczególnymi kategoriami użytkowników (projektowanie szkiców
"ekranów").
2.5. Specyfikacja praw dostępu i ochrony danych.
2.6. Specyfikacja statystyk zbieranych przez system w celu jego oceny i analizy
potrzeb użytkowników.
2.7. Specyfikacja jakości (łatwość użytkowania, łatwość pielęgnacji, niezawodność,
możliwości rozwoju).
2.8. Współdziałanie z innymi systemami.
III. Prototyp
3.1. Opis prototypu.
3.2. Ocena prototypu przez przyszłych użytkowników systemu. Propozycje.
3.3. Wnioski.
IV. Architektura systemu. Zarządzanie realizacją projektu
4.1 Technologiczna podstawa działania systemu (model klient-serwer, system
otwarty, przyjazność dla użytkownika, minimalizacja nakładów na utrzymanie i
administrację systemu, podatność na zmiany otoczenia itd.).
4.2. Ilościowa i jakościowa charakterystyka parametrów wydajnościowych systemu,
w tym wskazanie parametrów krytycznych dla jakości systemu oraz
dopuszczalnych ograniczeń.
4.3. Krótka analiza rynku oprogramowania i sprzętu. Wnioski.
4.3. Specyfikacja oprogramowania i jego konfiguracja.
4.4. Specyfikacja i konfiguracja sprzętu komputerowego i sieciowego.
4.5. Metodyczne i narzędziowe zalecenia w zakresie zarządzania realizacją projektu.
V. Nakłady/zasoby i organizacja pracy
1.
Harmonogram prac wraz z punktami kontrolnymi etapowej oceny realizacji
systemu i wskazaniem ścieżki krytycznej.
2. Kosztorys implementacji systemu.
5.3. Zasoby ludzkie niezbędne do realizacji systemu.
5.4. Zasady przyjmowania etapów realizacji systemu.
5.5. Opisy zadań (ang. terms of reference) dla wszystkich członków zespołu
wykonawczego.
5.6. Zasady współpracy zleceniodawca - wykonawca.
5.7. Ocena nakładów osobowych i finansowych na utrzymanie systemu
(eksploatacja i rozwój).
VI. Analiza korzyści (costs/benefits analysis)
6.1. Oszacowanie nakładów/kosztów.
6.2. Oszacowanie korzyści.
6.3. Wnioski.
VII. Zarządzanie jakością
7.1. Wybór metod(y) zarządzania jakością.
7.2. Zalecenia.
VIII. Programy szkoleń
8.1. Szkolenia dla użytkowników.
8.2. Szkolenia dla administratorów.
IX. Układ rzeczowy i struktura dokumentacji
9.1. Dokumentacja dla użytkowników.
9.2. Dokumentacja systemu
- dla administratora aplikacji
- dla administratora bazy danych
9.3. Dokumentacja techniczna.
X. Scenariusz wdrożenia. Zasady przyjęcia system
10.1. Reguły pilotowego wdrożenie systemu
10.2. Testy systemu. Kryteria oceny.
10.3. Formularz i zasady oceny systemu przez użytkowników.
10.4. Zasady wprowadzania poprawek.
10.5. Schemat sprawozdania końcowego.
XI. Perspektywy rozwojowe systemu.
Forma końcowa
−
projekt techniczny zgonie z podanym wyżej konspektem,
-
seminarium dla zainteresowanych środowisk.