Projektowanie systemów multimedialnych

Transkrypt

1 Projektowanie systemów multimedialnych

2 Plan wykładu Podstawy projektowania obiektowego - Elementy UML Projektowanie dla web - WebML - Webratio Projektowanie interfejsów / GUI Multimedia w internecie

3 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 Specyfikacja -

4 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. Język komunikacji między architektami i budowniczymi

5 Elementy UML Wykorzystanie UML w cyklu życia oprogramowania (model kaskadowy) Określenie wymagań Projektowanie Implementacja UML Testowanie Konserwacja

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

7 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

8 Perspektywy Perspektywa przypadków użycia Perspektywa dynamiczna Perspektywa logiczna Perspektywa komponentów Perspektywa rozlokowania UML 2.x

9 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

10 Perspektywy Perspektywa logiczna Dokumentuje statykę systemu Ukazuje powiązania logicznych elementów składowych systemu (klasyfikatory i ich instancje)

11 Perspektywy Perspektywa dynamiczna Opisuje dynamikę systemu Ukazuje sposób realizacji oczekiwanych zachowań instancji klasyfikatorów w systemie

12 Perspektywy Perspektywa komponentów Dedykowana dla programistów Specyfikacja oprogramowania na poziomie komponentów składowych

13 Perspektywy Perspektywa rozlokowania Specyfikacja systemu od strony sprzętu niezbędnego do jego prawidłowego funkcjonowania

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

15 Diagramy UML 2.0 Diagram klas (class diagram) PL + Hurtownia - nazwa : String - adres : String + hurtownia zamówienie 1..* + klient + Zamówienie - datazlozenia : int + zamówienie podst. platnosci *.kls *.cld + Platnosc + platnosc 1..* + Naleznosc - terminplatnosci : int - suma : float 1/13 + Wplyw + zaksieguj()

16 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

17 Diagramy UML 2.0 Diagram pakietów (package diagram) Porządkowanie dokumentacji rozbudowanego systemu Stosowany we wszystkich perspektywach architektury systemu *.pkt *.pd 3/13

18 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

19 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

20 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

21 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

22 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]

23 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

24 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()

25 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/ : potwierdzrezerwacje() baza baza :

26 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

27 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

28 Kolejność budowania diagramów Przypadków użycia Klas Czynności Sekwencji Niezobowiązująca

29 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

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

31 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

32 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

33 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

34 Diagram przypadków użycia Pojedynczy przypadek użycia + Pacjent + Zapisz na wizyte Pokazuje, co system robi dla aktora a NIE jak to robi

35 Diagram przypadków użycia Przypadki użycia z określoną granicą obszaru zastosowań systemu + Doktor + Przepisz recete + Zapisz na wizyte + Pacjent Klinika

36 Diagram przypadków użycia Przypadki użycia wykorzystywane przez różnych aktorów + Doktor + Przepisz recepte + Pokaz wolne terminy + Pacjent + Zapisz na wizyte

37 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

38 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

39 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

40 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

41 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

42 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

43 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

44 Diagram przypadków użycia Liczebność na DPU + Doktor 1 0..* + Przepisz recepte

45 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

46 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

47 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

48 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

49 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

50 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?>

51 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: