UML(1), Inżynieria oprogramowania

[ 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 ]

  • zanotowane.pl
  • doc.pisz.pl
  • pdf.pisz.pl
  • emaginacja.xlx.pl

    •