Nowe mechanizmy modelowania i analizy wyjątków w standardzie języka UML 2.0

138 Pages·2008·1.61 MB·Polish

Akademia Górniczo-Hutnicza
Wydział Elektrotechniki, Automatyki, Informatyki i Elektroniki
Rozprawa doktorska
Nowe mechanizmy modelowania
i analizy wyjątków w standardzie
języka UML 2.0
mgr Andrzej Zieliński
Promotor:
Prof. dr hab. inż. Tomasz Szmuc
Kraków 2007
Spis treści
Konwencje leksykalne . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Wykaz skrótów . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1. Wstęp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.1. Tematyka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2. Stan aktualnej wiedzy . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.3. Cel badań . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.4. Organizacja rozprawy . . . . . . . . . . . . . . . . . . . . . . . . . 16
2. Wyjątki w standardzie Unified Modeling Language (UML) 2.0 18
2.1. Specyfikacja standardu . . . . . . . . . . . . . . . . . . . . . . . . 18
2.1.1. Infrastruktura . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.1.2. Aplikacja . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2. Modelowanie wyjątków . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2.1. Diagramy aktywności . . . . . . . . . . . . . . . . . . . . . 24
2.2.2. Klasy behawioralne . . . . . . . . . . . . . . . . . . . . . . 34
2.2.3. Interakcje . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.3. Wnioski . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3. Rozszerzenie standardu UML 2.0 . . . . . . . . . . . . . . . . . . . 46
3.1. Wprowadzenie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.2. Zmiany korekcyjne . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.3. Modyfikacja diagramów aktywności . . . . . . . . . . . . . . . . . 49
3.3.1. Procedura obsługi . . . . . . . . . . . . . . . . . . . . . . . 49
3.3.2. Zgłaszanie . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.4. Modyfikacja klasy Behavior . . . . . . . . . . . . . . . . . . . . . . 54
3.5. Elementy zawierające klasę Behavior . . . . . . . . . . . . . . . . . 66
3.6. Modyfikacja diagramów interakcji . . . . . . . . . . . . . . . . . . 67
3.7. Metryki . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
3.8. Wnioski . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4. Konstrukcja atrybutów . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.1. Projekt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.2. Graf przepływu wyjątków . . . . . . . . . . . . . . . . . . . . . . 73
4.2.1. Przepływ w diagramach aktywności . . . . . . . . . . . . . 75
4.2.2. Przepływ w maszynach stanów . . . . . . . . . . . . . . . . 84
4.3. Algorytm konstrukcji . . . . . . . . . . . . . . . . . . . . . . . . . 87
4.4. Wnioski . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
5. Cykl wytwórczy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
5.1. Proces wytwórczy . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
5.2. CASE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.3. Wnioski . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
6. Przykład i ocena rozwiązania . . . . . . . . . . . . . . . . . . . . . . 103
6.1. Funkcjonalność . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
6.2. Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
6.3. Atrybuty wyprowadzone. . . . . . . . . . . . . . . . . . . . . . . . 116
6.4. Wnioski . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
7. Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
7.1. Opis zbiorowy wyników . . . . . . . . . . . . . . . . . . . . . . . . 123
7.2. Wnioski końcowe . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
7.3. Możliwości zastosowań i dalszego rozwoju . . . . . . . . . . . . . . 126
Spis rysunków . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Bibliografia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Skorowidz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Konwencje leksykalne
aktywność (ang. activity) Tłumaczenie terminu języka UML.
atrybut wyprowadzony (ang. derived attribute) Atrybutwyprowadzo-
ny na podstawie innych danych atrybutów. Oznaczony jest ukośnikiem /.
klasa aktywna (ang. active class) Klasa,którejobiektysąaktywne,czy-
li posiadają sterowanie wykonania np.: zadania, wątki, procesy.
klasa pasywna (ang. passive class) Klasa, która nie jest aktywna.
meta-model (ang. meta-model) Model definiujący koncepcje do budo-
wania innych modeli.
metoda (ang. method) Implementacja operacji.
metryka oprogramowania (ang. software metric) Funkcjaprzypisują-
capewnemufragmentowilubcałościprojektuczykoduprogramuwartość
liczbową.
model (ang. model) Abstrakcja rzeczywistego systemu.
obiekt (ang. object) Instancja klasy
obiekt aktywny (ang. active object) Instancja klasy aktywnej.
operacja (ang. operation) Deklaracja pewnego serwisu, który może być
wykonany przez instancję klasy do której należy lub przez samą klasę.
Zawiera nazwę, listę przyjmowanych parametrów, wartość zwracaną oraz
listę zgłaszanych wyjątków.
profil (ang. profile) Tłumaczenie terminu języka UML.
stereotyp (ang. stereotype) Tłumaczenie terminu języka UML.
właściwość (ang. property) Paranazwa-wartośćcharakteryzującapewien
element.
wyjątek (ang. exception) Zdarzenie zgłaszane specjalną akcją, którego
obsługa polega na zmianie normalnego przepływu sterowania i zwijaniu
stosu wywołań w celu poszukiwania procedury obsługi.
wyjątek asynchroniczny (ang. asynchronous exception) Wyjątekzgła-
szany z jednego zadania w kierunku innego zadania, gdzie powinien być
obsłużony.
KONWENCJE LEKSYKALNE 4
wyjątek synchroniczny (ang. synchronous exception) Wyjątek zgła-
szany i obsługiwany w jednym i tym samym zadaniu.
zadanie (ang. task) Wykonywalna części programu, która posiada stero-
wanie. Częściami takimi w UML są obiekty aktywne, natomiast w syste-
mach operacyjnych są to: procesy lub wątki.
zdarzenie (ang. event) Wywołanie metody obiektu, skonstruowanie lub
skasowanieobiektu,albowiadomośćprzesłanazjednegoobiektulubklasy
do innego obiektu lub klasy.
Wykaz skrótów
CASE Computer Aided Software Engineering
CORBA Common Object Request Broker Architecture
CPU Central Processing Unit
CWM Common Warehouse Model
EAI Enterprise Application Integration
EDOC Enterprise Distributed Object
EJB Enterprise Java Beans
ER Entity Relationship
GPS Global Positioning System
GPW Graf Przepływu Wyjątków
GUI Graphical User Interface
ID Identyfikator
IT Information Technology
JRE Java Runtime Environment
MDA Model Driven Architecture
MDC Meta-Data Coalition
MMI Man Machine Interface
MOF Meta-Object Facility
OCL Object Constraint Language
OMG Object Management Group
OMT Object-Modeling Technique
OOA Object-Oriented Analyzis
OOD Object-Oriented Design
OOSE Object-Oriented Software Engineering
PLL Phase Locked Loop
POSIX Portable Operating System Interface
SADT Structured Analyzis and Design Technique
SDL Specification and Description Language
SPT Schedulability, Performance, and Time
TP Testing Profile
UML Unified Modeling Language
WAE Web Application Extensions
WYKAZ SKRÓTÓW 6
WfMC Workflow Management Coalition
XMI XML Metadata Interchange
XML Extensibility Markup Language
1. Wstęp
1.1. Tematyka
Obecnie informatyka występuje niemal w każdej dziedzinie życia. Progra-
my komputerowa działają nie tylko na komputerach osobistych, ale w wie-
lu urządzeniach codziennego użytku. Co roku powstają miliony linii kodu,
z czego wiele jest niestety błędnych lub niespełniających zakładanych wy-
magań. Przyczyny tych błędów są oczywiście różne, ale z pewnością wyni-
kają również z braku porozumienia między projektantami i koderami lub
też z powodu pominięcia fazy projektowania i przejściu od razu do kodowa-
nia. W obu wspomnianych przypadkach istotę stanowi wykonanie dobrego
projektu, który byłby czytelny dla inżynierów zajmujących się tworzeniem
wymagań oraz dla inżynierów zajmujących się implementacją. Osoba specy-
fikująca wymagania musi wziąć udział w tworzeniu modelu systemu, jako re-
prezentantklienta,akodermusiumiećprzeczytaćmodel,abyprzełożyćgona
język programowania. Stworzenie modelu systemu ma na celu minimalizację
kosztu tworzenia oprogramowania poprzez zredukowanie kosztu złej jakości.
Osiąga się to dzięki udziałowi zespołu tworzącego wymagania w konstruk-
cji modelu oraz wczesnemu wychwytywaniu błędów już na etapie projektu,
aniedopiero podczas implementacji.Stąd bardzoistotne jestskonstruowanie
dobrego projektu przedmiotowego systemu.
Istnieje wiele metodologii projektowych. Chronologicznie można wymie-
nić główne: Data Structure Oriented Design [26,65,66], Structured Analyzis
and Design Technique (SADT) [51,65,66,73] Object-Oriented Design (OOD)
i Object-Oriented Analyzis (OOA) [5,10,12,57,65,66]. Dobrym pomysłem
wydawało się więc zebranie najlepszych praktyk i utworzenie jednego języka
modelowania. Byłby on wykorzystywany przez szeroką rzeszę projektantów,
a cały wysiłek skupiałby się nad rozwojem jednego standardu modelowa-
nia, zamiast utrzymywania kilku konkurencyjnych. Zunifikowany język, któ-
ry miał zastąpić najczęściej używane wówczas języki, przyjął nazwę Unified
Modeling Language (UML) [42].
ROZDZIAŁ 1. WSTĘP 8
Język UML powstał głównie na fali syntezy trzech najpopularniejszych
metod modelowania, tj. Object-Modeling Technique (OMT) Rumbaugh’a
[58], używanej do obiektowej analizy OOA, metody Booch’a [6], stosowanej
w projektowaniu obiektowym OOD oraz metody Jacobson’a - Object-Orien-
ted Software Engineering (OOSE) [27]. UML jest rozwijany od roku 1994,
a formalnie od 1997 przez konsorcjum Object Management Group (OMG)
[40].Jestjęzykiemobiektowym.OMGstworzyłocałyszeregspecyfikacji,któ-
re składają się na standard UML [42–50]. UML stał się najpopularniejszym
językiem modelowania wypierając inne języki takie jak: Specification and
Description Language (SDL), diagramy Entity Relationship (ER) czy Ob-
jectory. Język ten umożliwia specyfikację, wizualizację i udokumentowanie
modeli w sposób bardzo czytelny, nawet dla początkujących projektantów,
jednocześniejestnatyleścisły,żemożliwejestgenerowaniekoduzniektórych
jego diagramów. Jest używany na etapie analizy, tj. tworzenia wymagań oraz
projektowania. W tym pierwszym obszarze daje on dodatkowe możliwości
wczesnego wykrywania błędów łącznie z prezentacją klientowi kilku prostych
diagramów, szczególnie diagramów przypadków użycia.
Wiele języków programowania takich jak: Ada, C++, Common Lisp, D,
Delphi, Eiffel, Java, Objective-C, OCaml, PHP (od wersji 5), Python, RE-
ALbasic, ML, Ruby i wszystkie języki .NET posiadają mechanizmy obslugi
wyjątków [71]. Wyjątek jest zdarzeniem, które powoduje przerwanie normal-
nego przepływu sterowania [8,13,14,18,39]. Wyjątek jest zgłaszany specjal-
ną instrukcją i obsługiwany w procedurze obsługi, której zasięg wyznaczają
specjalne znaczniki. Obsługa wyjątku polega na zwijaniu stosu wywołań tak
długo, aż instrukcja sterująca będzie w zasięgu właściwej procedury obsługi.
Wyjątki używane są głównie do sygnalizowania sytuacji błędnych. Znacznie
wygodniej jest grupować procedury obsługi wyjątków, tak aby każda z nich
obsługiwała pewien typ wyjątków, zamiast uciążliwie sprawdzać każdy kod
powrotu wywoływanych operacji. Napisany w ten sposób program jest znacz-
nie bardziej czytelny, prostszy w utrzymaniu, przez co mniej narażony na
błędy. Wersja wykonywalna jest mniejsza rozmiarowo, gdyż pozbawiona jest
wielokrotnego sprawdzania kodu powrotu w celu wykrycia błędu. W pew-
nych przypadkach zwrócenie kodu błędu jest nieefektywne, wówczas dobrym
rozwiązaniem jest zgłoszenie wyjątku, o ile są w ogóle dostępne. Mechanizm
wyjątków pozwala na bardziej przejrzystą obsługę błędów, ale nieprawidłowo
zastosowany sam może być źródłem błędów. Każdy nieobsłużony wyjątek
przerywa wykonywanie programu, co w niektórych systemach, szczególnie
systemach czasu rzeczywistego, jest dyskwalifikujące. Powoduje to ich całko-
ROZDZIAŁ 1. WSTĘP 9
witą bezużyteczność. Zatem dobre zaprojektowanie wyjątków wydaje się być
bardzo istotne, a wręcz krytyczne. Ceną jaką płaci się za używanie mechani-
zmu wyjątków jest konsumpcja pamięci na stosie wykonywanego programu
oraz czasu procesora w celu przechowywania odpowiednich struktur umożli-
wiającychposzukiwanieproceduryobsługi.Wostatniejdekadzie,przyrosną-
cychszybkościachprocesorów,niskichkosztachpamięciorazdużychkosztach
naprawczych, niezawodoność i łatwość utrzymania programu jest istotniejsza
niż oszczędności dokonane na sprzęcie.
Wymaganiadotyczącezachowaniasystemuwczasiesytuacjiwyjątkowych
wsystemachczasurzeczywistegosąwpewnymsensieważniejszeodwymagań
określających normalną pracę. Szczególnie widoczne jest to w przypadku sys-
temów o twardych wymaganiach czasowych, kiedy życie ludzkie lub ogromne
wartości materialne zależą od prawidłowego działania. Niestety wyjątki bar-
dzoczęstosązaniedbywanączęściąprogramu.Niesąobsługiwanewogólelub
zgłaszane są w sposób chaotyczny i nieprzemyślany, co skutkuje niespodzie-
wanymi zakończeniami wykonywania się programu. Czasami koszty takich
błędów są ogromne. Tak było w przypadku wystrzelenia rakiety Ariane 5,
lot 501, 4 czerwca 1996 r. przez europejski system wynoszenia w celu dostar-
czenia satelitów na orbitę geostacjonarną. Rakieta uległa zniszczeniu w 37
sekund po starcie. Przyczyną katastrofy było oprogramowanie, gdzie nieob-
służony wyjątek finalnie spowodował awarię systemu komputerowego [15,36].
Koszty oszacowano powyżej 370 mln USD.
Obsługawyjątkówjestzagadnieniemzłożonymibardzoważnym,wszcze-
gólnościwsystemachczasurzeczywistego.PowszechniestosowanyjęzykUML
2.0, traktowany w zasadzie jako standard w dziedzinie modelowania oprogra-
mowania,charakteryzujesiębrakiemzaawansowanychtechnikopisuiobsługi
wyjątków. Podjęcie badań w celu takiego rozszerzenia UML 2.0 powiększa-
jącego jego szeroko rozumiane możliwości modelowania wyjątków wydaje się
celowe. Dotyczy to nie tylko łatwości definiowania odpowiednich struktur,
lecz również zapewnienia czytelności konstrukcji i wspomagania analizy po-
prawności.
Szacuje się, że około 70% firm z branży Information Technology (IT)
używa języka UML w celach projektowych oraz około 50% narzędzi do mo-
delowania w użyciu komercyjnym lub akademickim wspiera język UML [52].
Tak szerokie stosowanie uzasadnia celowość zajmowania się analizą i udosko-
nalaniem standardu. Najprawdopodobniej liczba aktywnych użytkowników
języka UML będzie wzrastała, co dodatkowo potwierdza ważność tematyki.
Rozszerzanie języka UML odbywa się na dwa sposoby. Pierwszy polega