Welcome Guest Search | Active Topics | Members | Log In

Referencyjny model składu Options · View
Emil
Posted: Tuesday, November 02, 2010 6:46:37 PM

Rank: Advanced Member

Joined: 10/29/2006
Posts: 50
Points: 147
Location: Warszawa, Polska
Poniżej przedstawiam moje rozmyślania nt. ewentualnej modyfikacji modelu składu w Odrze.

Cele modyfikacji modelu:

1. Wprowadzenie większej uniwersalności i modularności kodu
2. Umożliwienie modelowania obiektów należących jednocześnie do wielu kolekcji.
3. Zamodelowanie ekstensji klasy (również dla obiektów z dziedziczeniem, wielodziedziczeniem, rolami itp.)


W podstawowym modelu referencyjnym RM0 (Reference Model) występują następujące byty:
1. Obiekt nie posiadający wartości atomowej <i>, gdzie

* i jest unikalnym identyfikatorem obiektu


2. Obiekt posiadający wartość atomową będący parą <i, v> gdzie:

* i jest unikalnym identyfikatorem obiektu
* v jest wartością atomową

3. Referencja modelująca powiązania między obiektami <n, i1, i2, c>, gdzie:

* n jest nazwą referencji
* i1 jest identyfikatorem obiektu początkowego
* i2 jest identyfikatorem obiektu docelowego
* c (compose) jest flagą wskazującą, czy dana referencja modeluje mocne wiązanie (kompozycję) pomiędzy dwoma obiektami

Opisany model składu różni się od modelu AS0 tym, że obiekty nie mają przypisanej nazwy, a więc mogą być dostępne w składzie pod wieloma nazwami. W konsekwencji obiekt może być bezpośrednio częścią wielu kolekcji jednocześnie, co nie było możliwe w AS0. Umożliwia to zamodelowanie ekstensji, również z uwzględnieniem dziedziczenia. Np. obiekt klasy Pracownik, dziedziczącej po klasie Osoba należy jednocześnie do dwóch ekstensji.
W opisanym modelu świadomie zrezygnowałem z podziału na obiekty proste i złożone. Dopuszcza się, aby obiekt zawierający wartość atomową prowadził za pomocą referencji do innych obiektów. W ten sposób można zamodelować pewne nieregularności w danych, np. elementy XML będące jednocześnie węzłami i wartościami. Przykładem takiego elementu XML jest:

<pracownik>
Jan Kowalski
<zarobek>2000</zarobek>
</pracownik>

Aby zamodelować podobne dane za pomocą AS0 konieczne okazało się wprowadzenie dodatkowej składni (słowa kluczowego _VALUE), która w zdecydowanej większości przypadków jest lukrem syntaktyczym i zaciemnia użyte zapytania.

Poniżej prezentuję prostą bazę danych w opisanym składzie danych:


Funkcja nested.
Rezultatem nested wywołanej na id obiektu jest lista binderów utworzona na podstawie referencji prowadzących od danego obiektu. Przykładowo, dla obiektu korzeniowego bazy i1, rezultatem nested będą bindery: Emp(i2), Dept(i5). Różnica między AS0 polega na tym, że nie ma potrzeby pobierania obiektów ze składu, a jedynie na wyszukaniu odpowiednich referencji. Co prawda w Loqisie zostało to zoptymalizowane poprzez wprowadzenie namiastek referencji do każdego obiektu złożonego, ale należy pamiętać że wprowadza to redundancję w modelu składu i musi być obsłużone przez takie operacje jak kasowanie czy zmiana nazwy obiektu w składzie.

Operator delete.
W powyższym modelu składu obiekty nie są reprezentowane jako jednolite “bryły”, zasięg obiektu wyznaczany jest przez referencje. Ponieważ semantyka operatora delete polega na skasowaniu całego obiektu, istotne jest rozróżnienie które obiekty podrzędne (wskazane przez referencje) są z nim ściśle związane, a zatem również powinny zostać usunięte. Do tego służy flaga “compose” określona w każdej referencji.
Przykładowo, operacja “delete Emp” będzie przebiegać następująco:
1. Usuń referencję Emp prowadzącą od i1 do i2.
2. Usuń obiekt wskazany przez referencję
3. Usuń wszystkie referencje powiązane z usuniętym obiektem
4. Dla tych obiektów, na które wskazuje silne wiązanie (referencja od usuniętego obiektu z flagą compose=true) wykonaj rekurencyjnie kroki od 2 do 4.

W ten sposób uzyskujemy enkapsulację obiektów podobnie jak w rodzinie modeli AS, dodatkowo rozwiązany został problem “zwisających pointerów”, gdyż w naturalny sposób zostają usunięte referencje prowadzące do usuniętych obiektów. W modelach AS wymagałoby to odnalezienia wszystkich obiektów prowadzących do usuniętego obiektu, co bez specjalnych indeksów jest operacją bardzo kosztowną.

Dwustronne asocjacje.
W celu zamodelowania dwustronnych asocjacji w modelu składu, należy uzupełnić referencję o nazwę zwrotną:
<n, n2, i1, i2, c>, gdzie:

* n jest nazwą referencji
* n jest nazwą zwrotną referencji
* i1 jest identyfikatorem obiektu początkowego
* i2 jest identyfikatorem obiektu docelowego
* c (compose) jest flagą wskazującą, czy dana referencja modeluje mocne wiązanie (kompozycję) pomiędzy dwoma obiektami

Należy przy tym pamiętać że flaga compose odnosi się tylko dla relacji i1->i2, jeśli dopuszczalne jest obustronne mocne wiązanie, należy wprowadzić drugą flagę c2 określającą siłę wiązania i2->i1.
subieta
Posted: Wednesday, November 03, 2010 4:51:47 PM

Rank: Advanced Member

Joined: 12/22/2004
Posts: 675
Points: 704
Location: Legionowo
Może to być ciekawe, ale aby stało się faktem nalezałoby konsekwentnie zbudować semantykę dla wszystkich operatorów języka zapytań. Do tego potrzebny jest system typologiczny, abstrakcje takie jak funkcje, procedury, klasy, metody, perspektywy, jak również metody optymalizacji zapytań. Ten cały inwentarz jest już zbudowany na bazie modeli składu AS0 - AS3, pytanie, czy przy próbie powielenia już istniejących rozwiązań dla tego nowego modelu składu nie trafimy na jakieś zasadnicze trudności. Na razie brakuje mi wyobraźni co do konsekwencji tej zmiany.

Modelowanie złożonych obiektów przy pomocy flagi wydaje się mało eleganckie, ciężko będzie przekonać ludzi, że taki sposób jest właściwy. Ale w końcu istnieją kaskadowe usuwania w modelu relacyjnym także modelowane za pomocą związków klucz główny-obcy oraz jakichś flag, więc żyć się z tym da.

Moim zdaniem, ta dyskusja powinna być na innym wątku, nie wewnątrz projektu SYNAT
habela
Posted: Wednesday, November 03, 2010 7:46:22 PM
Rank: Administration

Joined: 12/6/2004
Posts: 360
Points: 52
Spróbujemy wobec tego wyeksportować ten wątek na zewnątrz, do innego forum. Na razie jeszcze tego nie robię.
Dla kompletu przypomnę dyskusję o niezmiennikach nazwowych z wiosny 2006: http://odraforum.pjwstk.edu.pl/Default.aspx?g=posts&t=111

Załączam też wycinek dokumentu z sekcją, która stanowi próbę opisu UML-owo-OCL-owego modelu danych, wedle założeń, które musieliśmy przyjąć w VIDE, wyrażonego w terminach SBA.

EDIT: korekta znacznego błędu w tekście załącznika.

File Attachment(s):
VIDE_UML_store.doc (64kb) downloaded 12 time(s).


subieta
Posted: Thursday, November 11, 2010 8:58:56 AM

Rank: Advanced Member

Joined: 12/22/2004
Posts: 675
Points: 704
Location: Legionowo
Przesyłam wszystko z Loqisa. Pana będą interesować dwa pliki: VPOS.c oraz VPOS.doc. Niestety ten drugi kiepsko się otwiera w Wordzie (stary), może lepiej będzie w notatniku. Tak czy inaczej, to tylko sugestia, procedury (klasy) dla nowego składu trzeba opracować niezależnie, tym bardziej, ze musi to być wyposażone w transakcje, czego w Loqisie nie było. Jeżeli chodzi o dokumnetację do VPOS, to zabiorę ze sobą wersję papierową, bardziej czytelną.

Refaktoryzacja będzie oznaczać przede wszystkim określenie potrzebnej funkcjonalności i w ramach tego, uporzadkowanie kodu lub jego przepisanie. Rozpoznaniem ma się zająć Michal Drabik, zaimplementowanie rozproszonych transakcji – Wiktor Filipowicz. Dla celów zrobienia systemy rozproszonego trzeba ustalić sposób globalnej identyfikacji rozproszonych obiektów oraz jakieś rejestry ustalające co i gdzie jest przechowywane (na wzór ewentialnie CORBA implementation repository).

File Attachment(s):
loqis.zip (1,099kb) downloaded 13 time(s).


Emil
Posted: Thursday, November 11, 2010 9:25:08 AM

Rank: Advanced Member

Joined: 10/29/2006
Posts: 50
Points: 147
Location: Warszawa, Polska
Dziękuję.
Planowaną refaktoryzację dostępu do fizycznego składu oraz wdrożenie referencyjnego składu danych rozumiem jako dwa niezależne zadania. Do tego drugiego zamierzałem przekonać Profesora i resztę zespołu, ponieważ uważam że mocno pozytywnie wpłynie na funkcjonalność systemu. Oczywiście gdyby mi się nie udało, pomysł zostanie odłożony na potem.
subieta
Posted: Thursday, November 11, 2010 6:54:40 PM

Rank: Advanced Member

Joined: 12/22/2004
Posts: 675
Points: 704
Location: Legionowo
Emil wrote:
Dziękuję.
Planowaną refaktoryzację dostępu do fizycznego składu oraz wdrożenie referencyjnego składu danych rozumiem jako dwa niezależne zadania. Do tego drugiego zamierzałem przekonać Profesora i resztę zespołu, ponieważ uważam że mocno pozytywnie wpłynie na funkcjonalność systemu. Oczywiście gdyby mi się nie udało, pomysł zostanie odłożony na potem.

Prace nad nowym modelem składu może Pan kontynuować, nie jest o w sprzeczności z fizycznym składem, ktory powinien być na tyle uniwersalny, aby nie kolidował z dowolnym modelem. W modelu Loqisa skład składał się z nieinterpretowanych obiektów o rozmiarach od 16 bajtów do 16 MB. Obiekty mogły być zagnieżdżane, liczba poziomów zagnieżdzenia dowolna, liczba obiektów na jednym poziomie zagnieżdzenie rozsądnie ograniczona (chyba gdzieś do jakichś max 500). Teraz oczywiście należałoby zwiększyć maksymalny rozmiar obiektu przynajmnij do kilku gigabajtow, zwiększyć możliwą licbę podobiektów i ewentualnie wprowadzić jakieś bloby o rozmiarach w zasadzie dowolnych. Bloby byłyby pamiętane na oddzielnych plikach. Nad takim składem należy zbudować warstwę przetwarzania transakcji i to razem tworzyłoby fizyczny skład.

Jezeli chodzi o Panski pomysł, jest on nowościa w dziedzinie struktur danych, ale ja takie rzeczy lubię. Dotychczas wszystkie znane systemy programistczne przyjmowały, ze zmienne lub obiekty mogą mieć dokładnie jedną nazwę, natomiast jeżeli programista chciał mieć ich więcej, to wprowadzał jakieś obiekty referencyjne. W jednej z koncepcji dyskutowanej na tym forum wprowadziłem takie obiekty referencyjne w postaci tzw. wizjerów (viewers). Jest też taki papier prezentowany na VLDB. To oczywiście nie ma nic do założenia, że nazwy obiektów będą niezmiennikami klas, z tego możemy spokojnie zrezygnować, licząc się jednak z tym, że klasy mogą utracić część semantyki. Ale wystarczy te nazwy wyspecyfikować w deklaracjach obiektów i wyjdzie praktycznie na to samo. Nieco poważniejszym problemem jest to, że w ODRA pointery są typowane nie przez typ obiektu, do którego prowadza, ale przez jego nazwę. Jezeli zrezygnujemy z umieszczania nazwy jako niezmiennika obiektu wewnątz klasy (lub typu) to automatycznie należałoby wrócić do koncepcji, ze pointery są typowane typem/klasą/interfejsem obiektu, do którego prowadzą.
habela
Posted: Thursday, December 09, 2010 10:55:15 PM
Rank: Administration

Joined: 12/6/2004
Posts: 360
Points: 52
Pomimo, że nie jestem w stanie całościowo odnieść się do tej propozycji modelu składu, chciałbym reaktywować dyskusję, bo niezależnie od pilności bądź nie-pilności rozstrzygnięć, temat jest ciekawy.
Na wstępie pytanie w kwestii technicznej - czy wyciągamy wątek na bardziej (a jeśli tak - to w jakim stopniu) publiczne forum naszego forum board?

A w kwestiach merytorycznych. Myślę, że propozycja jest bardzo ciekawa, ale też dobrze wyczuwam potencjalny opór odbiorców - bo sam go odczuwam wobec kilku istotnych szczegółów.
Sądzę mianowicie, że bardzo dużo zależy od sposobu "sprzedania" tego składu w sensie oferowanych dlań operacji aktualizacyjnych języka oraz w sensie pojęć modelowania, za pomocą których taką strukturę będziemy objaśniać.

Rzeczą, której w kształtowaniu koncepcji tego składu mocno bym bronił jest pełna przejrzystość/intuicyjność relacji kompozycji.
Tutaj mam pytanie - czy dopuszczamy, aby jeden obiekt był celem więcej niż jednego powiązania mającego flagę composite=true ?
Gdybyśmy kierowali się tutaj punktem widzenia trygerów on delete znanych z SQL - to pewnie byśmy to chcieli dopuścić (tzn. że np. krotka "rola" będzie automatycznie usuwana zarówno przy usunięciu stosownej krotki "aktor", jak i stosownej krotki "film").
Z kolei - stosując filozofię kompozycji znanej z UML-a (ale też - naturalne rozumienie relacji fizycznego zawierania się) - raczej odpowiedzielibyśmy: nie.
Podobna kwestia - czy dopuszczamy, aby asocjacja dwukierunkowa miała oba końce oznaczone flagą composite?

Kolejne pytanie jest takie, czy bylibyśmy w stanie odwzorować dobrodziejstwa tego modelu składu na pojęcia diagramu klas UML (jeśli tak - znacznie łatwiej byłoby objaśnić użytkownikom, o co nam chodzi).
UML jest tu dość bogaty (wręcz redundantny) - więc należałoby pomyśleć, które jego pojęcia najlepiej tu pasują. Mamy do dyspozycji atrybuty klas (mogą mieć flagi kompozycji, agregacji, albo być zwykłe; potencjalnie mogą dotyczyć obiektów złożonych; dla obiektów złożonych mamy asocjacje - one też mogą mieć końce zwykłe, agregacje oraz kompozycje; dodatkowo, możemy utożsamiać końce asocjacji z atrybutami, albo traktować je jako odrębnie zachowujące się pojęcia.)
Podkreślam, nie pytam o to dlatego, żeby skutkiem jakiegoś nawyku z VIDE wymuszać tutaj zgodność z UML. Chodzi mi raczej o wykorzystanie szans na możliwie jak najmniej egzotyczny sposób udostępnienia możliwości tego modelu składu programiście.

Wreszcie - zaciekawiła mnie ta wzmianka o możliwości zgrabnego przykrycia przez ten model obiektów o zawartości mieszanej (w takim sensie, jak elementy o zawartości mieszanej w XML: obiekt mający równocześnie zawartość tekstową jak i podobiekty). Jak by to wyglądało w tym modelu i jak wyobrażamy sobie obsłużenie tego przez konstrukcje języka?
Emil
Posted: Friday, December 10, 2010 7:44:18 PM

Rank: Advanced Member

Joined: 10/29/2006
Posts: 50
Points: 147
Location: Warszawa, Polska
Dziękuję za wznowienie tematu

habela wrote:
Pomimo, że nie jestem w stanie całościowo odnieść się do tej propozycji modelu składu, chciałbym reaktywować dyskusję, bo niezależnie od pilności bądź nie-pilności rozstrzygnięć, temat jest ciekawy.
Na wstępie pytanie w kwestii technicznej - czy wyciągamy wątek na bardziej (a jeśli tak - to w jakim stopniu) publiczne forum naszego forum board?

Jestem jak najbardziej za.

habela wrote:
A w kwestiach merytorycznych. Myślę, że propozycja jest bardzo ciekawa, ale też dobrze wyczuwam potencjalny opór odbiorców - bo sam go odczuwam wobec kilku istotnych szczegółów.
Sądzę mianowicie, że bardzo dużo zależy od sposobu "sprzedania" tego składu w sensie oferowanych dlań operacji aktualizacyjnych języka oraz w sensie pojęć modelowania, za pomocą których taką strukturę będziemy objaśniać.

Zaproponowany model jest prostszy i moim zdaniem bardziej elastyczny od dotychczasowych rozwiązań, co korzystnie wpływa na moc języka programowania na którym ma zostać zbudowany.
Zasadniczymi nowością jest relatywizm nazw obiektów (każdy obiekt może być bezpośrednio dostępny pod wieloma nazwami). Dzięki temu możliwe jest umieszczenie obiektu jednocześnie w wielu kolekcjach (o różnych nazwach), co zwiększa elastyczność programowania.

habela wrote:
Rzeczą, której w kształtowaniu koncepcji tego składu mocno bym bronił jest pełna przejrzystość/intuicyjność relacji kompozycji.
Tutaj mam pytanie - czy dopuszczamy, aby jeden obiekt był celem więcej niż jednego powiązania mającego flagę composite=true ?
Gdybyśmy kierowali się tutaj punktem widzenia trygerów on delete znanych z SQL - to pewnie byśmy to chcieli dopuścić (tzn. że np. krotka "rola" będzie automatycznie usuwana zarówno przy usunięciu stosownej krotki "aktor", jak i stosownej krotki "film").
Z kolei - stosując filozofię kompozycji znanej z UML-a (ale też - naturalne rozumienie relacji fizycznego zawierania się) - raczej odpowiedzielibyśmy: nie.

W tym miejscu, kierując się moim inżynierskim wyczuciem dałbym, programiście swobodę w budowaniu tego typu modeli. Przykrywa to pojęcie kompozycji z uml i dodatkowo daje większe możliwości modelowania. Czy dobrze rozumiem, że podanego przykładu nie można zamodelować UML, a więc wymaga to "nieformalnych" komentarzy na diagramie?

habela wrote:
Podobna kwestia - czy dopuszczamy, aby asocjacja dwukierunkowa miała oba końce oznaczone flagą composite?

Tutaj również dałbym programiście swobodę. Oczywiście zawsze istnieje ryzyko że nadużywając kompozycji doprowadzi on do tak mocnego powiązania danych, że usunięcie pojedynczego obiektu spowoduje wyczyszczenie całej bazy, ale nie sądzę że powinniśmy się tym przejmować.

habela wrote:
Kolejne pytanie jest takie, czy bylibyśmy w stanie odwzorować dobrodziejstwa tego modelu składu na pojęcia diagramu klas UML (jeśli tak - znacznie łatwiej byłoby objaśnić użytkownikom, o co nam chodzi).
UML jest tu dość bogaty (wręcz redundantny) - więc należałoby pomyśleć, które jego pojęcia najlepiej tu pasują. Mamy do dyspozycji atrybuty klas (mogą mieć flagi kompozycji, agregacji, albo być zwykłe; potencjalnie mogą dotyczyć obiektów złożonych; dla obiektów złożonych mamy asocjacje - one też mogą mieć końce zwykłe, agregacje oraz kompozycje; dodatkowo, możemy utożsamiać końce asocjacji z atrybutami, albo traktować je jako odrębnie zachowujące się pojęcia.)
Podkreślam, nie pytam o to dlatego, żeby skutkiem jakiegoś nawyku z VIDE wymuszać tutaj zgodność z UML. Chodzi mi raczej o wykorzystanie szans na możliwie jak najmniej egzotyczny sposób udostępnienia możliwości tego modelu składu programiście.

Trudne pytanie, wydaje mi się że model składu jest na nieco innym poziomie abstrakcji niż UML. Model składu postrzegam jako bardziej "niskopoziomowy", na bazie którego tworzymy bardziej koncepcyjne pojęcia obecne w UML, jak asocjacje (jedno i dwukierunkowe), asocjacje z atrybutami, itp. Z kolei nie wszystkie pojęcia użyte w modelu składu przekładają się na UML (jak wspomniana kompozycja). Oczywiście warto spróbować, walor dydaktyczny przy wprowadzaniu nowego modelu składu na pewno jest istotny.

habela wrote:
Wreszcie - zaciekawiła mnie ta wzmianka o możliwości zgrabnego przykrycia przez ten model obiektów o zawartości mieszanej (w takim sensie, jak elementy o zawartości mieszanej w XML: obiekt mający równocześnie zawartość tekstową jak i podobiekty). Jak by to wyglądało w tym modelu i jak wyobrażamy sobie obsłużenie tego przez konstrukcje języka?

Jest propozycja aby usunąć podział na obiekty złożone i atomy, tj obiekt może zawierać wartość atomową i jednocześnie mieć powiązania do innych obiektów, tak jak taki specyficzny element w XML. Do języka można wprowadzić to w taki sposób, że zakładamy że każdy obiekt atomowy musi mieć przypisaną klasę (Integer, String, Boolean itp), oraz że można dziedziczyć po tych klasach, w podklasach dodając asocjacje do innych obiektów. W Javie dziedziczenie po takich klasach jest zabronione, ale czemu by na to nie pozwolić? Obiekt takiej klasy mógłby być "konsumowany" przez odpowiednie operatory działające na typach prostych, np +, -, *, /, and, or itp. Traktowanie typów prostych jako normalne obiekty ma też tę zaletę, że w tych klasach możemy umieścić pewne użyteczne funkcje jak trim(), charAt(), substring(), indexOf(), toLower(Upper)Case() itp nie zmieniając składni języka.
habela
Posted: Friday, December 10, 2010 8:19:46 PM
Rank: Administration

Joined: 12/6/2004
Posts: 360
Points: 52
Przerzuciłem wątek na forum ogólne.
stencel
Posted: Saturday, December 11, 2010 10:12:10 AM

Rank: Advanced Member

Joined: 12/7/2004
Posts: 598
Points: 74
Location: Raszyn
habela wrote:
Przerzuciłem wątek na forum ogólne.


Dopiero teraz dostałem powiadomienie. A tu widzę ciekawa dyskusja (i wiele innych też się przetoczyło). Prośba moja gorąca o powiadomienia. Jak ich nie dostaję, to często zapominam, że forum istnieje!

Jeśli chodzi o model, to ma sporo zalet:

* jest spójny,
* jest bliższy Javie,
* jest bliższy XML (choć nie do końca modeluje mixed content czyli tekst przemieszany totalnie ze znacznikami; pytanie, czy chcemy też to modelować).

Wadą jest chyba tylko to, że jest w pewnym oddaleniu od AS* i nie mamy pewności, jaka część zbiornicy wiedzy SBA do niego pasuje.

Z drugiej strony pytanie, czy uda nam się spopularyzować coś co nie jest Java/XML samo w sobie. Jakoś to środowisko bazodanowe jest bardzo inercyjne od dłuższego czasu. Nie interesują ich nowe rzeczy. Jak w Rejsie: jak mogą lubić modele, ktorych nie znają. Probować jednak warto.


Jesli chodzi o UML, to może jestem nie na czasie, ale kiedyś w UML była słaba kompozycja reprezentowana pustym diamencikiem, która mogłaby odpowiadać proponowanej fladze composite=true. Czy może już czegoś takiego nie ma?
radamus
Posted: Tuesday, December 14, 2010 9:26:34 AM

Rank: Advanced Member

Joined: 1/25/2005
Posts: 325
Points: 108
Location: Łódź
Wg mnie:
Główną motywacją modelu jest umożliwienie istnienia obiektu w więcej niż jednej kolekcji. Odbywa się to poprzez nie wprowadzanie nazw obiektów a zamiast tego wprowadzenie powiązań referencyjnych, które same obiektami nie są
a słuzą wiązaniu obiektów ze sobą. Wiązanie może odpowiadać powiązaniu asocjacyjnemu lub kompozycyjnemu (co ma wpływ m.in. na semantykę usuwania).



Moje pytania/wątpliwości budzi:
1. Kolekcje w modelu AS0 reprezentowane były poprzez obiekty o tej samej nazwie znajdujące się na tym samym poziomie składu. Rozumiem, że w tym modelu kolekcją jest grupa referencji o tej samej nazwie w tym samym obiekcie?
2. Jak się ma semantyka referencji do ich aktualizacji? Jeżeli rezultatem nested na obiekcie jest lista binderów, których wartością są identyfikatory obiektów wskazywanych przez referencje zawartych
w obiekcie-parametrze funkcji nested, to nie mamy możliwości aktualizacji. Rozumiem, że w przypadku ustawionej flagi c=true jest to dobre rozwiązanie, natomiast "w jaki sposób można zmienić dział, w którym pracuje pracownik?" ( referencje nie są obiektami - nie posiadają identyfikatora)?

3. Dopuszczenie posiadania wartości atomowej w obiekcie, który tak na prawdę opisuje byt złożony moim zdaniem jest rozwiązaniem, ktore w niektórych przypadkach może się faktycznie przydać (wspomniany XML), ale jest dziwaczne. Należałoby przyjąć, że nadmierne
stosowanie można ukrócić poprzez system typów. Aczkolwiek dla mnie, pierwotnie zabrzmiało to jakbyśmy chcieli mieć model w którym "wszystko jest wartościa atomową". Dopiero potem doczytałem, że to jest opcja. Tylko ta opcja będzie musiała być obsłużona w języku zapytań. (Jak każda opcja może się zmultiplikować rozprzestrzenić w meandrach implementacji). Pytaniem (trochę filozoficznym) jest też co jest opcją: czy dopuszczenie, że obiekt posiadający wartość atomową (czyli atomowy) posiada również referencje wyrażające "kompozycję". Czy może dopuszczenie istnienia obiektu "złożonego" posiadającego wartość atomową?

4. Co do wydajności modelu to nie wiem czy samo pojęcie "wydajności" jest adekwatne. Ja rozumiem, że w tym modelu operacja usuwania obiektu jest bardziej elegancka i prostsza w implementacji, ale wydajność wolałbym rozważać na poziomie konkretnej implementacji.
Czy aby na poziomie modelu nie zależy nam bardziej na jego sile wyrazu. A jeżeli ta siła wyrazu będzie zmniejszona jako cena za zwiększenie wydajności operacji usuwania czy jakiejkolwiek innej?

Podsumowując:
Model, w którym referencje wyznaczają nazwy obiektów jest modelem zbliżonym do tego, który mamy w językach programowania np. Javie.
Każda taka inicjatywa polepsza na pewno nasze możliwości zaistnienia na tej płaszczyźnie (skoro środowisko baz danych jest twardogłowe).
Uważam, że jest to ciekawy pomysł badawczy i warto byłoby go zaimplementować w celu ustalenia jego cech szczególych oraz możliwości
odwzorowywania bardziej złożonych modeli (role, etc.). Jeżeli obiekt nie ma nazwy to nie wiem jak to na przykład będzie wyglądało w przypadku ról. natomiast czy może to być model "referencyjny" to nie wiem.

Trzeba też pamiętać, że Emil jest przesiąknięty implementacją SBQL4J co jest w kontekście tego tematu i zaletą (doświadczenie) i wadą (subtelna stronniczość?) :).

Przy okazji:
W Odrze został kiedyś wprowadzony typ referencji nie posiadającej tożsamości, jednak był on uzupełnienim modelu AS0 wprowadzającym poziom specjalnych referencji (tak z resztą został pierwotnie nazwany). Pomyślany był jako uniwersalny mechanizm rozszerzania AS0 na kolejne poziomy.

Typy specjalnych referencji byly rozróżnianie poprzez ich nazwę. Taką referencję można bylo dodać do obiektu i usunąć. Nie można jej było aktualizować. W implementacji Odry istnieją specjalne referencje
- instanceof
(wykorzystywana dla powiązania instanceof: obiekt reprezentujący instancję ->obiekt reprezentujący klasę, oraz dziedzczenia statycznego obiekt reprezentujący klasę->obiekt reprezentujący klasę)
- reverse_ref
(wykorzystywana dla implementacji asocjacji dwukierunkowych)
- idxupd_trig
(wykorzystywana dla implementacji automatycznej aktualizacji indeksów)

roleof
(pozostało w planach)

Ale to jest inna bajka, ponieważ specjalne refrencje te były "niewidoczne" dla semantyki języka zapytań (funkcja nested nie operowałach na tych elementach). Były tylko mechanizmem implementacyjnym, niespójnym (każdy typ zachowywał się inaczej).
Ostatnio myśleliśmy z Tomkiem Kowalskim nad uogólnieniem tego mechanizmu i nad tym czy nie rozszerzyć go na semantykę jezyka.
subieta
Posted: Tuesday, December 14, 2010 10:08:30 AM

Rank: Advanced Member

Joined: 12/22/2004
Posts: 675
Points: 704
Location: Legionowo
stencel wrote:
[Z drugiej strony pytanie, czy uda nam się spopularyzować coś co nie jest Java/XML samo w sobie. Jakoś to środowisko bazodanowe jest bardzo inercyjne od dłuższego czasu. Nie interesują ich nowe rzeczy. Jak w Rejsie: jak mogą lubić modele, ktorych nie znają. Probować jednak warto.

Nie jestem optymistą w zakresie popularyzacji modelu dla środowiska Java. Obawiam się, że w tym zakresiem jest ono tak samo inercyjne jak środowisko bazo-danowe. Nie jestem także przekonany co do koncepcyjnej wartości tego modelu. Przy konstrukcji dowolnego modelu struktur danych trzeba przede wszystkim mieć na uwadze niekoniecznie jego możliwości techniczne, ale przede wszystkim mozliwości w zakresie modelowania pojeciowego rzeczywuistych problemów. Na dzisiaj takim standardem w zakresie modelowania pojeciowego jest UML. Zatem powstaje pytanie, jakie skutki dla UML (diagramu klas) będzie miało wprowadzenie takiego modelu struktur danych. Jezeli te skutki będą żadne lub skutki będą miały marginalne znaczenie dla ekpresyjności modelu UML w zakresie wyrażania pewnych istotnych cech koncepcyjnych to nalezy zastanowić się czy warto.
subieta
Posted: Tuesday, December 14, 2010 11:47:44 AM

Rank: Advanced Member

Joined: 12/22/2004
Posts: 675
Points: 704
Location: Legionowo
stencel wrote:
choć nie do końca modeluje mixed content czyli tekst przemieszany totalnie ze znacznikami; pytanie, czy chcemy też to modelować).

Problem jst bardziej złożony i moim zdaniem proponowany model (ani żaden z modeli AS0-AS3) go nie załatwia. W pliku XML, jezeli chcemy wstawić tagowany obiekt do srodka stringu (tekstu) nie jest obojętne gdzie go wstawiamy. Powiedzmy że tekst dotyczy występów artystycznych i string ma postać:
Quote:
"W dniu <data>2010.12.14</data> w Klubie Garnizonowym w Myszach Wielkich wystąpiła sławna <artystka>Doda</artystka> śpiewając swój światowy przebój <utwór>Ale było fajowo</utwór> w aranzacji miejscowej orkiestry straży pożarnej".

Mamy to do czynienia z wtrętami strukturalnym o dowolnym stopniu skomplikowania wewnątrz normalnego tekstu. Nasza rekurencyjna moda każe nam rozważać równie sytuację, kiedy te wtręty będą również miały teksty, ewentualnie również z wtrętami. I tak dowolnie zagnieżdząjąc bez zadnych oporów. Nie jest obojetne, gdzie te wtręty się znajdują, ponieważ ich miejsce jest ustalone semantyką języka naturalnego. Można oczywiście te wtręty zastąpić referencjami do obiektów gdzieś na boku, co oznaczałoby, że nasze stringi/teksty zostałyby dodatkowo wyposazone w specjalny alfabet umożliwiający wstawianie takich referencji. Model formalny czegoś takiego nie jest specjalnie skomplikowany, poradzimy sobie, natomiast prawdziwym wyzwaniem jest język zapytań uwzględniający takie teksty ze strukturalnymi wtrętami. Podstawowe pytanie polega na tym o co chcemy pytać - czy o podstring, czy o obecność strukturalnego wtrętu, czy o jego wartość, czy o ich kolejność. Może to zostało jakoś rozwiązane w XSD (schemat czegoś takiego) oraz w XQuery (po co i jak to odpytywać), ale wyobrażam sobie, że ogólne rozwiązanie wcale nie musi być łatwe i wymaga dość wyspecjalizowanych operatorów w języku zapytań. Czy taki problem jest na tyle istotny, aby z niego robić wielkie halo?
Emil
Posted: Tuesday, December 14, 2010 12:38:52 PM

Rank: Advanced Member

Joined: 10/29/2006
Posts: 50
Points: 147
Location: Warszawa, Polska
radamus wrote:
Wg mnie:
Główną motywacją modelu jest umożliwienie istnienia obiektu w więcej niż jednej kolekcji. Odbywa się to poprzez nie wprowadzanie nazw obiektów a zamiast tego wprowadzenie powiązań referencyjnych, które same obiektami nie są
a słuzą wiązaniu obiektów ze sobą. Wiązanie może odpowiadać powiązaniu asocjacyjnemu lub kompozycyjnemu (co ma wpływ m.in. na semantykę usuwania).

Moje pytania/wątpliwości budzi:
1. Kolekcje w modelu AS0 reprezentowane były poprzez obiekty o tej samej nazwie znajdujące się na tym samym poziomie składu. Rozumiem, że w tym modelu kolekcją jest grupa referencji o tej samej nazwie w tym samym obiekcie?

Dokładnie tak.
radamus wrote:
2. Jak się ma semantyka referencji do ich aktualizacji? Jeżeli rezultatem nested na obiekcie jest lista binderów, których wartością są identyfikatory obiektów wskazywanych przez referencje zawartych
w obiekcie-parametrze funkcji nested, to nie mamy możliwości aktualizacji. Rozumiem, że w przypadku ustawionej flagi c=true jest to dobre rozwiązanie, natomiast "w jaki sposób można zmienić dział, w którym pracuje pracownik?" ( referencje nie są obiektami - nie posiadają identyfikatora)?

Faktycznie, dla aktualizacji jest niewystarczające aby nested zwracało "proste" bindery n(i), powinno raczej zwracać bindery tożsame z referencją, aby można było je aktualizować.

radamus wrote:
3. Dopuszczenie posiadania wartości atomowej w obiekcie, który tak na prawdę opisuje byt złożony moim zdaniem jest rozwiązaniem, ktore w niektórych przypadkach może się faktycznie przydać (wspomniany XML), ale jest dziwaczne. Należałoby przyjąć, że nadmierne
stosowanie można ukrócić poprzez system typów. Aczkolwiek dla mnie, pierwotnie zabrzmiało to jakbyśmy chcieli mieć model w którym "wszystko jest wartościa atomową". Dopiero potem doczytałem, że to jest opcja. Tylko ta opcja będzie musiała być obsłużona w języku zapytań. (Jak każda opcja może się zmultiplikować rozprzestrzenić w meandrach implementacji). Pytaniem (trochę filozoficznym) jest też co jest opcją: czy dopuszczenie, że obiekt posiadający wartość atomową (czyli atomowy) posiada również referencje wyrażające "kompozycję". Czy może dopuszczenie istnienia obiektu "złożonego" posiadającego wartość atomową?

Nie bardzo rozumiem na czym miałby polegać problem "meandryczny". Ja to widzę łopatologicznie - pewne operatory języka konsumują wartości atomowe (odpowiedniego typu) a nie przyjmują obiektów złożonych. Teraz będą mogły wykorzystać również obiekty "mixed", co specjalnie wiele nie zmienia. Podobnie z operatorami niealgebraicznymi, będą działać tak jak do tej pory (bo "mixed" są odmianą obiektów złożonych).

radamus wrote:
4. Co do wydajności modelu to nie wiem czy samo pojęcie "wydajności" jest adekwatne. Ja rozumiem, że w tym modelu operacja usuwania obiektu jest bardziej elegancka i prostsza w implementacji, ale wydajność wolałbym rozważać na poziomie konkretnej implementacji.
Czy aby na poziomie modelu nie zależy nam bardziej na jego sile wyrazu. A jeżeli ta siła wyrazu będzie zmniejszona jako cena za zwiększenie wydajności operacji usuwania czy jakiejkolwiek innej?


Na mój gust siłą wyrazu modelu referencyjnego nie jest mniejsza, ale większa od AS0 - przykrywa wszystko co było w AS0 zwalniając niepotrzebne ograniczenia dotyczące nazw obiektów.


radamus wrote:
Podsumowując:
Model, w którym referencje wyznaczają nazwy obiektów jest modelem zbliżonym do tego, który mamy w językach programowania np. Javie.
Każda taka inicjatywa polepsza na pewno nasze możliwości zaistnienia na tej płaszczyźnie (skoro środowisko baz danych jest twardogłowe).
Uważam, że jest to ciekawy pomysł badawczy i warto byłoby go zaimplementować w celu ustalenia jego cech szczególych oraz możliwości
odwzorowywania bardziej złożonych modeli (role, etc.). Jeżeli obiekt nie ma nazwy to nie wiem jak to na przykład będzie wyglądało w przypadku ról. natomiast czy może to być model "referencyjny" to nie wiem.
Trzeba też pamiętać, że Emil jest przesiąknięty implementacją SBQL4J co jest w kontekście tego tematu i zaletą (doświadczenie) i wadą (subtelna stronniczość?) :).

Nigdy nie ukrywałem, że doświadczeniem jestem bliżej języków programowania, niż baz danych :) Co, jak myślę, nie przeszkadza w pracy z SBA, którego głównym założeniem jest to, że języki zapytań są odmianą języków programowania.

subieta wrote:
Nie jestem optymistą w zakresie popularyzacji modelu dla środowiska Java. Obawiam się, że w tym zakresiem jest ono tak samo inercyjne jak środowisko bazo-danowe. Nie jestem także przekonany co do koncepcyjnej wartości tego modelu. Przy konstrukcji dowolnego modelu struktur danych trzeba przede wszystkim mieć na uwadze niekoniecznie jego możliwości techniczne, ale przede wszystkim mozliwości w zakresie modelowania pojeciowego rzeczywuistych problemów.

Moim zdaniem zaproponowane rozwiązanie umożliwia lepsze rozwiązanie rzeczywistych problemów. Przykład - programista ma napisać funkcję wypisującą nazwy departamentów, dla danego pracownika (parametr funkcji). Haczyk polega na tym, że departamenty są w bazie w kilku kolekcjach (deptWarszawa, deptLodz, deptWroclaw, itp.), których liczba może ulec zmianie. W AS0 nie da się tego zamodelować (bo obiekt referencyjny jest typowany pojedynczą nazwą obiektu docelowego). Nawet gdyby się dało, wyglądałoby to tak:
Code:
nazwyDept(emp:Employee):string[0..*] {
    return emp.worksIn.deptWarszawa.name union emp.worksIn.deptLodz.name union emp.worksIn.deptWroclaw.name;
    //trzeba cos dopisac gdy pojawi sie nowa kolekcja departamentow)
}

Oczywiście powyższą funkcję można skompilować tylko wtedy gdy są już konkretne dane w bazie, mimo że jest ona bardziej ogólna - wystarczy informacja o typach, potrzebne dane są dostarczone w postaci parametru.

W modelu referencyjnym nazwy są na nieco wyższym poziomie abstrakcji (związane raczej z typami a nie danymi), co umożliwia pisanie bardziej ogólnych algorytmów:
Code:
nazwyDept(emp:Employee):string[0..*] {
    return emp.worksIn.name;
}

Nie ma tu żadnych elips.
Emil
Posted: Tuesday, December 14, 2010 3:21:40 PM

Rank: Advanced Member

Joined: 10/29/2006
Posts: 50
Points: 147
Location: Warszawa, Polska
subieta wrote:
stencel wrote:
choć nie do końca modeluje mixed content czyli tekst przemieszany totalnie ze znacznikami; pytanie, czy chcemy też to modelować).

Problem jst bardziej złożony i moim zdaniem proponowany model (ani żaden z modeli AS0-AS3) go nie załatwia. W pliku XML, jezeli chcemy wstawić tagowany obiekt do srodka stringu (tekstu) nie jest obojętne gdzie go wstawiamy. Powiedzmy że tekst dotyczy występów artystycznych i string ma postać:
Quote:
"W dniu <data>2010.12.14</data> w Klubie Garnizonowym w Myszach Wielkich wystąpiła sławna <artystka>Doda</artystka> śpiewając swój światowy przebój <utwór>Ale było fajowo</utwór> w aranzacji miejscowej orkiestry straży pożarnej".

Mamy to do czynienia z wtrętami strukturalnym o dowolnym stopniu skomplikowania wewnątrz normalnego tekstu. Nasza rekurencyjna moda każe nam rozważać równie sytuację, kiedy te wtręty będą również miały teksty, ewentualnie również z wtrętami. I tak dowolnie zagnieżdząjąc bez zadnych oporów. Nie jest obojetne, gdzie te wtręty się znajdują, ponieważ ich miejsce jest ustalone semantyką języka naturalnego. Można oczywiście te wtręty zastąpić referencjami do obiektów gdzieś na boku, co oznaczałoby, że nasze stringi/teksty zostałyby dodatkowo wyposazone w specjalny alfabet umożliwiający wstawianie takich referencji. Model formalny czegoś takiego nie jest specjalnie skomplikowany, poradzimy sobie, natomiast prawdziwym wyzwaniem jest język zapytań uwzględniający takie teksty ze strukturalnymi wtrętami. Podstawowe pytanie polega na tym o co chcemy pytać - czy o podstring, czy o obecność strukturalnego wtrętu, czy o jego wartość, czy o ich kolejność. Może to zostało jakoś rozwiązane w XSD (schemat czegoś takiego) oraz w XQuery (po co i jak to odpytywać), ale wyobrażam sobie, że ogólne rozwiązanie wcale nie musi być łatwe i wymaga dość wyspecjalizowanych operatorów w języku zapytań. Czy taki problem jest na tyle istotny, aby z niego robić wielkie halo?

Jeśli już chcemy zajmować się takim przypadkiem, możemy to zrobić bez specjalnej ingerencji w składnię i semantykę języka. Np. można stworzyć specjalną klasę (w bibliotece systemowej) o nazwie, dajmy na to, MixedString.

Code:

class MixedString : String {
    sequence subObjects:Object;
   
    //konstruktor obiektu
    // text jest ciągiem znaków ze znacznikami (np {data} itp)
    MixedString(text:String, subObj:Object[0..*]) {
        super(text);
        //wstawiamy obiekty subObj do sekwencji subObjects
    }

    toString():string {
    //metoda zwraca napis z zamienionymi znacznikami na wartosci podobiektow - konkatenacja stringow, mozemy zalozyc ze kazdy obiekt ma metode toString
    }
}

class SwiatoweWydarzenieKulturowoArtystyczne : MixedString {
data:Date;
artystka:String;
utwór:String;

//konstruktor - może by je wprowadzic do odry?...
public SwiatoweWydarzenieKulturowoArtystyczne(text:String; data:Date; artystka:String; utwór:String) {
    super(text; sequence(data, artystka, utwór));
    //przypisanie parametrow na podobiekty
    self.data = data;
    self.artystka= artystka;
    self.utwór= utwór;
}
}

Tworzymy nasz obiekt:
Code:
s1:MixedString := new MixedString("W dniu {data} w Klubie Garnizonowym w Myszach Wielkich wystąpiła sławna {artystka} śpiewając swój światowy przebój {utwór} w aranzacji miejscowej orkiestry straży pożarnej"; new Date("2010.12.14"); "Doda", "Ale było fajowo");

Nastepnie korzystamy z niego jak z normalnego obiektu zlozonego:
Code:
print(s1); // zostanie wypisane: 'W dniu 2010.12.14 w Klubie Garnizonowym w Myszach Wielkich wystąpiła sławna Doda śpiewając swój światowy przebój Ale było fajowo w aranzacji miejscowej orkiestry straży pożarnej'
d1:Date := s1.data;
//zapytanie sprawdzajace czy w calym napisie (z wartosciami podobiektow) wystepuje napis "Doda", metoda indexOf jest zaimplementowana w klasie String, zwraca indeks wystąpienia danego pod-napisu
b1:Boolean := s1.indexOf("Doda");


Oczywiście w AS0 chyba czegoś takiego za bardzo nie da się zrobić, choćby dlatego że obiekty będą występować pod dwoma nazwami jako subObjects w klasie MixedString i np. jako artystka w klasie SwiatoweWydarzenieKulturowoArtystyczne.

subieta
Posted: Tuesday, December 14, 2010 4:46:41 PM

Rank: Advanced Member

Joined: 12/22/2004
Posts: 675
Points: 704
Location: Legionowo
Trzeba by najpierw odpowiedzieć na pytanie po co wprowadzać strukturalizowane zapisy do wnętrza stringów lub tekstów. Moim zdaniem, powody są dwa:

1. Kontrola typologiczna i słownikowa: takie strukturalizowane zapisy są sprawdzanie pod wzlędem typologicznym i/lub słownikowym; dają możliwość wykrycia lub uniknięcia błędu w zapisie pewnych informacji. Np. wartość tagu <data> jest zdefiniowany gdzieś indziej jako typ date. Analogicznie mogą być definiowane tagi dla integer, real, itd. Podobnie <artystka> jest tagiem informującym o odwołaniu się do słownika, ktory normalizuje pewne informacje nie dopuszczając do błędów.

2. Skrócenie zapisu: w takim przypadku tagi razem z zawartością działają jak makra ułatwiając ręczne przygotowanie tekstu.

Przyjmując takie założenia wyszukiwanie w ogóle nie jest najważniejsze. Istotne jest specjalne oprogramowanie, ktore potrafiłoby zredagować ostateczny tekst z użyciem zdefiniowanych operacji na tagowanych wartościach. Ponieważ redagowanie może być dokonywane na wiele sposobów, możliwe jest stworzenie wielu programów redakcyjnych.
Obydwa te założenia w ogóle nie pasuję do naszych modeli składu. Tagowanych obiektów strukturalnych wewnątrz stringów lub tekstu można używać dowolnie lub w dowolnej kolejności. Nie pasują również do załozeń systemów mocnej kontroli typologicznej w językach programowania, włączając SBQL - jest to zupełnie inny system, którego celem jest dynamiczna kontrola tekstu. Jest to być moze ciekawy problem, ale mioim zdaniem, nie mający zbyt wiele wspólnego z dotychczas rozważanymi modelami składu.
Jezeli ktoś chciałby się tym zająć, to nie mam nic przeciwko, jakkolwiek tak postawiowny problem nie wydaje się zbyt głęboki od strony badawczej, w sam raz na pracę magisterską. Oczywiście zaimplementować to można nawet w modelu AS0.
Emil
Posted: Tuesday, December 14, 2010 5:41:14 PM

Rank: Advanced Member

Joined: 10/29/2006
Posts: 50
Points: 147
Location: Warszawa, Polska
subieta wrote:
Trzeba by najpierw odpowiedzieć na pytanie po co wprowadzać strukturalizowane zapisy do wnętrza stringów lub tekstów. Moim zdaniem, powody są dwa:

1. Kontrola typologiczna i słownikowa: takie strukturalizowane zapisy są sprawdzanie pod wzlędem typologicznym i/lub słownikowym; dają możliwość wykrycia lub uniknięcia błędu w zapisie pewnych informacji. Np. wartość tagu <data> jest zdefiniowany gdzieś indziej jako typ date. Analogicznie mogą być definiowane tagi dla integer, real, itd. Podobnie <artystka> jest tagiem informującym o odwołaniu się do słownika, ktory normalizuje pewne informacje nie dopuszczając do błędów.

2. Skrócenie zapisu: w takim przypadku tagi razem z zawartością działają jak makra ułatwiając ręczne przygotowanie tekstu.

Przyjmując takie założenia wyszukiwanie w ogóle nie jest najważniejsze. Istotne jest specjalne oprogramowanie, ktore potrafiłoby zredagować ostateczny tekst z użyciem zdefiniowanych operacji na tagowanych wartościach. Ponieważ redagowanie może być dokonywane na wiele sposobów, możliwe jest stworzenie wielu programów redakcyjnych.
Obydwa te założenia w ogóle nie pasuję do naszych modeli składu. Tagowanych obiektów strukturalnych wewnątrz stringów lub tekstu można używać dowolnie lub w dowolnej kolejności. Nie pasują również do załozeń systemów mocnej kontroli typologicznej w językach programowania, włączając SBQL - jest to zupełnie inny system, którego celem jest dynamiczna kontrola tekstu.

Jeżeli zakładamy, że dopuszczalnym rozwiązaniem byłoby utworzenie osobnych klas dla każdego elementu "mixed", to jest to problem banalny - rozwiązanie mogłoby być zbliżone do powyższego.

subieta wrote:
tak postawiowny problem nie wydaje się zbyt głęboki od strony badawczej, w sam raz na pracę magisterską

Byłaby to praca na max 11 dni, nawet bez pomocy teścia ;-)
habela
Posted: Tuesday, December 14, 2010 7:00:45 PM
Rank: Administration

Joined: 12/6/2004
Posts: 360
Points: 52
Kilka luźnych komentarzy do niedawnych postów.
Istotnie, pomiędzy umożliwieniem obiektowi złożonemu posiadania wartości typu prostego a zdolnością do przechowywania i magazynowania zawartości mixed jest dość daleka droga. Po pierwsze - kolejność poszczególnych podobiektów (w tej chwili model składu jej nie uwzględnia) zaczyna mieć znaczenie. Innymi słowy, obiekty nie mogą wobec tego przechowywać zbiorów referencji, ale raczej ich sekwencje. Po drugie, zawartość tekstowa w obiektach typu mixed to tak naprawdę wiele węzłów (być może także węzły znaków białych - można zobaczyć, jak to widzi chociażby DOM). Nie kojarzę, jak to jest rozwiązane w JAXB (dedykowane klasy i interfejsy Java generowane z definicji schematu XML) i im podobnych, ale podejerzewam, że się da, tyle że owocuje mało przyjemną w przetwarzaniu strukturą. Przetwarzać to w języku zapytań można, ale zapewne właśnie jako heterogeniczną sekwencję węzłów, w tym węzłów tekstowych i obiektowych.

Po poście Radka uświadomiłem sobie jeszcze mocniej, że ten model składu bardzo zgodnie się wpisuje w filozofię języków takich jak Java, jak i w inspirowane nim UML behavior. (choć oczywiście jest potencjalnie bogatszy - kompozycja i te prosto-złożone obiekty)
W UML-u linki też nie mają własnych identyfikatorów, co sprawia, że mamy tylko addLink i removeLink, a brak jest akcji updateLink. Podobnie dla atrybutów typów prostych.

A skoro już jesteśmy przy UML, to konfrontując możliwości tego modelu składu z modelem obiektów implikowanym przez definicję UML (i możliwości ich opisu poprzez model klas), warto zauważyć.
1) Niemożność bezpośredniego zamodelowania obiektu złożonego, który zawiera też wartość prostą. Wszelkie dane, które siedzą w UML-owym obiekcie przynależą do jakiejś nazwanej Property.
2) Jeśli by utożsamić ze sobą UML-owe atrybuty w klasach oraz końce asocjacji (a autorzy UML mają takie inklinacje, traktując jedno i drugie miejscami jako jedynie warianty notacyjne - choć metamodel jedno i drugie inaczej odwzorowuje) - to pozostaje nam mniej więcej taka różnorodność, jak ta potrzebna do opisania różnych wariantów wynikających z podniesienia lub nie flagi "composite".
Istotnie - można tam wyodrębnić zwykłe powiązania, agregację (pusty diamencik) i kompozycję (czarny diamencik). Ale z tą agregacją byłbym ostrożny. Autorzy UML twierdzą sami, że nie pociąga ona za sobą semantycznych konkretów i w jednym miejscu wręcz ją nazywają "modeling placebo". Co innego - kompozycja. Gdybyśmy chcieli uczynić obiekt częścią dwóch innych obiektów, to można by sięgnąć po zamodelowanie go agregacją. Choć semantykę usuwania, to musielibyśmy sobie do tego dopowiedzieć bo z samej specyfikacji UML to nie wynika. Z kolei asocjacja dwukierunkowa z propagacją usuwania w obie strony - nie ma dla siebie żadnej gotowej konstrukcji w UML.


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.253 seconds.