nakreślenie perspektywy

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
Testowanie
UML
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)
+ zamówienie 1..*
PL
+ Zamówienie
- dataZlozenia : int
+ klient
+ Hurtownia
- nazwa : String
- adres : String
+ zamówienie 1..1
+ hurtownia 1..1
+ podst. platnosci
+ platnosc 1..*
*.kls *.cld
+ Naleznosc
+ Platnosc
- terminPlatnosci : int
- suma : float
1/13
+ Wplyw
+ zaksieguj()
Diagramy UML 2.0
Diagram obiektów
(object diagram)
PL
*.obk *.od
2/13
• Rodzaj diagramu klas
• Odwzorowanie
struktury systemu w
wybranym momencie
działania
• Tylko elementarne
informacje
Diagramy UML 2.0
Diagram pakietów
(package diagram)
*.pkt *.pd
3/13
• Porządkowanie
dokumentacji
rozbudowanego systemu
• Stosowany we wszystkich
perspektywach architektury
systemu
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
+ Transakcja.exe
IPrzelew
IArtykul
*.kmp *.cod
IArtykul
IKupujacy
+ aukcja
IAkceptacja
5/13
ILicytacja
ILogowanie
+ :Kwota
Diagramy UML 2.0
Diagram rozlokowania
(deployment diagram)
• Modelowanie
rozmieszczenia
infrastruktury sprzętowej
Komputer egzaminatora : klient
Komputer studenta : klient
*.rzk *.dd
TCP/IP
6/13
ethernet
Serwer obslugi egz. : serwer
HP 1500 : drukarka
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
+ student
+ Dokonaj rejestracji
*.uzc *.ud
+ Przeprowadz lekcje
+ wykladowca
+ Przeprowadz egzamin
7/13
+ 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
[login nieznany]
[else]
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
Planowany
H
Edytowany
*.stn *.sm
Zatwierdzony
Przeprowadzany
9/13
Anulowany
Zakonczony
Diagramy UML 2.0
Diagram sekwencji
(sequence diagram)
• Opisuje sekwencje
komunikatów wymienianych
między obiektami
Recepcjonista :
Rezerwacja :
BazaDanych :
otwórzRezerwacje()
*.skw *.sd
sprawdzDostepnoscPokoi()
wprowadzDane()
10/13
zamknij()
dokonajRezerwacji()
Diagramy UML 2.0
Diagram komunikacji
(communication
diagram)
• Uwidacznia strukturalną
organizację i komunikowanie
się między instancjami
recepcjonista :
*.kmn *.cd
1 : otworzRezerwacje()
2 : wprowadzDane()
3 : zamknij()
IRezerwacja :
recepcjonista
irezerwacja
irezerwacja
1.1 : sprawdzDostepnoscPokoi()
2.1 : dokonajRezerwacji()
11/13
2.1.1 : potwierdzRezerwacje()
baza :
baza
Diagramy UML 2.0
Diagram
harmonogramowania
(timing diagram)
*.hrm *.td
12/13
• Reprezentuje zmiany w czasie
dopuszczalnych stanów
instancji klasyfikatora
• Pokazywane są stany instancji
uczestniczących w interakcji
Diagramy UML 2.0
Diagram sterowania
interakcją
(interaction overview
diagram)
*.kls *.cld
13/13
• Łączy diagramy sekwencji,
komunikacji, harmonogramowania
przepływami sterowania tworząc
logiczny ciąg.
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
Przypadek zawierający
<<include>>
+ Sprawdz karte pacjenta
Przypadek zawierany
Diagram przypadków użycia
Inne rodzaje związków
Include - zawieranie
• Najczęściej stosowane gdy przypadek
zawierany jest ponownie wykorzystywany
+ Doktor
+ Przepisz recepte
<<include>>
+ Pokaz wolne terminy
+ Sprawdz karte pacjenta
<<include>>
+ Pacjent
+ Zapisz na wizyte
Diagram przypadków użycia
Inne rodzaje związków
Extend - rozszerzanie
• Związek opcjonalny
+ Przeprowadz badanie
Przypadek rozszerzany
<<extend>>
+ Wykonaj analizy
Przypadek rozszerzający
Diagram przypadków użycia
Inne rodzaje związków
Extend - rozszerzanie
• Czasem jawnie podane
miejsca rozszerzeń
+ Przeprowadz badanie
Extension Points
Badania okresowe:
Niepewna diagnoza:
<<extend>>
+ Pobierz wymaz
<<extend>>
+ Wykonaj analize krwi
<<extend>>
+ Wykonaj USG
Diagram przypadków użycia
Inne rodzaje związków
generalization - uogólnienie
• ogólne określenie szeregu
podobnych instancji
+ Zapisz wyniki badan
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
+ Pracownik obslugi rejestracji
+ Pediatra
+ 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
<<include>>
+ klient
+ Zaloguj
+ Zloz zamowienie
<<include>>
Extension Points
Zbyt maly kredyt:
+ Sprzedawca
<<extend>>
+ Obsluz zbyt maly kredyt
+ Dokonaj platnosci
+ Dokonaj platnosci przelewem
+ dokonaj platnosci karta
Diagram przypadków użycia
Przykłady
+ Technik
+ Pracownik banku
+ Kasjer
+ Wplac srodki
<<extend>>
+ Serwisuj bankomat
+ Wplac gotowke w bankomacie
+ Pracownik dzialu pozyczek
+ Podejmij srodki
<<extend>>
+ Podejmij gotowke w bankomacie
+ Zaopiniuj pozyczke
<<extend>>
+ Zloz wniosek o pozyczke
+ Klient
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:
<W postaci wyrażenia czasownikowego>
Kontekst użycia:
<Cel, normalne warunki wystąpienia>
Zakres i poziom:
<Czy przypadek użycia dotyczy całego przedsiębiorstwa, wybranego
systemu czy fragmentu oprogramowania? Na jakim poziomie
szczegółowości jest opisany?>
Aktor główny:
<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: