Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Interfejs nie jest klasą? To chyba muszą przepisać wszystkie Object-Oriented systemy...

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Mateusz Kurleto:
Interfejs nie jest klasą? To chyba muszą przepisać wszystkie Object-Oriented systemy...

:)

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Jerzy N.:

[...]

Diagram klas:
Agregacja - z diagramu wynika, że Administrator składa się wyłącznie z jednego autora, natomiast Autor może wejść w skład Administratora .... chyba Ci nie o to chodziło, prawda ?
Agregacja całkowita oznacza, że jak nie ma zdjęcia, to nie ma galerii - też chyba nie o to Ci chodziło, prawda ?

Jerzy N. chyba nie zna notacji UML. Na diagramie klas pomiędzy osobą, autorem, a administratorem jest dziedziczenie, a nie agregacja. Autor diagramu poprawnie określił hierarchię. Taki zapis jest jak najbardziej dopuszczalny.

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Tomasz Napływowy:

Jerzy N.:

[...]

Diagram klas:
Agregacja - z diagramu wynika, że Administrator składa się wyłącznie z jednego autora, natomiast Autor może wejść w skład Administratora .... chyba Ci nie o to chodziło, prawda ?
Agregacja całkowita oznacza, że jak nie ma zdjęcia, to nie ma galerii - też chyba nie o to Ci chodziło, prawda ?

Jerzy N. chyba nie zna notacji UML. Na diagramie klas pomiędzy osobą, autorem, a administratorem jest dziedziczenie, a nie agregacja. Autor diagramu poprawnie określił hierarchię. Taki zapis jest jak najbardziej dopuszczalny.

Wypowiedź zawierająca diagramy była edytowana, być może wcześniejsza wersja posiadała agregację?

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Mateusz Kurleto:
Interfejs nie jest klasą? To chyba muszą przepisać wszystkie Object-Oriented systemy...

Ojej, dopóki nie znałem prawa powszechnego ciążenia jabłka wisiały spokojnie na drzewach? Nie rozumiem jakim cudem mimo mojej nieznajomości mechaniki kwantowej cała materia we wszechświecie jeszcze się nie rozleciała? Hmm, a może lepiej jej nie poznawać, gdzieś tam podobno coś się dzieli przez zero... i bum, już po nas!

"Nie mieszajmy systemów walutowych" (S. Bareja, Miś).

Ale poważnie. Będę wdzięczny za specyfikację która mówi inaczej.

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Artur Kęska:
Ale poważnie. Będę wdzięczny za specyfikację która mówi inaczej.

specyfikację czego i mówiącej inczej niż???

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Jarek Żeliński:

Artur Kęska:
Ale poważnie. Będę wdzięczny za specyfikację która mówi inaczej.

specyfikację czego

Mówimy o UML. Mówiliśmy już o językach UML i Java (na marginesie spojrzałem też na zręby C#). Kolega Mateusz twierdzi (jak mniemam Pan również) co następuje:

A. Interfejs jest klasą - więc pytam w jakim konkretnie kontekście i jaka specyfikacja (wszystko mi jedno czego) tak mówi.

i mówiącej inczej niż???

B. Jeżeli Interfejs nie jest Klasą to trzeba przebudować systemy tworzone w oparciu o OOP/OOD. Takie twierdzenie jest dla mnie o tyle nie na miejscu, że nie ma logicznego związku pomiędzy przyjęciem definicji Interfejsu a jego użyciem w praktyce. Dokładniej: obojętnie czy definicja będzie degradowała Klasę do interfejsu, czy też przyjmiemy, że nie ma między nimi bezpośredniej relacji, systemy będą działały.

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Artur Kęska:
A. Interfejs jest klasą - więc pytam w jakim konkretnie kontekście i jaka specyfikacja (wszystko mi jedno czego) tak mówi.

i mówiącej inczej niż???

Jeżeli interfejs to "zbiór publicznych metod klas komponentu lub pakietu" to modelujemy go (przedstawiamy na diagramach, w dokumentacji) jako abstrakcyjną klasę grupująca te publiczne metody nie mająca jedna atrybutów, czasem jako "lizak" jeśli nie musimy prezentować listy tychże metod.

Czy tak jest OK? Kto mówi, ze każda klasa musi mieć instancje w postaci obiektów? Klasa abstrakcyjna nie ma swoich instancji i nie musi mieć "rzeczywistych" specjalizacji. Klasa może modelować zbiór metod ... interfejs. Podkreślam, że w tym przypadku mowa o dokumentacji, modelu, UML.

B. Jeżeli Interfejs nie jest Klasą to trzeba przebudować systemy tworzone w oparciu o OOP/OOD. Takie twierdzenie jest dla mnie o tyle nie na miejscu, że nie ma logicznego związku pomiędzy przyjęciem definicji Interfejsu a jego użyciem w praktyce. Dokładniej: obojętnie czy definicja będzie degradowała Klasę do interfejsu, czy też przyjmiemy, że nie ma między nimi bezpośredniej relacji, systemy będą działały.

OK, wydaje mi się, że chodzi o dokumentowanie pewnych cech oprogramowania, jeśli założymy, że interfejs to (w rzeczywistości) lista publicznych metod czyli kilkanaście publicznych metod wyodrębnionych z kilkudziesięciu klas mających kilkaset metod w tym także prywatnych i chronionych to prezentacja na diagramie tylko kilkunastu w "jednym miejscu" dla lepszego zrozumienia projektu to abstrakcyjna klasa ze stereotypem <<interfejs>>. Czyż nie?

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Zignorujmy na chwilę wysublimowane słownictwo, bo z racji godziny nie chce mi się go używać. Powiedzmy sobie wprost. Kiedyś nie używało się tak powszechnie interfejsów i interfejsy były na styku sprzętu i użytkownika. Klawiatura była interfejsem komputera, potem były interfejsy systemów - system był bazodanowy i miał dwa interfejsy - desktopowy i webowy. A potem mądrzy ludzie (głównie od zabezpieczeń) stwierdzili, że z każdej klasy można wydzielić część publiczną, zrobić ją osobną klasą i tą klasę nazwali interfejsem. A zatem interfejs JEST klasą. UML to dla mnie narzędzie a nie przedmiot studiów nad interpunkcją w specyfikacji. Więc nawet nie sięgam do niej by sypać cytatami. Interfejs to klasa. Jak ją zamodelujesz - Twoja sprawa. Jak dla mnie możesz w ogóle nie korzystać z predefiniowanych rozwiązań języka i zrobić osobną klasę połączoną z klasą podstawową. Będzie równie użyteczne. Możesz ją nawet za zaleceniami ustawy o języku polskim iblabla nazwać międzymordzie.

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Mateusz Kurleto:
A potem mądrzy ludzie (głównie od zabezpieczeń) stwierdzili, że z każdej klasy można wydzielić część publiczną, zrobić ją osobną klasą i tą klasę nazwali interfejsem. A zatem interfejs JEST klasą.

Tu nie ma logicznej konsekwencji. To, że zdegenerowano pojęcie klasy bez implementacji do czegoś co nazwano interfejsem, w cale nie musi oznaczać, że to coś nadal jest klasą. Myślę, że mocno jesteś związany z C++.

UML to dla mnie narzędzie a nie przedmiot studiów nad interpunkcją w specyfikacji. Więc nawet nie sięgam do niej by sypać cytatami.

Więc dla czego się tak bardzo upierasz? Nie znasz specyfikacji a podajesz definicje? To nielogiczne.

Jasne, że to tylko specyfikacja, ale sztab ludzi nad nią siedział i warto ją znać. Jeżeli twierdzisz inaczej, to może zaprzeczysz sensowności znajomości notacji w rysunku technicznym, elektronice, formalizmom równań matematycznych ... ? Przecież można rysować po swojemu - tylko kto to potem zrozumie?
Jeżeli zadałem pytanie czy komponent może udostępniać interfejs i aktor z niego korzystać - to nie dla tego, żeby zgłębiać notację UML, ale, żeby mieć pewność jak inni takie coś zrozumieją. Wszystkie te formalizmy jak dla mnie tylko temu mają służyć.
Dyskusja niestety poszła w innym kierunku.

Interfejs to klasa. Jak ją zamodelujesz - Twoja sprawa. Jak dla mnie możesz w ogóle nie korzystać z predefiniowanych rozwiązań języka i zrobić osobną klasę połączoną z klasą podstawową.

Jasne, że możesz, tylko nie mówimy o tym jak można modelować, tylko czym formalnie jest dany element w specyfikacji.

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Czym jest IPerson powyżej? jest to interfejs, czy jest to klasa czy nie? A jest to poprawny diagram UML...

Moim zdaniem diagram pokazuje, że:
- składa się z czterech klas bo IPerson obowiązuja dokładnie te same zasady syntaktyczne i semantyczne co posotale elementy diagramu (klasy)
- tu dodatkowo widać, że superklasa może stanowić interfejs dla swoich specjalizacji co zresztą jest często praktykowane we wzorcach i dobrych praktykach...

nie widze tu kolizji ze specyfiakcja UML.
polecam UML Superstructure 09-02-04 par. 7.3.24 Interface (from InterfacesJarek Żeliński edytował(a) ten post dnia 08.09.09 o godzinie 11:33

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Jarek Żeliński:




Czym jest IPerson powyżej? jest to interfejs, czy jest to klasa czy nie? A jest to poprawny diagram UML...

Moim zdaniem diagram pokazuje, że:
- składa się z czterech klas bo IPerson obowiązuja dokładnie te same zasady syntaktyczne i semantyczne co posotale elementy diagramu (klasy)
- tu dodatkowo widać, że superklasa może stanowić interfejs dla swoich specjalizacji co zresztą jest często praktykowane we wzorcach i dobrych praktykach...

nie widze tu kolizji ze specyfiakcja UML.
polecam UML Superstructure 09-02-04 par. 7.3.24 Interface (from InterfacesJarek Żeliński edytował(a) ten post dnia 08.09.09 o godzinie 11:33

Mogę prosić o link (jeżeli jest publicznie dostępny). Na http://www.omg.org/technology/documents/formal/uml.htm nie ma takiego dokumentu. Z numerem 09-02-04 jest ale "UML 2.2 Infrastructure Specification" ale w tym dokumencie z kolei nie ma rozdziału 7.3.24.

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Artur Kęska:

takiego dokumentu. Z numerem 09-02-04 jest ale "UML 2.2 Infrastructure Specification" ale w tym dokumencie z kolei nie ma rozdziału 7.3.24.

http://www.omg.org/spec/UML/2.2/Superstructure/PDF/
rozdział 7.3.24

a co w kwestii powyższego przykładu??

kolejny cytat z dokuemntacji:

In UML, keywords are used for four different purposes:
• To distinguish a particular UML concept (metaclass) from others sharing the same general graphical form. For
instance, the «interface» keyword in the header box of a classifier rectangle is used to distinguish an Interface from
other kinds of Classifiers.

reszta tu:
http://www.goldenline.pl/forum/projektowanie-i-program...Jarek Żeliński edytował(a) ten post dnia 08.09.09 o godzinie 12:48

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Jarek Żeliński:

Artur Kęska:

takiego dokumentu. Z numerem 09-02-04 jest ale "UML 2.2 Infrastructure Specification" ale w tym dokumencie z kolei nie ma rozdziału 7.3.24.

http://www.omg.org/spec/UML/2.2/Superstructure/PDF/
rozdział 7.3.24

to jest dokument 09-02-02, i tu jest ww. rozdział. Tym dokumentem posługiwaliśmy się już parę tygodni wcześniej.

a co w kwestii powyższego przykładu??

kolejny cytat z dokuemntacji:

In UML, keywords are used for four different purposes:
• To distinguish a particular UML concept (metaclass) from others sharing the same general graphical form. For
instance, the «interface» keyword in the header box of a classifier rectangle is used to distinguish an Interface from
other kinds of Classifiers.

Wszystko OK, tylko specyfikacja mówi cały czas o "klasyfikatorze" (Classifier) a nie "klasie" (Class).
Wcześniej - mowa jest o "słowie kluczowym" (Keyword) jako narzędziu służącemu odróżnieniu Form Graficznych (graphical form). A wiec zapis jest podobny co nie oznacza, że koduje tą samą informację.
W zapisie, z wyglądu Klasa i Interface są podobne, ale to w cale nie oznacza, że semantycznie są tym samym.

Ta interpretacja jest mi prawdę mówiąc nie na rękę, bo wracając do tematu od którego to wszystko się zaczęło, uważam, że Aktor może korzystać z Interfejsów systemu a nie jego komponentów. Dobrym przykładem wydaje mi się urządzenie jakim jest klawiatura komputera (wymieniona wcześniej). Gdybym korzystał z jej jako komponentu, wbijał bym nią gwoździe, ale ponieważ korzystam z jej konkretnego Interfejsu, pisze ten tekst.

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Artur Kęska:

Mateusz Kurleto:
A potem mądrzy ludzie (głównie od zabezpieczeń) stwierdzili, że z każdej klasy można wydzielić część publiczną, zrobić ją osobną klasą i tą klasę nazwali interfejsem. A zatem interfejs JEST klasą.

Tu nie ma logicznej konsekwencji. To, że zdegenerowano pojęcie klasy bez implementacji do czegoś co nazwano interfejsem, w cale nie musi oznaczać, że to coś nadal jest klasą. Myślę, że mocno jesteś związany z C++.

W ogóle nie jestem związany z C++. Nie jestem programistą. Jak już coś piszę to w Java/Python.

UML to dla mnie narzędzie a nie przedmiot studiów nad interpunkcją w specyfikacji. Więc nawet nie sięgam do niej by sypać cytatami.

Więc dla czego się tak bardzo upierasz? Nie znasz specyfikacji a podajesz definicje? To nielogiczne.

Nigdzie nie podałem definicji.

Jasne, że to tylko specyfikacja, ale sztab ludzi nad nią siedział i warto ją znać. Jeżeli twierdzisz inaczej, to może zaprzeczysz sensowności znajomości notacji w rysunku technicznym, elektronice, formalizmom równań matematycznych ... ? Przecież można rysować po swojemu - tylko kto to potem zrozumie?
Jeżeli zadałem pytanie czy komponent może udostępniać interfejs i aktor z niego korzystać - to nie dla tego, żeby zgłębiać notację UML, ale, żeby mieć pewność jak inni takie coś zrozumieją. Wszystkie te formalizmy jak dla mnie tylko temu mają służyć.
Dyskusja niestety poszła w innym kierunku.

Interfejs to klasa. Jak ją zamodelujesz - Twoja sprawa. Jak dla mnie możesz w ogóle nie korzystać z predefiniowanych rozwiązań języka i zrobić osobną klasę połączoną z klasą podstawową.

Jasne, że możesz, tylko nie mówimy o tym jak można modelować, tylko czym formalnie jest dany element w specyfikacji.

Formalnie jak się z kimś spierasz to warto czytać ze zrozumienie. Więc skoro dla Ciebie teoria ważniejsza jest od praktyki, to proszę:

Cytaty ze specyfikacji:

7.3.24 Interface (from Interfaces)
Generalizations
• “Classifier (from Kernel, Dependencies, PowerTypes)” on page 52
Description
An interface is a kind of classifier that represents a declaration of a set of coherent public features and obligations. An
interface specifies a contract; any instance of a classifier that realizes the interface must fulfill that contract. The
obligations that may be associated with an interface are in the form of various kinds of constraints (such as pre- and postconditions)
or protocol specifications, which may impose ordering restrictions on interactions through the interface.
Since interfaces are declarations, they are not instantiable. Instead, an interface specification is implemented by an
instance of an instantiable classifier, which means that the instantiable classifier presents a public facade that conforms to
the interface specification. Note that a given classifier may implement more than one interface and that an interface may
be implemented by a number of different classifiers (see “InterfaceRealization (from Interfaces)” on page 89).

W dużym skrócie dla meritum sprawy ważne jest to, że interfejs jest rodzajem klasyfikatora(Classifier). Zastanówmy się więc, czym jest klasyfikator(Classifier)?

7.3.8 Classifier (from Kernel, Dependencies, PowerTypes)
A classifier is a classification of instances, it describes a set of instances that have features in common.
Generalizations
• “Namespace (from Kernel)” on page 99
• “RedefinableElement (from Kernel)” on page 130
• “Type (from Kernel)” on page 135
Description
A classifier is a namespace whose members can include features. Classifier is an abstract metaclass.
A classifier is a type and can own generalizations, thereby making it possible to define generalization relationships to
other classifiers. A classifier can specify a generalization hierarchy by referencing its general classifiers.
A classifier is a redefinable element, meaning that it is possible to redefine nested classifiers.

Dla meritum dyskusji istotne jest, że klasyfikator jest przestrzenią nazw zawierającą pewne cechy. I co dla naszego rozważania najważniejsze KLASYFIKATOR JEST ABSTRAKCYJNĄ METAKLASĄ.

A zatem jeśli interfejs jest klasyfikatorem, a klasyfikator jest metaklasą, a metaklasa jak mam nadzieję dowodzić nie trzeba jest klasą...
to dzięki powszechnie znanemu sylogizmowi hipotetycznemu (prawo przechodniości implikacji [( p => q ) & ( q => r )] => ( p => r) wiemy, że... INTERFEJS JEST KLASĄ.

Dziękuję za uwagę. Choć i tak nie widzę większego sensu w tym sporze, bo nie wnosi on nic do praktyki.

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Artur Kęska:

Jarek Żeliński:

Artur Kęska:

takiego dokumentu. Z numerem 09-02-04 jest ale "UML 2.2 Infrastructure Specification" ale w tym dokumencie z kolei nie ma rozdziału 7.3.24.

http://www.omg.org/spec/UML/2.2/Superstructure/PDF/
rozdział 7.3.24

to jest dokument 09-02-02, i tu jest ww. rozdział. Tym dokumentem posługiwaliśmy się już parę tygodni wcześniej.

a co w kwestii powyższego przykładu??

kolejny cytat z dokuemntacji:

In UML, keywords are used for four different purposes:
• To distinguish a particular UML concept (metaclass) from others sharing the same general graphical form. For
instance, the «interface» keyword in the header box of a classifier rectangle is used to distinguish an Interface from
other kinds of Classifiers.

Wszystko OK, tylko specyfikacja mówi cały czas o "klasyfikatorze" (Classifier) a nie "klasie" (Class).
Wcześniej - mowa jest o "słowie kluczowym" (Keyword) jako narzędziu służącemu odróżnieniu Form Graficznych (graphical form). A wiec zapis jest podobny co nie oznacza, że koduje tą samą informację.
W zapisie, z wyglądu Klasa i Interface są podobne, ale to w cale nie oznacza, że semantycznie są tym samym.

Ta interpretacja jest mi prawdę mówiąc nie na rękę, bo wracając do tematu od którego to wszystko się zaczęło, uważam, że Aktor może korzystać z Interfejsów systemu a nie jego komponentów. Dobrym przykładem wydaje mi się urządzenie jakim jest klawiatura komputera (wymieniona wcześniej). Gdybym korzystał z jej jako komponentu, wbijał bym nią gwoździe, ale ponieważ korzystam z jej konkretnego Interfejsu, pisze ten tekst.

Oczywiście, że aktor korzysta z interfejsów a nie komponentów. Nawet jak korzysta z komponentów. Dlaczego? Ano dlatego, że anwet jak nie używasz Klasyfikatora <<inferface>> to jedyne co się zmienia to to, że nie jesteś dość dokłądny, żeby wyodrębnić interfejs (publiczną część klasy) od pozostałej jej części.

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Artur Kęska:
wracając do tematu od którego to wszystko się zaczęło, uważam, że Aktor może korzystać z Interfejsów systemu a nie jego komponentów. Dobrym przykładem wydaje mi się urządzenie jakim jest klawiatura komputera (wymieniona wcześniej). Gdybym korzystał z jej jako komponentu, wbijał bym nią gwoździe, ale ponieważ korzystam z jej konkretnego Interfejsu, pisze ten tekst.

a tego akurat nie neguję :), tez uwazam, że aktor korzysta z interfejsu a nie komponentu bezpośrdenio, jednak jeżeli byłby to interfejs programowy a nie klawiatura to tym interfejsem beda publiczne metody klas tworzących komponent, można "człowieka" czytającego zostawić z modelem tego komonentu by sobie sam "wyszperał" liste publicznych metod, z których mogłby skorzystac jednak dla porządku i dbałości o zdrowie czytelnikow dokuemntacji zbiera sie te metody w abstrakcyjnej klasie oznaczonej <<interfejs>>. Wyznacznikiem tego czy cos jest klasa czy nie spokojnie może być to, że:
- ma to samo znaczenie: jest klasyfikatorem
- obowiązują go te same zasady syntaktyki
- jest tak samo oznaczany

jak klasa rzeczywista - stąd pojęcie klasy i tak to w moim rozumieniu opsiuje wlasnie specyfikacja UML i załącznii. Można dywagowac czy interfejs to całkiem klasa czy tylko troszke, i tu zgoda ale jest klasa w rozumieniu semantyki i znaczenia modelownaej struktury.

nadal nikt sie nie odnióśł do przykąłdowego diagramu ktory zamieściłem ;) jest dobry czy nie jest ? :)

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

nadal nikt sie nie odnióśł do przykąłdowego diagramu ktory zamieściłem ;) jest dobry czy nie jest ? :)

A czepił bym się, bo Student i Programmer niczym się nie różnią, więć jak dla mnie te 2 klasy są zupełnie niepotrzebne:P Aczkolwiek całość jest jak najbardziej poprawna. A nawet jeśli gdzieś w specyfikacji napisali drobnym maczkiem, że zaleca się przepisywanie klasyfikatorów do klas dziedziczących (wpisanie <<interface>> do Student i Programmer) to i tak jest to czytelne zrozumiałe i jednoznaczne więc DOBRE. A to dla mnie ważniejsze niż poprawnność formalna.

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Mateusz Kurleto:
A czepił bym się, bo Student i Programmer niczym się nie różnią, więć jak dla mnie te 2 klasy są zupełnie niepotrzebne:P Aczkolwiek całość jest jak najbardziej poprawna.

gdyby mial sie ja czepić to możliwe, że algorytmy operacji work() sa inne dla kazdego z nich i wtedy ma sens ta separacja :) różnia sie metodami

ale to już ot tak :0 ;P

wazna dla mnie konkluzja jest na pewno to, że modele UMl to dokuemntacja a kod programu do implementacja, dokuemntacja ma mówić o co chodzi mino tego, ze konkretny język programowania może miec pewne ograniczenia (np. brak wielodziedziczenia) itp...

byc może kłopot w tym, że programista nie "implementuje" klas abstrakcyjnych gdyz służa one jedynie do pzrekazania pewnych informacji, więc możliwe że może "nie lubić i nie rozumieć" tych klas... jeżeli nie ma ich w swoim narzędziu czyli kompilatorze...Jarek Żeliński edytował(a) ten post dnia 08.09.09 o godzinie 14:39

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Mateusz Kurleto:

metaklasą, a metaklasa jak mam nadzieję dowodzić nie trzeba jest klasą...

"mam nadzieję"?????

Co to u licha jest "abstract metaclass" (dosłownie cytuję ze specyfikacji)???

Nie chcę być złośliwy, ale: nie miej nadziei - szczególnie jako analityk. I załóż proszę, że przeczytałem specyfikację o której mówimy.

Mogłem oczywiście coś pominąć - gdybym był nieomylny nie pisał bym w tym wątku i nie prosił o wyjaśnienie. Dla tego, jeżeli możesz mi wskazać definicję "abstract metaclass" i pokazać, gdzie napisane jest, że Description to definicja będę zobowiązany.

Inaczej muszę przyjąć, że to czym jest Klasyfikator definiuje sekcja opisująca generalizację (bo to jest formalny opis zależności). A z tej definicji wynika, że zarówno Interfejs jak i Klasa wywiedzione są z klasyfikatora. Nigdzie nie ma słowa na temat tego, jakoby Klasyfikator był wywiedziony z Klasy.