PDF Archive

Easily share your PDF documents with your contacts, on the Web and Social Networks.

Share a file Manage my documents Convert Recover PDF Search Help Contact



ip .pdf



Original filename: ip.pdf

This PDF 1.4 document has been generated by www.konwerter.net / *, and has been sent on pdf-archive.com on 17/06/2016 at 22:17, from IP address 193.59.x.x. The current document download page has been viewed 344 times.
File size: 1.8 MB (27 pages).
Privacy: public file




Download original PDF file









Document preview


Politechnika Świętokrzyska
w Kielcach
Wydział Elektrotechniki, Automatyki i Informatyki

Inżynieria programowania

Instrukcja laboratoryjna 1
„Wstęp do UML
Diagram przypadków użycia”

Przygotował:
mgr inż. Paweł Pięta
Kielce, 2016

1

Czym jest UML?

UML (ang. Unified Modeling Language), czyli zunifikowany język modelowania, to
system graficznych notacji/oznaczeń, oparty o środowisko metamodelowania MOF (ang.
MetaObject Facility), który pomaga przy specyfikowaniu, projektowaniu, wizualizacji i dokumentowaniu modeli systemów oprogramowania. W szczególności służy do modelowania struktury, zachowania i architektury systemów informatycznych, tworzonych za pomocą języków obiektowych. Może być także użyty do modelowania procesów bizenesowych
i struktur danych, jak również aplikacji nie programowanych obiektowo (np. w językach
Fortran, Visual Basic, COBOL). Poprzez użycie standardu XMI (ang. XML Metadata
Interchange) możliwe jest przenoszenie modeli UML pomiędzy różnymi narzędziami.
Za ojców języka UML uznawani są Grady Booch, James Rumbaugh i Ivar Jacobson.
W latach 1994–1995 pracujący w Rational Software Grady Booch i James Rumbaugh
opracowali język Unified Method. Jego dokumentacja w wersji 0.8 została zaprezentowana publicznie w 1995 roku. Także w 1995 roku do prac nad językiem dołączył Ivar
Jacobson. W 1997 roku Rational Software wydało wersję 1.0 dokumentacji, w której to
po raz pierwszy pojawiła się nazwa UML. Później w tym samym roku, UML w wersji 1.1
został zaadaptowany jako standard przez konsorcjum OMG (Object Management Group),
które od tamtej pory definiuje i zarządza specyfikacją tego języka. Pełna dokumentacja
UML opublikowana jest na stronie internetowej http://www.uml.org. Najnowsza wersja
standardu oznaczona jest numerem 2.5, a jej specyfikacja znajduje się pod następującym
adresem: http://www.omg.org/spec/UML/2.5/
Język UML modeluje systemy informatyczne za pomocą diagramów UML. Mogą być
one używane na trzy sposoby: jako szkic (ang. sketch), schemat (ang. blueprint) lub język
programowania. UML jako szkic i schemat mogą być zastosowane zarówno w inżynierii do
przodu (ang. forward engineering), jak i inżynierii wstecznej (ang. reverse engineering).
Dla inżynierii do przodu najpierw rysowane są diagramy UML, a dopiero potem pisany kod
aplikacji. W przypadku inżynierii wstecznej, diagramy UML budowane są na podstawie już
istniejącego kodu w celu jego lepszego zrozumienia. Najczęściej UML stosowany jest jako
szkic. Istotą szkicu jest selektywność, schemat charakteryzuje natomiast kompletność.
Szkice są celowo niekompletne, ponieważ podkreślają jedynie najważniejsze informacje.
Z kolei schematy w zamyśle są wyczerpujące i kompleksowe.
W inżynierii do przodu szkice używane są podczas dyskusji w zespole programistów,
pomagają zakomunikować pomysły i alternatywne rozwiązania na temat kodu, który ma
zostać wkrótce napisany. W inżynierii wstecznej szkice objaśniają działanie pewnych części
systemu. Nie przedstawiają każdej klasy, a jedynie te, które są najbardziej interesujące
i warte omówienia, zanim przejdzie się do analizowania samego kodu aplikacji.
Schematy mogą przedstawiać detale całego systemu, lub tylko jego szczególnego obszaru. W inżynierii do przodu opracowywane są przez projektantów, których zadaniem
2

jest stworzenie szczegółowych projektów przeznaczonych dla programistów. Powinny być
one wystarczająco kompletne, aby umożliwić programistom przełożenie ich bezpośrednio
na kod programu. W inżynierii wstecznej schematy dążą do przekazania szczegółowych
informacji na temat kodu programu w formie papierowej dokumentacji lub interaktywnej
przeglądarki graficznej.
Wraz ze wzrostem doświadczenia w używaniu języka UML, programowanie staje się
czynnością coraz bardziej mechaniczną, do tego stopnia, że można myśleć o jego zautomatyzowaniu. Z pomocą przychodzi trzeci aspekt korzystania z UML – jako języka programowania. W specjalnych, wyrafinowanych środowiskach istnieje możliwość określenia
specyfikacji całego systemu informatycznego za pomocą diagramów UML, które następnie kompilowane są bezpośrednio do kodu wykonywalnego. UML staje się wówczas kodem
źródłowym programu.
Na zajęciach laboratoryjnych język UML będzie używany do modelowania diagramów
UML jako szkiców i schematów. Przy zadaniach do wykonania będzie zaznaczone, czy
mają być wykonane jako szkic, czy schemat.

2

Diagramy UML

Język UML w wersji 2.0 definiuje trzynaście typów diagramów, podzielonych na trzy
kategorie. Sześć diagramów reprezentuje statyczne struktury aplikacji, składając się na
diagramy struktur (ang. structure diagrams):







diagram
diagram
diagram
diagram
diagram
diagram

klas ang. (class diagram),
komponentów (ang. component diagram),
struktur złożonych (ang. composite structure diagram),
wdrożenia (ang. deployment diagram),
obiektów (ang. object diagram),
pakietów (ang. package diagram).

Kolejne trzy diagramy reprezentują ogólne typy zachowań, składając się na diagramy
zachowań (ang. behavior diagrams):
• diagram aktywności (ang. activity diagram),
• diagram przypadków użycia (ang. use case diagram),
• diagram maszyny stanów (ang. state machine diagram).
Ostatnie cztery diagramy również należą do diagramów zachowań. Reprezentują różne
aspekty interakcji, składając się na diagramy interakcji (ang. interaction diagrams):
• diagram komunikacji (ang. communication diagram),
• diagram przeglądu interakcji (ang. interaction overview diagram),
3

• diagram sekwencji (ang. sequence diagram),
• diagram czasowy (ang. timing diagram).
Poszczególne zajęcia laboratoryjne będą dotyczyć następujących diagramów:
1.
2.
3.
4.
5.

3

diagram
diagram
diagram
diagram
diagram

przypadków użycia,
komponentów,
klas,
sekwencji,
aktywności.

Diagram przypadków użycia

Diagram przypadków użycia podsumowuje informacje na temat tego kto i w jaki sposób używa systemu informatycznego. Pokazuje granice systemu oraz jego interakcje ze
światem zewnętrznym. Przedstawia aktorów, przypadki użycia i następujące zależności
między nimi:







którzy aktorzy wykonują jakie przypadki użycia,
które przypadki użycia zawierają inne przypadki użycia,
które przypadki użycia rozszerzają inne przypadki użycia,
którzy aktorzy generalizują innych aktorów,
które przypadki użycia generalizują inne przypadki użycia,
które przypadki użycia zależą od innych przypadków użycia.

Przykładowe diagramy przypadków użycia zostały pokazane na rysunkach 1 i 2. Poszczególne elementy oznaczone wartościami liczbowymi to:
1. aktor (ang. actor ) – użytkownik, organizacja lub zewnętrzny system, które wchodzą
w interakcję z modelowanym systemem,
2. przypadek użycia (ang. use case) – akcja wykonywana przez jednego lub więcej
aktorów w celu osiągnięcia konkretnego celu,
3. asocjacja (ang. association) – oznacza, że aktor bierze udział w przypadku użycia,
4. asocjacja skierowana (ang. navigable association) – oznacza, że aktor inicjuje przypadek użycia,
5. podsystem (ang. subsystem) – pewna część modelowanego systemu; może być to
pojedyncza klasa, większy komponent lub cała aplikacja; przypadki użycia, których
dostarcza podsystem, znajdują się wewnątrz jego prostokąta; na diagramie komponentów jego odpowiednikiem jest komponent,

4

Rysunek 1: Diagram przypadków użycia – przykład nr 1

Rysunek 2: Diagram przypadków użycia – przykład nr 2

5

6. relacja zawierania (ang. include relation) – dodaje funkcjonalność przypadku zawieranego do przypadku bazowego (zawierającego); przedstawia rozbicie przypadku
bazowego na mniejsze kroki; przypadek bazowy wywołuje wszystkie zawierane przypadki, jednakże diagram przypadków użycia nie pokazuje kolejności poszczególnych
kroków (do tego celu służą diagramy aktywności i sekwencji); przypadek zawierany
znajduje się przy symbolu strzałki,
7. relacja rozszerzania (ang. extend relation) – dodaje cele i kroki przypadku rozszerzającego do przypadku bazowego (rozszerzanego) po wystąpieniu/spełnieniu pewnych
okoliczności/warunków (które mogą zostać zapisane np. w komentarzu); przypadek
rozszerzany znajduje się przy symbolu strzałki,
8. generalizacja (ang. generalization) – inaczej uogólnienie lub dziedziczenie; łączy element szczegółowy (potomek) z ogólnym (rodzic); element ogólny znajduje się przy
symbolu strzałki:
• szczegółowy przypadek użycia dziedziczy cele i aktorów swojego uogólnienia
oraz może dodać więcej celów i kroków do ich osiągnięcia,
• szczegółowy aktor dziedziczy przypadki użycia, atrybuty i asocjacje swojego
uogólnienia i może dodać ich więcej,
9. zależność (ang. dependency) – sygnalizuje, że konstrukcja elementu źródłowego zależy od elementu docelowego (tego, przy którym znajduje się strzałka),
10. komentarz (ang. comment) – używany w celu dodawania ogólnych notatek do diagramów,
11. artefakt (ang. artifact) – dostarcza link do innego diagramu lub dokumentu; zazwyczaj używany do połączenia przypadku użycia z diagramem sekwencji.

4

Zadania
1. Wybierz tematykę modelowanego systemu informatycznego.
2. Zapoznaj się z literaturą i materiałami do zajęć.
3. Zapoznaj się z możliwościami tworzenia projektów modelowania oraz diagramów
UML w oprogramowaniu Microsoft Visual Studio.
4. Z użyciem oprogramowania Microsoft Visual Studio zamodeluj diagram przypadków
użycia wybranego systemu informatycznego (szkic całego systemu).

6

Politechnika Świętokrzyska
w Kielcach
Wydział Elektrotechniki, Automatyki i Informatyki

Inżynieria programowania

Instrukcja laboratoryjna 2
„Diagram komponentów”

Przygotował:
mgr inż. Paweł Pięta
Kielce, 2016

1

Diagram komponentów

Diagram komponentów (ang. component diagram) pomaga przy wizualizacji struktury
systemu informatycznego na wysokim poziomie abstrakcji (wyższym niż diagram klas).
Pokazuje podział systemu na komponenty i ich wzajemne zależności (świadczone usługi)
realizowane poprzez interfejsy. Komponenty powinny reprezentować części systemu, które
mogą być niezależnie sprzedawane i aktualizowane. Pojedynczy komponent może implementować jedną lub więcej klas. Przykładowy diagram komponentów został pokazany na

Rysunek 1: Przykładowy diagram komponentów
rysunku 1. Poszczególne elementy oznaczone wartościami liczbowymi to:
1. komponent (ang. component) – reużywalny fragment funkcjonalności systemu; dostarcza usługi i korzysta z (wymaga) usług poprzez interfejsy; może składać się
z innych komponentów,
2. port (ang. port) – miejsce interakcji komponentu z innym komponentem, swoimi
częściami lub światem zewnętrznym,
3. interfejs dostarczany (ang. provided interface) – usługa dostarczana przez komponent; reprezentuje zestaw operacji, które komponent implementuje, i który może
zostać użyty przez inne komponenty lub zewnętrzne systemy,
4. interfejs wymagany (ang. required interface) – żądanie dostarczenia usługi; reprezentuje wiadomość, którą komponent wysyła do innych komponentów lub zewnętrznych
systemów w celu skorzystania z ich usług; wymagany w celu działania komponentu,
5. zależność (ang. dependency) – wskazuje, że interfejs wymagany jednego komponentu
może zostać obsłużony przez interfejs dostarczany innego komponentu; relacja ta
może być też użyta bardziej ogólnie, w celu zasygnalizowania, że konstrukcja elementu źródłowego zależy od elementu docelowego (tego, przy którym znajduje się
2

strzałka),
6. część (ang. part) – fragment wewnętrznej implementacji komponentu, którego typem jest zazwyczaj inny komponent; na diagramie umieszcza się je zagnieżdżone
wewnątrz komponentu; komponent może posiadać kilka części tego samego typu;
różne komponenty mogą posiadać części tego samego typu,
7. połączenie części (ang. part assembly) – łączy interfejs wymagany jednej części z interfejsem dostarczanym innej części; połączone części muszą znajdować się wewnątrz
tego samego komponentu,
8. delegacja (ang. delegation) – łączy port komponentu z interfejsem jednej z jego
części; może sygnalizować dwie rzeczy:
• żądania dostarczenia usługi wysyłane do komponentu są obsługiwane przez
jego część,
• żądania dostarczenia usługi wysyłane przez część są wysyłane na zewnątrz
przez komponent rodzica,
9. generalizacja (ang. generalization) – inaczej uogólnienie lub dziedziczenie; łączy element szczegółowy (potomek) z ogólnym (rodzic); element ogólny znajduje się przy
symbolu strzałki; szczegółowy komponent dziedziczy elementy i interfejsy swojego
uogólnienia,
10. komentarz (ang. comment) – używany w celu dodawania ogólnych notatek do diagramów,
11. kontrolka zwinięcia/rozwinięcia – ukrywa/pokazuje elementy wewnętrzne.

2

Zadania
1. Z użyciem oprogramowania Microsoft Visual Studio zamodeluj diagram komponentów wybranego podczas pierwszych zajęć systemu informatycznego (szkic całego
systemu). Wykorzystaj projekt z pierwszych zajęć, dodając w nim nowy typ diagramu.

3


Related documents


PDF Document pyt2
PDF Document ip
PDF Document ip lab05
PDF Document podatek vat 19 01 2015
PDF Document rider techniczny borze ski kasprzak
PDF Document kotly kondensacyjne


Related keywords