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

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

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)

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.

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.

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.

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

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.

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 http://brasil.cel.agh.edu.pl/~09sbfraczek/uml-definicja-historia,1,54.html

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

UML Wprowadzenie Przewagą UML nad innymi formalnymi językami opisu projektów informatycznych jest to, że stworzony model jest niezwykle przyjazny dla programisty. http://wtoman.awardspace.com/articles/uml.pdf

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

UML Wprowadzenie Przegląd diagramów

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: 012412 1976 Pojemność:7 kg Co można robić? Włożyć pranie Nasypać proszek Wyjąć ubrania

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

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.

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

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

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.

Diagram interakcji (interaction diagram)

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

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

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

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

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

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

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

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

Modelowanie przypadków użycia

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.

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:

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

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

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

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

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

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, , http://wazniak.mimuw.edu.pl/images/7/76/Io-5-wyk.pdf

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, , http://wazniak.mimuw.edu.pl/images/7/76/Io-5-wyk.pdf

Przypadki użycia – system biblioteczny Przypadki użycia mogą być powiązane zależnościami. Rozszerzenie (stereotyp <<extend>>) oznacza dodatkową funkcjonalność przypadku użycia http://wazniak.mimuw.edu.pl/images/7/76/Io-5-wyk.pdf

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) http://wazniak.mimuw.edu.pl/images/7/76/Io-5-wyk.pdf

Przypadki użycia – system biblioteczny Granice systemu http://wazniak.mimuw.edu.pl/images/7/76/Io-5-wyk.pdf

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

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

Przypadki użycia – system biblioteczny (ext.) http://wazniak.mimuw.edu.pl/images/7/76/Io-5-wyk.pdf

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

Przypadki użycia – warsztat samochodowy

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

Przykład Internetowy system aukcyjny

Diagramy czynności

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

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.

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

Przykład: tworzenie konta bloga internetowego:

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)

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

Grupowanie czynności

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.

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.

Alternatywne reprezentacje przepływu obiektów Istnieją różne sposoby notacji dla przepływu obiektów: http://brasil.cel.agh.edu.pl/~09sbfraczek/diagram-aktywnosci,1,10.html

Przykład Przykład przepływu obiektów dla obiektu „Order”: http://brasil.cel.agh.edu.pl/~09sbfraczek/diagram-aktywnosci,1,10.html

Zestawy obiektów Czasami istnieje potrzeba zaznaczenia, że dla określonych czynności potrzeba zestawu obiektów na wejściu: http://brasil.cel.agh.edu.pl/~09sbfraczek/diagram-aktywnosci,1,10.html

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

Nadawanie oraz odbieranie sygnałów

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.

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.

Partycje (tory pływackie)

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.

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. http://brasil.cel.agh.edu.pl/~09sbfraczek/diagram-aktywnosci,1,10.html

Przykłady Realizacja zamówienia http://brasil.cel.agh.edu.pl/~09sbfraczek/diagram-aktywnosci,1,10.html

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

Przykłady Wypożyczenie książki http://brasil.cel.agh.edu.pl/~09sbfraczek/diagram-aktywnosci,1,10.html

Przykłady Logowanie http://brasil.cel.agh.edu.pl/~09sbfraczek/diagram-aktywnosci,1,10.html

Przykłady Licytacja http://brasil.cel.agh.edu.pl/~09sbfraczek/diagram-aktywnosci,1,10.html

Przykłady Licytacja – finalizacja aukcji http://brasil.cel.agh.edu.pl/~09sbfraczek/diagram-aktywnosci,1,10.html

Przykłady Wystawienie aukcji http://brasil.cel.agh.edu.pl/~09sbfraczek/diagram-aktywnosci,1,10.html

Przykłady Przeglądanie historii http://brasil.cel.agh.edu.pl/~09sbfraczek/diagram-aktywnosci,1,10.html