pobierz plik referatu

Transkrypt

Rozdział monografii: 'Bazy Danych: Rozwój metod i technologii', Kozielski S., Małysiak B., Kasprowski P., Mrozek D. (red.), WKŁ 2008
Rozdział 11
w
Kompleksowe podejście do nauczania języka UML
2.x na uczelniach wyższych
w
da
.b
w
Streszczenie. Wersja 2.x języka UML stanowi jeszcze bardziej złożony
i zróżnicowany zestaw technik notacyjnych, niż miało to miejsce we wcześniejszych wersjach. Tym samym twórcy systemów informatycznych zaproponowali formalne wprowadzenie jego uproszczonej wersji, zwanej wersją
Light, “lekką”, „minimalną” lub „szybką”. Zagadnienie to stało się zarazem
poważnym wyzwaniem dla środowisk akademickich. Celem niniejszego rozdziału jest wyspecyfikowanie zakresu wersji Light języka UML 2.x na podstawie doświadczenia dydaktycznego, wspartego wynikami ankiety. Pozwoliło to na aktualizację i reorientację dotychczas stosowanego programu nauczania języka UML w zastosowaniach bazodanowych zgodnie z wynikami badania i wnioskami, zaprezentowanymi w końcowej części niniejszego rozdziału. Rozdział składa się z czterech podrozdziałów. Po wprowadzeniu zaprezentowano założenia metodologiczne dotychczas stosowanego programu nauczania języka UML. W kolejnej części zaprezentowano uwarunkowania
oraz wyniki badania ankietowego. Rozdział zamykają wnioski, ściśle związane z modyfikacjami, poczynionymi w dotychczas stosowanym programie
nauczania języka UML. Treść niniejszego rozdziału oparto na doświadczeniach uczelni wyższych w Gdańsku, zebranych w ramach wykładów i laboratoriów, wspieranych studiami przypadków, narzędziami CASE i treściami elearningowymi – jak również opiniach 180 studentów wspomnianych uczelni.
pl
s.
1 Wprowadzenie
Język UML (Unified Modeling Language), zaproponowany przez (Boocha, Jacobsona
i Rumbaugh, 1998, 1999, 2004), przyciągnął uwagę zarówno środowisk akademickich, jak
również praktyków w środowisku analityków i projektantów systemów informatycznych.
Specyfikacje języka UML pozwalają na dokumentowanie systemu informatycznego w kategoriach przypadków użycia, ich scenariuszy, klas, interakcji oraz innych diagramowych
kategorii notacyjnych, wybranych do tego celu spośród aktualnego zbioru 13 typów diagramów języka UML w wersji 2.1. Jak zasygnalizowano w popularnych podręcznikach, takich
jak (Ambler, 2005), (Dennis, 2005), (Eriksson i in., 2004), (Fowler, 2004), (Pilone, 2004)
i (Wrycza i in., 2005), narzędzie to sprawdza się w modelowaniu znacznego zakresu rozStanisław Wrycza, Bartosz Marcinkowski
Uniwersytet Gdański, Katedra Informatyki Ekonomicznej, ul. Piaskowa 9, 81-864 Sopot, Polska
email:{swrycza, bmarc}@univ.gda.pl
(c) Copyright by Politechnika Śląska, Instytut Informatyki, Gliwice 2008
S. Wrycza, B. Marcinkowski
w
wiązań z zakresu tworzenia systemów informatycznych, odpowiadających potrzebom gospodarki opartej na wiedzy. Standard jest nieustannie monitorowany, rozwijany, modyfikowany i ulepszany przez organizację OMG (Object Management Group). W rzeczy samej,
wersje 2.0 (OMG, 2005) i 2.1 (OMG, 2006) języka UML są repozytoriami zróżnicowanych
technik, które – w połączeniu z procesem tworzenia systemu – tworzą kompletną platformę
metodologiczną, służącą rozwojowi docelowego systemu.
UML jest nie tylko ugruntowanym standardem w dziedzinie oprogramowania, lecz również najpopularniejszym językiem w nauczaniu inżynierii oprogramowania, a w szczególności analizy i projektowania systemów informatycznych na różnych poziomach studiów
akademickich (Dennis, 2005). W rzeczy samej, na przestrzeni kilku ostatnich lat, zagadnienia związane z UML zdominowały dydaktykę w dziedzinie. Podejście to jest również intensywnie rozwijane w zakresie możliwości opisu baz danych, co przejawia się m. in. Licznością stereotypów, proponowanych w kontekście diagramu klas. Wzrost zainteresowania
językiem spowodował jego rozpowszechnianie w sylabusach specjalności informatycznych, a opisana tendencja doprowadziła do wymiany poglądów nt. efektywnych metod
nauczania UML pomiędzy wykładowcami i trenerami kursów z zakresu tworzenia systemów informatycznych. Język stał się zarówno wyzwaniem zawodowym, jak i niezbędnym
elementem wiedzy współczesnego analityka i projektanta systemów informatycznych.
Ostatnia znacząca rewizja języka, tj. UML 2.0, stała się w związku z tym istotnym komponentem profilu absolwenta specjalności Informatyka ekonomiczna i wywarła daleko idący
wpływ na umiejętności zawodowe i podejście przyszłych projektantów oprogramowania
i twórców baz danych.
UML 2.x jako całość jest złożonym składniowo i semantycznie językiem graficznym,
a – co za tym idzie – poważnym wyzwaniem w nauczaniu analizy i projektowania systemów informatycznych. Z drugiej strony, ani zastosowania biznesowe ani praktyczne studia
przypadków, stosowane w nauczaniu modelowania systemów, nie wykorzystują całego,
zróżnicowanego instrumentarium języka UML 2.x. Wprost przeciwnie – wydaje się, że także w tym przypadku znajduje zastosowanie reguła metodologiczna “20 - 80”, stanowiąca,
że 20% kategorii UML wystarcza w 80% zastosowań. Pozostałe 80% kategorii modelowania UML wykorzystuje się z silnie zróżnicowaną częstotliwością. Obie te przesłanki skłoniły badaczy do zaproponowania zwięzłych wersji UML, określanych mianem minimUML
(Turner, 2006), minimalUML (DeLooze, 2005), QuickUML (Alphonce, 2006) czy wreszcie LightUML (Wrycza i Marcinkowski, 2006). Większość wykładowców UML podkreśla
ponadto kwestię złożoności języka oraz różnorodności jego kategorii modelowania.
Kwestie te klasyfikowane są jako problemy o fundamentalnym znaczeniu z punktu widzenia procesu nauczania. Wersje uproszczone zwykle poleca się jako podstawowy element
kursów wprowadzających w tematykę tworzenia systemów informatycznych, podczas gdy
wersję kompletną – uczestnikom studiów na poziomie magisterskim. Niektórym wersjom
uproszczonym dedykowano oddzielne narzędzia CASE, przy jednoczesnej powszechnej
dostępności pakietów open-source, charakteryzujących się posiadaniem raczej ograniczonej
funkcjonalności.
Na podstawie rzeczywistych projektów oraz doświadczenia dydaktycznego można
stwierdzić, iż jedynie wybrane elementy kompletnego potencjału języka UML znajdują
zastosowanie w cyklu życia systemu. Autorzy notacji uproszczonych zazwyczaj proponują
ograniczony zestaw diagramów UML wraz ze zbiorem odpowiednich kategorii pojęciowych, przypisywanych do tych diagramów – zazwyczaj pojęć, które zdaniem autorów są
najbardziej istotne w dydaktyce i osiąganiu celów w praktycznych projektach.
Znaczną liczbę argumentów za wyszczególnieniem podzbioru UML sformułowali
(LeBlanc and Stiller, 2000) już w odniesieniu do wersji 1.x języka UML, która to wersja
była zasadniczo bardziej zwięzła i zawierała zarówno mniej diagramów, jak i kategorii mo-
da
.b
w
w
pl
s.
138
Kompleksowe podejście do nauczania języka UML 2.x na uczelniach wyższych
w
delowania, dostępnych w odniesieniu do każdego z diagramów. Zasugerowali oni skupienie
się na przekazaniu najbardziej istotnych języka UML, aby uniknąć „przytłoczenia” studentów na poziomie licencjackim mnogością wysublimowanych możliwości notacyjnych.
Autorzy zasugerowali utworzenie rdzenia języka, prostego w zrozumieniu i przyswojeniu –
ze względu na włączenie do niego jedynie podstawowych diagramów, takich jak diagramy
przypadków użycia, klas, obiektów, sekwencji i komunikacji.
(Burton i Bruhn, 2003) uogólnili własne doświadczenia w stosowaniu UML i podkreślili
rolę stosowania narzędzi CASE w nauczaniu UML. Ich zdaniem narzędzia te stanowią
istotny czynnik w stymulowaniu aktywnego zaangażowania studentów w procesie nauczania. Pozwalają one także na dostosowanie elementów dokumentacji do indywidualnych
potrzeb użytkownika poprzez łatwe wprowadzanie stereotypów. Pomimo, iż autorzy proponują włączenie kilku typów diagramów do wersji „minimalnej”, ich prace koncentrują się
na diagramach klas, przy relatywnie szerokim zakresie funkcjonalności notacyjnej.
Z kolei (Flint, Gardner i Boughton, 2004) wskazują na szereg problemów, związanych
z nauczaniem UML. Także oni formułują wniosek, że zastosowanie jasno zdefiniowanych
podzbiorów UML jest łatwiejsze do przyswojenia niż posługiwanie się pełną składnią języka. Autorzy wykorzystują diagramy klas, maszyny stanowej, komunikacji oraz sekwencji,
definiując tym samym wersję UML, określaną jako „wykonywalną/transformowalną”.
Koncepcję minimalnego zestawu diagramów proponował także (DeLooze, 2005). Stosował on UML w projektowaniu i wdrożeniu aplikacji webowej w ramach kursu edukacyjnego. Proces modelowania wykonywany był w zgodzie z cyklem życia systemu. Autor wyszczególnił cztery fazy, w których wprowadzane były odpowiednie diagramy:
− fazę planowania (Planning) – diagramy przypadków użycia;
− fazę analizy (Analysis) – diagramy sekwencji oraz analityczne diagramy klas;
− fazę projektowania (Design) – projektowe diagramy klas;
− fazę implementacji (Implementation) – kodowanie.
(DeLooze, 2005) podkreślił również problem dążenia przez studentów do realizacji kodowania przed przeprowadzeniem obiektowej analizy i projektowania systemu.
Najbardziej wyczerpujące rozważania, dotyczące uproszczonego podejścia w tworzeniu
dokumentacji względem UML w podstawowych kursach informatycznych, zawarto w pracy (Turner i in., 2005). Autorzy dokonali oszacowania pięciu pakietów UML pod kątem ich
przydatności dydaktycznej. Podstawowymi kryteriami oceny była łatwość w użytkowaniu
w stosunku do umiejętności studentów. Zdaniem autorów, do rozwiązania potencjalnych
problemów, pojawiających się przed studentem, potrzeba bardzo niewielkiego fragmentu
specyfikacji UML. Tym samym koncepcja minimUML została ograniczona do diagramów
klas. O ile takie ograniczenie wydaje się być daleko przesadzonym, zastosowanie odpowiedniego narzędzia pozwala bezpośrednio przenieść projekty w UML na kod źródłowy
w języku C++ lub Java. Podobne narzędzie, wspierające iteracyjne tworzenie diagramów
klas, proponują (Alphonce i Ventura, 2003). Narzędzie umożliwia ponadto dokonanie inżynierii zwrotnej poprzez przekształcenie plików źródłowych w języku Java na diagramy
klas.
Dodatkowo, (Dobing i Parsons, 2006) przeprowadzili badanie wśród 171 praktyków
UML. Badanie to było ukierunkowane na zawężenie specyfikacji języka.
Wreszcie, (Wrycza i in., 2005) zaproponowali dwa poziomy tworzenia systemów informatycznych – poziom konceptualny oraz wdrożeniowy. Jednocześnie, kategorie pojęciowe
każdego rodzaju diagramu zostały uszeregowane pomiędzy podstawowe a zaawansowane.
Diagramy konceptualne pełnią rolę przyjaznej dla użytkownika, ogólnej specyfikacji systemu, która to specyfikacja służy przede wszystkim przeglądowi przyszłego systemu przez
kadrę zarządzającą, jak również zdefiniowaniu i uszczegółowieniu wymagań systemowych.
Naturalnie, model konceptualny jest przygotowywany z wykorzystaniem podstawowych
da
.b
w
w
pl
s.
139
w
kategorii modelowania. Niniejszy model stanowi punkt wyjścia we wprowadzaniu kategorii
zaawansowanych, dzięki czemu stopniowo dochodzi się do modelu wdrożeniowego, wykorzystując i rozwijając umiejętności zawodowe projektantów systemu i twórców baz danych,
biegłych w semantycznych subtelnościach języka.
Większość propozycji wprowadzenia „minimalnej” lub „lekkiej” edukacyjnej odmiany
języka UML opiera się na konkretnej podstawie metodologicznej i/lub doświadczeniu dydaktycznym autorów oraz ich obserwacjach. (Turner i in., 2005) oraz (Wrycza
i Marcinkowski, 2006) zastosowali ponadto wyczerpujące badania ankietowe wśród uczestników kursów UML.
Jak zaznaczono wcześniej, nie występuje wspólne stanowisko autorów w zakresie zawartości uproszczonej wersji UML, a wymienione propozycje są niezależne od siebie
i stronnicze. Przeprowadzony powyżej przegląd propozycji potwierdza tezę, iż tempo uaktualniania i modyfikowania UML – jak również złożoność tego języka i potencjalne trudności początkujących użytkowników, wynikające z tego – zostały niedoszacowane.
Celem niniejszego rozdziału jest wyspecyfikowanie zakresu wersji Light języka UML
2.x na podstawie doświadczenia dydaktycznego, wspartego wynikami ankiety, przeprowadzonej wśród studentów uczelni. Pozwoliło to na aktualizację oraz reorientację dotychczas
stosowanego programu nauczania języka UML zgodnie z wynikami badania i wnioskami,
zaprezentowanymi w końcowej części niniejszego rozdziału. Tym samym, w kolejnym
podrozdziale zaprezentowano wykorzystywany dotychczas program nauczania wraz z jego
podstawami metodologicznymi, a w podrozdziale trzecim – założenia i wyniki badania
ankietowego. Rozdział zamykają wnioski, ściśle związane z modyfikacjami, poczynionymi
w dotychczas stosowanym programie nauczania języka UML.
da
.b
w
w
2 Proces dydaktyczny – założenia metodologiczne
pl
s.
Jak wskazano we wprowadzeniu do niniejszego opracowania, przedstawione przykłady nauczania tworzenia systemów informatycznych oparte zostały na intensywnym wykorzystaniu języka UML i osadzone w szeroko rozumianym podejściu metodologicznym, z reguły
wyszczególniającym stawianie problemu, pracę grupową nad jego rozwiązaniem oraz zastosowanie narzędzi CASE. Podejście takie, różniące się wszakże kwestiami szczegółowymi, zaprezentowano w pracach (Brewer i Lorenz, 2003) oraz (Tabrizi i in., 2004). Sformułowano także oryginalne i niezwykle interesujące propozycje eksperymentalnego nauczania
języka UML w oparciu o ideogramy (Hansen i Ratzer, 2002) oraz skojarzenia (Pavlov
i Yatsenko, 2005).
Istota nauczania języka UML 2.x na Uniwersytecie Gdańskim wynika z doświadczenia
i dostępnej wiedzy w zakresie dydaktyki analizy i projektowania systemów informatycznych (Wrycza i Rybiński, 1993), (Wrycza, 1999), (Wrycza i Marcinkowski, 2006).
Podstawowe założenia tego podejścia obejmują:
− zrozumienie istoty procesów biznesowych i systemowych,
− rozwiązywanie postawionych praktycznych problemów biznesowych,
− nieustanną aktualizację posiadanych zasobów,
− pracę w grupach, zorientowaną na współpracę interpersonalną w zakresie specyfikowania i rozwiązywania problemów (symulacja funkcjonowania rzeczywistych zespołów projektowych),
− silne wsparcie profesjonalnego oprogramowania typu CASE (Computer-Aided
Software Engineering),
− zaangażowanie zasobów e-learningingowych w proces dydaktyczny.
140
w
Założenia wyszczególnione powyżej i odniesione do kursu UML 2 związane są z następującymi obszarami działalności dydaktycznej:
− specyfikacją przypadków użycia (Fowler, 2004), (Jacobson, 1992), (Wrycza i in.,
2005) oraz (Wrycza, 2006);
− udostępnieniem standardów, książek, contentu e-learningowego i innych materiałów, związanych z nauczaniem języka UML, w szczególności specyfikacji języka –
UML 2.0 Superstructure (OMG, 2005) oraz (OMG, 2006);
− doborem składu zespołu w oparciu o testy psychologiczne, identyfikujących zdolności zarządcze, promotorskie, analityczne oraz pomocnicze poszczególnych studentów;
− dostępnością narzędzi CASE, takich jak Sparx Systems Enterprise Architect (Sparx,
2007) bądź, opcjonalnie Rational Rose (Rational, 2001) i jego następcy.
Zakres kursu był nieustannie rozwijany, m. in. poprzez włączenie technik i metodologii
pokrewnych UML, takich jak:
− Modelowanie procesów biznesowych (BPM) (Eriksson i in., 2004);
− Modelowanie analityczne (Jacobson i in., 1992);
− Rational Unified Process (RUP) (Rational, 2001), (Kruchten, 2004).
Wymienione powyżej założenia procesu dydaktycznego oraz zasoby zostały wkomponowane w podejście dydaktyczne, zorientowane na rozwiązywanie problemów [(Polya, 1957)
oraz (Wrycza i Rybiński, 1993)], jak wskazano na rys. 1.
da
.b
w
w
Dokumentacja
systemowa
Weryfikacja
rezultatów
Proces dydaktyczny
Diagramy UML
Dynamika
systemu
Realizacja planu
Struktura
systemu
Narzędzia
CASE
pl
s.
Specyfikacja
wymagań
Planowanie
rozwiązania
Specyfikacja problemu
biznesowego
Analiza sytuacyjna;
Postawienie problemu
Zasoby dydaktyczne
Podręcznik UML 2
Wykłady
e-learning
Pokrewne techniki
obiektowe
Zasoby dydaktyczne
Oficjalna dokumentacja OMG
języka UML 2.0 i 2.1
Rys. 1. Założenia i rezultaty akademickiego kursu języka UML 2.x
141
w
Kluczowym elementem omawianego podejścia jest naturalnie obszerna wiedza w zakresie języka UML, zawarta przede wszystkim w takich publikacjach jak (Booch, Jacobson
i Rumbaugh, 1998, 1999, 2004), jak również (OMG, 2005) oraz (OMG, 2006). Rolę stymulującą pełniły ponadto liczne podręczniki dotyczące UML 2, wymienione wcześniej. Tematyka, oparta na języku UML, została uzupełniona o pokrewne metody, techniki i metodologie obiektowe, takie jak BPM, analiza analityczna oraz RUP. Materiały źródłowe służyły
jako podstawa do autonomicznej działalności dydaktycznej, takiej jak wykłady, autorski
podręcznik kursowy (Wrycza i in., 2005), zestaw studiów przypadku i ćwiczeń (Wrycza,
2006) oraz content e-learningowy. Dzięki niniejszym zasobom dydaktycznym, można było
zainicjować proces dydaktyczny, realizowany w laboratoriach komputerowych. Wszystkie
laboratoria wyposażono w narzędzie CASE – Enterprise Architect, wspomagające proces
nauczania.
Podejście oparto na specyfikacjach studiów przypadków oraz opisach rzeczywistych
problemów i sytuacji, mających miejsce w różnych sektorach biznesu. Powinny one spełniać następujące kryteria:
− nie powinny być nadmiernie uproszczone, a zarazem powinny umożliwiać wypracowywanie różnorodnych wariantów rozwiązań;
− powinny umożliwiać wykorzystanie szerokiego zakresu diagramów języka UML;
− powinny być możliwe do podzielenia na szereg jasno wyspecyfikowanych, indywidualnych zadań, wykonywanych następnie przez poszczególnych członków zespołu
projektowego.
Diagramowa dokumentacja UML 2.0 rozwiązywanych studiów przypadków jest organizowana w oparciu o model architektury 4+1 Kruchtena (Kruchten, 1995), (Kruchten,
2004), jak przedstawiono na rys. 2.
Tym samym, proces tworzenia systemu inicjowany jest w ramach perspektywy przypadków użycia, która to perspektywa jest usytuowana centralnie wobec innych perspektyw.
Istotną rolę w specyfikowaniu wymagań pełnią diagramy przypadków użycia, dokumentacja scenariuszy przypadków użycia – a także modele procesów biznesowych i analityczne.
Wychodząc od wyszczególnionych i szczegółowo udokumentowanych przypadków
użycia, można przygotować wybrane diagramy spośród 12 pozostałych ich rodzajów,
organizując te diagramy w odpowiednie perspektywy. Perspektywy obejmują zarówno
statykę, jak i dynamikę systemu. Szczegółowe diagramy dalszych perspektyw są naturalnie
wspierane przez zastosowane narzędzie CASE.
W rezultacie procesu, przedstawionego na rys. 1, generowana jest dokumentacja konkretnego studium przypadku. Dokumentacja ta jest następnie iteracyjnie dopracowywana,
prezentowana przez grupę oraz oceniana. Proces ten przebiega zgodnie z harmonogramem
wykładów i laboratoriów, wyszczególnionym w tabeli 1. Należy poruszyć najistotniejsze
aspekty systemu, podczas gdy liczba godzin, przeznaczona na przygotowywanie różnych
elementów poszczególnych dokumentacji, jest elastyczna i dostosowywana do charakterystyki danego projektu.
Proces dydaktyczny przebiega w zgodzie z kolejnymi krokami procedury rozwiązywania
problemu: analizą sytuacyjną, planowaniem rozwiązania, realizacją planu i weryfikacją wyników.
Wybrane rozwiązania studiów przypadku, zaprezentowane przez studentów, włączane są
do puli projektów z zakresu UML 2, przechowywanej na platformie e-learningowej.
Zasadnicze zalety zastosowanej metody (rys. 1) są następujące:
− metoda stymuluje studentów do aktywnej i kreatywnej pracy grupowej, jak również
zasadniczo zwiększa wiedzę i umiejętności w zakresie UML;
da
.b
w
w
pl
s.
142
−
−
praca oparta na studiach przypadku daje szansę na symulowanie warunków
praktycznej pracy projektowej i realizowania zadań, na które studenci mogą natrafić
w przyszłej pracy zawodowej;
ogólna wydajność grupy rośnie, gdyż każdy jej członek jest dopingowany
i kontrolowany przez pozostałych członków grupy.
w
Diagram klas
Diagram obiektów
Diagram struktur połączonych
Diagram pakietów
Perspektywa dynamiczna
(ang. Dynamic View)
w
Diagramy interakcji
Diagram czynności
Diagram maszyny stanowej
Diagram pakietów
Perspektywa logiczna
(ang. Logical View)
da
.b
w
Diagram przypadków użycia
Diagramy analityczne
Diagram pakietów
Perspektywa
przypadków użycia
(ang. Use Case View)
Perspektywa komponentów
(ang. Implementation View)
Diagram rozlokowania
Diagram pakietów
pl
s.
Perspektywa rozlokowania
(ang. Deployment View)
Diagram komponentów
Diagram pakietów
Rys. 2. Perspektywy architektury systemu wraz z zalecanymi diagramami
Źródło: (Wrycza i in., 2005)
143
Tabela 1. Wyciąg z sylabusu przedmiotu
Zagadnienie
Liczba godzin
Wykłady
Ćwiczenia
w
1h
Diagram przypadków użycia
3h
Diagramy klas i obiektów
4h
4h, w tym
dokumentacja
scenariuszy PU
2h
Diagram czynności
3h
2h
Diagram maszyny stanowej
2h
1h
Wprowadzenie do diagramów interakcji
1h
Diagram sekwencji
3h
3h
Diagram komunikacji
1h
1h
Diagram harmonogramowania
1h
1h (opcjonalnie)
Diagram sterowania interakcją
1h
1h (opcjonalnie)
Diagramy wdrożeniowe
2h
1h
Diagram pakietów
1h
Proces RUP (Rational Unified Process)
Modelowanie biznesowe z
wykorzystaniem profilu biznesowego
UML
Modelowanie analityczne
2h
2h
Narzędzia CASE
1h
da
.b
w
w
UML – rozwój, struktura, pojęcia
1h
pl
s.
3 Wybrane wyniki badania
1h
Kursy z zakresu języka UML (wersja 2.1, 2.0 i wcześniejsze) są realizowane na Uniwersytecie Gdańskim od 2001 roku. Wypracowane podejście dydaktyczne było aktualizowane
i udoskonalane wraz z każdą kolejną wersją UML. W opracowaniu (Wrycza i Marcinkowski, 2005) zidentyfikowano i przeanalizowano szereg problemów dydaktycznych, wynikających z przeprowadzonego badania. Jednym z podstawowych wniosków, potwierdzający
opinie cytowanych wyżej autorów, jest fakt niemożności przyswojenia przez studentów zasad stosowania pełnego zestawu diagramów UML. Dodatkowo każdy z rodzajów diagramów UML wyposażono w rozbudowany zestaw kategorii modelowania UML, spośród których uczestnicy szkoleń wybierają zawężony podzbiór kategorii i stosują je w praktyce,
podczas gdy inne są ignorowane. W ramach definiowania założeń przyszłej wersji Light
autorzy przyjęli następujące trzy podstawowe ograniczenia:
− wersja Light powinna składać się wyłącznie z najpowszechniej stosowanych w praktyce diagramów, natomiast składnia poszczególnych diagramów powinna być
maksymalnie zawężona;
144
−
w
UML 2.x Light powinna w szerokim zakresie wspomagać główne dyscypliny metodyki RUP, tj. specyfikację wymagań oraz analizę i projektowanie;
− wersja taka powinna być w pełni kompatybilna z pełną specyfikacją języka UML
2.x.
Niniejsza koncepcja nie ogranicza potencjału UML, jako, że specyfikacje systemu opracowane z wykorzystaniem wersji Light mogą być sukcesywnie wzbogacane i rozbudowywane z wykorzystaniem kategorii modelowania oraz diagramów „pełnej” wersji języka
UML.
Dla określenia zakresu wersji UML 2.x Light autorzy przeprowadzili badanie o charakterze ankietowym wśród studentów specjalności Informatyka Ekonomiczna. Jego rezultaty
pozwoliły nie tylko na dogłębną ocenę kursu UML przez jego uczestników, lecz także stanowiło podstawę do dokonania rewizji aktualnie stosowanego podejścia.
Grupa docelowa obejmowała 180 studentów, zarówno z uczelni prywatnych, jak i publicznych, posiadających wiedzę i kompetencje w zakresie zarówno obiektowego, jak i strukturalnego podejścia do tworzenia systemów informatycznych. Kompetencje wspomnianej
grupy studentów opierały się na:
− udziale w 30-godzinnym wykładzie, poświęconym standardowi UML 2.x;
− przestudiowaniu autorskich podręczników (Wrycza i in., 2005) oraz (Wrycza,
2006);
− opanowaniu technicznej sprawności w zakresie komputerowego wspomagania
tworzenia poszczególnych diagramów UML z wykorzystaniem narzędzia Enterprise
Architect firmy Sparx Systems;
− uczestnictwie w projektach biznesowych, wykonywanych w małych grupach
w oparciu o standard UML;
− dostępie do materiałów internetowych oraz e-learningowych, związanych z poruszaną tematyką;
− w licznych przypadkach na doświadczeniu praktycznym w zakresie programowania
i projektowania systemów.
Kwestionariusz ankietowy składał się z 17 podstawowych pytań. Pytania dotyczyły
głównie pojęć związanych z wersją Light języka UML, wzajemnych zależności pomiędzy
podejściem strukturalnym a obiektowym, jak również potencjalnych rozszerzeń i technik
pochodnych w stosunku do UML. W celu dokonania precyzyjnej oceny zakresu proponowanej wersji Light dokonano analizy następujących kwestii:
− oceny poziomu złożoności języka UML;
− adekwatności liczby rodzajów diagramów języka UML 2.x;
− oceny użyteczności poszczególnych rodzajów diagramów;
− identyfikacji diagramów „przeciążonych” zaawansowanymi kategoriami pojęciowymi;
− wytypowania diagramów przyjaznych użytkownikowi (ang. user-friendly);
− wskazania diagramów stanowiących najlepsza podstawę do generowania kodu źródłowego.
Obszerna graficzna analiza statystyczna wraz z komentarzami została zaprezentowana
m. in. w opracowaniu (Wrycza i Marcinkowski, 2007). Poniżej komentowane są jedynie
wybrane wyniki.
Kwestionariusz zainicjowano pytaniem o złożoność języka UML (rys. 3). Uznanie języka UML za nadmiernie złożony ma fundamentalne znaczenie z punktu widzenia wprowadzania wersji Light języka UML. Odpowiedzi respondentów potwierdziły hipotezę autorów
– 51% ankietowanych uważało UML za średnio trudny, 33% za trudny, podczas gdy 7% za
da
.b
w
w
pl
s.
145
bardzo trudny. A zatem dla ponad 90% studentów zawężona wersja języka UML, tj. UML
Light, stanowiłaby cenną asystę w przyswajaniu języka.
7%
2%
7%
bardzo łatwy
33%
łatwy
w
średnio trudny
trudny
51%
bardzo trudny
w
Rys. 3. Oszacowanie stopnia trudności UML
da
.b
w
Ankietowani studenci mieli możliwość przyswojenia na zajęciach i/lub w praktyce
wszystkich 13 rodzajów diagramów języka UML. Liczba diagramów jest w sposób naturalny powiązana ze złożonością języka. Większość z badanych (ponad 57%) uznała, iż UML
składa się ze zbyt wielu rodzajów diagramów. Pozostali respondenci akceptowali pełny
zestaw diagramów UML, nie odnosząc się jednakże do wpływu i znaczenia liczności zaawansowanych kategorii modelowania składających się na poszczególne diagramy.
Skoro poszczególne rodzaje diagramów użytkowane są ze zróżnicowaną intensywnością
– niektóre mają charakter uniwersalny, inne stosowane są w specyficznych sytuacjach – postawiono pytanie o użyteczność poszczególnych rodzajów diagramów. Badanie wykazało,
iż w opinii respondentów najbardziej użyteczne są następujące diagramy:
− diagramy klas (62% pozytywnych wskazań respondentów),
− diagramy przypadków użycia (56%),
− diagramy czynności (26%),
− diagramy sekwencji (21%).
Studium potwierdziło powszechnie uznawaną rolę przewodnią pełnioną przez dwa rodzaje diagramów – diagramy klas oraz diagramy przypadków użycia. W istocie stanowią
one dwa podstawowe graficzne formalizmy modelowania odpowiednio struktury oraz dynamiki systemu informatycznego. Diagramy klas stanowią podstawowy artefakt w modelowaniu baz danych. Dodatkowo, diagramy przypadków użycia inicjują iteracyjno-przyrostowy cykl życia metodyki RUP (Rational Unified Process), pełniąc tym samym specyficzną
rolę w każdym projekcie. Z kolei jako najmniej użyteczne postrzegane są:
− diagramy maszyny stanowej (28%),
− diagramy harmonogramowania (19%),
− diagramy rozlokowania (13%),
− diagramy struktur połączonych (12%).
Niewątpliwie wciąż niedoceniana jest rola diagramów maszyn stanowych oraz diagramów rozlokowania, choć i tak nie pretendują one do roli najbardziej uniwersalnych. Podczas gdy diagramy maszyny stanowej są bogate semantycznie i użyteczne w modelowaniu
statusów obiektów klas w obiektowych bazach danych, lecz niechętnie stosowane przez początkujących analityków i projektantów, diagramy rozlokowania są bliższe fizycznemu
wdrożeniu systemu w zgodzie z metodyką RUP. Stąd dwa powyższe rodzaje diagramów
należy szczególnie polecić realizującym kursy z zakresu programowania.
W związku z czwartym kryterium, studentów poproszono o wskazanie diagramów przeciążonych zaawansowanymi kategoriami modelowania (rys. 4). W ocenie studentów cecha
ta dotyczy przede wszystkim poszczególnych rodzajów diagramów interakcji. I tak, 32%
pl
s.
146
w
respondentów uważało, że nadmierność pojęciowa towarzyszy przede wszystkim diagramom sekwencji (32% odpowiedzi), podczas gdy odpowiednio 28% i 27% respondentów
oceniło w ten sposób diagramy sterowania interakcją oraz diagramy komunikacji. Spośród
diagramów interakcji wyłącznie diagram harmonogramowania został uznany za stosunkowo nieskomplikowany. Problem nadmiarowości nie dotyczył również semantycznie bogatych diagramów obiektów, diagramów przypadków użycia oraz diagramów klas. Tylko odpowiednio 14%, 18% oraz 20% respondentów zakwalifikowało te diagramy jako nadmiarowe. Akceptacja dla znacznej złożoności diagramów klas wiąże się z doświadczeniem studentów w dziedzinie programowania w języku obiektowym Java. Kategorie modelowania
diagramów klas są tam w szerokim zakresie implementowane praktycznie.
w
za dużo kategorii modelowania
zdecydowanie za dużo kategorii modelowania
30%
20%
15%
10%
5%
0%
Prz
da
.b
w
25%
pl
s.
Ha
Ste
Str
Ma
Ko
Ro
Cz
Ob
rm
u kt K o m
ro w P a k
szy Se kw
yp a Klas
mu
zl o
ynn
o
i
ur
po n
i
e
e
n
a
n
k
nik
kow
t
d kó
o
y s enc
n
ó
t ów
p
o śc
g
i
w
e
o
a in
acj
ra m
n
ł
ta n
ji
an
ą
wu
i
t
ów
czo
i
te r
ia
ow
ow
ży c
a
n
ej
an
y
k
ia
c
c
h
ia
ją
Rys. 4. Ocena stopnia nadmiarowości kategorii modelowania w diagramach języka UML
Przyjazność dla użytkownika jest jednym ze słów kluczowych a zarazem wyzwaniem
współczesnej informatyki. Ocena diagramów UML z tego punktu widzenia powinna ułatwić wytypowanie zakresu wersji UML Light. Opierając się na wynikach badania należy
podkreślić, że diagramy przypadków użycia zostały uznane za najłatwiejsze do opanowania
i zarazem przyjazne użytkownikowi spośród 13 diagramów UML 2.x. Niemalże
¾ respondentów doceniło tę cechę, tak niezbędną szczególnie w dziedzinach modelowania
biznesowego oraz specyfikacji wymagań. W istocie, diagramy te stanowią wspólną platformę porozumienia poszczególnych udziałowców systemu – tj. właścicieli, menadżerów,
przyszłych użytkowników oraz informatyków. Współpraca tych grup udziałowców staje się
dobrą podstawą dla osiągnięcia poprawności, precyzji, spójności oraz kompletności dokumentacji w konsekwencji zastosowania merytorycznie powiązanych diagramów UML.
Wspomniany już wielokrotnie pragmatyczny wymiar diagramów klas i ich ścisły związek z programowaniem i tworzeniem baz danych spowodował, że osiągnęły one również
147
w
wysoką ocenę – 66% respondentów zakwalifikowały je jako łatwe lub bardzo łatwe w użytkowaniu. Studenci docenili również (59%) znaczenie diagramów czynności jako szkieletu
dla algorytmów oraz specyfikacji programistycznych. Przyjazność dla użytkownika pewnych typów diagramów UML powinna być ponownie rozważona. Uwaga ta dotyczy
w szczególności diagramów sterowania interakcją (43%), diagramów rozlokowania (39%)
oraz diagramów struktur połączonych (38%). Wspomniane rodzaje diagramów należy traktować jako naturalnych kandydatów do wykluczenia z wersji Light języka UML 2.x.
Rozwój narzędzi CASE zainspirował badania oraz prace nad generowaniem kodu źródłowego na podstawie dokumentacji systemowej, przygotowanej z wykorzystaniem języka
UML. Diagramy tego języka dają solidną podstawę do generowania kodu źródłowego na
bazie diagramowej specyfikacji systemu. Respondenci uznali następujące rodzaje diagramów za dobra podstawę do tworzenia specyfikacji programistycznych:
− diagram klas (66% odpowiedzi pozytywnych),
− diagramy czynności (42%),
− diagramy sekwencji (34%),
− diagramy komunikacji (34%),
− diagramy komponentów (23%).
w
w
4 Wnioski
da
.b
Ostatecznie, w wyniku przeprowadzonych badań proponuje się umieszczenie w wersji
Light języka UML czterech rodzajów diagramów:
− diagramów przypadków użycia,
− diagramów klas,
− diagramów czynności,
− diagramów sekwencji.
Wspomniane cztery rodzaje diagramów (rys. 5) pozwalają na modelowanie wszystkich
podstawowych aspektów systemu, tj. specyfikacji wymagań oraz analizy i projektowania
zarówno struktury, jak i dynamiki systemu. Dostarczają również odpowiedniej ilości danych pod kątem generowania kodu.
pl
s.
148
Diagram UML 2.x
Diagram dynamiki
Diagram struktury
w
w
«Light»
Diagram
przypadków użycia
Diagram struktur
połączonych
«Light»
Diagram klas
Diagram obiektów
«Light»
Diagram
czynności
Diagram pakietów
w
Diagram
interakcji
Diagram wdrożeniowy
da
.b
Diagram
komponentów
Diagram maszyny
stanowej
Diagram
rozlokowania
«Light»
Diagram sekwencji
Diagram
komunikacji
Diagram
harmonogramowania
Diagram
sterowania
interakcją
Rys. 5. Diagramy UML 2.x zakwalifikowane do wersji Light
pl
s.
Nie występuje konieczność wprowadzania wyczerpującej listy dostępnych kategorii modelowania do specyfikacji systemowych, przygotowanych z wykorzystaniem wersji Light
języka UML 2.x. Podstawowe kategorie modelowania są niezbędne do tworzenia diagramów na poziomie konceptualnym, podczas gdy zaawansowane kategorie modelowania –
do tworzenia diagramów na poziomie wdrożeniowym. Propozycja podziału kategorii modelowania pomiędzy podstawowe oraz zaawansowane może stanowić punkt wyjścia w
określaniu zakresu pojęciowego poszczególnych diagramów, jak przedstawiono w tabeli 2.
W konsekwencji nabytego doświadczenia dydaktycznego i poczynionych obserwacji,
w tym omawianego badania, dokonano przekształcenia struktury kursu UML, polegającej
na skoncentrowaniu się w ramach laboratoriów na 4 rodzajach diagramów wersji Light,
podczas gdy pełne spektrum diagramów omawiane jest szczegółowo w ramach wykładów.
149
Tabela 2. Podstawowe i zaawansowane kategorie modelowania w kontekście wersji Light
języka UML 2.x
w
Podstawowe kategorie
modelowania
Diagram klas
D. przypadków
użycia
Zobowiązanie
Widoczność
Atrybut/operacja
statyczna
Asocjacja n-arna
Klasa asocjacyjna
Asocjacja
zwrotna
Asocjacja
wielokrotna
Kwalifikacja
Uogólnienie
Zależność
Realizacja
1.
2.
3.
4.
Aktor
Klasa
Klasa graniczna
Czynność
Klasa sterująca
Podczynność
Klasa
Początek
przechowująca
Koniec
Linia życia
Przepływ sterowania
Ośrodek
sterowania
Komunikat
synchroniczny
Komunikat
asynchroniczny
Komunikat
zwrotny
Decyzja
Komunikat
Łącznik
utracony
Złączenie
Komunikat
Akcja
znaleziony
Przekaźnik danych
Komunikat
Parametr czynności
opcjonalny
Waga
Komunikat
Sygnał
oczekujący
Bufor centralny
Warunek
Składnica danych
Samowywołanie
Partycja
Iteracja
Obszar rozszerzenia
Rozgałęzienie
Obszar przerwania
Fragment
Manipulator
wyodrębniony
wyjątków
Przywoływane
wystąpienie
interakcji
Brama
Zależność
zawierania
Zależność
rozszerzania
Uogólnienie
Rodzaje aktorów
Liczebność
Nawigacja
Realizacja
pl
s.
Literatura
Diagram sekwencji
da
.b
Zaawansowane kategorie modelowania
w
w
Klasa
Atrybut
Operacja
Asocjacja binarna
Przypadek użycia
Nazwa asocjacji
Aktor
Role
Asocjacja binarna
Nawigacja
Liczebność
Agregacja
Kompozycja
Diagram czynności
Alphonce C., Ventura P.: “QuickUML: A Tool to Support Iterative Design and Code
Development”, Proceedings of OOPSLA, Anaheim 2003, s. 80-81.
Ambler S. W.: The Elements of UML 2.0 Style, Cambridge University Press, Cambridge 2003.
Booch G., Rumbaugh J., Jacobson I.: The Unified Software Development Process, AddisonWesley, Boston 1998.
Booch G., Rumbaugh J., Jacobson I.: The Unified Modeling Language User Guide, AddisonWesley, Boston 1999.
150
5.
6.
7.
8.
w
Booch G., Rumbaugh J., Jacobson I.: The UML Reference Manual. 2nd edition, AddisonWesley, Boston 2004.
Brewer J., Lorenz L.: “Using UML and Agile Development Methodologies to Teach ObjectOriented Analysis & Design Tools and Techniques”, Proceedings of CITC4, Lafayette 2004, s.
54-57.
Burton P. J., Bruhn R. E.: “Using UML to Facilitate the Teaching of Object-Oriented Systems
Analysis & Design”, Journal of Computing Sciences in Colleges, 2004, 19 (3), s. 278-290.
DeLooze L. L., “Minimal UML Diagrams for a Data-Driven Web Site”, SIGITE, 2005, s. 229232.
Dennis A.: Systems Analysis and Design with UML Version 2.0, Wiley, Nowy Jork 2005.
Dobing B., Parsons J.: “How UML is Used”, Communications of ACM, 2006, 49 (5), s. 109113.
Eriksson H., Penker M., Lyons B., Fado D.: UML 2 Toolkit, OMG Press, Indianapolis 2004.
Flint S., Gardner H., Boughton C.: “Executable/Translatable UML in Computing Education”,
Conferences in Research and Practice in Information Technology, 2004, s. 69-75.
Fowler M.: UML Distilled, 3rd ed. Addison-Wesley, Boston 2004.
Hansen K. M., Ratzer A. V.: “Tool Support for Collaborative Teaching and Learning of ObjectOriented Modeling”, Proceedings of ITiCSE, Aarhus 2002, s. 146-150.
Jacobson I., Christerson M., Jonsson P., Overgaard G.: Object-Oriented Software Engineering: A
Use-Case Driven Approach. Addison-Wesley, Boston 1992.
Kontio M.: “Architectural Manifesto: Designing Software Architectures. Part 5. Introducing the
4+1 View Model”, http://www-128.ibm.com/developerworks/wireless/library/wi-arch11, 2005
(stan na sierpień 2007).
Kruchten P.: “Architectural Blueprints - the ‘4+1’ View Model of Software Architecture”, IEEE
Software, 1995, 12 (6), s. 42-50.
Kruchten P.: The Rational Unified Process, Addison-Wesley, Boston 2004.
LeBlanc C., Stiller E.: “UML for Undergraduate Software Engineering”, Proceedings of JCSC
15, Consortium for Computing in Small Colleges, 2000, s. 8-18.
OMG, Object Management Group: “Unified Modeling Language 2.0 Superstructure
Specification”, http://www.omg.org/cgi-bin/doc?formal/05-07-04, 2005 (stan na sierpień 2007).
OMG, Object Management Group: “The UML 2.1 Superstructure Convenience Document”,
http://www.omg.org/cgi-bin/doc?ptc/2006-04-02, 2006 (stan na sierpień 2007).
Pavlov L. V., Yatsenko A.: “The Babel Experiment: An Advanced Pantomime-Based Training
in OOA and OOD with UML”, Proceedings of SIGCSE, St. Louis 2005, s. 231-235.
Pilone D.: UML 2.0 in a Nutshell, O’Reilly, Pekin 2005.
Poyla G.: How to solve it, Princeton University Press, New York 1957.
Rational Software Corporation: “Business Modeling with UML: The Light at the End of the
Tunnel”, 2001, http://www.therationaledge.com/content/dec_01/m_businessModeling_bb.html
Sparx Systems Enterprise Architect 7.0, http://www.sparxsystems.com.au (stan na sierpień
2007).
Tabrizi M., Collins C., Ozan E., Li K.: “Implementation of Object-Orientation Using UML in
Entry Level Software Development Courses”, Proceedings of SIGITE, Salt Lake City 2004, s.
128-131.
Trujillo J.: “A Report on the First International Workshop on Best Practices of UML”, SIGMOD
Record, 2006, 35 (3), s. 48-50.
Turner S. A., Perez-Quinones M., Edwards S. H.: “minimUML: A Minimalist Approach to UML
Diagramming for Early Computer Science Education”, ACM Journal of Educational Resources
in Computing, 2005, s. 1-24.
UML Tools: http://www.oose.de/umltools.htm, 2005 (stan na sierpień 2007).
Wrycza S.: Analiza i projektowanie systemów informatycznych zarządzania, PWN, Warszawa
1999.
Wrycza S. (red.): UML 2.1. Ćwiczenia, Helion, Gliwice 2006.
Wrycza S., Marcinkowski B.: “UML 2 Teaching at Postgraduate Studies – Prerequisites and
Practice”, Proceedings of ISECON 2005, 22, AITP Foundation for Information Technology
Education, Columbus, rekord 5123, 2005, s. 1-7.
9.
10.
13.
14.
15.
16.
18.
19.
20.
21.
22.
26.
27.
28.
29.
30.
31.
32.
33.
pl
s.
23.
24.
25.
da
.b
17.
w
w
11.
12.
151
w
34. Wrycza S., Marcinkowski B.: “UML 2 Academic Course – Methodological Background and
Survey Benchmarking”, Proceedings of ISECON 2006, 23, AITP Foundation for Information
Technology Education, Columbus, rekord 5125, 2006, s. 1-6.
35. Wrycza S., Marcinkowski B.: ”Towards a Light Version of UML 2.x: Appraisal and Model”,
Proceedings of the 2nd AIS SIGSAND European Symposium on Systems Analysis and Design,
Gdańsk 2007, s. 46-53.
36. Wrycza S., Marcinkowski B., Wyrzykowski K.: Język UML 2.0 w modelowaniu systemów
informatycznych, Helion, Gliwice 2005.
37. Wrycza S., Rybiński W.: “Information Systems Development Education: Assumptions and
Practice”, (w) Stowell F. A., West D., Howell J. G. (red), Systems Science. Addressing Global
Issues. Plenum Press, Nowy Jork 1993, s. 475-481.
da
.b
w
w
pl
s.
152

pobierz plik referatu

Transkrypt

Podobne dokumenty

Podstawy UML

projektowanie obiektowe i modelowanie z użyciem uml

Laboratorium 3 Diagramy klas — Różnice między kompozycją a

OCUP-F/TOPDS Warsztat przygotowujący do egzaminu OMG UML

dr inż. Ryszard Myhan Nazwa przedmiotu: Techniki programowania

Stanisław Bajor

Laboratorium 2 - Instytut Sterowania i Systemów Informatycznych

Książki dla studentów kierunku „geodezja i kartografia”

Laboratorium 6 - Instytut Sterowania i Systemów Informatycznych

Modelowanie w języku UML (kod: UML1)