Wstęp do UML cz.2 - trochę o modelowaniu

Jak sama nazwa wskazuje, UML jest językiem modelowania lub, inaczej mówiąc, konstruowania modeli. Czym jest w takim razie model? Model jest określany jako sposób na uproszczenie rzeczywistości przedstawiającej wybrane cechy i zasady działania pewnego obiektu, np. systemu informatycznego. Znając już definicję modelu, możemy dalej więc stwierdzić, że modelowanie ma na celu zapanowanie nad złożonością problemów, np. oprogramowaniem. 

Do czego potrzebne nam jest modelowanie? Modelujemy np. po to, aby uzyskać spójny widok tego, czego jeszcze nie mamy, ale chcemy to stworzyć. W przypadku systemów informatycznych modelujemy w celu:

• ukrycia szczegółów rzeczywistego, skomplikowanego systemu;
• dostosowania abstrakcji do potrzeb odbiorcy;
• lepszego zrozumienia funkcjonowania systemu;
• wnioskowania o zachowaniu rzeczywistego systemu na podstawie badania jego modelu.

Zarówno organizacje produkujące oprogramowanie jak i jego odbiorcy zdają sobie sprawę ze znaczenia metodyki tworzenia modeli wytwarzanych systemów. Cały problem polega bowiem na stworzeniu modelu, który jest zrozumiały dla zamawiających, a jednocześnie może posłużyć wykonawcom systemu jako wystarczająco szczegółowy plan. Model powinien być zatem zrozumiały dla przyszłych użytkowników systemu oraz osób zajmujących się wytwarzaniem go.

Podczas konstruowania modeli stosowana jest zasada abstrakcji, dzięki której możemy dostosować poziom opisu modelu do naszych potrzeb. Zasada abstrakcji polega przede wszystkim na ukrywaniu szczegółów. Znacznie ułatwia to projektantom systemów zapanować nad ich złożonością. Tym samym pozwala na lepsze zrozumienie przyszłemu użytkownikowi funkcjonowania rzeczywistych procesów zachodzących w systemie.

Najpowszechniejszą tendencją w projektowaniu systemów informatycznych jest modelowanie obiektowe. Modele obiektowe składają się przede wszystkim z obiektów, które ściśle odpowiadają pojęciom używanym np. przez użytkowników systemów w rzeczywistym świecie. Jednocześnie te same obiekty służą programistom do definiowania klas, czyli jednostek kodu w językach programowania obiektowego. Dzięki temu modele obiektowe są zrozumiałe zarówno dla programistów, jak i użytkowników systemów. Poza tym modele obiektowe mogą być bezpośrednio tłumaczone na kod, co w znaczący sposób ułatwia życie podczas budowy oprogramowania. 

Modelowanie systemów informatycznych obejmuje aspekty funkcjonalne i niefunkcjonalne. Obie kategorie dynamicznie rozwijały się w związku z wymaganiem obiektowego wytwarzania oprogramowania. Oba te aspekty są również wspierane przez UML, którego kolejne wersje rozszerzają je o nowe metody i techniki spełniające wymagania twórców systemów informatycznych.

Modele systemów informatycznych mogą być sklasyfikowane na podstawie różnych kryteriów. Modelując możemy brać pod uwagę np. przeznaczenie modelu, obszar modelowanego systemu, czy też stopień złożoności. Projektując system informatyczny możemy użyć modeli z następujących kategorii:

• model wymagań (a co za tym idzie, również modele wymagań funkcjonalnych i niefunkcjonalnych);
• model architektury;
• model implementacyjny;
• model danych.

Wciąż należy jednak pamiętać, że każdy model może być przedstawiony na różnym poziomie abstrakcji, czyli może zawierać różną liczbę szczegółów.

Klasyfikacja modeli może opierać się też na ich oddziaływaniu na system. W tym przypadku należy przyjrzeć się różnym perspektywom w modelowaniu systemu oraz kolejnych odwzorowaniach w procesie projektowania. W pierwszej kolejności wykonuje się zazwyczaj odwzorowanie świata rzeczywistego na model koncepcyjny. Zajmują się tym przede wszystkim analitycy biznesowi, którzy konstruują uproszczony model analityczny opisujący w zrozumiały i jednocześnie precyzyjny sposób rzeczywiste procesy. Wynikiem prac analityków biznesowych jest najczęściej model wymagań i model dziedzinowy prezentujący aspekty statyczne, czyli uczestników i elementy modelowanych procesów. Jest to perspektywa analityczna, która opisuje logikę działania systemu oraz jego strukturę. Modele z tej perspektywy budowane są na wysokim poziomie abstrakcji - nie zawierają szczegółów wystarczających do zaplanowania procesu implementacji systemu. Z tego względu potrzebne jest dokonanie transformacji z perspektywy analitycznych na implementacyjną. 

Modele konstruowane na potrzeby implementacji uwzględniają wymagania dotyczące środowiska implementacji systemu. Modele te zawierają szczegółowe informacje dotyczące m.in. typów danych, struktur danych lub algorytmów realizujących modelowane procesy w systemie. Zauważalny jest tutaj oczywiście większy stopień szczegółowości i skomplikowania. Modele te są z tego względu przeznaczone przede wszystkim dla twórców systemu.

W książce Modelowanie systemów informatycznych w języku UML 2.1 w praktyce opisane są pewne cechy dobrego i złego modelu. Według jej autorów, dobry model powinien:

• być zrozumiały dla wszystkich odbiorców, dla których jest przeznaczony;
• być zapisany w jasnej i przejrzystej formie;
• stosować zrozumiałe dla wszystkich odbiorców modelu symbole i elementy;
• zawierać taką liczbę szczegółów, aby nie zamazywać elementów, które na danym etapie są ważne (odpowiedni poziom abstrakcji);
• ułatwiać zrozumienie działania systemu na odpowiednim poziomie abstrakcji;
• umożliwiać realizację celu, dla którego został opracowany;
• być spójny i logiczny.

Z kolei zły model nie jest dostosowany do potrzeb projektowych i posiada następujące cechy:

• jest bardzo rozbudowany i zawiera wiele nieistotnych szczegółów;
• jest zapisany niezrozumiałym, skomplikowanym językiem;
• stosuje do opisu rozbudowaną i skomplikowaną notację;
• jest niespójny lub trudny w zrozumieniu;
• nie wiadomo, dla kogo jest przeznaczony i jakiemu celowi ma służyć.

UML jest najpowszechniej stosowanym standardem notacji modelowania obiektowego. Stał się powszechnym sposobem na projektowanie systemów informatycznych, ponieważ jest niezależny od używanej technologii czy języka programowania. Oprócz systemów informatycznych, UML służy także do modelowania procesów biznesowych. Wynika to w dużej mierze z łatwości przetłumaczenia tak opisanych procesów na projekt systemu wspierającego je.

Język UML jest tak popularny ze względu na swoją uniwersalność. Może znaleźć zastosowanie zarówno na etapie zamawiania oprogramowania, jak i szczegółowego projektowania struktury oraz interakcji składników kodu systemu. Kluczowe jest tutaj wybieranie ze składni języka tylko tych elementów, które są potrzebne na danym poziomie szczegółowości modelu.

Budowanie modeli jest dobrym sposobem na rozwiązywanie złożonych problemów. Model ułatwia zrozumienie rzeczywistego problemu i zapanowanie nad jego najważniejszymi elementami. Zawsze należy jednak pamiętać o dobrym zaplanowaniu modelowania. Należy brać wtedy pod uwagę m.in. to, do czego model będzie nam potrzebny (co chcemy za jego pomocą pokazać), kto będzie z niego korzystał, czy jaki poziom szczegółowości powinien opisywać. 

Do tego wszystkiego możemy śmiało wykorzystać język UML.

Źródła