Zastosowanie UML w projektowaniu - WordPress.com · 2019. 11. 25. · symboli stosuje się zapis za...

2019-11-23 09:13 D:\POKAZ-PPT1\PROJEKTOWANIE.ppt 1

Zastosowanie UML

w projektowaniu

systemów – cd.

dr inż. prof. WSZiA Władysław Wornalkiewicz


1. …. Podstawy UML 2.0 Artykuł w

Internecie

2. Jarosław Wąs, Laboratorium nr 1.

Podstawy UML, diagram klas,

artykuł w Internecie

3. Program freeware’owy z Internetu: StarUML

C”/Documents and Settings/Admin/Moje

dokumenty/Downloads/StarUML-v2.00-beta1

D:/UML/… C:/ProgramFiles/StarUML


Wstęp

Jest to wstęp do UML 2.0 – metodologii1

stosowanej na co dzień w fazie projektowej podczas

produkcji oprogramowania. Tekst porusza te

zagadnienia związane z UMLem, które są

szczególnie istotne i przydatne w fazie tworzenia

dokumentu technicznego gier komputerowych.

Stąd wiele jest w tekście uproszczeń, nagięć języka,

tak aby jak najlepiej służył celom programistów

gier. Ponadto z bogatej kolekcji 13 diagramów

zdefiniowanych w standardzie UML 2.0 [1] tekst

porusza tylko te, które znajdują szersze

zastosowanie w projektowaniu poszczególnych

części gry bądź jej rdzenia.


Chciałbym także zaznaczyć, że często będę używał

terminu obiekt jako polskiego odpowiednika słowa

‘item’. W naszym rodzimym języku jest to najlepiej

pasujący termin, który niestety koliduje z innym

określeniem związanym z programowaniem. Jeśli

nie będzie to oczywiste, postaram się to

zastosowanie podkreślić.

Ponadto trochę z przyzwyczajenia w znacznej

części przykładów stosuję angielskie nazwy dla klas

(a także ich składowych, obiektów, aktorów itd.).

Są to jednak słowa na tyle elementarne, że ich

znalezienie w słowniku nie będzie stanowić

problemu dla osób, które ich nie znają.


Czym jest UML?

UML (Unified Modeling Language) jest to sposób formalnego opisu

modeli reprezentujących projekty informatyczne (zazwyczaj te o

charakterze programistycznym, choć i od tej reguły zdarzają się

wyjątki).

Wysoki poziom abstrakcji gwarantuje całkowitą niezależność od

platformy i języka. Obecnie obowiązujący standard (2.1), będący

twórczym rozwinięciem UML 1.x (a także stosunkowo młodego 2.0)

definiuje 13 różnych diagramów (podzielonych na dwie kategorie:

strukturalne i opisujące zachowania) o różnym przeznaczeniu.

Każdy z nich opisuje dany system pod innym kątem, z innej

perspektywy, a

nawet na różnym poziomie abstrakcji.

Dla nas z praktycznego punktu widzenia znaczenie będą miały

jedynie następujące spośród nich wszystkich:


Diagram klas

(zwany też czasem po prostu diagramem strukturalnym)

Diagram obiektów

Diagram przypadków użycia

Diagram aktywności

Diagram Automatu Stanów

Diagram sekwencyjny


Największą zaletą UMLa i w ogóle koncepcji projektowania, jest

olbrzymia oszczędność czasu w późniejszej fazie produkcji oraz

zmniejszenie ryzyka konieczności przepisywania kodu źródłowego

na nowo.

Choć to zdanie wielu osobom z pewnością wyda się być truizmem,

rzesze programistów dzień w dzień zdają się o nim zapominać.

Trzeba więc o tym przy każdej okazji przypominać.

Przewagą UMLa nad innymi formalnymi językami opisu projektów

informatycznych jest to, że stworzony model jest niezwykle

przyjazny dla programisty – nie dość, że model zwykle ukazuje

pewien program w prosty i czytelny sposób, to na dodatek nie jest

wymagana duża dodatkowa wiedza, żeby diagramy modelu

zrozumieć czy nawet rozszerzyć (w przypadku metodologii takich

jak np. PRINCE2 czy COBIT tak łatwo już nie jest).


Oczywiście nie dotyczy to wszystkich modeli. UML choć z

pozoru prosty, może się bowiem znacznie skomplikować,

gdy zaczniemy się zagłębiać w jego szczegóły.

Jednak z punktu widzenia programisty (a nie typowego

architekta czy projektanta) taka wiedza nie zawsze jest

potrzebna.

W dalszej części znajduje się dokładniejszy opis każdego z

wymienionych diagramów wraz ze stosownymi

przykładami.

Zamieszczony tu opis to wielki skrót, który jednak

powinien całkowicie wystarczyć dla naszych celów.


Diagramy języka UML W miarę rozwoju języka UML rosła liczba diagramów składowych.

Wraz z wersją UML 2.2 wprowadzono czternasty diagram profili.

Najpopularniejsze diagramy języka UML stosowane w narzędziach

typu CASE dzielimy na cztery rodzaje diagramów, a w ramach nich

występują diagramy składowe.

Diagram struktury obejmujący diagramy składowe:

klas,

obiektów,

pakietów,

struktur połączonych,

profili.

Diagram wdrożeniowy nawiązujący do diagramu struktury, a w

ramach niego diagramy składowe:

rozlokowania,

Komponentów.


Diagram dynamiki obejmujący diagramy składowe:

przypadków użycia,

czynności,

maszyny stanowej.

Diagram interakcji, a w ramach niego diagramy składowe:

sekwencji,

komunikacji,

harmonogramowania,

sterowania interakcją.

W opisie stosowane mogą być formy pełne i skrócone wyróżników

rodzaju diagramu.

2019-11-23 09:13 D:\POKAZ-

PPT1\PROJEKTOWANIE.ppt

11


Rodzaje diagramów języka UML 1/3

2019-11-23 09:13 D:\POKAZ-


14



Generowanie kodu źródłowego diagramu

Posłużono się systemem informacji hotelowej dla

pokazania sposobu przejścia z diagramu klas do sekwencji

kodu źródłowego programu w języku Java. W tym celu

zarówno atrybuty jak również metody nie posiadają

polskich znaków ani spacji. Zastosowano narzędzie

programistyczne Enterprise Architect 8.

Kroki postępowania są następujące:

1. Zaznaczamy klasę GoscHotelowy w ramach diagramu

klas.

2. Po wyborze opcji generowania kodu źródłowego

następuje automatyczne utworzenie – listingu o nazwie

GoscHotelowy z zestawem atrybutów zgodnym z klasą

w diagramie.

2019-11-23 09:13 D:\POKAZ-


16


IMPLEMENTACJA KLASY GoscHotelowy

2019-11-23 09:13 D:\POKAZ-


18


Opis implementacji GoscHotelowy

Wymienione w listingu metody nie posiadają

implementacji w zakresie dodawania lub usuwania gościa

hotelowego. Możemy to wykonać poprzez:

- utworzenie diagramu czynności o strukturze

algorytmów,

- pozostawienie programiście wyboru sposobu

implementacji metod.

Na listingu występuje odwołanie do klasy Meldunek oraz

Rezerwacja.

Przykładowo dodawanie gości hotelowych odbywa się

poprzez pobranie danych z formatki tekstowej i zapisanie

w bazie danych MySQL. Sposób zaimplementowania

metody dodajGoscia w języku Java pokazano na kolejnym

listingu.


Implementacja metody dodajGoscia() 1. Public void dodajGoscia(){

2. FormatkaGoscia fg=new FormatkaGoscia();

3. fg.setVisible(true):

4. this.imie=fg.imie.getText();

5. this.nazwisko=fg.nazwisko.get.Text();

6. …(fragment kodu pominięty)…

7. this.numerPaszportu=fg.numerPaszportu.getText();

8. Class.forName(„com.mysgl.jdbc.Driver”).newInstance();

9. try {

10. Connection polaczenie =

DriverManager.getConnection(„jdbc:mysql://serwermysql/nazwaBazy”,

„uzytkownik”, „haslo”);

11. Statement skladnia = polaczenie.createStatement();

12. skladnia.addBatch(„INSERT INTO GoscHotelowy (VALUES)

(\” ”+imie+”\,\” „+nazwisko+

13. … (fragment pominięty) …

14. +”\”,\” „ +numerPaszportu+\”)”);

15. skladnia.executeBatch();

16. Polaczenie.close();


Implementacja metody dodajGoscia() c.d.

17. }

18. Catch(IOException e) {

19. JOptionPane.ShowMesageDialog(null),”Wystąpił błąd podczas dostępu do

bazy danych”, „System rezerwacji hotelowych”,

IOptionPane.ERROR_MESSAGE):

20. }

21. Catch(Exception e) {

22. JOptionPane.showMessageDialog(null,”Wystąpił nieznany błąd:

„+e.getMessage(),”System rezerwacji

hotelowych”,IOPtionPane.ERROR_MESSAGE);

23. }

24. }

W liniach 6 oraz 13 pominięto fragmenty kodu, których celem jest zebranie z pól

tekstowych na formatce ekranowej pozostałych informacji.


Opisy Diagramów

Diagram klas (diagram strukturalny)

Diagram ten będący podstawowym i chyba najczęściej

wykorzystywanym diagramem strukturalnym, ukazuje wzajemne

powiązania między klasami tworzącymi dany system. Nie ukazuje on

jednak żadnych relacji pomiędzy samymi obiektami (za to

odpowiada diagram obiektów).

Zatrzymajmy się na chwilę w tym miejscu i powiedzmy sobie kilka

słów o podstawowej notacji obowiązującej dla tego diagramu. Klasy

w zapisie UML 2.0 reprezentowane są przez prostokąty podzielone w

poziomie na 3 części. W górnej z nich, po środku znajduje się nazwa

klasy, w środkowej z wyrównaniem do lewej – składowe zmienne

klasy, a w dolnej - również z wyrównaniem do lewej strony –

składowe funkcje klasy. Poniżej znajduje się przykładowa klasa,

zapisana zgodnie z notacją UML 2.0:


Omówimy teraz pokrótce szczegóły dotyczące powyższego zapisu.

Składowe zmienne i funkcje zapisywane są w następujący sposób:

zmienne: [zasięg]8 nazwa [: typ] [= wartość początkowa]

funkcje: [zasięg] nazwa([typ argumentu]) [: typ zwracany]

Gdzie:

zasięg określany jest w jeden z następujących sposobów:

o + - publiczny

o # - chroniony

o - - prywatny

Należy w tym miejscu wspomnieć, że czasem zamiast powyższych

symboli stosuje się zapis za pomocą odpowiednich ikon. Jednak, taki

zapis można spotkać jedynie w oprogramowaniu wspomagającym

projektowanie w UMLu, gdyż rysowanie skomplikowanych

kształtów na papierze (od czego zwykle wszystko się zaczyna) jest

raczej niepraktyczne (nie mówiąc o tym, że takie rysunki mogą być

mniej czytelne od znaków ASCII).


typ, typ argumentu oraz typ zwracany – nazwa typu (może to być

albo typ prosty, albo nazwa innej klasy istniejącej w ramach

danego systemu).

UML 2.0 definiuje następujące typy proste:

o Integer – liczby całkowite (odpowiednik z C++: int)

o Float – liczby zmiennoprzecinkowe (odpowiednik z C++: float,

double)

o String – łańcuchy znaków (odpowiednik z C++: char*)

o Void – typ nieokreślony (odpowiednik z C++: void)

wartość początkowa – wartość ustawiana dla zmiennej w fazie jej

inicjowania.


Kilka dodatkowych przykładów:

#age: Integer – prywatna zmienna typu całkowitego

+text: String = „Hello world” – publiczna zmienna typy String

(ciąg znakowy)

+squareRoot(Float): Float – publiczna funkcja przyjmująca

argument typu Float i zwracająca liczbę tego samego typu.

W diagramach klas zwykło się nie umieszczać następujących

elementów:

Konstruktory i destruktory

Akcesory (funkcje postaci set...() i get...())

Elementy bibliotek pochodzących spoza projektu, w tym

elementy pochodzące z biblioteki standardowej danego języka

(w przypadku STL – dotyczy to np. kontenerów, iteratorów,

itd.)

Wskaźniki


Relacje

Pojedyncze klasy nie mają praktycznie żadnej wartości. Dopiero

współpraca kilku lub większej liczby klas ma rzeczywiste znaczenie.

Współpraca klas jest definiowana poprzez tzw. relacje,

reprezentowane przez linie (krawędzie) z odpowiednim

zakończeniem, które dalej będę nazywał grotami (choć nie jest to

nazwa formalna ani poprawna, pozwoli na utożsamienie relacji ze

strzałkami).

Grot wskazuje zawsze tę klasę, która jest w danej relacji ważniejsza.

Można powiedzieć, że klasa 2. świadczy na rzecz klasy B pewne

usługi.

Poniżej znajdują się 2 klasy będące w relacji:


W tym konkretnym przypadku powiemy, że klasa SettingsWindow

(na którą grot wskazuje) jest rodzicem klasy

SettingsWindowWin329.

Powiązanie

Dwie klasy są powiązane jeśli są w relacji, do której określenia

pozostałe typy relacji UMLa są niewystarczające.

Relację tę można sprecyzować za pomocą krótkiego opisu słownego,

umieszczanego powyżej linii reprezentującej relację.

Opis ten ogranicza się zwykle do kilku wyrazów, z których

conajmniej jeden zwykle nazywa czynność. Ważne jest też to, że przy

tego typu relacji linia może być pozbawiona „grotu”. Wówczas jest

to relacja dwustronna.


1

Powyższa relacja oznacza, że obiekty klasy Player grają

dla klasy Team. Innymi słowy klasa Player świadczy usługę

grania na rzecz klasy Team.

W tym konkretnym przypadku relacja mogłaby być

pozbawiona grotu, jeśli po drugiej stronie widniałby napis

np. „is being paid by”.

Relacja byłaby wtedy dwukierunkowa. Zwróćmy jeszcze

uwagę na liczby poniżej linii definiującej relację.


Generalizacja

Generalizacja reprezentuje dziedziczenie z OOP (Object

Oriented Programming – programowanie zorientowane

obiektowo).

Jeśli klasa B jest w relacji generalizacji z klasą A - klasą

podrzędną, to klasa B ma wszystkie składowe klasy A oraz

potencjalnie swoje unikalne.

Klasa A jest klasą rodzicielską, a klasa B potomną.

Przykładem – być klasy: Animal i Bird.

Bird będzie oczywiście w relacji generalizacji klasą

podrzędną, gdyż zawiera wszystkie cechy zwykłego

zwierzęcia (np. zdolność poruszania się, brak umiejętności

przeprowadzania procesu

fotosyntezy) i dodatkowo definiuje własne, unikalne

zachowania i cechy (np. skrzydła, latanie).


Jeśli strzałka jest rysowana linią przerywaną a nie

ciągłą, zamiast o generalizacji, możemy powiedzieć

o realizacji, co jednak z punktu widzenia

implementacji, często nie ma aż tak istotnego

znaczenia.

2019-11-23 09:13 D:\POKAZ-


35

Zawieranie

Jeśli mówimy, że klasa A jest zawarta w klasie

B, to znaczy, że klasa A jest jednym z

elementów klasy B, np. klasa Zeszyt może być

zawarta w klasie Plecak.

Niemniej zawieranie mówi o tym, że zarówno

klasa A jak i klasa B mogą istnieć jako

oddzielne elementy. W naszym przypadku

jest to prawda, zarówno Zeszyt jak i Plecak

są elementami nie uzależnionymi od siebie.

2019-11-23 09:13 D:\POKAZ-


36

2019-11-23 09:13 D:\POKAZ-


37

Kompozycja

Jest szczególnym (skrajnym) przypadkiem

zawierania. Różnica polega na tym, że klasa B,

która jest zawarta w A, nie może posiadać

samodzielnych instancji.

Innymi słowy zawsze jest składową obiektów klasy

B, np. drzwi samochodowe nie mogą istnieć jako

samodzielne obiekty. Zawsze są skomponowane z

obiektami klasy Samochód. Różnica w notacji w

stosunku do zawierania polega na tym, że romb na

zakończeniu krawędzi reprezentującej relację jest

wypełniony.

2019-11-23 09:13 D:\POKAZ-


38

Zależność

Ten rodzaj relacji jest zwykle stosowany w

początkowej fazie projektowania systemu, ze

względu na fakt, że jest to relacja bardzo ogólna,

stosowana do opisania wielu rodzajów powiązań.

Innymi słowy, jeśli wiadomo, że dwie klasy są w

relacji, ale początkowo nie jesteśmy w stanie

określić w jakiej dokładnie, wówczas należy

skorzystać z relacji zależności, a w późniejszej fazie

projektowania zastąpić ją relacją bardziej

precyzyjną.

Relację tę reprezentuje zwykła linia pozbawiona

jakichkolwiek zakończeń.

2019-11-23 09:13 D:\POKAZ-


39

Realizacja

Klasa B realizuje klasę A, wtedy gdy

implementuje jej wszystkie metody.

Zazwyczaj klasa A jest interfejsem.

W tym przypadku relacja jest dodatkowo

opisana przez stereotyp (dość podobnym

znaczeniowo stereotypem jest

<<implements>>).

2019-11-23 09:13 D:\POKAZ-


40


1

Opis relacji

Okazuje się, że rysowanie samych tylko strzałek z różnymi

grotami, jest często niewystarczające, po prostu zbyt mało

precyzyjne.

Aby lepiej opisać relację, można (i często należy) stosować

jedną z poniższych technik:

określić stereotyp relacji – stereotyp relacji jest to jak

gdyby zachowanie się relacji, swoiste doprecyzowanie

zdefiniowane w UMLu; stereotypy dotyczą też innych

obiektów UMLa – np. klas.

umieścić krótki opis słowny powyżej linii

reprezentującej relację, np. wspomniane już

„plays for”,

określić pomiędzy iloma obiektami zachodzi dana

relacja.

2019-11-23 09:13 D:\POKAZ-


42

Szczególne znaczenie w modelach mają następujące

wartości:

0

1

0..* (od zera do nieskończoności)

1..* (od jednego do nieskończoności)

* (dowolna liczba)

Numer znajdujący się w najbliższym sąsiedztwie

danej klasy mówi, ile obiektów tej klasy uczestniczy

w relacji.

W przykładzie z klasami Team i Player mamy więc,

że każdy zawodnik gra dla dokładnie 1. drużyny, a

drużyna ma co najmniej 1. zawodnika.


Diagram obiektów

Tak jak diagram klas opisuje klasy i powiązania

między nimi, tak diagram obiektów zajmuje się

obiektami z OOP. Choć diagram obiektów można

często traktować jako uszczegółowienie diagramu klas,

należy pamiętać, że nie jest jedno i to samo. Diagram

obiektów ukazuje role

spełniane przez poszczególne instancje danej klasy

(klas). Różna jest także notacja. W diagramie

obiektów, obiekt ukazywany jest jako prostokąt (tym

razem nie podzielony na żadne części), w którym

umieszczona jest jego nazwa pisana z podkreśleniem.

Po dwukropku po nazwie, można podać też nazwę

klasy, którą dany obiekt reprezentuje.

2019-11-23 09:13 D:\POKAZ-PPT1\PROJEKTOWANIE.ppt

44

Dla obiektu możliwe jest także określenie jego stanu

działania (run-time state), czyli ustalenie wartości jakie

przyjmą składowe klasy obiektu w trakcie działania

systemu.

Powyższy przykład to obiekt klasy reprezentującej

teksturę trawy, czyli pojedynczą teksturę używaną w

świecie gry. Width i Height i wartości im towarzyszące są

zaś wspomnianym stanem działania.


Diagram przypadków użycia

Diagram przypadków użycia jest diagramem istotnym

we wstępnej fazie projektowania.

Prezentuje bowiem wymagania stawiane przed

tworzonym systemem (lub dowolnym jego

podsystemem).

Można go użyć jako pomoc przy specyfikacji wymagań

stawianych przed systemem informatycznym.

Diagram ten prezentuje interakcje zachodzące

pomiędzy

systemem a zewnętrznymi jednostkami.


W diagramie użycia jednym z ważniejszych obiektów (tu nie chodzi

mi jednak o obiekt w sensie OOP) jest tzw. Aktor.

Aktorem nazywamy taki obiekt, który prowadzi interakcję z

systemem jednak sam do niego nie należy.

Przykładem Aktora może być Klient11 wchodzący do systemu Sklep

i prowadzący z tym systemem pewną interakcję, np. Kup.

Aktorzy mogą być z innymi aktorami w takich samych relacjach jak

klasy (również notacja nie ulega zmianom).

Sposobem reprezentacji Aktorów jest człowieczek złożony z

odcinków z dużą głową:


Innym ważnym pojęciem są tak zwane przypadki użycia

(w zasadzie jest to sedno tego diagramu). Jest to element

reprezentujący jakąś konkretną pracę, interakcję

reprezentowaną bez przedstawienia szczegółów.

Dla przykładu ze sklepem przypadkiem użycia mogłaby

być Zakup. Przypadki użycia są prezentowane przy

pomocy owali, w środku których jest wyrażenie

odczasownikowe.

Podobnie jak klasy i aktorzy Przypadki Użycia mogą być

z innymi obiektami w relacjach. Inne właściwości

Przypadków Użycia pomijamy.

Poniżej znajduje się przykład przypadków użycia

systemu Player (który może być utożsamiany z postacią

gracza):


Diagram aktywności

Diagram aktywności to nic innego jak sieć

działań danego podsystemu.

Jedyna poważniejsza różnica między nim a

typowym schematem blokowym to inna

forma notacji.

Istnieją jednak szczegóły będące jeszcze

innymi różnicami.


Początek schematu oznaczany jest przez

wypełnione koło, a koniec przez dwa koła

zawarte jedno w drugim.

Operacje (tu zwane akcjami) oznaczamy

przez prostokąty o mocno zaokrąglonych

rogach, a instrukcje warunkowe standardowo

przez równoległoboki.

Obok strzałek, informujących o kierunku

przepływu działania systemu, można

umieszczać opisy. Diagram ten ma jeszcze

dodatkowe możliwości.


Diagram Automatu Stanów

Automat Stanów, to schemat blokowy, o ustalonym

początku i końcu (nazywanych odpowiednio stanem

początkowym i końcowym) oraz pewną skończoną liczbą

stanów pośrednich pomiędzy nimi.

Diagram Automatu Stanów opisuje zachowanie (czy

sekwencję zachowań) konkretnego obiektu, a nie jak w

przypadku diagramu aktywności – całego systemu lub

pewnego jego podsystemu.

Sam Stan to status obiektu w danym momencie, lub

aktualnie wykonywana przez niego czynność.

Każdy Stan jest połączony przynajmniej z jednym innym

w taki sposób, że zawsze istnieje droga ze stanu

początkowego do końcowego.


Każdy stan jest prezentowany jako prostokąt z

zaokrąglonymi rogami i nazwą stanu w jego górnej

części - pośrodku.

Dwa stany są ze sobą połączone za pomocą strzałki,

której grot wskazuje kierunek przechodzenia przez

stany.

Nad nią może się też znajdować krótki opis

czynności będącej przyczyną zmiany stanu.

Jeśli takiego opisu brakuje, oznacza to, że zmiana

zachodzi w sposób samoistny bez względu na status

systemu.


4

Czasem przydatną możliwością jest określenie działań

systemu przy wejściu i opuszczeniu danego stanu.

Jeśli taka konieczność zachodzi, w dolnej części prostokąta

stanu wpisuje się:

On Entry / [działanie]

On Exit / [działanie]

Stan może przejść z siebie samego do siebie samego.

Poniżej znajduje się przykład prezentujący stan

psychiczny potwora (NPC) w zależności od kilku działań

gracza.

Sposób zapisu stanów początkowego i końcowego jest

identyczny jak w diagramie aktywności.


Diagram sekwencyjny

Diagram sekwencyjny ukazuje współpracę między

obiektami (czyli tym razem już nie na poziomie klas) i

przesyłane między nimi komunikaty. Możliwe jest też

użycie w przypadku tego diagramu Aktorów.

Obiekt jest prezentowany w sposób standardowy, tj. jako

prostokąt z nazwą obiektu i ewentualnie nazwą jego klasy:

np. Obiekt: B to obiekt klasy B.

Bez względu na użyte figury, prezentuje się je w sposób

tradycyjny, przy czym leżą one w jednej linii (w poziomie)

i od każdego z nich odchodzi w dół pionowa przerywana

linia.

Te przerywane linie są ze sobą łączone strzałkami, powyżej

których umieszcza się nazwę komunikatu przesyłanego

miedzy poszczególnymi obiektami.


Komunikat można przesyłać między dowolnymi dwoma

zdefiniowanymi na diagramie obiektami – nawet do

obiektu, który komunikat wysłał.

Możliwe jest też wysyłanie komunikatu od obiektu do

siebie samego.

Przesyłanie komunikatu jest zaznaczane za pomocą

strzałki, powyżej której znajduje się krótki opis bądź

nazwa komunikatu. Jeśli strzałka jest rysowana za pomocą

linii przerywanej, oznacza to że dochodzi do wysłania

(send) bądź zwrócenia (return) pewnych

danych.

Poszczególne komunikaty są numerowane począwszy od

indeksu 1 dla komunikatu umieszczonego najwyżej w

diagramie. Indeksy rosną wraz ze schodzeniem w dół

diagramu.


Oprogramowanie

Zaletą UMLa jest to, że bez trudu da się zaprojektować

podsystemy przy pomocy kartki i długopisu (lub ołówka –

wówczas łatwiej o poprawianie błędów).

Jednak zwykle i tak należy ostatecznie skorzystać z

oprogramowania komputerowego. Niestety brak na rynku

dobrych darmowych narzędzi zgodnych ze standardem

UML 2.0 (nie wspominając o wersji 2.1), a cena

komercyjnych pakietów zwykle przekracza możliwości

pojedynczego programisty (czy nawet niewielkich

zespołów developerskich).

Można skorzystać z freeware’owego StarUML, mimo że

nie jest w pełni zgodny z najnowszą specyfikacją i choć

ciągle pełen jest drobnych błędów.


Dobrym narzędziem jest komercyjny pakiet Poseidon

– istnieje jednak jego darmowa uproszczona wersja

Trial.

Z innych narzędzi należy również wymienić olbrzymi

pakiet korporacji Rational, czyli Rose.

Jednak jego zaporowa cena nie czyni z niego

dostępnego pakietu.

Zajęto się tylko pobieżnie najistotniejszymi aspektami

UMLa 2.0.

Ponadto nie wspomniano o różnych modelach.

Nie przedstawiono precyzyjnej definicji pojęcia model.

Jednak wiedza ta nie jest niezbędna do tworzenia

pełnoprawnych projektów z wykorzystaniem tego

języka.


Bloki konstrukcyjne

UML

Omówienie z zastosowaniem

programu

StarUML


Podstawowe obiektowe bloki konstrukcyjne UML

stosowane do budowy modeli:

• elementy – abstrakcje i obywatele pierwszej

kategorii w modelu; wyróżniamy następujące

elementy:

strukturalne,

czynnościowe,

grupujące,

komentujące.

• związki – powiązania między elementami modelu,

• diagramy – służą do grupowania istotnych

elementów.


Elementy strukturalne wyrażone rzeczownikami

stanowiące podstawowe składniki zapisanego w UML

modelu struktury:

• stanowią statyczne części modelu,

• reprezentują składniki pojęciowe albo fizyczne,

• istnieją 4 podstawowe rodzaje i 3 podobne do klas

(klasy aktywne, komponenty, węzły), gdyż określają

zbiory obiektów o zbliżonych atrybutach,

operacjach, związkach i znaczeniu.

Komponenty i węzły reprezentują byty fizyczne, a

pozostałe wymienione byty pojęciowe i logiczne.


Warianty elementów podstawowych:

• aktorzy,

• sygnały,

• klasy funkcji usługowych (rodzaje klas),

• procesy i wątki (rodzaje klas aktywnych),

• programy,

• dokumenty,

• pliki,

• biblioteki,

• witryny i tabele (rodzaje komponentów).

Dwa elementy czynnościowe wyrażone czasownikami –

dynamiczna część modelu opisujące zachowanie w

czasie i przestrzeni


Maszyna stanowa

Określa ciąg stanów, jakie obiekt lub interakcja

przyjmuje w odpowiedzi na zdarzenia zachodzące w

czasie ich życia.

Określa też ich odpowiedzi na zdarzenia. Za jej

pomocą można zdefiniować zachowanie pojedynczej

klasy lub korporacji. Maszyna stanowa składa się z

innych elementów:

• stany oraz przejścia (między stanami),

• zdarzenia (które powodują przejścia),

• czynności (odpowiedzi na zdarzenia).

Stan jest przedstawiany na diagramie jako prostokąt z

zaokrąglonymi rogami, z nazwą oraz podstanami jeśli

istnieją.


Elementy grupujące pełniące rolę organizacyjną –

bloki na które dany model może być rozłożony

Podstawowy rodzaj tego typu elementy to pakiet, za

pomocą którego można usystematyzować zapisany

model w UML. Inne elementy tego typu to:

• zręby,

• modele,

• podsystemy (rodzaje pakietów).

Elementy komentujące odgrywające rolę objaśniającą

Są to adnotacje, których można użyć w celu opisania,

uwypuklenia lub zaznaczenia dowolnych składników

modelu.


Notatka - stanowi podstawowy element komentujący,

który może się pojawić w modelu.

Służy do zbogacenia diagramu o ograniczenia i

objaśnienia, które najłatwiej wyrazić za pomocą

tekstu.

Wymagania - definiują zachowanie oczekiwane przez

otoczenie modelu

Związki:

• zależność,

• powiązanie,

• uogólnienie,

• realizacja.

Podstawowe bloki konstrukcyjne służące do

łączenia elementów w poprawnym modelu.


Powiązania - stanowią związek strukturalny

określający zbiór wiązań między obiektami.

Szczególny przypadek to agregacja (składanie), które

wyznacza więź między całością a częściami.

Na diagramie stanowi linię ciągłą, niekiedy z nazwą,

ale częściej z nazwami ról i oznaczeniami liczebności.


Diagramy

Diagram - schemat (rzut systemu) przedstawiający

zbiór bytów. Ten sam byt może się pojawić:

• na wszystkich diagramach,

• na niektórych,

• na żadnym.

Może zawierać dowolna kombinację elementów i

związków, lecz tylko niektóre kombinacje odpowiadają

5. perspektywom architektonicznym oprogramowania.

Najczęściej jest grafem w którym wierzchołkami są

elementy, a krawędziami związki.


Rodzaje diagramów:

• klas,

• obiektów,

• przypadków użycia,

• przebiegu,

• kooperacji,

• stanów,

• czynności,

• komponentów,

• wdrożenia.


Istnieją także inne rodzaje związków, a mianowicie:

• udoskonalenie,

• ślad,

• zawieranie,

• rozszerzenie (rodzaje zależności).


W UML są reguły znaczeniowe dotyczące:

• nazw – jak nazywać elementy, związki i

diagramy,

• zasięgu – jaki jest kontekst, który nadaje nazwie

specyficzne znaczenie,

• widoczności – w jaki sposób nazwy mogą być

widzialne i używane,

• spójności – jak elementy są ze sobą powiązane i

czy są właściwe,

• wykonywania – co oznacza działanie lub

symulowanie modelu dynamicznego.

Modele ewoluują w miarę upływu czasu. Tworzy się

też modele: skrócone, niepełne, niespójne.


Mechanizmy językowe w UML:

• specyfikacje,

• dodatki,

• zasadnicze rozgraniczenia,

• mechanizmy rozszerzenia (wprowadzania

nowych konstrukcji).

Dodatki: każdy element UML składa się z symbolu

podstawowego i rozmaitych dodatków.


Zasadnicze rozgraniczenie w modelowaniu systemów

obiektowych:

• klasa (abstrakcja) i obiekt (jedne konkretne

urzeczywistnienie tej abstrakcji),

• podobna dychotomia (występują przypadki

użycia i egzemplarze przypadków użycia,

komponenty i ich egzemplarze, węzły i ich

egzemplarze),

• interfejs – implementacja,

• przypadki użycia i kooperacje,

• operacje i metody.

Graficznie symbol obiektu różni się od symbolu

klasy tego obiektu jedynie podkreśleniem nazwy

linia ciągła.


3


Mechanizmy rozszerzenia dla potrzeb konkretnego

zadania oraz nowych technologii np. języków

programowania systemów rozproszonych:

UML jest językiem otwartym na różne niuanse

rzeczywistości. Występują 3 mechanizmy rozszerzania:

• Stereotypy umożliwiające rozszerzenie

słownictwa, by stały się dla danego języka

programowania obywatelami pierwszej kategorii

(standardowymi blokami konstrukcyjnymi),

• metki (umożliwia rozszerzenie listy właściwości

bloku konstrukcyjnego),

• ograniczenia, np. porządku umożliwiające

rozszerzenie bloku konstrukcyjnego.


Architektura systemu informatycznego to zbiór

znaczących decyzji dotyczących:

• organizacji,

• wyboru elementów i interfejsów,

• zachowań elementów opisanego w kooperacjach,

• składania elementów strukturalnych i

czynnościowych w podsystemy,

• stylu tworzenia konstrukcji.

Powinna umożliwiać kontrolowanie iteracyjnego i

przyrostowego procesu tworzenia systemu.

Architekturę systemu informatycznego można

zobrazować z 5 . powiązanych ze sobą perspektyw.


Wstęp do podstaw budowy modeli w StarUML

1. Okno po otwarciu programu z Start-

StarUML z pokazaniem:

• menu głównego (File, Edit, Format,

Model, Tools, View, Debug, Help,

• podkatalogów i opcji w prawej strony

okna tzw. menu Explorer,

• zestaw narzędzi Toolbox do budowy

bloków konstrukcyjnych UMLa,

• arkusz kratkowany budowy diagramów

(część środkowa).


Toolbox obejmuje następujące rozwijalne

grupy elementów i pojedyncze elementy

konstrukcyjne:

grupa Classes (Basic) obejmująca:

• Class (klasa), Interface (interfejs),

• Association (asocjacja),

• Aggregation (agregacja),

• Composition (kompozycja),

• Dependency (…)

• Generalizaction (generalizacja),

• Interface Realization (interface

realizacji),


Dalsze zaawansowane grupy elementów:

Clases Adavanced


Packages


Instances


Annotations


Robustness


2. Wybór nowego projektu np. typu (4+1 View

model) w postaci 4. widoków oraz 1. widoku

ogólnego przypadków użycia.

Korzystamy z menu:

File/New From Template/4+1 View Model.

W podoknie lewym pojawia się wyszczególnienie

widoków:


• Scenarios – scenariusze np. z etapu koncepcji i

analizy.

• Logical View - projektu (klasy, interfejsy,

wzorce). Występuje tu możliwość użycia

diagramów klas, obiektów, aktywności, struktur

złożonych i sekwencji.

• Development View - wdrożenia (konfiguracja,

instalacja i wykonywanie).

W ramach tego należy pokazać komunikację

fizycznego układu sprzętu z systemem. Użyte są

diagramy komponentów, wdrożenia i interakcji.


• Implementacji (zarządzanie konfiguracją systemu,

komponenty, wdrożenia, interakcje), diagramy

komponentów, czas interakcji, stany, struktury

złożone.

• Process View - procesów (ilustracja informacji w

zakresie współbieżności, wydajności i skalowalności).

Użyte są diagramy interakcji i aktywności

pokazujące zachowanie systemu podczas jego pracy.

• Physical View - przypadków użycia, pokazuje

wymaganą funkcjonalność systemu. Zastosowane są

diagramy przypadków użycia oraz kilka diagramów

interakcji pokazujących ich szczegóły.


3. Dodanie elementu na schemacie diagramie klas:

Naciskamy Class w podoknie lewym, następnie

lewym przyciskiem myszy uaktywniamy menu

podręczne i wybieramy Add.

Pojawia się stereotyp zdefiniowanej nazwy Class1.

Poprawiamy np. na Student.

W podoknie lewym w widoku Logical View

pokazuje się nowa nazwa.

Można myszką uaktywnić dany element na

diagramie, zmienić jego rozmiary i kolor czcionki

naciskając na A.


4. Dodanie atrybutu Attribute do klasy

Student poprzez kliknięcie prawym

przyciskiem myszy elementu na ekranie,

rozwinięcie menu Add i naciśnięcie Attribute.

Pojawia się stereotyp +Attribute1 Podwójne

kliknięcie i wpisanie Nazwisko.

Wybieramy w Properties, visibility

(widoczność) opcję private dla danej klasy

Student.


5. Dodajemy analogicznie kolejne atrybuty (pola

rekordu): imię, kierunek, semestr poprzez

naciśniecie przycisku „+” przy klasie.


Wprowadzamy kolejne klasy Wykładowca, Zjazd, Sala

oraz ich atrybuty analogicznie jak dla klasy Student też

jako prywatne.


7. Dodajemy interface – element spinający

klasy poprzez wybranie klasy i dodaj oraz

wprowadzenie np. atrybutów.

Z menu głównego Format wybieramy Format

Stereotype a następnie None.

Powoduje to zaznaczenie prostokąta na

wcześniej zaznaczonym interface Dziekanat.

Porządkujemy też nasze elementy projektu.


8. W głównym menu Format występuje domyślnie Supperss

Operations pozwalająca widzieć jak operacje na interfejsie

wpływają na widok diagramu.


9. Przykładowo usunięcie wcześniejszych

atrybutów w interface Dziekanat

następuje po kliknięciu na ten element i

potwierdzenie dla konkretnego atrybutu

opcji Delete from Model.


Dziękuję

za

uwagę

Zastosowanie UML w projektowaniu - WordPress.com · 2019. 11. 25. · symboli stosuje się zapis za...

Documents

Transcript of Zastosowanie UML w projektowaniu - WordPress.com · 2019. 11. 25. · symboli stosuje się zapis za...