Projektowanie systemów multimedialnych
Plan wykładu Podstawy projektowania obiektowego - Elementy UML Projektowanie dla web - WebML - Webratio Projektowanie interfejsów / GUI Multimedia w internecie
Elementy UML Ujednolicony Język Modelowania. Twórcami UMLa są Grady Booch, James Rumbaugh i Ivar Jacobson ("trzej amigos") Język rozwijany początkowo przez firmę Rational, obecnie opiekuje się nim Object Management Group (OMG) Zrzeszenie firm, w tym: IBM, Apple Computer, Sun Microsystems Obecna wersja 2.1.2 Specyfikacja - http://www.omg.org/spec/uml/2.1.2/
Elementy UML Zadaniem UML jest wyposażyć ludzi zajmujących się tworzeniem i rozwojem oprogramowania w narzędzia analizy, projektowania i implementacji systemów opartych na oprogramowaniu jak również narzędzia modelowania procesów biznesowych i podobnych. www.uml.org Język komunikacji między architektami i budowniczymi
Elementy UML Wykorzystanie UML w cyklu życia oprogramowania (model kaskadowy) Określenie wymagań Projektowanie Implementacja UML Testowanie Konserwacja
Elementy UML UML jest językiem obejmującym szeroki zakres zastosowań. Nie wszystkie jego elementy składowe są potrzebne przy opisywaniu konkretnej domeny tworzenia systemów lub konkretnej aplikacji. Modułowa budowa języka UML pozwala na wybór tylko tych jego części, które są właściwe do opisu danego problemu.
Elementy UML Podział na moduły jest dopasowany do konieczności uwzględnienia różnych punktów widzenia na system Np. użytkownika projektanta programisty Perspektywy patrzenia
Perspektywy Perspektywa przypadków użycia Perspektywa dynamiczna Perspektywa logiczna Perspektywa komponentów Perspektywa rozlokowania UML 2.x
Perspektywy Perspektywa przypadków użycia Definiuje zakres i oczekiwaną funkcjonalność projektowanego systemu Kluczowa wobec pozostałych Operuje pojęciami zrozumiałymi dla wszystkich udziałowców przedsięwzięcia
Perspektywy Perspektywa logiczna Dokumentuje statykę systemu Ukazuje powiązania logicznych elementów składowych systemu (klasyfikatory i ich instancje)
Perspektywy Perspektywa dynamiczna Opisuje dynamikę systemu Ukazuje sposób realizacji oczekiwanych zachowań instancji klasyfikatorów w systemie
Perspektywy Perspektywa komponentów Dedykowana dla programistów Specyfikacja oprogramowania na poziomie komponentów składowych
Perspektywy Perspektywa rozlokowania Specyfikacja systemu od strony sprzętu niezbędnego do jego prawidłowego funkcjonowania
Diagramy UML 2.0 W rzeczywistości język UML składa się z zestawu diagramów wykorzystywanych w poszczególnych perspektywach Każdy diagram posiada pewną ilość typów elementów składowych. Typy te mogą być dostosowywane do potrzeb konkretnego zastosowania - opisywanego konkretnego problemu Dla typowych zastosowań tworzone są zestawy elementów składowych wykorzystywanych na diagramach.
Diagramy UML 2.0 Diagram klas (class diagram) PL + Hurtownia - nazwa : String - adres : String + hurtownia 1..1 + zamówienie 1..* + klient + Zamówienie - datazlozenia : int + zamówienie 1..1 + podst. platnosci *.kls *.cld + Platnosc + platnosc 1..* + Naleznosc - terminplatnosci : int - suma : float 1/13 + Wplyw + zaksieguj()
Diagramy UML 2.0 PL Diagram obiektów (object diagram) *.obk *.od Rodzaj diagramu klas Odwzorowanie struktury systemu w wybranym momencie działania Tylko elementarne informacje 2/13
Diagramy UML 2.0 Diagram pakietów (package diagram) Porządkowanie dokumentacji rozbudowanego systemu Stosowany we wszystkich perspektywach architektury systemu *.pkt *.pd 3/13
Diagramy UML 2.0 Diagram struktur połączonych (composite structure diagram) *.spl *.csd 4/13 Ilustruje współdziałanie różnych elementów systemu (części współdziałania) przy realizacji konkretnego zadania
Diagramy UML 2.0 Diagram komponentów (component diagram) Modelowanie elementów oprogramowania i związków między nimi + oferta IArtykul + Transakcja.exe IPrzelew *.kmp *.cod 5/13 ILicytacja IArtykul + aukcja ILogowanie IKupujacy IAkceptacja + :Kwota
Diagramy UML 2.0 Diagram rozlokowania (deployment diagram) Modelowanie rozmieszczenia infrastruktury sprzętowej Komputer egzaminatora : klient Komputer studenta : klient *.rzk *.dd TCP/IP ethernet 6/13 HP 1500 : drukarka Serwer obslugi egz. : serwer USB
Diagramy UML 2.0 Diagram przypadków użycia (use case diagram) Określają funkcjonalność systemu i sposób komunikowania się użytkowników Definiowanie wymagań od systemu *.uzc *.ud + student + Dokonaj rejestracji + Przeprowadz lekcje 7/13 + Przeprowadz egzamin + wykladowca + Przegladaj wyniki + Przygotuj zadanie
Diagramy UML 2.0 Diagram czynności (activity diagram) Graficzne przedstawienie przepływów sterowania i danych między uporządkowanymi ciągami czynności Wprowadz login *.czn *.ad [else] [login nieznany] wprowadz haslo 8/13 [trzecia pomylka] [bledne haslo] [else]
Diagramy UML 2.0 Diagram maszyny stanowej (state machine diagram) Pokazuje sekwencję stanów przez które przechodzi obiekt w odpowiedzi na zdarzenia H Planowany *.stn *.sm Edytowany 9/13 Zatwierdzony Anulowany Przeprowadzany Zakonczony
Diagramy UML 2.0 Diagram sekwencji (sequence diagram) Opisuje sekwencje komunikatów wymienianych między obiektami Recepcjonista : Rezerwacja : BazaDanych : *.skw *.sd otwórzrezerwacje() sprawdzdostepnoscpokoi() 10/13 wprowadzdane() dokonajrezerwacji() zamknij()
Diagramy UML 2.0 Diagram komunikacji (communication diagram) Uwidacznia strukturalną organizację i komunikowanie się między instancjami *.kmn *.cd recepcjonista : 1 : otworzrezerwacje() 2 : wprowadzdane() 3 : zamknij() recepcjonista irezerwacja IRezerwacja : irezerwacja 1.1 : sprawdzdostepnoscpokoi() 2.1 : dokonajrezerwacji() 11/13 2.1.1 : potwierdzrezerwacje() baza baza :
Diagramy UML 2.0 Diagram harmonogramowania (timing diagram) Reprezentuje zmiany w czasie dopuszczalnych stanów instancji klasyfikatora Pokazywane są stany instancji uczestniczących w interakcji *.hrm *.td 12/13
Diagramy UML 2.0 Diagram sterowania interakcją (interaction overview diagram) Łączy diagramy sekwencji, komunikacji, harmonogramowania przepływami sterowania tworząc logiczny ciąg. *.kls *.cld 13/13
Kolejność budowania diagramów Przypadków użycia Klas Czynności Sekwencji Niezobowiązująca
Diagram przypadków użycia Umożliwia jednoznaczną dokumentację wymagań użytkowników wobec projektowanego systemu Określa funkcjonalność tworzonego systemu oraz sposób komunikowania się użytkowników z systemem Przedstawia interakcję aktorów z przypadkami użycia systemu
Diagram przypadków użycia Umożliwia analizę obszaru zastosowań systemu Umożliwia opracowanie projektu systemu Dość zrozumiały dla typowego śmiertelnika. Ułatwia komunikację między grupami zajmującymi się systemem (inwestorzy projektanci - programiści)
Diagram przypadków użycia Aktor + student Określa rolę jaką pełni wobec systemu konkretny użytkownik, typ użytkownika Np. Student Wykładowca System obsługi stypendiów
Diagram przypadków użycia Przypadek użycia + przegladaj oceny Określa poszczególne usługi świadczone przez system na rzecz aktorów Np. Udostępnianie cennika Przyjmowanie zamówień Drukowanie faktur
Diagram przypadków użycia Związek Semantyczne powiązanie między elementami diagramu Najczęściej asocjacja Asocjacja opisuje powiązania między instancjami. Standardowo wskazuje na komunikację dwukierunkową, nie oznacza konkretnego przepływu
Diagram przypadków użycia Pojedynczy przypadek użycia + Pacjent + Zapisz na wizyte Pokazuje, co system robi dla aktora a NIE jak to robi
Diagram przypadków użycia Przypadki użycia z określoną granicą obszaru zastosowań systemu + Doktor + Przepisz recete + Zapisz na wizyte + Pacjent Klinika
Diagram przypadków użycia Przypadki użycia wykorzystywane przez różnych aktorów + Doktor + Przepisz recepte + Pokaz wolne terminy + Pacjent + Zapisz na wizyte
Diagram przypadków użycia Inne rodzaje związków Include - zawieranie Związek obligatoryjny Zawierany PU nie jest wykonywany samodzielnie + Zapisz na wizyte <<include>> + Sprawdz karte pacjenta Przypadek zawierający Przypadek zawierany
Diagram przypadków użycia Inne rodzaje związków Include - zawieranie + Doktor Najczęściej stosowane gdy przypadek zawierany jest ponownie wykorzystywany + Przepisz recepte <<include>> + Pokaz wolne terminy + Sprawdz karte pacjenta + Pacjent <<include>> + Zapisz na wizyte
Diagram przypadków użycia Inne rodzaje związków Extend - rozszerzanie Związek opcjonalny <<extend>> + Przeprowadz badanie + Wykonaj analizy Przypadek rozszerzany Przypadek rozszerzający
Diagram przypadków użycia Inne rodzaje związków Extend - rozszerzanie + Przeprowadz badanie Extension Points Badania okresowe: Niepewna diagnoza: Czasem jawnie podane miejsca rozszerzeń <<extend>> + Wykonaj analize krwi <<extend>> <<extend>> + Pobierz wymaz + Wykonaj USG
Diagram przypadków użycia Inne rodzaje związków generalization - uogólnienie + Zapisz wyniki badan ogólne określenie szeregu podobnych instancji Przypadek ogólny + Zapisz wynik morfologii pacjenta + Zapisz USG pacjenta Przypadek szczegółowy
Diagram przypadków użycia Inne rodzaje związków generalization - uogólnienie + Pracownik Kliniki dotyczy również aktorów Przypadek ogólny + Lekarz + Pracownik obslugi rejestracji + Laborant Przypadek szczegółowy
Diagram przypadków użycia Inne rodzaje związków generalization - uogólnienie + Pracownik Kliniki możliwa struktura drzewiasta + Lekarz + Pediatra + Pracownik obslugi rejestracji + Laborant + Gastrolog + Laryngolog
Diagram przypadków użycia Liczebność na DPU + Doktor 1 0..* + Przepisz recepte
Diagram przypadków użycia Przykłady + sprawdz stan zamowienia + klient <<include>> + Zloz zamowienie <<include>> + Zaloguj Extension Points Zbyt maly kredyt: + Sprzedawca <<extend>> + Dokonaj platnosci + Obsluz zbyt maly kredyt + Dokonaj platnosci przelewem + dokonaj platnosci karta
Diagram przypadków użycia Przykłady + Technik + Pracownik banku + Kasjer + Serwisuj bankomat + Wplac srodki <<extend>> + Wplac gotowke w bankomacie + Pracownik dzialu pozyczek + Podejmij srodki <<extend>> + Podejmij gotowke w bankomacie + Klient + Zaopiniuj pozyczke <<extend>> + Zloz wniosek o pozyczke
Diagram przypadków użycia Tworzenie DPU Proces iteracyjny Wyszczególnić można etapy identyfikacja aktorów identyfikacja przypadków użycia opracowanie związków (asocjacje) ewentualne rozszerzenie o związki dodatkowe (zawieranie, uogólnienie) udokumentowanie przypadków użycia
Diagram przypadków użycia Scenariusze przypadku użycia Sposób dokumentacji przypadku użycia Precyzyjny opis pełnej funkcjonalności reprezentowanej przez dany przypadek użycia Jeden PU ma scenariusz główny i ewentualnie scenariusze alternatywne
Diagram przypadków użycia Scenariusze przypadku użycia Sposób dokumentacji przypadku użycia Precyzyjny opis pełnej funkcjonalności reprezentowanej przez dany przypadek użycia Jeden PU ma scenariusz główny i ewentualnie scenariusze alternatywne
Diagram przypadków użycia Scenariusze przypadku użycia Przykład sformalizowanego zapisu scenariusza PU Nazwa: Kontekst użycia: Zakres i poziom: Aktor główny: <W postaci wyrażenia czasownikowego> <Cel, normalne warunki wystąpienia> <Czy przypadek użycia dotyczy całego przedsiębiorstwa, wybranego systemu czy fragmentu oprogramowania? Na jakim poziomie szczegółowości jest opisany?> <Nazwa głównego aktora, opis jego roli> Pozostali aktorzy i udziałowcy: <Nazwy aktorów, ich interesy> Wyzwalacze / Inicjacja: <Zdarzenie powodujące rozpoczęcie przypadku użycia> Warunki początkowe: <Co system zapewnia przed zezwoleniem na rozpoczęcie przypadku użycia?>
Diagram przypadków użycia Scenariusze przypadku użycia Przykład sformalizowanego zapisu scenariusza PU (cd.) Warunki końcowe: - Gwarancje powodzenia: <Warunki spełnione po pomyślnym wykonaniu głównego scenariusza przypadku użycia> - Minimalne gwarancje: <Minimalne wymagania prawdziwe na końcu każdego przebiegu przypadku użycia (również niepoprawnego)> Główny scenariusz powodzenia / Przepływ podstawowy: <Numer kroku> <Opis akcji> <Numer kroku> <Opis akcji> Przepływy alternatywne: <Numer zmienionego kroku> <Opis akcji> Punkty rozszerzenia: <Miejsca i warunki występowania rozszerzeń> Specjalne wymagania (np. niefunkcjonalne): Dodatkowe informacje: