Welcome Guest Search | Active Topics | Members | Log In

Interfejsy a perspektywy - szkic raportu Options · View
habela
Posted: Monday, December 06, 2004 8:25:57 PM
Rank: Administration

Joined: 12/6/2004
Posts: 360
Points: 52
Załączam dyskutowany wcześniej plik (niestety dość obszerny) opisujący koncepcję interfejsów.
Głównym motywem jest tutaj zapewnienie jednolitego traktowania obiektów wirtualnych oraz obiektów konkretnych w sensie specyfikacji ich interfejsu.
Poważnym źródłem złożoności jest założenie, że jeden obiekt może posiadać wiele różnych interfejsów, klasa może wspierać różne interfejsy, a także - że jeden interfejs może być implementowany przez różne klasy.
Drugie źródło złożoności to unikanie pojęcia ekstensji. Klasa będzie miała w bazie danych tyle miejsc występowania, ile zostanie zadeklarowanych "zmiennych" (w terminologii UML mówilibyśmy o własnościach strukturalnych (structural feature), które mogą określać obiekty-korzenie bazy, albo mogą składać się na stan obiektów określonej klasy.
Wszystkie te założenia prowadzą do istotnej modyfikacji sposobu definiowania perspektyw, choć zasadnicze mechanizmy pozostają niezmienione.
Zwracam uwagę na nadal obszerną sekcję "otwarte kwestie" i zapraszam do dyskusji.
Niebawem zostanie uporządkowana (nieco uproszczona) i wyspecyfikowana propozycja składni (dostępnej na razie tylko w postaci przykładów).
Sprawą na osobny wątek będzie też poruszona już w dyskusji kwestia: liczności / tablice / sekwencje.
Uzupełnimy też doprecyzowaną ostatnio przez Krzysztofa Kaczmarskiego składnię dla definiowania kluczy.

<załącznik zastąpiono nowszą wersją>
habela
Posted: Tuesday, December 07, 2004 1:55:32 PM
Rank: Administration

Joined: 12/6/2004
Posts: 360
Points: 52
Dodam, że w tym dość długim tekście, problemem o największym chyba ciężarze gatunkowym są zmiany w sposobie definiowania perspektyw.
Interesują mnie zatem opinie osób obeznanych z views na temat tego, czy nie zanadto tu "narozrabialiśmy" (być może da się zachować przezroczystość obiektów wirtualnych w jakiś bardziej konserwatywny sposób??).
Pojęciem, które powoduje zamieszanie jest rozumiana po UML-owemu feature, która logicznie (ale nie fizycznie) wprowadza jakby poziom pośredni pomiędzy obiektem nadrzędnym, który ją posiada a jego podobiektami (jakby "partycjonując" dopuszczalną zawartość obiektu nadrzędnego). To znaczy, że np. wstawiając do obiektu Osoba obiekt o nazwie imię, bierzemy pod uwagę, że ten podobiekt będzie przynależał do własności strukturalnej imię : String i należy respektować zadeklarowane dla tej konkretnej własności ograniczenia i ewentualne efekty uboczne, jeśli takowe wyspecyfikowano...
stencel
Posted: Wednesday, December 08, 2004 12:05:55 PM

Rank: Advanced Member

Joined: 12/7/2004
Posts: 598
Points: 74
Location: Raszyn
Piotrze, dodaj prosze osobny topic, w ktorym beda tylko kolejne wersje Twojego dokumentu.
To jest konieczne zeby laywo mozna bylo je znalezc. Oczywiscie trzeba tez te wersje
umieszczac w glownym watku dyskusji, ale taki watek tylko z dokumentem bedzie
bardzo wazny. Probowalem sam go dodac, ale mi nie wyszlo, bo nie wiem, jak na tym
forum zalaczyc zalaczniki w poscie.

Teraz merytoryczne.

Ciagle mam problemy z uzywana przez Ciebie terminologia (zwlaszcza magiczne, nic
nie znaczace feature z UML), ale poniewaz sa przyklady, to moge sie odniesz do
koncepcji, ktorych wczesniej nie kapowalem. Dla mnie zawsze lepsze sa konkrety,
tj. przyklady, przyklady i przyklady. Ich nigdy za duzo.

Dobrze by bylo, zeby pokrywaly one wsztstkie opisywany koncepcje. Wydaje mi sie,
ze obecnie nie ma i trzeba dorobic:

1. Klasy, ktora implementuje nazwany gdzie indziej interfejs(-y).
2. Klasy, ktora jest dynamiczna rola.
3. Klasy, ktora dziedziczy po innej klasie (-ach).
4. Asocjacji w klasie.
* Czy musimy w ogole je miec? Po co kopiowac relationship z ODMG? Czy nie lepiej
po prostu poslugiwac sie atrybutami typow referencyjnych?

5. w przykladzie 3 jest {dzial where ... d } i to niedopowiedzenie bardzo mi
przeszkadza. Czy moglbys je jakos konkretnie uzupelnic? I jaka jest rola tego
"d"? Gdzie sie go uzywa? Mozesz jakos uzupelnic? Moze w tresci metody
"zarejestrujZgloszenie"? Jesli tak, to trzeba jakos uzupelnic jej tresc
(nawet ulomnie).

Zauwazylem tez, ze niestety to, co piszesz ma sie nijak do raportu o typach i
pracy doktorskiej Rafala Hryniowa. Czy czytales ten raport? Czy uwazasz ze mozna
to jakos ujednolicic? Bo nie mozemy miec dwoch roznych systemow typow i
stylow deklaracji? Ogolnie, czy masz jakis pomysl, jak te dwa nurty
(TYPE vs. INTERFACE) pozenic. TYPE oznacza zbior koncepcji opisanych w raporcie
Rafala a INTERFACE to zbior koncepcji opisanych w Twoim dokumencie.

habela
Posted: Friday, December 10, 2004 9:55:45 PM
Rank: Administration

Joined: 12/6/2004
Posts: 360
Points: 52
Podsyłam obiecany plik z przykładami. Tym razem dokument jest krótki i składa się z samej konkretnej składni. Na razie co i rusz jakieś zmiany, więc mogą być niespójności.
Jeden z problemów jaki chciałbym zasygnalizować: skoro mamy efektywnie teraz tylko public i private, to czy przy dziedziczeniu z klasy do klasy oraz z obiektu roli do obiektu bazowego, powinny być dla dziedziczącego widoczne tylko własności ujęte w domyślnym interfejsie klasy bazowej, czy cała prywatna zawartość?

<załącznik po korektach został włączony do dokumentu Interfejsy5.doc>
michal
Posted: Friday, December 10, 2004 11:21:43 PM

Rank: Advanced Member

Joined: 12/6/2004
Posts: 332
Points: -61
A ja przesylam moja wersje. Na razie nie myslalem jaki to ma sens,
tylko przerobilem skladnie na wstepnie zgodna z moja wizja.

File Attachment(s):
moduly.txt (3kb) downloaded 60 time(s).


habela
Posted: Saturday, December 11, 2004 2:13:39 PM
Rank: Administration

Joined: 12/6/2004
Posts: 360
Points: 52
Niebawem trochę odświeżę i poprawię wysłany wczoraj plik.
Quote:
Przyklad 1:

module Przyklady.Firma {
Dzial<0..*> : KlasaDzial;

class KlasaDzial {
.....

Czy to tylko przykład, czy z jakichś powodów będziesz wymagał, aby zawsze w tym samym module była deklaracja "zmiennej" dla deklarowanej tam klasy?
Quote:

public, private, interface...

Ja proponowałem tu słówko export. Wprawdzie wygląda bardziej egzotycznie (a ludzie "lubią piosenki, które już kiedyś słyszeli"), ale, zamiast 3 słów kluczowych mamy jedno, bo pasuje ono zarówno do "oflagowania" upublicznianej własności (jak public) oraz do zadeklarowania nazwanej definicji interfejsu (jak interface).
Quote:
public, get, set:
NazwaDzialu : string;
AdresDzialu : string;

Ja też bym wolał, żeby te modyfikatory dostępu mogły sobie siedzieć przed deklaracją danej własności, albo lepiej, jak tu - nawet przed blokiem tak samo udostępnianych własności. Ale... bardzo zależy mi, aby zachować jednolitą składnię w obu wypadkach:
- gdy jak wyżej, w klasie dla własności konkretnych po prostu mówimy że coś pozwala np. na aktualizację (tj. set, czy update) i już;
- gdy stwierdzamy to samo (znowu samym tylko słowem kluczowym) w definicji nazwanego interfejsu (albo - można rzec - w definicji nazwanego eksportu ;-)
- gdy we wnętrzu klasy lub definicji perspektywy, definiujemy, w nawiasach klamerkowych, implementację tej operacji generycznej.
Sprawa dotyczy nie tylko rozsądnej lokalizacji tych słów kluczowych, ale także tego, aby odzwierciedlały nazwy wykonywanych przy tej okazji operacji generycznych (obstaję przy retrieve, update, insert, delete).
Quote:
PrywatnaMetodaPomocnicza : boolean {
// ...
}

Zgoda z tym przesunięciem: skoro atrybuty deklarujemy po pascalowemu, to sygnature operacji tez. (Choć jakiś powód dla tej niekonsekwencji miałem, ale w oparciu o te przykłady niestety go nie kojarzę...).
Quote:
Przyklad 2:

....
Zatrudniony<0..*> : Pracownik inverse MiejsceZatrudnienia;
Kierownik<0..1> : Dyrektor inverse Kieruje;
....

To trzeba wyjaśnić (nie zareagowałem, jak napisałeś w innym wątku, że osoba w osobie fizycznie zagnieżdżona być nie może). Czy zakładasz, że zawsze jak w obiekcie dział będzie umieszczony pracownik, to będzie się to mogło odbywać wyłacznie poprzez wskaźnik? (tj. dyskutowana płaska struktura)?? Czy też zakładasz, że może być tak i tak. Ale wtedy - nie połykałbym tego słówka kluczowego ref czy jak kto woli association, bo jeśli inverse uczynimy opcjonalnym, to nie będzie jak odróżnić!
Quote:
Przyklad 3:
// w tym przykladzie bylo cos namieszane
// i nie potrafilem przetlumaczyc

Próbowałem tam odpowiedzieć na postawioną przez Ciebie kwestię widoczności deklaracji z wnętrza zagnieżdżonych modułów. W obu wypadkach potrzebujemy użyć w deklaracji (jako nadklasy) klasy, która została zadeklarowana w innym module. Ilustracja pokazuje moją propozycję kryteriów, kiedy trzeba używać import-u, a kiedy nie.
Quote:
Przyklad 4:

...
public, get, create, delete:
Osoba<1..*> : KlasaOsoba;

Nie utożsamiałbym insert-a z create! Create kojarzy się z konstruktorem, a obiekt Osoba, który chcielibyśmy tam umieścić mógłby zostać utworzony nawet przed stworzeniem klasy czy interfejsu, w którym ww. deklaracja się znajduje. Create obiektu Osoba to moim zdaniem inna bajka i znajduje się poza zakresem odpowiedzialności interfejsu, który używa Osoby jako jednej z własności.
Quote:
Przyklad 5:
...

// to mnie denerwuje. strasznie zaciemnia kod
Kontakt<0..*> : virtual( (Dzial where Przedstawicielstwo) as d ) DaneKontaktoweJednostki {
...

Tutaj (nareszczie ;-) się zgadzam. Przykład trochę niewdzięczny, bo tu akurat zamiast gotowej klasy podstawiamy perspektywę.
Prostsza ilustracja problemu i odmienne (bardziej chyba trafne) podejście jest u mnie w przykładzie 1a. Otóż tam, klasa Dzal implementuje interfejs JednostkaOrganizacyjna i (jak w Javie) oznacza jawnie obiecane przez ten interfejs własności jako upubliczniane. W przykładzie z perspektywą miałoby się to dziać implicite, przez sam fakt implementowania interfejsu. To jest chyba niepożądane.
Nasuwa się pytanie, czy wobec tego, jesli przyjąć strukturalne kryteria zgodności interfejsów, deklarowanie, że klasa implementuje dany interfejs jest obowiązkowe.
Quote:
Przyklad 6:
....
role Dyrektor of Pracownik {
...

Tak składnia wygląda zgrabniej niż class Dyrektor role of Pracownik. Ale...
Wyobrażam sobie, że zamiast deklarować klasę roli, możnaby stworzyć tylko abstrakcyjny interfejs. Wtedy trzeba by rozróżnić: export Dyrektor role of Osoba od class Dyrektor role of Osoba.
stencel
Posted: Sunday, December 12, 2004 11:51:13 AM

Rank: Advanced Member

Joined: 12/7/2004
Posts: 598
Points: 74
Location: Raszyn
Od razu odpowiadam na obie propozycje: Piotra i Michala, przy czym zaznaczam, ze badziej sympatyzuje z propozycja Piotra, jako ze wg mnie jego pomysly sa blizsze duchowi SBA. Tego ducha zawsze powinnismy miec na uwadze.

Aha, no i podziekowania dla Piotra za wymyslenie i wrozenie idei forum, bo jak widac sprawdza sie ono znakomicie, a dyskusja idzie az wiory leca. Co wiecej, mysle ze zblizamy stanowiska, bo jak pierwszy szkic Piotra wzbudzal moj sprzeciw, tak teraz jestem gotow wiele rzeczy popierac.

Tak naprawde nie o skladnie przykladow tu chodzi, ale o koncepcje, ktore najczesciej najlepiej widac na dopracowanych skladniowo przykladach, dlatego tak sie przy nich upieram.

O propozycji Piotra. Zakladam, ze w przykladzie 1:

Code:
} instance Dzial


oznacza niezmiennicza nazwe obiektow klasy Dzial. Jesli tak nie jest to protestuj. Wpp milcz, bo nie ma co zasmiecac dyskusji. Jesli tak, to mi sie skladnia bardzo podoba.

Przyklad 1a zawiera klase implementujaca interfejs i skladnia mi nie odpowiada:

Code:
class Dzial : JednostkaOrganizacyjna {


bo moze dotyczyc zarowno dziedziczenia po klasie jak i implementacji interfejsu. A to sa inne rzeczy. Ogolnie bardzo podoba mi sie slowko "export" uzywane w sposob uniwersalny do obslugi interfejsow. Nie podoba mi sie Piotrze to co zrobiles w przykladzie 1 uzywajac tego slowka do oznaczenia kazdego elementu oddzielnie. Uwazam, ze slowko export powinno oznaczac definicje lub uzycie interfejsu, a wiec w ramach klasy:

Code:
export { features }; // definicja nienazwanego interfejsu tej klasy (moze byc tylko jeden)
export ABC { features }; // definicja nazwanego  interfejsu tej klasy (moze byc wiele)
export EFG; // deklaracja, ze klasa implementuje zdefiniowany gdzie indziej interface EFG


Slowko interfejs nie powinno byc w ogole inaczej uzywane. Oczywiscie moze ono tez sluzyc do zdefiniowania nazwanego interfejsu na najwyszym poziomie modulu. Poprzednia wersja przykladu 1 byla lepsza pod wzgledem uzycia slowka "export".

W przykladzie 1a byloby wiec:

Code:
class Dzial {
  export JednostkaOrganizacyjna;


Uwazam, ze fakt implementowania jakiegos interfejsu musi byc jawnie zadeklarowany i nie ma mowy o jakims implementowaniu interfejsu I przez klase K poprzez strukturalna zgodnosc interfejsu I z eksportem klasy K. K implementuje interfejs I wtw. jest to jawnie zadeklarowane w klasie K.

Piotrze, jesli trzeba, to moge przerobic przyklady zgodnie z Twoja idea (gdy nie sie nie zgadzasz z nia, to przyklady moglyby przekonac; gdy sie zgadzasz, moglbym Ci oszczedzic roboty).

Oczywiscie w klauzuli "inverse" nie ma potrzeby wskazywac nazwy zwrotnego interfejsu. ODMG to byly lamy.

W przykladzie 2 w interfejsie DaneKontaktoweJednostki moj sprzeciw budzi zagniezdzenie obiektu. Ale ostatecznie jest to poprawne. Ustalona nazwa obiektow Osoba nie przeszkadza tu. W koncu jak ktos chce innej nazwy, to moze napisac:

Code:
kontakty : ref to Osoba[1..*] retrieve, insert, delete;


albo z uzyciem zagniezdzonego obiektu zlozonego:

Code:
kontakty : struct { Osoba[1..*] } retrieve, insert, delete;


albo (jak wolicie; skladnia moze byc rozmaita):

Code:
struct kontakty { Osoba[1..*] } retrieve, insert, delete;



W przykladzie 3 nie ma sensu podawac licznosci obiektow wirtualnych "kontakt", bo przeciez ich licznosc wynika z licznosci wynikow zapytania {Dzial where ...}.

Teraz o dokumencie Michala.

Podoba mi sie pomysl z definiowaniem zmiennych na top-levelu modulu, ale nazwa (zgodnie z M1) powina byc wprowadzona przy definicji klasy, a wiec przyklad 1:

Code:
module Przyklady.Firma {
    Dzial[0..*];

    class KlasaDzial {
                   .....
    } instance Dzial;
}


Znacznie bardziej podobaja mi sie nazwy operacji u Piotra (retrieve, insert, delete, update) niz u Michala (get, set etc). Te Piotrkowe sa bardziej zgodne z SBA. O kwestii public i export wypowiedzialem sie wczesniej. "export" jest naprawde super. I nie ma co dodawac jeszcze "interface". Mysle, ze tam gdzie Michal napisal "create" mial na mysli "insert".

Uwazam, ze tez, ze "ref to" jest konieczne, zeby rozroznic je od zagniezdzania obiektow.

habela
Posted: Sunday, December 12, 2004 1:35:34 PM
Rank: Administration

Joined: 12/6/2004
Posts: 360
Points: 52
Quote:
moze dotyczyc zarowno dziedziczenia po klasie jak i implementacji interfejsu

Naturalnie - dwie różne. Choć trzeba jednak pamiętać, że jak dziedziczymy po klasie, to od razu pociąga za sobą implementowanie jej interfejsów...
Generalnie - pomysł aby implementowanie interfejsu przez daną klasę oznaczać słowem kluczowym export podoba mi się.
Przy okazji nasuneło mi się pytanie - czy jeśli zdecydujemy się na nazwę obiektu jako niezmiennik - to czy tylko w ramach klasy, czy także w ramach dowolnego innego nazwanego interfejsu?

Quote:
"export" uzywane w sposob uniwersalny do obslugi interfejsow. Nie podoba mi sie Piotrze to co zrobiles w przykladzie 1 uzywajac tego slowka do oznaczenia kazdego elementu oddzielnie. Uwazam, ze slowko export powinno oznaczac definicje lub uzycie interfejsu, a wiec w ramach klasy:

Muszę tu wspomnieć, że pierwotnie tak było, że export bez nadanej nazwy wyznaczał sekcję, w której umieszczone były upubliczniane własności.
Natomiast Krzysztof Kaczmarski zasygnalizował testując tę składnię na swoim przykładzie, że bardzo frustrująca jest (przy tworzeniu domyślnego interfejsu danej klasy) konieczność powtarzania deklaracji upublicznianych własności w takiej sekcji export. Zaproponował, aby wobec tego przyjąć, że to co jest zadeklarowane w domyślnym interfejsie (nienazwana klauzula export wewnątrz klasy), było już traktowane jako część definicji klasy. I aby pod spodem trzeba było dopisywać już tylko własności prywatne.
Mnie się to zdecydowanie nie podobało, bo zaczynało się robić brzydko w przypadku podobiektów wirtualnych (w klauzuli export pojawiałyby się elementy implementacyjne). Ponadto, nie byłbym w stanie np. zadeklarować, że dla metod danej klasy dany podobiekt implementuje np. możliwość jego aktulalizacji, a dla sięgających z zewnątrz - już nie.
Uznałem jednak powagę problemu tej nadmiarowości - i stąd w przykładach powrót to możliwości osobnego etykietowania poszczególnych własności słowem export.
Quote:
Piotrze, jesli trzeba, to moge przerobic przyklady zgodnie z Twoja idea (gdy nie sie nie zgadzasz z nia, to przyklady moglyby przekonac; gdy sie zgadzasz, moglbym Ci oszczedzic roboty).

Ok - załączam wobec tego plik w wersji w międzyczasie lekko skorygowanej.
Quote:
Oczywiscie w klauzuli "inverse" nie ma potrzeby wskazywac nazwy zwrotnego interfejsu. ODMG to byly lamy.

Też mi się tak wydaje, choć trzeba się będzie zastanowić, czy nie ma tu jakichś pułapek związanych z grafem dziedziczenia (ale dopuszczenie tu pewnej dowolności --- np. inverse którego deklaracja w przeciwległej klasie prowadzi do naszej podklasy - grozi sporą złożonością...).

Quote:
W przykladzie 3 nie ma sensu podawac licznosci obiektow wirtualnych "kontakt", bo przeciez ich licznosc wynika z licznosci wynikow zapytania {Dzial where ...}.

W niektórych wypadkach to może okazać się ważne. Wszak mówimy o aktualizowalnych perspektywach, toteż liczność może kontrolować dopuszczalność wstawienia lub usunięcia!

Quote:
albo z uzyciem zagniezdzonego obiektu zlozonego:
Code:
kontakty : struct { Osoba[1..*] } retrieve, insert, delete;

albo (jak wolicie; skladnia moze byc rozmaita):
Code:
struct kontakty { Osoba[1..*] } retrieve, insert, delete;

Tutaj ostrożnie... Struct będzie oczywiście występował m.in. w metamodelu rezultatu zapytania, natomiast nie jestem pewien, czy chciałbym mieć to słowo kluczowe w DDL... Może lepiej odizolować się od możliwości takich potencjalnie wielopoziomowych definicji, wymagając w razie czego zadeklarowania na tę potrzebę klasy?
stencel
Posted: Sunday, December 12, 2004 6:17:16 PM

Rank: Advanced Member

Joined: 12/7/2004
Posts: 598
Points: 74
Location: Raszyn
habela wrote:
Uznalem jednak powage problemu tej nadmiarowosci - i stad w przykladach powrót to mozliwosci osobnego etykietowania poszczególnych wlasnosci slowem export.


No trudno. Ja tu jestem zwolennikiem porzadku koncepcyjnego kosztem pewnej nadmiarowosci. Niech programista mapisze troche wiecej, ale niech to ma rece i nogi. W wypadku PL/SQL, Turbo Pascala czy C/C++ w czesci implementacyjnej trzeba powtarzac naglowki procedur. I jakos ludzie z tym zyja. Zobaczcie, ze, np:

Code:
export nazwa : string retrieve, update;


jest pomieszaniem dwoch rzeczy: interefejsu i deklaracji typu danych. Dlatego jestem wrogiem tej notacji i uwazam ze trzeba to rozdzielic. Porzadek pojeciowy jest wazniejszy niz drobna nadmiarowosc.

habela wrote:
Tutaj ostroznie... Struct bedzie oczywiscie wystepowal m.in. w metamodelu rezultatu zapytania, natomiast nie jestem pewien, czy chcialbym miec to slowo kluczowe w DDL... Moze lepiej odizolowac sie od mozliwosci takich potencjalnie wielopoziomowych definicji, wymagajac w razie czego zadeklarowania na te potrzebe klasy?


To nie musi byc struct. To musi byc mozliwosc definiowana zagniezdzonych struktur w miejscu. Koniecznosc dodawania w takiej sytuacji nowej "sztucznej" klasy nie jest dobra, bo przeczy relatywizmowi obiektow i duchowi SBA. Jesli nie lubisz "struct" to mozna i bez tego zasygnalizowac zlozony podobiekt.

Code:
kontakty :  { Osoba[1..*]; }


Mamy podobiekt zlozony (jak w skladzie) a nie struct (jak w rezultacie apytania).
michal
Posted: Tuesday, December 28, 2004 5:40:22 PM

Rank: Advanced Member

Joined: 12/6/2004
Posts: 332
Points: -61
czy pojawilo sie tutaj cos nowego?
czy dysponujemy juz uporzadkowana wersja interfejsow?
stencel
Posted: Wednesday, December 29, 2004 1:56:44 PM

Rank: Advanced Member

Joined: 12/7/2004
Posts: 598
Points: 74
Location: Raszyn
michal wrote:
czy pojawilo sie tutaj cos nowego?
czy dysponujemy juz uporzadkowana wersja interfejsow?


Ostatnio nic. Moze Piotrze udaloby Ci sie uaktualnic ten tekst na podstawie wynikow praktycznie juz martwej dyskusji?
habela
Posted: Wednesday, December 29, 2004 3:25:23 PM
Rank: Administration

Joined: 12/6/2004
Posts: 360
Points: 52
W załączeniu dokument o interfejsach skrócony i zaktualizowany (mam nadzieję, że trafnie...) o rezultaty tutejszej dyskusji.
Przykłady trochę ilustrują, niemniej jednak postaram się w najbliższych dniach uzupełnić ten szkic składni o gramatykę.
Oczywiście - czekam na dalsze uwagi.

(ostatnia aktualizacja - 14.01.2005 - dotyczy pliku z DDL - usunięto go z niniejszego postu oraz zamieszczono i skomentowano poprawioną wersję niżej)

Niżej zaś plik z propozycją składni (EBNF w stylu stosowanym w specyfikacji standardu CORBA; gruntowna modyfikacja DDL-a zrobionego przy okazji prac nad grid-owym raportem IPI) - niestety na razie bez opisu, toteż ciężko strawne...; ważniejsze komentarze - tutaj:
- na razie nie poruszony temat tablica<>sekwencja. Założyłem tutaj, że dysponujemy jednym (w sensie sposobów dostępu) sposobem przechowywania uporządkowanych podobiektów, toteż występują nawiasy kwadratowe - czyli mamy tylko liczności plus flagę "ordered".
- pozostawiony narzut związany z bazami rozproszonymi (określanie współzależności replikacji);
- są też środki do deklarowania unikalności, co też dociąża nieco składnię;
- gramatyka nie była uruchamiana - mogę zagwarantować, że zawiera w tej chwili jakieś błędy...

File Attachment(s):
Interfejsy5.doc (106kb) downloaded 44 time(s).


habela
Posted: Saturday, January 01, 2005 4:06:47 PM
Rank: Administration

Joined: 12/6/2004
Posts: 360
Points: 52
Dwie kwestie warte uzgodnienia:

1) Czy jeśli definicja związku asocjacyjnego w interfejsie po jednej stronie dwukierunkowej asocjacji dopuszcza dodawanie (insert) powiązania, to jeśli po drugiej stronie bliźniacza definicja na to nie pozwala:
a) powinno to być traktowane jako niespójność schematu;
b) powinno to uniemożliwiać [użytkownikowi posługującemu się danym schematem] dodanie powiązania za pomocą bezpośredniej operacji generycznej;
c) dodanie powiązania za pomocą bezpośredniej operacji generycznej powinno być dopuszczone (o ile polecenie jest wywołane po odpowiedniej stronie) i przeciwległe powiązanie zostanie (zgodnie z regułami integralności referencyjne) utworzone.

2) W przykładzie 3 mamy następujące zagadnienia:
- Deklaracja własności "globalnych" (tj. obiekty przechowywane bezpośrednio w module) - zarówno wirtualna jak i konkretna.
Pytanie - czy wzorem klasy warto stosować na poziomie modułu mechanizm hermetyzacji (wyróżniając, co jest eksportowane, a co nie?) - na pierwszy rzut oka wydaje się to mało przydatne.
- Deklaracja własności wirtualnej (tutaj - kontakt) konstruuje złożony obiekt wirtualny. Na potrzeby tego obiektu definiuje również metodę, czyli, że cała definicja tej perspektywy (tj. własności wirtualnej) zawiera w sobie jakby stworzoną ad-hoc, anonimową definicję klasy. Teraz pytanie: czy w takiej sytuacji powinniśmy wprowadzać hermetyzację (tj. wymów definiowania w klauzuli export dostępnych na zewnątrz własności)? Wygląda na to, że dla ogólnej spójności należałoby tak uczynić (czyli przykład 3 byłby bardziej skomplikowany...).
michal
Posted: Tuesday, January 04, 2005 10:23:35 PM

Rank: Advanced Member

Joined: 12/6/2004
Posts: 332
Points: -61
czy zastanawiales sie juz troche dokladniej
w jaki sposob zrealizowac kwestie bezpieczenstwa?

zalozmy ze mamy 2 schematy: jan i stefan.
jan zawiera definicje klasy A i interfejsy do niej iA1, iA2.
jan chcialby udostepnic dostep do obiektow klasy A
za pomoca interfejsu iA2 stefanowi. co musi zrobic?
habela
Posted: Tuesday, January 04, 2005 10:41:32 PM
Rank: Administration

Joined: 12/6/2004
Posts: 360
Points: 52
michal wrote:
zalozmy ze mamy 2 schematy: jan i stefan.
jan zawiera definicje klasy A i interfejsy do niej iA1, iA2.
jan chcialby udostepnic dostep do obiektow klasy A
za pomoca interfejsu iA2 stefanowi. co musi zrobic?


Pomysł jest póki co dość mglisty.
Wyobrażam to sobie tak, że administrator bazy przypisałby stefanowi schemat, w którym ten sam moduł miałby ewentualnie szczuplejszy zasób definicji klas i interfejsów niż w schemacie głównym. Zaś - co najważniejsze - definicja odpowiedniej własności wewnątrz tego modułu, posiadająca taką samą nazwę jak rzeczone obiekty klasy A, byłyby zadeklarowane w schemacie stefan jako wystąpienia iA2, i czyniłoby to ich rzutowanie na iA1 lub na A niepoprawnym.
habela
Posted: Friday, January 14, 2005 2:52:49 PM
Rank: Administration

Joined: 12/6/2004
Posts: 360
Points: 52
Spore zmiany w konstrukcjach DDL.
1) zauważyłem, że w klasach brakowało definicji domyślnego (bazowego) interfejsu - dodałem klauzulę export { ... }.
2) zmiana słowa kluczowego interface na export (koncepcyjnie nieco bardziej pasuje, zwłaszcza gdybyśmy z powodu zwięzłości składni chcieli w przyszłości dopuścić zamiast dublowania w klauzuli export deklaracji upublicznianych własności - poprzedzanie ich - na podobieństwo słówka public - słowem kluczowym export)
3) zmienione podejście do sygnatur operacji (tutaj poruszam się trochę po omacku, więc proszę o skorygowanie z punktu widzenia poprawności oraz zgodności z zakładanym obecnie systemem komunikowania parametrów - na razie zakładam, że byłby 1 domyślny - np. strict call by value).

File Attachment(s):
DDL-draft03a.doc (42kb) downloaded 56 time(s).


habela
Posted: Monday, January 24, 2005 9:15:34 AM
Rank: Administration

Joined: 12/6/2004
Posts: 360
Points: 52
Najważniejsze tezy w postaci artykułowego tekstu po angielsku.
Do ewentualnego skomentowania, względnie do zaproponowania pomysłu na pochodny artykuł w przyległych tematach.
<załącznik zastąpiono nowszą wersją w dalszej części wątku>
stencel
Posted: Monday, January 24, 2005 10:40:17 PM

Rank: Advanced Member

Joined: 12/7/2004
Posts: 598
Points: 74
Location: Raszyn
Uff, moze juz jestem jakis lewy, ale tekst, ktory napisales po angielsku, jest o niebo czytelniejszy niz ten polski. Albo ja nie umiem czytac po polsku, albo Ty nie umiesz pisac w tym jezyku ;) W kazdym razie ja umiem czytac angielski a Ty umiesz w tym jezyku pisac.

Zanim zadam jakies szczegolowe pytania, chce zwrocic uwage, ze trzeba w abstrakcie i Introducion podkreslic, dlaczego nasze podejscie jest super. Bo inaczej recenzenci spuszcza nas do kanalu. I to trzeba miec spisane w punktach zanim naniesie sie to na tekst. Widze juz nastepujace punkty (kazdy z forumowiczow nie uzupelnia te liste):

1. Jednakowe traktowanie (definiowanie uprawnien) dla obiektow wirtualnych i konkretnych.
2. Pelna przezroczystosc obiektow wirtualnych.
3. Mozliwosc definiowania uprawnien uzytkownikow do poszczegolnych interfejsow (bardzo wazne w wypadku baz danych).
4. Interfejsy, klasy, perspektywy sa obiektami pierwszej kategorii (bardzo wazne w wypadku baz danych).

Ta lista jest bardzo wazna, bo od niej zalezy powodzenie artykulu, tzn. to, czy uda sie go sprzedac.

Ad 3 i 4. Zalaczam list Szefa do Piotra (wiele wyjasnia).

Subieta-to-Habela wrote:
To, co wydaje sie konieczne do podkreslenia na wstepie dotyczy istotnej roznicy pomiedzy interfejsami w jezykach programowania i interfejsami w bazach danych. W jezykach programowania nie wystepuje potrzeba ani mozliwosc dawania uprawnien do poslugiwania sie poszczegolnymi interfejsami dla poszczegolnych programistow. W bazach danych jest to konieczne i jest to dodatkowy wymiar tego, co nazywamy encapsulation. Tego wymiaru nie uda sie osiagnac w inny sposob niz traktujac interfejsy jako byty pierwszej kategorii programistycznej, czyli cos co moze byc dynamicznie wstawione/usuniete do/z bazy danych. Ten wymiar w prostej linii prowadzi do aktualizowalnych perspektyw jako odpowiednikow interfejsow.

Moze byloby takze warto podkreslic pewna dalsze roznice. Mianowicie, klasyczne interfejsy sa tylko specyfikacja, czyli sa drugiej kategorii programistycznej. Ich implementacja jest klasa. W naszym przypadku mamy 3 warstwy: interfejs ma specyfikacje (jak zwykle), ma implementacje w postaci aktualizowalnej perspektywy, oraz ostateczna implementacje w postaci klasy.


Jesli chodzi o szczegoly to:

1. Na stronie 4 w przykladzie uzylbym dwa razy deref(es) i deref(bs) zamiast es+"" i bs+"".
2. Na stronie 6 chyba cos sie urwalo w bullecie "Operations". Robi wrazenie niezakonczonego.
3. Str. 7 Fig. 1. Nie ma nazwy roli dla polaczenia Module->Feature, choc jest taka nazwa (definedIn) dla zwiazku Module->Interface. Nie ma tez nazwy jednej roli w zwiazku AssocLink<->AssonLink (jesli mialaby byc jedna rola to chyba po drugiej stronie, a nie pos stronie strzalki?)
4. Str. 11-12. Przyklady. Uwazam, ze oba moduly powinny miec rozne nazwy. Pierwszy definiuje eksporty a drugi ich implementacje, wiec drugi powinien miec inna nazwe. Wedlug mnie czysciej bedzie jak beda to dwa rozne moduly niz jeden w dwoch wersjach. Dlatego nazwal bym je inaczej i usunal wielokropki na koncu pierwszego i na poczatku drugiego. Drugi z nich ma miec deklaracje importu pierwszego.
5. W przykladach uzywasz slowa kluczowego "implements" mimo ze wczesniej piszesz ze bedziemy uzywac "supports' na oznaczenie deklaracji implementacji eksportu.
6. Str. 13 Przyklady. Jest import jakiegos Samples.Documents, ktory nie pojawia sie w tekscie. Uwazam, ze to nie dobrze. Przyklady maja byc self-contaned. Moze z tego powodu warto tez napisac jakies proste kody metod?

Jesli chodzi o gramatyke angielska to mam wiele zastrzezen, ale przy koncu prac merytorycznych, pozwole sobie poprosic o prawo do wygladzenia gramatyki angielskiej ostatecznego tekstu. W tej fazie jest to zbedne o ile rozumiemy tekst. A przeciez rozumiemy.

Jesli bedziesz chcial, to mozesz mi powierzyc wprowadzenie do tekstu sugestii Szefa i tych moich sugestii, z ktorymi sie zgodzimy.
habela
Posted: Monday, January 24, 2005 11:05:03 PM
Rank: Administration

Joined: 12/6/2004
Posts: 360
Points: 52
Ogólnie ze wszystkimi tezami się zgadzam.
Przy czym ten element:
stencel wrote:
3. Str. 7 Fig. 1. Nie ma nazwy roli dla polaczenia Module->Feature, choc jest taka nazwa (definedIn) dla zwiazku Module->Interface. Nie ma tez nazwy jednej roli w zwiazku AssocLink<->AssonLink (jesli mialaby byc jedna rola to chyba po drugiej stronie, a nie pos stronie strzalki?)

zostawiłbym tak jak jest, gdyż:
a) w metadanych opisujących wzajemnie zwrotne kierunki asocjacji tkwi potężna nadmiarowość, tak więc meta-asocjacja "reverse" jest zupełnie wystarczająca w wydaniu jednokierunkowym;
b) nazwa roli w asocjacji - właśnie po stronie strzałki. Też uważam, że to głupawa konwencja, ale w składni UML tak zrobili (z powodu dopuszczania tych nieszczęsnych asocjacji n-arnych z rombem... :-( )
Aha - to znaczy w kwestii drugiej części cytowanego podpunktu. Bo co do pierwszej, to rzeczywiście warto uzupełnić nazwę roli po stronie kompozycji - mam XDE, więc ja to zrobię.

Pozostałe sprawy - w tym wskazane tu kierunki argumentacji (tj. zachwalania naszego podejścia w abstrakcie i nie tylko) - w pełni się zgadzam. Do tekstu nie zajrzę pewnie wcześniej niż we czwartek, tak więc Krzyśku - możesz zgodnie z podanymi uwagami edytować, o ile tylko równocześnie Szef nie zaleci jakichś bardziej gruntownych zmian w rozwiązaniach...
stencel
Posted: Monday, January 24, 2005 11:26:23 PM

Rank: Advanced Member

Joined: 12/7/2004
Posts: 598
Points: 74
Location: Raszyn
Dobrze, to ja sobie pohulam z tym tekstem do czwartku (a moze do piatku, bo akurat bede na wyjezdzie daleko od rodziny i bede mial wiecej czasu na prace). Mysle ze jeden dzien mi podarujesz, jesli bede mial dobre pomysly. Zakladam, ze rysunek w kwestii roli asocjacji Module->Feature poprawisz Ty. Jesli chodzi o UML, zdaje sie na Twoja wiedze, bo choc kiedys przetlumaczylem ksiazke o UML, to teraz jestem mocno do tylu.

W kwestii on_insert vs. on_create uwazam, ze jedno z nich jest nam potrzebne a drugie redundantne. On_insert na poziomie zagniezdzenia "n" oznacza on_create na poziomie zagniezdzenia "n+1". W szczegolnosci on_create w bezposrednim skladniku modulu oznacza on_insert dla modulu. Tu widac kiepskosc tej koncepcji (wielowariantowosc takiego on_insert na module), dlatego jestem za on_insert (a tak naprawde on_create) opisanym w tekscie.

Poniewaz teraz ja pracuje na tekscie dlatego prosba do Szefa by korespondencje na temat pracy kierowal tez do mnie albo po prostu komentarze podawal publicznie na forum w tym watku.
Users browsing this topic
Guest


Forum Jump
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

Main Forum RSS : RSS

Powered by Yet Another Forum.net version 1.9.1.6 (NET v2.0) - 11/14/2007
Copyright © 2003-2006 Yet Another Forum.net. All rights reserved.
This page was generated in 0.210 seconds.