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

Jarek Żeliński:

Jerzy N.:
Zatem aktor nie może posiadać asocjacji z węzłem.
Proszę nie wprowadzać w błąd innych osób.

Interfejs to klasa, jeżeli jakiś moduł (kod) jest komponentem

Interfejs to nie jest klasa.
Proszę zajrzeć do specyfikacji "Unified Modeling Language: Superstructure, version 2.0, formal/05-07-04".
Rys.7.12 pokazuje część metamodelu związanego z klasami, a 7.16 pokazuje część metamodelu związanego z interfejsami.
Ponadto warto zaznajomić się z rozdziałem 7.3.24. Interface.

obsługującym ekran logowania to aktor ma logiczny związek z tym kawałkiem kodu, po drugie, wymienione ograniczenie dotyczy "Actor (from UseCases)" a tu nie mamy przypadku użycia tylko aktora i kawałek kodu,

Odnośnik (from UseCases) oznacza, że aktor został zdefiniowany w części specyfikacji (pakietu) dotyczącej UseCase - rozdział 16. Use Cases - pakiet UseCases. Nie oznacza to, że istnieją inne definicje aktora w specyfikacji UML.
Specyfikacja UML nie definiuje "logicznego związku".

Życzę większej uwagi i wytrwałości przy studiowaniu specyfikacji UML. Uchroni nas to przed wygłaszaniem błędnych opinii.

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

Jerzy N.:
Życzę większej uwagi i wytrwałości przy studiowaniu specyfikacji UML. Uchroni nas to przed wygłaszaniem błędnych opinii.

:), interfejs to jeden ze możliwych stereotypów klasy ale ja tam sie nie znam...

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

Jarek Żeliński:

Jerzy N.:
Życzę większej uwagi i wytrwałości przy studiowaniu specyfikacji UML. Uchroni nas to przed wygłaszaniem błędnych opinii.

:), interfejs to jeden ze możliwych stereotypów klasy ale ja tam sie nie znam...

Człowiek się uczy całe życie ...
Stereotyp służy do rozszerzenia klasy do własnych potrzeb, niezdefiniowanych przez standard UML, stąd może mieć dowolną nazwę, np. klasa, albo tralala ....
Trzeba odróżniać element zdefiniowany przez standard UML, od np. stereotypu określonego przez kogokolwiek ...
Na szczęście standard UML nie definiuje elementu "Tralala" ...
Mówiąc więc o interfejsie w standardzie UML mówimy o jego zdefiniowanym elemencie, a nie o stereotypach, które ktoś gdzieś sobie zdefiniował ...

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

Jerzy N.:

Jarek Żeliński:

Jerzy N.:
Życzę większej uwagi i wytrwałości przy studiowaniu specyfikacji UML. Uchroni nas to przed wygłaszaniem błędnych opinii.

:), interfejs to jeden ze możliwych stereotypów klasy ale ja tam sie nie znam...

Człowiek się uczy całe życie ...
Stereotyp służy do rozszerzenia klasy do własnych potrzeb, niezdefiniowanych przez standard UML, stąd może mieć dowolną nazwę, np. klasa, albo tralala ....
Trzeba odróżniać element zdefiniowany przez standard UML, od np. stereotypu określonego przez kogokolwiek ...
Na szczęście standard UML nie definiuje elementu "Tralala" ...
Mówiąc więc o interfejsie w standardzie UML mówimy o jego zdefiniowanym elemencie, a nie o stereotypach, które ktoś gdzieś sobie zdefiniował ...

A co to jest:
"An interface is a kind of classifier that represents a declaration of a set of coherent public features and obligations."

dalej 9 str. 24 UML Superstructure, Table 2.3 Metamodel packages added in Level 1) Classes::Interfaces, innymi słowy, <<interface>> jest to stereotyp określający jeden ze stanadardowych w UML typów klas, są to klasy będące realizacją udostępnianych przez np. pakiet lub komponent operacji. Interfejs nie jest stereotypem "dowolnym" a ma konkrete zdefiniowane znaczenie i nie podlega redefinicji.

Na diagramie reprezentoany jest symbolem "kieliszka" lub jako klasa oznaczona właśnie stereotypem <<interface>>.

Szczegóły tu, strona 156.
http://www.omg.org/spec/UML/2.2/Superstructure/PDF/

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

Jarek Żeliński:

Jerzy N.:

Jarek Żeliński:

Jerzy N.:
Życzę większej uwagi i wytrwałości przy studiowaniu specyfikacji UML. Uchroni nas to przed wygłaszaniem błędnych opinii.

:), interfejs to jeden ze możliwych stereotypów klasy ale ja tam sie nie znam...

Człowiek się uczy całe życie ...
Stereotyp służy do rozszerzenia klasy do własnych potrzeb, niezdefiniowanych przez standard UML, stąd może mieć dowolną nazwę, np. klasa, albo tralala ....
Trzeba odróżniać element zdefiniowany przez standard UML, od np. stereotypu określonego przez kogokolwiek ...
Na szczęście standard UML nie definiuje elementu "Tralala" ...
Mówiąc więc o interfejsie w standardzie UML mówimy o jego zdefiniowanym elemencie, a nie o stereotypach, które ktoś gdzieś sobie zdefiniował ...

A co to jest:
"An interface is a kind of classifier that represents a declaration of a set of coherent public features and obligations."

Definicja elementu interface, którą Ci poleciłem. Miło, że wreszcie wziąłeś się za czytanie standardów ...

dalej 9 str. 24 UML Superstructure, Table 2.3 Metamodel packages added in Level 1) Classes::Interfaces, innymi słowy,

Powyższy zapis potwierdza to co napisałem wcześniej, a mianowicie to, że pakiet opisujący element interface zawarty jest w pakiecie nazwanym Classes. Zdecydowanie brak Ci podstaw z inżynierii oprogramowania, jeśli interpretujesz ten zapis jako stereotyp.

<<interface>> jest to stereotyp określający jeden ze stanadardowych w UML typów klas, są to klasy będące realizacją udostępnianych przez np. pakiet lub komponent operacji. Interfejs nie jest stereotypem "dowolnym" a ma konkrete zdefiniowane znaczenie i nie podlega redefinicji.

Jedyne frazy <<interface>>, jakie znalazłem w UML posłużyły do alternatywnego przedstawienia interfejsu (kółeczko ze związkiem) w formie prostokąta z tym napisem. Innymi słowy prostokącik to klasyfikator, gdyż zarówno klasa jak i interfejs dziedziczy po klasyfikatorze ...

Na diagramie reprezentoany jest symbolem "kieliszka" lub jako klasa oznaczona właśnie stereotypem <<interface>>.

Szczegóły tu, strona 156.
http://www.omg.org/spec/UML/2.2/Superstructure/PDF/

pomyliłeś klasę z klasyfikatorem ....
Na rysunku 7.16 - Contents of Interfaces package zobaczysz, że interfejs dziedziczy po klasyfikatorze, natomiast na rysunku 7.12 - Classes diagram of the Kernel package zobaczysz, że klasa też dziedziczy po klasyfikatorze.
Klasyfikator to nie klasa .....

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

no cóż.. moja intencją mnie było udowodnienie czegokolwiek a przekazanie mojego zdania...

Poproszę, jako niedouczony, kolegę Jerzego o odpowiedź na pytanie: co to jest interfejs? (człowiek uczy się całe życie)Jarek Żeliński edytował(a) ten post dnia 23.07.09 o godzinie 22:00

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

Jarek Żeliński:
no cóż.. moja intencją mnie było udowodnienie czegokolwiek a przekazanie mojego zdania...

Poproszę, jako niedouczony, kolegę Jerzego o odpowiedź na pytanie: co to jest interfejs? (człowiek uczy się całe życie)Jarek Żeliński edytował(a) ten post dnia 23.07.09 o godzinie 22:00

Odpowiedź:
prześledź poprzednie wypowiedzi.

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

Jerzy N.:

Jarek Żeliński:
no cóż.. moja intencją mnie było udowodnienie czegokolwiek a przekazanie mojego zdania...

Poproszę, jako niedouczony, kolegę Jerzego o odpowiedź na pytanie: co to jest interfejs? (człowiek uczy się całe życie)

Odpowiedź:
prześledź poprzednie wypowiedzi.

podobno miarą człowieka jest umiejętność udzielania odpowiedzi.... już dziękuję, rozumiem, że odpowiedź na proste pytanie czym jest interfejs przerosła...

a jako moderator tej grupy "nawołuję" do szacunku dla innych jej członków ... powyższa odpowiedź niczemu nie służy a na szanującej się uczelni (gdyby zapytał student) była by wprost nie do przyjęciaJarek Żeliński edytował(a) ten post dnia 24.07.09 o godzinie 06:33

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

Jarek Żeliński:
a jako moderator tej grupy "nawołuję" do szacunku dla innych jej członków ...

W tej sprawie zgadzam się z Panem całkowicie.

pytanie czym jest interfejs

Moje zdanie w tej sprawie jest jednak następujące.
Logicznie rzecz biorąc każda klasa może udostępniać jakiś interfejs co sugerowało by generalizację od elementu Class do Interface. Semantyka UML'a jednak nic o tym nie mówi.
Być może jednak twórcy UML dostrzegli na tyle dużo rozbieżności pomiędzy klasą a interfejsem, że zdecydowali się nie przenosić cech jednego na drugi w sposób bezpośredni.
Generalizacja Interfejsu do elementu typu Klasa, poprzez stereotypowanie kasy, była by moim zdaniem nadużyciem stereotypu.
Stereotyp ten sprowadzał by się do usunięcia cech z elementu typu Class, co stanowiło by definicję przez zaprzeczenie. Jeżeli można stworzyć definicję poprzez dodanie cech a nie usuwanie, to moim zdaniem lepiej wybrać właśnie tę drogę.

Nie mniej jednak, pamiętam z jednych z pierwszych książek jakie na ten temat czytałem, że faktycznie istniała taka interpretacja.

Co może być mylące to zapis przy opisie notacji:

As a classifier, an interface may be shown using a rectangle symbol with the keyword «interface» preceding the name.

Ciekawa rzecz, mowa jest tu o "słowie kluczowym" a nie o stereotypie, a notacja jest jakoś dziwnie podobna.

Abstrahując od jakiejkolwiek specyfikacji, moim zdaniem logicznym jest założenie, że klasa to nie to samo co interfejs. Interfejs jest specyfikacją usług udostępnianych przez system. Klasa natomiast obrazuje implementację usługi. Można powiedzieć co najwyżej, że klasa posiada pewne cechy interfejsu ale też nie wszystkie i wydaje mi się, że twórcy UML znaleźli na tyle dużo rozbieżności, że opłacało się stworzyć abstrakcyjny byt Classifier i w nim zgromadzić cechy wspólne.

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

Artur Kęska:
wszystkie i wydaje mi się, że twórcy UML znaleźli na tyle dużo rozbieżności, że opłacało się stworzyć abstrakcyjny byt Classifier i w nim zgromadzić cechy wspólne.

osobiście jak mam problem z odczytaniem oryginalnej dokumentacji UML (do lekkich nie należy) to pytam programistów jak tego używają i mamy tu:
interfejs to klasa nie zawierająca atrybutów implementująca publiczne metody klas pakietu lub komponentu i realizująca "kontrakt" z którego dany komponent lub pakiet musi się wywiązać. Zaleca się poprzedzać nazwę klas będącej interfejsem literką I i oznaczać stereotypem <<interface>> np. klasa ISterowanie mająca metody a nie mająca atrybutów. Na diagramie będzie to kółeczko lub prostokąt klasa z oznaczeniem <<interface>> Innymi słowy dedykowana klasa bez atrybutów implementuje interfejs).

Dlatego wydaje mi się, że takie wątpliwości warto rozstrzygać z adresatem modeli czyli np. programistami.Jarek Żeliński edytował(a) ten post dnia 24.07.09 o godzinie 19:40

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

Jarek Żeliński:

Jerzy N.:

Jarek Żeliński:
no cóż.. moja intencją mnie było udowodnienie czegokolwiek a przekazanie mojego zdania...

Poproszę, jako niedouczony, kolegę Jerzego o odpowiedź na pytanie: co to jest interfejs? (człowiek uczy się całe życie)

Odpowiedź:
prześledź poprzednie wypowiedzi.

podobno miarą człowieka jest umiejętność udzielania odpowiedzi.... już dziękuję, rozumiem, że odpowiedź na proste pytanie czym jest interfejs przerosła...

a jako moderator tej grupy "nawołuję" do szacunku dla innych jej członków ... powyższa odpowiedź niczemu nie służy a na szanującej się uczelni (gdyby zapytał student) była by wprost nie do przyjęciaJarek Żeliński edytował(a) ten post dnia 24.07.09 o godzinie 06:33

Uuuuu.... student studentem, ale gdyby tak rozmawiać z klientem... ;)

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

W jednym z podręczników do Javy na temat interfejsu jest napisane:

"Słowo kluczowe interface generuje zupełnie abstrakcyjną klasę bazową, która jest całkowicie pozbawiona implementacji. Klasa taka pozwala swemu twórcy ustanowić nazwy metod, listy argumentów, typy zwracane - jednak bez ciał metod. Interfejs ustanawia więc formę bez jakiejkolwiek treści.
Interfejs informuje: Oto jak będą wyglądać wszystkie klasy implementujące mnie. (...) Ale interfejs to nie tylko klasa bazowa o najwyższej możliwej abstrakcyjności; (...)."

A więc w kodzie interfejs jest mega-abstrakcyjną klasą ;)
Co nie przeszkadza twórcom UML-a wydzielić go jako odrębny klasyfikator (w szeregu obok klasy, czy komponentu).Joanna Usidus edytował(a) ten post dnia 24.07.09 o godzinie 21:35

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

Joanna Usidus:
W jednym z podręczników do Javy na temat interfejsu jest napisane:

"Słowo kluczowe interface generuje zupełnie abstrakcyjną klasę bazową, która jest całkowicie pozbawiona implementacji. Klasa taka pozwala swemu twórcy ustanowić nazwy metod, listy argumentów, typy zwracane - jednak bez ciał metod. Interfejs ustanawia więc formę bez jakiejkolwiek treści.
Interfejs informuje: Oto jak będą wyglądać wszystkie klasy implementujące mnie. (...) Ale interfejs to nie tylko klasa bazowa o najwyższej możliwej abstrakcyjności; (...)."

A więc w kodzie interfejs jest mega-abstrakcyjną klasą ;)
Co nie przeszkadza twórcom UML-a wydzielić go jako odrębny klasyfikator (w szeregu obok klasy, czy komponentu).Joanna Usidus edytował(a) ten post dnia 24.07.09 o godzinie 21:35

Nie wiem co to był za podręcznik, ale specyfikacja języka Java również nic nie wspomina jakoby interfejs był specjalnym rodzajem klasy: http://java.sun.com/docs/books/jls/third_edition/html/...

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

Jarek Żeliński:
Dlatego wydaje mi się, że takie wątpliwości warto rozstrzygać z adresatem modeli czyli np. programistami.

A wyobraża Pan sobie, że inżynierowie projektujący budynki pytają wykonawców jak ci interpretują ich malowidła? Albo projektując układ elektroniczny, czy ktokolwiek ustala interpretację schematu z wykonawcą?
Wiem, te modele są prostsze, a w budownictwie o szczegółach i tak decyduje kierownik lub inny specjalista na budowie. Niemniej jednak zarówno projektant jak i wykonawca posługują się dobrze zdefiniowanym językiem, który przynajmniej w teorii powinni interpretować tak samo.

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

Artur Kęska:
Nie wiem co to był za podręcznik, ale specyfikacja języka Java również nic nie wspomina jakoby interfejs był specjalnym rodzajem klasy: http://java.sun.com/docs/books/jls/third_edition/html/...

"Thinking in Java" Bruce Eckel'a (ed. polska, wyd. IV) str. 273.
-----------
Jeżeli ktoś miałby wątpliwości co do różnic pomiędzy klasą abstrakcyjną a interfejsem, to może to pomoże:

http://www.centrumxp.pl/dotNet/1106,1,10_Interfejsy_cz...

http://acd.ovh.org/index.php?id=41Joanna Usidus edytował(a) ten post dnia 25.07.09 o godzinie 13:44

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

Joanna Usidus:

Artur Kęska:
Nie wiem co to był za podręcznik, ale specyfikacja języka Java również nic nie wspomina jakoby interfejs był specjalnym rodzajem klasy: http://java.sun.com/docs/books/jls/third_edition/html/...

"Thinking in Java" Bruce Eckel'a (ed. polska, wyd. IV) str. 273.
-----------
Jeżeli ktoś miałby wątpliwości co do różnic pomiędzy klasą abstrakcyjną a interfejsem, to może to pomoże:

Niech będzie i tak, ale co to jest "zupełnie abstrakcyjna klasa" (vide poprzedni Pani post)?

http://www.centrumxp.pl/dotNet/1106,1,10_Interfejsy_cz...

http://acd.ovh.org/index.php?id=41[edited]Joanna Usidus

Bez urazy, ale to nie ten etap nauki.

http://msdn.microsoft.com/en-us/library/aa664574(VS.71...
Tu też nikt nie pisze, że interfejs jest klasą, czy jej jakimkolwiek "pociotkiem".

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

Artur Kęska:
A wyobraża Pan sobie, że inżynierowie projektujący budynki pytają wykonawców jak ci interpretują ich malowidła?

Nie to miałem na myśli, na pewno nie "ich interpretację" w sensie "ja pod pojęciem śliwka rozumem także mandarynki", miałem na myśli dokładnie to co napisałem i co było napisane w przykładzie który Pan podał: interfejs to (na diagramie!) zebrane metody publiczne w klasie (tu fakt, że abstrakcyjnej) reprezentujące wszytko to (metody) co tak przedstawione klasy "potrafią". Czyli, jeśli mamy np. komponent zawierający sto różnych klas i na zewnątrz realizują one (ten komponent) cztery polecenia (operacje) to te cztery operacje stanowią sobą interfejs tego komponentu.

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

Artur Kęska:

Niech będzie i tak, ale co to jest "zupełnie abstrakcyjna klasa" (vide poprzedni Pani post)

Mogę się tylko domyślać (mieć nadzieję), że autor uciekł się do takiego porównania aby tym lepiej zobrazować "abstrakcyjność" interfejsu (w opracowaniu Eckel'a zabrakło wg mnie słowa JAKBY klasa).

Przykład ten wkleiłam też po to, by pokazać, jak różne opracowania potrafią różnie opisywać symbolikę i pojęcia. Cóż z tego, że źródła (Sun, OMG) podają sztywne zasady; ludzie sobie będą tłumaczyć po swojemu, używając różnych przenośni: "skuter to taki mały motor", "łoś to taki koń z rogami" itp. :)
Takich przykładów na co dzień jest niestety więcej, dlatego IMO zawsze źródłem dla nas powinna być specyfikacja OMG.

Bez urazy, ale to nie ten etap nauki.

Tytuł tematu to "ośla łączka" - więc korzystają z niego osoby na różnym etapie zaawansowania, proszę nie brać tych adresów do
siebie :)Joanna Usidus edytował(a) ten post dnia 26.07.09 o godzinie 09:20

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

Jarek Żeliński:

Artur Kęska:
A wyobraża Pan sobie, że inżynierowie projektujący budynki pytają wykonawców jak ci interpretują ich malowidła?

Nie to miałem na myśli, na pewno nie "ich interpretację" w sensie "ja pod pojęciem śliwka rozumem także mandarynki" (...)

Ale uważam, że dyskusja i tak się bardzo przydała.
Przy okazji zgłębiania tematu interpretacji symboli w opracowaniach, znalazłam w sieci wiele dyskusji na FORACH programistycznych na temat różnic pomiędzy klasą abstrakcyjną a interfejsem - okazało się, że niektórzy programiści - mają poważny problem z tymi różnicami...

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

Joanna Usidus:

Jarek Żeliński:

Artur Kęska:
A wyobraża Pan sobie, że inżynierowie projektujący budynki pytają wykonawców jak ci interpretują ich malowidła?

Nie to miałem na myśli, na pewno nie "ich interpretację" w sensie "ja pod pojęciem śliwka rozumem także mandarynki" (...)

Ale uważam, że dyskusja i tak się bardzo przydała.
Przy okazji zgłębiania tematu interpretacji symboli w opracowaniach, znalazłam w sieci wiele dyskusji na FORACH programistycznych na temat różnic pomiędzy klasą abstrakcyjną a interfejsem - okazało się, że niektórzy programiści - mają poważny problem z tymi różnicami...

To prawda, po drugie jest jeszcze bardzo istotna rzecz: pragramatyka każdego modelu należy pamiętać, że każdy obiektowy język programowania to jakaś implemntacja teorii obiektowości, która to implementacja może mieć ograniczenia. Co z tego, że w projekcie użyję jakiegoś megasymbolu zgodnego z teoria i UML skoro w konkretnej technologi będzie on nie do zaimplementowania.

To pytanie się (o ile to możliwe) programistów polega na tym, by poznać ograniczenia narzędzie które stosują i nie używać w projekcie tego czego nie da się wprost użyć w implementacji.

Bo nie ma sensu projektowanie ścianek z płyty gipsowokartonowej jeśli wiadomo, że że poza cegłami i mokrymi tynkami nie będzie innych możliwości. Jeśli mimo to architekt zaprojektuje takie ściany, tylko dlatego, że technologia taka istnieje i on o niej wie, naraża się na to, że i tak ekipa przeprojektuje sama te ściany (wykona własną implemntacje z cegły) ale tu już architekt utracił panowanie nad realizacją własnego projektu i byłby bardzo złym architektem gdyby nadal narzekał, że ktoś mu pogrzebał w projekcie, bo wiedza o ograniczeniach wykonawcy jest tu wręcz kluczem.