Nadstruktura języka UML w wersji 2.2

Prezentacja na temat: "Nadstruktura języka UML w wersji 2.2"— Zapis prezentacji:

1 Nadstruktura języka UML w wersji 2.2
Część II Modelowanie struktury – klasy (pakiet UML::Classes)

2 Pakiet UML::Classes – struktura

3 Pakiet UML::Classes::Kernel
Zależności od pakietów infrastruktury

4 Pakiet Kernel – diagram bazowy

5 Pakiet Kernel – diagram przestrzeni nazew-niczych

6 Pakiet Kernel – diagram krotności

7 Pakiet Kernel – diagram wyrażeń

8 Pakiet Kernel – diagram instancji

9 Pakiet Kernel – diagram ograniczeń

10 Pakiet Kernel – diagram klasyfikatorów

11 Pakiet Kernel – diagram klasyfikatorów – dodatkowe atrybuty i powiązania
RedefinableElement::isLeaf – określa czy dana instancja rzeczywiście może być przedefiniowana true – brak możliwości przedefiniowania Domyślnie: false Generalization::isSubstitutable – określa czy klasyfikator specyficzny może być użyty w miejsce klasyfikatora ogólnego (domyślnie: true) Classifier::redefinedClassifier – klasyfikatory (zagnieżdżone) przedefiniowane przez bieżący klasyfikator UML::Classes::Kernel dodaje możliwość przedefiniowywania zagnieżdżonych klasyfikatorów

12 Pakiet Kernel – diagram cech

13 Pakiet Kernel – diagram cech – dodatkowe atrybuty i powiązania
Feature::isStatic – określa czy dana cecha charakteryzuje instancje klasyfikatora (false – wartość domyślna), czy sam klasyfikator (true) StructuralFeature::isReadOnly – określa czy wartość cechy może być modyfikowana przez klienta false (domyślna) – może być modyfikowana true – nie może być modyfikowana Parameter::defaultValue – specyfikacja wartości domyślnej dla parametru Parameter::default staje się atrybutem pochodnym

14 Cechy statyczne Dana cecha nie może być statyczna w jednym kontekście, a niestatyczna w innym Specyfikacja UML dopuszcza dwojakie rozumienie cech statycznych Cecha statyczna ma tę samą wartość we wszystkich cechowanych klasyfikatorach (jak w C++/Java/C#) Cecha statyczna ma różne wartości w różnych klasyfikatorach, do jakich należy W standardowej notacji cechy statyczne są podkreślone

15 Pakiet Kernel – diagram operacji

16 Pakiet Kernel – diagram klas

17 Pakiet Kernel – diagram klas – dodatkowe atrybuty i powiązania
Class::nestedClassifier – wskazuje na wszystkie klasyfikatory zdefiniowane wewnątrz klasy (zagnieżdżone) Property::defaultValue – specyfikacja wartości domyślnej właściwości Property::default jest atrybutem pochodnym Property::aggregation – określa rodzaj agregacji stosowany do danej właściwości AggregationKind::none – brak agregacji (domyślne) AggregationKind::shared – agregacja współdzielona AggregationKind::composite – agregacja całkowita (kompozycja) Property::isComposite jest atrybutem pochodnym

18 Notacja powiązań – dodatkowe elementy
Jawna notacja własności, nawigowalności i rodzaju agregacji Górny diagram: agregacja współdzielona, oba końce należą do klasyfikatorów, koniec b jawnie nienawigowalny. Dolny diagram: agregacja całkowita, oba końce należą do klasyfikatorów, koniec b jawnie nawigowalny. Zamiast {ordered,nonunique} można pisać {sequence} albo {seq}

19 Pakiet Kernel – diagram typów danych

20 Pakiet Kernel – diagram pakietów

21 Standardowe stereotypy klasyfikatorów
<<realization>> – klasyfikator (np. komponent) określający pewną dziedzinę obiektów, definiujący zarazem ich fizyczną implementację <<specification>> – klasyfikator określający pewną dziedzinę obiektów bez definiowania ich fizycznej implementacji Np. komponent zawierający tylko zapewniane interfejsy

22 Standardowe stereotypy klas
<<auxiliary>> – pomocnicza klasa wspierająca inną bardziej fundamentalną, np. przez określenie drugorzędnej logiki albo przepływu sterowania Klasa wspierana może być określona jawnie jako klasa ogniskująca, albo niejawnie przy pomocy zależności <<focus>> – klasa ogniskująca, czyli określająca fundamentalną logikę lub przepływ sterowania dla jednej lub więcej pomocniczych klas wspierających

23 Standardowe stereotypy klas (c.d.)
<<implementationClass>> – implementacja klasy w języku programowania, w którym instancja nie może mieć więcej niż jednej klasy (C++, Java) <<metaclass>> – klasa, której instancjami są klasy <<type>> – klasa opisująca pewną dziedzinę obiektów łącznie z operacjami na tych obiektach bez definiowania ich fizycznej implementacji <<utility>> – klasa bez instancji, opisująca zbiór atrybutów i operacji o zasięgu klasowym Instancja klasy (Class) w UML może mieć dowolnie wiele klas, może też je zmieniać dynamicznie. Obiekt może mieć co najwyżej jedną klasę implementacyjną, chociaż może być zgodny z wieloma typami.

24 Standardowe stereotypy pakietów
<<framework>> – pakiet zawierający elementy modeli definiujące wielokrotnie używalną architekturę części lub całości systemu Typowo zawiera klasy, wzorce lub szablony <<modelLibrary>> – pakiet zawierający elementy modeli przeznaczone do wykorzystania w innych pakietach Często używane w połączeniu z profilami Profil zależy od biblioteki albo ją zawiera Biblioteka nie definiuje stereotypów ani wartości etykietowanych

25 Standardowe stereotypy cech czynnościowych
<<create>> – oznacza, że dana cecha czynnościowa tworzy instancje klasyfikatora, do którego jest dołączona <<destroy>> – oznacza, że dana cecha czynnościowa usuwa instancje klasyfikatora, do którego jest dołączona

26 Pakiet UML::Classes::Dependencies

27 Metaklasa Dependency Zależność jest związkiem mówiącym, że element lub zbiór elementów modelu (client) wymaga innych elementów (supplier) do swojej specyfikacji lub implementacji Modyfikacja dostawcy (supplier) może mieć wpływ na elementy klienckie (client) Związek zależności nie ma żadnych implikacji w semantyce czasu wykonania modelu

28 Notacja zależności

29 Metaklasa Usage Użycie jest związkiem, w którym element wymaga innego elementu (lub zbioru elementów) do pełnej implementacji lub działania

30 Standardowe stereotypy związku użycia
<<call>> – związek pomiędzy operacjami (również klasami) – wywołanie <<create>> – klasyfikator-klient tworzy instancje klasyfikatora-dostawcy <<instantiate>> – operacje klasyfikatora-klienta tworzą instancje klasyfikatora-dostawcy <<responsibility>> – kontrakt lub zobowiązanie jednego elementu wobec innego <<send>> – operacja-klient wysyła sygnał-dostawcę

31 Metaklasa Abstraction
Abstrakcja jest związkiem łączącym dwa elementy (lub zbiory elementów) reprezentujące to samo pojęcie na różnych poziomach abstrakcji albo ukazane z różnych punktów widzenia W metamodelu istnieje odwzorowanie między dostawcą a klientem Formalne lub nieformalne Jedno- lub dwukierunkowe Notacja: symbol zależności ze słowem kluczowym <<abstraction>> (lub innym określonym przez stereotyp)

32 Standardowe stereotypy związku abstrakcji
<<derive>> – klient może być wyliczony na podstawie dostawcy; odwzorowanie określa sposób wyliczenia <<refine>> – związek rozwinięcia (uszczegółowienia) łączący elementy modelu na różnych poziomach semantycznych (np. analiza i projektowanie); odwzorowanie określa szczegóły związku <<trace>> – związek śledzenia między elementami reprezentującymi to samo pojęcie w różnych modelach; używany głównie do śledzenia wymagań i zmian pomiędzy modelami Związek śledzenia bywa często dwukierunkowy

33 Metaklasa Realization
Realizacja jest specjalizowanym związkiem abstrakcji pomiędzy specyfikacją (dostawca) a jej implementacją (klient)

34 Metaklasa Substitution
Podstawienie jest związkiem między dwoma klasyfikatorami mówiącym, że substitutingClassifier wypełnia kontrakt określony przez klasyfikator contract Tym samym instancje substitutingClassifier mogą być w czasie wykonania podstawione w miejsce instancji klasyfikatora contract Nie jest to specjalizacja Nie implikuje dziedziczenia cech Może określać specjalne reguły podstawiania (np. implementacja tych samych interfejsów, zgodność portów, itp.)

35 Notacja podstawienia

36 Pakiet UML::Classes::Interfaces

37 Metaklasa Interface Interfejs – rodzaj klasyfikatora reprezentujący deklarację spójnego zbioru publicznych cech i zobowiązań Określa kontrakt, który musi być wypełniony przez każdą instancję klasyfikatora realizującego dany interfejs Zobowiązania nakładane przez kontrakt mogą być określone w postaci Ograniczeń (np. warunków wstępnych i końcowych) Specyfikacji protokołu (np. określenia dopuszczalnej kolejności wywołania operacji) Atrybuty i powiązania interfejsów są także jedynie zobowiązaniami (są abstrakcyjne)

38 Metaklasa Interface – ograniczenie
self.feature->forAll(visibility = VisibilityKind::public)

39 Metaklasy Interface i InterfaceRealization
Interfejs – jako deklaracja – nie ma własnych instancji Jest realizowany (implementowany) przez instancjonowalny klasyfikator Realizacja interfejsu oznacza, że klasyfikator dostarcza cech określonych przez interfejs i wszystkie interfejsy bazowe Interfejsy realizowane przez klasyfikator to jego interfejsy zapewniane Klasyfikator może też określić zbiór interfejsów wymaganych

40 Interfejsy – notacja

41 Interfejsy – przykład definicji protokołu

42 Pakiet UML::Classes::AssociationClasses

43 Kwalifikatory powiązań – metaklasa AssociationClasses::Property
Właściwość, która jest końcem powiązania może mieć właściwości, które służą jako jej kwalifikatory Kwalifikator określa podział zbioru powiązanych instancji względem instancji na kwalifikowanym końcu Przy danym kwalifikowanym obiekcie i danej instancji kwalifikatora liczba obiektów na drugim końcu powiązania jest ograniczona przez deklarowaną krotność Jeśli dolne ograniczenie jest dodatnie (zwykle 1), to dla każdej instancji kwalifikatora musi być określony powiązany obiekt „Surowa” krotność powiązania kwalifikowanego wynosi (praktycznie zawsze) 0..*

44 Notacja powiązań kwalifikowanych

45 Klasy powiązań – metaklasa AssociationClasses::AssociationClass
Element modelu o cechach zarówno klasy, jak i powiązania Deklaracja związku semantycznego między klasyfikatorami, który ma własne cechy (atrybuty, operacje) Dla konkretnej instancji klasy powiązania jest tylko po jednej instancji klasyfikatorów na jego końcach

46 Notacja klas powiązań

47 Pakiet UML::Classes::PowerTypes

48 Zbiór uogólnień – metaklasa PowerTypes::GeneralizationSet
Definiuje szczególny zbiór instancji związków uogólnienia opisujący sposób, w jaki ogólny klasyfikator może być podzielony (na podzbiory) przy użyciu specyficznych podtypów Atrybut isCovering mówi czy dany podział stanowi pokrycie ogólnego klasyfikatora true (oznaczane jako {complete}) – tak false ({incomplete}) – nie, tzn. istnieją instancje klasyfikatora ogólnego nie będące instancjami żadnego klasyfikatora specyficznego z danego zbioru uogólnień

49 Zbiór uogólnień (c.d.) Atrybut isDisjoint mówi o tym, czy klasyfikatory specyficzne mają wspólne instancje true oznacza się {disjoint} false oznacza się {overlapping} Wartości domyślne to {incomplete, disjoint} Przyjmuje się następujące ograniczenie: generalization->collect(general)->asSet()->size() <= 1

50 Notacja zbiorów uogólnień

51 Notacja atrybutów zbioru ogólnień

52 Typy potęgowe Typ potęgowy to klasyfikator (na ogół klasa), którego instancje są podklasami innej klasy Typ potęgowy jest więc w szczególności metaklasą

53 Typ potęgowy – przykład

54 Podstawowe diagramy struktury
Diagramy klas Diagramy pakietów Diagramy obiektów

55 Typowa zawartość diagramów klas
Węzły Klasa Interfejs Krawędzie Powiązanie Agregacja Kompozycja Uogólnienie Zależność Realizacja (w tym realizacja interfejsu)

56 Typowa zawartość diagramów pakietów
Węzły Pakiet Krawędzie Zależność Import pakietowy Scalenie pakietów

57 Typowa zawartość diagramów obiektów
Węzły Specyfikacja instancji (klasy) Krawędzie Wiązanie (specyfikacja instancji powiązania)