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

• 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

• 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
• Unified Modeling Language

• 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

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

• 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

• 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

• 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
• Diagramy sekwencji dla metod

• ArgoUML (OpenSource, Linux/Wndows/Mac OS) UML 1.4, generowanie kodu dla wielu języków
• Eclipse UML2 Tools (Eclipse Modeling Framework, EMF), Acceleo - system generacji kodu oparty o EMF
• Dia (GTK, GPL, Linux/Win/Mac) + Dia2code, cpp2dia
• Creately diagramming & collaboration
• Umbrello UML Modeller (KDE)
• StarUML (Win), GNU GPL, inżynieria w przód i wstecz kodu w Javie, C#, C++
• IBM Rational Software
• MS Visio
• List of UML tools

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

• Klas: nazwa, atrybuty (pola), operacje (metody)
• 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)

• Asocjacja - powiązanie pomiędzy obiektami lub klasami
• Agregacja i kompozycja
• Generalizacja
• Powiązania ilościowa

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

• Diagram przypadków użycia (ang. use-case diagram) opisuje system z punktu widzenia użytkownika. Modeluje funkcjonalności systemu.

• Szczegółowy opis przypadków użycia → diagramu aktywności, diagramy stanów

• 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)
• przypadki użycia – sekwencja możliwych czynności, które system może wykonać
• pojedynczy przypadek użycia
  * związki – asocjacje, generalizacja

• zawieranie (includes) - wydzielenie przypadku użycia w celu uproszczenia modelu (przypadek może jest wielokrownie 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

• modelowanie zachowania systemu, realizacja przypadków użycia
• opisuje interakcje pomiędzy częściami systemu w postaci sekwencji komunikatów wymienianych między nimi

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

• Regiony (ramki) (ang. interaction use) umożliwiają zapis takich aspektów realizacji programu jak instrukcje warunkowe czy pętle.
• opt (optional), alt (alternative), ref (reference), loop, assert, …

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

• Dla dowolnej metody w kodzie → Generate Sequence Diagram
• 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ć

• Diagram aktywności (diagram czynności), przedstawia sekwencję kroków wykonywanych przez modelowany fragment (rodzaj schematu blokowego)

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

• 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

• 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ść - pokazuje połączenie wymaganego interfejsu komponentu z udostępnionym interfejsem innego komponentu
• Część - wewnętrzna składowa komponentu, może być też komponentem
• Delegat - połączenie portu interfejsu z częścią (wewnętrznym komponentem)
• Uogólnienie
• Komentarz

• 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

• 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

• Architecture explorer
• Layer explorer
• Diagramy klas i sekwencji
• Mapy kodu (code maps) i grafy zależności (dependency graphs)

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

• tworzenie map tylko VS 2013 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

• tylko VS 2013 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)

• 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

• 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

• 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

• Modeling the Application (MSDN)
• http://creately.com/diagram-type/use-case
• Creately diagramming & collaboration
• Diagramy UML Michał Wolski
• http://www.uml-diagrams.org/