1 / 34

Język UML (Unified Modelling Language)

Język UML (Unified Modelling Language). Przyczyny opracowania języka UML. Różnorodność modeli stosowanych w metodach obiektowych, tworzonych w latach 90-ych. Konieczność ujednoliconego modelowania modelowania aspektu statycznego i dynamicznego modelu (systemu)

jolene
Download Presentation

Język UML (Unified Modelling Language)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Język UML(Unified Modelling Language)

  2. Przyczyny opracowania języka UML • Różnorodność modeli stosowanych w metodach obiektowych, tworzonych w latach 90-ych. • Konieczność ujednoliconego modelowania modelowania aspektu statycznego i dynamicznego modelu (systemu) • Dostarczenie narzędzia do modelowania tak problemu jak i tworzonego rozwiązania.

  3. Źródła języka UML • Metoda OBJECTORY (Jacobson) • OMT (Raumbough) • Metoda Boocha

  4. Cele języka UML • Modelowanie (sformalizowany opis) problemu • Specyfikacja wymagań użytkowników (prezentacja modelu nowego rozwiązania) • Prezentacja projektu nowego rozwiązania (składniki technologiczne) • Możliwość dogodnego przekształcania modeli na kod języków programowania obiektowego. • Dokumentowanie prac nad rozwiązaniem informatycznym

  5. Artefakty możliwe do prezentacji przez UML • Wymagania • Architektura • Projekt (jego składniki) • Kod źródłowy • Testy • Prototypy • Kolejne wersje rozwiązania

  6. Podstawowe pojęcia języka UML • Obiekt • Klasa • Atrybut • Operacja – usługa, której można zażądać od obiektu • Metoda – implementacja operacji w klasie obiektów, zawierająca algorytm • Relacja – zależność występująca pomiędzy klasami w modelu klas • Interfejs – deklaracja operacji, służących do realizowania usługi przez obiekt

  7. Abstrakcyjna klasa UML Służy do klasyfikowania obiektów (stereotypów) na podstawie struktury lub zachowania Są to: • Typy • Interfejsy (aplikacji) • Klasy • Podsystemy • Pakiety • Bazy danych • Tabele bazy danyc, itd..

  8. Diagramy modelowania i projektowania struktury SI • Diagram klas • Diagram obiektów (egzemplarzy klas) • Diagramy komponentów • Diagramy wdrożenia

  9. Przykład diagramu klas Liczność obligatoryjna Klient Zamówienie 1..1 o..* Nazwa adres Data przyjęcia przygotowane numer cena ocenakredytowa() 1 asocjacja Do realizacji() Zamknij() Klient - osoba Klient - firma Linia pozycji Reguła Integ- ralności Pozycja zamówienia Karta kredyt Nazwisko kontaktu Wskaźnik kredytu Limit kredytu * Ilość cena zrealizowanny Przypomnij() Rachunek za miesiąc ocenakredytowa()=‘słaba’ 1..* Przedstawiciel handlowy 0..* 1 Liczność opcjonalna 0..1 Pracownik Produkt

  10. Cele diagramów komponentów • Prezentacja rozwiązań przyjmowanych w trakcie realizacji projektu informatycznego • Przedstawiają architekturę sytemu informatycznego

  11. Przykład diagramu komponenetów Przetwarzanie biznesowe Interfejs użytkownika Baza danych Procedury bezpieczeństwa

  12. Przykład diagramu grupowania Podsystem „Planowanie” Reklama Harmonogramowanie Podsystem „Biuro” Kartoteka klientów Dokumentowanie Sprzedaży Ewidencja sprzedaży

  13. Diagramy modelowania dynamiki (procesów przetwarzania) • Diagram przypadków użycia • Diagramy interakcji: • sekwencji czyności • współdziałania • Diagramy przekształceń stanów • Diagram czynności

  14. Diagram przypadków użycia Analiza zamówienia Dział zamówień Przygotowanie wysyłki Kasa Składanie zamówienia Realizacja płatności Klient fakturowanie Księgowość

  15. Cele diagramu sekwencji czynności • Wskazanie obiektów i użytkowników biorących udział w przypadku oraz sposobu ich komunikowania się. • Ujęcie chronologiczne przesyłanych komunikatów i wywoływanych przez nie czynności w obiektach.

  16. Anonimowy klient Diagram sekwencji czynności :Pozycja towarowa :Rachunek :Zamówienie Utwórz() Rezerwuj(data, rachunek Obciąż(koszt) Bonus(data,rach.) powrót Potwierdź realizację Likwidacja

  17. Cele diagramu współdziałania (kolaboracji) • Reprezentacja powiązań pomiędzy obiektami (klasami) • Podstawa do wyznaczenia pakietów (modułów, podsystemów)

  18. Pojęcia definiowania interakcji obiektów i ich notacja graficzna • Interakcja – wymiana komunikatów między obiektami w określonym celu • Komunikat – specyfikacja łączności pomiędzy metodami pryporzadkowanymi klasom obiektów

  19. Diagram współdziałania - analiza zamówienia :Formularz wprowadzania zamówienia 1:Przygotuj() 5: Konieczne do zamówienia () :Zamówienie 2: Przygotuj linię zamówienia() Specjalna linia :Linia zamówienia Specjalny zapas : Pozycja magazynowa 3:Sprawdź() 4: [Sprawdż=prawda] Zmniejsz zapas() 7: [Sprawdź=prawda] nowa() 6: nowa() :Pozycja wysyłki :Pozycja zamówiona

  20. Cele diagramów przekształceń stanów • Reprezentują one tak zwane maszyny stanowe • Maszyna stanowa określa ciąg stanów przyjmowanych przez obiekt w czasie jego życia, a także reakcje obiektu na te zdarzenia • Maszyna stanowa może być dodatkowo reprezentowana przez diagramy czynności – reprezentując przepływ sterowania od czynności do czynności.

  21. Podstawowe pojęcia maszyny stanowej • Otoczenie – obiekty odbierające i emitujące komunikaty do obiektu naszego zainteresowana • Stan – okoliczność lub sytuacja, w której obiekt znajduje się w trakcie swego życia • Stan początkowy i końcowy • Przejścia • Zdarzenie uruchamiające • Warunek dozoru – wyrażenie logiczne określające przejście z jednego do drugiego stanu obiektu • Akcja – niepodzielna procedura obliczeniowa, wywołana pzez zdarzenie uruchamiające

  22. Diagram przekształceń stanów Stan początkowy Stan Końcowy Zamówienie przyjęte Pozycje niezrealizowane Zamówienie zapłacone Zamówienie Zrealizowane częściowo Zamówienie analizowane Uregulowana płatność Zamówienie fakturowane Wysyłka Niektórych pozycji Zakończenie analizy Zamówienie przyjęte do realizacji Zamówienie zrealizowane całkowicie Wysłana faktura Wysyłka Wszystkich pozycji

  23. Diagramy przekształceń stanów • Zagnieżdżone • współbieżne

  24. Przykład zagnieżdżonego diagramu przekształceń stanów Zegarek elektroniczny ustaw Wyświetl Ustaw ustaw Wyświetl czas Wyświetl datę Wyświetl alarm Ustaw czas Ustaw datę Ustaw alarm

  25. Przykład diagramu współbieżnego przekształcania stanów Stanowisko pracy Komputer Lampka Zegarek Lampka Komputer Zegarek Wyłączona Włączona

  26. Diagram czynności (aktywności) Cel: • Reprezentowanie przypadku użycia lub grupy przypadków użycia jako sieci działań • Określenie obiektów i ich stanów związanych z czynnościami występującymi w przypadku użycia

  27. Przykład diagramu czynności(obsługa zamówienia) Dział sprzedaży Magazyn Klient Zamówienie rejestrowane Przyjmij Zamówienie Żądaj obsługi Zamówienie przyjęte Płać Zamówienie przygotowane Wystaw fakturę Przygotuj zamówienie Zamówienie wysłane Dokonaj wysyłki Ewidencjonuj zamówienia zrealizowane Zamówienie archiwowane

  28. Wersja 2.0 Model systemu składa się z 4 komponentów: • Superstructura • Infrastruktura • Język reguł obiektowych (OCL) • Diagram wymiany (Interchange diagram)

  29. 3 Nowe diagramy • Diagram strukturalny (Composite structure diagram ) • Diagram harmonogramowania (Timing Diagram) • Diagram przeglądu interakcji (Interaction Overview Diagram)

  30. Diagramy struktury • Klas (ang. class diagram) • Obiektów (object diagram) • Pakietów • Struktur połączonych (złożonych) • Wdrożeniowe (diagram abstrakcyjny): • Komponentów • Rozlokowania

  31. Diagramy dynamiki • Przypadków użycia (use case) • Czynności (activity) • Maszyny stanowej (przekształceń stanów obiektu) • Interakcji (diagramy abstrakcyjny) • Sekwencji • Komunikacji • Harmonogramowania (lub Zależności czasowych) • Sterowania interakcją

  32. Mechanizmy rozszerzania definicji języka UML • 4- poziomowa architektura metamodelowania • Stereotypy

  33. Architektura języka • Warstwa meta-metamodelu (poziom M3): Definicje pojęć • Warstwa metamodelu (poziom M2): Definicje metaklas – ich atrybutów, operacji, itp.. • Warstwa modelu (poziom M1): definicje klas ich atrybutów itp.. Realizowane przez analityków dla konkretnego problemu • Warstwa użytkownika (poziom M0): definicje konkretnych obiektów, wartości atrybutów

  34. Stereotypy • Nowe typy elementów modelujących w języku • Są one definiowane poprzez pokazanie związków z innymi z metaklasami języka UML • Przykład: <<Metaklasa>> Klasa obiektów <<stereotyp>> Projekt

More Related