Index of /rozprawy2/10018

Pełen tekst

(1)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.

(2) 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. Modelowanie wyjątków . . . . . . . . . . . . . . . . . . . . . . . .. 24. 2.2.1.. Diagramy aktywności . . . . . . . . . . . . . . . . . . . . .. 24. 2.2.2.. Klasy behawioralne . . . . . . . . . . . . . . . . . . . . . .. 34. 2.2.3.. Interakcje. . . . . . . . . . . . . . . . . . . . . . . . . . . .. 43. Wnioski . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 43. 3. Rozszerzenie standardu UML 2.0 . . . . . . . . . . . . . . . . . . .. 46. 2.2.. 2.3.. 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.

(3) 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.

(4) Konwencje leksykalne aktywność (ang. activity) Tłumaczenie terminu języka UML. atrybut wyprowadzony (ang. derived attribute) Atrybut wyprowadzony na podstawie innych danych atrybutów. Oznaczony jest ukośnikiem /. klasa aktywna (ang. active class) Klasa, której obiekty są aktywne, czyli 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 budowania innych modeli. metoda (ang. method) Implementacja operacji. metryka oprogramowania (ang. software metric) Funkcja przypisująca pewnemu fragmentowi lub całości projektu czy kodu programu wartość 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) Para nazwa-wartość charakteryzująca pewien 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ątek zgłaszany z jednego zadania w kierunku innego zadania, gdzie powinien być obsłużony..

(5) KONWENCJE LEKSYKALNE. 4. wyjątek synchroniczny (ang. synchronous exception) Wyjątek zgłaszany i obsługiwany w jednym i tym samym zadaniu. zadanie (ang. task) Wykonywalna części programu, która posiada sterowanie. Częściami takimi w UML są obiekty aktywne, natomiast w systemach operacyjnych są to: procesy lub wątki. zdarzenie (ang. event) Wywołanie metody obiektu, skonstruowanie lub skasowanie obiektu, albo wiadomość przesłana z jednego obiektu lub klasy do innego obiektu lub klasy..

(6) Wykaz skrótów CASE. Computer Aided Software Engineering. CORBA CPU CWM EAI EDOC. Common Object Request Broker Architecture Central Processing Unit Common Warehouse Model Enterprise Application Integration Enterprise Distributed Object. EJB ER GPS GPW. Enterprise Java Beans Entity Relationship Global Positioning System Graf Przepływu Wyjątków. GUI ID IT JRE. Graphical User Interface Identyfikator Information Technology Java Runtime Environment. MDA MDC MMI MOF OCL. Model Driven Architecture Meta-Data Coalition Man Machine Interface Meta-Object Facility Object Constraint Language. OMG OMT OOA OOD. Object Management Group Object-Modeling Technique Object-Oriented Analyzis Object-Oriented Design. OOSE PLL POSIX SADT SDL. Object-Oriented Software Engineering Phase Locked Loop Portable Operating System Interface Structured Analyzis and Design Technique Specification and Description Language. SPT TP UML WAE. Schedulability, Performance, and Time Testing Profile Unified Modeling Language Web Application Extensions.

(7) WYKAZ SKRÓTÓW WfMC XMI XML. Workflow Management Coalition XML Metadata Interchange Extensibility Markup Language. 6.

(8) 1. Wstęp. 1.1. Tematyka Obecnie informatyka występuje niemal w każdej dziedzinie życia. Programy komputerowa działają nie tylko na komputerach osobistych, ale w wielu urządzeniach codziennego użytku. Co roku powstają miliony linii kodu, z czego wiele jest niestety błędnych lub niespełniających zakładanych wymagań. Przyczyny tych błędów są oczywiście różne, ale z pewnością wynikają również z braku porozumienia między projektantami i koderami lub też z powodu pominięcia fazy projektowania i przejściu od razu do kodowania. 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 specyfikująca wymagania musi wziąć udział w tworzeniu modelu systemu, jako reprezentant klienta, a koder musi umieć przeczytać model, aby przełożyć go na 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 konstrukcji modelu oraz wczesnemu wychwytywaniu błędów już na etapie projektu, a nie dopiero podczas implementacji. Stąd bardzo istotne jest skonstruowanie dobrego projektu przedmiotowego systemu. Istnieje wiele metodologii projektowych. Chronologicznie można wymienić 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 modelowania, 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]..

(9) 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-Oriented Software Engineering (OOSE) [27]. UML jest rozwijany od roku 1994, a formalnie od 1997 przez konsorcjum Object Management Group (OMG) [40]. Jest językiem obiektowym. OMG stworzyło cały szereg specyfikacji, 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 Objectory. Język ten umożliwia specyfikację, wizualizację i udokumentowanie modeli w sposób bardzo czytelny, nawet dla początkujących projektantów, jednocześnie jest na tyle ścisły, że możliwe jest generowanie kodu z niektó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, REALbasic, ML, Ruby i wszystkie języki .NET posiadają mechanizmy obslugi wyjątków [71]. Wyjątek jest zdarzeniem, które powoduje przerwanie normalnego przepływu sterowania [8, 13, 14, 18, 39]. Wyjątek jest zgłaszany specjalną 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 znacznie 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 pewnych 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-.

(10) 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 mechanizmu wyjątków jest konsumpcja pamięci na stosie wykonywanego programu oraz czasu procesora w celu przechowywania odpowiednich struktur umożliwiających poszukiwanie procedury obsługi. W ostatniej dekadzie, przy rosnących szybkościach procesorów, niskich kosztach pamięci oraz dużych kosztach naprawczych, niezawodoność i łatwość utrzymania programu jest istotniejsza niż oszczędności dokonane na sprzęcie. Wymagania dotyczące zachowania systemu w czasie sytuacji wyjątkowych w systemach czasu rzeczywistego są w pewnym sensie ważniejsze od wymagań określających normalną pracę. Szczególnie widoczne jest to w przypadku systemów o twardych wymaganiach czasowych, kiedy życie ludzkie lub ogromne wartości materialne zależą od prawidłowego działania. Niestety wyjątki bardzo często są zaniedbywaną częścią programu. Nie są obsługiwane w ogóle lub zgłaszane są w sposób chaotyczny i nieprzemyślany, co skutkuje niespodziewanymi 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 dostarczenia satelitów na orbitę geostacjonarną. Rakieta uległa zniszczeniu w 37 sekund po starcie. Przyczyną katastrofy było oprogramowanie, gdzie nieobsłużony wyjątek finalnie spowodował awarię systemu komputerowego [15,36]. Koszty oszacowano powyżej 370 mln USD. Obsługa wyjątków jest zagadnieniem złożonym i bardzo ważnym, w szczególności w systemach czasu rzeczywistego. Powszechnie stosowany język UML 2.0, traktowany w zasadzie jako standard w dziedzinie modelowania oprogramowania, charakteryzuje się brakiem zaawansowanych technik opisu i obsługi wyjątków. Podjęcie badań w celu takiego rozszerzenia UML 2.0 powiększają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 poprawnoś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 modelowania w użyciu komercyjnym lub akademickim wspiera język UML [52]. Tak szerokie stosowanie uzasadnia celowość zajmowania się analizą i udoskonalaniem 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.

(11) ROZDZIAŁ 1. WSTĘP. 10. na wykorzystaniu wbudowanych metod, czyli mechanizmów profili i stereotypów. Mechanizmy te, choć prymitywne i ubogo realizujące rozszerzenia, umożliwiają zdefiniowanie elementów języka, które są charakterystyczne dla dziedziny modelowanego systemu. Sam standard zawiera w sobie kilka predefiniowanych profili, które mogą być użyte według potrzeb. Wśród nich znajduje się profile: Enterprise Java Beans (EJB), Enterprise Application Integration (EAI), Enterprise Distributed Object (EDOC), Schedulability, Performance, and Time (SPT), Testing Profile (TP) oraz nieformalny profil Web Application Extensions (WAE), który zapewne wkrótce stanie się częścią standardu. Stereotypy i profile umożliwiają jedynie dodanie nowych elementów w pewien ograniczony sposób. Wszystkie inne dalej idące modyfikacje wymagają zmiany w samym metamodelu, czym jest wspomniana wyżej druga metoda modyfikacji. W pracy przedstawiono rozszerzenie standardu UML 2.0 poprzez modyfikację metamodelu.. 1.2. Stan aktualnej wiedzy Początki prac nad zagadnieniem obsługi wyjątków sięgają lat 70-tych, kiedy to zajmowano się proceduralnymi językami programowania, takimi jak: Mesa, CLU czy Ada [14]. Wszystkie z wymienionych języków posiadały obsługę wyjątków, która powstała na bazie postrzeganej obecnie jako klasyka publikacji Goodenough’a [18]. Lata 80-te i początek lat 90-tych XX w. to dynamiczny rozwój języków obiektowych i wysiłek zaopatrzenia ich w mechanizm obsługi wyjątków [13]. W języku C++ wyjątki wprowadzono wiosną 1992 r., chociaż zaprojektowane były od samego początku, ale z powodu niewystarczającej analizy odsuwano datę ich wprowadzenia [63]. Inne obiektowe języki programowania, które zostały zaopatrzone w mechanizmy obsługi wyjątków to: CommonLisp (+CLOS, 1988), Eiffel (1988) czy SmallTalk (1989). Druga połowa lat 90-tych XX w. i lata ostatniej dekady to głównie starania w analizie przepływu wyjątków w różnych językach programowania i innych dziedzinach. To również rozwój języków modelowania, w tym aspektu obsługi wyjątków. Artykuły [53, 54] podsumowują stan wiedzy i badań nad ogólnie pojętymi wyjątkami do roku 2000 w różnych dyscyplinach. Pierwszy z nich traktuje o publikacjach skupionych na tradycyjnych problemach związanych z wyjątkami z jakimi mamy do czynienia w językach programowania, projektowania czy systemach operacyjnych. Drugi natomiast dotyczy zagadnień w konkretnych używanych przez człowieka systemach. Obsługę.

(12) ROZDZIAŁ 1. WSTĘP. 11. wyjątków w standardzie UML można zaliczyć do pierwszej grupy, stosując kryteria powyższych artykułów. O tym, że oprogramowanie używane niemalże codziennie i postrzegane jako stabilne ma słabo zaimplementowaną obsługę sytuacji wyjątkowych przekonali się autorzy [34] przeprowadzając testy i opisując ich rezultaty na około 15. systemach operacyjnych i 233. funkcjach POSIXa. W zależności od systemu od 18 do 33% testów spowodowało nietypowe zakończenie wywołania systemowego i 5 systemów zakończyło niespodziewanie swoje działanie. Tylko od 55 do 76% funkcji zwróciło błąd w czasie testów nie powodując niestabilnego zachowania. W publikacji [8] zostały przedstawione problemy związane z obsługą wyjątków w systemach współbieżnych. Wprowadzono pojęcie wykonania (ang. execution) oraz wyjątku asynchronicznego jako wyjątku, który może być zgłoszony z jednego wykonania w kierunku innego, gdzie powinien być obsłużony. Autorzy analizują trzy modele obsługi wyjątków, które są ogólnie znane i opisywane również w innych publikacjach [39, 72]. Pierwszy, model przerywania (ang. termination model), polega na tym, że po zgłoszeniu wyjątku następuje uruchomienie procedury obsługi. Po jej wykonaniu sterowanie powraca do instrukcji, występującej za procedurą obsługi, która zostaje wykonana zamiast bloku instrukcji, które zgłosiły wyjątek. Drugi, model powrotu (ang. resume model), którego istotą jest powrót do instrukcji, która byłaby wykonana, gdyby wyjątek nie był zgłoszony. Powrót ten następuje jak tylko procedura obsługi zakończy swoje zadanie. Trzeci to model powtórzenia (ang. retrying model) - jeśli wyjątek zostanie zgłoszony, wówczas po jego obsłużeniu blok zgłaszający wyjątek jest powtórnie wykonywany. Pewne idee zostały zaczerpniete z omawianego artykułu w dalszej części rozprawy. Za każdym razem jest to wyraźnie zaznaczone. Autorzy omawiają również czwarty, model transferu nielokalnego (ang. nonlocal transfer model), który umożliwia poprzez specjalną instrukcję goto skok do pewnej etykiety programu połączony ze skokiem w odpowiednie miejsce stosu. Model taki znalazł swoją realizację w języku PL/I. W języku C za pomocą instrukcji setjmp i longjmp realizacja tego modelu jest również możliwa. Do grupy tradycyjnych problemów możemy zaliczyć również analizę programów pod kątem konstrukcji obsługujących i zgłaszających wyjątki. Istotą jest zbadanie programu w celu określenia przepływu wyjątków pomiędzy wywoływanymi funkcjami czy też zadaniami. Próby takie podjęto w publikacji [56], gdzie zaproponowano pewien model do analizy przepływu wyjątków oraz zaimplementowano go w programie Jex w celu użycia do kodu w języka.

(13) ROZDZIAŁ 1. WSTĘP. 12. Java. Następnie dokonano analizy popularnych bibliotek JRE. Model umożliwiał łatwe zlokalizowanie miejsc, gdzie obsługa wyjątków powinna być poprawiona. Zdefiniowano trzy funkcje: encounters, catches i uncaught. Pierwsza z nich, encounters, zwraca listę wyjątków, jakie mogą się pojawić w chronionym bloku instrukcji (try...catch), który jest argumentem funkcji. Funkcja catches dla argumentu, którym jest instrukcją obsługi (wyrażeniem catch), zwraca wyjątki przez nie obsługiwane. Wreszcie uncaught jest funkcją, która dla chronionego bloku instrukcji przypisuje wyjątki, które nie są w nim obsłużone. Artykuł ze swoim modelem skupia się na analizie wyjątków zgodnych z modelem przerywania, który jest zaimplementowany w języku Java. Przedstawione tam zostały dwie perspektywy analizy. Pierwsza - wszerz, polega na analizie wyjątków, liczby i typu, które mogą wpłynąć do pewnego bloku instrukcji. Projektant może wówczas dowiedzieć się ile wyjątków może potencjalnie przepłynąc przez pewien fragment kodu. Inna perspektywa opisywana w omawianym artykule to analiza wgłąb, której celem jest określenie jak długa jest droga między zgłoszeniem a obsłużeniem wyjątku. Kolejną publikacją, która zajmuje się analizą wyjątków oraz prezentuje swoje rezultaty dla języka Java jest artykuł [7]. Autorzy przedstawiają pewien schemat projektowania i analizy wyjątków, który ma zapewnić ich lepszą obsługę. Artykuł [60] zajmuje się analizą programów pod kątem przepływu sterowania i danych. Aby prezentowane techniki mogły być używane z powodzeniem w programach napisanych w językach typu C++ czy Java, należy brać pod uwagę istnienie wyjątków, ich przepływ oraz wpływ na zachowanie się całego programu. Artykuł przedstawia efekt jaki wywierają konstrukcje zgłaszające wyjątki na istniejące techniki, prezentuje algorytmy, które umożliwiają dopasowanie mechanizmów obsługi i zgłaszania wyjątków do tych technik. Prace dotyczące wyjątków traktują również o ludzkiej percepcji, naturze i skłonności do popełniania błędów (zapomnienie lub brak świadomości o możliwości zaistnienia pewnej sytuacji) [37]. Autorzy przedstawiają przykładowe techniki zapobiegania jak: burza mózgów, N-wersyjne programowanie oraz przypadki zależności, których zastosowanie powoduje, że program jest lepszy pod względem obsługi sytuacji wyjątkowych. Burza mózgów i N-wersyjne programowanie są powszechnie znane w literaturze. Istotą tego pierwszego jest zasada, iż efektywność grupy jest większa niż najlepsza efektywność indywidualnej jednostki. Druga technika polega na stworzeniu równolegle kilku wersji tego samego oprogramowania oraz pewnego arbitra, który potrafi rozpoznać błędne zachowanie się systemu od prawidłowego. Wówczas.

(14) ROZDZIAŁ 1. WSTĘP. 13. szansa, że sytuacja wyjątkowa wystąpi na obydwu jednocześnie jest mniejsza, a jeśli wystąpi tylko na jednym, wówczas arbiter wybierze prawidłowe wartości. Metoda ta jest jednak dosyć droga w rozwiązaniu i w praktyce rzadko stosowana. Trzecia metoda została opracowana przez autorów i jej najlepsza efektywność została wykazana zakończonym sukcesem eksperymentem. Polega na zastosowaniu przypadków zależności. Przypadek zależności jest to konstrukcja wraz z uzasadnieniem, że system jest odporny na pewne zidentyfikowane ryzyka. W obecnej literaturze spotyka się również opracowania dotyczące obsługi wyjątków w systemach, w których końcowy użytkownik posiada możliwość obsługi wyjątków. Przykładem są tutaj systemy typu arkusz kalkulacyjny (ang. spreadsheets systems), gdzie sytuacje wyjątkowe mogą mieć miejsce i powinny być obsługiwane. Artykuł [9] omawia zagadnienia związane z obsługą wyjątków w arkuszach kalkulacyjnych. Programy te mogą być bardzo złożone i duże, dlatego też, ze względu na ich stabilność i utrzymanie, konieczne jest potraktowanie z uwagą obsługi wyjątków. Autorzy przedstawiają swoje doświadczenie oraz analizę modelu wartości błędnych dla arkuszy kalkulacyjnych. Inny przykład systemów, gdzie końcowy użytkownik, nie programista tworzący system, zajmuje się sytuacjami wyjątkowymi, znajduje się w publikacji [19]. Autorzy zwracają uwagę, że bardzo ważne jest uzyskanie dobrej obsługi sytuacji wyjątkowych w nowoczesnych systemach przepływu (ang. workflow systems). Rozproszone środowisko, długie i czasochłonne aktywności oraz złożony wykonywany program występują tam jednocześnie. Przykładem takiego systemu są procesy biznesowe, np.: rezerwacja samolotu, samochodu i hotelu lub ewentualnie pociągu w celu podróży biznesowej, gdzie udział biorą ludzie jak i maszyny włącznie z systemem komputerowym. Autorzy opisują zaawansowany mechanizm obsługi sytuacji wyjątkowych używając transakcji, jak i klasycznej metody obsługi wyjątków. Takie podejście jest unikalne, gdyż łączy ono wyjątki z transakcjami oraz traktuje cały system przepływu jako środowisko programistyczne, gdzie zastosowanie mają idee z metodologii tworzenia oprogramowania obsługującego błędy (ang. fault tolerant). Można również stosować czynności mające na celu zapobieganie błędom (ang. fault prevention), o czym artykuł wspomina, przy czym następnie pada stwierdzenie, iż utworzenie systemu, który zapobiegałby wszystkim błędom jest niemożliwe, dlatego też bardzo ważna jest ich obsługa. Język modelowania systemów przepływu wprowadzony przez autorów posiada specjalne cechy w celu detekcji i obsługi błędów, koncepcyjnie zbliżone do rozwiązań spraw-.

(15) ROZDZIAŁ 1. WSTĘP. 14. dzonych w obecnych językach programowania. W celu powrotu po obsłużonej błędnej sytuacji został wprowadzony mechanizm atomowych transakcji, podobnie jak powszechnie znane transakcje z dziedziny baz danych. Autorzy opracowali również pewne techniki sprawdzania poprawności przepływów w sytuacjach, kiedy wyjątki są zgłaszane i obsługiwane. Kolejnym artykułem traktującym o tej tematyce jest publikacja [35]. Zostały tam przedstawione detale implementacyjne dotyczące architektury wprowadzonej przez Workflow Management Coalition (WfMC) oraz zaprezentowano kilka przykładów obrazujących szczegóły opracowanych rozwiązań. Zagadnienie to jest o tyle ciekawe, że pomiędzy przepływami a diagramami aktywności w standardzie UML 2.0 istnieje wiele podobieństw. Wyjątki są szczególnie ważne w dziedzinie systemów czasu rzeczywistego, gdzie spełnialność wymagań czasowych decyduje o użyteczności systemu w ogóle. Istnieje wiele prac traktujących o zaawansowanych metodach projektowania tych systemów [32,65,66,70]. Celem badań jest również możliwość zastosowania języka UML w modelowaniu systemów czasu rzeczywistego [24]. W przeciwieństwie do literatury o analizie programów, nie istnieją publikacje, które traktują o metrykach określających jakość programu w aspekcie przepływu wyjątków. Istnieje wiele publikacji na temat wyjątków w językach obiektowych. Artykuły te koncentrują się głównie na zastosowaniu opisywanych przez nie pomysłów do programów napisanych w najpopularniejszych obecnie językach, czyli C++ lub Java. Analiza wyjątków w standardzie UML 2.0 jest również zagadnieniem czekającym na wnikliwe przebadanie. W publikacjach [61, 62] autor rozważa semantykę diagramów aktywności. Standard UML 2.0 przedstawia semantykę diagramów aktywności używając terminologii zaczerpniętej z sieci Petriego. Nie realizuje tego jednak w sposób formalny. Autor podejmuje próbę wyrażenia semantyki diagramów aktywności za pomocą sieci Petriego [55], które są znanym formalizmem w dziedzinie projektowania systemów współbieżnych [28–31,55,67]. W publikacji [61] zostaje przedstawione semantyczne tłumaczenie przepływu sterowania w diagramach aktywności za pomocą sieci Petriego miejsc i przejść. Jest to jedynie przepływ sterowania, dlatego nie jest konieczne użycie kolorowanych sieci Petriego ze względu na pominięcie w analizie typu danych. Artykuł ten jest ciekawy z punktu widzenia analizy diagramów aktywności, które są szczegółowo przebadane w czasie konstrukcji atrybutów wyprowadzonych zaprezentowanej w dalszej części rozprawy. Podobnie, jeśli chodzi o drugi z artykułów tego samego autora [62], który jest jeszcze bliższy niniejszej rozprawie, gdyż traktuje o semantyce.

(16) ROZDZIAŁ 1. WSTĘP. 15. wyjątków w UML 2.0. Autor prezentuje w jaki sposób dla aktywności, która zawiera konstrukcje związane z obsługą wyjątków skonstruować sieć Petriego, która semantycznie oddawałaby istotę przepływu wyjątków. Dyskusyjnym wydaje się być podejście polegające na zgłaszaniu wyjątków pod wpływem pewnej wiadomości lub w wierzchołku decyzyjnym, czy też nie uwzględnienie wierzchołków strukturalnych jako regionu chronionego. W UML 2.0 istnieje specjalna akcja do zgłaszania wyjątku, który jest obsłużony przez odpowiednią procedurę. Istnieją inne prace, które również omawiają tłumaczenia diagramów aktywności na sieci Petriego [4, 38]. W pracy [20] autorzy przedstawiają propozycję notacji wyjątków i ich semantykę na diagramach sekwencji. Inspiracją do artykułu był profil UML 2 Testing Profiles. Obsługa wyjątków w diagramach sekwencji polega na dynamicznej alokacji fragmentów diagramów interakcji, które odgrywają rolę procedury obsługi. Kiedy taki diagram zostaje zlokalizowany, odkładany jest na stos, który istnieje jedynie w płaszczyźnie semantycznej diagramów sekwencji i jest nowością dla UML 2.0. Standard nie traktuje o istnieniu w semantyce diagramów sekwencji stosu. Po wykonaniu odłożonego na stos diagramu sekwencji będącego procedurą obsługi następuje powrót do pierwotnego diagramu. Diagramy sekwencji w rozprawie, traktowane są bardziej jako pewne scenariusze i raczej jako ślady po wykonaniu, a nie jako sposób wyrażenia funkcjonalności. Są więc odpowiednikiem logów z wykonania programu, a nie projektem, który ma wyznaczać koderowi jak zaimplementować system (podejście zaczerpnięte z autorskiej publikacji [74, 75]). Dlatego też powyższa propozycja nie wpisuje się w całokształt idei jaką rozprawa prezentuje. W chwili obecnej brak jest opracowań, które traktowałyby o analizie wyjątków w standardzie UML 2.0 lub też ogólnie o wyjątkach w standardzie. Jednak zagadnienie to jest na tyle istotne i ważne, że powstała konieczność podjęcia badań w tym obszarze. Publikacja [72], która ukazała się wcześniej niż [8], opisuje model zastąpienia (ang. replacement model), który jest właściwie hybrydą opisywanych powyżej pierwszych trzech modeli. Zawiera on w sobie cechy wszystkich trzech i taki model został wykorzystany w rozprawie. Dodatkowo praca [19] wykorzystuje również model zastąpienia zastosowany do systemów przepływu, które w pewien sposób są podobne do diagramów aktywności, co potwierdza trafność wyboru..

(17) ROZDZIAŁ 1. WSTĘP. 16. 1.3. Cel badań Celem pracy jest rozszerzenie języka UML 2.0 o nowe mechanizmy modelowania obsługi wyjątków. Opracowane mechanizmy winny zapewniać łatwiejsze modelowanie obsługi wyjątków i uzyskiwanie przejrzystych konstrukcji oraz wspomaganie analizy poprawności obsługi wyjątków. Rozszerzenie powinno również eliminować wady i niedogodności jakie UML 2.0 posiada w obecnej formie. Dlatego też konieczna jest wnikliwa analiza obecnych struktur jakie UML 2.0 posiada w celu opracowania rozwiązań, które czynią standard silniejszym w zakresie modelowania wyjątków, stawiając go przed obecnymi obiektowymi językami programowania. W rozprawie formułuje się następującą tezę: Możliwe jest rozszerzenie standardu języka UML 2.0 o nowe mechanizmy obsługi wyjątków, dostarczające narzędzi modelowania oraz ułatwiające analizę poprawności i unikanie błędów modelowania. Zaproponowane mechanizmy umożliwiają również definiowanie metryk przepływu wyjątków w modelu. Metryki te pozwalają określić jakość aspektu obsługi wyjątków modelowanego systemu.. 1.4. Organizacja rozprawy Rozprawa składa się z siedmiu rozdziałów. W pierwszym rozdziale przedstawiono krótki wstęp do tematyki rozprawy, uzasadniono ważność tematyki, opisano stan aktualnej wiedzy i przedstawiono cel badań wraz z uzasadnieniem jego ważności oraz sformułowano tezą rozprawy. Rozdział drugi porusza temat mechanizmów w obsłudze wyjątków zawartych w UML 2.0. Trzeci, czwarty i piąty rozdział zawierają autorskie rozwiązania opracowane w celu wykazania tezy. Rozdział trzeci przedstawia rozszerzenie standardu UML 2.0 oraz poprawę znalezionych błędów. Zmiany głównie dotyczą zachowań oraz w szczególności diagramów aktywności. Następny rozdział to przedstawienie algorytmów konstrukcji będących przedmiotem rozszerzenia. Rozdział piąty traktuje o praktycznym wykorzystaniu przedmiotowych rozszerzeń w rzeczywistym procesie wytwórczym oprogramowania. Rozdział szósty przedstawia przykład ilustrujący opracowane rozwiązanie..

(18) ROZDZIAŁ 1. WSTĘP. 17. W rozdziale siódmym sformułowano wnioski końcowe oraz podano kierunki dalszych badań. Na początku rozprawy znajduje się słownik pojęć używanych w pracy oraz skrótów powszechnie przyjętych. W treści pracy wprowadza się również inne dodatkowe skróty zaproponowane przez Autora w celu zwiększenia czytelności rozprawy (długie nazwy klas specyfikacji języka UML). Każdy taki skrót jest podawany przy pierwszym użyciu długiej nazwy i jest używany do końca podrozdziału w którym został wprowadzony. W treści rozprawy, oprócz tekstu normalnego, używa się również czcionki maszynowej oraz kursywy. Czcionką maszynową są pisane elementy standardu UML i elementy innych języków, natomiast kursywą nazwy będące elementem przykładowego projektu. Kursywa jest również używana do pisania definicji, kluczowych stwierdzeń oraz wzorów matematycznych. Czcionką tłustą wyróżniono zwięzły tekst, będący przeważnie pewnym wnioskiem lub dowiedzionym stwierdzeniem, które ma bezpośredni wpływ na wykazanie tezy rozprawy. Elementy nowe na diagramach klasowych modelujących język UML zaznaczono kolorem szarym. W rozprawie użyto szeregu rysunków zaczerpniętych z modelu pakietów InfrastructureLibrary i SuperstructureLibrary wykonanych w Rational Rose [44] oraz ze specyfikacji dostarczonych przez OMG [47,50]. Rysunki c te oznaczono symbolem °OMG 2.0 i uzyskano zgodę na ich publikację. W rozdziale zawierającym przykład, rysunki wykonano za pomocą narzędzia Enterprise Architect [16], polecanego przez OMG jako najbardziej zgodnego ze standardem UML 2.0 [41]..

(19) 2. Wyjątki w standardzie UML 2.0. 2.1. Specyfikacja standardu UML jest wizualnym językiem służącym do specyfikacji i dokumentacji systemów. Jego cechą charakterystyczną jest wszechstronność, może więc być użyty do projektowania w wielu dziedzinach przemysłowych, jak i naukowych. Bardzo dobrze specyfikuje istotę i cel abstrahując od docelowej platformy. Organizacja OMG [40] jest oficjalnie odpowiedzialna za rozwój standardu UML. Prace nad językiem UML są częścią większego planu jakim jest rozwój Model Driven Architecture (MDA). Celem jest skonstruowanie kompletnego standardu do tworzenia niezależnych od implementacji modeli, które mogą być zaprojektowane na dowolne platformy sprzętowe. UML ma odgrywać rolę centralną w rozwijaniu MDA, poprzez zastosowanie do wyrażania specyfikacji standardów składających się na MDA, czyli: UML, Meta-Object Facility (MOF) i Common Warehouse Model (CWM). MOF jest meta-meta-modelem, którego instancjami są UML i CWM (meta-modele). Jest on częścią długoterminowej strategii OMG, polegającej na łatwej wymianie modeli stworzonych przy pomocy różnych narzędzi pochodzących od różnych dostawców. Sposób reprezentacji modeli wykonanych w językach wyprowadzonych ze standardu MOF precyzuje XML Metadata Interchange (XMI). Sam MOF jest zdefiniowany za pomocą podzbioru UML oraz precyzyjnego języka naturalnego [49], s. 11. CWM jest językiem modelowania wypracowanym w porozumieniu OMG z Meta-Data Coalition (MDC). Celem CWM jest dostarczenie podobnego rozwiązania w modelowaniu danych, jakim jest UML w modelowaniu obiektów. UML opisuje wspólny język modelowania do budowy systemów, podczas gdy CWM opisuje wymianę danych w hurtowniach danych. Specyfikacja UML została zdefiniowana wykorzystując podejście polegające na meta-modelowaniu. UML jest więc meta-modelem, którego instancje to konkretne modele użytkownika. Sam UML jest również modelem, instancją meta-modelu MOF. MOF natomiast jest zdefiniowany za pomocą.

(20) ROZDZIAŁ 2. WYJĄTKI W STANDARDZIE UML 2.0. 19. Rysunek 2.1. Przykład 4-poziomowej hierarchii metamodelowania c °OMG 2.0 [50], s. 19. konstrukcji UML znanych z poprzednich wersji, języka Object Constraint Language (OCL) oraz dobrze określonego języka naturalnego. Dlatego też język UML nie jest tak rygorystyczny jak matematyczne metody formalne, pozostawiając projektantowi pewną swobodę w interpretacji, jaką niesie za sobą użycie języka naturalnego. Rozważa się cztery warstwy w podejściu meta-modelowym. Koncepcja ta została przedstawiona przykładem na rys. 2.1. Ze względu na swoją rozległą przestrzeń modelowania UML musi charakteryzować się budową modularną, aby możliwe było wybranie tylko takich podzbiorów języka, które są najbardziej przydatne. Modularność (ang. modularity/partitioning) została osiągnięta poprzez wprowadzenie repozytorium zwanego pakietem. UML może być łatwo rozszerzony (ang. extensibility) na dwa sposoby. Po pierwsze z wykorzystaniem istniejących mechanizmów, tj. profili (ang. profiles) lub poprzez modyfikacje wprowadzone w meta-modelu UML. Meta-model zawiera również w sobie elementy, które są wielokrotnie użytkowane (ang. reuse) czyniąc go łatwiej rozszerzalnym i bardziej czytelnym. Specyfikacja UML 2.0 składa się z dwóch pakietów opisanych w następnych rozdziałach. Są to UML 2.0 Infrastructure i UML 2.0 Superstructure..

(21) ROZDZIAŁ 2. WYJĄTKI W STANDARDZIE UML 2.0. (a) Rola wspólnego pakietu Core. 20. (b) Pakiet InfrastructureLibrary. Rysunek 2.2. Infrastruktura c °OMG 2.0 [50], s. 12. 2.1.1. Infrastruktura UML 2.0 Infrastructure jest specyfikacją opisującą infrastrukturę języka UML 2.0. Rolą pakietu jest zdefiniowanie takiej części meta-modelu UML, zwanej rdzeniem, która zawiera fundamentalne elementy wspólne dla wszystkich języków z grupy MDA oraz umożliwia wygodne definiowanie innych modeli wchodzących w skład architektury MDA, czyli UML, MOF i CWM. Rdzeń realizowany jest przez pakiet Core. Stanowią go niskopoziomowe abstrakcyjne elementy, które niekoniecznie nadają się do użycia przez użytkownika w sposób bezpośredni, ale mogą być użyte do definiowania innych elementów, np.: Classifier. Wśród tych elementów znajdują się również takie, które mogą być użyte przez użytkownika i są wspólne dla wszystkich języków z grupy MDA, np.: Class. Tak więc UML jest metamodelem - instancją meta-metamodelu MOF oraz z drugiej strony importuje pakiet Core, podobnie jak MOF. Zatem MOF, CWM i UML mają pewną wspólną część, którą głównie stanowią: typy danych, podstawowe konstrukcje i abstrakcje. Drugim ważnym celem pakietu jest umożliwienie dostosowania elementów języka UML do specyficznych dziedzin poprzez mechanizm profili oraz tworzenie nowego języka bazującego na pakiecie Core. Mechanizm profili został zawarty w pakiecie Profiles. Na rys. 2.2 została przedstawiona zawartość pakietu InfrastructureLibrary oraz relacje z językami modelowania składającymi się na MDA. 2.1.2. Aplikacja Część użytkowa UML określona jest w pakiecie SuperstructureLibrary [47]. UML 2.0 Infrastructure razem ze specyfikacją UML 2.0 Superstructure, zwaną aplikacją (nazwa wprowadzona przez Autora), stanowią najważniejszą część standardu. Aplikacja zawiera konstrukcje (ang. language units),.

(22) ROZDZIAŁ 2. WYJĄTKI W STANDARDZIE UML 2.0 Element języka Actions Activities Classes Components Deployments General Behaviors Information Flows Interactions Models Profiles State Machines Structures Templates Use Cases. 21. Cel modelowania (Podstawa) Akcje Zachowania za pomocą przepływu danych i sterowania (Podstawa) Podstawowe struktury Złożone struktury dla technologii komponentowych Rozlokowanie (Podstawa) Podstawowe zachowania i czas Przepływ abstrakcyjnych struktur danych Zachowania poprzez interakcję między obiektami Organizacja modelu Rozszerzanie i dopasowywanie języka Zachowania sterowane zdarzeniami Złożone struktury danych Szablony Nieformalne wymagania zachowań. Tabela 2.1. Elementy języka UML 2.0. które mogą być bezpośrednio użyte przez użytkownika języka UML, np.: maszyny stanów, diagramy aktywności czy diagramy sekwencji. Elementy te przedstawiono w tabeli 2.1 wraz z krótką charakterystyką ich przeznaczenia [59]. Pogrupowane są w repozytoriach zwanych pakietami. Pakiety mogą zawierać inne pakiety jako składniki oraz być w relacji połączenia (ang. merge) lub importu (ang. import) z innymi. Oznacza to odpowiednio fizyczne skopiowanie elementów z pakietu, który jest dołączany lub jedynie dodanie tych elementów do przestrzeni nazw pakietu docelowego. W tym drugim przypadku kopiowanie nie następuje. Definiuje również cztery (L0,L1,L2,L3) poziomy zgodności syntaktycznej (ang. compliance level) ściśle określając, jakie konstrukcje muszą być dostarczane użytkownikowi przez narzędzie modelowe zgodne z językiem UML na pewnym poziomie [59]. Poziomy zgodności wraz z pakietami w nie wchodzącymi zostały przedstawione w tabelach 2.2 - 2.4. Przykładem mogą być maszyny stanów, które muszą być dostępne na poziomie L2, a nie muszą na poziomie L1. Istnieją dwa rodzaje zgodności syntaktycznej. • Zgodność składniowa abstrakcji (ang. abstract syntax compliance). Dotyczy zgodności ze względu na zawartość metamodelu i relacji, jakie tam występują. Innymi słowy zgodność ta definiuje zespół reguł, który zapewnia poprawność modelu, np.: nie można połączyć dwóch klas tranzycją maszyny stanów. • Zgodność składniowa notacji (ang. concrete syntax compliance). Dotyczy.

(23) ROZDZIAŁ 2. WYJĄTKI W STANDARDZIE UML 2.0. Element języka Pakiet metamodelu Actions Actions::BasicActions Activities Activities::FundamentalActivities Activities::BasicActivities Classes Classes::Kernel Classes::Dependencies Classes::Interfaces General Behavior CommonBehaviors::BasicBehaviors Structures CompositeStructure::InternalStructures Interactions Interactions::BasicInteractions UseCases UseCases Tabela 2.2. Pakiety metamodelu na poziomie L1 c °OMG 2.0 [47], s. 6. Element języka Actions Activities Components Deployments General Behavior Interactions Profiles Structures. State Machines. Pakiet metamodelu Actions::StructuredActions Actions::IntermediateActions Activities::IntermediateActivities Activities::StructuredActivities Components::BasicComponents Deployments::Artifacts Deployments::Nodes CommonBehaviors::Communications CommonBehaviors::SimpleTime Interactions::Fragments AuxilliaryConstructs::Profiles CompositeStructures::InvocationActions CompositeStructures::Ports CompositeStructures::StructuredClasses StateMachines::BehaviorStateMachines. Tabela 2.3. Pakiety metamodelu na poziomie L2 c °OMG 2.0 [47], s. 6-7. 22.

(24) ROZDZIAŁ 2. WYJĄTKI W STANDARDZIE UML 2.0. 23. Element języka Action Activities. Pakiet metamodelu Actions::CompleteActions Activities::CompleteActivities Activities::CompleteStructuredActivities Activities::ExtraStructuredActivities Classes Classes::AssociationClasses Classes::PowerTypes Components Components::PackagingComponents Deployments Deployments::ComponentDeployments Information Flows AuxilliaryConstructs::InformationFlows Models AuxilliaryConstructs::Models State Machines StateMachines::ProtocolStateMachines Structures CompositeStructures::Collaborations CompositeStructures::StructuredActivities Templates AuxilliaryConstructs::Templates Tabela 2.4. Pakiety metamodelu na poziomie L3 c °OMG 2.0 [47], s. 7. Rysunek 2.3. Semantyka UML c °OMG 2.0 [47], s. 9. zgodność na poziomie notacji, np.: dziedziczenie jest przedstawiane jako strzałka z niewypełnionym trójkątnym grotem. Mówiąc o semantyce UML 2.0 należy wyróżnić semantykę repozytoryjną (ang. repository semantics) i semantykę wykonania (ang. runtime semantics), w skrócie semantykę. Nie każdy element języka jest wykonywalny. Wykonywalnym przypisuje się pewne akcje wykonawcze (ang. runtime semantics), np.: maszyna stanów, natomiast tym drugim przypisuje się znaczenie repozytoryjne (ang. repository semantics), np.: pakiet. Rys. 2.3 przedstawia architekturę semantyczną języka UML. Elementy warstwy wyższej zależą od elementów warstwy niższej. Pierwszą warstwą są podstawowe elementy strukturalne. Wynika to z własności języka UML, gdzie każde zachowanie musi być związane z pewnym aktywnym obiektem w kontekście, którego się wykonuje [47], (s. 9, punkt 6.3.1). Następna warstwa składa się z trzech części. Opisują one komunikację między obiektami oraz komunikację wewnątrz.

(25) ROZDZIAŁ 2. WYJĄTKI W STANDARDZIE UML 2.0. 24. obiektową. Znając sposób komunikacji obiektów, możemy określić znaczenie akcji. Biorąc pod uwagę znaczenie semantyczne akcji, możliwe jest określenie znaczenia najbardziej złożonych struktur, czyli aktywności, maszyn stanów oraz interakcji. Akcje są podstawowymi jednostkami składającymi się na model. Z semantycznego punktu widzenia akcje odpowiadają instrukcjom w tradycyjnych językach programowania. Z kolei aktywności składają się z akcji i są odpowiednikiem funkcji w tradycyjnych językach programowania. Aktywności należy czytać podobnie jak sieci Petriego, [47], s. 408, gdzie każda akcja jest odpowiednikiem tranzycji, a jej wejście i wyjście to miejsca. Wprowadzono również pojęcie znacznika, który może przenosić dane lub sterowanie. Akcja jest wykonana tylko wtedy, gdy wszystkie wymagane znaczniki znajdują się na jej wejściu. Maszyny stanów UML działają w sposób analogiczny jak automaty. Interakcje natomiast przedstawiają przepływ wiadomości między obiektami.. 2.2. Modelowanie wyjątków Wyjątki w UML 1.x są sygnałami [43], s. 2-94. Zgłoszenie wyjątku i jego obsługa wygląda zatem identycznie jak wysłanie i odebranie sygnału. Sygnał zgłaszany jest przez specjalną akcję (SendSignalAction), a odbierany przez receptor (Reception) lub maszynę stanów, w której może spowodować wykonanie tranzycji. Jest to zatem pewien rodzaj komunikacji między obiektowej. W czasie obsługi nie następuje zwijanie stosu wywołań oraz niszczenie obiektów stworzonych lokalnie w celu poszukiwania właściwej procedury obsługi wyjątku. W UML 2.0 dostrzeżono to bardzo poważne uchybienie i podjęto starania, aby je wyeliminować. Kolejne podrozdziały opisują w jaki sposób i za pomocą jakich konstrukcji wyjątki są modelowane w języku UML 2.0. Na końcu przedstawiono wnioski oceniające obecne mechanizmy obsługi wyjątków w standardzie. 2.2.1. Diagramy aktywności Diagramy aktywności postrzegane są jako obraz funkcjonalności, ponieważ ilustrują przepływ sterowania oraz logikę wykonywanych czynności. Opisują szczegółowo funkcjonalność w postaci sekwencji akcji i decyzji podejmowanych w czasie ich wykonywania. Zmiany między UML 1.x a 2.0 są znaczące w dziedzinie ich reprezentacji w metamodelu, chociaż część widoczna przez użytkownika, czyli notacja, nie zawiera zbyt wielu zmian. Najbardziej.

(26) ROZDZIAŁ 2. WYJĄTKI W STANDARDZIE UML 2.0. 25. fundamentalną zmianą jest odseparowanie diagramów aktywności od maszyn stanów [59]. W przypadku UML 1.x, [43], s. 2-171, diagramy aktywności były pewnego rodzaju maszyną stanów. W wersji UML 2.0 zostały one zaprojektowane od początku, a nie na bazie maszyny stanów. Pierwotna klasyfikacja była błędna. Istotą diagramów aktywności nie jest przebywanie w pewnym stanie i związane z tym aktywności, czy też tranzycje między stanami, jako reakcja na zdarzenia zewnętrzne. Istotny jest przepływ sterowania i danych w celu wykonania pewnych akcji, niekoniecznie sekwencyjnie (możliwość równoległości) i być może bez udziału środowiska zewnętrznego, zmierzających do końcowej aktywności. Diagramy aktywności w UML 2.0 zostały potraktowane zupełnie oddzielnie i istnieją obok maszyn stanów jako samodzielne jednostki. Otrzymały semantykę zbliżoną do kolorowanych sieci Petriego. Aktywności mogą wykonywać się równolegle, o ile wszystkie dane do wykonania aktywności są dostępne. Klasą określającą diagram aktywności jest Activity. Została zdefiniowana w pakiecie BasicActivities. Dziedziczy ona z klasy Behavior, zatem diagramy te modelują zachowanie. Składają się one z sekwencji akcji, które mogą się rozgałęziać, zapętlać, uwspółbieżniać oraz finalizować w sposób normalny lub też z powodu wyjątku. Klasą implementującą akcje jest Action, zdefiniowana w pakiecie BasicActions. Jest to klasa abstrakcyjna. Akcje posiadają wejścia i wyjścia (OutputPin, InputPin). Na wejściu akcja otrzymuje pewne wartości, które mogą być przez nią przetworzone i zwrócone na wyjściu. Diagram aktywności jest pewnego rodzaju grafem z wierzchołkami, którymi są aktywności oraz krawędziami obrazującymi przejścia między akcjami. Krawędzie łączą wyjścia akcji z wejściami pokazując możliwy przepływ sterowania oraz danych. Stosując analogię z systemami czasu rzeczywistego napisanymi we współczesnych językach programowania, diagramy te mogą zamodelować proces, ewentualnie jego część, który może tworzyć i kończyć wątki w ramach swojej przestrzeni wykonania. Instrukcje, jakie się tam wykonują, oprócz zwykłych operacji arytmetryczno-logicznych, odpowiedników akcji, to instrukcje wykonania warunkowego oraz pętle. Przykładowe diagramy aktywności znajdują się w rozdziale 6, np.: rys. 6.8, s. 112. Standard UML 2.0 semantykę diagramów aktywności wyraża w sposób nieformalny i stąd nieprecyzyjny stosując ideologię zaczerpniętą z sieci Petriego [47], s. 314. Sieci Petriego są znanym formalizmem w wyrażaniu przepływów równoległych [28–31, 55, 65, 67]. Ideę przepływu znaczników, wzbudzania i odpalania tranzycji oraz przebywania znaczników w miejscach za-.

(27) ROZDZIAŁ 2. WYJĄTKI W STANDARDZIE UML 2.0. 26. stosowano w opisie semantyki diagramów aktywności. Istnieją prace, które traktują o tłumaczeniu diagramów aktywności na sieci Petriego [4,38,61,62]. Wierzchołkami w diagramach aktywności są akcje lub struktury sterujące (fork, join, wierzchołki decyzyjne, wierzchołki startowe i końcowe). Znacznik natomiast jest obiektem lub sterowaniem i jest obecny w diagramie w pewnym wierzchołku. W przypadku znacznika sterowania, identyfikuje on gdzie znajduje się obecnie sterowanie. Jest przekazywany po krawędziach do następnej akcji. W przypadku wierzchołka rozwidlającego ForkNode, sterowanie jest powielane na wszystkie krawędzie wychodzące z tego wierzchołka (tworzenie wątków). Odwrotnie jest w przypadku wierzchołka JoinNode, gdzie sterowania z wchodzących krawędzi są redukowane do jednego wychodzącego (zakończenie wątków). Znaczniki, które są obiektami, przepływają jako parametry wyjściowe pewnego wierzchołka do następnego, ale już jako parametry wejściowe. Znaczniki są transportowane krawędziami. Wierzchołek będący akcją zostaje wykonany, kiedy wszystkie warunki narzucane na znaczniki wejściowe są spełnione. Po wykonaniu wszystkie znaczniki są zabierane z krawędzi wejściowych i odpowiednie znaczniki, w zależności już od konkretnej akcji są wystawiane na krawędzie wyjściowe. Taka reprezentacja diagramów aktywności umożliwia równoległe wykonanie o ile wierzchołki nie są w tym samym przepływie, np.: utworzenie nowego wątku za pomocą wierzchołka sterującego ForkNode. Równoległe wykonanie jest również możliwe poprzez powielenie sterowania na wyjściu z akcji, czyli z jednej akcji wychodzi kilka krawędzi do innych akcji (ang. implicit fork [47], s. 302). Opisane w podrozdziale 2.1.2 poziomy zgodności w przypadku diagramów aktywności realizują pakiety przedstawione między innymi na rys. 2.4. Poziom L1 definiuje pakiet BasicActivities odpowiadający za podstawowe cechy diagramów aktywności. Poziom L3 traktuje również o kompatybilności w obszarze obsługi wyjątków poprzez pakiet ExtraStructuredActivities. Na poziomie L3 znajduje się również CompleteStructuredActivities i CompleteActivities, które w pełni umożliwiają zaawansowane modelowanie aktywności poprzez udostępnienie notacji pętli, warunkowych wykonań oraz innych. Rozważając poziomy zgodności należy dodać, że na poziomie L2 znajdują się pakiety: StructuredActivities i IntermediateActivities, które udostępniają między innymi mechanizmy do modelowania współbieżności. Wyjątki w diagramach aktywności mogą być zgłoszone, jak i obsłużone. Zgłoszenie wyjątku odbywa się poprzez akcję RaiseExceptionAction zdefi-.

(28) ROZDZIAŁ 2. WYJĄTKI W STANDARDZIE UML 2.0. Rysunek 2.4. Package Merges c °OMG 2.0 [44]. 27.

(29) ROZDZIAŁ 2. WYJĄTKI W STANDARDZIE UML 2.0. 28. Rysunek 2.5. Activities/ExtraStructuredActivities/Exceptions c °OMG 2.0 [44]. niowaną w pakiecie StructuredActions. Pakiet ten znajduje się na poziomie zgodności L2. Obsługa wyjątków, czyli specyfikacja klasy ExceptionHandler, znajduje się w pakiecie ExtraStructuredActivities, czyli na poziomie L3. Pojawia się tu pewna niespójność, ponieważ jeśli wyjątki mają być obsługiwane na pewnym poziomie zgodności, musi to następować kompleksowo. Jeśli użytkownikowi zostanie udostępniony mechanizm zgłaszania wyjątków na pewnym poziomie zgodności, musi on być całościowy, a nie połowiczny, aby miał w ogóle sens (Problem 1, s. 43). Na rys. 2.5 przedstawiono klasę ExceptionHandler (EH), czyli procedurę obsługi wyjątku. EH jest w relacji kompozycji jeden do wielu z klasą ExecutableNode (EN), czyli EN może posiadać wiele lub nie posiadać w ogóle EH. Nazwy protectedNode i handler są nazwami Elementów relacji, czyli EH jest identyfikowany jako handler przez EN, a EN jako protectedNode przez EH. Ograniczenia jakie zostały nałożone na element handler to subsets ownedElement oznacza, że zbiór możliwych obiektów identyfikowanych jako handler jest podzbiorem obiektów identyfikowanych jako ownedElement. Natomiast zbiór ownedElement stanowią wszystkie obiekty, które są traktowane jako elementy przynależne do EN. Właściwość tę EN odziedziczył w sposób pośredni z elementu Element, który jest atomem języka UML. Element nie dziedziczy już z żadnej klasy, a dziedziczą z niego wszystkie inne klasy z pakietu InfrastructureLibrary i SuperstructureLibrary. Jeśli zatem jakaś klasa w ograniczeniu relacji posiada: subsets ownedElement, należy to rozumieć w taki sposób, że elementy tej relacji dodają się do istniejącego zbioru ownedElement stając się podzbiorem całości. W sposób analogiczny należy rozumieć ograniczenie subsets owner, tylko że z punktu widzenia drugiego elementu relacji, który też dziedziczy z obiektu Element. Element może zatem być w relacji kompozycji do posiadanych obiektów,.

(30) ROZDZIAŁ 2. WYJĄTKI W STANDARDZIE UML 2.0. 29. Rysunek 2.6. Classes/Kernel/Root c °OMG 2.0 [44]. Rysunek 2.7. Procedura obsługi wyjątków - notacja c °OMG 2.0 [44] s. 352. również klasy Element, jak również może być kompozycją innego obiektu klasy Element, dokładnie jak ilustruje to rys. 2.6. EN jest klasą abstrakcyjną, z której dziedziczą akcje lub inne wierzchołki w diagramie aktywności (rys. 2.9). Na uwagę zasługuje fakt, że EH jest w relacji kompozycji tylko z jednym EN. Ten sam EH nie może zatem obsługiwać więcej niż jeden EN. Najbardziej interesującym przypadkiem jest, gdy EN jest akcją albo wierzchołkiem strukturalnym, StructuredActivityNode. Kiedy EH ma zostać uruchomiony wykonuje się jego handlerBody, którym jest akcja albo pewien wierzchołek specjalny StructuredActivityNode. Notacja zdefiniowana do modelowania procedury obsługi wyjątków została zilustrowana na rys. 2.7. EH jest skojarzony poprzez relację asocjacji z wierzchołkiem obiektowym (ObjectNode), poprzez relację o jednym z końców exceptionInput, gdzie pojawia się znacznik z obiektem, który ma być zgłoszony jako wyjątek. Pojawienie się znacznika w tym miejscu umożliwia wykonanie procedury.

(31) ROZDZIAŁ 2. WYJĄTKI W STANDARDZIE UML 2.0. 30. Rysunek 2.8. Actions/StructuredActions/RaiseActions c °OMG 2.0 [44]. obsługi, podobnie jak pojawienie się znacznika przed tranzycją w sieciach Petriego. EH posiada również listę wyjątków jakie może obsługiwać. Są one identyfikowane przez koniec relacji asocjacji exceptionType i może nim być dowolny obiekt dziedziczący z Classifier. Nie może to być Classifier bezpośrednio, gdyż jest on klasą abstrakcyjną. Classifier wydaje się być zbyt szeroko określonym typem, gdyż wyjątkiem w tej sytuacji mógłby być obiekt typu relacja asocjacji (Association), który dziedziczy z Classifier, co jest niedopuszczalne (Problem 3, s. 45). Zgłoszenie wyjątku następuje przez akcję RaiseExceptionAction (REA) (rys. 2.8), zatem jeśli wyjątek ma być obsłużony, to EH musi być powiązany relacją kompozycji z jednym z wymienionych elementów, które dziedziczą z EN, tj.: • akcją go zgłaszającą; • akcją, która wywołuje inne zachowanie, czyli CallAction; • wierzchołkiem strukturalnym, czyli StructuredActivityNode. CallAction jest klasą abstrakcyjną zdefiniowaną w pakiecie BasicActions. Jest to akcja, która wywołuje pewne zachowanie oraz zwraca na swoim wyjściu wartości powrotu. Z klasy tej dziedziczą dwie akcje: CallBehaviorAction (CBA) oraz CallOperationAction (COA). CBA jest akcją, która wywołuje pewne zachowanie, z którym jest skojarzona relacją asocjacji. Zachowanie to jest zatem znane w sposób statyczny na etapie budowy modelu i jest dokładnie jedno. Nie zależy od obecnego wykonania programu (ang. runtime). Przykładem może być wywołanie pewnej aktywność zdefiniowanej jako oddzielny byt. Wyrażając się w terminologii C++, np.: wywołanie funkcji globalnej. Operacja zidentyfikowana przez nazwę jest znana w sposób statyczny i nie zależy od obecnego wykonania programu. COA, natomiast jest akcją wywołującą operację pewnego obiektu docelowego otrzymywanego na wejściu, który decyduje jakie zachowanie będzie.

(32) ROZDZIAŁ 2. WYJĄTKI W STANDARDZIE UML 2.0. 31. wywołane. Przykładem może być wywołanie operacji, która jest implementowana za pomocą aktywności. Stosując analogię do języka C++ przykładem mogą być funkcje wirtualne, gdy sama nazwa funkcji i obiektu nie identyfikuje jednoznacznie użytej metody. Operacja zidentyfikowana przez nazwę nie jest znana w sposób statyczny, zależy od wykonania programu oraz wymaga obiektu, aby mogła być zidentyfikowana. StructuredActivityNode jest wierzchołkiem, którego celem jest możliwość zgrupowania innych wierzchołków. Został on przedstawiony na rys. 2.9. Dziedziczy z ActivityGroup, przez co może zawierać w sobie inne wierzchołki i krawędzie aktywności. Dziedziczy również z Action, posiada zatem swoje wejście i wyjście. rys. 2.10. Funkcjonalnie odpowiada fragmentowi diagramu aktywności. Dziedziczą z niego następujące elementy: • ConditionalNode - odpowiednik instrukcji sterującej warunkowej if z języków programowania; • LoopNode - pętla; • SequenceNode - sekwencja akcji wykonywana w kolejności; • ExpansionRegion - akcje wykonywane za każdym razem na nowo dla kolekcji wartości wejściowych. Semantyka przepływu wyjątków jest częścią semantyki diagramów aktywności. Akcja zgłaszająca wyjątek na swoim wejściu otrzymuje obiekt, który ma być zgłoszony jako wyjątek. Następuje przerwanie wykonania aktywności, w której ta akcja się znajduje i poszukiwanie procedury obsługi [47], s. 302. Najpierw sprawdzane jest, czy taka aktywność istnieje w akcji zgłaszającej wyjątek lub też w wierzchołku strukturalnym typu StructuredActivityNode (pętla, wyrażenie jeżeli). Akcją zgłaszającą wyjątek może być albo RaiseExceptionAction, albo CallAction. Jeśli nie znajdzie się takiej aktywności, poszukiwanie następuje poziom wyżej, w zagnieżdżonej przestrzeni wywołań. Jeśli wyjątek nie będzie obsłużony nawet na najwyższym poziomie, to zachowanie systemu nie jest zdeterminowane [47], s. 352. Standard nie precyzuje również, czy w przypadku wierzchołka typu ForkNode, kiedy tworzona jest nowa gałąź, wyjątki w niej są odseparowane, co oznacza, że zgłoszenie wyjątku w takiej gałęzi nie powoduje przerwania wykonywania równoległych gałęzi. Takie podejście zastosowano w kompilatorach współczesnych języków programowania: C++ [64] [33], Java [69]. Stos wywołań należy tam do wątku i jeśli tylko procedura obsługi wyjątku nie znajduje się na stosie wywołań, to wątek jest przerywany z powodu nieobsłużonego wyjątku. UML nie precyzuje z czym ma być związany stos wywołań. Jeśli diagramy aktywności mają semantykę zbliżoną do kolorowanych sieci Petriego, ich fizyczna implementacja.

(33) ROZDZIAŁ 2. WYJĄTKI W STANDARDZIE UML 2.0. Rysunek 2.9. Activities/StructuredActivities/StructuredNodes c °OMG 2.0 [44]. 32.

(34) ROZDZIAŁ 2. WYJĄTKI W STANDARDZIE UML 2.0. 33. Rysunek 2.10. Activities/Complete/StructuredActivities/StructuredNodes c °OMG 2.0 [44]. ze względu na możliwość równoległego wykonywania niekoniecznie musi być oparta na tworzeniu stosu wywołań dla każdej gałęzi. Wydaje się to być niewłaściwym rozwiązaniem. W rozprawie zakłada się, że stos wywołań, związany jest z obiektem aktywnym, tak więc ani ForkNode, ani wspomniany implicit fork (podrozdział 2.2.1) nie powodują stworzenia nowego stosu wywołań dla obsługi wyjątków. Nie obsłużony wyjątek, a zgłoszony w pewnej gałęzi, dotrze do zachowania startowego powiązanego obiektu aktywnego i spowoduje zakończenie wykonania tego obiektu aktywnego. Każde zachowanie wykonuje się w kontekście pewnego obiektu aktywnego [47], s. 9, punkt 6.3.1 Procedura obsługi, handler, ma jedno wejście, które jest tożsame z wejściem do EH, a wyjście dokładnie takie samo, tzn. taka sama liczba parametrów o zgodnych typach, jak w przypadku wyjście z akcji lub wierzchołka strukturalnego, z którym jest związana. Sterowanie z wierzchołka chronionego do następnego jest przekazywane w momencie, kiedy procedura obsługi wyjątku się zakończy. EH po swoim wykonaniu wyjście przekierowywuje na wyjście protectedNode, tj.: akcji, aktywności, wierzchołka strukturalnego, [47], s. 352. W standardzie istnieje również pojęcie InterruptibleActivityRegion (IAR). W pracy [62] można znaleźć propozycję użycia IAR jako regionu chroniącego fragment aktywności. IAR został jednak wprowadzony, aby obsługiwać przerwania, a nie wyjątki. Kiedy znacznik wydostanie się poza IAR, wszystkie przepływy w IAR są kończone. Nie następuje jednak poszukiwanie.

(35) ROZDZIAŁ 2. WYJĄTKI W STANDARDZIE UML 2.0. 34. Rysunek 2.11. InterruptibleActivityRegion przykład, c °OMG 2.0 [47], s. 368. procedury obsługi, a jedynie przekazanie sterowania w inne miejsce diagramu aktywności (rys. 2.11). 2.2.2. Klasy behawioralne Kluczową klasą w dziedzinie opisu zachowania jest abstrakcyjna klasa Behavior przedstawiona na rys. 2.12. Została ona zdefiniowana w pakiecie BasicBehaviors (poziom zgodności L1, podrozdział 2.1.2), następnie rozszerzona w CompleteActivities (L3). Pierwsza definicja w BasicBehaviors, zaopatruje klasę Behavior w atrybut isReentrant typu Boolean. Jeśli atrybut jest ustawiony na true, to zachowanie może być wykonane ponownie, mimo że poprzednie wykonanie jeszcze się nie zakończyło. Jeśli jest ustawiony na false, wówczas zachowanie nie będzie wywołane, o ile zostało już raz wywołane i nie zakończyło swojego działania. Rozszerzenie w pakiecie CompleteActivities nie dodaje żadnych atrybutów, a jedynie przedefiniowywuje relacje ownedParameter. Zachowanie, gdy jest wywołane, oczekuje listy parametrów, które odzwierciedla relacja ownedParameter. Parameter może być typu ParameterEfectKind czyli: wejściowy (in), wyjściowy (out), wejściowo-wyjściowy (inout) albo powrotu (return). Relacja ta została przedefiniowana i uściślona w pakiecie CompleteActivities poprzez rozszerzenie definicji parametrów rys. 2.13. Do ich właściwości dodano atrybut isStream, jeśli parametr jest strumieniem oraz isException, jeśli jest parametrem przekazanym w czasie zgłaszania wyjątku. Atrybut isException stosuje się tylko do parametrów wyjściowych. Jeśli na wyjściu, które będzie przekierowane do wejścia procedury obsługującej.

(36) ROZDZIAŁ 2. WYJĄTKI W STANDARDZIE UML 2.0. Rysunek 2.12. CommonBehaviors/BasicBehaviors c °OMG 2.0 [44]. 35.

(37) ROZDZIAŁ 2. WYJĄTKI W STANDARDZIE UML 2.0. 36. Rysunek 2.13. Activities/CompleteActivities/Parameters c °OMG 2.0 [44]. wyjątki, pojawi się znacznik z takim atrybutem, wówczas cały przepływ w aktywności ulega przerwaniu i wyjście nie jest przekazywane do następnej akcji, lecz następuje poszukiwanie procedury obsługi. Aktywność zatrzymuje się. Nie jest to zakończenie, gdyż na wyjściu z aktywności nie pojawiają się żadne wartości [47] s. 384. Z klasy Behavior dziedziczą: diagramy aktywności (Activity), maszyny stanów (StateMachine) oraz interakcje (Interaction), czyli wszystkie elementy języka opisujące pewne zachowanie. Hierarchię najistotniejszych klas UML 2.0 przedstawiono na rys. 2.14 wraz z zawieraniem się pakietów na rys. 2.4. Przedstawia on najczęściej omawiane klasy w rozprawie z perspektywy ich relacji dziedziczenia. Jednocześnie prezentuje najważniejsze elementy języka UML, którymi zainteresowany jest bezpośrednio końcowy użytkownik. Rys 2.12 przedstawia również abstrakcyjną klasę BehavioredClassifier (BC). Dziedziczą z niej powszechnie używane klasy: klasa (Class), diagramy przypadków użycia (UseCase) oraz diagramy współdziałania (Collaboration) (rys. 2.14). Z Class dziedziczą również elementy języka służące do modelowania fizycznych elementów oprogramowania, takich jak: pliki czy biblioteki dynamicznie dołączane w czasie wykonywania, tabele w bazach danych i inne. Należą do nich: Component, Device czy ExecutionEnvironment. Zachowanie.

(38) ROZDZIAŁ 2. WYJĄTKI W STANDARDZIE UML 2.0. Rysunek 2.14. Classifiers Hierarchy c °OMG 2.0 [44]. 37.

(39) ROZDZIAŁ 2. WYJĄTKI W STANDARDZIE UML 2.0. 38. jest więc, poprzez relację kompozycji ownedBehavior, częścią wyżej wymienionych elementów, które charakteryzują się cechami dynamicznymi, czyli mogą realizować funkcjonalność. UseCase są diagramami ilustrującymi pewien możliwy wariant użycia modelowanego systemu z punktu widzenia użytkownika. Diagramy współdziałania - Collaboration grupują pewną liczbę klas lub obiektów wraz z powiązaniami między nimi w celu zrealizowania pewnego scenariusza. Component jest modularną częścią systemu ukrywającą względem otoczenia swoją zawartość. Component w rzeczywistym świecie realizowany jest przez pewien Artifact będący z nim w relacji zależności oznaczonej stereotypem <<manifest>>. Operacje i właściwości dostarczane przez Artifact są realizowane przez związany z nim Component, którego funkcjonalność jest zamodelowana za pomocą elementów języka UML. Component może zostać wymieniony na inny realizujący ten sam interfejs w sposób transparentny dla całego systemu. Interfejsy w fizycznej realizacji przypisane są do pewnych Portów - Port. Jeden Port może zawierać wiele Interface. Przypisanie to odgrywa taką rolę, jak analogicznie Component dla pewnego Artifact. Jest to zatem relacja łącząca fizyczne wymagania programu z fizyczną realizacją programu. Inne używane w modelowaniu architektury programu elementy oprócz Component, to Device i ExecutionEnvironment. Pierwszy jest fizycznym zasobem, maszyną z możliwościami obliczeniowymi. Drugi (ExecutionEnvironment) jest przeważnie podelementem Device, w sensie programowym, umożliwiającym wykonywanie modelowanego oprogramowania, np.: system operacyjny. Zarówno Device jak i ExecutionEnvironment posiadają porty, przez które komunikują się ze światem realizując i oczekując pewnych interfejsów. Tworzenie instancji Behavior polega na wykonaniu tego zachowania. Zachowanie może zostać wywołane bezpośrednio za pomocą CallBehaviorAction, która w relacji asocjacji posiada zachowanie, jakie ma być wywołane. Innym sposobem jest przez operację - Operation, która dziedziczy z BehavioralFeature (BF), za pomocą CallOperationAction, gdzie jako parametr musi być przekazany obiekt, którego operacja ma zostać wywołana (rys. 3.5, s. 53). CallOperationAction precyzuje nazwę operacji, która ma być wykonana. Jeśli taka operacja nie jest metodą, nie ma zdefiniowanego zachowania, wówczas CallOperationAction powoduje wysłanie CallEvent z nazwą operacji. Zdarzenie to może być obsłużone przez akcję AcceptCallAction jako wywołanie asynchroniczne [47], s. 228..

(40) ROZDZIAŁ 2. WYJĄTKI W STANDARDZIE UML 2.0. 39. Aktywności czy maszyny stanów nie muszą zawsze implementować zachowań obiektów, lecz mogą nie być związane z żadnym obiektem. Analogicznie do funkcji w C++. Kontekst zachowania, czyli relacja o końcu context z rys. 2.12, jeśli istnieje, to jest on co najwyżej jeden. Jest to pewna klasa BC, czyli Class, UseCase albo Collaboration, do której zachowanie należy. Jeśli zachowanie bezpośrednio należy do obiektu będącego BC, czyli jest z nim w relacji poprzez ownedBehavior lub przez classifierBehavior albo jest implementacją operacji tego obiektu, wówczas kontekst jest tym obiektem. W przeciwnym razie poprzez relację owner, dziedziczoną z klasy Element, idąc w górę można dojść do pewnej klasy BC. Wartością context jest wówczas pierwsza napotkana taka klasa. Przykładem może być aktywność wejściowa do maszyny stanów, wówczas kontekstem jest najbliższa klasa, która jest właścicielem tego zachowania w sensie relacji owner, czyli w tym przypadku maszyna stanów. Kontekst może nie istnieć, np.: samoistna aktywność startowa programu nie będąca metodą ani zachowaniem żadnej klasy, odpowiednik funkcji main w C++. Wtedy zachowanie jest w swoim własnym kontekście i nie ma innego BC który byłby jego właścicielem. Wartość context powinna być wyprowadzona, gdyż wynika z pozostałych innych atrybutów. Kontekst jest atrybutem pochodnym wynikającym z treści modelu. Wydaje się to być błędem standardu, który nie przypisuje temu atrybutowi właściwości wyprowadzony (Problem 2, s. 45). Relacja classifierBehavior (rys. 2.12), specyfikuje, że zachowanie może być zachowaniem startowym klasy BC i jest uruchamiane, kiedy instancja BC jest tworzona [47], s. 420. Istnieje również akcja w diagramach aktywności, StartClassifierBehaviorAction, która zgodnie ze specyfikacją standardu rozpoczyna zachowanie. Nie uruchamia ona wbrew swojej nazwie zachowania classifierBehavior, gdyż ono uruchamia się zaraz po skonstruowaniu obiektu. Na wejściu otrzymuje obiekt, który jest zachowaniem. Standard precyzuje, że takim zachowaniem może być maszyna stanów lub zachowanie, którego kod jest napisany w innym języku [47], s. 275. Relacja redefinedBehavior określa zachowanie, które zostało przedefiniowane. Odpowiada to przeładowaniu funkcji w języku C++, kiedy operacje przyjmują takie same nazwy parametry, ale mają różne implementacje. Atrybut ten również powinien być wyprowadzony. Klasa BC zawiera zachowania poprzez relację ownedBehavior. Identyfikuje ona zachowania, które są zdefiniowane w przestrzeni BC. Inną ważna klasą związaną z aspektem behawioralnym jest klasa Be-.