Identyfikacja i modelowanie struktur i procesów biologicznych Laboratorium 2: Wprowadzenie do UML-a. mgr inż. Urszula Smyczyńska AGH Akademia Górniczo-Hutnicza 1. Cel zajęć Celem zajęć jest zapoznanie z podstawami modelowania systemów w języku UML, ze szczególnym uwzględnieniem jego zastosowań związanych z medycyną i inżynierią biomedyczną. 2. Wstęp UML (ang. Unified Modelling Language), zunifikowany język modelowania, służy do graficznego modelowania różnorodnych systemów i procesów. UML został zaprojektowany około połowy lat 90. XX wieku jako narzędzie do modelowania systemów informatycznych. Pierwotnie miał służyć przede wszystkim do usprawnienia komunikacji w zespołach zajmujących się projektowaniem i produkcją oprogramowania. Było to wówczas istotne, ponieważ systemy (najczęściej budowane w oparciu o techniki programowania obiektowego) stawały się bardzo złożone, a ich twórcy posługiwali się bardzo różnymi metodami opisu, co w praktyce często uniemożliwiało sprawny przepływ informacji. Istnienie jednolitej notacji, znanej niemal wszystkim osobom zaangażowanym w produkcję systemów informatycznych, miało ułatwić m.in. uzyskanie porozumienia między klientem a dostawcą oprogramowania, przepływ informacji między członkami zespołu twórców oprogramowania (np. kierownikiem projektu, analitykami i programistami) oraz szybkie wprowadzenie nowych członków zespołu w pracę nad projektem. Modelowanie systemu w UML-u polega na graficznym przedstawieniu jego funkcjonalności, stawianych mu wymagań i działania w określonych okolicznościach. Proces ten jest praktycznie niezależny od technologii informatycznej, w jakiej system będzie później realizowany. Dzięki temu okazało się, że UML może być z powodzeniem stosowany nie tylko w modelowaniu systemów informatycznych i programów komputerowych, ale też innych procesów i struktur, np. działania systemów biznesowych czy przedsiębiorstw, baz danych, a nawet procedur medycznych. Mimo, że nauki biomedyczne nie są najbardziej typowym obszarem zastosowania modelowania w UML-u, to istnieją przykłady jego skutecznego użycia również w tych dziedzinach. 1
3. Diagramy UML Notacja UML zakłada, że opis systemu będzie składał się z szeregu powiązanych diagramów, budowanych w oparciu o zunifikowaną notację. Diagramy dostępne w UML-u zwykle dzieli się na 2 kategorie: diagramy zachowań (dynamiczne), prezentujące działanie systemu oraz diagramy struktur (statyczne), odwzorowujące budowę systemu. Do diagramów zachowań zalicza się w UML 2.4.1 (najczęściej używane zaznaczone na czerwono): 1. Diagram przypadków użycia (ang. use case diagram) 2. Diagram aktywności, czynności (ang. activity diagram) 3. Diagram maszyny stanów (ang. state machine diagram) 4. Diagramy interakcji (ang. interaction diagram): Diagram komunikacji (ang. communication diagram) Diagram sekwencji (ang. sequence diagram) Diagram czasowy (ang. timing diagram) Diagram przeglądu interakcji (ang. interaction overview diagram) Do diagramów struktur w UML 2.4.1 zaliczmy: 1. Diagram klas (ang. class diagram) 2. Diagram obiektów (ang. object diagram) 3. Diagram komponentów (ang. component diagram) 4. Diagram wdrożenia (ang. deployment diagram) 5. Diagram struktur złożonych (ang. composite structure diagram) 6. Diagram pakietów (ang. package diagram) 7. Diagram profili (ang. profile diagram) Klasyfikacja diagramów może być również zaprezentowana graficznie, co jest widoczne na poniższym rysunku, będącym jednocześnie pierwszym przykładem użycia notacji UML, a konkretnie diagramu klas. Diagram Diagram zachowań Diagram struktur Diagram przypadków użycia Diagram aktywności Diagram klas Diagram obiektów Diagram pakietów Diagram profili Diagram interakcji Diagram maszyny stanów Diagram komponentów Diagram struktur złożonych Diagram wdrożenia Diagram sekwencji Diagram czasowy Diagram komunikacji Diagram przeglądu interakcji Typy diagramów UML; przetłumaczony schemat z [5] 2
3.1. Diagram aktywności (czynności) Diagramy aktywności służą do prezentowania sekwencji czynności składających się na modelowany proces. Szczególnie ważna jest tu kolejność wykonywania czynności. W diagramach aktywności wykorzystujemy m.in. następujące elementy: Stan początkowy początek opisywanego procesu. Stan końcowy koniec procesu. Stany akcji kolejne wykonywane czynności. Węzeł decyzyjny możliwość wyboru jednej z kilku alternatywnych sekwencji zdarzeń. Punkty synchronizacji rozdzielanie i łączenie równoległych przepływów czynności. 3
Przykład 3.1: Organizacja konsultacji chirurgicznej Diagram aktywności dla konsultacji chirurgicznej pacjenta, źródło: [4] 4
3.2. Diagram przypadków użycia Diagram przypadków użycia służy do zobrazowania działania modelowanego systemu, a w szczególności sytuacji, w których może on być stosowany. Elementami diagramów przypadków użycia są m.in.: Aktorzy osoby (aktor osobowy), urządzenia lub programy (aktorzy nieosobowi), które wchodzą w interakcję z modelowanym systemem oraz inicjują jego działanie. Przypadki użycia sytuacje, w których używany jest system. Przy konstruowaniu przypadków użycia stosujemy zasadę, że opisane ma być co się dzieje?, a nie jak ma się to stać?. Związki powiązania między elementami modelu: Asocjacja połączenie aktora z przypadkiem użycia, z którego może korzystać. Zawieranie związek oznaczający, że jeden przypadek zawiera inny. Poniższy diagram czytamy zgodnie z kierunkiem strzałki, czyli Przypadek użycia 1 zawiera Przypadek użycia 2. Rozszerzanie związek, służący do opisania opcjonalnych działań, które mogą, ale nie muszą być elementem konkretnego przypadku użycia. Również czytamy zgodnie z kierunkiem strzałki, czyli poniżej mamy Przypadek użycia 2 rozszerza Przypadek użycia 1. 5
Przykład 3.2: system do zdalnego wykonywania badań USG Diagram przypadków użycia dla robotycznego systemu badań USG, z [3] 6
3.3. Diagram klas Diagramy klas są używane do opisywania elementów składowych systemu, w szczególności klas w programowaniu obiektowym. Podstawowymi elementami diagramu klas są: Klasy elementy systemu. Opis klasy składa się z nazwy, atrybutów (cech) i metod (funkcji), przy czym dwa ostatnie elementy mogą zostać pominięte. Związki powiązania między klasami: Generalizacja (dziedziczenie) związek oznaczający, że klasa pochodna posiada wszystkie cechy i funkcje klasy bazowej oraz inne dodatkowe. Strzałki na diagramach skierowane są od klasy pochodnej do bazowej, czyli na poniższym rysunku Klasa 2 dziedziczy po Klasie 1. Agregacja opisuje relacje typu część-całość, przy czym poszczególne części mogą funkcjonować również niezależnie, bez łączenia w całość. Kompozycja relacja podobna do agregacji, z tym, że części składowe nie są niezależne. Poniżej: Klasa 1 składa się z Klasy 2 i Klasy 3. 7
Zależność powiązanie oznaczające, że zmiana jednej z jego stron powoduje zmianę w drugiej. Asocjacja dowolne, inne, trwałe powiązanie. Może być skierowanie linia ze strzałką lub nie. Przykład 3.3: Schemat organizacyjny szpitala Struktura organizacyjna szpitala w formie diagramu klas, źródło: [1] 8
3.4. Diagram sekwencji Diagramy sekwencji używane są do modelowania komunikacji między poszczególnymi elementami systemu i jego otoczenia. Na tym diagramie czynności przedstawia się zawsze w kolejności chronologicznej z początkiem procesu u góry. Podstawowymi częściami diagramu sekwencji są: Linie życia obiektów (uczestników) służą do zaznaczania, jakie obiekty biorą udział w procesie, kiedy wykonują działania i jak się ze sobą komunikują. U góry linii w prostokącie wpisuje są nazwę obiektu. W dół od prostokąta biegnie przerywana oś czasu, której pogrubione fragmenty oznaczają okresy, gdy obiekt jest aktywny. Komunikat wysłanie komunikatu oznacza się strzałką, skierowaną od obiektu wysyłającego do adresata; nad strzałką dodaje się opis komunikatu. Odpowiedź na komunikat oznaczana strzałką przerywaną. 9
Przykład 3.4: Wyszukiwanie danych pacjenta w systemie informatycznym Diagram sekwencji dla wyszukiwania informacji o pacjencie w bazie danych, źródło: [2] 10
3.5. Diagram maszyny stanów Diagram maszyny stanów budujemy z następujących elementów: stan początkowy początek modelowanego procesu. stan końcowy koniec modelowano procesu. Może być kilka stanów końcowych. stan dowolny pośredni stan systemu, złożony z pewnych czynności i/lub oczekiwania na zaistnienie określonego zdarzenia. przejście między stanami wskazuje, jakie stany mogą następować bezpośrednio po sobie i jakie są warunki przejścia między nimi. Przykład 3.5: Użycie sprzętu chirurgicznego Diagram stanów narzędzi chirurgicznych 11
4. Przykłady oprogramowania Diagramy UML można tworzyć m.in. w następujących programach: 1. Violet UML Editor prosty program, który będzie używany podczas zajęć. Umożliwia tworzenie tylko niektórych typów diagramów. alexdp.free.fr/violetumleditor/page.php/ 2. Microsoft Visio program rozbudowany, przeznaczony do przygotowywania różnych schematów. Odpłaty, ale dla uczelni może być dostępny przez platformę w programie MSDN DreamSpark. Pozwala narysować większość diagramów UML 3. Visual Paradigm for UML również rozbudowane, profesjonalne narzędzie. W pełnej wersji do zastosowań komercyjnych, ale istnieje też wersja Community Edition bezpłatna do zastosowań niekomercyjnych, ale na diagramach pojawia się znak wodny firmy. Nadaje się do tworzenia wszystkich diagramów UML. www.visual-paradigm.com/solution/freeumltool/ Szersza lista narzędzi UML jest dostępna w Wikipedii. Ponadto istnieją również narzędzia umożliwiające generowanie diagramów UML z kodu programu lub odwrotnie kodu na podstawie diagramów. 5. Literatura 1. www.uml-diagrams.org. 2. Shi, S., Xiong, S.: Analysis and design of clinical information management system based on UML of AIDS of traditional chinese medicine. National Conference on Information Technology and Computer Science, CITCS 2012. ss. 119 123. Atlantis Press (2012). 3. Guiochet, J., Tondu, B., Baron, C.: Integration of UML in human factors analysis for safety of a medical robot for tele-echography. Proceedings of the 2003 of the IEEE/RSJ International Conference on Intelligent Robots and Systems. ss. 3212 3217. IEEE, Las Vegas, Nevada (2003). 4. Sobolev, B., Sanchez, V., Kuramoto, L.: Health Care Evaluation Using Computer Simulation. Springer (2012). 5. Object Managment Group: UML 2.4.1 Superstructure Specification. (2011). 12