Welcome Guest Search | Active Topics | Members | Log In

Metamodel w Odrze Options · View
greg
Posted: Tuesday, March 22, 2005 12:38:54 AM
Rank: Newbie

Joined: 12/16/2004
Posts: 7
Points: 0
Location: Warszawa
http://www.pjwstk.edu.pl/~s1621 Wersja 1.1

Jedna z pierwszych prób ugryzienia metamodelu w Odrze.
Do struktury bazy zostały dopisane odpowiednie struktury: MetaObiekt, MetaAtrybut, MetaWartość, MetaRelacja.

Przyjąłem spłaszczony model metamodelu. - "print schema" pokazuje strukturę metamodelu.


Wykonane:
01.02.2005 dodane nowe datastore i metastore do zapisu metamodelu.
21.03.2005 zmiana: metamodel będzie zapisywany w identycznej strukturze co cała baza. Przyjąłem konwencję, iż struktury metamodelu zaczynają się prefiksem małpki "@"- wymagało przekompilowania gramatyki.

Dodałem już funkcje wewnątrz kodu umożliwiające dodawanie metaobiektów, atrybutów itp w kodzie: Region "Funkcje zewnętrzne metamodelu" w Odra.cs.
Zastanawiam się nad słownikowaniem typów "Kind" tak aby np. klasa, class, Klasa znaczyło to samo.


Obecnie wypełniamy metamodel w kodzie w funkcji:
public void FillMetamodel()
{
OID t1 = AddMetaObject("T1", "Triger");
OID t2 = AddMetaObject("t2", "Triger");

OID ta = AddMetaAttribute("Wyzwalany");
AddMetaValue("After update", t1, ta);




Odpytywać metamodel można przez konsolę:
Przykłady:
@MetaObject where Kind="klasa"; - wszystkie klasy
@MetaObject where Name="T1"; - wszystkie obiekty o nazwie T1
(@MetaObject where Kind="Triger").Name; - nazwy wszystkich trigerów
(@MetaValue where ((Describe.@MetaObject.Name="T1")and(Describe.@MetaObject.Kind="Triger"))).Value; - wszystkie typy wyzwalania trigera T1

ToDO:
Sprawdzić strukturę metamodelu - liczności
Pytanie czy implementować funkcje dla programistów za pomocą funkcji Odry - "Bootstrapping"
Ustalić czy taka struktura jest wystarczająca - jakie dodatkowe funkcje dla programistów
Czy dodać relacje z atrubutami relacji?
i inne


Zapraszam do dyskusji....

Grzegorz Sobolewski
habela
Posted: Saturday, March 26, 2005 11:40:45 AM
Rank: Administration

Joined: 12/6/2004
Posts: 360
Points: 52
Poniżej kilka spostrzeżeń (tuż po wykonaniu polecenia print schema).

1. Struktura bardzo prosta (można rzec - w pełni znormalizowana). Mniej więcej tak w założeniu miało być, chociaż przekonamy się w praktyce, czy aż tak prosty wariant nie utrudni życia programiście przy prostych zadaniach.
Zmierzam do tego, że ja projektując strukturę metadanych przyjąłem, że tak powiem bardziem MetaObiekt-ocentryczne podejście.
Pewne wczesne założenia znalazły się np. w:
http://www.pjwstk.edu.pl/~habela/publications/OOIS2003overcoming.pdf

2. Zapisując strukturę schematu zewnętrznego (praca p. Juranka i p. Białczaka) przyjęliśmy następującą budowę meta-związków w metamodelu:



Jak widać zakładamy tam, że chcemy mieć możliwość dwukierunkowej nawigacji, tzn. że meta-związki będą sparowane.
Co do metazwiązków, to nie sądzę, by możliwość osadzenia w nich atrybutów była warta dodatkowej komplikacji struktury.
Natomiast w niektórych wypadkach użyteczna byłaby własność uporządkowania meta-związków (aby nie wikłać się w numerowanie za pomocą meta-wartości / meta-atrybutów (zależnie od przyjętej terminologii) wszędzie tam, gdzie numerowanie jest potrzebne). Temat pojawia się np. gdybyśmy chcieli w rozwiniętej postaci pokazywać parametry w sygnaturze operacji. (ostatecznie tego nie robimy, pozostawiając sygnaturę w postaci zwalidowanego tekstu).
Gdyby powyższe okazało się przydatne, to na powyższym diagramie należałoby dać {ordered} przy końcu rels.

3. Co do meta atrybutów / meta wartości.
Znów - podane rozwiązanie jest o tyle dobre, że nie narusza dyscypliny budowy schematu. Byłaby ona złamana, gdybyśm np. uznali, że rolę meta-wartości będą pełnić stringowe podobiekty meta-obiektu, mające dowolne nazwy za wyjątkiem name i kind.
Znowu także - rozważane przeze mnie rozwiązania zakładały raczej możliwość prostej nawigacji od meta-obiektu do meta-wartości niż odwrotnie.

Czy to kwestia ergonomii - czy tylko kwestia gustu - nie podejmuję się obecnie rozstrzygać.

4. Trochę mnie zdziwiła obecność tutaj MetaAtrybutu. W zastosowanej u mnie terminologii, meta-atrybut odpowiadałby u Pana pojęciu MetaValue, zaś meta-wartość - atrybutowi Value w Pana obiekcie MetaValue.
Zdziwiła dlatego, że MetaAtrybut rozumiany tak jak tutaj pochodzi nieco "z innej bajki". Konkretnie - to są (jak sugeruje asocjacja IsInstance) dwa różne meta-poziomy. Jeśli meta obiekty, meta związki i meta wartości (rozumiane jako wystąpienia) nazwiemy metadanymi, to każde wystąpienie MetaAttribute będzie meta-metadaną.
Zakładam, że generalnie zrębów meta-metamodelu nie będziemy implementować. Tzn. że pojęcia metamodelu będą raczej "wszyte" w implementację. W przeciwnym razie, należałoby to jakoś skatalowgować, wiążąc dopuszczalne nazwy meta-atrybutów z określonymi wartościami kind meta-obiektów i meta-związków.
Ale w tej chwili zorientowałem się, że to raczej efekt ostrej normalizacji niż wchodzenia na poziom meta-metadanych.
Nie wiem, czy nie warto by wobec tego nieco zdenormalizować, tzn. zastąpić w meta-value (albo meta-attribute - zależnie jak nazwiemy obiekt zawierający opis konkretnego metaobiektu) referencję do obiektu meta-attribute (w którym tkwi tylko nazwa) samą tą nazwą.
greg
Posted: Monday, March 28, 2005 8:30:58 PM
Rank: Newbie

Joined: 12/16/2004
Posts: 7
Points: 0
Location: Warszawa
Ad 2. Możliwość parowania metazwiązków wydaje mi się pożyteczna, zatem uwzględnię ją, nie bardzo jednak rozumiem:

"Natomiast w niektórych wypadkach użyteczna byłaby własność uporządkowania meta-związków (aby nie wikłać się w numerowanie za pomocą meta-wartości / meta-atrybutów (zależnie od przyjętej terminologii) wszędzie tam, gdzie numerowanie jest potrzebne). Temat pojawia się np. gdybyśmy chcieli w rozwiniętej postaci pokazywać parametry w sygnaturze operacji. (ostatecznie tego nie robimy, pozostawiając sygnaturę w postaci zwalidowanego tekstu).
Gdyby powyższe okazało się przydatne, to na powyższym diagramie należałoby dać {ordered} przy końcu [i]rels."

Ad 3, 4
Reczywiście odpytywanie MetaObiektów o ich atrybuty jest tu utrudnione. Dopiero pojawienie się MetaValue "spina"
jakby metaobiekt z metaatrybutem.

Rozważam zbliżenie się do schematu nr 2 z wymienionego dokumentu.

W swojej wypowiedzi pisze Pan:
" to raczej efekt ostrej normalizacji niż wchodzenia na poziom meta-metadanych.
Nie wiem, czy nie warto by wobec tego nieco zdenormalizować, tzn. zastąpić w meta-value (albo meta-attribute - zależnie jak nazwiemy obiekt zawierający opis konkretnego metaobiektu) referencję do obiektu meta-attribute (w którym tkwi tylko nazwa) samą tą nazwą. "

Trudno mi jest podjąć decyzję, które rozwiązanie jest lepsze.
Funkcje udostępniane "programistom" wewnątrz kodu ułatwiają dodawanie nowych atrybutów i przypisywanie wartości, a ostra
normalizacja zapewnia pełną spójność.......


====================


Rozważam jeszcze wprowadzenie słownikowania atrybutów "kind", nie wiem jednak w jaki sposób definiować zasady walidacji: czy tylko
jako dozwolone kombinacje czy jakoś inaczej.

====================

Planuje umieścić coś w rodzaju okienkowego ObjectViewera oraz jakiegoś narzędzia do rysowania schematu (nie tylko metamodelu).

Chciałbym jednak wcześniej zamknąć kwestię schematu.
habela
Posted: Tuesday, March 29, 2005 10:26:38 AM
Rank: Administration

Joined: 12/6/2004
Posts: 360
Points: 52
greg wrote:
Ad 2. Możliwość parowania metazwiązków wydaje mi się pożyteczna, zatem uwzględnię ją, nie bardzo jednak rozumiem:

"Natomiast w niektórych wypadkach użyteczna byłaby własność uporządkowania meta-związków (aby nie wikłać się w numerowanie za pomocą meta-wartości / meta-atrybutów (zależnie od przyjętej terminologii) wszędzie tam, gdzie numerowanie jest potrzebne). Temat pojawia się np. gdybyśmy chcieli w rozwiniętej postaci pokazywać parametry w sygnaturze operacji. (ostatecznie tego nie robimy, pozostawiając sygnaturę w postaci zwalidowanego tekstu).
Gdyby powyższe okazało się przydatne, to na powyższym diagramie należałoby dać {ordered} przy końcu rels."

Istotnie, zdanie jest niejasne, bo zmieszałem tu sam postulat oraz próbę wyjaśnienia, jak zmieniłby on przytoczony wyżej diagram klas.
Chodziło mi o to, że:
a) Gdy np. wiążemy (za pomocą meta-związków) metaobiekt reprezentujący klasę z kilkoma metaobiektami reprezentującymi jej atrybuty - to ich kolejność nie jest dla nas istotna.
b) Z kolei, gdyby pokazywać powiązania meta-obiektu operacji z meta-obiektami jej parametrów, to ważne jest dla nas, który jest pierwszy, który drugi itd.

Należy wobec tego przyjrzeć się możliwym zastosowaniom i rozstrzygnąć, czy bardziej cenimy sobie:
1. Możliwość uporządkowania powiązań (za cenę dodatkowej złożoności) przez umieszczenie wskaźników z MetaObject do MetaRelationship w kolekcji uporządkowanej.
2. Prostotę - wtedy godzimy się z koniecznością numerowania tam gdzie to potrzebne (za pomocą meta-wartości w meta-obiektach).

Zwróćmy uwagę, że powyższy problem dotyczy tylko zdenormalizowanego rozwiązania, w którym nawigacja z MetaObiektu jest możliwa dzięki przechywywaniu przezeń kolekcji pointerów do MetaRelationship.

greg wrote:
W swojej wypowiedzi pisze Pan:
" to raczej efekt ostrej normalizacji niż wchodzenia na poziom meta-metadanych.
Nie wiem, czy nie warto by wobec tego nieco zdenormalizować, tzn. zastąpić w meta-value (albo meta-attribute - zależnie jak nazwiemy obiekt zawierający opis konkretnego metaobiektu) referencję do obiektu meta-attribute (w którym tkwi tylko nazwa) samą tą nazwą. "

Myślę, że akurat to posunięcie w stronę denormalizacji wielkiej rewolucji nie spowoduje, a zredukuje liczbę rodzajów niezbędnych obiektów.

Natomiast poważniejsza sprawa to ww. podejście do połączenia meta-obiektów z ich meta-związkami. Tzn. czy decydujemy się na "denormalizację" poprzez włożenie do meta-obiektu n wskaźników do prowadzących zeń meta-związków.

greg wrote:
Rozważam jeszcze wprowadzenie słownikowania atrybutów "kind", nie wiem jednak w jaki sposób definiować zasady walidacji: czy tylko
jako dozwolone kombinacje czy jakoś inaczej.


Myślę, że ważność słownikowania (jako przeciwieństwa "wszycia" pojęć do implementacji) zależeć będzie od tego, czy dopuścimy rozszerzalność (np. dla administratora) zestawu rodzajów przechowywanych w systemie metadanych.
Decydując się na słownikowanie (rozważałem to w Fig. 3 cytowanego artykułu), można pomyśleć o:
- określeniu zestawu kinds dla meta-obiektów;
- określenie zestawu kinds dla meta-związków;
- wskazanie jakie kinds meta-obiektów (na odpowiednich końcach!) mogą być łączone meta-związkami o jakich kinds;
- określenie zestawu nazw meta-atrybutów;
- określenie, jakie meta-atrybuty (nazwy) stosują się do meta-obiektów poszczególnych rodzajów;

Sądzę, że dalsze niuanse - np. wzajemne wykluczanie się dwóch różnych meta-związków czy dwóch atrybutów dla danego meta-obiektu albo np. liczności meta związków danego rodzaju - byłyby tu przesadą.
Chociaż (zob. ww. rysunek i artykuł) - zostawiłem tu pewną furtkę w postaci zapytań z regułami walidacyjnymi (zwrócą prawda lub fałsz). Można je traktować jako analogicznie do ograniczeń pisanych w języku UML za pomocą wyrażeń OCL.
Jednak - podkreślam - trzeba się zastanowić, czy wchodzimy w temat tego słownikowania (to w sumie byłaby już po części implementacja meta-metamodelu).
greg
Posted: Wednesday, March 30, 2005 7:59:22 AM
Rank: Newbie

Joined: 12/16/2004
Posts: 7
Points: 0
Location: Warszawa
1. Zdenormalizowałem schemat zgodnie uwagami - (print schema pokazuje nowy model).
Stąd można ściągnąć: http://www.pjwstk.edu.pl/~s1621/ i potestować.

Metoda AddMetaValue(OID obiekt_opisywany, string atrybut, string wartosc) w momenci wywołania
dodaje relationship taki jak podany atrybut.

Przykłady nowych zapytań:

(@MetaObject where Kind="Triger").wyzwalany.@MetaValue.Value;

-wszystkie typy wyzwalań trigerów


((@MetaObject where Name="Osoba") where nazwisko.@MetaValue.Value = "Sobolewski").imie.@MetaValue.Value;

Imiona wszystkich z klasy osoba gdzie nazwisko = "Sobolewski"

2. Dodawanie Relationships odbywa się już jako para relacji.
Jest dodane Reverse.

Metoda public OID AddMetaRelationship(string typ12, string typ21, OID obiekt1, OID obiekt2)
tutaj podajemy opis relacji w jedną i drugą stronę

Przykładowe zapytanie:
(@MetaRelationship where Kind="wynika").Reverse.@MetaRelationship.Kind;
-zwraca odwrotną relację dla relacji typu wynika

Czy takie rozwiązanie będzie bardziej przyjazne?
habela
Posted: Saturday, April 02, 2005 1:42:46 PM
Rank: Administration

Joined: 12/6/2004
Posts: 360
Points: 52
Code:
@MetaObject = {
  Name = String [1..1]
  Kind = String [1..1]
  imie = ref @MetaValue  nazwisko = ref @MetaValue  wyzwalany = ref @MetaValue
wyzwalany = ref @MetaValue } @MetaValue = {
  Value = String [1..1]
} @MetaRelationship = {
  Kind = String [1..1]
  IsSource = ref @MetaObject [1..1]
  IsTarget = ref @MetaObject [1..1]
  Reverse = ref @MetaRelationship [1..1]
}}


Zmiana dotycząca MetaRelationship jest chyba dość praktyczna. Nadal mamy tu swoistą normalizację - przez co trudniej jest nawigować zaczynając od meta-obiektu - ale może się to sprawdzi.
Natomiast tego, co zostało zrobione z MetaValue nie nazwałbym denormalizacją - ale raczej de-schematyzacją czy de-typizacją. Najlepszym tego dowodem jest przytoczony wyżej zrzut schematu, który - trzeba przyznać - wygląda sztucznie.
Zwróćmy uwagę, że gdyby zrobić np. tak:
Code:
@MetaObject = {
  Name = String [1..1]
  Kind = String [1..1]
  attributes = ref @MetaAttribute  [0..*]}
@MetaAttribute = {
  Name = String [1..1]
  Value = String [1..1]
} ...

(tu trochę inne rozumienie MetaAttribute - bo ma tyle instancji ile opisywanych wartości, a nie tyle ile rodzajów meta-atrybutów.)
To zachowamy (niezależnie od zestawu zdefiniowanych meta-atrybutów) wiedzę, jakich pointerów należy się spodziewać wewnątrz MetaObject i MetaRelationship oraz do czego prowadzą (do MetaObject - te w MetaRelationship albo do MetaAttribute - ten w MetaObject).

Innymi słowy - ze względów szeroko rozumianej estetyki postuluję, aby niezależnie od tego, jak daleko posuniemy się z normalizacją (i niezależnie - w jaki sposób będziemy łączyć z metaobiektem meta-wartości) zestaw stosowanych nazw rodzajów metaobiektów, nazw rodzajów metazwiązków oraz nazw meta-atrybutów nie miał wpływu na schemat struktury metadanych.
greg
Posted: Wednesday, April 06, 2005 12:00:19 AM
Rank: Newbie

Joined: 12/16/2004
Posts: 7
Points: 0
Location: Warszawa
Schemat poprawiłem. Rzeczywiście wpływ zawartości metamodelu na jego schemat był niedopuszczalny.
Obecnie mamy tylko MetaAtrybuty o nazwach i wartościach z referencją do obiektu.

Przykładowe zapytania:


@MetaObject.Attributes.@MetaAttribute;

wszystkie atrybuty obiketów


(@MetaObject where Kind="Triger").Attributes.@MetaAttribute.Value;

wszystkie wartości atrybutów dla trigerów


Zapraszam: http://www.pjwstk.edu.pl/~s1621/ po najnowszą wersję 1.3.



(Szukam obecnie przykładów gdzie taki schemat będzie niewystarczający)
habela
Posted: Friday, April 08, 2005 4:14:27 PM
Rank: Administration

Joined: 12/6/2004
Posts: 360
Points: 52
Kilka drobnych uwag. Zacznijmy od schematu, jaki narzędzie nam drukuje:
Code:
@MetaObject = {
  Name = String [1..1]
  Kind = String [1..1]
  Attributes = ref @MetaAttribute }
@MetaAttribute = {
  Name = String [1..1]
  Value = String [1..1]
} @MetaRelationship = {
  Kind = String [1..1]
  IsSource = ref @MetaObject [1..1]
  IsTarget = ref @MetaObject [1..1]
  Reverse = ref @MetaRelationship [1..1]
}}

Tak właśnie wyobrażałem sobie użycie meta-atrybutu. Tutaj tylko gwoli ścisłości dwie sprawy:
- ponieważ Attributes nie jest złożonym obiektem-kolekcją referencji, ale stanowi nazwę każdej jednej referencji - to pasowałaby raczej nazwa attribute;
- nie wiem, jak aktualna implementacja podchodzi do sprawy pokazywania liczności, natomiast z pewnością logiczne byłoby na tym schemacie podanie: Attribute = ref @MetaAttribute [0..*] .

Z kolei instancje metaobiektów i meta-atrybutów mówią co innego. Z poniższego wynika, że MetaRelationship jest rozpięte pomiędzy meta-atrybutami a nie pomiędzy dwoma metaobiektami:
Code:
025  @MetaAttribute = {
026   Name = wyzwalany
027   Value = after_update
     }
029  @MetaAttribute = {
030   Name = wyzwalany
031   Value = before_delete
     }
033  @MetaRelationship = {
034   Kind = wynika
035   IsSource = -> 25
036   IsTarget = -> 29
042   Reverse = -> 37
     }
037  @MetaRelationship = {
038   Kind = jest po
039   IsSource = -> 29
040   IsTarget = -> 25
041   Reverse = -> 33

Byłbym za tym, aby nie tworzyć meta-zwązków pomiędzy meta-atrybutami (nawet, jeśli w niektórych sytuacjach spowoduje to potrzebę użycia większej liczby metaobiektów do opisu struktury).

Co do MetaRelationship, to wspominając o denormalizacji forsowałem nieco inne rozwiązanie. Nie jestem pewien, czy jest sens namawiać na jego wprowadzenie, ale skoro już wprowadził Pan te wskaźniki Reverse (a to już blisko) - to napiszę, jaki był pomysł.
Otóż dzięki temu Reverse dosyć spójne wydało mi się rozwiązanie jak na diagramie z wcześniejszego posta.
To by wyglądało mniej więcej tak:
Code:
@MetaObject = {
  Name = String [1..1]
  Kind = String [1..1]
  Attributes = ref @MetaAttribute [0..*]
  Relationships = ref @MetaRelationship [0..*]
}
@MetaAttribute = {
  Name = String [1..1]
  Value = String [1..1]
}
@MetaRelationship = {
  Kind = String [1..1]
  Target = ref @MetaObject [1..1]
  Reverse = ref @MetaRelationship [1..1]
}

greg
Posted: Tuesday, April 12, 2005 11:09:00 PM
Rank: Newbie

Joined: 12/16/2004
Posts: 7
Points: 0
Location: Warszawa
Zmiany w schemacie metamodelu, obecnie mamy:

@MetaObject = {
Name = String [1..1]
Kind = String [1..1]
Attribute = ref @MetaAttribute [0..*]
Relationship = ref @MetaRelationship [0..*]
} @MetaAttribute = {
Name = String [1..1]
Value = String [1..1]
} @MetaRelationship = {
Kind = String [1..1]
Target = ref @MetaObject [1..1]
Reverse = ref @MetaRelationship [1..1]
} @MetaKindDictionary = {
Kind = String [1..1]
Type = String [1..1]
}}

Zmiana w MetaObiekcie - referencje Attribute i Relationship z odpowiednimi licznościami
Zmiana w MetaRelationship - referencja Target do MetaObiektu i Reverse do sparowanej MetaRelationship
Doszedł prosty słownik wartości Kind dla MetaObiektu i MetaRelationship.

>Z kolei instancje metaobiektów i meta-atrybutów mówią co innego. Z poniższego wynika, że MetaRelationship jest rozpięte pomiędzy meta-atrybutami
> a nie pomiędzy dwoma metaobiektami:
Rzeczywiście był błąd w FillMetamodel.




W kodzie:
Doszły funkcje FillDictionary - wypełnienie słownika
W AddMetaObject i AddMetaRelationship sprawdzamy czy Kind znajduje się już w słowniku.
Wykonywane jest zapytanie które sprawdza liczność wyniku i ewentualnie wywołuje exception.


Przykładowe zapytania:

@MetaObject.Relationship.@MetaRelationship.Kind;
@MetaObject.Attribute.@MetaAttribute;



TODO:
Cciałbym finalnie zamknąć kwestię schematu
Zobaczę co dalej ze słownikiem, czy warto go rozwijać.
Myślę o jakimś środowisku okienkowym do edycji metamodelu, słownika i prezentacji tych danych.


Wersja 1.4 na http://www.pjwstk.edu.pl/~s1621
greg
Posted: Sunday, April 24, 2005 1:17:54 PM
Rank: Newbie

Joined: 12/16/2004
Posts: 7
Points: 0
Location: Warszawa
Nowa wersja 1.5 wgrana na http://www.pjwstk.edu.pl/~s1621/.

Schemat metamodelu bez zmian.


Zrobione:
Wydzielone klasy obiektów metamodelu w store
Możliwe jest tworzenie obiektów metamodelu z wnętrza obiektu datastore. - zainteresuje osoby które chcą sobie coś zapisać w metamodelu z tego poziomu - procedury, trigery itp.

Niestety słownikowanie działa obecnie tylko przy wywoływaniach z odra.cs. Nie ma możliwości odpytywania bazy za pomocą SBQL wewnątrz obiektu datastore. No i nie wiem jeszcze czy i jak to robić :(


TODO:
Przydałyby się jeszcze: edycja obiektów metamodelu i usuwanie.
Środowisko okienkowe ... w drodze.
greg
Posted: Wednesday, May 11, 2005 1:14:53 AM
Rank: Newbie

Joined: 12/16/2004
Posts: 7
Points: 0
Location: Warszawa
Nowa rewolucyjna, okienkowa wersja 2.0 wgrana na http://www.pjwstk.edu.pl/~s1621.

Nowe:
Możliwość otwierania wielu okien
Szybkie odpalanie zapytań - F5
Manager MetaObiektów z dodawaniem MetaObiektów, wkrótce reszta


Zapraszam do testów, proszę o uwagi i opinie.

Schemat metamodelu bez zmian.

GS
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.141 seconds.