Inżynieria oprogramowania -...

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.


Alternatywne określenia dla przypadku

użycia:

Funkcjonalność,

Karta wymagań,

Historia użytkownika.


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.


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


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


Relacje między przypadkami użycia

– <<include>>,

– <<extend>>,

– grupowania,

– dziedziczenia.


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


Usługa

Logowanie

Wylogowanie

<<include>>

<<include>>

Błędny diagram przypadków użycia

Użytkownik


Usługa

Logowanie

Wylogowanie

<<include>>

Poprawny diagram przypadków użycia

Użytkownik

Sesja

<<include>>

<<include>>


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


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



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.




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


Diagram

przypadków użycia

Projektowanie SIG

Perspektywa aktora

Projektant




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


Dziedziczenie

Dodawanie

osoby

Dodawanie

klienta

Dodawanie

pracownika

Relacja dziedziczenia między przypadkami użycia


Języki opisu przypadków użycia:

• W języku naturalnym (w aktualnej fazie

wykładu)

• Diagram aktywności (później)


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


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


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


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.


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.



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.



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


PU Edytuj dane klienta


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.


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.


PU Modyfikuj dane klienta c.d.


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.


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



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.


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.








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.



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


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


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


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


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.


Modyfikuj dane

zapisu studenta

na wykład

<<include>>

<<include>>


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


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



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.




16. PU wyświetla czy student spełnia wymagania zapisu na wykład.





Diagramy czynności







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


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.


Przydział zestawu naprawczego


Zwolnienie zestawu naprawczego

Reliability enhanced activity diagram (READ)

of computer system maintenance process

System komputerowy z CPU, dwoma dyskami

i dwoma zestawami naprawczymi


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


Modyfikujdane studenta

<<include>>

<<include>>


Edycja danych studenta

Użytkownik

Diagramy sekwencji

PU Edytuj dane studenta


1. Użytkownik otwiera Okno edycji 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


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


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

Inżynieria oprogramowania -...

Documents

Transcript of Inżynieria oprogramowania -...