Projektowanie systemw informacyjnych Wykad 7 Model obiektowy 4

Projektowanie systemów informacyjnych Wykład 7 Model obiektowy (4) Ewa Stemposz, Kazimierz Subieta Instytut Podstaw Informatyki PAN, Warszawa Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 1

Zagadnienia Dziedziczenie asocjacji Asocjacje pochodne Redukcja liczności Role wielowartościowe Trochę więcej o agregacji Agregacja rekursywna Trochę więcej o asocjacji kwalifikowanej Trochę więcej o mechanizmach rozszerzalności E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 2

Dziedziczenie asocjacji (1) K 1 {incomplete} a K 1 K 2 K 3 a K 4 a K 2 K 3 K K Aby asocjacje a (diagram po lewej stronie) mogły zostać zastąpione jedną asocjacją a poprowadzoną od nadklasy K 1 do klasy K (diagram po prawej stronie) obie asocjacje a z diagramu po lewej stronie muszą spełniać następujące warunki: § muszą mieć tą samą semantykę, § muszą mieć tą samą strukturę, § asocjacja a musi łączyć klasę K z wszystkimi podklasami klasy K 1. E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 3

Dziedziczenie asocjacji (2) Termin godz. Referat 1. . * tytuł autorzy [1. . *] Nazwa dla klasy asocjacji ? wygłaszany 0. . 1 wygłaszany Zwykły ocena 1. . * 0. . 1 Zaproszony Termin godz. wygłaszany Termin godz. E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 4 Sesja nazwa data 1 Zastosowanie dziedziczenia asocjacji spowodowało, że część informacji nie została przeniesiona na nowy diagram (zmiany zostały oznaczone czerwonym kolorem).

Asocjacje pochodne Osoba 1. . * mieszka 1. . * 1 pracodawca Firma Miasto 1 pracuje w ? 0. . 1 1 znajduje się 1. . * Możliwe asocjacje pochodne: /mieszka lub /znajduje się E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 5 1) Jeśli Osoba mieszka w mieście w którym pracuje, to któraś z asocjacji: mieszka lub znajduje się powinna zostać oznaczona jako pochodna (albo usunięta z diagramu). 2) Jeśli liczność roli pracodawca wynosi 0. . 1 asocjacja mieszka nie będzie pochodna, ponieważ nie dla wszystkich obiektów powiązania będą mogły być wydedukowane.

Redukcja liczności Wykorzystanie klasy pośredniczącej dla redukcji liczności związków wiele-do-wielu K 1 x y K 2 K 1 1 K a 1 a 2 K a 1 y a 2 x 1 K 2 gdzie: x, y oznaczają liczności wiele Przykład Osoba 1. . * * Firma 1. . * Zatrudnienie Osoba stanowisko pensja E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 6 Zatrudnienie 1 stanowisko * pensja 1 1. . * * /pracodawca Firma

Role wielowartościowe (1) Rola wielowartościowa to taka rola, dla której górna granica liczności jest większa od 1. Przyjmuje się domyślnie: 1 * K 1 r 2 K 2 Rola r 2 jest tu rolą wielowartościową. Uwaga: W sensie dosłownym, liczności obu końców asocjacji oznaczają liczności obu ról. § zbiór obiektów, opisujący daną rolę, jest nieuporządkowany, § dany obiekt pojawia się tylko jeden raz w w zbiorze obiektów opisującym rolę, § powyższe reguły mogą zostać zmienione dzięki ograniczeniom {ordered}, {bag} i stereotypowi «history » . Ograniczenie {ordered} pozwala na uporządkowanie zbioru obiektów opisującego daną rolę. a K 1 a 1. . 2 K 2 E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 7 : K 2 a : K 2 : K 1 {ordered} * a : K 1 : K 2

Role wielowartościowe (2) Dwa powiązania między dwoma tymi samymi obiektami występują też w sytuacji, jak poniżej, ale nie są to powiązania o tej samej semantyce, jak w przykładzie poprzednim. pracuje 0. . 1 * Osoba {subset} Firma Nowak : Osoba 0. . 1 1 jest dyrektorem Ograniczenie: {bag} : Zatrudnienie {bag} Osoba IBM : Firma 1. . * * Firma X: Osoba Zatrudnienie data zatrudnienia data zwolnienia stanowisko pensja E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 8 01. 1990 15. 12. 1995 programista 2000 : Zatrudnienie 01. 1998 NULL analityk 5000 Y: Firma

Role wielowartościowe (3) Stereotyp: «history» dla oznaczenia roli pracodawca Osoba * 1. . * «history » pracodawca Firma : Zatrudnienie data zatrudnienia data zwolnienia stanowisko pensja : Osoba 01. 1990 15. 12. 1995 programista 2000 : Zatrudnienie Stereotyp «history» , podobnie jak ograniczenie {bag}, pozwala na utworzenie więcej niż jednego powiązania o danej semantyce między dwoma obiektami, ale wykorzystywanie go jest raczej ukierunkowane na rejestrowanie zmian w czasie. E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 9 01. 1998 NULL analityk 5000 : Firma

Role wielowartościowe (4) Zatrudnienie Osoba * data zatrudnienia data zwolnienia stanowisko pensja 1. . * Firma : Zatrudnienie 01. 1990 15. 12. 1995 programista 2000 : Firma : Osoba Zastosowanie klasy pośredniczącej Zatrudnienie wprawdzie pozwala na utworzenie wielu powiązań pracuje między dwoma tymi samymi obiektami, wystąpieniami klas Osoba i Firma, ale nie uwidacznia tego faktu. E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 10 : Zatrudnienie 01. 1998 NULL analityk 5000

Agregacja (1) Agregacja jest rodzajem asocjacji; zadaniem agregacji jest modelowanie związku całość-część. aagregacja jest asocjacją: dla obu jej końców są określane liczności, a także może mieć atrybuty, np. Grupa * 1. . 15 Student Termin od do a agregacja jest wykorzystywana do modelowania związku całość-część Grupa * całość 1. . 15 część E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 11 Student

Agregacja (2) Inne nazwy dla ról agregacji: całość część askłada się z azawiera aobejmuje, itp. awchodzi w skład anależy ajest zawarta w, itp. Nazwa agregacji i nazwy jej ról, jako oczywiste, są pomijane ! Własności agregacji: A B § jest relacją niesymetryczną, tzn. jeśli B jest częścią A, to A nie jest częścią B C § jest relacją przechodnią (tranzytywną), tzn. jeśli C jest częścią B i B jest częścią A, to C jest częścią A E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 12

Agregacja (3) Kryteria służące analitykowi pomocą w podjęciu decyzji czy do modelowania pojęciowego wykorzystać agregację, czy też zwykłą asocjację. § kryterium istnienia (część nie istnieje samodzielnie bez całości), § kryterium wstawiania (nie ma sensu wstawianie części do systemu, jeśli nie wstawiono do niego całości), § kryterium usuwania (usuwanie całości powinno skutkować usunięciem wszystkich powiązanych z tą całością części), § kryterium fizycznej części. zmień plan Grupa * 1. . 15 plan zmień plan Student Termin od do zmień plan Wszystkie kryteria zawiodły, a mimo to zdecydowano się zastosować agregację, ponieważ lepiej niż zwykła asocjacja modeluje związek część-całość - pewne operacje można wykonywać na całości, a nie na każdej z części oddzielnie. Operacja zmień plan została oznaczona jako ta, która będzie automatycznie wykonana dla wszystkich części, wtedy gdy zostanie wywołana dla całości (propagacja operacji). E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 13

Agregacja rekursywna (1) Agregacja rekursywna ? K Obiekt klasy K może zarówno wchodzić w skład innych obiektów klasy K, jak i zawierać obiekty klasy K. ? K 0. . 1 : K : K a Co by było, gdyby któryś z końców tej agregacji (lub oba końce) oznaczyć licznością dokładnie 1 zamiast liczności opcjonalnej 0. . 1 ? a Jakie zmiany wprowadziłoby do powyższego diagramu zastosowanie zwykłej asocjacji zamiast agregacji ? a Czy można tu zastosować kompozycję? E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 14

Agregacja rekursywna (2) K 0. . 1 : K * : K : K : K a Czy można tu zastosować liczność dokładnie 1 zamiast 0. . 1 i liczność 1. . * zamiast liczności * ? I Część 0. . 1 nazwa materiał rozmiary II Firma * 1 * Oddział 0. . 1 * b Dla którego z obu powyższych diagramów możliwość zastosowania kompozycji wydaje się być bezdyskusyjna? E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 15

Agregacja rekursywna (3) * K : K * : K : K : K Przykłady agregacji rekursywnych I Program Instrukcja 0. . 1 złożona II 2 -gi operand 1 1. . * a Jak wyglądałby diagram obiektowy dla wyrażenia, np. * 1 -szy operand 1 Blok Instrukcja prosta * * E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 16 1 (x + y/2) * (x/3 - y) Człon Wyrażenie Zmienna operator binarny nazwa Stała wartość

Asocjacja kwalifikowana (1) Katalog 1 Katalog nazwa pliku * Plik nazwa 1 0. . 1 { nazwa pliku jest unikatowa w ramach katalogu } Plik Perspektywa pojęciowa - plik jest w ramach katalogu jednoznacznie identyfikowany przez nazwę. Perspektywa projektowa - wskazanie na to, że katalog plików można zorganizować jako tablicę asocjacyjną lub słownik (przeszukiwanie za pomocą nazwy pliku). E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 17

Asocjacja kwalifikowana (2) 1 Tablica 100 Kwadrat rząd kolumna 1 1 Kwadrat Kwalifikator asocjacji może stanowić więcej niż jeden atrybut. Warunek - wartości tych atrybutów muszą pozwolić na jednoznaczną identyfikację obiektu w ramach pewnego zbioru obiektów (tutaj - w ramach zbioru kwadratów należących do jednej konkretnej tablicy, czyli jednego obiektu klasy Tablica). Asocjacja kwalifikowana, jak każda asocjacja, może posiadać atrybuty. Bank * * nazwa Osoba imię nazwisko nr konta data założ. E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 18 Bank nazwa Osoba nr. konta * 0. . 1 imię nazwisko data założ.

Mechanizmy rozszerzalności w UML W UML istnieją trzy rodzaje mechanizmów rozszerzalności: § stereotypy, § wartości etykietowane, § ograniczenia. Stereotypy § Stereotypy umożliwiają meta-klasyfikację elementów modelu. § Istnieje lista stereotypów dla każdego rodzaju elementów modelu (elementu metamodelu UML), np. relacji między przypadkami użycia, klas czy metod. § Dany element modelu (np. jedna relacja między przypadkami użycia, klasa czy metoda) może mieć co najwyżej jeden stereotyp. § Są stereotypy predefiniowane, ale użytkownicy mogą też definiować własne. § Stereotypy rozszerzają semantykę metamodelu. E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 19

Stereotypy - notacja Notacja: zwykle «nazwa stereotypu» lub ikona, ale można też używać koloru czy tekstury, choć z różnych względów nie jest to polecane (ograniczenia ludzkie lub sprzętu). « lub » guillemets - jeden znak - używany w charakterze cudzysłowia w jęz. francuskim (a) (c) «sterowanie» PióroŚwietlne lokacja: Punkt uruchom (Tryb) (b) PióroŚwietlne lokacja: Punkt uruchom (Tryb) «sterowanie» PióroŚwietlne lokacja: Punkt uruchom (Tryb) ikona (d) PióroŚwietlne Ikona może być używana na 2 sposoby: zamiast symbolu stereotypu (c, d) lub razem z nim (b). W przypadkach a, b, c zawartość elementu modelu opatrzonego stereotypem (tu: klasy Pióro Świetlne) jest widoczna. W przypadku d została opuszczona. E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 20

Stereotypy; przykłady P 1 «include» P 3 P 2 «extend» P 4 rodzaj elementów modelu: relacje między przypadkami użycia lista stereotypów dla tego rodzaju: «include» i «extend» Każda relacja między przypadkami użycia (element modelu) jest opatrzona jednym z dwóch stereotypów z powyższej listy. «trwała» Prostokąt punkt 1: Punkt punkt 2: Punkt «konstruktory» Prostokąt (p 1: Punkt, p 2: Punkt) «zapytania» obszar () : Real aspekt() : Real «zapytania» obszar () : Real aspekt () : Real . . . «aktualizacje» przesuń (delta: Punkt) przeskaluj (współczynnik: Real) «» przesuń (delta: Punkt) przeskaluj (współczynnik: Real) E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 21 Jednym stereotypem można opatrzyć całą listę elementów modelu. Koniec listy może być oznaczany przez «» .

Wartości etykietowane są używane do skojarzenia arbitralnej informacji z pojedynczym elementem modelu. § Wartość etykietowaną stanowi ciąg znaków o postaci: słowo kluczowe = wartość. Dowolny łańcuch znaków może być użyty jako słowo kluczowe. § Są słowa kluczowe predefiniowane, ale użytkownik może też definiować własne. § Listę wartości etykietowanych (oddzielonych przecinkami) umieszcza się w {}. § Dowolny element modelu może być skojarzony nie tylko z listą wartości etykietowanych, ale w bardziej ogólnym sensie z łańcuchem własności, w postaci: {dowolny łańcuch znaków}. Przykład: {autor = “Jan Nowak”, termin zakończenia = “ 31 Maja 1999”, status = analiza} Wartości etykietowane są szczególnie przydatne do przechowywania informacji związanych z zarządzaniem projektem (jak w przykładzie powyżej) czy szczegółów implementacyjnych. E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 22

Ograniczenia specyfikują restrykcje nakładane na elementy modelu. Mogą stanowić wyrażenia języka naturalnego czy języka formalnego (np. OCL w UML), mogą też przyjmować postać formuły matematycznej lub fragmentu kodu (czy też pseudokodu). Notacja: są zawarte wewnątrz {} i umieszczane za elementem w klasie, lub poza klasą. Mogą też być umieszczane w komentarzu (przykład na następnej folii). Pracownik imię nazwisko pensja {<=10 000} Pracownik imię nazwisko pensja zmień pensję (nowa) ograniczenie dynamiczne Ograniczenie dynamiczne - tu interesuje nas poprzedni stan elementu, na który jest nałożone ograniczenie. Czy powiedzie się próba zmiany pensji z 2500 na 5500? E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 23 ograniczenie statyczne {pensja <=10 000} {pensja nie wzrasta o więcej niż 300}

Ograniczenia; przykłady Symbole, takie jak - - oraz - - > mogą być używane do wskazywania elementów, na które zostały nałożone ograniczenia. 0. . 1 Firma Konto * {xor} * należy do 0. . 1 Osoba podwładny * 0. . 1 szef Osoba 1. . * pracownik {Osoba. pracodawca = Osoba. szef. pracodawca} E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 24 0. . 1 pracodawca Firma ograniczenie w komentarzu

Ograniczenia predefiniowane; przykłady j. angielski j. polski {complete} {podział całkowity} {incomplete} {podział nie całkowity} {disjoint} {podział rozłączny} {overlapping} {podział nierozłączny} {or} {lub} {xor} {albo} {ordered} {uporządkowane} {subset} {podzbiór} {bag} {wielozbiór} {history} {historia} {hierarchy} {hierarchia} {dag} dag - directed acyclic graph {graf acykliczny skierowany} E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 25

Design by Contract (1) W idealnym przypadku ograniczenia powinny być implementowane jako asercje w docelowym języku programowania. Asercje są sercem metody projektowania Design by Contract zastosowanej przez Bertranda Meyer’a w języku Eiffel. Design by Contract nie jest metodą specyficzną dla tego tylko języka - może i powinna być wykorzystana w każdym. Asercja - to wyrażenie typu Boolean (warunek), którego wartość = FALSE prowadzi do błędu. Zwykle asercje są testowane jedynie podczas debuggowania. Design by Contract używa 3 rodzajów asercji: warunek wstępny (precondition) - definiuje, co powinno być spełnione, aby dana operacja wykonała się poprawnie (jak powinien wyglądać “świat sprzed”), warunek końcowy (postcondition) - określa, co będzie po poprawnym wykonaniu operacji (“świat po”), inwariant - asercja, definiowana dla klas posiadających dane, które nie powinny ulec zmianie po wykonaniu operacji; ten warunek musi być zawsze spełniony dla wszystkich wystąpień danej klasy. Na bazie definicji warunków wstępnego i końcowego można sformułować definicję wyjątku (exception) - zachodzi przy spełnionym warunku wstępnym i niemożliwości spełnienia warunku końcowego. E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 26

Design by Contract (2) Warunki, jak powyżej, mają kluczowe znaczenie dla wykonania się operacji i są zupełnie niezależne od kontekstu, w jakim operacja jest wywoływana. Bertrand Meyer stwierdza, że obecność tych warunków należy traktować jako kontrakt wiążący daną operację i operacji wywołujących ją. Operacja gwarantuje: “jeśli wywołasz mnie ze spełnionym warunkiem wstępnym, to obiecuję doprowadzić do stanu, w którym będzie spełniony warunek końcowy” [Meyer 1988, 1992]. Warunki nie narzucają konkretnej implementacji w języku programowania. Przykład: “dane pracownika są usuwane po 2 latach od daty…” warunek wstępny: minęło 2 lata, warunek końcowy: dane pracownika zostały usunięte z zasobów. Kto powinien być odpowiedzialny za poprawność warunków (aby uniknąć nadmiaru kontroli) - w idealnym przypadku: za warunek wstępny - operacja wywołująca, za warunek końcowy i inwarianty - operacja wywoływana. Warunki wstępne i końcowe powinny być dokumentowane łącznie z dokumentowaniem operacji. W idealnym przypadku powinny stanowić część kodu definiującego interfejs. E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 27

Przykład asercji w języku Eiffel Class STACK[T] export nb_elements, empty, full, push, pop, top feature nb_elements : INTEGER; . . . push(x : T) is - Add on top require not full; do. . . ensure not empty; top=x; nb_elements=old nb_elements + 1 end; - push. . . E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 28

Przykład asercji w języku Eiffel (cd. ) invariant 0 nb_elements; nb_elements max_size; empty = (nb_elements = 0) end; - class STACK Inwarianty mogą przybierać wartość = FALSE jedynie w trakcie wykonywania operacji. Przykład Tablica sortuj «postcondition» {po sortowaniu: nie zmienia się liczba elementów; każda wartość pojawia się tyle samo razy, co przed sortowaniem; dla kolejnych wartości x i y zachodzi x <= y } E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 29

OCL - Object Constraint Language (1) OCL jest językiem o notacji tekstowej służącym do specyfikowania warunków, ograniczeń, asercji i zapytań (zapisu wyrażeń ścieżkowych). OCL zawiera pewien zestaw predefiniowanych operatorów do operowania na elementach kolekcji czy typach podstawowych, ale nie jest przeznaczony do zapisywania kodu wykonalnego. Podstawowe elementy składni OCL: § selektor może być nazwą atrybutu (opisującego element) - wtedy zwracana jest albo wartość albo zbiór wartości atrybutu § selektor może być nazwą roli (celu) - wtedy zwracany jest zbiór powiązanych obiektów element. selektor Przykład A a. A m. A 1 r. A B * a. B r. B m. B Niech OA oznacza pewien obiekt klasy A, wtedy: • wyrażenie OA. a. A zwróci wartość atrybutu a. A • wyrażenie OA. r. B zwróci zbiór obiektów klasy B powiązanych z danym obiektem OA E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 30

OCL - Object Constraint Language (2) element. selektor (lista arg) selektor jest nazwą operacji wywoływanej dla elementu, wartością wyrażenia jest tu wynik zwracany przez operację element. selektor (kwalifikator) selector specyfikuje asocjację kwalifikowaną; element plus wartość kwalifikatora jednoznacznie identyfikują zbiór powiązanych obiektów zbiór-> własność-zbioru stanowi nazwę wbudowanej w OCL funkcji na zbiorze, np. select, reject, size zbiór->select (warunek) zwraca podzbiór elementów wyspecyfikowany warunek zbiór->reject (warunek) zwraca podzbiór elementów nie spełniających wyspecyfikowanego warunku zbiór->size zwraca liczność zbioru self specyfikuje aktualnie rozważany obiekt (może być opuszczony, gdy kontekst jest znany) operator np. =, <, >, <=, >=, <>, +, -, *, /, not, and, or, xor E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 31 spełniających

OCL - Object Constraint Language (3) Przykłady lot. pilot. godziny_treningowe >= lot. samolot. min_godz może być wykorzystane do zwrócenia zbioru pilotów, którzy wylatali odpowiednią dla danego samolotu liczbę godzin firma. pracownik->select (tytuł = “szef” and self. raport->size >10) zwróci zbiór pracowników będących szefami, którzy dostarczyli więcej niż 10 raportów E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 32

Zasada zamienialności a ograniczenia Zasada zamienialności (byt programistyczny typu B może zastąpić byt typu A, o ile B jest podtypem A) przenosi się na ograniczenia w sposób wyrażony poniższym potocznym stwierdzeniem: Nie żądaj więcej, nie obiecuj mniej (“demand no more, promise no less”). A m Obiekt klasy B może zastąpić obiekt klasy A, co oznacza, że jego zachowanie z punktu widzenia obiektu wysyłającego komunikat wywołujący metodę m, powinno być takie same, jak gdyby komunikat wysłano do obiektu klasy A. B m Warunek wstępny dla metody m w klasie B - powinien być nie silniejszy niż dla metody m w klasie A; warunek końcowy - nie słabszy niż w klasie A. E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 33

Podsumowanie mechanizmów rozszerzalności a UML dostarczyła kilku mechanizmów rozszerzalności, aby umożliwić projektantom wprowadzanie modyfikacji bez konieczności zmiany samego języka modelowania. Twórcy UML starali się w ten sposób (chociażby w pewnym stopniu) zaspokoić potrzeby specyficznych dziedzin problemowych czy środowisk programowych. a Narzędzia mogą przechowywać wprowadzone modyfikacje oraz manipulować nimi bez konieczności wnikania w ich semantykę - modyfikacje z reguły są przechowywane w postaci łańcuchów znakowych. a Narzędzia mogą ustanowić własną składnię i semantykę dla obsługi mechanizmów rozszerzalności. a Należy pamiętać, że rozszerzenia stanowią z definicji odstępstwo od standardów UML, i że w naturalny sposób prowadzą do utworzenia pewnego dialektu UML, a to z kolei może prowadzić do problemów z przenaszalnością. Trzeba zawsze dobrze rozważyć zyski i straty możliwe do poniesienia dzięki korzystaniu z tych mechanizmów, szczególnie wtedy, gdy “stare” standardowe mechanizmy pracują wystarczająco dobrze. E. Stemposz, Analiza i Projektowanie Systemów Informatycznych, Wykład 7, Slajd 34