→ Slide 1
Modelowanie systemu i badanie architektury systemów
→ Slide 2
Modelowanie systemów
Model obrazuje przyszły lub istniejący system
Jest zawsze przybliżeniem, nigdy w pełni nie odpowiada rzeczywistości
Uwypukla tylko wybrane aspekty systemu i pomija inne
Zunifikowany język: UML
→ Slide 3
Unified Modeling Language
Język do modelowania systemów nie tylko informatycznych. Semantyka i notacja pozwalająca opisywać szerokie spektrum problemów.
Zasady modelowania obiektowego jednak niezależne od języków programowania
Skalowany, do małych i dużych projektów, od ogólnych modeli do bardzo szczegółowych
1997 styczeń zatwierdzenie języka UML (wersja 1.0) przez Object Menagement Group (prace nad ujednoliceniem od 1994)
obecnie versja 2.5, 14 diagramów głównych + 2 abstrakcyjne
-
→ Slide 4
UML nie jest ...
językiem programowania, chociaż istnieje możliwość generowania kodu z niektórych diagramów
narzędziem, choć zawiera specyfikacje dla narzędzi
metodyką, nie definiuje procesu tworzenia oprogramowania, chociaż istnieją metodyki bazujące na UML
nie jest sposobem na analizę i projektowanie systemów komputerowych
→ Slide 5
Rodzaje diagramów
→ Slide 6
Diagramy struktur
-
-
-
Wdrożenia (deployment diagram)
Struktur złożonych (composite structure diagram) UML 2.0
Pakietów (package diagram) UML 2.0
Profili (profile diagram) UML 2.2
→ Slide 7
Diagramy zachowań
-
-
Maszyny stanów (
state machine diagram)
(dla UML 1.x Stanów, statechart diagram)
-
Komunikacji (communication diagram)
(dla UML 1.x Współdziałania, collaboration diagram)
-
Czasowy, harmonogramowania (timing diagram) UML 2.0
Sterowania interakcji (interaction overview diagram) UML 2.0
→ Slide 8
Projektowanie oprogramowania
Projekt architektury: wyodrębnienie podsystemów, modułów, komponentów i relacji między nimi
Specyfikacja abstrakcji (oprogramowania): wyszczególnienie dostarczanych usług i ograniczeń dla każdego podsystemu (środowisko, biblioteki, technologie, itp.)
Specyfikacja interfejsu dla każdego podsystemu
→ Slide 9
Najważniejsze diagramy
Projektując system informatyczny, rozpoczyna się przeważnie od tworzenia diagramów w następującej kolejności:
Przypadków użycia
Sekwencji
Klas
Aktywności
Są to najczęściej wykorzystywane diagramy. Pozostałe bywają pomijane, zwłaszcza przy budowaniu niedużych systemów informatycznych.
→ Slide 10
UML w Visual Studio
od VS 2010 ultimate
Diagram klas: typy i relacje między nimi
Diagram przypadków użycia: opis funkcjonalności
Diagram aktywności: sekwencyjny (lub współbieżny) przepływ informacji miedzy obiektami
Diagram komponentów: relacje komponentów i ich interfejsów,
Diagram sekwencji: interakcje między obiektami, komponentami i aktorami
→ Slide 11
UML Modeling Project
Rysowanie, edycja diagramów
Import diagramów w formacie XMI
Przeszukiwanie diagramów
Elementy diagramów mogą być współdzielone pomiędzy diagramami
Eksport diagramów jako obrazy, możliwe kopiowanie diagramów do Worda i PP
Możliwe rozszerzenie funkcjonalności narzędzi UML
Łącznie elementów diagramów lub całych diagramów ze zgłoszeniami TFS
→ Slide 12
Odkrywanie modelu w VS
Diagramy warstw: ogólna budowa systemu, walidacja zgodności modelu z kodem
Diagramy zależności (dependency graph): wizualizacja zależności w kodzie, (VS 2013 Ultimate, także Resharper)
Mapy kodu (code maps), VS 2013 Ultimate
Generowane z kodu diagramy klas, brak w VS2015
Diagramy sekwencji dla metod, brak w VS2015
→ Slide 13
Inne narzędzia
ArgoUML (OpenSource, Linux/Wndows/Mac
OS) UML 1.4, generowanie kodu dla wielu języków
-
Dia (GTK,
GPL, Linux/Win/Mac) + Dia2code, cpp2dia
-
-
StarUML (Win), GNU
GPL, inżynieria w przód i wstecz kodu w Javie, C#, C++
-
MS Visio
-
→ Slide 14
UML Diagram klas - podstawy
Diagram klas statyczny, koncepcyjny widok projektowanej aplikacji. Prezentuje strukturę klas i relacji miedzy nimi.
Pozwala na sformalizowanie specyfikacji danych i zestawu metod
Wizualizacja szczegółów implementacji klas
Tylko statyczne relacja, model zachowania może być opisany diagramem stanów
Realizację diagramu klas obrazuje diagram obiektów (odwzorowanie systemu w w wybranym momencie działania)
Narzędzia projektowe zgodne ze specyfikacją UML umożliwiają, na podstawie diagramów klas, generowanie elementów źródeł w popularnych językach obiektowych, takich (C++,Java, C#)
→ Slide 15
Opis klasy
[widocznosc] nazwa [:typ] [wielokrotnosc][= wartosc domyslna]
[widocznosc] nazwa [( lista parametrow )] [:typ zwracany]
→ Slide 16
→ Slide 17
Asocjacje (relacje)
Asocjacja - trwałe powiązanie pomiędzy obiektami lub klasami (np. firma i pracownicy).
Jednokierunkowa (ze strzałką), dwukierunkowa, agregacje (kompozycje)
Asocjacja może posiadać nazwą, na końcach połączeń może być określona rola oraz powiązania ilościowe
→ Slide 18
Agregacja
agregacja (zawieranie obiektów), wiązek typu całość-część, relacja posiadania, elementy częściowe mogą należeć do większej całości, jednak również mogą istnieć bez niej.
→ Slide 19
Kompozycja
kompozycja (złożenie), związek typu całość-część, części należą tylko do jednej całości, a ich okres życia jest wspólny — razem z całością niszczone są również części.
→ Slide 20
Generalizacja
→ Slide 21
Powiązania ilościowe
1 | tylko 1 |
0..1 | 0 lub 1 |
0..* | 0 lub więcej |
1..n | od 1 do n |
n..m | od n do m |
→ Slide 22
Interfejsy
→ Slide 23
Diagram klas w VS
→ Slide 24
Elementy diagramu klas
→ Slide 25
Generowanie kodu
→ Slide 26
Generowanie diagramów klas
Dostępne w VS2013, brak w VS2015
Diagram klas UML można utworzyć przeciągając wybrane elementy Architecture Explorer do projektu z diagramem klas
View → View Class Diagram tworzy diagram zbliżony do diagramu klas UML w solucji projektu. Daje możliwość edycji zawartości klas.

→ Slide 27
UML Diagram przypadków użycia
→ Slide 28
Aktorzy
→ Slide 29
Przypadki użycia
przypadki użycia – sekwencja możliwych czynności, które system może wykonać
pojedynczy przypadek użycia
→ Slide 30
Powiązania
związki – połączenie między elementami systemu
nie posiadają nazw
asocjacje dwukierunkowe lub jednokierunkowe, uogólnienia, zależność, realizacja
związki nie określają kierunku przepływu informacji
generalizacja, jak w diagramie klas (rodzaje aktorów i przypadków użycia)
→ Slide 31
Zawieranie i rozszerzenie
zawieranie (includes) - wydzielenie przypadku użycia w celu uproszczenia modelu (przypadek może jest wielokrotnie użyty). Przypadek wydzielony jest zawsze realizowany wraz z przypadkiem bazowym.
rozszerzenie (extend) - wydziela przypadek użycia, który występuje opcjonalnie
Źródło: http://www.agilemodeling.com/essays/useCaseReuse.htm
→ Slide 32
Diagram przypadków użycia w VS

→ Slide 33
UML Diagram sekwencji
modelowanie zachowania systemu, realizacja przypadków użycia
opisuje interakcje pomiędzy częściami systemu w postaci sekwencji komunikatów wymienianych między nimi
→ Slide 34
Elementy diagramu
Komunikaty
komunikaty asynchroniczne (strzałka)
wywołanie funkcji (strzałka z wypełnionym grotem)
powrót z funkcji (strzałka przerywaną linią)
Linie życia obiektów (ang. lifelines) - pionowe linie, reprezentują czas. Białe prostokąty umieszczone na linii życia obiektu oznaczają, że obiekt jest zajęty wykonywaniem pewnej czynności (natomiast nie mają bezpośredniego związku z istnieniem obiektu).
Tworzenie obiektów (konstruktory) i ich niszczenie (znak X)
→ Slide 35
→ Slide 36
Diagram sekwencji w VS
→ Slide 37
Generowanie diagramu sekwencji
Zmiany w kodzie i w diagramie nie są synchronizowane
Nawigacja od linii czasowych i komunikatów do linii w kodzie
Diagram nie powstaje w osobnym projekcie modelu ale można go (lub jego fragmenty) przekekopiować
→ Slide 38
UML Diagram aktywności
Diagram aktywności (diagram czynności), przedstawia sekwencję kroków wykonywanych przez modelowany fragment (rodzaj schematu blokowego)
W odróżnieniu od diagramu stanu nie opisuje działań związanych z jednym obiektem a wieloma, pomiędzy którymi może występować komunikacja przy wykonywaniu czynności
→ Slide 39
Elementy diagramu aktywności
Źródło: wikipedia.org
Stan początkowy i końcowy (czarne kółka)
Akcja wraz z etykietą (zaokrąglony prostokąt)
Przejście przepływu sterowania (ciągła strzałka)
Przejście przepływu obiektów (przerywana strzałka)
Decyzje (romb)
Współbieżność (poziome belki)
→ Slide 40
Diagram aktywności w VS

→ Slide 41
Diagram komponentów
→ Slide 42
Elementy diagramu komponentów
Komponent - fragment systemu, udostępnia interfejs, może zawierać inne komponenty
Udostępniony port interfejsu - zestaw wywołań jakie implementuje komponent
Wymagany port interfejsu - zestaw wywołań jakie musi udostępniać komponent
Zależność - połączenie wymaganego interfejsu z udostępnionym interfejsem innego komponentu
Część - wewnętrzna składowa komponentu
Delegat - połączenie portu interfejsu z częścią
Uogólnienie
Komentarz
→ Slide 43
Diagram komponentów w VS

→ Slide 44
Diagram warstw
Używany do obrazowania wysokopoziomowej, logicznej architektury systemu.
Organizuje fizyczne zadania, obiekty w logiczne, abstrakcyjne grupy zwane warstwami.
Za ich pomocą obrazowane są zadania jakie pełnią obiekty, lub fizyczne elementy systemu.
Każda warstwa może się składać z wielu podwarstw.
Organizacja kodu w warstwy opisujące oddzielne role i funkcje systemu pozwala lepiej zorganizować kod
→ Slide 45
Warstwy w VS
→ Slide 46
Elementy diagramu warstw
warstwa: logiczna lub fizyczna część systemu (namespace, klasa, metoda)
zależność: określa która warstwa korzysta z funkcjonalności innej warstwy
komentarze i połączenia z komentarzami
→ Slide 47
Generowanie z kodu
Generowanie diagramu warstw poprzez przeciąganie elementów z: Solution Explorer, Architecture Explorer, Dependency graphs
Walidacja zgodności modelu (diagramu) z rzeczywistym projektem, elementy projektu (artefakty) są powiązane automatycznie z elementami diagramu
Można definiować połączenia artefaktów (klasy, przestrzenie nazw, pliki) z warstwami. Forbidden/Required Namespaces - określenie czy dany artefakt jest dozwolony w przestrzeni nazw
Elementy diagramu można powiązać z innymi przedmiotami (np. dokumenty worda)
Grupy artefaktów mogą tworzyć pojedynczą warstwę lub mogą być rozseparowane na osobne warstwy
Warstwy mogą być zagnieżdżone
Liczba połączeń z warstwą widoczna na diagramie
Generate Dependencies - wsteczna inżynieria istniejących zależności (tylko dla elementów które można walidować)
→ Slide 48
Analiza architektury
→ Slide 49
Mapy kodu (code maps)
tworzenie map tylko VS 2013/15 Ultimate
wizualizacja powiązań pomiędzy obiektami (odwołania do obiektów) i metodami (wywołanie metod)
mapy pozwalają z łatwością nawigować po kodzie
Show on Code Map:
dla pliku źródłowego lub binarnego,
dla obiektu lub klasy
w czasie odpluskwiania (pause)
Architecture → Dependency Graph
→ Slide 50
Dependency graph
tylko VS 2013/15 Ultimate
ułatwia zrozumienie kodu i zależności w nim zawartych
zależności dla całej solucji, projektu, pliku, klasy, …
zależności pomiędzy plikami (np. pliki źródowe i nagłowkowe)
→ Slide 51
Zależności modułów
→ Slide 52
Zależności wewnątrz modułów i klas
→ Slide 53
Powiązanie plików C++
→ Slide 54
Analizator
wykrywanie problemów: pętle i cykle w grafie, zbyt głębokie zależności, brak zależności
Legend → Add → Analyzers
analizatory działają automatycznie dopóki nie zostaną usunięte
→ Slide 55
Architecture Explorer
Pozwala odnaleźć specyficzny fragment kodu poruszając się wgłąb hierarchii projektu: od widoku (klas, solucji), przez węzły, typy węzłów
W każdej kolejnej kolumnie pojawiają się elementy logicznie powiązane z aktualnym zaznaczeniem
Class view: logiczna struktura, przestrzenie nazw, klasy, elementy klas
Solution view: fizyczna struktura, projekty, pliki
Możliwość filtrowania i grupowania wyników
działa także dla plików binarnych
→ Slide 56
→ Slide 57