Projektowanie systemów informacyjnych

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

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

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. 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 Środki informatyczne: sprzęt, oprogramowanie, sieć, języki, narzędzia, technologie.

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

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.

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 Modelowanie obiektów i klas, modelowanie zachowania, modelowanie dynamiczne, modelowanie przepływu danych, ... Techniki: Konkretna składnia i semantyka służąca do zapisu modelu: diagramy obiektów i klas, diagramy dynamiczne, diagramy przepływu danych Notacje:

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

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.

Metodyki obiektowe OMT, Rumbaugh MainstreamObjects, Yourdon OOA/OOD, Coad/Yourdon Express Catalysis, D’Souza & Wills Martin/Odell Fusion, HP Laboratories OODA, Booch DOOS, Wirfs-Brock OOSA, Shlaer-Mellor Goldberg/Rubin Objectory, Jacobson OORAM BON (Business Object Notation), Nerson & Walden Sintropy EROOS (Entity-Relationship Object-Oriented Specification) OSA MOSES (Methodology for Object-Oriented Software Engineering of System) UML (Unified Modelling Language), Booch, Jacobson, Rumbaugh

Jakie metodyki są używane? Fusion Inne Shlaer-Mellor 4% 17% 13% Booch 4% Coad/Yourdon 13% OMT OOIE 32% 17% Źródło: Gartner Group - 1995

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

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

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.

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

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

Diagramy i techniki OMT Model Modelowany poprzez Cel Komunikacja klas (class communication) (CADRE) Asocjacja klas (class association) (OMT) Dynamiczny (OMT) Fumkcjonalny (OMT) Diagram komunikacji klas (Class Communication Diagram, CCD) Diagram generalizacji komunikatów (Message Generalization Diagram, MGD) Diagram asocjacji klas (Class Association Diagram, CAD) Diagram zmian stanów (State Transition Diagram, STD) Diagram tropów zdarzeń (Event Trace Diagram, ETD) Diagram przepływu danych (Data Flow Diagram, DFD) Modeluje komunikację wewnątrz systemu poprzez pokazanie interfejsów między obiektami. Dekomponuje strukturę złożonych komunikatów. Modeluje statyczną strukturę system poprzez sieć klas i związków. 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ę. 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 Projektowanie Model funkcjonalny Projektowanie systemu Projektowanie obiektów

Sformułowanie problemu Proces analizy Użytkownicy Generowanie wymagań Projektanci Kierownictwo Wywiady z użytkownikami Budowa modeli Analiza Wiedza dotycząca dziedziny problemowej Doświadczenie w zakresie projektów Model obiektów Model dynamiczny Model funkcjonalny Projektowanie

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.

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.

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.

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.

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.

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

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.

Przykładowy model obiektów Rozgrywki Ligii Piłkarskiej OSOBA PREZES FAN TRENER ZAWODNIK prowadzi gra dla kieruje wspomaga DRUŻYNA trenuje na grają przeciwko sobie kibicuje odbywa się STADION MECZ

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.

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ą.

Schematy Przepływu Danych - Przykład PASAŻER Bilet z rezerwacją miejsca Karta pokładowa Żądanie rezerwacji miejsca Bilet do odprawy REZERWACJA MIEJSC W SAMOLOCIE ODPRAWA PASAŻERÓW Sprawdzenie rezerwacji Zarezerwowane miejsce Zrealizowana odprawa LISTA REZERWACJI Diagram nie odwzorowuje zależności czasowych Semantyka jest wyrażana poprzez NAZWY OBIEKTÓW

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ę

Projektowanie systemów informacyjnych