UML - Unified Modeling Language

Prezentacja na temat: "UML - Unified Modeling Language"— Zapis prezentacji:

1 UML - Unified Modeling Language
Część 1 - Wprowadzenie

2 Modelowanie (obiektowe) Historia UML Wprowadzenie, przegląd diagramów
Plan wykładu Modelowanie (obiektowe) Historia UML Wprowadzenie, przegląd diagramów

3 Modelowanie obiektowe
Otwarty format UML (ang. Unified Modeling Language, czyli Ujednolicony Język Modelowania), to język formalny służący do opisu świata obiektów w analizie obiektowej oraz programowaniu obiektowym (Wikipedia) Model to „układ (...) możliwie mało skomplikowany, działający analogicznie do oryginału” (Słownik Języka Polskiego, PWN 1998)

4 Modelowanie obiektowe
System informatyczny powinien być jak najwierniejszym modelem otaczającego świata. W jaki więc sposób skonstruować model, aby spełniał to wymaganie? Klienci mają pewne wymagania w stosunku do systemu. Zamawiający znają problem i potrafią o niej opowiadać za pomocą specjalistycznego słownictwa. Nie potrafią jednak tworzyć technicznych opisów systemu. Programiści wiedzą, jak konstruować systemy. Programiści tworzą system korzystając z języka programowania. Są oni zorientowani w szczegółach platformy programowej. Nie są natomiast ekspertami w dziedzinie, dla której tworzą system.

5 Modelowanie obiektowe
Obiekty na danym poziomie abstrakcji ukrywają informacje nieistotne dla czytelnika modelu. Obiekty są zatem pewnego rodzaju czarnymi skrzynkami. Dopiero po „otwarciu” odkrywamy dalsze szczegóły. Obiekty z jednej strony obiekty odpowiadają pojęciom z modelowanej dziedziny problemu. Z drugiej strony są podstawą implementacji realizowanego systemu.

6 Modelowanie obiektowe
Elementem, który pozwala pogodzić język użytkownika z językiem programisty jest obiekt. Obiekty z jednej strony obiekty odpowiadają pojęciom z modelowanej dziedziny problemu. Z drugiej strony są podstawą implementacji realizowanego systemu.

7 Modelowanie obiektowe
Korzystając z pojęcia obiektów tworzy się modele obiektowe (odwzorowanie rzeczywistych systemów). Modelowanie obiektowe polega więc na: wyodrębnianiu obiektów  opisywaniu struktury i dynamiki działania obiektów oraz klasyfikacji obiektów  opisywaniu struktury powiązań klas obiektów opisywaniu dynamiki współpracy obiektów

8 Modelowanie obiektowe
Modelowanie obiektowe polega na sporządzeniu opisu, odwzorowującego strukturę i dynamikę składających się na niego obiektów. Opis taki może być wykonany na różne sposoby, np: Opis słowny Opis w postaci rysunków i diagramów Modele obiektowe będziemy warto tworzyć za pomocą jednolitej notacji, wspólnej dla wszystkich. Dzięki temu mamy pewność, że model zostanie zrozumiany. Przykładem takiej notacji jest graficzny język UML.

9 Historia UML Historia UML
do 1994 wiele konkurencyjnych metod analizy i projektowania 1994, 1995 Autorzy trzech dominujących G. Booch (OOAD), I. Jacobson(OOSE) , J. Rumbaugh (OMT) rozpoczynają pracę w Rational Software Corporation 1994 rozpoczęto oficjalne prace nad UML 1995 ujednolicenie metod OOAD i OMT, powstanie roboczej wersji UML 0.8a 1996 rozszerzenie wersji roboczej o OOSE, wersja 0.9 1996 powstaje konsorcjum firm (HewlettPackard, IBM, Microsoft, Oracle, Rational .....) 1997 styczeń zatwierdzenie języka UML (wersja 1.0) przez OMG

10 Potrafią też zachowywać się w odpowiedni sposób w różnych sytuacjach
UML Wprowadzenie Obiekt (ang. object) może być opisany za pomocą: tożsamości, stanu i zachowania. Każdy obiekt ma zatem indywidualną tożsamość odróżniającą go od innych obiektów. Obiekty zawierają również elementarne składniki o zmieniających się wartościach, które określają ich stan. Potrafią też zachowywać się w odpowiedni sposób w różnych sytuacjach

11 UML Wprowadzenie Przewagą UML nad innymi formalnymi językami opisu projektów informatycznych jest to, że stworzony model jest niezwykle przyjazny dla programisty.

12 UML Wprowadzenie UML określa szereg diagramów, opisujących statyczne i dynamiczne zachowanie systemu. UML obejmuje 13 rodzajów diagramów: • diagram pakietów • diagram klas i diagram obiektów • diagram struktur złożonych • diagram komponentów • diagram wdrożenia • diagram przypadków użycia • diagram czynności • diagram maszyny stanowej • diagramy interakcji (sekwencji, komunikacji, przeglądu interakcji) • diagram uwarunkowań czasowych Modelowanie statyczne Modelowanie dynamiki

13 UML Wprowadzenie Przegląd diagramów

14 Diagramy obiektów (object diagram)
Obiekt (ang. object) może być opisany za pomocą: tożsamości, stanu i zachowania. Moja_pralka Typ: Frania Nazwa modelu: kt100 Numer fabryczny: Pojemność:7 kg Co można robić? Włożyć pranie Nasypać proszek Wyjąć ubrania

15 Diagramy klas (class diagram)
W programowaniu obiektowym klasa jest definicją dla obiektów. Definicja obejmuje dopuszczalny stan obiektów oraz ich zachowania. Obiekt, który został stworzony na podstawie danej klasy nazywany jest jej instancją.

16 Diagramy przypadków użycia (use case diagram)
Przypadek użycia to opis zachowania systemu z punktu widzenia użytkownika. Służy do uchwycenia podstawowych założeń i funkcjonalności systemu z punktu widzenia jego użytkowników.

17 Diagramy przypadków użycia
Diagramy przypadków użycia pozwalają na zaznaczenie granic systemu.

18 Diagram stanów (statechart diagram)
Odnosi się do obiektów klas. Reprezentuje przejścia od jednego stanu do kolejnych.

19 Diagram interakcji (interaction diagram)
W systemie obiekty pozostają we wzajemnych zależnościach czasowych i wpływają na siebie. Diagramy przebiegu opisują dynamikę zachowania systemu w czasie. Woda wpływa do bębna przez rurę. Bęben pozostaje nieruchomy przez pięć minut. Woda przestaje wpływać do bębna. Bęben obraca się przez 15 minut. Woda z mydłem spływa do ścieku. Woda zaczyna ponownie napływać. Bęben obraca się. Woda przestaje napływać. Woda spłukująca spływa do ścieku. Bęben szybko wiruje przez 5 minut. Bęben przestaje się obracać. Pranie zakończone.

20 Diagram interakcji (interaction diagram)

21 Diagram czynności (acitvity diagram)
Przydają się do opisu operacji wykonywanych przez obiekt, zachodzących w określonej kolejności.

22 Diagram kooperacji Wyrażają kooperację poszczególnych komponentów systemu.

23 Widoki modelu Istnieje wiele diagramów (także kilka niewymienionych) oraz sposobów przedstawienia modelowanego systemu. Najczęściej stosowany to system widoków 4+1

24 Widoki logiczny Przedstawia abstrakcyjny opis części systemu. Używany jest do modelowania części systemu oraz sposobów, w jaki one współdziałają. Należą do niego: Diagramy klas Diagramy obiektów Diagramy stanów Diagramy interakcji

25 Widoki procesu Opisuje procesy w systemie. Jest on szczególnie przydatny przy wizualizacji wszystkich przypadków, jakie muszą zajść w systemie. Zawiera zazwyczaj diagramy czynności

26 Widoki konstrukcji Opisuje sposób, w jaki części systemu zorganizowane są w moduły oraz komponenty. Jest przydatny do zarządzania warstwami w obrębie architektury systemu. Zawiera zazwyczaj: Diagramy pakietów Diagramy komponentów

27 Widoki fizyczny Opisuje w jaki sposób opisany system jest powoływany do życia w postaci rzeczywistych obiektów. Diagramy pokazują, w jaki sposób części abstrakcyjne odwzorowywane są do postaci rzeczywistego, wdrożonego systemu. Zawiera zazwyczaj diagramy wdrożenia

28 Widoki przypadków użycia
Widok opisuje funkcjonalność modelowanego systemu z perspektywy zewnętrznej. Wszystkie inne widoki bazują na przypadkach użycia. Zawiera zazwyczaj: Diagramy przypadków użycia Opisy Diagramy przeglądowe

29 Modelowanie przypadków użycia

30 Przypadki użycia Przypadek użycia jest sytuacją, w której dany system jest używany w celu spełnienia jednego lub więcej wymagań użytkowników. „Dotykają” wszystkich elementów składających się na model systemu.

31 Przypadki użycia Przypadek użycia definiują funkcjonalność systemu z punktu widzenia użytkownika, pozwalają rozdzielić prace nad projektem (przypisane p.u. do konkretnych osób) oraz pomagają w tworzeniu testów. System oraz „aktorzy” na zewnątrz systemu:

32 Stereotypy Stereotypy sygnalizują specjalne użycie elementu notacji UML. Modyfikują znaczenie tego elementu. Aktor w UML jest klasą o nadanym znaczeniu (stereotypie)

33 Notatki Notatki pozwalają na dodanie komentarzy do diagramów.

34 Przypadki użycia Systemu używają aktorzy. Aktorami mogą być: − Osoby (pojedyncza osoba, grupa, organizacja itp.) − Zewnętrzne systemy (programowe bądź sprzętowe) − Czas Ogólnie można wyróżnić aktorów osobowych i nieosobowych

35 Przypadki użycia Aktorzy reprezentują szczególny przypadek pewnej „klasy”. Aktorzy mogą być powiązani ze sobą relacjami uogólnienia/uszczegółowienia. Można więc cechy aktora np. dziedziczyć.

36 Przypadki użycia - aktorzy
Można przyjmować oznaczenia specjalne (które nie są objęte standardem): Czas Termin płatności Ostatni dzień miesiąca Aktor nieosobowy, urządzenie Nagrywarka DVD-RAM Kiosk multimedialny Aktor osobowy Konsultant Dział sprzedaży System zewnętrzny System rezerwacji pokoi System sporządzania zestawień Wikipedia

37 Przypadki użycia – system biblioteczny
Przypadek użycia reprezentuje funkcję dostępną dla aktora. Asocjacja (ang. association) - związek pomiędzy dwoma lub więcej klasyfikatorami, opisującym powiązanie pomiędzy ich instancjami. Asocjacja skierowana (ang. directed association) - asocjacja skierowana dziedziczy wszystkie cechy po asocjacji, lecz dodatkowo wskazuje kierunek nawigacji. Używana kiedy chcemy ukazać inicjatora interakcji (np. Aktor "Klient" jest inicjatorem przypadku użycia "Kup produkt"). Wikipedia, ,

38 Przypadki użycia – system biblioteczny
Przypadki użycia mogą być powiązane zależnościami. Uszczegółowienie (stereotyp <<include>>) oznacza wykonanie jednego przypadku użycia przez drugi. Wikipedia, ,

39 Przypadki użycia – system biblioteczny
Przypadki użycia mogą być powiązane zależnościami. Rozszerzenie (stereotyp <<extend>>) oznacza dodatkową funkcjonalność przypadku użycia

40 Przypadki użycia – system biblioteczny
Przypadki użycia mogą być powiązane zależnościami. Uszczegółowienie oznacza szczegółową funkcjonalność dla danego przypadku użycia (analogia do dziedziczenia)

41 Przypadki użycia – system biblioteczny
Granice systemu

42 Przypadki użycia – uwagi
Tworzenie przypadków użycia jest procesem iteracyjnym. Często po dodaniu większej ilości informacji odkrywa się brakujące elementy i trzeba poprawiać poprzednio utworzone diagramy. Na tym jednak polega rozwój i „odkrywanie” systemu. Diagramom przypadków użycia powinien towarzyszyć opis, zawierający np: Powiązane wymagania Kontekst zadaniowy Warunki wstępne Warunek pomyślnego zakończenia Aktorzy główni Aktorzy drugoplanowy Wyzwalacz Rozszerzenia

43 Przypadki użycia – administracja systemem pamiętników internetowych

44 Przypadki użycia – system biblioteczny (ext.)

45 Przypadki użycia – automat do sprzedaży papierosów

46 Przypadki użycia – warsztat samochodowy

47 Przykład Zestaw diagramów przypadków użycia związanych z obsługą aukcji internetowych

48 Przykład Internetowy system aukcyjny

49 Diagramy czynności

50 Diagramy czynności (aktywności)
Diagramy aktywności są jedynymi diagramami w widoku procesu modelowanego systemu. Są jednym z rodzajów diagramów języka UML opisujących dynamikę systemu. .

51 Diagramy czynności (aktywności)
Przypadku użycia pokazują, co system powinien robić. Diagramy czynności (ang. activity diadrams) pokazują w jaki sposób osiągnąć zamierzone cele. Diagramy czynności są szczególnie przydatne w modelowaniu procesów biznesowych. Wiele narzędzie typu business process management (BPM) umożliwia zdefiniowanie procesów biznesowych właśnie na diagramach czynności, a następnie ich wykonanie.

52 Diagramy czynności (aktywności)
Stosowana konwencja:

53 Przykład: tworzenie konta bloga internetowego:

54 Jednoczesne wykonywanie wielu zadań
Czynności nie zawsze wykonuje się w sposób sekwencyjny. Aby wskazać równoległe wykonywanie czynności korzysta się z rozwidleń (ang. fork)

55 Grupowanie czynności Czynności można grupować pod określoną nazwą, aby np. odwoływać się do nazwy czynności.

56 Grupowanie czynności

57 Zadania czasowe Aby podkreślić czas na wykonanie określonej czynności lub opóźnienie korzystamy ze znacznika czasowego. Czekaj 3 dni StarUML nie posiada tego symbolu.

58 Reprezentacja obiektów w diagramach czynności
Obiekty reprezentowane są za pomocą węzłów obiektów. Może on zostać użyty dla zaprezentowania, że dany obiekt został użyty, jest tworzony lub został zmodyfikowany. StarUML nie posiada tego symbolu.

59 Alternatywne reprezentacje przepływu obiektów
Istnieją różne sposoby notacji dla przepływu obiektów:

60 Przykład Przykład przepływu obiektów dla obiektu „Order”:

61 Zestawy obiektów Czasami istnieje potrzeba zaznaczenia, że dla określonych czynności potrzeba zestawu obiektów na wejściu:

62 Prezentacja danych wejściowych oraz wyjściowych czynności
Notacja służy podkreśleniu, że cała czynność wymaga określonych danych (obiektów) oraz udostępnia dane wyjściowe (obiekty).

63 Nadawanie oraz odbieranie sygnałów

64 Przerywanie czynności
Obszary przerwań służą do przedstawienia czynności, które w określonym momencie mogą zostać przerwane, z jednoczesną zmianą ścieżki czynności. Obszar przerwań StarUML nie posiada tego symbolu.

65 Partycje (tory pływackie)
Tory pływackie, rysowane za pomocą linii ciągłych. Służą do określania, który element systemu wykonuje dane akcje.

66 Partycje (tory pływackie)

67 Obszary rozszerzenia Obszar rozszerzenia jest fragmentem diagramu, z wyspecyfikowanymi wejściami i wyjściami, który jest wykonywany wielokrotnie - tyle razy ile otrzyma elementów wejściowych.

68 Złożone diagramy czynności - konektory
Gdy zachodzi potrzeba można przekazywać sterowanie pomiędzy różnymi miejscami na diagramie, bez rysowania strzałek Konektory służą właściwie tylko do zwiększania czytelności diagramów StarUML nie posiada tego symbolu.

69 Przykłady Realizacja zamówienia

70 Przykład Zestaw diagramów czynności związanych z obsługą aukcji internetowych

71 Przykłady Wypożyczenie książki

72 Przykłady Logowanie

73 Przykłady Licytacja

74 Przykłady Licytacja – finalizacja aukcji

75 Przykłady Wystawienie aukcji

76 Przykłady Przeglądanie historii