- obiektowej metodyki analizy i projektowania SI

Slides:



Advertisements
Podobne prezentacje
7. Metody analizy i modelowania strukturalnego SI
Advertisements

Związki w UML.
Modelowanie przypadków użycia
Projektowanie w cyklu życia oprogramowania
Studia Podyplomowe IT w Biznesie Inżynieria Oprogramowania
Część 2 OiZPI Iteracyjny przyrostowy model cyklu życiowego Rational Unified Process™ w materiałach wykorzystano: K.Subieta: Budowa i integracja systemów.
Formalizacja i uwiarygodnianie Iteracyjny proces syntezy modeli
PROGRAMOWANIE STRUKTURALNE
Kamil Łącki Dominik Strzelichowski
Projektowanie Aplikacji Komputerowych
UML Unified Modeling Language
Propozycja metodyki nauczania inżynierii oprogramowania
Projektowanie systemów informacyjnych
Co UML może zrobić dla Twojego projektu?
Bartosz Walter Prowadzący: Bartosz Walter
Tomasz Jabłoński Michał Ziach
Cykle życia oprogramowania
Inżynieria Oprogramowania dla Fizyków
Projektowanie systemów informacyjnych
Diagram czynności (Activity Diagrams)
Rational Unified Process
Wstęp do programowania obiektowego
Projektowanie i programowanie obiektowe II - Wykład IV
Projektowanie i programowanie obiektowe II - Wykład II
Wstęp do interpretacji algorytmów
Praca Inżynierska „Analiza i projekt aplikacji informatycznej do wspomagania wybranych zadań ośrodków sportowych” Dyplomant: Marcin Iwanicki Promotor:
Projektowanie - wprowadzenie
Projektowanie dynamiki - diagramy interakcji
Wykład 4 Analiza i projektowanie obiektowe
Wykład 5 UML - Unified Modeling Language
Wykład 3 Analiza i projektowanie strukturalne
Analiza i projektowanie systemów informacyjnych
Wykład 2 Cykl życia systemu informacyjnego
C.d. wstępu do tematyki RUP
Unified Modeling Language graficzny język wizualizacji, specyfikowania, tworzenia i dokumentowania systemów informatycznych.
Wykład 1 – część pierwsza
Źródła: podręcznikopracował: A. Jędryczkowski.
Podsumowanie metodologii OMT
Programowanie obiektowe – język C++
Programowanie obiektowe 2013/2014
ZWIĄZKI MIĘDZY KLASAMI KLASY ABSTRAKCYJNE OGRANICZENIA INTERFEJSY SZABLONY safa Michał Telus.
1 Każdy obiekt jest scharakteryzowany poprzez: tożsamość – daje się jednoznacznie wyróżnić; stan; zachowanie. W analizie obiektowej podstawową strukturą
Modelowanie obiektowe Diagramy UML – diagram przypadków użycia
Unified Modeling Language - Zunifikowany Język Modelowania
Wprowadzenie do UML dr hab. inż. Kazimierz Subieta profesor PJWSTK.
Modelowanie obiektowe Diagramy klas
UML W V ISUAL S TUDIO Mateusz Lamparski. UML D EFINICJA Unified Modeling Language (UML) to graficzny język do obrazowania, specyfikowania, tworzenia i.
Interakcja człowiek – komputer Podstawy metod obiektowych mgr inż. Marek Malinowski Zakład Matematyki i Fizyki Wydz. BMiP PW Płock.
Algorytmika.
Moduł III Definiowanie i planowanie zadań typu P 1.
Treści multimedialne - kodowanie, przetwarzanie, prezentacja Odtwarzanie treści multimedialnych Andrzej Majkowski 1 informatyka +
Model obiektowy bazy danych
Diagram aktywności (czynności)
Diagram klas Kluczowymi elementami są: klasy (class)
Zarządzanie zagrożeniami
Analiza jako początek i podstawa zmian w systemie informatycznym.
Proces tworzenia oprogramowania Proces tworzenia oprogramowania jest zbiorem czynności i związanych z nimi wyników, które prowadzą do powstania produktu.
Modelowanie obiektowe - system zarządzania projektami.
Michał Sipek Piotr Kapciak
Projektowanie obiektowe. Przykład: Punktem wyjścia w obiektowym tworzeniu systemu informacyjnego jest zawsze pewien model biznesowy. Przykład: Diagram.
Diagramy przepływu danych
Ergonomia procesów informacyjnych
Projektowanie bazy danych z użyciem diagramów UML Obiektowe projektowanie relacyjnej bazy danych Paweł Jarecki.
Wstęp do interpretacji algorytmów
E. Stemposz. Rational Unified Process, Wykład 10, Slajd 1 wrzesień 2002 Powrót Studia Podyplomowe IT w Biznesie Rational Unified Process Wykład 10 Przepływ.
Inżynieria systemów informacyjnych
Inżynieria Oprogramowania Laboratorium
Wykład 1 – część pierwsza
Cykl życia oprogramowania
Zapis prezentacji:

- obiektowej metodyki analizy i projektowania SI Wprowadzenie do OMT - obiektowej metodyki analizy i projektowania SI

Plan wykładu 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

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 Coad/Yourdon 4% 13% OOIE OMT 17% 32% Ź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? The Unified Modelling Language 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 wykład dr hab. inż. Kazimierz Subieta profesor PJWSTK 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 funkcjonalnym (strukturalnym) 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 Fumkcjonalny 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

Proces analizy Analiza Projektowanie Użytkownicy Generowanie wymagań Projektanci Kierownictwo Sformułowanie problemu 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 tożsamość związki z innymi obiektami atrybuty operacje 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 FAN TRENER ZAWODNIK PREZES 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 diagram przepływu danych. 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 Karta pokładowa Bilet z rezerwacją miejsca Żądanie rezerwacji miejsca Bilet do odprawy ODPRAWA PASAŻERÓW REZERWACJA MIEJSC W SAMOLOCIE 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ę