Home » Modeling » EMF » about the hierarchy of emf
| about the hierarchy of emf [message #415655] |
Wed, 26 December 2007 02:06  |
Eclipse User |
|
|
|
Originally posted by: heiyuchuanxia.163.com
hi, i'm a newbie here. I have a question about the hierarchy of EMF.
since in the EMF overview document, it says "EMF can be thought of as a
highly efficient Java implementation of a core subset of the MOF API.
However, to avoid any confusion, the MOF-like core meta model in EMF is
called Ecore instead of MOF." So according to this, I thought EMF Ecore
is in the M3 Layer, and a model defined using Ecore is in the M2 layer.
But in the OMG MOF hierarchy, UML is in the M2 layer, since UML is
defined using MOF. So we can get that UML is in the same layer of a
model defined using Ecore. But in the fact, a model defined using Ecore
can be generated from a UML class diagram, which is defined using UML
and is in the M1 layer. So this transformation is in different layer?
And I was so confused why the model in different layer can be transformed.
Thanks very much to care about my problem, and I'm appreciated to listen
to your opinion on this question.
Stefanie
|
|
|
| Re: about the hierarchy of emf [message #415659 is a reply to message #415655] |
Wed, 26 December 2007 11:52  |
 Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Stefanie,
Comments below.
stefanie zhao wrote:
> hi, i'm a newbie here. I have a question about the hierarchy of EMF.
>
> since in the EMF overview document, it says "EMF can be thought of as a
> highly efficient Java implementation of a core subset of the MOF API.
> However, to avoid any confusion, the MOF-like core meta model in EMF is
> called Ecore instead of MOF."
Yes. It's very closely aligned with EMOF, which is effectively MOF split
into Essential MOF and Complete MOF. In fact, Ecore can be written to an
EMOF conforming serialization and can be read from an EMOF conforming
serialization; the editor does that automatically if you save to or load
from a *.emof extension.
> So according to this, I thought EMF Ecore
> is in the M3 Layer, and a model defined using Ecore is in the M2 layer.
>
Oh dear. The M levels! That's always good for some confusing fun...
Certainly there is Ecore.ecore, which can be used to define
Library.ecore, for which you used to define a instance.library, but
Ecore.ecore also defines itself as is in fact a serialized instance of
itself so is M3, M2, and M1 all at once.
> But in the OMG MOF hierarchy, UML is in the M2 layer, since UML is
> defined using MOF.
Yep. Ecore.ecore also defines XSD (XML Schema), which might specify
Library.xsd, which in turn specifies the structure for instance.library.
So now Ecore.ecore is M4. Of course there is Ecore.xsd which is
Ecore.ecore converted to an XSD and that of course describes Ecore
itself so kind of gets you into a loop with Ms going on forever.
> So we can get that UML is in the same layer of a
> model defined using Ecore.
The fun with M never ends!
> But in the fact, a model defined using Ecore
> can be generated from a UML class diagram, which is defined using UML
> and is in the M1 layer. So this transformation is in different layer?
>
Yep. The UML project even has an Ecore.uml.
> And I was so confused why the model in different layer can be transformed.
>
That's because Ms are a relative thing. You can't strictly pin anything
to a particular level and make it stay there because no matter what
instance level thing you have (a *.ecore, *.uml, *.xsd, *.wsdl, *.bpel
and so on), it might well be a meta for something else thereby pushing
everything used to specify it up in the M levels.
> Thanks very much to care about my problem, and I'm appreciated to listen
> to your opinion on this question.
>
Just keep in mind that these M level things are an endless source of
confusion which is why I tend to say, a model is a model is a model and
most importantly the model of a model is a model. I.e., these M levels
would degrade into senseless infinite recursion unless the loop is
broken by a model that describes itself; such a model is both a model
and a metamodel. Ecore.ecore describes it's own abstract syntax,
XMLSchema.xsd describes its own concrete syntax, and Java can be used to
implement its own semantics...
> Stefanie
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: about the hierarchy of emf [message #415662 is a reply to message #415655] |
Wed, 26 December 2007 13:52 |
Philipp Kutter
Messages: 306
Registered: July 2009 |
Senior Member |
|
|
Hi, Stefanie.
The metaphore of M0 (MOF of MOF), M1 (MOF of UML), M2 (UML of System),
M3 (System of Objects) is used to make the usage of abstraction and
different languages on different abstraction levels clear.
It basically tells you that the language defined on Mi is used describe
instances on Mi+1. Mof is used to define the concepts of MOF in M0,
Mof is used to define the concepts of UML on M1, UML is used to define
the concepts of your application on M2, and your application is used to
define the objects or your domain on M3.
The EMF project defines ECore/EMof (EMof is the subset of MOF implemnted
by EMF.) using ECore. The UML2 project uses ECore/EMof to define UML.
And projects like TopcaseD use UML to make tools to define systems,
and then various software generation projects use UML models to generate
systems. All these activities fit in the above metaphore.
HOWEVER most people using EMF use it differently:
Mx (ECore of ECore)
Mx+1 (ECore of Sytem)
Mx+2 (ECore generated System of ECore-Objects)
whether you set x to 0 or 1 does not matter, but it is important, that
most people only use 3 levels out of the 4.
The MDA initiative is about having many abstraction levels, and defining
them, and the transformation from one to the next using MOF based
standard. Unfortunately, in order to explain MDA, the M0-M3 metaphore is
used, which confuses a lot.
I hope this was useful,
Philipp
PS: The overview document should be updates. It should mentioned that
until EMF 2.2 the covered subset of MOF is called (and standardized as)
EMof, and that EMF 2.3 covers some Java Generics aspects too.
stefanie zhao wrote:
> hi, i'm a newbie here. I have a question about the hierarchy of EMF.
>
> since in the EMF overview document, it says "EMF can be thought of as a
> highly efficient Java implementation of a core subset of the MOF API.
> However, to avoid any confusion, the MOF-like core meta model in EMF is
> called Ecore instead of MOF." So according to this, I thought EMF Ecore
> is in the M3 Layer, and a model defined using Ecore is in the M2 layer.
> But in the OMG MOF hierarchy, UML is in the M2 layer, since UML is
> defined using MOF. So we can get that UML is in the same layer of a
> model defined using Ecore. But in the fact, a model defined using Ecore
> can be generated from a UML class diagram, which is defined using UML
> and is in the M1 layer. So this transformation is in different layer?
> And I was so confused why the model in different layer can be transformed.
>
> Thanks very much to care about my problem, and I'm appreciated to listen
> to your opinion on this question.
>
> Stefanie
|
|
|
| Re: about the hierarchy of emf [message #415682 is a reply to message #415662] |
Fri, 28 December 2007 16:15 |
Marcelo Paternostro
Messages: 602
Registered: July 2009 |
Senior Member |
|
|
Hi Philipp,
Probably Ed is thinking "Why is he reading the NG instead of writing the
book?" ;-) From time to time I manage to get loose and sneak my head
here and there for a few minutes :-P
I liked your explanation a lot (this M thing is really confusing) but I
think you got it backwards: M0 is data (the "real world" as referred
here http://en.wikipedia.org/wiki/Meta-Object_Facility) and the level of
abstraction increases with the number. A few years ago, when I was
trying to understand this mess I though to myself: M0 -> Mo -> letter
"o" of objects.
Anyhow... back to chapter 11.
Cheers,
Marcelo
Philipp W. Kutter wrote:
> Hi, Stefanie.
>
> The metaphore of M0 (MOF of MOF), M1 (MOF of UML), M2 (UML of System),
> M3 (System of Objects) is used to make the usage of abstraction and
> different languages on different abstraction levels clear.
>
> It basically tells you that the language defined on Mi is used describe
> instances on Mi+1. Mof is used to define the concepts of MOF in M0,
> Mof is used to define the concepts of UML on M1, UML is used to define
> the concepts of your application on M2, and your application is used to
> define the objects or your domain on M3.
>
> The EMF project defines ECore/EMof (EMof is the subset of MOF implemnted
> by EMF.) using ECore. The UML2 project uses ECore/EMof to define UML.
> And projects like TopcaseD use UML to make tools to define systems,
> and then various software generation projects use UML models to generate
> systems. All these activities fit in the above metaphore.
>
> HOWEVER most people using EMF use it differently:
>
> Mx (ECore of ECore)
> Mx+1 (ECore of Sytem)
> Mx+2 (ECore generated System of ECore-Objects)
>
> whether you set x to 0 or 1 does not matter, but it is important, that
> most people only use 3 levels out of the 4.
>
> The MDA initiative is about having many abstraction levels, and defining
> them, and the transformation from one to the next using MOF based
> standard. Unfortunately, in order to explain MDA, the M0-M3 metaphore is
> used, which confuses a lot.
>
> I hope this was useful,
> Philipp
>
> PS: The overview document should be updates. It should mentioned that
> until EMF 2.2 the covered subset of MOF is called (and standardized as)
> EMof, and that EMF 2.3 covers some Java Generics aspects too.
>
> stefanie zhao wrote:
>> hi, i'm a newbie here. I have a question about the hierarchy of EMF.
>>
>> since in the EMF overview document, it says "EMF can be thought of as a
>> highly efficient Java implementation of a core subset of the MOF API.
>> However, to avoid any confusion, the MOF-like core meta model in EMF is
>> called Ecore instead of MOF." So according to this, I thought EMF Ecore
>> is in the M3 Layer, and a model defined using Ecore is in the M2 layer.
>> But in the OMG MOF hierarchy, UML is in the M2 layer, since UML is
>> defined using MOF. So we can get that UML is in the same layer of a
>> model defined using Ecore. But in the fact, a model defined using Ecore
>> can be generated from a UML class diagram, which is defined using UML
>> and is in the M1 layer. So this transformation is in different layer?
>> And I was so confused why the model in different layer can be transformed.
>>
>> Thanks very much to care about my problem, and I'm appreciated to listen
>> to your opinion on this question.
>>
>> Stefanie
|
|
|
| Re: about the hierarchy of emf [message #415683 is a reply to message #415682] |
Fri, 28 December 2007 16:47 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Marcelo,
And "they" couldn't even start counting at 1! :-P
Marcelo Paternostro wrote:
> Hi Philipp,
>
> Probably Ed is thinking "Why is he reading the NG instead of writing the
> book?" ;-) From time to time I manage to get loose and sneak my head
> here and there for a few minutes :-P
>
> I liked your explanation a lot (this M thing is really confusing) but I
> think you got it backwards: M0 is data (the "real world" as referred
> here http://en.wikipedia.org/wiki/Meta-Object_Facility) and the level of
> abstraction increases with the number. A few years ago, when I was
> trying to understand this mess I though to myself: M0 -> Mo -> letter
> "o" of objects.
>
> Anyhow... back to chapter 11.
>
> Cheers,
> Marcelo
>
> Philipp W. Kutter wrote:
>
>> Hi, Stefanie.
>>
>> The metaphore of M0 (MOF of MOF), M1 (MOF of UML), M2 (UML of System),
>> M3 (System of Objects) is used to make the usage of abstraction and
>> different languages on different abstraction levels clear.
>>
>> It basically tells you that the language defined on Mi is used describe
>> instances on Mi+1. Mof is used to define the concepts of MOF in M0,
>> Mof is used to define the concepts of UML on M1, UML is used to define
>> the concepts of your application on M2, and your application is used to
>> define the objects or your domain on M3.
>>
>> The EMF project defines ECore/EMof (EMof is the subset of MOF implemnted
>> by EMF.) using ECore. The UML2 project uses ECore/EMof to define UML.
>> And projects like TopcaseD use UML to make tools to define systems,
>> and then various software generation projects use UML models to generate
>> systems. All these activities fit in the above metaphore.
>>
>> HOWEVER most people using EMF use it differently:
>>
>> Mx (ECore of ECore)
>> Mx+1 (ECore of Sytem)
>> Mx+2 (ECore generated System of ECore-Objects)
>>
>> whether you set x to 0 or 1 does not matter, but it is important, that
>> most people only use 3 levels out of the 4.
>>
>> The MDA initiative is about having many abstraction levels, and defining
>> them, and the transformation from one to the next using MOF based
>> standard. Unfortunately, in order to explain MDA, the M0-M3 metaphore is
>> used, which confuses a lot.
>>
>> I hope this was useful,
>> Philipp
>>
>> PS: The overview document should be updates. It should mentioned that
>> until EMF 2.2 the covered subset of MOF is called (and standardized as)
>> EMof, and that EMF 2.3 covers some Java Generics aspects too.
>>
>> stefanie zhao wrote:
>>
>>> hi, i'm a newbie here. I have a question about the hierarchy of EMF.
>>>
>>> since in the EMF overview document, it says "EMF can be thought of as a
>>> highly efficient Java implementation of a core subset of the MOF API.
>>> However, to avoid any confusion, the MOF-like core meta model in EMF is
>>> called Ecore instead of MOF." So according to this, I thought EMF Ecore
>>> is in the M3 Layer, and a model defined using Ecore is in the M2 layer.
>>> But in the OMG MOF hierarchy, UML is in the M2 layer, since UML is
>>> defined using MOF. So we can get that UML is in the same layer of a
>>> model defined using Ecore. But in the fact, a model defined using Ecore
>>> can be generated from a UML class diagram, which is defined using UML
>>> and is in the M1 layer. So this transformation is in different layer?
>>> And I was so confused why the model in different layer can be transformed.
>>>
>>> Thanks very much to care about my problem, and I'm appreciated to listen
>>> to your opinion on this question.
>>>
>>> Stefanie
>>>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: about the hierarchy of emf [message #415740 is a reply to message #415682] |
Fri, 04 January 2008 16:29 |
Philipp Kutter
Messages: 306
Registered: July 2009 |
Senior Member |
|
|
Hi, Marcelo.
Thanks for telling about my error.
Please feel free to reuse the explanation (of course with the correction
;-)) I'd as well like to give comments to any part of the forthcomming book.
Best, Philipp
Marcelo Paternostro wrote:
> Hi Philipp,
>
> Probably Ed is thinking "Why is he reading the NG instead of writing the
> book?" ;-) From time to time I manage to get loose and sneak my head
> here and there for a few minutes :-P
>
> I liked your explanation a lot (this M thing is really confusing) but I
> think you got it backwards: M0 is data (the "real world" as referred
> here http://en.wikipedia.org/wiki/Meta-Object_Facility) and the level of
> abstraction increases with the number. A few years ago, when I was
> trying to understand this mess I though to myself: M0 -> Mo -> letter
> "o" of objects.
>
> Anyhow... back to chapter 11.
>
> Cheers,
> Marcelo
>
> Philipp W. Kutter wrote:
>> Hi, Stefanie.
>>
>> The metaphore of M0 (MOF of MOF), M1 (MOF of UML), M2 (UML of System),
>> M3 (System of Objects) is used to make the usage of abstraction and
>> different languages on different abstraction levels clear.
>>
>> It basically tells you that the language defined on Mi is used describe
>> instances on Mi+1. Mof is used to define the concepts of MOF in M0,
>> Mof is used to define the concepts of UML on M1, UML is used to define
>> the concepts of your application on M2, and your application is used to
>> define the objects or your domain on M3.
>>
>> The EMF project defines ECore/EMof (EMof is the subset of MOF implemnted
>> by EMF.) using ECore. The UML2 project uses ECore/EMof to define UML.
>> And projects like TopcaseD use UML to make tools to define systems,
>> and then various software generation projects use UML models to generate
>> systems. All these activities fit in the above metaphore.
>>
>> HOWEVER most people using EMF use it differently:
>>
>> Mx (ECore of ECore)
>> Mx+1 (ECore of Sytem)
>> Mx+2 (ECore generated System of ECore-Objects)
>>
>> whether you set x to 0 or 1 does not matter, but it is important, that
>> most people only use 3 levels out of the 4.
>>
>> The MDA initiative is about having many abstraction levels, and defining
>> them, and the transformation from one to the next using MOF based
>> standard. Unfortunately, in order to explain MDA, the M0-M3 metaphore is
>> used, which confuses a lot.
>>
>> I hope this was useful,
>> Philipp
>>
>> PS: The overview document should be updates. It should mentioned that
>> until EMF 2.2 the covered subset of MOF is called (and standardized as)
>> EMof, and that EMF 2.3 covers some Java Generics aspects too.
>>
>> stefanie zhao wrote:
>>> hi, i'm a newbie here. I have a question about the hierarchy of EMF.
>>>
>>> since in the EMF overview document, it says "EMF can be thought of as a
>>> highly efficient Java implementation of a core subset of the MOF API.
>>> However, to avoid any confusion, the MOF-like core meta model in EMF is
>>> called Ecore instead of MOF." So according to this, I thought EMF Ecore
>>> is in the M3 Layer, and a model defined using Ecore is in the M2 layer.
>>> But in the OMG MOF hierarchy, UML is in the M2 layer, since UML is
>>> defined using MOF. So we can get that UML is in the same layer of a
>>> model defined using Ecore. But in the fact, a model defined using Ecore
>>> can be generated from a UML class diagram, which is defined using UML
>>> and is in the M1 layer. So this transformation is in different layer?
>>> And I was so confused why the model in different layer can be transformed.
>>>
>>> Thanks very much to care about my problem, and I'm appreciated to listen
>>> to your opinion on this question.
>>>
>>> Stefanie
|
|
| |
| Re: about the hierarchy of emf [message #415742 is a reply to message #415741] |
Fri, 04 January 2008 17:08 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Philipp, Ed,
I just have to weigh in on this one. The modeling layer stack is one of my
favourite topics :-)
I think, in this case, that zero is a particularly expressive index. The
objects at M0 do not constitute a model, whereas at every other M-level
they do. So, M0 is the "not a model" modeling layer, and zero neatly
represents absence.
Even Ecore does not manifest itself at the M0 level as it does at all of the
others, because that is the domain of the JVM's object model.
UML has InstanceSpecifications that *model* M0 instances, but they are M1
elements nonetheless. So, that's a different waxy ball.
Cheers,
Christian
Philipp W. Kutter wrote:
> Wirth always told in his lectures, that real computer
> scientists do start to count at 1.
>
> Today after many years I'd tell him, that this and similar
> ideas are the reason, why nobody understands them...
>
> Philipp
>
> Ed Merks wrote:
>> Marcelo,
>>
>> And "they" couldn't even start counting at 1! :-P
>>
|
|
|
| Re: about the hierarchy of emf [message #415744 is a reply to message #415742] |
Fri, 04 January 2008 19:02 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------090506050209030705090405
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Christian,
Does that make the hardware itself running the JVM an M-1 thing? It's
representing the JVM's model of real live Java after all...
Christian W. Damus wrote:
> Hi, Philipp, Ed,
>
> I just have to weigh in on this one. The modeling layer stack is one of my
> favourite topics :-)
>
> I think, in this case, that zero is a particularly expressive index. The
> objects at M0 do not constitute a model, whereas at every other M-level
> they do. So, M0 is the "not a model" modeling layer, and zero neatly
> represents absence.
>
> Even Ecore does not manifest itself at the M0 level as it does at all of the
> others, because that is the domain of the JVM's object model.
>
> UML has InstanceSpecifications that *model* M0 instances, but they are M1
> elements nonetheless. So, that's a different waxy ball.
>
> Cheers,
>
> Christian
>
>
> Philipp W. Kutter wrote:
>
>
>> Wirth always told in his lectures, that real computer
>> scientists do start to count at 1.
>>
>> Today after many years I'd tell him, that this and similar
>> ideas are the reason, why nobody understands them...
>>
>> Philipp
>>
>> Ed Merks wrote:
>>
>>> Marcelo,
>>>
>>> And "they" couldn't even start counting at 1! :-P
>>>
>>>
>
>
--------------090506050209030705090405
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Christian,<br>
<br>
Does that make the hardware itself running the JVM an M-1 thing? It's
representing the JVM's model of real live Java after all...<br>
<br>
<br>
Christian W. Damus wrote:
<blockquote cite="mid:fllp6k$j9e$1@build.eclipse.org" type="cite">
<pre wrap="">Hi, Philipp, Ed,
I just have to weigh in on this one. The modeling layer stack is one of my
favourite topics :-)
I think, in this case, that zero is a particularly expressive index. The
objects at M0 do not constitute a model, whereas at every other M-level
they do. So, M0 is the "not a model" modeling layer, and zero neatly
represents absence.
Even Ecore does not manifest itself at the M0 level as it does at all of the
others, because that is the domain of the JVM's object model.
UML has InstanceSpecifications that *model* M0 instances, but they are M1
elements nonetheless. So, that's a different waxy ball.
Cheers,
Christian
Philipp W. Kutter wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Wirth always told in his lectures, that real computer
scientists do start to count at 1.
Today after many years I'd tell him, that this and similar
ideas are the reason, why nobody understands them...
Philipp
Ed Merks wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Marcelo,
And "they" couldn't even start counting at 1! :-P
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
<br>
</body>
</html>
--------------090506050209030705090405--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: about the hierarchy of emf [message #415749 is a reply to message #415744] |
Fri, 04 January 2008 19:35 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
A palpable hit!
That'll teach me not to use the overloaded term "model" from a different
context.
:-)
Ed Merks wrote:
> Christian,
>
> Does that make the hardware itself running the JVM an M-1 thing? It's
> representing the JVM's model of real live Java after all...
>
-----8<-----
>> Even Ecore does not manifest itself at the M0 level as it does at all of
>> the others, because that is the domain of the JVM's object model.
----->8-----
|
|
|
| Re: about the hierarchy of emf [message #415763 is a reply to message #415742] |
Fri, 04 January 2008 22:11 |
Philipp Kutter
Messages: 306
Registered: July 2009 |
Senior Member |
|
|
I like the topic too.
An idea that ghosts around my head is to use EMF to bridge abstraction
levels.
What do I mean?
Imagine you have some ECore model X with concepts/classes A, B, C.
Now you can create ECore objects of type A, B, C. Lets call them a1, a2,
b1, b2, c1, c2. Lets call the universe of these objects Y:
Imagine you want to express that the objects of type A are concepts
again. Something like annotating A as being a concept, whose instances
are concepts again.
This would lead to a model with a1 and a3 being concepts/classes. Lets
call this Model Z.
At first this sounds strange. But now think of X as the Ecore model of
UML. And of Y as a UML Model being entered
with the ecore editor generated from the UML.ecore:
X == UML.ecore
Y == My.uml
Now A is the concept of UML-class.
A=UML::Class
The UML model we entered has thus two UML classes a1 and a2. B and C could
be UML-model elements we cannot instantiate later, like package or
inheritance.
(references can be instantiated, and only this makes it really
interesting, but it makes it complex too)
In this scenario Z is the Ecore model generated from UML Model Y.
Z == My.ecore
At the moment, the information that UML-class corresponds to Ecore-class
and UML-reference to Ecore-reference is
hidden in the UML2Ecore importer.
By annotating a ECore model, telling which of its concepts, if
instantiated correspond to which ECore concept, we
could automate this step of bridging abstraction levels. The UML 2 Ecore
importer would then simply be an application of
these annotations.
Consequently, one could annotate any ECore based model, and then import
the ECore from this model. This would mean,
that we can have domain specific modeling languages. UML2 would just be
an overly complex example of such a domain specific
language. Simplifications or subsets of UML2 as well as extensions of
ECore would be other examples. By simply annotating
their ECore model with the information which of the concepts's instances
correspond to which ECore concept, we could
generalize what happens if a modeling language like UML is defined.
Best, Philipp
|
|
|
Goto Forum:
Current Time: Sat Apr 20 00:37:41 GMT 2024
Powered by FUDForum. Page generated in 0.03067 seconds |
] 
Search
Help
Register
Login
Home
