ZARZĄDZANIE TECHNOLOGIAMI INFORMATYCZNYMI PRZYKŁADY TECHNOLOGII INFORMATYCZNYCH I ICH ZASTOSOWANIE Gdańsk Technologie Informacyjne. Zarządzanie PWNT 2007 ROZDZIAŁ 5 5.WYBRANE METODY I NARZĘDZIA MODELOWANIA SYSTEMÓW INFORMATYCZNYCH Z UŻYCIEM JĘZYKA UML Adam CZARNECKI 5.1. Wprowadzenie Rozdział prezentuje przykład technologii modelowania systemów informatycznych opartej na podejściu obiektowym w jednolitym środowisku, począwszy od Zunifikowanego Języka Modelowania (UML), poprzez metodykę Rational Unified Process (RUP), po aplikację Rational Software Modeler (RSM). 5.2. Rola modelowania Jednym z najczęściej powtarzanych stwierdzeń na temat przedsięwzięć informatycznych jest to, że mało które mieści się w określonym harmonogramie, budżecie i spełnia oczekiwania jakościowe. Inżynieria oprogramowania doczekała się wielu metodyk (m.in. Rational Unified Process RUP, Capability Maturity Model CMM, Information Technology Infrastructure Library ITIL, Project Management Body of Knowledge PMBoK, Projects in Controlled Environments PRINCE 2) służących zapewnieniu jakości powstającego systemu informatycznego. Niezależnie od tego, czy wybrana metodyka posiada to w swoich zaleceniach, czy też nie, warto się zastanowić nad skorzystaniem przy każdym realizowanym przedsięwzięciu z narzędzia pozwalającego zbudować model tworzonego oprogramowania. Dlaczego? Można wskazać szereg zalet włączenia w przedsięwzięcie fazy modelowania, m.in.: model pozwala wyabstrahować tylko te elementy rzeczywistości, które są istotne z punktu widzenia mającego powstać systemu, model daje się łatwiej analizować przez zespół niż tworzony kod, a tym samym oszczędzić czas analizy i ewentualne koszty wynikające z popełnionego błędu, Politechnika Gdańska, Wydział Zarządzania i Ekonomii, Zakład Zarządzania Technologiami Informatycznymi, e-mail: adam.czarnecki@zie.pg.gda.pl.
2 A. Czarnecki dobrze zbudowany model systemu informatycznego może być zrozumiały dla klienta i jednocześnie dość formalny, by był podstawą prac w zespole wytwórczym, a zatem może pełnić rolę dokumentacji zarówno przy inżynierii wymagań, jak i przy pracach implementacyjnych, złożony system można zdekomponować na zbiór prostszych modeli. Oczywiście, modelowaniu można też wytknąć wady, jakimi są czas i koszt potrzebne do budowy modelu. Zazwyczaj jednak, gdy przedsięwzięcie jest rozpisane na miesiące, a jego budżet znaczący, poświęcenie części tych zasobów na modelowanie może przynieść ich znaczną oszczędność w dalszych etapach. Szczególnie, gdy przestrzega się następujących zasad modelowania [4]: Model w znacznym stopniu przesądza o sposobie, w jakim będzie przebiegało rozwiązywanie modelowanego zagadnienia. Każde zjawisko można modelować na różnym poziomie ogólności/szczegółowości, a sztuką jest znalezienie poziomu optymalnego dla postawionego modelowi problemu. Najlepszy model to taki, który odwołuje się do odzwierciedlanej rzeczywistości upraszcza, ale nie idzie na skróty, które w rzeczywistości są manowcami. Rzadko pojedynczy model wystarcza do opisania zjawiska. Często lepiej zbudować kilka mniejszych modeli niż od razu porywać się na jeden kompleksowy. Spostrzeżenie, że wykorzystanie modelowania w projektach informatycznych może przynieść korzyści zarówno w wymiarze jakościowym, jak i ilościowym, doprowadziło to powstania co najmniej kilku technik, m.in. Object Modeling Technique OMT, Objectory Method, metoda Boocha. Twórcy tych technik, to jest w kolejności ich wymieniania Jim Rumbaugh, Ivar Jacobson oraz Grady Booch w połowie lat 90. XX w. połączyli swoje siły w firmie Rational Software, co stało się zaczątkiem Zunifikowanego Języka Modelowania (ang. Unified Modeling Language UML). Jest to w tej chwili standard de facto w modelowaniu systemów informatycznych. 5.3. Diagramy UML Formą prezentowania modeli w języku UML są diagramy. W wersji 2.1.2 zdefiniowanych jest 13 rodzajów diagramów: Diagramy strukturalne (ang. Structre Diagrams): o Diagramy klas (ang. Class Diagrams) prezentują klasy, ich atrybuty, operacje czy zobowiązania oraz relacje między klasami. o Diagramy komponentów (ang. Component Diagrams) ukazują podział systemu na komponenty, obrazując występujące między nimi zależności; mogą być używane do modelowania architektury systemu. o Diagramy obiektów (ang. Object Diagrams) przedstawiają strukturę systemu w określonym momencie, np. na potrzeby przypadków testowych. o Diagramy wdrożenia/rozlokowania (ang. Deployment Diagrams) pokazują rozlokowanie systemu, głównie na węzłach oznaczających sprzęt. o Diagramy struktur złożonych/połączonych (ang. Composite Structure Diagrams) służą pokazaniu wnętrza klasy i połączeń, jakie może nawiązywać ona nawiązywać realizując zadaną funkcjonalność. o Diagramy pakietów (ang. Package Diagrams) obrazują logiczny podział systemu na podsystemy/grupy wraz z zależnościami je łączącymi (w tym relacji zawierania). Diagramy zachowań (ang. Behaviour Diagrams): o Diagramy czynności (ang. Activity Diagrams) ukazują przepływ kontroli w systemie przez kolejne czynności.
Błąd! Nie można odnaleźć źródła odwołania.. Wybrane metody i narzędzia modelowania systemów informatycznych z użyciem języka UML 3 o Diagramy przypadków użycia (ang. Use Case Diagrams) prezentują funkcjonalności systemu użyteczne dla tzw. aktorów. o Diagramy stanów/maszyny stanowej (ang. State Machine Diagrams) opisują stany systemu oraz warunki przejść pomiędzy tymi stanami. o Diagramy interakcji (ang. Interaction Diagrams): Diagramy sekwencji (ang. Sequence Diagrams) pokazują przepływ komunikatów w czasie pomiędzy obiektami. Diagramy komunikacji (ang. Communication Diagrams) ukazują wymianę komunikatów pomiędzy obiektami, czerpiąc z informacje z diagramów: klas, sekwencji i przypadków użycia. Diagramy przeglądu interakcji (ang. Interaction Overview Diagrams) łączą diagramy sekwencji z elementami specyficznymi dla diagramów czynności. Diagramy czasowe/harmonogramowania (ang. Timing Diagrams) kładą nacisk na badanie zachowania obiektów w czasie; oś czasu biegnie na nich od lewej do prawej. Dokładne omówienie języka UML i jego diagramów czytelnik znajdzie w [1]. 5.4. Rational Unified Process W rzeczywistości tworzenia złożonych systemów sam język modelowania nie wystarcza, by radykalnie poprawić jakość (dojrzałość) przedsięwzięcia informatycznego. Sposobem jest skorzystanie z którejś z gotowych metodyk. UML powstał z myślą o z zgodności z wiodącymi w połowie lat 90. XX w. metodami projektowania obiektowego. Sam jednak stał się motorem do powstania w firmie Rational (zatrudniającej już wówczas twórców języka UML) nowej metodyki nazwanej Rational Unified Process (RUP) 1. Jest to zbiór wytycznych do procesu o charakterze iteracyjnym, które można dobierać (komponować) pod kątem konkretnego przedsięwzięcia informatycznego. Oto jego skrótowe przedstawienie. Metodykę RUP definiują trzy główne elementy: 1. zestaw podstawowych reguł skutecznego tworzenia oprogramowania, do których należą: o podejście iteracyjne, o zarządzanie wymaganiami, o stosowanie architektury opartej na komponentach, o modelowanie wizualne (z użyciem UML), o ustawiczne weryfikowanie jakości, o zarządzanie zmianą, 2. ramowy model procesu oraz powiązana z nim biblioteka dostępnych treści metod, 3. język do opisu treści metod i procesów. Najnowsza specyfikacja RUP oznaczona jest numerem 7.0. 5.4.1. Fazy Tak jak tkaninę tworzą nici wątku i osnowy, tak materię RUP definiują fazy i dyscypliny (Rys. 5.1). Fazy obrazują przebieg przedsięwzięcia w czasie. Wyróżnia się: 1 Można próbować tłumaczyć tę nazwę na język polski jako Zunifikowany Proces firmy Rational lub Sensowny i Ujednolicony Proces, jednak przyjęło się może i słusznie, patrząc na powyższy efekt prób translatorskich stosować nazwę oryginalną, a jeszcze częściej jej skrót RUP.
4 A. Czarnecki 1. rozpoczęcie (ang. Inception) tu następuje sformułowanie problemu, tj. zagadnienia biznesowego, 2. opracowywanie (ang. Elaboration) analiza dziedziny i stworzenie wstępnej architektury systemu, 3. budowanie (ang. Construction) w głównej mierze są to prace programistyczne, 4. przekazanie (ang. Transition) dostarczenie produktu, tj. oprogramowania, użytkownikom końcowym. Rys. 5.1. Fazy, dyscypliny oraz iteracje w Rational Unified Process wraz z szacowanym rozkładem zasobów. Źródło: [5]. 5.4.2. Dyscypliny Drugim wymiarem RUP są dyscypliny. Jest ich dziewięć i wskazują one na treść tego, co ma zostać wytworzone: 1. modelowanie biznesowe (ang. Business Modeling) opisanie wizji funkcjonowania organizacji po wdrożeniu systemu, występujących procesów, ról, odpowiedzialności, 2. wymagania (ang. Requirements) zbierane przez analityków; mają opisywać, co system ma robić (a nie: jak?), 3. analiza i projekt (ang. Analysis & Design) zobrazowanie sposobu, w jaki będzie tworzony system w fazie implementacji, 4. implementacja (ang. Implementation) wytworzenie kodu źródłowego, jego testy jednostkowe, integracja komponentów i kompilacja, 5. testowanie (ang. Test) kompleksowe działania sprawdzające funkcjonalność, jakość użytkową, niezawodność, wydajność i podatność na obsługę tworzonego systemu, 6. wdrożenie (ang. Deployment) działania zapewniające dostarczenie końcowemu użytkownikowi działającego systemu oraz wsparcia,
Błąd! Nie można odnaleźć źródła odwołania.. Wybrane metody i narzędzia modelowania systemów informatycznych z użyciem języka UML 5 7. zarządzanie zmianą i konfiguracją (ang. Configuration and Change Management) procedury zapewniające korzystanie z właściwych wersji tworzonych jednostek konfiguracji (artefaktów) oraz dające formalne możliwości ich zmiany, 8. zarządzanie projektem (ang. Project Management) zapewnia wytyczne do planowania, kierowania zespołem, realizacji oraz kontrolowania postępów projektu z uwzględnieniem czynników ryzyka, 9. środowisko (ang. Environment) służy określeniu działań niezbędnych do zaprojektowania procesu pod kątem realizowanego przedsięwzięcia Dyscypliny 1-6 mają charakter inżynierski, 7-9 to dyscypliny pomocnicze. 5.4.3. Zawartość W ramach faz i dyscyplin RUP odwołuje się do swoistych cegiełek tworzących proces. Są to: role (kto?) określają zbiór umiejętności, kompetencje oraz odpowiedzialność, produkty (co?) artefakty powstałe w wyniku realizacji zadań, wliczając w to dokumentację oraz modele, zadania (jak?) określają jednostki pracy przypisane do ról, a skutkujące powstaniem konkretnych produktów. Rys. 5.2. Dokumentacja Rational Unified Process w Software Development Platform. Źródło: SDP 6.0. Zarządzanie projektami z użyciem metodyki RUP może być wsparte przez aplikację IBM Rational Method Composer. Z nią zgodne są też pozostałe narzędzia z serii Rational. Sam
6 A. Czarnecki opis metody dołączany jest do środowiska Software Development Platform (Rys. 5.2). Pokazuje to, że zaprezentowana metodyka nie jest tylko zaakceptowanym przez grono ekspertów dokumentem, ale wcielonym w praktyce rozwiązaniem. 5.5. Rational Software Modeler Przykładem narzędzia zgodnego z RUP jest Rational Software Modeler (obecnie w wersji 7.0). To narzędzie modelowania systemów informatycznych firmy IBM (od 2003 r., kiedy to IBM kupił firmę Rational). Aplikacja ta działa w szerszym środowisku IBM Software Development Platform zbudowanym na opensource owym rozwiązaniu Eclipse. Rational Software Modeler (RSM) powstał z myślą o wytarzaniu oprogramowania w oparciu o tworzony model (ang. Model-Driven Development, MDD) (Rys. 5.3). W praktyce tworzony jest zbiór modeli opisujących system na potrzeby poszczególnych czynności oraz etapów cyklu wytwórczego. Przekształcanie modelu Modelowanie przedsiębiorstwa Analiza wymagań - przypadki użycia Modelowanie architektury Tworzenie modeli szczegółowych Śledzenie źródła modelu Rys. 5.3. Proces wytwarzania oprogramowania w oparciu o model (MDD) w narzędziu Rational Software Modeler. Źródło: opracowanie własne na podstawie [2, s.1-6]. Poszczególne modele tworzone za pomocą RSM wykorzystywane mogą być przez osoby pełniące różne role w projekcie. Przykładowo, inżynier systemów może zanalizować architekturę czy wydzielić podsystemy, a również stworzyć model wstępnego wdrożenia. Z kolei architekt może przekształcić stworzony przez analityka model przypadków użycia w projekt systemu niezależny od środowiska implementacji. Ten zaś model można osadzić już na konkretniej platformie, jaką jest np. Java lub C++. RSM pozwala na uszczegóławianie modeli powstających w kolejnych etapach tworzenia systemu z zachowaniem możliwości śledzenia zależności pomiędzy kolejnymi modelami, dzięki czemu możliwe jest przejście w modelu od ogółu do szczegółu. W celu wydajniejszej pracy RSM oferuje tzw. perspektywy zestaw pasków narzędziowych i okien z dostępem do funkcjonalności typowych dla wybranych zadań. Jako że RSM może stanowić element większego środowiska programistycznego, poza perspektywą modelowania oferuje także zestawy widoków dla programistów Javy, testerów czy zbierania wymagań. Decydując się na perspektywę modelowania i tworząc nowy projekt UML, użytkownikowi udostępniane są standardowo wzorce kilku modeli (Rys. 5.4): analityczny wspierający profil proces inżynierii, zawierający zestaw wzorcowych pakietów i diagramów, projektowania IT przedsiębiorstwa ułatwia modelowanie usług oraz przekształcanie projektu w kod programu, szczególnie przy tworzeniu aplikacji biznesowych, przypadków użycia zgodnie z nazwą wspiera głównie modelowanie interakcji aktorów z systemem,
Błąd! Nie można odnaleźć źródła odwołania.. Wybrane metody i narzędzia modelowania systemów informatycznych z użyciem języka UML 7 projektowania usług związany z wdrożeniem i ponownym wykorzystaniem elementów, pusty bez zdefiniowanych diagramów, stereotypów czy pakietów. Rys. 5.4. Perspektywy oraz wzorce modeli UML dostępne w narzędziu Rational Software Modeler. Źródło: okna aplikacji RSM 7.0. W ramach modeli RSM umożliwia tworzenie kilku typów diagramów UML: klas, struktur złożonych, komponentów, wdrożenia, obiektów, przypadków użycia, czynności, stanów, sekwencji, komunikacji, swobodny, pozwalający umieszczać elementy z różnych typów diagramów. Stosowane w wersji RSM 7.0 diagramy UML są zgodne ze specyfikacją 2.1. Co prawda elementy różnią się od oficjalnej specyfikacji większą plastycznością form, ale nie utrudnia to interpretacji modelu. Tworzenie modelu odbywa się wizualnie, poprzez umieszczanie elementów w obszarze roboczym diagramu oraz łączeniu odpowiednimi relacjami. Wówczas RSM automatycznie dodaje takie elementy do struktury modelu widocznej w oknie eksploratora projektu (Rys. 5.5).
8 A. Czarnecki Rys. 5.5. Główne okno projektu w RSM z przykładowym diagramem klas. Źródło: aplikacja RSM 7.0. Każdy z elementów modelu charakteryzowany jest przez zbiór własności, czy to charakterystycznych dla niego (jak atrybuty i operacje dla klas), czy też dostępnych praktycznie dla każdej części projektu. Taką powszechną własnością jest pole przeznaczone na dokumentację. Konsekwentnie wypełnianie tego typu pól znacznie ułatwia zarządzanie przedsięwzięciem, zwłaszcza gdy model przechodzi od autora do kolejnego członka zespołu. Dodatkowym ułatwieniem dla tworzącego modele w RSM jest umieszczenie w aplikacji zbioru wzorców projektowych zaproponowanych przez Gammy, Helma, Johnsona i Vlissidesa [3], a podzielonych na: konstrukcyjne, strukturalne i czynnościowe. RSM ma możliwość walidacji tworzonych modeli. Formalne sprawdzenie kończy się raportem zawierającym ewentualne błędy, ostrzeżenia oraz inne komunikaty. Ważne jest, że RSM jako moduł Rational Development Platform oferuje przekształcanie modeli na zręby kodu (Java, Enterprise Java Beans i C++). Możemy zatem mówić tu o funkcjonalności tzw. inżynierii wprzód. W środowisku Rational dostępna też jest odtworzenie modelu na podstawie kodu, czyli inżynieria wstecz. Oczywiście, współczesne środowiska wytwarzania oprogramowania nie mogą się obejść bez wsparcia dla pracy grupowej. RSM na etapie samego modelowania pozwala na podział modelu na mniejsze fragmenty, które mogą być tworzone przez wielu członków zespołu, a następnie łączone. Natomiast funkcjonalność inżynierii wprzód pozwala przejść z modelu stworzonego przez analityka do ramowego kodu, który rozwijać będzie dalej programista. Tworzony kod można następnie konfrontować (np. w ramach formalnych przeglądów) z wytycznymi architektury systemu. Firma IBM zapewnia dla RSM, jak i całego środowiska Rational pomoc w postaci dostępnej on-line dokumentacji (m.in. tzw. Czerwonych Ksiąg) oraz szkoleń.
Błąd! Nie można odnaleźć źródła odwołania.. Wybrane metody i narzędzia modelowania systemów informatycznych z użyciem języka UML 9 Z punktu widzenia doboru narzędzi ważna jest także ich cena. Na polskim rynku IBM oferuje pięć rodzajów licencji na aplikację Rational Software Modeler w cenie od 1 045 do 3 357 euro. 5.6. Podsumowanie Rozdział miał na celu pokazanie, jak idea połączenia sił trójki osób dała możliwość rozwoju dużego środowiska służącego wytwarzaniu oprogramowania. Skupiono się tu na języku UML, metodyce RUP oraz narzędziu RSM. Pominięto opisywanie innych aplikacji wywodzących się spod marki Rational, jak na przykład Rational Software Architect, by zaprezentować zagadnienie modelowania, nie wchodząc już w obszar typowo deweloperski. Charakteryzując aplikację Rational Software Modeler wymieniono zwrócono uwagę na kilka cech, m.in. zgodność ze specyfikacją UML i RUP, rodzaje wspieranych typów diagramów, funkcje inżynierii wprzód i wstecz (oraz języków programowania, dla jakich jest ona dostępna), dostępne wsparcie techniczne czy wreszcie cena zakupu licencji. Warto przyjrzeć się innym dostępnym na rynku narzędziom modelowania i, opierając się na wspólnym modelu oceny, porównać je ze sobą. Bibliografia [1] UML Resource Page. http://www.uml.org/ [2] DEV399 Essentials of IBM Rational Software Modeler of Systems Development. Student Guide. Version v1.0. Rational University. International Business Machines Corporation, 2006. [3] Gamma E., Helm R., Johnson R., Vlissides J.: Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, Reading (USA:MA), 1995. [4] DEV275 Essentials of Visual Modeling with UML. Student Guide. Version 2004.02. Rational University. International Business Machines Corporation, 2005. [5] Péraire C., Edwards M., Fernandes A., Mancin E., Carroll K.: The IBM Rational Unified Process for System z. International Technical Support Organization. International Business Machines, 2007.
10 A. Czarnecki {Odrębna strona streszczeń i adresów} Zarządzanie technologiami informatycznymi Przykłady technologii informatycznych i ich zastosowanie A. Czarnecki* *Politechnika Gdańska, Wydział Zarządzania i Ekonomii, Zakład Zarządzania Technologiami Informatycznymi, e-mail: adam.czarnecki@zie.pg.gda.pl Rozdział 5. Wybrane metody i narzędzia modelowania systemów informatycznych z użyciem języka UML. Rozdział prezentuje przykład technologii modelowania systemów informatycznych opartej na podejściu obiektowym w jednolitym środowisku, począwszy od Zunifikowanego Języka Modelowania (UML), poprzez metodykę Rational Unified Process (RUP), po aplikację Rational Software Modeler (RSM). IT Management Examples of Information Technologies and Their Applications A. Czarnecki* *Gdańsk University of Technology, Faculty of Management and Economics, Department of the Information Technologies Management, e-mail: adam.czarnecki@zie.pg.gda.pl Chapter 5. Methods and Tools for IT UML-Driven System Development. The chapter presents an example of the object-oriented IT modeling technology based on the common environment consisting of the Unified Modeling Language (UML), the Rational Unified Process (RUP) methodology and the software application - Rational Software Modeler (RSM).