| Feedback [message #561340] |
Tue, 27 November 2007 15:38 |
 Kenn Hussey
Messages: 1620
Registered: July 2009 |
Senior Member |
|
|
First of all, I want to thank you for this proposal. Coming from a strong
modeling background, I gladly welcome contributions that might advance the
state of the art with respect to MDD; it's initiatives like this that will
eventually make MDA (Model Driven Architecture) a reality.
Having said that, one of the most important questions to ask when a new
Eclipse (sub)project is proposed is "How will this benefit the Eclipse
community?". There's no doubt that the perspective and practical experience
you bring will benefit Eclipse - only through diversity can the community
truly grow. But looking at the proposal, a number of questions come to mind.
- The obvious initial question, as others have remarked, is why this project
isn't proposed as a subproject of the Modeling project. If you truly believe
in MDD, as we in the Modeling project do, why not work with us to help build
a better tooling landscape for modeling users? Given that it's already
difficult to select from among the myriad of projects and components
available at Eclipse, how do you think adding another set of potentially
"redundant" components will benefit the Eclipse community?
- You mention that the current product uses a subset of the UML2
functionalities to limit the scope of modeling to what is necessary in the
context of MDD. I'm curious as to what this subset is, and how it is
different from the subset offered by MOF (a portion of which - EMOF - is
effectively implemented already by Ecore in the EMF project). Note that UML
as a language is, by design, quite broad and diverse, but there is a
standard mechanism for subsetting it to suit specific domains (MDD could be
considered a "domain"), i.e. via profiles. Did you consider using this
approach?
- It's interesting to hear that standards bodies have been using this
product to deliver standard specifications and APIs; subprojects/components
of the Modeling project (notably EMF, UML2 and OCL) have also been used over
the past few years to evolve (OMG) standards, e.g. UML, MOF, SPEM, SysML,
SBVR. I would argue that the community of standards authors is quite
different from that of "general" MDD users; is Tigerstripe really intended
to focus more on the former?
Taking a look at the current capabilities of Tigerstripe, there are a number
of obvious overlaps with subprojects/components in Modeling:
- graphical editor for class or instance diagrams (UML2 Tools)
- model scoping capabilities (EMF, UML2)
- strong, flexible generation engine (JET, M2T, TMF)
- headless model-driven generation (JET, M2T, TMF)
It might perhaps be easier to understand/evaluate the proposal if you could
explain how what you are offering in Tigerstripe is different and how this
difference will benefit the user community.
Finally, the proposal states that documentation will made available in an
effort to further bootstrap the growth of the existing user community.
Perhaps the best way to grow your community would be to leverage the
existing community being built by the Modeling project. I'm sure that many
of us were involved in building similar frameworks before the advent of the
Modeling project a couple of year ago. Since then, many of us have abandoned
our proprietary solutions in favor of adopting and evolving what we feel is
a compelling vision of what modeling can be...
Kenn (MDT project lead)
|
|
|
Powered by
FUDForum. Page generated in 0.02499 seconds
] 
Search
Help
Register
Login
Home
