Home » Language IDEs » C / C++ IDE (CDT) » UML, CDT and JDT
|
| Re: UML, CDT and JDT [message #6743 is a reply to message #6724] |
Sat, 15 December 2001 00:36   |
 C4Eclipse Team
Messages: 65
Registered: July 2009 |
Member |
|
|
Gary,
Those aren't the only possibilities. Why not model-model translators fired by
change listeners? That should be better than a RefreshLocal, especially if
you meant a manually initiated one.
The CDT and JDT models are different because they were designed to do
different jobs. JDT's model is used for compilation, while CDT's was
built with a schema that is dynamically extensible by remote tools, the
parser being one such tool. (see http://64.38.235.23/tools/cdt/downloads/0.5.0/com.ibm.cpp.do cs.user/index.html
under "Extensibility")
Brian
Gary Coldren wrote:
> I haven't downloaded the CDT yet, but I was wondering if
> there is any coordination between CDT and JDT with regard
> to the meta model of the source code?
>
> Is it conceivable that someone could develop plugins that
> provide a UML Perspective for OO modeling, and have these
> UML plugins work seamlessly with either CDT or JDT?
>
> Would they integrate strictly at the level of file resources,
> with changes in one perspective requiring a refreshLocal
> call in the other, or would it require a higher level of
> integration, such as an abstract OO meta model that C++
> elements in CDT and Java elements in JDT extend?
|
|
|
| Re: UML, CDT and JDT [message #6750 is a reply to message #6743] |
Sat, 15 December 2001 13:23 |
Gary Coldren
Messages: 3
Registered: July 2009 |
Junior Member |
|
|
Yes, what I was trying to say (indirectly) is that refreshLocal is not an
adequate solution, even if triggered programmatically. There would have
to be some form of direct interaction between a UML toolkit and any
OO language toolkit.
I hadn't thought about model-model translators. That might work, but
it seems that would require a rather complex mapping of model elements.
If each toolkit vendor has his own proprietary meta model, then how
does one generically construct the model-model translators?
For example, if I am developing a language toolkit would I have to select
specific UML vendors I want to be compatible with and implement the
mapping from my meta model to theirs? Unless there is some generic
way to construct the model-model translation between any two
arbitrary toolkit vendors, this approach would seem to defeat the purpose
of a component software architecture.
As a consumer, I want to be able to pick my favorite UML toolkit and
my favorite language toolkit(s) and *know* that they will work seamlessly
together.
I know I may be dreaming, but it seems to me that one way to achieve
this would be for the Eclipse platform to provide a generic OO meta
model, with appropriate extension points, that all of the various toolkit
vendors can use.
Let me go further out on a limb and say that ideally, there would be no
need for translators or change notifications, because the language editors
and UML diagram editors are actually editing the *same* resources.
The UML and language toolkits are simply providing a different view,
or different perspective, of the same underlying meta model.
This model can be persisted as XML file resources, and the language
toolkits can provide incremental builders to generate source files for
compilation.
I know I'm doing a lot of hand-waving here. If you think I'm nuts don't
be afraid to say so. It won't be the first time :)
Gary
"Brian Thomson" <eclipsc@ca.ibm.com> wrote in message
news:3C1A9AF6.D2AE840F@ca.ibm.com...
> Gary,
>
> Those aren't the only possibilities. Why not model-model translators
fired by
> change listeners? That should be better than a RefreshLocal, especially
if
> you meant a manually initiated one.
>
> The CDT and JDT models are different because they were designed to do
> different jobs. JDT's model is used for compilation, while CDT's was
> built with a schema that is dynamically extensible by remote tools, the
> parser being one such tool. (see
http://64.38.235.23/tools/cdt/downloads/0.5.0/com.ibm.cpp.do cs.user/index.ht
ml
> under "Extensibility")
>
> Brian
>
>
> Gary Coldren wrote:
>
> > I haven't downloaded the CDT yet, but I was wondering if
> > there is any coordination between CDT and JDT with regard
> > to the meta model of the source code?
> >
> > Is it conceivable that someone could develop plugins that
> > provide a UML Perspective for OO modeling, and have these
> > UML plugins work seamlessly with either CDT or JDT?
> >
> > Would they integrate strictly at the level of file resources,
> > with changes in one perspective requiring a refreshLocal
> > call in the other, or would it require a higher level of
> > integration, such as an abstract OO meta model that C++
> > elements in CDT and Java elements in JDT extend?
>
|
|
| |
| Re: UML, CDT and JDT [message #6795 is a reply to message #6750] |
Tue, 18 December 2001 18:04 |
C4Eclipse Team
Messages: 65
Registered: July 2009 |
Member |
|
|
Gary,
You bring up a couple of points worth discussing.
The universal metamodel is an active research topic but not something I think
we know how to do today. Modelling tools and interface mappers and the like
would prefer models at the UML level, while language tools that compile and
navigate references and refactor code need more implementation detail.
If JDT and CDT were to converge, the result would probably resemble the
model used by the Datrix project
(ref. http://www.iro.umontreal.ca/labs/gelo/datrix/refmanuals/asgm odel-1.4.pdf)
more than the proposed JMI bindings
(ref. http://www.jcp.org/jsr/detail/40.jsp)
so I think we would stil have different models for different purposes, and
some path to synch them.
Clearly though, although one-size-fits-all may not be achievable, we don't
want N models either with 2**N pairwise converters.
Your other point is a little more subtle, when you talk about editors
editing the models and generating code to be compiled.
The Eclipse "model", to overuse a word, is the opposite of this.
The authoritative version of a project is always what is stored in the file
system, and models we work with are derived from that, not the other
way around. This principle allows users to use external tools to
generate or modify their source. To be consistent with
this direction, a modelling tool shouldn't update our C++ parse
tree (for example), it should generate source that we reparse.
Brian
Gary Coldren wrote:
> Yes, what I was trying to say (indirectly) is that refreshLocal is not an
> adequate solution, even if triggered programmatically. There would have
> to be some form of direct interaction between a UML toolkit and any
> OO language toolkit.
>
> I hadn't thought about model-model translators. That might work, but
> it seems that would require a rather complex mapping of model elements.
> If each toolkit vendor has his own proprietary meta model, then how
> does one generically construct the model-model translators?
>
> For example, if I am developing a language toolkit would I have to select
> specific UML vendors I want to be compatible with and implement the
> mapping from my meta model to theirs? Unless there is some generic
> way to construct the model-model translation between any two
> arbitrary toolkit vendors, this approach would seem to defeat the purpose
> of a component software architecture.
>
> As a consumer, I want to be able to pick my favorite UML toolkit and
> my favorite language toolkit(s) and *know* that they will work seamlessly
> together.
>
> I know I may be dreaming, but it seems to me that one way to achieve
> this would be for the Eclipse platform to provide a generic OO meta
> model, with appropriate extension points, that all of the various toolkit
> vendors can use.
>
> Let me go further out on a limb and say that ideally, there would be no
> need for translators or change notifications, because the language editors
> and UML diagram editors are actually editing the *same* resources.
> The UML and language toolkits are simply providing a different view,
> or different perspective, of the same underlying meta model.
>
> This model can be persisted as XML file resources, and the language
> toolkits can provide incremental builders to generate source files for
> compilation.
>
> I know I'm doing a lot of hand-waving here. If you think I'm nuts don't
> be afraid to say so. It won't be the first time :)
>
> Gary
|
|
|
| Re: UML, CDT and JDT [message #8751 is a reply to message #6795] |
Wed, 02 January 2002 13:30 |
Gary Coldren
Messages: 3
Registered: July 2009 |
Junior Member |
|
|
Hi Brian,
After a two week vacation I'm finding it hard to get my brain back in work
mode.
Coffee helps. Let me see if I can make sense of this.
As you say, clearly we don't want N models with 2**N pairwise converters.
Would
it make sense to have a core Eclipse OO model, and then say that any toolkit
that
supplies its own model or model extensions is responsible for mapping its
model
to the core model. Then you have N+1 models with N mappings. Any model
element
change notifications should then be expressed in terms of the core model.
Your point about using external editors is a good one. I hadn't thought
about that.
Personally, I have no problem with living within the IDE, but we should be
able
to coexist peacefully with those who insist on using vim and command line
build
scripts.
If we accept as a requirement that the model elements are persisted as
source
files, then we could say that it is the language toolkit's responsibility to
parse the
source files and populate the core model at start up. If a UML toolkit
required
its own persistent resources to supplement the source files, then you start
having
to do start up validation checks to make sure the UML model is synchronized
with
any changes made to the source files in an external editor. Yuk.
Another configuration that must be supported is to use a UML toolkit by
itself
without JDT or CDT. Then the UML tool has to take charge of the
persistence.
The more I think about this, the more I realize this is not a simple
problem. I'm not
sure what the final solution should be, but I think that it would be a shame
if CDT
and JDT diverge to the point where a semi-elegant solution is not possible.
Gary
"Brian Thomson" <eclipsc@ca.ibm.com> wrote in message
news:3C1F8510.1A8F1DFB@ca.ibm.com...
> Gary,
>
> You bring up a couple of points worth discussing.
>
> The universal metamodel is an active research topic but not something I
think
> we know how to do today. Modelling tools and interface mappers and the
like
> would prefer models at the UML level, while language tools that compile
and
> navigate references and refactor code need more implementation detail.
> If JDT and CDT were to converge, the result would probably resemble the
> model used by the Datrix project
> (ref.
http://www.iro.umontreal.ca/labs/gelo/datrix/refmanuals/asgm odel-1.4.pdf)
> more than the proposed JMI bindings
> (ref. http://www.jcp.org/jsr/detail/40.jsp)
> so I think we would stil have different models for different purposes, and
> some path to synch them.
> Clearly though, although one-size-fits-all may not be achievable, we don't
> want N models either with 2**N pairwise converters.
>
> Your other point is a little more subtle, when you talk about editors
> editing the models and generating code to be compiled.
> The Eclipse "model", to overuse a word, is the opposite of this.
> The authoritative version of a project is always what is stored in the
file
> system, and models we work with are derived from that, not the other
> way around. This principle allows users to use external tools to
> generate or modify their source. To be consistent with
> this direction, a modelling tool shouldn't update our C++ parse
> tree (for example), it should generate source that we reparse.
>
> Brian
>
>
> Gary Coldren wrote:
>
> > Yes, what I was trying to say (indirectly) is that refreshLocal is not
an
> > adequate solution, even if triggered programmatically. There would have
> > to be some form of direct interaction between a UML toolkit and any
> > OO language toolkit.
> >
> > I hadn't thought about model-model translators. That might work, but
> > it seems that would require a rather complex mapping of model elements.
> > If each toolkit vendor has his own proprietary meta model, then how
> > does one generically construct the model-model translators?
> >
> > For example, if I am developing a language toolkit would I have to
select
> > specific UML vendors I want to be compatible with and implement the
> > mapping from my meta model to theirs? Unless there is some generic
> > way to construct the model-model translation between any two
> > arbitrary toolkit vendors, this approach would seem to defeat the
purpose
> > of a component software architecture.
> >
> > As a consumer, I want to be able to pick my favorite UML toolkit and
> > my favorite language toolkit(s) and *know* that they will work
seamlessly
> > together.
> >
> > I know I may be dreaming, but it seems to me that one way to achieve
> > this would be for the Eclipse platform to provide a generic OO meta
> > model, with appropriate extension points, that all of the various
toolkit
> > vendors can use.
> >
> > Let me go further out on a limb and say that ideally, there would be no
> > need for translators or change notifications, because the language
editors
> > and UML diagram editors are actually editing the *same* resources.
> > The UML and language toolkits are simply providing a different view,
> > or different perspective, of the same underlying meta model.
> >
> > This model can be persisted as XML file resources, and the language
> > toolkits can provide incremental builders to generate source files for
> > compilation.
> >
> > I know I'm doing a lot of hand-waving here. If you think I'm nuts don't
> > be afraid to say so. It won't be the first time :)
> >
> > Gary
>
|
|
|
| Re: UML, CDT and JDT [message #10839 is a reply to message #8751] |
Mon, 07 January 2002 15:04 |
C4Eclipse Team
Messages: 65
Registered: July 2009 |
Member |
|
|
Gary Coldren wrote:
> As you say, clearly we don't want N models with 2**N pairwise
> converters. Would it make sense to have a core Eclipse OO model,
> and then say that any toolkit that supplies its own model or model
> extensions is responsible for mapping its model to the core model.
> Then you have N+1 models with N mappings. Any model
> element change notifications should then be expressed in terms of
> the core model.
That sounds reasonable, but there are a lot of details that need
elaboration. I think you assume the core model is UML based, for
some purposes that would clearly be suitable, but perhaps not for
program restructuring or slicing tools that could also legitimately
be (relatively) language independent.
I think rather than starting by defining the technology, we
should start with the use-cases you want to support.
In a modelling tool, for example, would you really want
updates to your model to be automatic, or should they be triggered
by an explicit RE action on the part of the user?
> If we accept as a requirement that the model elements are persisted as
> source files, then we could say that it is the language toolkit's
> responsibility to parse the source files and populate the core model
> at start up. If a UML toolkit required its own persistent resources
> to supplement the source files, then you start having to do
> start up validation checks to make sure the UML model is
> synchronized with any changes made to the source files in
> an external editor. Yuk.
That maybe came out more strongly than it should have.
Multiple copies and representations are fine as long as we
don't get confused about their roles. Sometimes we make
copies in order to cache information - the Eclipse navigator
does this in its model of filesystem artifacts, which is why you
might need to "Refresh from Local" after an external change.
Sometimes we make working copies that we modify and then
save, replacing the original, as in editors.
Our C/C++ language models are of the cache variety,
they represent the source file contents and are read-only
by tools.
But, it wouldn't be unreasonable for a tool to take a copy of
a (portion of?) our model, or of a derived UML model,
modify it, and generate source based
on the result. Until you commit those changes back to the
source files, though, our original model shouldn't change.
I would think that a UML toolkit will represent design
artifacts that can't be inferred from the sources, and
so will necessarily require additional persistence
mechanisms, is this not true in the cases you
are considering?
It might even make sense to separately persist
a working copy of the model, if forcing a
user to update source before they are ready
would be unreasonable.
Again though, this decision should be driven by use-cases.
Brian
|
|
|
Goto Forum:
Current Time: Fri Dec 27 10:10:50 GMT 2024
Powered by FUDForum. Page generated in 0.07020 seconds |
] 
Search
Help
Register
Login
Home
