Wprowadzenie do obiektowej analizy i proj

Download Report

Transcript Wprowadzenie do obiektowej analizy i proj

Projektowanie systemów informacyjnych
Wykład 3:
Wprowadzenie do OMT
- obiektowej metodyki
analizy i projektowania SI
Kazimierz Subieta
Instytut Podstaw Informatyki PAN,
Warszawa
Polsko-Japońska Wyższa Szkoła
Technik Komputerowych, Warszawa
K.Subieta. Projektowanie systemów informacyjnych, Wykład 3, Folia 1
Plan wykładu
Problem analizy i projektowania
Pojęcie metodyki
Ogólna charakterystyka analizy i projektowania obiektowego
Założenia metodyki OMT:
Trzy modele OMT: obiektów, dynamiczny i funkcjonalny
Fazy metodyki OMT
Analiza wg OMT
Projektowanie wg OMT
Implementacja wg OMT
Model obiektów
Model dynamiczny
Model funkcjonalny
K.Subieta. Projektowanie systemów informacyjnych, Wykład 3, Folia 2
Problem analizy i projektowania
opanowanie nadmiernej złożoności
Analiza,
projekowanie,
konstrukcja,
dokumentacja,
wdrożenie,
eksploatacja
Zespół ludzi podlegający
ograniczeniom pamięci,
percepcji, psychologii,
wyrażania informacji i
wzajemnej komunikacji.
Środki informatyczne:
sprzęt, oprogramowanie, sieć,
języki, narzędzia, technologie.
K.Subieta. Projektowanie systemów informacyjnych, Wykład 3, Folia 3
Dziedzina problemowa,
najczęściej obejmująca
ogromną liczbę wzajemnie
uzależnionych aspektów,
procesów i problemów.
Obiektowość:
nowa jakość
w opanowaniu
złożoności
Cykl życiowy projektu
• Określenie strategicznych celów wprowadzenia informatyki
• Planowanie i definicja projektu
• Analiza
Analiza dziedziny przedsiębiorczości
Analiza wymagań systemowych
• Projektowanie
Projektowanie pojęciowe
Projektowanie logiczne
Projektowanie fizyczne
• Konstrukcja
Rozwijanie
Testowanie
Dokumentacja
• Przygotowanie użytkowników, akceptacja, szkolenie
• Działanie, włączając wspomaganie tworzenia aplikacji
K.Subieta. Projektowanie systemów informacyjnych, Wykład 3, Folia 4
Pojęcie metodyki
methodology
Zestaw 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.
Zwykle metodyka jest powiązana z odpowiednią notacją służącą do zapisywania wyniku
poszczególnych faz projektu, jako środek wspomagający ludzką pamięć i wyobraźnię i jako
środek komunikacji w zespołach oraz pomiędzy projektantami i klientem.
Metodyka
ustala:
• fazy projektu,
• scenariusze postępowania w każdej z faz,
• sposoby i uwarunkowania przechodzenia od danej fazy do następnej fazy,
• notację, którą należy używać w każdej z faz
• dokumentację powstającą w każdej z faz.
Metodyka dyscyplinuje przebieg procesu projektowego
pozwalając na w miarę obiektywne rozliczenie
(czasowe, finansowe) jego uczestników.
K.Subieta. Projektowanie systemów informacyjnych, Wykład 3, Folia 5
Analiza i projektowanie obiektowe
Kombinacja technik, notacji i wzorców postępowania posiadająca następujące cechy:
Wyróżnianie w rzeczywistości będącej przedmiotem systemu informatycznego
bytów o określonych granicach, zwanych “obiektami”
Grupowanie obiektów w klasy
Ustalenie zależności pomiędzy klasami w postaci hierarchii dziedziczenia
Przypisanie do klas atrybutów obiektów i powiązań asocjacyjnych obiektów
Przypisanie do klas metod, tj. operacji, funkcji lub procedur działąjących na
obiektach tych klas
Techniki:
Notacje:
Modelowanie obiektów i klas, modelowanie zachowania,
modelowanie dynamiczne, modelowanie przepływu danych, ...
Konkretna składnia i semantyka służąca do zapisu modelu:
diagramy obiektów i klas, diagramy dynamiczne, diagramy
przepływu danych
K.Subieta. Projektowanie systemów informacyjnych, Wykład 3, Folia 6
Tematyka analizy i projektowania
obiektowego
• Analiza i modelowanie struktur obiektów
• Analiza i modelowanie procesów i sekwencji transakcji
• Analiza i modelowanie interakcji pomiędzy obiektami
• Analiza i modelowanie cyklu życiowego obiektów
• Kompleksowe modelowanie systemów
• Planowanie projektu
• Zarządzanie projektami dotyczącymi obiektowości
• Analiza wymagań dotyczących systemu
• Projektowanie logiczne
• Projektowanie fizyczne
• Rozwijanie obiektowych aplikacji
• Testowanie, akceptacja, wdrażanie, działanie
K.Subieta. Projektowanie systemów informacyjnych, Wykład 3, Folia 7
Metodyka obiektowa
Metodyka wykorzystująca pojęcia obiektowości dla celów modelowania pojęciowego
oraz analizy i projektowania systemów informatycznych.
Podstawowym składnikiem tych metodyk jest diagram obiektów, będący zwykle
wariantem notacyjnym i pewnym rozszerzeniem diagramów encja-związek.
Diagram obiektów zawiera takie elementy jak: klasy, w ramach klas specyfikacje
atrybutów i metod, strukturę dziedziczenia pomiędzy klasami, związki asocjacji i
agregacji, liczności tych związków, różnorodne ograniczenia oraz inne oznaczenia.
Uzupełnieniem tego diagramu są inne, np. diagramy dynamiczne uwzględniające
stany poszczególnych procesów przetwarzania i przejścia pomiędzy tymi stanami,
diagramy zależności pomiędzy wywołaniami metod, np. diagram tropów komunikatów,
diagramy fukcjonalne (będące zwykle pewną mutacją diagramów przepływu danych).
Ostatnio popularność zdobyła także koncepcja przypadków użycia (use cases), której
podstawowym celem i walorem jest odwzorowanie struktury systemu z punktu
widzenia jego użytkownika.
K.Subieta. Projektowanie systemów informacyjnych, Wykład 3, Folia 8
Metodyki obiektowe
Express
OMT,
Rumbaugh
MainstreamObjects, Yourdon
Martin/Odell
OODA, Booch
OOSA, Shlaer-Mellor
Objectory, Jacobson
OOA/OOD, Coad/Yourdon
Catalysis, D’Souza & Wills
Fusion, HP Laboratories
DOOS, Wirfs-Brock
Goldberg/Rubin
BON (Business Object Notation), Nerson & Walden
EROOS (Entity-Relationship Object-Oriented Specification)
OORAM
Sintropy
MOSES (Methodology for Object-Oriented Software Engineering of System)
UML (Unified Modelling Language), Booch, Jacobson, Rumbaugh
K.Subieta. Projektowanie systemów informacyjnych, Wykład 3, Folia 9
OSA
Jakie metodyki są używane?
Shlaer-Mellor
13%
Coad/Yourdon
13%
OOIE
17%
Fusion
4%
Inne
17%
Booch
4%
OMT
32%
Źródło: Gartner Group - 1995
K.Subieta. Projektowanie systemów informacyjnych, Wykład 3, Folia 10
Wprowadzenie do OMT
 Co to jest OMT?
 Trzy podstawowe modele OMT
 Diagramy i techniki OMT
 Obiekty, klasy
 Atrybuty
 Operacje, metody
 Powiązania, asocjacje
 Agregacje
 Generalizacje, dziedziczenie
K.Subieta. Projektowanie systemów informacyjnych, Wykład 3, Folia 11
Co to jest OMT?
OMT = Object Modelling Technique, technika modelowania obiektów.
Książka:
J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, W. Lorenson.
Object-Oriented Modelling and Design.
Englewood Cliffs, NJ, Prentice Hall 1991
Przyszłość:
Trzech czołowych obiektowych metodologów,
Grady Booch, Ivar Jacobson i James Rumbaugh,
połączyło swoje wysiki i metodyki w ramach firmy
Rational Software Corporation.
Rezutat (wrzesień 1996) określili jako
The Unified Modelling Language
K.Subieta. Projektowanie systemów informacyjnych, Wykład 3, Folia 12
Filozofia OMT
Główna różnica pomiędzy podejściem obiektowym w
rozwoju oprogramowania, a podejściem tradycyjnym:
Podejście obiektowe nie opiera się na funkcjonalnej dekompozycji procesów
zachodzących w świecie rzeczywistym, a na opisie obiektów rzeczywistych,
które grają określoną rolę w tym świecie.
Wg OMT obiektowość jest sposobem myślenia i organizacji oprogramowania
polegającym na wyodrębnianiu dyskretnych obiektów, które odwzorowują
zarówno statyczną strukturę świata i danych, jak i zachowanie (behaviour).
Charakterystyki obiektowości:
• tożsamość obiektów
• klasyfikacja (grupowanie obiektów w klasy)
• polimorfizm
• dziedziczenie
(te charakterystyki mogą być przedmiotem dyskusji)
Istotna jest identyfikacja i organizacja pojęć z dziedziny
aplikacyjnej, a nie pojęć z dziedziny implementacyjnej.
K.Subieta. Projektowanie systemów informacyjnych, Wykład 3, Folia 13
Wkład podejścia obiektowego
Większy nacisk na istotne własności obiektów zmusza analityka lub projektanta
do staranniejszego i głębszego myślenia o tym, czym jest obiekt i co on robi.
Główne zyski nie polegają na zredukowaniu czasu rozwoju, lecz na przyszłym
powtórnym użyciu klas i innych fragmentów projektu, zredukowaniu błędów
i pracochłonności utrzymania (maintenance).
Wkład:
Przesunięcie trudu rozwoju na fazę analizy
Większy nacisk na struktury danych,
a mniejszy na funkcje, co wspomaga stabilność
Bezszwowy proces rozwoju
Podejście iteracyjne raczej niż sekwencyjne.
Cechy projektu są dodawane i wyjaśniane w kolejnych iteracjach
K.Subieta. Projektowanie systemów informacyjnych, Wykład 3, Folia 14
OMT- 3 modele
Model obiektów
statyczna struktura obiektów i związków
przykrywa aspekt “danych”
Model funkcjonalny
przykrywa aspekt “funkcjonalny”
zależności funkcyjne pomiędzy wartościami
Model dynamiczny
przykrywa zachowanie się obiektów w terminach “bodziec-odpowiedź”
przykrywa aspekt “sterowania”
Projektowanie i implementacja polega na uszczegóławianiu i łączeniu tych modeli
K.Subieta. Projektowanie systemów informacyjnych, Wykład 3, Folia 15
Diagramy i techniki OMT
Model
Modelowany poprzez
Cel
Komunikacja klas Diagram komunikacji klas
Modeluje komunikację wewnątrz systemu
(class
(Class Communication
poprzez pokazanie interfejsów między obiektami.
communication)
Diagram, CCD)
(CADRE)
Diagram generalizacji
Dekomponuje strukturę złożonych komunikatów.
komunikatów (Message
Generalization Diagram, MGD)
Asocjacja klas
(class association)
(OMT)
Dynamiczny
(OMT)
Diagram asocjacji klas (Class
Association Diagram, CAD)
Modeluje statyczną strukturę system poprzez sieć
klas i związków.
Diagram zmian stanów (State
Transition Diagram, STD)
Modeluje strukturę sterowania systemu. Pokazuje
sekwencję działań między niektórymi stanami
systemu w terminach stanów i przejść.
Pokazuje sekwencję zdarzeń między różnymi
obiektami jako uporządkowaną listę.
Diagram tropów zdarzeń
(Event Trace Diagram, ETD)
Fumkcjonalny
(OMT)
Diagram przepływu danych
(Data Flow Diagram, DFD)
K.Subieta. Projektowanie systemów informacyjnych, Wykład 3, Folia 16
Modeluje procesy systemu. Pokazuje przepływ
wartości danych od ich źródeł w obiektach poprzez
procesy, do ich przeznaczenia w innych obiektach.
Fazy metodyki OMT
OMT zakłada iterację (powtarzanie) następujących faz:
Analiza: budowa modelu świata rzeczywistego
Projektowanie systemowe: zagadnienia architektoniczne, podsystemy, itd
Projektowanie obiektowe: budowa modeli obiektowych opartych na
wynikach analizy.
Implementacja: zakodowanie projektu w języku programowania
Analiza
Model obiektów
Model dynamiczny
Model funkcjonalny
Projektowanie
Projektowanie systemu
Projektowanie obiektów
K.Subieta. Projektowanie systemów informacyjnych, Wykład 3, Folia 17
Proces analizy
Użytkownicy
Projektanci
Generowanie
wymagań
Kierownictwo
Sformułowanie
problemu
Wywiady z
użytkownikami
Wiedza dotycząca
dziedziny problemowej
Budowa
modeli
Doświadczenie w
zakresie projektów
Analiza
Model obiektów
Model dynamiczny
Model funkcjonalny
Projektowanie
K.Subieta. Projektowanie systemów informacyjnych, Wykład 3, Folia 18
Analiza
Włącza następujące czynności:
Rozpoznanie, wyjaśnianie, modelowanie, specyfikowanie i dokumentowanie
rzeczywistości lub problemu będącego przedmiotem projektu;
Ustalenie kontekstu projektu;
Ustalenie wymagań użytkowników;
Ustalenie wymagań organizacyjnych
Inne ustalenia, np. dotyczące preferencji sprzętowych, preferencji w zakresie
oprogramowania, ograniczeń finansowych, ograniczeń czasowych, itd.
Analiza nie zajmuje się zmianą tej rzeczywistości poprzez wprowadzenie tam
nowych elementów np. w postaci systemu informatycznego; jej celem jest
dokładne rozpoznanie wszystkich tych aspektów danej rzeczywistości, które
mogłyby mieć wpływ na postać, organizację lub wynik projektu. Analiza nie
powinna odwoływać się do jakichkolwiek aspektów implementacyjnych.
K.Subieta. Projektowanie systemów informacyjnych, Wykład 3, Folia 19
Projektowanie systemowe
Etap w którym projektant systemu podejmuje decyzje wysokiego poziomu
dotyczące całościowej architektury systemu.
Wynikowy system jest organizowany w podsystemy na podstawie wyników
analizy jak i założeń co do ogólnej architektury. Projektant musi podjąć
decyzje dotyczące optymalizacji charakterystyk wydajnościowych, wybrać
strategię rozwiązania tego problemu oraz podjąć decyzje odnośnie alokacji
zasobów.
Np. projektant musi określić charakterystyki monitorów (rozdzielczość, rozmiar
ekranu, kolory), musi wybrać konfigurację sprzętu, strategię buforowania pamięci,
właściwe protokóły komunikacyjne, itd.
K.Subieta. Projektowanie systemów informacyjnych, Wykład 3, Folia 20
Projektowanie obiektowe
Projekt bazuje na wyniku analizy oraz wyniku projektowania systemowego.
Zawiera wiele elementów implementacyjnych odnoszących się do struktury
obiektowej oraz algorytmów (metod) przetwarzania potrzebnych do
implementacji klas.
Klasy wyodrębnione podczas analizy są również istotne na etapie
projektowania obiektowego, z następującymi różnicami:
niektóre klasy wyodrępbnione podczas analizy nie kwalifikują się
do implementacji;
zwykle konieczne jest wprowadzenie nowych klas odnoszących się
do struktur danych i algorytmów niezbędnych dla implementacji
(ekranów, plików, itd)
Obie kategorie klas (anliza, implementacja) są opisywane w sposób jednorodny
przy pomocy tej samej notacji obiektowej.
K.Subieta. Projektowanie systemów informacyjnych, Wykład 3, Folia 21
Implementacja
Obiekty i klasy wyodrębnione podczas projektowania obiektowego są
ostatecznie odwzorowane w postaci konstrukcji języka programowania
(najlepiej obiektowego), bazy danych, oraz konfiguracji sprzętowej.
Zakłada się, że etap programowania powinien być mnie ważną,
w zasadzie pół-mechaniczną czynnością, która nie wypacza
jakichkolwiek elementów projektu. Wszelkie trudne decyzje
dotyczące implementacji muszą być podjęte i udokumentowane
na etapie projetu. To założenie jest szczególnie ważne dla dużych
projektów, kiedy pojedynczy programista nie ma możliwości
ogarnięcia jego całościowej logiki.
Odwzorowanie projektu w implementację powinno być
bezszwowe, bezpośrednie, tak, aby każdy fragment
oprogramowania mógł być jednoznacznie przyporządkowany
odpowiedniemu fragmentowi projektu.
K.Subieta. Projektowanie systemów informacyjnych, Wykład 3, Folia 22
Model obiektów
Cel: wyłowienie tych pojęć z modelowanej rzeczywistości, które są istotne
dla danego zastosowania.
Model obiektów opisuje strukturę obiektów w systemie:
• tożsamość
• związki z innymi obiektami
• atrybuty
• operacje
Jest podstawą dla modeli dynamicznych i funkcjonalnych
Graficzna reprezentacja modelu obiektów w postaci diagramów obiektowych
zawierających klasy obiektów.
Klasy są organizowane w hierarchie, i są połączone z innymi klasami związkami
asocjacyjnymi.
K.Subieta. Projektowanie systemów informacyjnych, Wykład 3, Folia 23
Konstruowanie modelu obiektów
Konstruowanie modelu obiektów wymaga następujących kroków:
*
Identyfikacja obiektów i klas
*
Przygotowanie słownika danych
*
Zidentyfikowanie związków między obiektami
*
Zidentyfikowanie atrybutów obiektów
*
Zorganizowanie i uproszczenie klas obiektów z użyciem dziedziczenia
*
Analiza ścieżek dostępu dla prawdopodobnych zapytań
*
Iteracje i precyzowanie modelu
*
Grupowanie klas w moduły
K.Subieta. Projektowanie systemów informacyjnych, Wykład 3, Folia 24
Budowa modelu obiektowego - przykład
W Systemie ROZGRYWEK LIGII PIŁKARSKIEJ zbierane są informacje o
drużynach występujących w lidze, rozgrywanych przez nie spotkaniach oraz
kibicach drużyn.
W rozgrywkach Ligii Piłkarskiej uczestniczy wiele zespołów.
Rozgrywają one między sobą mecze zgodnie z harmonogramem rozgrywek.
Każdy mecz odbywa się w ustalonym dniu i godzinie oraz na wybranym stadionie.
Każda drużyna prowadzona jest przez jednego szkoleniowca (trenera), który ustala
plan treningów zespołu.
Treningi danej drużyny odbywają się na różnych stadionach, przy czym na tym
samym stadionie może trenować kilka drużyn.
Prezes drużyny nadzoruje i koordynuje jej działalność oraz ma decydujący głos w
sprawie powoływania zawodników do zespołu.
Po zakończeniu rozgrywek drużyny klasyfikowane są na podstawie sumy zdobytych
punktów oraz strzelonych i straconych bramek.
Każda drużyna piłkarska posiada swoich fanów, którzy wspierają jej działalność oraz
kibicują jej w trakcie rozgrywanych meczy.
K.Subieta. Projektowanie systemów informacyjnych, Wykład 3, Folia 25
Przykładowy model obiektów
Rozgrywki
Ligii Piłkarskiej
OSOBA
FAN
TRENER
prowadzi
wspomaga
PREZES
ZAWODNIK
gra dla
DRUŻYNA
kieruje
trenuje na
grają
przeciwko
sobie
kibicuje
MECZ
K.Subieta. Projektowanie systemów informacyjnych, Wykład 3, Folia 26
odbywa się
STADION
Model dynamiczny
Opisuje te aspekty analizowanego systemu, które są związane z czasem i
kolejnościa wykonywania operacji.
• zdarzenia, które wyznaczają zmiany
• sekwencje
zdarzeń
• stany, które definiują kontekst zdarzeń
• organizację zdarzeń i stanów
Model dynamiczny obejmuje sterowanie, tj. taki aspekt systemu, który
odzwierciedla następstwo operacji, bez wnikania co te operacje robią,
na czym one działają, i jak są zaimplementowane.
Model dynamiczny jest reprezentowany graficznie w postaci diagramów stanów.
Każdy diagram stanów opisuje kolejności stanów i zdarzeń dozwolonych w systemie
dla jednej klasy obiektów.
K.Subieta. Projektowanie systemów informacyjnych, Wykład 3, Folia 27
Model funkcjonalny
Dotyczy tych aspektów systemu, które zajmują się transformacją wartości tj. funkcjami, odwzorowaniami, ograniczeniami, zależnościami funkcyjnymi.
Model funkcjonalny przykrywa to, co system robi, bez wnikania jak i kiedy to robi.
Model funkcjonaly pokazuje statyczną zależność pomiędzy czynnościami
wykonywanymi przez system, bez określania następstwa czasowego tych czynności.
Model funkcjonalny jest reprezentowany przez
diagram przepływu danych.
Pokazuje on zależności pomiędzy wartościami i obliczeniami wartości wyjściowych
z wartości i funkcji wejściowych, bez rozpatrywania kiedy i czy funkcje są wykonywane.
Niektórzy metodolodzy (Yourdon) uważają tę cechę OMT za niekonsekwentną.
K.Subieta. Projektowanie systemów informacyjnych, Wykład 3, Folia 28
Schematy Przepływu Danych - Przykład
PASAŻER
Karta
pokładowa
Bilet do
odprawy
ODPRAWA
PASAŻERÓW
Zrealizowana
odprawa
Sprawdzenie
rezerwacji
Bilet z
rezerwacją
miejsca
Żądanie
rezerwacji
miejsca
Zarezerwowane
miejsce
REZERWACJA
MIEJSC
W SAMOLOCIE
LISTA REZERWACJI
Diagram nie odwzorowuje zależności czasowych
Semantyka jest wyrażana poprzez NAZWY OBIEKTÓW
K.Subieta. Projektowanie systemów informacyjnych, Wykład 3, Folia 29
Zależności pomiędzy modelami
Każdy model opisuje specyficzny aspekt modelowanej rzeczywistości, ale
zawiera odniesienia do pozostałych modeli.
Model obiektów:
opisuje strukturę, na której działają model dynamiczny i model funkcjonalny.
Operacje w modelu obiektów odpowiadają zdarzeniom w modelu dynamicznym
lub funkcjom w modelu funkcjonalnym
Model dynamiczny opisuje strukturę sterowania związaną z obiektami.
Model funkcjonalny opisuje
• funkcje wywoływane poprzez operacje w modelu obiektów,
• argumenty tych funkcji,
• akcje w modelu dynamicznym
• ograniczenia na wartości obiektów
Niejasności mogą być wyjaśniane w języku naturalnym lub poprzez specyficzną notację
K.Subieta. Projektowanie systemów informacyjnych, Wykład 3, Folia 30