UML – Podstawy

“Unikalny Model Lansowania” własnego systemu to klucz do wdrożenia dobrego oprogramowania. Modele są opracowywane aby zobrazować architekturę systemy, przedstawić interakcje i co najważniejsze panować nad tym w procesie tworzenia tego systemu.

Grady Booch “UML przewodnik…”

Gdy chcesz zbudować psią budę, możesz rozpocząć od zgromadzenia desek, gwoździ i podstawowych narzędzi, takich jak młotek, piła i taśma miernicza. W kilka godzin, obywając się bez wcześniejszego planowania robót, jesteś w stanie samodzielnie postawić coś takiego. Twój pies będzie Ci wdzięczny – pod warunkiem, że buda będzie wystarczających rozmiarów i że dach nie będzie przeciekał. Jeśli nie uda Ci się realizacja tego przedsięwzięcia, możesz zacząć wszystko od początku lub zmienić psa na mniej wymagającego.

Tego typu zachowania możesz przenieść na inne swoje zaangażowania. Jednakże nie trudno przewidzieć, że raczej spotkasz się z wymaganiami przekraczającymi oczekiwania Twojego psa. Dopiero przygotowanie projekty, przedyskutowanie go i oszacowanie pozwala na podjęcie zobowiązania, które ma szansę zostać dotrzymane.

Humorystyczne przedstawienie problemu, to często jedyny jaki Ci pozostanie sposób skwitowania nieprawidłowego podejścia do tworzenia i zarządzania projektem. Wielokrotnie słyszę o chęci studentów tworzenia skomplikowanych projektów, a podchodzą do tego jak do zbijania wspomnianej psiej budy.

Modelowanie

Trudnością nie jest napisanie setek linii kodu, a takie nim zarządzanie, aby dokładnie odzwierciedlał potrzeby i pozwalał na nadzór podczas jego tworzenia i eksploatacji. Wiele projektów wyglądających na początku jak psia buda z czasem przerodziła się w bardzo skomplikowane systemy. Wtedy właśnie te projekty mogą stać się ofiarami własnego sukcesu i uginać się pod naporem źle skonstruowanego systemu zarządzania, a właściwie braku należycie zaprojektowanego systemu zarządzania. Porażka w małym projekcie naraża na szkodę ograniczoną grupę ludzi, ale gdy z wielkim hukiem wali się duży projekt to poszkodowanymi mogą być rzesze ludzi inwestujących w niego.

Systemy źle projektowane często załamują się z różnych problemów, ale te, które odniosły sukces mają często podobne cechy. Tak jak na sukces oprogramowania ma wpływ wiele czynników, tak jednym z najważniejszych z nich jest modelowanie. Tworzenie modeli jest przyjętą i sprawdzoną metodą w inżynierii oprogramowania. Pozwala na opracowanie uproszczonej wizji projektu i ustalenie przewidzianych w nim zachowań, interakcji, koniecznych zasobów itp. Jedną z podstawowych przyczyn dla których tworzymy model jest chęć jak najlepszego zrozumienia systemu, który zamierzamy stworzyć.

Przez modelowanie jesteśmy w stanie osiągnąć następujące cele:

• Łatwiej jesteśmy w stanie wyobrazić sobie system takim jaki jest, jakim chcemy aby był i zweryfikować tę wizję z innymi.
• Modelowanie umożliwia nam określenie struktury i zachowania systemu.
• Wynikiem modelowania są szablony, które ułatwiają sterowanie działaniami w trakcie tworzenia systemu.
• Modele stanowią część dokumentacyjną projektu i naszych decyzji.

Wiadomo, że tworzenie modelu dla małych projektów przynosi małe korzyści (wymaga od nas zwiększonych wysiłków na stworzenie modelu projektu), ale w przypadku projektów wielkich i rozbudowanych jest ono niezastąpione. Główną cechą przemawiającą za tworzeniem modelu w przypadku dużych systemów jest to, że dzięki temu jesteśmy w stanie ogarnąć taki system w całości na pewnym określonym poziomie abstrakcji.

Zasady modelowania

W zależności od strony od której podchodzimy do “ugryzienia” naszego problemu wybieramy właściwy wg nas sposób modelowania. Cztery zasady modelowania traktują o:

• Podjęcie decyzji, jakie modele tworzyć, ma wielki wpływ na to, w jaki sposób zaatakujemy problem i jaki kształt przyjmie rozwiązanie.
• Każdy model może być opracowany na różnych poziomach szczegółowości (abstrakcji).
• Najlepsze modele odpowiadają rzeczywistości.
• Żaden model nie jest wystarczający. Niewielka liczba niemal niezależnych modeli to najlepsze rozwiązanie w przypadku każdego niebanalnego systemu.

Prowadzi nas to do stwierdzenia, że w przypadku modelowania istotną rolę pełni perspektywa z której dokonujemy wglądu w projekt wybierając to co jest dla nas istotne w danym momencie. Brak takiego opracowania zostawia nas albo z brakiem danych albo z ich kolosalnym natłokiem uniemożliwiając dostrzeżenie tego co niezbędne – często błędów koncepcyjnych istniejących od założenia. W przypadku systemów obiektowych zrozumienie architektury wymaga przeanalizowania kilku dopełniających się, wzajemnie powiązanych perspektyw. Są to: perspektywa przypadków użycia dotycząca wymagań stawianych systemowi; perspektywa projektowa uwzględniająca słownictwo specyficzne dla danego zagadnienia i przestrzeń dopuszczalnych rozwiązań; perspektywa procesowa modelująca podział systemu na procesy i wątki; perspektywa implementacyjna dotycząca fizycznego wykonania systemu; oraz perspektywa wdrożeniowa związana z inżynierią systemu. Każda z nich omawiać może zarówno strukturę, jak i zachowanie systemu. Pełne ich uwzględnienie prowadzi do stworzenia projektu systemu.

Wreszcie UML

Unified Modeling Language jest ściśle znormalizowany, służy opisaniu systemu korzystając z artefaktów, tworząc grafy o zdefiniowanych relacjach reprezentujące różne cechy tworzonego systemu. Jak sama nazwa wskazuje jest on językiem, a więc służy do opisania tworzonego systemu niezależnie czy mowa o oprogramowaniu, czy w innych dziedzinach, służy do:

• obrazowania
• specyfikowania
• tworzenia
• dokumentowania

Obrazowanie

Kiedy jedna osoba pisze program to w zasadzie łatwo jej w głowie kreślić wzajemne zależności tworzonego oprogramowania. Jednakże takie podejście bywa zwodnicze, gdy dochodzimy do pewnego poziomu uszczegółowienia systemu nagle może okazać się, że tak kreślone powiązania są zbyt mało szczegółowe, a rysunki naprędce skreślane gdzieś na skrawkach papieru niezrozumiałe nawet dla ich twórcy. Jeszcze większym problemem staje się przekazanie tych koncepcji innym członkom zespołu, lub nawet jeśli już ci członkowie potrafią się zrozumieć na tak szczątkowym komunikowaniu, to praktycznie niemożliwe jest włączenie nowego członka do zespołu. Opracowanie modeli UML rozwiązuje problem komunikacji formalnie wspomagając porozumiewanie się. Z powodu ograniczeń wynikających z zapisem niektórych idei tekstem UML umożliwia dokonanie tego za pomocą grafiki. Z uwagi na fakt, że UML to nie tylko zestaw symboli graficznych, a ściśle powiązane z nim idee skojarzeniowe programista może zapisać w nim swoiste swoje schematy myślowe powodując, że stają się one nie tylko dostrzegalne ale i zrozumiałe przez innego programistę.

Specyfikowanie

Specyfikowanie to tworzenie modeli dokładnie odzwierciedlających zamierzenia twórcze, dających jednoznaczne odpowiedzi w zakresie co i jak dany system ma realizować. UML jest językiem umożliwiającym dokładne specyfikowanie decyzji analitycznych, projektowych i implementacyjnych koniecznych do podjęcia w procesie tworzenia i wdrażania systemu.

Tworzenie

UML nie jest językiem programowania, ale istnieją systemy potrafiące na podstawie jego notacji tworzyć kod w różnych językach takich jak Java, C++ itp. Możliwe jest przetransponowanie odpowiednich opisów UML w relacyjną bazę danych. Takie przekształcenia umożliwiają forward ingeenering, czyli generowanie kodu z opisów UML, jednakże przekształcanie kodu w zapis UML (reverse engeenering) mimo, że także możliwe, jest jednak utrudnione z powodu, że w kodzie nie ma zawartych powiązań opisanych w UML, co wymaga stosowania odpowiednich narzędzi i nierzadko pomocy człowieka. Z uwagi na uniwersalizm, jednoznaczność i elastyczność opisu UML umożliwia przekształcanie bezpośrednie modeli w kod, uruchamianie ich, symulację oraz dostrajanie tak wdrożonych systemów.

Dokumentowanie

Poprawnie przeprowadzony proces tworzenia oprogramowania powoduje powstanie prócz kodu pobocznych treści tzw. artefaktów takich jak:

• wymagania,
• architektura,
• projekt,
• kod źródłowy,
• plany projektu,
• testy,
• prototypy,
• kolejne wersje.

Są one efektem pracy programistów, a ich forma zależy od samych programistów, ich zwyczajów, czasu czyli mniej lub bardziej formalnie. Są one istotnymi wskazówkami dla kontrolowania, oceniania i przekazywania informacji o systemie podczas tworzenia jak i w trakcie jego wdrażania.

Gdzie stosować UML

Przede wszystkim jego rola jest niebagatelna w przypadku budowania systemów informatycznych, z powodzeniem można go stosować w:

• tworzeniu systemów informacyjnych przedsiębiorstw,
• usługach bankowych i finansowych,
• telekomunikacji,
• transporcie,
• przemyśle obronnym i lotniczym,
• sprzedaży detalicznej,
• elektronice w medycynie,
• nauce,
• rozproszonych usługach internetowych.

Jak stosować UML

Aby możliwe było skorzystanie z tego narzędzia należy przede wszystkim poznać jego trzy główne składniki, a więc podstawowe bloki konstrukcyjne, reguły określające sposób łączenia tech bloków oraz mechanizmy stosowane w całym języku. Przyswojenie tych informacji umożliwi przede wszystkim zdolność czytania modeli w UML, a także w miarę zwiększania wprawy w pisaniu coraz bardziej zaawansowanych projektów.

Bloki konstrukcyjne UML

Słownictwo UML uwzględnia trzy rodzaje bloków konstrukcyjnych i są to:

• elementy,
• związki
• diagramy.

Elementy to byty abstrakcyjne i obywatele pierwszej kategorii w modelu; związki to powiązania między elementami, a diagramy służą do grupowania istotnych elementów.

Elementy

Elementy strukturalne

• Klasa
• Interfejs
• Kooperacja
• Przypadek użycia
• Klasa aktywna
• Komponent
• Węzeł

Elementy czynnościowe

• Interakcja
• Maszyna stanowa

Elementy grupujące

• Pakiet

Elementy komentujące

• Notatka

Związki

Cztery rodzaje związków występujące w UML to:

• zależność,
• powiązanie,
• uogólnienie,
• realizacja.

Diagramy

W UML wyróżniamy szereg schematów. Diagram w UML jest takim schematem przedstawiający zbiór bytów, najczęściej w formie grafu. Wspomniane byty mogą pojawiać się na wszystkich diagramach, czy różnych diagramach lub nie pojawiać się wcale. Diagramy te to rzut perspektywistyczny systemu z uwagi na dane założenie. Pozwala obejrzeć i przeanalizować różne aspekty systemu począwszy od jego części składowych poprzez jego pracę i wzajemne zależności. W UML wyróżnia się 9 rodzajów diagramów:

• klas,
• obiektów,
• przypadków użycia,
• przebiegu,
• kooperacji,
• stanów,
• czynności,
• komponentów,
• wdrożenia.

Reguły

Bloki konstrukcyjne muszą być rozmieszczone wg wyspecyfikowanych reguł, tak jak i w każdym języku są reguły składni zdania, tak i w UML takie zasady istnieją, by całość była zrozumiała, a model był wewnętrznie spójny i zgodny z innymi z nim powiązanymi modelami.

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

• nazw,
• zasięgu,
• widoczności,
• spójności,
• wykonywania.

Podstawowe mechanizmy językowe w UML

Są to:

• specyfikacje,
• dodatki,
• zasadnicze rozgraniczenia,
• mechanizmy rozszerzania.

Architektura

Obrazowanie, specyfikowanie, tworzenie i dokumentowanie systemu informatycznego wymaga podejścia do niego z kilku punktów widzenia. Perspektywy te są istotne w celu zagwarantowania realizacji przez system powierzonych mu zadań. Architektura to zbiór znaczących decyzji dotyczących:

• organizacji systemu komputerowego,
• wyboru elementów strukturalnych i ich interfejsów, z których system jest zbudowany,
• zachowania tych elementów, opisanego w kooperacjach,
• składania elementów strukturalnych i czynnościowych w coraz większe podsystemy,
• stylu architektonicznego, według którego tworzy się konstrukcję systemu, to znaczy charakterystycznych elementów statycznych i dynamicznych oraz ich interfejsów, kooperacji i składania.

Cykl tworzenia oprogramowania

UML jako niezależny od przyjętych procedur projektowych nie jest dostosowany do jakiegokolwiek cyklu. Z uwagi jednak na jego zalety przynosi największe korzyści w procesie:

• ukierunkowanym na przypadki użycia systemu,
• architekturocentrycznym,
• iteracyjnym i przyrostowym