→ Slide 1

Modelowanie systemu i badanie architektury systemów

  • Modelowanie systemu
    • inżynieria w przód: specyfikacja → model → implementacja
    • UML, modele warstwowe
    • generowanie kodu z modelu
  • Analiza złożoności systemów
    • inżynieria wstecz:
      oprogramowanie → model i specyfikacja
    • walidacja poprawności modelu i zrealizowanego systemu
    • wizualizacja zależności w kodzie, systemie
    • eksplorator architektury, mapy kodu, grafy zależności
→ Slide 2
  • 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

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

→ Slide 6
→ Slide 7
→ Slide 8
  • Projekt architektury: wyodrębnienie podsystemów, modułów, komponentów i relacji między nimi
    • diagramy: komponentów , pakietów, warstw (nie UML)
  • Specyfikacja abstrakcji (oprogramowania): wyszczególnienie dostarczanych usług i ograniczeń dla każdego podsystemu (środowisko, biblioteki, technologie, itp.)
    • diagramy: przypadków użycia
  • Specyfikacja interfejsu dla każdego podsystemu
    • diagram: pakietów, komponentów
  • Specyfikacja komponentu
    • usługi komponentu: diagram przypadków użycia, sekwencji, itp.
    • budowa komponentu: diagram klas
  • Specyfikacja danych: opis struktur danych
    • diagramy: klas
  • Specyfikacja algorytmu
    • diagramy: sekwencji, aktywności
→ Slide 9

Projektując system informatyczny, rozpoczyna się przeważnie od tworzenia diagramów w następującej kolejności:

  1. Przypadków użycia
  2. Sekwencji
  3. Klas
  4. Aktywności

Są to najczęściej wykorzystywane diagramy. Pozostałe bywają pomijane, zwłaszcza przy budowaniu niedużych systemów informatycznych.

→ Slide 10

  • 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
  • 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
  • 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
→ Slide 14

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
  • Klasy: nazwa, atrybuty (pola), operacje (metody)
[widocznosc] nazwa [:typ] [wielokrotnosc][= wartosc domyslna]
[widocznosc] nazwa [( lista parametrow )] [:typ zwracany] 

→ Slide 16
  • poziom widoczności
    • - prywatne, tylko w obrębie klasy
    • + publiczne, dostęp globalny
    • # chronione, dostęp przez dziedziczenie
    • ~ zakres pakietu
  • zakres
    • klasowy (classifier), wspólny dla klas, pola i metody statyczne (podkreślenie)
    • instancji, tylko w zakresie obiektu
  • Klasy abstrakcyjne, metody abstrakcyjne (kursywa)
→ Slide 17
  • 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 (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 (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.

agilemodeling.com_images_models_classdiagramcomposition.jpg

→ Slide 20
  • generalizacja (dziedziczenie), oznacza się za pomocą niewypełnionego trójkąta symbolizującego strzałkę (skierowaną od klasy pochodnej do klasy bazowej).

→ Slide 21

agilemodeling.com_images_models_classdiagramassocationnotation.jpg

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
  • Do UML 1.4: interfejsy realizowane za pomocą klas abstrakcyjnych
  • UML 2: słowa «class», «interface»

  • Implementacja interfejsu
→ Slide 23

→ Slide 24

→ Slide 25

→ Slide 26
  • 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
  • Diagram przypadków użycia (ang. use-case diagram) opisuje system z punktu widzenia użytkownika (modeluje funkcjonalności)

  • Szczegółowy opis przypadków użycia → diagram aktywności, diagramy stanów
→ Slide 28
  • aktorzy – osoby, grupy osób lub elementy otoczenia systemu wchodzące w interakcje z systemem i odgrywający pewną rolę (jedna osoba może być reprezentowana przez kilku aktorów odgrywających różne role)

→ Slide 29
  • przypadki użycia – sekwencja możliwych czynności, które system może wykonać
  • pojedynczy przypadek użycia

→ Slide 30
  • 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 (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

→ Slide 33

  • 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
  • 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
  • Regiony (ramki) (ang. interaction use) umożliwiają zapis takich aspektów realizacji programu jak instrukcje warunkowe czy pętle.

Źródło: http://www.tracemodeler.com

  • inne: opt (optional), alt (alternative), ref (reference), loop, assert, …

Źródło: http://www.tracemodeler.com

http://www.uml-diagrams.org/

→ Slide 36

→ Slide 37
  • Dla dowolnej metody w kodzie PKM → Generate Sequence Diagram
  • brak w VS 2015

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

Ź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

→ Slide 41
  • Diagram komponentów - ogólna struktura systemu (lub jego fragmentu) oraz opis udostępnianych interfejsów
  • Opis sposobu oddziaływania na siebie wydzielonych części systemu

→ Slide 42
  • 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

→ Slide 44
  • 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

→ Slide 46

  • warstwa: logiczna lub fizyczna część systemu (namespace, klasa, metoda)
  • zależność: określa która warstwa korzysta z funkcjonalności innej warstwy
    • Jednokierunkwa, dwukierunkowa
  • komentarze i połączenia z komentarzami
→ Slide 47
  • 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

  • Architecture explorer
  • Layer explorer
  • Diagramy klas i sekwencji
  • Mapy kodu (code maps) i grafu zależności (dependency graphs)
→ Slide 49
  • 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
  • informacje o obiektach i połączeniach

  • Oznaczanie elementów oraz dodawanie komentarzy

→ Slide 50
  • 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

→ Slide 52

→ Slide 53

→ Slide 54
  • wykrywanie problemów: pętle i cykle w grafie, zbyt głębokie zależności, brak zależności
  • Legend → Add → Analyzers
    • Circular Reference - cykle
    • Find Hubs - 25% węzłow posiadających najwięcej połączeń
    • Unreferenced Nodes
  • analizatory działają automatycznie dopóki nie zostaną usunięte
→ Slide 55

  • 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
  • Elementy diagramów (np. obiekty i relacje) można połączyć z zadaniami TFS (work items)
    UML Model Explorer → Create Eork Item/ Link to Work Item
  • Diagramy powinny być dodane do repozytorium
  • Przykłady:
    • user story + diagram aktywności → opis możliwych sekwencji operacji
    • przypadek użycia + test case → weryfikacja poprawności implementacji przypadku użycia
    • element diagramu klas + bug → informacja o błędach w implementacji klasy
    • komponent + zadanie (task) → możliwość śledzenia postępów prac nad komponentem
→ Slide 57