|
[ Pobierz całość w formacie PDF ]
V Konferencja PLOUG Zakopane Październik 1999 Język UML Kazimierz Subieta Instytut Podstaw Informatyki PAN, Warszawa Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa Streszczenie UML (Unified Modeling Language), zunifikowany język do modelowania, jest następcą i syntezą notacji występujących w obiektowych metodykach analizy i projektowania systemów informatycznych, które pojawiły się w końcu lat 80-tych i na początku lat 90-tych. Jest on oparty o pojęcia obiektowości, takie jak obiekty, klasy, atrybuty, związki, agregacje, dziedziczenie, metody i inne. UML powstał w wyniku połączonych wysiłków trzech znanych metodologów: Grady Boocha, Ivara Jacobsona i Jamesa Rumbaugh'a. Są oni autorami popularnych metodyk: OODA (Booch), Objectory (Jacobson) i OMT (Rumbaugh). UML jest zestawem pojęć oraz notacji graficznych (diagramów), które pozwalają wszechstronnie odwzorować modelowaną dziedzinę problemu, założenia projektowanego systemu informatycznego, oraz większość istotnych aspektów jego konstrukcji. UML jest obecnie wspomagany przez wiele narzędzi CASE. Został on także zaakceptowany jako przemysłowy standard przez ciało standardyzacyjne OMG rozwijające standard CORBA. Artykuł wprowadza w motywacje i cele UML oraz objaśnia na przykładach podstawowe pojęcia, notacje i zastosowania UML. 1 Wstęp Wzrost popularności obiektowości w informatyce spowodował prawdziwą eksplozję metodyk i notacji określanych jako „obiektowe”, wśród nich: BON, Catalysis, DOOS (Wirfs/Brock), EROOS, Express, Fusion, Goldberg/Rubin, MainstreamObjects, Martin/Odell, MOSES, Objectory (Jacobson), OMT (Rumbaugh), OOA/OOD (Coad/Yourdon), OOAD (Booch), OSA, Sintropy, OOSA (Shlaer/Mellor) i inne [Booc94, CoYo91a, CoYo91b, Cole+94, GoRu95, Jaco92, MaOd91, MaOd94, MaOd96, Mart93, Meye97, Rumb+91, Your+95]. Mimo różnic zarówno w podejściu jak i w przeznaczeniu, metodyki te mają ze sobą wiele wspólnego. Dość powszechne stało się odczucie, że różnice pomiędzy notacjami wprowadzanymi w tych metodykach są drugorzędne. UML ma (w założeniu) dokonać unifikacji notacji używanych w istniejących metodykach. W odróżnieniu od metodyk obiektowych, które oprócz notacji ustalają także postępowanie w każdej fazie projektu, UML jest tylko zestawem pojęć i notacji. Może on być użyty do dowolnej metodyki. Zdaniem autorów, UML swoim zakresem przykrywa większość elementów i faz procesów analizy i projektowania. UML jest dziełem trzech znanych metodologów: Grady Booch’a, Ivara Jacobsona i James’a Rumbaugh’a (określanych w literaturze jako „ three amigos ”, trzej przyjaciele), w ramach firmy Rational Software Corporation. Są oni autorami popularnych metodyk: OMT [Rumb+91] (głównym autorem był J.Rumbaugh), OODA [Booc94] (autorem był G.Booch) oraz Objectory [Jaco92] (głównym autorem był I.Jacobson). Celem ich wysiłków jest uzyskanie popularności wybranej przez nich notacji i przez to opanowanie znacznej części rynku narzędzi CASE, szkoleń, analiz, ekspertyz, projektów, konsultacji, itd. Szanse rynkowe UML zostały wzmocnione poprzez zaakceptowanie go jako przemysłowego standardu przez ciało standardyzacyjne OMG ( Object Management Group ) opracowujące standard CORBA [OMG95]. Pierwsze wersje (UML 0.8-0.91) datują się na lata 1995-1996. W styczniu 1997 powstała wersja UML 1.0 [UML97], która została przesłana do OMG. Wersja UML 1.1, powstała w końcu 1997, została zatwierdzona jako składnik standardu OMG. Wersja UML 1.3 ukazała się w kwietniu 1999. Obecnie mówi się o wersji UML 1.4. Ponadto autorzy UML pracują nad zunifikowaną metodyką analizy i projektowania [Kruc98, JBR99]. UML jest przedmiotem ogromnej ilości książek, artykułów, stron WWW i innych materiałów, patrz np. [BJR98, Cant98, DoHu98, DSWi98, FSJ97, Laem97, Mull99, OdFo98, Oest99, RoSc99, RJB99, Subi98, UML97, WaKl99]. Słowniki [FiEy95, Subi99] wyjaśniają znaczenia terminów i pojęć obiektowości, które leżą u podstaw UML. Podstawowym celem UML jest modelowanie systemów (nie tylko oprogramowania) z użyciem pojęć obiektowych. UML jest notacją pośrednią, pomostem pomiędzy ludzkim rozumieniem struktury i działania programów, a kodem programów. Taka notacja jest niezbędna do specyfikacji, konstrukcji, wizualizacji i dokumentacji wytworów związanych z systemami intensywnie wykorzystującymi oprogramowanie. Diagramy UML ustanawiają bezpośrednie powiązanie elementów modelu pojęciowego z wykonywalnymi programami. Jednocześnie umożliwiają one objęcie zagadnień związanych ze skalą problemu, towarzyszących złożonym systemom o krytycznej misji. Ideałem byłoby utworzenie języka do modelowania użytecznego zarówno dla ludzi jak i maszyn, czyli czegoś w rodzaju super-języka programowania, który z jednej strony byłby całkowicie adekwatny w stosunku do ludzkiej percepcji, zaś z drugiej strony, mógłby być użyty do automatycznej generacji programów. W związku z tym (zdaniem autorów UML) prace nad konstrukcją UML nie są istotnie różne od zaprojektowania nowego języka programowania. Można jednak mieć sceptyczny stosunek do tego rodzaju zapowiedzi. UML jest przede wszystkim językiem odwołującym się do ludzkiej percepcji i wyobraźni. Uczynienie z niego języka algorytmicznego wymagałoby m.in. precyzji w specyfikacji struktur danych oraz środków manipulacji tymi strukturami danych, co nieuchronnie prowadziłoby do znacznego zmniejszenia czytelności diagramów, czyli zmniejszenia potencjału UML jako środka modelowania 2 pojęciowego. Uwzględnienie w jednym języku zarówno wymagań dotyczących naturalności, poglądowości i wysokiego poziomu abstrakcji niezbędnego dla ludzi zajmujących się projektem, jak i wymagań dotyczących algorytmicznej precyzji niezbędnej dla komputera, wydaje się nieosiągalne. Zgodnie z deklaracjami autorów, UML przykrywa wszystko to, co może być zrobione przy pomocy istniejących metodyk. Jak można się domyśleć, to twierdzenie ma podłoże marketingowe i nie jest ani do udowodnienia, ani do obalenia, gdyż bazuje na subiektywnych odczuciach. (Autorzy innych metodyk są często innego zdania.) Wysiłek autorów UML jest skoncentrowany na stworzeniu wspólnego meta-modelu (unifikacji semantyki) i wspólnej notacji (odbioru tej semantyki przez ludzi). Promowany jest iteracyjny i przyrostowy proces rozwoju oprogramowania, który jest napędzany przez przypadki użycia ( use cases ) i skoncentrowany na koncepcyjnej architekturze projektowanego systemu. Zdaniem autorów, UML przykrywa także projektowanie systemów współbieżnych i rozproszonych. 2 Diagramy definiowane w UML Ze względu na mnogość aspektów projektowanych systemów żadna pojedyncza perspektywa spojrzenia na projektowany system nie jest wystarczająca. Tę sytuację można porównać do projektu złożonego mechanizmu. Pojedynczy rzut tego mechanizmu na jedną płaszczyznę nie jest wystarczający do zrozumienia jego budowy; potrzebne jest wiele rzutów i przekrojów. Stąd metodyki projektowania wprowadzają wiele środków graficznych (diagramów) służących do „rzutowania” analizowanego lub projektowanego systemu na pewien szczególny jego aspekt. W notacji UML można zapisać następujące diagramy: ¾ Diagramy przypadków użycia ( use case ). Są one podstawą metodyki Objectory. Ich głównym celem jest odwzorowanie funkcji projektowanego systemu w taki sposób, w jaki będą je widzieć jego użytkownicy. W metodykach opartych na UML przypadkom użycia przypisuje się szczególne znaczenie jako środka napędzającego cały proces rozwoju systemu. ¾ Diagramy klas ( class diagrams ). Są one odmianą dość klasycznych diagramów encja-związek ( entity-relationship ). Zostały praktycznie bez większych zmian przejęte z OMT. Wprowadzone są rozszerzenia poprawiające czytelność diagramów i przystosowujące je do konkretnej dziedziny zastosowań (np. stereotypy i odpowiadające im ikony). Odmianą diagramów klas sa diagramy pakietów ( package diagrams ). ¾ Diagramy odwzorowujące dynamiczne własności systemu ( behavior ), w tym: • Diagramy sekwencji (szczególny przypadek diagramów interakcji): pokazanie kolejności komunikatów przesyłanych pomiędzy obiektami dla pewnej sytuacji, np. przypadku użycia. • Diagramy współpracy ( collaboration ) (szczególny przypadek diagramów interakcji): podobne do diagramów sekwencji, ale z jednoczesnym odwzorowaniem statycznej struktury obiektów. • Diagramy stanów : odwzorowanie istotnych stanów (w których może znaleźć się proces przetwarzania) oraz przejść pomiędzy tymi stanami. Diagramy aktywności : diagramy przepływu sterowania ( flowcharts ) uzupełnione o proste środki odwzorowania równoległych procesów. ¾ Diagramy implementacyjne , w tym: • • Diagramy komponentów Diagramy wdrożeniowe ( deployment ) Ze względu na ograniczoną objętość tego artykułu omówione zostaną tylko niektóre z wymienionych diagramów. • 3 1.1 Przypadki użycia Przypadki użycia ( use cases ) [Jaco92, RoSc99, SWJ98] były w sposób intuicyjny stosowane w tradycyjnym projektowaniu systemów informatycznych na długo przed pojawieniem się metodyk obiektowych. Zasługą Jacobsona jest zarówno wyodrębnienie przypadków użycia jako metody projektowania, jak i stworzenie metodyki i notacji graficznej dla tego paradygmatu. Jak często bywa z powszechnie stosowanymi, lecz nie nazwanymi rzeczami, kariera przypadków użycia w literaturze z zakresu projektowania SI zaczęła się od wprowadzenia dla nich specjalnej nazwy, przypisaniu tej nazwie określonego znaczenia i rozpropagowanie tego pojęcia jako specjalnego paradygmatu projektowania. Przypadek użycia jest to pewna nazwana lub dobrze określona interakcja pomiędzy użytkownikiem a systemem komputerowym. Przypadek użycia odwzorowuje pewną funkcję systemu w taki sposób, w jaki będą ją widzieć jego przyszli użytkownicy. Jakkolwiek w tym stwierdzeniu można podejrzewać banał, rzecz tak oczywistą, że nie warto o niej mówić, okazuje się, że dla dużych systemów o wielu złożonych i wzajemnie powiązanych funkcjach tego rodzaju podejście ma ogromny sens. Pozwala ono zapomnieć o strukturze/architekturze systemu i jego detalach technicznych i skoncentrować się na zewnętrznych funkcjach systemu. Podejście do projektowania od strony przypadków użycia jest uważane za znacznie bardziej zdrowe od podejść „technokratycznych”, ponieważ sprzyja ono punktowi widzenia, w którym centralnym ośrodkiem zainteresowania staje się człowiek - przyszły użytkownik systemu - a nie budowa mechanizmu systemu. Jak pokazały doświadczenia wielu projektów, jedną z głównych przyczyn ich niepowodzeń było zbytnie skoncentrowanie się projektantów na detalach technicznych, z pominięciem lub brakiem dostatecznej uwagi dla interakcji pomiędzy użytkownikami a systemem komputerowym. Podejście przypadków użycia ma przede wszystkim na względzie określenie wymagań na projektowany system. Celem tej metody jest: ¾ Głębsze zrozumienie użycia systemu będącego przedmiotem procesu projektowania. ¾ Zwiększenie stopnia świadomości analityków i projektantów co do celów tego systemu. ¾ Umożliwienie interakcji zespołu projektowego z przyszłymi użytkownikami systemu. ¾ Weryfikacja poprawności i kompletności projektu. ¾ Ustalenie wszystkich strukturalnych i funkcjonalnych własności systemu. ¾ Ustalenie składowych systemu i związanego z nimi planu konstrukcji systemu. ¾ Dostarczenie podstawy do sporządzenia planu testów systemu. Diagramy przypadków użycia są bardzo proste. Rys.1 przedstawia diagram przypadków użycia dla pewnej (hipotetycznej) firmy zajmującej się pośrednictwem w sprzedaży. Ustalenie limitów Aktualizacja rozliczeń Dyrektor handlowy System rozliczeniowy Analiza ryzyka «uses» Wyliczenie ocen Sprawy cenowe «uses» Handlowiec Ocena zysków «extends» Sprzedawca Przekroczenie limitów Rys.1. Przykładowy diagram przypadków użycia 4 Model przypadków użycia dostarcza bardzo abstrakcyjnego poglądu na system z pozycji aktorów, którzy go używają. Nie włącza jakichkolwiek szczegółów, co pozwala wnioskować o systemie na odpowiednio ogólnym, abstrakcyjnym poziomie. Diagram przypadków użycia zawiera znaki graficzne oznaczające aktorów (ludziki) oraz przypadki użycia (owale z wpisanym tekstem). Te oznaczenia połączone są liniami odwzorowującymi powiązania poszczególnych aktorów z poszczególnymi przypadkami użycia. Podstawowym zastosowaniem takich diagramów jest dialog z użytkownikami zmierzający do sformułowania wymagań na system. Stąd wynika, że diagramy i opis przypadków użycia muszą być bardzo naturalne, proste i nie mogą wprowadzać elementów komputerowej egzotyki i żargonu. W późniejszej fazie przypadki użycia mogą być wyspecyfikowane bardziej precyzyjnie przy pomocy notacji lub diagramów obiektowych. Następną fazą w postępowaniu opartym na przypadkach użycia jest rozpisanie ich przy pomocy notacji wprowadzanych w innych diagramach UML. Należy podkreślić, że tworzenie przypadków użycia jest niezdeterminowane i subiektywne. Na ogół różni analitycy tworzą różne modele. Metoda przypadków użycia wymaga od analityka określenia wszystkich aktorów związanych w jakiś sposób z projektowanym systemem. Każdy aktor używa lub będzie używać systemu na kilka specyficznych sposobów (przypadków użycia). Zazwyczaj aktorem jest osoba, ale może nim być także pewna organizacja (np. biuro prawne) lub inny system komputerowy. Należy zwrócić uwagę, że metoda modeluje aktorów, a nie konkretne osoby. Jedna osoba może pełnić rolę wielu aktorów; np. być jednocześnie sprzedawcą i klientem. I odwrotnie, jeden aktor może odpowiadać wielu osobom, np. strażnik budynku. Aktor jest pierwotną przyczyną napędzającą przypadki użycia. Jest on sprawcą zdarzeń powodujących uruchomienie przypadku użycia, jak też odbiorcą informacji wyprodukowanych przez przypadki użycia. Aktor reprezentuje rolę, którą może grać w systemie jakiś jego użytkownik, np. kierownik, urzędnik, klient. Można tworzyć aktorów abstrakcyjnych, na podobieństwo klas abstrakcyjnych. Np. aktor „urzędnik” jest nadklasą dla aktorów „kasjer” i „dyrektor”; powiązania z konkretnymi przypadkami użycia mogą być ustalone zgodnie z tą hierarchią klas aktorów. Przypadek użycia reprezentuje sekwencję operacji lub transakcji wykonywanych przez system w trakcie interakcji z użytkownikiem; np. potwierdzenie pisma, złożenie zamówienia. Przypadki użycia reprezentują przepływ zdarzeń w systemie i są uruchamiane (inicjowane) przez aktorów. Przypadek użycia jest zwykle charakteryzowany przez krótką nazwę. Opis przypadku użycia może być jednak dowolnie rozbudowany, w szczególności może zawierać następujące fragmenty: ¾ Jak i kiedy przypadek użycia zaczyna się i kończy? ¾ Opis interakcji przypadku użycia z aktorami, włączając w to kiedy interakcja ma miejsce i co jest przesyłane. ¾ Kiedy i do czego przypadek użycia potrzebuje danych zapamiętanych w systemie, lub jak i kiedy zapamiętuje dane w systemie? ¾ Wyjątki przy przepływie zdarzeń. ¾ Jak i kiedy używane są pojęcia dziedziny problemowej? UML wprowadza także bardzo proste powiązania pomiędzy przypadkami użycia, oznaczane strzałkami dodatkowymi napisami «extends» (rozszerza) i «uses» (używa), Rys.1. Przypadek użycia podłączony przez strzałkę «extends» oznacza, że niekiedy (nie zawsze) dany przypadek użycia jest rozszerzony przez inny przypadek użycia. Przypadek użycia podłączony przez strzałkę «uses» oznacza wspólny fragment w wielu przypadkach użycia, który warto jest wyodrębnić ze względu na jego podobieństwo koncepcyjne oraz ze względu na późniejszą możliwość uniknięcia wielokrotnej implementacji tego fragmentu. Taki fragment jest niekiedy określany jako blok ponownego użycia ( reuse ). Typowa dokumentacja przypadków użycia powinna zawierać następujące elementy: ¾ Krótki opis przypadku użycia. ¾ Przepływ zdarzeń opisany nieformalnie. ¾ Związki pomiędzy przypadkami użycia. 5 [ Pobierz całość w formacie PDF ] |
Wątki
|