inżynieria oprogramowania -...
TRANSCRIPT
Inżynieria oprogramowania
Jan Magott
Wprowadzenie
Literatura do języka UML
• G. Booch, J. Rumbaugh, I. Jacobson, UML przewodnik użytkownika, Seria Inżynieria oprogramowania, WNT, 2001, 2002.
• M. Fowler, UML w kropelce, wersja 2.0, LTP, 2005.
• M. Śmiałek, Zrozumieć UML 2.0, Metody modelowania obiektowego, Helion, 2005.
• S. Wrycza, B. Marcinkowski, K. Wyrzykowski, Język UML 2.0 w modelowaniu systemów informatycznych, Helion, 2005.
Wprowadzenie
Literatura do wzorców projektowych
• E. Gamma, R. Helm, R. Johnson, J. Vlissides, Wzorce
projektowe, Elementy oprogramowania obiektowego
wielokrotnego użytku, WNT, Warszawa, 2005.
• Shalloway, J. R. Trott, Projektowanie obiektowo
zorientowane, Wzorce projektowe, wydanie II, Helion,
2005.
Wprowadzenie
Programowanie
w kodzie maszynowym (0,1)
Programowanie
w asemblerze
Programowanie
w języku wysokiego poziomu
Programowanie
w języku nieobiektowym
Programowanie
w języku obiektowym
Strukturalne projektowanie
oprogramowania
Metoda Coada/Yourdona
obiektowo zorientowanych
analizy i projektowania
oprogramowania
Metoda Boocha, 1994 OMT, 1991
OMT-2
Rumbaugh
OOSE, 1992
Jacobson
Unified Modeling Language (UML)
Booch, Rumbaugh, Jacobson
UML 1.0, 1997
Wprowadzenie
Inżynieria oprogramowania
Inżynieria systemowa
UML
SysML
Wprowadzenie
Znaczenie języka UML
• Język komunikacji z użytkownikiem– Na etapie specyfikacji wymagań stosowane są diagramy i opis w języku
naturalnym.
• Język wielu perspektyw:– Wymagań użytkownika,
– Struktury abstrakcyjnej,
– Dynamiki abstrakcyjnej,
– Architektury implementacji (komponenty programowe),
– Architektury sprzętowo-programowej – wdrożenia (rozmieszczenia komponentów programowych w węzłach fizycznych).
• Język dokumentacji projektu
• Język projektowania poprzez modelowanie
Wprowadzenie
Źródło:
A. Bobkowska, M. Gala,
Konsekwencje zastosowania modelowania w projektach
informatycznych – badanie z udziałem praktyków,
w: J. Górski, C. Orłowski, Inżynieria oprogramowania w
procesach integracji systemów informatycznych, PWNT,
Gdańsk, 2010, str. 49-56
Wprowadzenie
Korzyści z zastosowania metod modelowania w inżynierii oprogramowania:
• Pomoc w radzeniu sobie ze złożonością systemu, dzięki mechanizmowi abstrakcji, umożliwiającemu prezentację tylko tych elementów, które są istotne z danego punktu widzenia
• Możliwość przewidywania własności i skutków działania oprogramowania na podstawie modeli, dzięki czemu modele stosowane są do analizy, weryfikacji, walidacji, oceny i porównania różnych wersji systemu
• Wspomaganie komunikacji w zespole i z klientem dzięki wspólnym modelom koncepcyjnym
• Standardowa notacja i zwiększenie precyzji dokumentacji systemu
• Możliwość automatycznego przekształcania modeli, np. generacji dokumentacji, generacji kodu, sprawdzaniu poprawności syntaktycznej, spójności i innych własności modeli.
Wprowadzenie
Czynniki powodujące rezygnację z
modelowania w praktyce:
• Ograniczenia czasowe nałożone na termin
wykonania
• Opracowywanie modeli nie powoduje
bezpośredniego przyrostu kodu programu
Wprowadzenie
Badanie
ankietoweKontekst:
stanowisko respondenta, specyfika firmy
Czy modelowanie
jest stosowane
przez respondenta?
Oczekiwane korzyści i motywacje
stosowania modelowania
(pytania otwarte) Przyczyny i konsekwencje
braku modelowania
Korzyści i problemy wynikające
z zastosowania modelowania
Korzyści i problemy wynikające
ze stosowania narzędzi UML
T F
Wprowadzenie
Badanie ankietowe
Adres systemu ankietowania www.webankieta.pl
• Ankieta miała charakter anonimowy.
• Prośba o wypełnienie wysłana pod 285 adresów email należących do 170 przedsiębiorstw informatycznych działających na terenie Polski.
• Wzięło udział 66 respondentów (współczynnik odpowiedzi 23%) w tym 38 wypełniło kwestionariusz w pełni, a 28 – częściowo.
Wprowadzenie
Poziom stosowania modelowania rośnie wraz ze:
• wzrostem złożoności systemu,
• wzrostem liczebności zespołu projektowego,
• wzrostem sformalizowania metodyki wytwarzania oprogramowania.
Poziom stosowania modelowania:
• Metodyka RUP (Rational Unified Process) opracowana przez twórców języka UML– 92% respondentów
• Podejście tradycyjne – 65%
• Podejście zwinne – 51%
Wprowadzenie
Wg ankiety
• Wśród języków modelowania najczęściej stosowany jest UML lub jego podzbiór (87%)
• W pozostałych przypadkach (13%) zadeklarowano stosowanie innych metod (BPMN, SysML, DSM)
Wprowadzenie
Przykłady szeroko stosowanych w praktyce języków modelowania przepływu prac i procesów biznesowych:
BPEL – Business Process Execution Language,
BPMN - Business Process Modeling Notation,
Diagramy czynności (aktywności) języka UML.
Według porównania 14 komercyjnych produktów modelowania przepływu prac i procesów biznesowych, BPMN i diagramy czynności języka UML są jednymi z trzech najlepszych pod względem mocy wyrażania przepływu sterowania.
Źródło: N. Russel, A.H.M. ter Hofstede, W.M.P. van der Aalst, N. Mulyar, Workflow control-flow patterns, A revised view.
Wprowadzenie
DSM - Domain Specific Modelling
DSL - Domain Specific Language
Wprowadzenie
Obszary zastosowania modelowania:
• Modelowanie systemu (86%)
• Prezentacja wymagań (83%)
• Modelowanie procesów biznesowych (66%)
• Modelowanie architektury (40%)
Najczęściej modelowanie stosowane jest przez analityków
Wprowadzenie
Oczekiwane korzyści i motywacje stosowania modelowania (66 respondentów, 38 wypełniło kwestionariusz w pełni):
1. Jednoznaczny i spójny opis systemu (10 respondentów)
2. Komunikacja w ramach zespołu (9)
3. Modelowania statyczne systemu (8)
4. Modelowanie biznesowe systemu (5)
5. Modelowanie zachowania systemu (zamiast opisu słownego) (5)
6. Gromadzenie wiedzy (repozytorium modeli systemu) (5)
7. Zarządzanie wymaganiami / zmianą (5)
8. Redukcja złożoności problemu/systemu (5)
9. Ułatwienie przepływu wiedzy (5)
10. Standaryzacja dokumentacji/formalizacja opisu systemu (5)
11. Komunikacja z klientem (5)
12. Redukcja liczby błędów (szczególnie we wstępnych fazach) (3)
13. Poprawa pielęgnowalności (3)
14. Generacja kodu źródłowego (2)
15. Szybsze wprowadzenie nowych osób do projektu (2)
16. Wymaganie ze strony klienta (model jako produkt) (1)
Wprowadzenie
Korzyści wynikające z zastosowania modelowania
Wprowadzenie
Problemy wynikające z zastosowania modelowania
Nie stwierdzono:
• Występowania problemów ze zrozumieniem wykorzystywanej
notacji przez zespół wytwórczy
• Niejasnej formy prezentacji modelu
• Braku spójności modeli
• Nieodpowiedniego poziomu szczegółowości modeli
Występowanie problemów ze zrozumieniem notacji przez klienta –
45% ankietowanych odpowiedziało „trudno powiedzieć”
Korzyści wynikające ze stosowania narzędzi UML
Wprowadzenie
Przyczyny braku modelowania
20 z 66 respondentów stwierdziło, że nie stosuje modelowania. 14 respondentów (70%) w pełni odpowiedziało na pytania tej ścieżki.
Przedstawiciele tej grupy realizują krótkoterminowe, niskobudżetowe projekty, w których uczestniczy mały zespół projektowy.
Najczęściej metody modelowania nie są stosowane ze względu na:
• ograniczenia projektowe (krótkie terminy, brak dostępności zasobów)
• brak zdefiniowanego procesu wytwórczego z zastosowaniem metod modelowania.
W grupie 14 respondentów, 10 z nich (71%) zadeklarowało, że stosuje metodyki zwinne.
Wprowadzenie
Konsekwencje braku modelowania
Fakt, że 71% respondentów zaprzeczyło istnieniu problemów z komunikacją w grupie, można wytłumaczyć stosowaniem innych sposobów komunikacji w zespole.
Koniec powołań na źródło:
A. Bobkowska, M. Gala, Konsekwencje zastosowania modelowania w projektach informatycznych – badanie z udziałem praktyków, …
Wprowadzenie
Przyczyny tworzenia narzędzi
programistycznych wspierających rysowanie i
analizę diagramów języka UML:
• Tylko dla prostych diagramów, rysowanie i
analiza nie są uciążliwe,
• Złożoność analizy zgodności między diagramami,
• Możliwości algorytmizacji analizy diagramów.
Wprowadzenie
Wymagania stawiane nowoczesnym narzędziom CASE (Computer Aided Software Engineering):
• Rysowanie diagramów ze sprawdzaniem ich poprawności,
• Pełnienie roli repozytorium,
• Umożliwienie nawigacji po komponentach systemu przy pracy z różnymi kategoriami modeli,
• Umożliwienie jednoczesnej pracy wielu użytkownikom na tym samym modelu,
• Generowanie kodu,
• Inżynieria odwrotna,
• Integrowanie z innymi narzędziami, np. w celu edycji i kompilacji kodu uzupełniającego szkielet kodu, testowania,
• Praca ze wszystkimi poziomami abstrakcji systemu, od wysokiego poziomu do poziomu kodu,
• Wymiana fragmentów modelu z innymi narzędziami.
Wprowadzenie
Repozytorium: struktura, dynamika
Diagramy
przypadków
użycia
Diagramy
klas
Diagramy
sekwencji
Diagramy
komunikacji
Diagramy
maszyn stanów
Diagramy
czynności
Diagramy
komponentów
Diagramy
wdrożenia
Diagramy
opisu
interakcji
Diagramy
składowych
Diagramy
czasowe
Diagramy
obiektów
Diagramy
pakietów
Wprowadzenie
Zadania, dla których narzędzie CASE wykorzystuje repozytorium:
• Sprawdzanie zgodności diagramu i zgodności między diagramami,
• Wskazywanie uchybień modeli,
• Sporządzanie dokumentów z projektu,
• Stosowanie elementów projektu w innym projekcie.
Diagramy przypadków użycia
Specyfikacja wymagań za pomocą diagramów przypadków użycia
• Modelowanie obiektowe można stosować nie tylko do systemów programowych ale również do systemów sprzętowych czy organizacji. Stąd diagramy przypadków użycia mogą być stosowane do specyfikowania wymagań nałożonych na systemy powyższych kategorii.
• Podczas przyrostowej realizacji projektu ważnymi decyzjami są rozstrzygnięcia, które przypadki użycia powinny być dostarczone na początku i w jakiej kolejności dołączane będą następne przypadki.
• Na początku specyfikowania wymagań, często korzystne jest opracowanie katalogu pojęć z dziedziny zastosowania (wycinka rzeczywistości), które będą stosowane w wyrażaniu przypadków użycia.
Diagramy przypadków użycia
Alternatywne określenia dla przypadku
użycia:
Funkcjonalność,
Karta wymagań,
Historia użytkownika.
Diagramy przypadków użycia
Aktor oddziaływuje z modelowanym
(projektowanym) systemem. Aktor może
być człowiekiem lub innym systemem.
Aktor reprezentuje rolę. Indywidualny
użytkownik nie jest aktorem. Konkretny
użytkownik może pełnić różne role: może
być np. Klientem jak również
Pracownikiem.
Diagramy przypadków użycia
Relacja uogólniania między aktorami
Klient
Klient ubezpieczający
podmiot fizyczny
Klient ubezpieczający
podmiot prawny
Relacja uogólniania między klasami klientów
agencji ubezpieczeniowej
Diagramy przypadków użycia
Asocjacja komunikacji między aktorem a przypadkiem użycia
• Aktor i Przypadek użycia są klasami. Często Aktor wysyła komunikaty do Przypadku użycia i komunikaty otrzymuje.
• Przypadek użycia reprezentuje kompletną funkcjonalność widzianą ze strony aktora lub innego przypadku użycia. Jest to zbiór sekwencji akcji wykonywanych przez system, w których wyniku otrzymywany jest mierzalny produkt działania systemu.
Przypadek
użycia
Aktor
Diagramy przypadków użycia
Relacje między przypadkami użycia
– <<include>>,
– <<extend>>,
– grupowania,
– dziedziczenia.
Diagramy przypadków użycia
Relacja <<include>>
Zakres stosowania:
• Reprezentacja hierarchii funkcji systemu,
• Wyodrębnianie części wspólnej dla co najmniej dwu funkcji
systemu.
Przypadek1
Przypadek3
Przypadek2
<<include>
><<include>
>
Przypadek3 jest częścią wspólną
wydzieloną z dwu funkcji
Diagramy przypadków użycia
Usługa
Logowanie
Wylogowanie
<<include>>
<<include>>
Błędny diagram przypadków użycia
Użytkownik
Diagramy przypadków użycia
Usługa
Logowanie
Wylogowanie
<<include>>
Poprawny diagram przypadków użycia
Użytkownik
Sesja
<<include>>
<<include>>
Diagramy przypadków użycia
Relacja <<extend>>
Zakres stosowania:
• Wyrażanie wyjątków, alternatywnych przebiegów,
• Wyrażanie funcji tworzonych na dalszych etapach budowy systemu.
Sprzedaż
towaru
Wystawienie
pełnego
rachunku
Wystawienie
gwarancji
<<extend>>
<<extend>>
Diagramy przypadków użycia
Grupowanie przypadków użycia
• Przypadki użycia związane ze sobą mogą być grupowane w pakiet,
który może być dostępny jako jednostka.
Zarządzanie
Zarządzanie
finansami
Zarządzanie
kadrami
Diagramy przypadków użycia
(Diagramy hierarchii funkcji, diagramy hierarchii
procesów biznesowych ich poprzednikami)System informacji geograficznej (SIG)
• Mapa komputerowa zawiera obiekty takie jak:– Punkty (np. budynek),
– Linie (np. rzeka),
– Obszary (np. park).
• Obiekt ma nazwę i opis składający się ze słów kluczowych np.:– rodzaj firmy,
– miejsce jej ulokowania,
– liczba pracowników.
• Użytkownik może oglądać obiekty opisane wybranymi przez niego słowami kluczowymi.
Zarządzanie SIG
Przeglądanie SIG Projektowanie SIG
Prezentacjafragmentów
mapy
Prezentacjaobiektów wybranych
słowami kluczowymi
Prezentacjaopisu
obiektu
Edycja tła(zdjęcia satelitarnego
lub mapy)
Modyfikacja
obiektów
Modyfikacja
słów
kluczowych
Dodawanieobiektu
Usuwanieobiektu
Edycjaobiektu
u
Dodawaniesłowa
kluczowego
Usuwaniesłowa
kluczowego
Edycjasłowa
kluczowego
Diagramy przypadków użycia
(Diagramy hierarchii funkcji, diagramy hierarchii
procesów biznesowych ich poprzednikami)
Diagramy przypadków użycia reprezentują wymagania funkcjonalne.
W diagramach przypadków użycia wyodrębnione są klasy obiektów zewnętrznych wchodzących w identyczne interakcje z systemem.
Klasy obiektów zewnętrznych względem projektowanego systemu nazywane są aktorami i opatrywane nazwami ról np. Projektant, Użytkownik.
Diagramy przypadków użycia
(Diagramy hierarchii funkcji, diagramy hierarchii
procesów biznesowych ich poprzednikami)
Diagram
przypadków
użycia
Przeglądanie SIG
Perspektywa
aktora
Użytkownik
Prezentacja
fragmentów
mapy
Prezentacja
obiektów wybranych
słowami kluczowymi
Prezentacja
opisu
obiektu
Użytkownik
Diagramy przypadków użycia
Diagram
przypadków użycia
Projektowanie SIG
Perspektywa aktora
Projektant
Diagramy przypadków użycia
(Diagramy hierarchii funkcji, diagramy hierarchii
procesów biznesowych ich poprzednikami)
Diagram
przypadków
użycia
Projektowanie SIG
Perspektywa aktora
Projektant
Edycja tła
Modyfikacja obiektów
Modyfikacja słów kluczowych
Dodawanie
obiektu
Usuwanie
obiektu
Edycja
obiektu
u
Dodawanie
słowa
kluczowego
Usuwanie
słowa
kluczowego
Edycja
słowa
kluczowego
Projektant
Diagramy przypadków użycia
Dziedziczenie
Dodawanie
osoby
Dodawanie
klienta
Dodawanie
pracownika
Relacja dziedziczenia między przypadkami użycia
Diagramy przypadków użycia
Języki opisu przypadków użycia:
• W języku naturalnym (w aktualnej fazie
wykładu)
• Diagram aktywności (później)
Diagramy przypadków użycia
Opis przypadku użycia w języku naturalnym
1. Cel
2. Warunki wstępne
3. Przebieg podstawowy
4. Przebiegi alternatywne
5. Przepływ komunikatów (często pomijany)
6. Warunki końcowe
Diagramy przypadków użycia
Plan
1. Diagram przypadków użycia dla Zarządzania klientami
z następującymi przypadkami użycia najwyższego
poziomu:
• Dodaj nowego klienta
• Usuń klienta
• Przeglądaj dane klienta
• Edytuj dane klienta
2. Diagram przypadków Zapisu studenta na wykład
Diagramy przypadków użycia
Diagram przypadków użycia dla zarządzania klientami
Dodaj
nowego klienta
Edytuj
dane klienta
Przeglądaj
dane klienta
Usuń klienta
Szukaj
klienta
Pracownik
Modyfikuj
dane klienta
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
<include>>
Diagramy przypadków użycia
PU (przypadek użycia) Dodaj nowego klienta
Cel PU
Celem tego PU jest dodanie do bazy danych nowego klienta banku.
Warunki wstępne
PU jest inicjowany przez Pracownika.
Diagramy przypadków użycia
PU Dodaj nowego klienta c.d.
Przebiegi sposobu realizacji PU
Podstawowy 1. Pracownik wydaje polecenie dodania nowego klienta do bazy danych,
naciskając przycisk Dodaj klienta w oknie Zarządzaj klientami.
2. Wyświetlane jest okno Klient zawierające pola edycyjne opisujące poszczególne dane klienta.
3. Pracownik edytuje dane klienta, wypełniając poszczególne pola edycyjne okna.
4. Pracownik naciska przycisk Zapisz.
5. Inicjowany jest PU Modyfikuj dane klienta.
6. Następuje powrót z PU Modyfikuj dane klienta.
7. Wyświetlenie Komunikatu wynikowego.
8. Zamykane jest okno Klient i PU zostaje zakończony.
Diagramy przypadków użycia
PU Dodaj nowego klienta c.d.
Przepływ komunikatów
1. Nowy klient - Pracownik inicjuje PU, naciskając przycisk Dodaj klienta w oknie Zarządzaj klientami.
2. Dane klienta - Pracownik podaje dane klienta, wypełniając pola edycyjne okna Klient.
3. Zapisz - Pracownik inicjuje zapis danych do bazy danych, naciskając przycisk Zapisz.
4. Modyfikuj dane klienta - PU inicjuje PU Modyfikuj dane klienta.
5. Komunikat powrotu do PU z PU Modyfikuj dane klienta.
6. Komunikat wynikowy.
7. Zamknij - Pracownik zamyka okno Klient.
Diagramy przypadków użycia
PU Dodaj nowego klienta c.d.
Warunki końcowe
PU uznaje się za zakończony po zamknięciu okna Klient.
(lub
PU uznaje się za zakończony po zapisaniu danych nowego klienta.)
Diagramy przypadków użycia
PU Edytuj dane klienta
Przebiegi sposobu realizacji PU
Podstawowy
1. Pracownik wydaje polecenie edytowania danych klienta, naciskając przycisk Edytuj dane klienta w oknie Zarządzaj klientami.
2. Wyświetlane jest okno Klient zawierające pole PESEL.
3. Pracownik wpisuje PESEL i naciska przycisk Szukaj.
4. Inicjowany jest PU Szukaj klienta.
5. Następuje powrót z PU Szukaj klienta.
6. Wyświetlane jest okno Klient zawierające pola edycyjne opisujące poszczególne dane klienta.
7. Pracownik edytuje dane klienta, wypełniając poszczególne pola edycyjne okna.
8. Pracownik naciska przycisk Zapisz.
9. Inicjowany jest PU Modyfikuj dane klienta.
10. Następuje powrót z PU Modyfikuj dane klienta.
11. Wyświetlenie Komunikatu wynikowego.
12. Zamykane jest okno Klient i PU zostaje zakończony.
Diagramy przypadków użycia
PU Modyfikuj dane klienta
Cel PU
Celem tego PU jest zmodyfikowanie danych klienta.
Warunki wstępne
PU inicjowany jest przez PU Dodaj nowego klienta lub przez PU Edytuj dane klienta. W momencie wywołania do PU przekazywane są aktualne dane o kliencie. Jeśli PU inicjującym jest PU Edytuj dane klienta, to przekazywany jest wskaźnik na dane klienta.
Diagramy przypadków użycia
PU Modyfikuj dane klienta c.d.
Przebiegi sposobu realizacji PU
1. PU inicjowany jest przez PU Dodaj nowego klienta lub przez PU Edytuj dane klienta.
2. Jeśli inicjującym jest PU Edytuj dane klienta, to przejście do kroku 6.
3. Inicjowany jest PU Szukaj klienta
4. Następuje powrót z PU Szukaj klienta
5. Jeśli istnieje w bazie klient o podanym numerze PESEL, to wyświetlany jest komunikat: Klient o podanym PESEL istnieje i przejście do kroku 7.
6. PU modyfikuje dane klienta.
7. PU kończy się i następuje powrót do PU, który wywołał PU Modyfikuj dane klienta.
Diagramy przypadków użycia
PU Modyfikuj dane klienta c.d.
Warunki końcowe
PU uznaje się za zakończony po modyfikacji danych
klienta (co może wystąpić dla obu inicjujących
przypadków użycia) lub po stwierdzeniu, że
klient o podanym numerze PESEL już w bazie
istnieje (co może nastąpić tylko dla inicjacji
przez PU Dodaj nowego klienta).
Okno główne
Wykład
Okno zapisu studenta na wykład
Wydział
Dane wykładu
ID wykładu
Okno wykładu
Dodaj wykład
Zapisz na wykład
Usuń wykład
Edytuj dane wykładu
ID studenta
Zapisz Tak Nie
Czy spełnione wym.
Szukaj danych studenta
Modyfikuj dane
zapisu studenta
na wykład
<<include>>
<<include>>
Diagram przypadków użycia
Zapis studenta na wykład
Zapisz studenta
na wykład
Użytkownik
Szukaj danych wykładu
<<include>>
Szukaj danych
wydziału
<<include>>
Diagramy przypadków użycia
Diagramy przypadków użycia
PU Zapisz studenta na wykład
Przebieg podstawowy realizacji PU
1. Użytkownik otwiera Okno zapisu studenta na wykład.
2. Użytkownik wybiera Nazwę wydziału.
3. Inicjowany jest PU Szukaj danych wydziału.
4. Następuje powrót z PU Szukaj danych wydziału.
5. Użytkownik podaje ID wykładu lub wybiera przejście do 2.
6. Inicjowany jest PU Szukaj danych wykładu.
7. Następuje powrót z PU Szukaj danych wykładu.
8. Jeśli nie znaleziono wykładu, to PU wyświetla napis Nie znaleziono wykładu.
9. Jeśli PU wyświetla napis Nie znaleziono wykładu, to Użytkownik wybiera przejście do: 2 lub 5.
10.Jeśli znaleziono wykład, to PU wyświetla dane o wykładzie m.in. czy są wolne miejsca.
Diagramy przypadków użycia
PU Zapisz studenta na wykład c.d.
Przebieg podstawowy realizacji PU c.d.
10. Jeśli znaleziono wykład, to PU wyświetla dane o wykładzie m.in. czy są wolne miejsca.
11. Jeśli nie ma wolnych miejsc, to PU wyświetla napis Nie ma wolnych miejsc
12. Jeśli PU wyświetla napis Nie ma wolnych miejsc, to Użytkownik wybiera przejście do: 2 lub 5.
13. Użytkownik podaje ID studenta.
14. Inicjowany jest PU Szukaj danych studenta.
15. Następuje powrót z PU Szukaj danych studenta.
16. PU wyświetla czy student spełnia wymagania zapisu na wykład.
17. Jeśli student nie spełnia wymagań, to PU wyświetla napis Nie spełnia wymagań.
18. Jeśli PU wyświetla napis Nie spełnia wymagań, to Użytkownik wybiera przejście do: 2 lub 5.
19. Jeśli Użytkownik wybiera Nie w polu Zapisz, to PU przechodzi do 24.
20. Użytkownik wybiera Tak w polu Zapisz.
Diagramy przypadków użycia
PU Zapisz studenta na wykład c.d.
Przebieg podstawowy realizacji PU c.d.
17. Jeśli student nie spełnia wymagań, to PU wyświetla napis Nie spełnia wymagań.
18. Jeśli PU wyświetla napis Nie spełnia wymagań, to Użytkownik wybiera przejście do: 2 lub 5.
19. Jeśli Użytkownik wybiera Nie w polu Zapisz, to PU przechodzi do 24.
20. Użytkownik wybiera Tak w polu Zapisz.
21. Inicjowany jest PU Modyfikuj dane zapisu studenta na wykład.
22. Następuje powrót z PU Modyfikuj dane zapisu studenta na wykład.
23. Użytkownik zamyka Okno wykładu lub wybiera przejście do: 2 lub 5.
24. PU zostaje zakończony z zamkniętym Oknem wykładu.
Diagramy przypadków użycia
PU Zapisz studenta na wykład c.d.
Alternatywne przebiegi
• W dowolnym momencie Użytkownik może zamknąć
Okno wykładu.
• Jeśli po wykonaniu jednego z punktów: 1,4, 7, 15,
22, Użytkownik nie wykona żadnej akcji w ciągu 30 s,
to PU przechodzi do 24.
Diagramy czynności (aktywności)
• W początkowych wersjach języka UML
Diagramy czynności były oparte, podobnie jak maszyny stanowe, na mapach stanów Harel’a
• W wersji UML 2.0 i dalszych
Diagramy czynności są oparte na sieciach Petriego
Diagramy czynności
Wzajemne wykluczanie dwu cyklicznych procesów sekwencyjnych
Fazy aktywności procesu:
• CS – sekcja krytyczna,
• RP – pozostała część procesu,
• P(s), V(s) – operacje semaforowe.
P(s)
CS
V(s)
RP
Diagramy czynności
Wzajemne wykluczanie dwu cyklicznych procesów sekwencyjnych
Fazy aktywności procesu:
• CS – sekcja krytyczna,
• RP – pozostała część procesu,
• P(s), V(s) – operacje semaforowe.
Cykliczny proces sekwencyjny reprezentowany siecią Petriego
(kółko – miejscem, kreska – przejściem, znacznik - kropką)
CRP – zakończenie pozostałej części procesu
RP
RP
P(s)
CS
V(s)
CRP
P(s)
CS
V(s)
Diagramy czynności
Wzajemne wykluczanie dwu cyklicznych procesów sekwencyjnych
Sekwencja odpalanych przejść: P(s) V(s) CRP
RP
CRP
P(s)
CS
V(s)
RP
CRP
P(s)
CS
V(s)
P(s)
RP
CRP
P(s)
CS
V(s)
V(s)
CRP
Diagramy czynności
Wzajemne wykluczanie dwu cyklicznych procesów sekwencyjnych
CS – proces jest w sekcji krytycznej,
RP – proces jest w pozostałej części procesu,
CRP – zakończenie pozostałej części procesu,
P(s), V(s) – operacje semaforowe,
IR – krytyczny zasób jest dostępny.
Przejścia z etykietami P(s)
są przygotowane do odpalenia
P(s) P(s)
V(s) V(s)
P1 P2
IRCS1 CS2
RP1 RP2
CRP1 CRP2
a)
Diagramy czynności
Wzajemne wykluczanie dwu cyklicznych procesów sekwencyjnych
Przejście V(s) procesu P1 jest przygotowane do odpalenia
Sieć Petriego po odpaleniu przejścia P(s) procesu P1
P(s) P(s)
V(s) V(s)
P1 P2
IRCS1 CS2
RP1 RP2
CRP1 CRP2
b)
Diagramy czynności
Prosty protokół komunikacyjny
PM – produkcja komunikatu, CPM – zakończenie produkcji komunikatu,
SM – wysłanie komunikatu, WA – oczekiwanie na potwierdzenie,
TM – transmisja komunikatu, RM – odbiór komunikatu,
SA – wysłanie potwierdzenia, CM – konsumpcja komunikatu,
CCM – zakończenie konsumpcji komunikatu, TA – transmisja potwierdzenia,
RA – odbiór potwierdzenia.
SM
RAPM CM
TM
TA
CPM CCM
RM
SA
WA
Diagramy czynności
p3
t1t1
p1 p2
t2
t3t4
22
2
2
t1
p1 p2
t2
t3t4
22
2
2
p3
p4
p4
Diagramy czynności
t3t1
p1 p2
t2
t3t4
22
2
2
p3
p3
t1
p1 p2
t2
t3t4
22
2
2
p4
p4
Diagramy czynności
Graf osiągalności
1011 – znakowanie początkowe
1011
2001
0021 0120
1110
2100
t1
t1
t1
t4
t4
t4
t3t2
t2
t1
Okno główne
Wykład
Okno zapisu studenta na wykład
Wydział
Dane wykładu
ID wykładu
Okno wykładu
Dodaj wykład
Zapisz na wykład
Usuń wykład
Edytuj dane wykładu
ID studenta
Zapisz Tak Nie
Czy spełnione wym.
Szukaj danych studenta
Modyfikuj dane
zapisu studenta
na wykład
<<include>>
<<include>>
Diagram przypadków użycia
Zapis studenta na wykład
Zapisz studenta
na wykład
Użytkownik
Szukaj danych wykładu
<<include>>
Szukaj danych
wydziału
<<include>>
Diagramy czynności
Diagramy czynności
PU Zapisz studenta na wykład
Przebieg podstawowy realizacji PU
1. Użytkownik otwiera Okno zapisu studenta na wykład.
2. Użytkownik wybiera Nazwę wydziału.
3. Inicjowany jest PU Szukaj danych wydziału.
4. Następuje powrót z PU Szukaj danych wydziału.
5. Użytkownik podaje ID wykładu lub wybiera przejście do 2.
6. Inicjowany jest PU Szukaj danych wykładu.
7. Następuje powrót z PU Szukaj danych wykładu.
8. Jeśli nie znaleziono wykładu, to PU wyświetla napis Nie znaleziono wykładu.
9. Jeśli PU wyświetla napis Nie znaleziono wykładu, to Użytkownik wybiera przejście do: 2 lub 5.
10.Jeśli znaleziono wykład, to PU wyświetla dane o wykładzie m.in. czy są wolne miejsca.
Diagramy czynności
PU Zapisz studenta na wykład c.d.
Przebieg podstawowy realizacji PU c.d.
10. Jeśli znaleziono wykład, to PU wyświetla dane o wykładzie m.in. czy są wolne miejsca.
11. Jeśli nie ma wolnych miejsc, to PU wyświetla napis Nie ma wolnych miejsc
12. Jeśli PU wyświetla napis Nie ma wolnych miejsc, to Użytkownik wybiera przejście do: 2 lub 5.
13. Użytkownik podaje ID studenta.
14. Inicjowany jest PU Szukaj danych studenta.
15. Następuje powrót z PU Szukaj danych studenta.
16. PU wyświetla czy student spełnia wymagania zapisu na wykład.
17. Jeśli student nie spełnia wymagań, to PU wyświetla napis Nie spełnia wymagań.
18. Jeśli PU wyświetla napis Nie spełnia wymagań, to Użytkownik wybiera przejście do: 2 lub 5.
19. Jeśli Użytkownik wybiera Nie w polu Zapisz, to PU przechodzi do 24.
20. Użytkownik wybiera Tak w polu Zapisz.
Diagramy czynności
PU Zapisz studenta na wykład c.d.
Przebieg podstawowy realizacji PU c.d.
17. Jeśli student nie spełnia wymagań, to PU wyświetla napis Nie spełnia wymagań.
18. Jeśli PU wyświetla napis Nie spełnia wymagań, to Użytkownik wybiera przejście do: 2 lub 5.
19. Jeśli Użytkownik wybiera Nie w polu Zapisz, to PU przechodzi do 24.
20. Użytkownik wybiera Tak w polu Zapisz.
21. Inicjowany jest PU Modyfikuj dane zapisu studenta na wykład.
22. Następuje powrót z PU Modyfikuj dane zapisu studenta na wykład.
23. Użytkownik zamyka Okno wykładu lub wybiera przejście do: 2 lub 5.
24. PU zostaje zakończony z zamkniętym Oknem wykładu.
Diagramy czynności
PU Zapisz studenta na wykład c.d.
Alternatywne przebiegi
• W dowolnym momencie Użytkownik może zamknąć
Okno wykładu.
• Jeśli po wykonaniu jednego z punktów: 1, 4, 7, 15,
22, Użytkownik nie wykona żadnej akcji w ciągu 30 s,
to PU przechodzi do 24.
Wybiera
Okno zapisu
studenta na wykładWyświetla
Okno zapisu
studenta na wykład
Wybiera
Nazwę wydziału
2
Po 30s
1
Wykonuje
PU Szukaj danych wydziału
2
Po 30s
1
[kontynuacja][powrót]
Podaje
ID wykładuWykonuje
PU Szukaj danych wykładu
Wybiera
Przycisk zamykania
Okno wykładuZamyka
Okno wykładu
2
1
Użytkownik System
Reliability enhanced activity diagrams (READ)
(M. Kowalski, J. Magott)
Podstawy języka READ:
1. Diagramy czynności języka UML
2. Konstrukcje fork i join diagramów czynności rozszerzone w kierunku przejść sieci Petriego
3. Probabilistyczne drzewa niezdatności z zależnościami czasowymi [1]
[1] Babczyński, T., Łukowicz, M., Magott, J. (2010). Time coordination of distance protections using probabilistic fault trees with time dependencies. IEEE Transaction on Power Delivery, July, Vol. 25, No. 3, 1402-1409.
Reliability enhanced activity diagrams (READ)
Przydział zestawu naprawczego
Reliability enhanced activity diagrams (READ)
Zwolnienie zestawu naprawczego
Reliability enhanced activity diagram (READ)
of computer system maintenance process
System komputerowy z CPU, dwoma dyskami
i dwoma zestawami naprawczymi
Reliability enhanced activity diagrams (READ)
of computer system maintenance process
Regularna praca | Naprawa | Stan procesu
Diagramy klas
Następujący diagram klas pochodzi z:
G. Booch, J. Rumbaugh, I. Jacobson, UML przewodnik
użytkownika, Seria Inżynieria oprogramowania, WNT,
2001, 2002.
Diagramy klas
Relacje między klasami na diagramach klas
Rodzaje relacji:
• Asocjacja (ang. Association),
• Agregacja (ang. Aggregation) jest szczególnym przypadkiem asocjacji.
• Uogólnienie (ang. Generalization),
• Zależność (ang. Dependency),
• Uszczegółowienie (ang. Refinement).
Diagramy klas
Asocjacje
Obiekt jest instancją klasy.
Powiązanie jest instancją asocjacji.
Sposoby obrazowania asocjacji:
• krawędzią,
• łukiem.
Zwykle asocjacja obrazowana jest krawędzią. Krawędź stosowana jest gdy:
• możliwe jest przejście w obie strony między klasami połączonymi nią lub gdy
• nie dysponuje się pełną informacją o kierunkach przejść.
Łuk może być stosowany w przypadku, gdy na poziomie implementacji
klasa Klasa1 ma wskaźnik do klasy Klasa2 ale nie w drugą stronę.
Klasa1 Klasa2
Diagramy klas
Krotność asocjacji określa z iloma obiektami klasy drugiej może być połączony obiekt pierwszej klasy.
Przykłady krotności:
• 1
• 0..1 0 lub 1
• 11
• 5..11
• * 0
Diagram klas o znaczeniu:
• Drużyna piłki nożnej składa się z jedenastu zawodników
Drużyna
piłkinożnej
Zawodnik1 11
Asocjacja rekursywna
Diagram klas o znaczeniu:
Graf składa się z wierzchołków połączonych krawędziami
Diagram obiektów reprezentujący konkretny graf
Diagramy klas
Wierzchołek1 : Wierzchołek
Wierzchołek4 : Wierzchołek
Wierzchołek2 : Wierzchołek
Wierzchołek3 : Wierzchołek
Wierzchołek5 : Wierzchołek
Wierzchołek
*
*
krawędź
• Role w asocjacji
Diagramy klas
Wierzchołek
źródło
cel
łuk
Asocjacja kwalifikowana
Kwalifikator określa jak specyficzny obiekt na końcu asocjacji o krotności "wiele" jest identyfikowany.
Diagramy klas
Lista osóbOsoba
Identyfikator*
Klasa asocjacji
Klasa Stanowisko opisuje asocjację.
Z każdym powiązaniem między obiektami klas: Osoba, Firma jest skojarzony obiekt klasy Stanowisko, który charakteryzuje powiązanie.
Diagramy klas
Stanowisko
Wymagane kwalifikacje
Wynagrodzenie
Szlifowanie
OsobaFirma
Asocjacja binarna a asocjacja trzyarna
• Asocjacja binarna
• Asocjacja trzyarna modelująca przygotowywanie projektów w firmie programistycznej
Diagramy klas
Drużyna
piłki
nożnej
Zawodnik1 11
Osoba
ProjektJęzyk
*
1..*
1..3
Asocjacja trzyarna modelująca przygotowywanie projektów w firmie programistycznej
• Osoba znająca dany język programowania może nie realizować projektu w tym języku ale może też realizować więcej niż jeden projekt w tym języku.
• Osoba pracująca w projekcie może używać jednego, dwu lub trzech języków.
• Jeśli projekt jest realizowany, to jest wykonywany w co najmniej jednym języku ale żaden z wykonawców nie może pracować w więcej niż trzech językach w ramach jednego projektu.
Diagramy klas
Osoba
ProjektJęzyk
*
1..*
1..3
Diagramy klas
Asocjacja uporządkowana
• W firmie pracuje co najmniej jedna osoba.
• Osoba może nie pracować w żadnej firmie.
• Osoby zaangażowane w firmie mogą być uporządkowane np. alfabetycznie. Sposób uporządkowania można podać pisząc np. :
{ordered alphabetically}
1..*
{ordered}Osoba Firma
*
Diagramy klas
Agregacja
Agregacja jest szczególnym przypadkiem asocjacji.
Obiekt klasy Dokument składa się z co najmniej jednego
obiektu klasy Paragraf
zawiera
jest częścią
Dokument
Paragraf
1..*
całość część
Diagramy klas
Agregacja dzielona
• Części mogą być częściami różnych klas, co
jest wyrażone krotnością * po stronie całości.
• Student może studiować na więcej niż jednym
wydziale.
Wydział Student
**
Diagramy klas
Uogólnienie
Klasa ogólna (nadklasa) a klasy specjalizowane (podklasy)
• Klasy specjalizowane dziedziczą po klasie ogólnej.
• Powyższa lista podklas nie daje w sumie mnogościowej -nadklasy.
• W rozważanym wycinku rzeczywistości uzasadnione może być rozważanie tylko tych powyższych trzech klas.
Pojazd
Samochód
osobowy
Samochód
ciężarowy Łódź
Pojazd
Samochód
osobowy
Samochód
ciężarowy Łódź
Diagramy klas
Klasa Pojazd jest
abstrakcyjna, natomiast
klasy Samochód i Łódź
są klasami konkretnymi
Napęd jest
dyskryminatorem, który
odróżnia podklasy
między sobą.
Pojazd
drive()
Samochód
drive()
Łódź
drive()
Napęd Napęd
drive() uruchamia koła
drive() uruchamia śrubę
Diagramy klas
• Ograniczenia dla definiowania
uogólnienia
Diagramy klas
Syntaktyka deklaracji atrybutu
[widoczność] nazwa [liczebność] [: typ] [= wartość_początkowa] [{łańcuch_własności}]
Uwaga: Obowiązkowa jest tylko nazwa.
widoczność:
• + atrybut publiczny (atrybut jest dostępny z innych klas),
• - atrybut prywatny (atrybut nie jest dostępny z innych klas),
• # atrybut chroniony, dostępny w klasach dziedziczących (ang. protected),
• widoczność atrybutu jest interpretowana jako atrybut publiczny.
Przykład
Faktura
+ data : Data = Bieżąca data
+ nazwaProduktu : String+ ilość : integer
+ cenaJednostkowa : Cena
+ klient : String
osobaWystawiająca : String
Diagramy klas
widoczność cd
pokreślony opis atrybutu - atrybut o zakresie klasy (atrybut prywatny, którego wartość
jest identyczna dla każdego obiektu klasy)
Przykład
Atrybut licznik jest używany przez wszystkie procesy do zliczania liczby wykonań
operacji zwiększStanLicznika .
Proces
licznik : integer
zwiększStanLicznika
Diagramy klas
Uwaga
Można definiować inne kategorie widoczności, jeśli
jest to uzasadnione możliwościami języka, w
którym system będzie implementowany.
{łańcuch_własności} w szczególnym przypadku
może być listą wartości typu wyliczeniowego czyli
{lista_wartości}
Diagramy klas
Implementacja klasy w języku Java
public Class Faktura
{
public Data data = newData();
public String nazwaProduktu;
public int ilość;
public Cena cenaJednostkowa;
public String klient;
private String osobaWystawiająca;
static private int liczbaFaktur = 0;
// Operacja konstruktora wywoływana przy tworzeniu obiektu
public Faktura()
{
//Nadawanie wartości początkowych atrybutom
//Inicjowanie powiązań z innymi obiektami
//Odnotowanie utworzenia faktury
liczbaFaktur ++;
}
//inne operacje
• };
Faktura
+ data : Data = Bieżąca data
+ nazwaProduktu : String+ ilość : integer
+ cenaJednostkowa : Cena
+ klient : String
osobaWystawiająca : String
liczbaFaktur : integer = 0
Diagramy klas
Syntaktyka nagłówka operacji
[widoczność] nazwa [(lista_parametrów)] [: typ_wyniku] [{łańcuch_własności}]
{ łańcuch_własności} może być wyliczeniem typu wyniku
Syntaktyka parametru formalnego
[tryb] nazwa : typ [= wartość domyślna]
tryb:
in parametr wejściowy; nie może być modyfikowany,
out parametr wyjściowy; może być modyfikowany w celu przekazania
informacji wywołującemu,
inout parametr wejściowy; może być modyfikowany.
Operacje o zakresie klasy mają dostęp tylko do atrybutów o zakresie klasy.
Implementacja operacji (kod w języku programowania) jest metodą.
Diagram
klas
Diagramy sekwencji
Następujący diagram sekwencji pochodzi z:
M. Śmiałek, Zrozumieć UML 2.0, Metody modelowania
obiektowego, Helion, 2005.
Diagramy sekwencji
Edytuj dane studenta
Szukaj danych studenta
Modyfikujdane studenta
<<include>>
<<include>>
Diagram przypadków użycia
Edycja danych studenta
Użytkownik
Diagramy sekwencji
PU Edytuj dane studenta
Przebieg podstawowy realizacji PU
1. Użytkownik otwiera Okno edycji danych studenta.
2. Użytkownik podaje ID studenta.
3. Inicjowany jest PU Szukaj danych studenta.
4. Następuje powrót z PU Szukaj danych studenta.
5. Użytkownik podaje Dane korygujące.
6. Inicjowany jest PU Modyfikuj dane studenta.
7. Następuje powrót z PU Modyfikuj dane studenta.
8. Użytkownik zamyka Okno studenta i PU zostaje zakończony.
Diagramy sekwencji
PU Szukaj danych studenta
Przebieg podstawowy realizacji PU w przypadku zainicjowania przez PU Edytuj dane studenta
1. PU jest inicjowany przez PU Edytuj dane studenta.
2. Na podstawie ID studenta szukane są jego dane.
3. Następuje powrót ze wskaźnikiem na studenta o podanym ID studenta i PU zostaje zakończony.
Diagramy sekwencji
PU Modyfikuj dane studenta
Przebieg podstawowy realizacji PU w przypadku
zainicjowania przez PU Edytuj dane studenta
1. PU jest inicjowany przez PU Edytuj dane
studenta.
2. Dane studenta są modyfikowane.
3. Następuje powrót i PU zostaje zakończony.
Okno główne
WydziałWykład
Student Wykładowcaał
Okno studenta
Dodaj studenta
Edytuj dane
stu denta
Usuń studenta
System okien
Okno wykładowcy
Okno wydziałuOkno wykładu
System okien dla Edycji danych studenta
Okno główne
Wydział Wykład
Student Wykładowca
ał
Okno studenta
Dodaj studenta
Edytuj dane studenta
Usuń studenta
Okno edycji danych studenta
Nazwisko
PESEL
Imię
Miejsce urodzenia
Grupa współdziałania dla realizacji
Edycja danych studenta
Uczelnia
odczytajDaneStudentadodajStudenta
usuńStudenta
edytujDaneStudenta
Student
nazwisko:Nazwa
IDstudenta:Numberget()
set()
wywołuje1
1
Okno studenta
pokażOkno
odczytajDaneStudenta
dodajStudentausuńStudenta
edytujDaneStudenta
Okno główne
pokażOkno
:Okno główne :Okno studenta :Student:Uczelnia
Diagram sekwencji dla
Edycja danych studenta
StudentpokażOkno
Edytuj dane studentaedytujDaneStudenta
edytujDane
Studenta
IDstudenta
Dane korygujące
zamknij
get(nazwisko)
get(imię)
set(nazwisko)
set(imię)
Diagramy maszyn stanowych
Następujący diagram maszyny stanowej pochodzi z:
M. Śmiałek, Zrozumieć UML 2.0, Metody modelowania
obiektowego, Helion, 2005.
Diagram
maszyny
stanowej