Home » Archived » Tigerstripe » Feedback
| Feedback [message #2416] |
Tue, 27 November 2007 15:38  |
Eclipse User |
|
|
|
Originally posted by: Kenn.Hussey.embarcadero.com
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)
|
|
| |
| Re: Feedback [message #2595 is a reply to message #2476] |
Tue, 27 November 2007 20:55  |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Steve,
Comments below.
Steve Jerman wrote:
> I thought I'd throw in a few comments as a user of this tool.... I
> should note that these are my comments and Eric may disagree :)
>
> Tigerstripe Workbench is not a general purpose UML modeling tool. It
> is a tool focused squarely (at least in my opinion) on Information
> Modeling.
What exactly does that mean? What's Information Modeling and how is it
different from Data Modeling or General Purpose Modeling?
> It does include the ability to draw class and instance diagrams, but
> it also includes some pieces of functionality not in UML, specifically
> the concept of 'facets' and things like 'binary' models.
Are these parts of the model or just aspects of the tools that support
them. Is this the reason for using neither UML nor Ecore?
> More importantly, it is designed to suit the workflow of
> developing/managing a large scale information model and generating
> artifacts based on a subset of it.
One could ask the question, why design a model so big you need to subset it?
>
> The tooling originated in work on model based interfaces in the
> telecom Service Provider standards community, but is not really
> specific to that vertical..
Where do you see the applicability boundaries for it?
>
> In Cisco's case, Tigerstipe has replaced a long and tortuous tool
> chain based on a combination of Commercial and open source tools
> (including home brew based on EMF/UML2). We use it for modeling
> networking technologies and services and then generating management
> interfaces for them.
Are these user interfaces (tools) of programming APIs (code)?
> Our information model is used by multiple groups in Cisco for
> different products and managing the use of different portions of the
> model by these different groups and keeping everything under control
> has been a rather painful exercise for us in the past.
>
> From a technical point of view, as people say there are now
> better/additional components available from the modeling project and
> Eric is committing to move towards them.
As I asked the other guys, I'd like to understand the reasons for not
using UML2 (too complex?) or Ecore (not complete?) and what would need
to change to make them acceptable in the future...
>
> Regards
> Steve
|
|
|
| Re: Feedback [message #4463 is a reply to message #2416] |
Wed, 28 November 2007 18:16 |
| Eclipse User |
|
|
|
Originally posted by: dstrombo.cisco.com
Hi Kenn,
Thank you for your considered thoughts on the Tigerstripe proposal.
Initially the Tigerstripe team at Cisco had hoped to be invited to
participate in the Modeling Project. But it seems that the focus there is
on frameworks and not tools. Also, the goals of the Modeling Project are
excellent, but the timeframe is different from ours.
In the course of developing Tigerstripe, we used what was available from
EMF and GMF at the times that we were making design decisions. The result
is that all the latest features are not used. There is a dynamic element
of how required features evolve into standards that needs to be factored
in. That challenge is not specific to Tigerstripe, but is a general
problem that the Eclipse Project will need to come to terms with.
That being said, if there is something in Tigerstripe that the Modeling
Project likes then we'd be delighted to contribute those to any framework.
Tigerstripe is not set up as an alternative to or in competition with any
of the excellent frameworks that the Modeling Project offers. In another
comment I made the case that Eclipse should embrace diversity of modeling
styles and tools. Tigerstripe is an example of a tool that is good for
UML2-data-modeling-to-code-generation, that allows certain extensions. I
can see how you'd want to standardize platforms, but I don't think you
should attempt to standardize on one tool or one modeling approach.
That some contributors have been able and willing to help build frameworks
is commendable. That these frameworks could evolve to do more and more is
a good thing. That the frameworks could even become an integrated
modeling tool would prove that the frameworks integrate so that's another
good thing.
I don't understand those same contributors' concern about Tigerstripe.
Why not allow innovation in a related project that makes use of (some of)
the Modeling frameworks? I think that allowing concern about how a
plethora of projects is causing confusion among Eclipse users to stop good
efforts or limit innovation would be a shame.
Best Regards,
Doug Strombom
|
|
|
| Re: Feedback [message #4603 is a reply to message #4463] |
Wed, 28 November 2007 22:03 |
| Eclipse User |
|
|
|
Originally posted by: Kenn.Hussey.embarcadero.com
Doug,
The Modeling project isn't focused only on frameworks - the Model
Development Tools (MDT) subproject, for example, provides a growing number
of end-user consumable UML diagram editors - although admittedly most of the
mature subprojects and components in Modeling are currently
infrastructure-related. I'm not sure which timeframe you're making reference
to, but the existence of end-user tools in Modeling has been limited only by
the lack contributors willing/able to build them.
I'm all for innovation and diversity, and as I've said before, we need more
of it - not less - if the Eclipse ecosystem is to contnue to grow and be
successful. Now that the scope of the Tigerstripe proposal has been
narrowed, I suspect the majority of concerns from Modeling project
contributors will have been addressed. I'm looking forward to opportunities
to collaborate as your project moves forward.
Kenn
"Doug Strombom" <dstrombo@cisco.com> wrote in message
news:6fcb1847cb26abae61f5a8f20553a75d$1@www.eclipse.org...
> Hi Kenn,
>
> Thank you for your considered thoughts on the Tigerstripe proposal.
>
> Initially the Tigerstripe team at Cisco had hoped to be invited to
> participate in the Modeling Project. But it seems that the focus there is
> on frameworks and not tools. Also, the goals of the Modeling Project are
> excellent, but the timeframe is different from ours.
> In the course of developing Tigerstripe, we used what was available from
> EMF and GMF at the times that we were making design decisions. The result
> is that all the latest features are not used. There is a dynamic element
> of how required features evolve into standards that needs to be factored
> in. That challenge is not specific to Tigerstripe, but is a general
> problem that the Eclipse Project will need to come to terms with.
> That being said, if there is something in Tigerstripe that the Modeling
> Project likes then we'd be delighted to contribute those to any framework.
>
> Tigerstripe is not set up as an alternative to or in competition with any
> of the excellent frameworks that the Modeling Project offers. In another
> comment I made the case that Eclipse should embrace diversity of modeling
> styles and tools. Tigerstripe is an example of a tool that is good for
> UML2-data-modeling-to-code-generation, that allows certain extensions. I
> can see how you'd want to standardize platforms, but I don't think you
> should attempt to standardize on one tool or one modeling approach.
>
> That some contributors have been able and willing to help build frameworks
> is commendable. That these frameworks could evolve to do more and more is
> a good thing. That the frameworks could even become an integrated
> modeling tool would prove that the frameworks integrate so that's another
> good thing.
> I don't understand those same contributors' concern about Tigerstripe.
> Why not allow innovation in a related project that makes use of (some of)
> the Modeling frameworks? I think that allowing concern about how a
> plethora of projects is causing confusion among Eclipse users to stop good
> efforts or limit innovation would be a shame.
>
> Best Regards,
> Doug Strombom
>
>
>
>
|
|
|
| Re: Feedback [message #4672 is a reply to message #4603] |
Thu, 29 November 2007 01:58 |
| Eclipse User |
|
|
|
Originally posted by: dstrombo.cisco.com
Apologies for repeating the mistake about MDT. I hadn't yet seen your
comment to Eric along the same lines.
Best Regards,
- Doug
|
|
|
| Re: Feedback [message #4740 is a reply to message #4672] |
Thu, 29 November 2007 13:54 |
| Eclipse User |
|
|
|
Originally posted by: Kenn.Hussey.embarcadero.com
No problem.
So, given that you haven't answered any of my specific questions about the
differences between the capabilities of Tigerstripe and the components in
Modeling, any chance you or Eric could comment on how/when you see
Tigerstripe migrating its "non-standard" components to the latest stable
components from Modeling? Would this include adopting the UML2 component of
MDT? Given that the UML2 component existed (as its own project) when
Tigerstripe was developed, I'm curious as to why it wasn't used in the first
place. Any feedback you can offer in this regard would no doubt be a benefit
to the growing community of consumers that are building (or have built)
robust modeling applications based on UML2.
Kenn
"Doug Strombom" <dstrombo@cisco.com> wrote in message
news:04f29e2bdaebbf2d696228ce9b25d503$1@www.eclipse.org...
> Apologies for repeating the mistake about MDT. I hadn't yet seen your
> comment to Eric along the same lines.
> Best Regards,
> - Doug
>
|
|
|
| Re: Feedback [message #4809 is a reply to message #4740] |
Thu, 29 November 2007 15:11 |
 Dave Carlson
Messages: 402
Registered: July 2009 |
Senior Member |
|
|
Well, it seems that I'm a bit late to the party :-) I came in to review
this proposal and found quite a flurry of activity. I won't duplicate other
comments, but will add a few thoughts from my tool development perspective.
I found Steve Jerman's comments interesting about tigerstripe's user
profile. Much of my current work has nearly identical tool requirements,
but focused on specifying and implementing HL7 healthcare standards. We
have very large information models, many different user groups that need
perspectives on subsets of the overall domain model, modeling users who are
not toolsmiths but only want/need to capture their clinical knowledge of
healthcare, a tool that enforces our methodology, etc. And we follow a
model-driven approach to generate XML Schemas and other SOA artifacts.
However, I am pushing for compliance with UML2 in all of our modeling
artifacts. Given that tigerstipe is not using UML2, then it is of no
interest to me, even though our goals are nearly identical. For our end
users, I am packaging a distribution that includes only the Eclipse and
modeling features that are needed (for now, only the UML2Tools class diagram
editor, EMF validation framework, the Web Tools XML editors, etc). By
insisting on UML spec compliance in our artifacts, other downstream users
who want to implement these message specs can use other UML tools of their
choice (IBM RSA, Sparx EA, etc). This is very important for our user
ecosystem.
Kenn has already emphasized that UML2Tools is not intended to deliver only
frameworks, but end-user model editors. From my selfish perspective, I
would *very* much welcome your particiapation in testing and contributing to
the completion of the diagram editors that you need, so that we all benefit.
You do not need to include "all of UML", but choose to package only the
model editors needed by your users, e.g. class diagram and object diagram.
For my healthcare users, I am extending these editors with a UML profile for
HL7, customized property tab editors that guide/enforce our methodology,
related wizards, model validation constraints, etc.
Apparently tigerstipe includes capability for publishing documentation of
the model specifications. We have a *huge* need for this in the HL7
healthcare standard specs. If we could define an Eclipse modeling component
for publishing specs from UML2 artifacts, then I would be interested in
contributing to that work. But not interested if it based on non-UML
models.
I found the tigerstipe goals to be very interesting and relevant. But my
preference is for tigerstripe to define its components (based on UML2
artifacts) that may by used and assembled into developer workbenches for
other non-telcom user groups, not a single specialized workbench for
telecom.
Best Regards,
Dave Carlson
www.xmlmodeling.com
|
|
|
| Re: Feedback [message #4878 is a reply to message #4740] |
Thu, 29 November 2007 16:37 |
Eric Dillon
Messages: 103
Registered: July 2009 |
Senior Member |
|
|
Hi Kenn,
Our current use of the UML2 component is on the boundaries: for
import/export into the internal
Tigerstripe representation. In fact, Tigerstripe manipulates UML2 models +
UML2 profiles, they are just not in the format defined in the UML2
component.
There was several reasons why we didn't adopt UML2 component at the time (3y
ago). Not all of them were based on technical considerations as always when
putting initial prototype together, one of them being the storage
requirements (1 file per element in the model for finegrain versioning
reasons), large number of diagrams, for example.
I'm looking in how/when we can migrate to using UML2 at the core of
Tigerstripe (not at the boundaries only as it is now). One of the key things
to take into account is our existing users. More than the integration of the
component, the migration path is what needs to be addressed. However, it IS
a requirement we have as we want to integrate OCL and allow more operations
directly thru an EMF-like API. I need to get back to the latest UML2
component version and cross-check this with of our requirements.
What is sure is that it will need to be phazed transition to avoid problems
for current users.
Now, I don't claim I understand all the details of the UML2 component. So...
I'll come back for advice at least :-)
Eric
"Kenn Hussey" <Kenn.Hussey@embarcadero.com> wrote in message
news:fimga8$26g$1@build.eclipse.org...
> No problem.
>
> So, given that you haven't answered any of my specific questions about the
> differences between the capabilities of Tigerstripe and the components in
> Modeling, any chance you or Eric could comment on how/when you see
> Tigerstripe migrating its "non-standard" components to the latest stable
> components from Modeling? Would this include adopting the UML2 component
> of MDT? Given that the UML2 component existed (as its own project) when
> Tigerstripe was developed, I'm curious as to why it wasn't used in the
> first place. Any feedback you can offer in this regard would no doubt be a
> benefit to the growing community of consumers that are building (or have
> built) robust modeling applications based on UML2.
>
> Kenn
>
> "Doug Strombom" <dstrombo@cisco.com> wrote in message
> news:04f29e2bdaebbf2d696228ce9b25d503$1@www.eclipse.org...
>> Apologies for repeating the mistake about MDT. I hadn't yet seen your
>> comment to Eric along the same lines.
>> Best Regards,
>> - Doug
>>
>
>
|
|
|
| Re: Feedback [message #4948 is a reply to message #4809] |
Thu, 29 November 2007 16:45 |
Eric Dillon
Messages: 103
Registered: July 2009 |
Senior Member |
|
|
Hi Dave,
see some comments inline.
Regards,
Eric
"Dave Carlson" <dcarlson@xmlmodeling.com> wrote in message
news:fimkq9$g4g$1@build.eclipse.org...
> Well, it seems that I'm a bit late to the party :-) I came in to review
> this proposal and found quite a flurry of activity. I won't duplicate
> other comments, but will add a few thoughts from my tool development
> perspective.
>
> I found Steve Jerman's comments interesting about tigerstripe's user
> profile. Much of my current work has nearly identical tool requirements,
> but focused on specifying and implementing HL7 healthcare standards. We
> have very large information models, many different user groups that need
> perspectives on subsets of the overall domain model, modeling users who
> are not toolsmiths but only want/need to capture their clinical knowledge
> of healthcare, a tool that enforces our methodology, etc. And we follow a
> model-driven approach to generate XML Schemas and other SOA artifacts.
>
> However, I am pushing for compliance with UML2 in all of our modeling
> artifacts. Given that tigerstipe is not using UML2, then it is of no
> interest to me, even though our goals are nearly identical. For our end
> users, I am packaging a distribution that includes only the Eclipse and
> modeling features that are needed (for now, only the UML2Tools class
> diagram editor, EMF validation framework, the Web Tools XML editors, etc).
> By insisting on UML spec compliance in our artifacts, other downstream
> users who want to implement these message specs can use other UML tools of
> their choice (IBM RSA, Sparx EA, etc). This is very important for our
> user ecosystem.
I need to clarify that Tigerstripe uses a subset of the UML2 modeling
standard, and only uses the UML2 component from MDT at the boundaries to
import/export from/to other UML2 modeling tools.
For example, in Cisco's case, the model came from a pure UML modeling
commercial environment and is now maintained
in Tigerstripe. There was no loss of information in the conversion, simply a
change of how the actual model is saved on disk
or more precisely in a SVN repository.
>
> Kenn has already emphasized that UML2Tools is not intended to deliver only
> frameworks, but end-user model editors. From my selfish perspective, I
> would *very* much welcome your particiapation in testing and contributing
> to the completion of the diagram editors that you need, so that we all
> benefit. You do not need to include "all of UML", but choose to package
> only the model editors needed by your users, e.g. class diagram and object
> diagram. For my healthcare users, I am extending these editors with a UML
> profile for HL7, customized property tab editors that guide/enforce our
> methodology, related wizards, model validation constraints, etc.
It seems like we have overlapping requirements, and we would like to migrate
to UML2, it sounds we should
be exploring some possible collaboration?
>
> Apparently tigerstipe includes capability for publishing documentation of
> the model specifications. We have a *huge* need for this in the HL7
> healthcare standard specs. If we could define an Eclipse modeling
> component for publishing specs from UML2 artifacts, then I would be
> interested in contributing to that work. But not interested if it based
> on non-UML models.
See my comment above about UML.
>
> I found the tigerstipe goals to be very interesting and relevant. But my
> preference is for tigerstripe to define its components (based on UML2
> artifacts) that may by used and assembled into developer workbenches for
> other non-telcom user groups, not a single specialized workbench for
> telecom.
>
> Best Regards,
> Dave Carlson
> www.xmlmodeling.com
>
>
|
|
|
| Re: Feedback [message #5087 is a reply to message #2416] |
Mon, 03 December 2007 16:10 |
| Eclipse User |
|
|
|
Originally posted by: gunther.walther.nsn.com
Kenn Hussey wrote:
> 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.
One of the potential benefits to the Eclipse Community would be that with
Tigerstripe being the current de-facto modeling tool for OSS/J and MTOSI
teams the tool would bring a lot of interest from the whole
Telecommunication industry with it.
> 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...
Not sure it is about growing the Tigerstripe community. This could be done
elsewhere. The tool reduced the work e.g. the Order Management API by 50%
and this is enough for us to think it is valuable enough to contribute to
it. But imho this proposal is more about getting the synergies between the
communities realized.
|
|
| |
| Re: Feedback [message #561460 is a reply to message #2476] |
Tue, 27 November 2007 20:55 |
Ed Merks
Messages: 33264
Registered: July 2009 |
Senior Member |
|
|
Steve,
Comments below.
Steve Jerman wrote:
> I thought I'd throw in a few comments as a user of this tool.... I
> should note that these are my comments and Eric may disagree :)
>
> Tigerstripe Workbench is not a general purpose UML modeling tool. It
> is a tool focused squarely (at least in my opinion) on Information
> Modeling.
What exactly does that mean? What's Information Modeling and how is it
different from Data Modeling or General Purpose Modeling?
> It does include the ability to draw class and instance diagrams, but
> it also includes some pieces of functionality not in UML, specifically
> the concept of 'facets' and things like 'binary' models.
Are these parts of the model or just aspects of the tools that support
them. Is this the reason for using neither UML nor Ecore?
> More importantly, it is designed to suit the workflow of
> developing/managing a large scale information model and generating
> artifacts based on a subset of it.
One could ask the question, why design a model so big you need to subset it?
>
> The tooling originated in work on model based interfaces in the
> telecom Service Provider standards community, but is not really
> specific to that vertical..
Where do you see the applicability boundaries for it?
>
> In Cisco's case, Tigerstipe has replaced a long and tortuous tool
> chain based on a combination of Commercial and open source tools
> (including home brew based on EMF/UML2). We use it for modeling
> networking technologies and services and then generating management
> interfaces for them.
Are these user interfaces (tools) of programming APIs (code)?
> Our information model is used by multiple groups in Cisco for
> different products and managing the use of different portions of the
> model by these different groups and keeping everything under control
> has been a rather painful exercise for us in the past.
>
> From a technical point of view, as people say there are now
> better/additional components available from the modeling project and
> Eric is committing to move towards them.
As I asked the other guys, I'd like to understand the reasons for not
using UML2 (too complex?) or Ecore (not complete?) and what would need
to change to make them acceptable in the future...
>
> Regards
> Steve
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Feedback [message #561655 is a reply to message #2416] |
Wed, 28 November 2007 18:16 |
| Eclipse User |
|
|
|
Originally posted by: dstrombo.cisco.com
Hi Kenn,
Thank you for your considered thoughts on the Tigerstripe proposal.
Initially the Tigerstripe team at Cisco had hoped to be invited to
participate in the Modeling Project. But it seems that the focus there is
on frameworks and not tools. Also, the goals of the Modeling Project are
excellent, but the timeframe is different from ours.
In the course of developing Tigerstripe, we used what was available from
EMF and GMF at the times that we were making design decisions. The result
is that all the latest features are not used. There is a dynamic element
of how required features evolve into standards that needs to be factored
in. That challenge is not specific to Tigerstripe, but is a general
problem that the Eclipse Project will need to come to terms with.
That being said, if there is something in Tigerstripe that the Modeling
Project likes then we'd be delighted to contribute those to any framework.
Tigerstripe is not set up as an alternative to or in competition with any
of the excellent frameworks that the Modeling Project offers. In another
comment I made the case that Eclipse should embrace diversity of modeling
styles and tools. Tigerstripe is an example of a tool that is good for
UML2-data-modeling-to-code-generation, that allows certain extensions. I
can see how you'd want to standardize platforms, but I don't think you
should attempt to standardize on one tool or one modeling approach.
That some contributors have been able and willing to help build frameworks
is commendable. That these frameworks could evolve to do more and more is
a good thing. That the frameworks could even become an integrated
modeling tool would prove that the frameworks integrate so that's another
good thing.
I don't understand those same contributors' concern about Tigerstripe.
Why not allow innovation in a related project that makes use of (some of)
the Modeling frameworks? I think that allowing concern about how a
plethora of projects is causing confusion among Eclipse users to stop good
efforts or limit innovation would be a shame.
Best Regards,
Doug Strombom
|
|
|
| Re: Feedback [message #561687 is a reply to message #4463] |
Wed, 28 November 2007 22:03 |
Kenn Hussey
Messages: 1620
Registered: July 2009 |
Senior Member |
|
|
Doug,
The Modeling project isn't focused only on frameworks - the Model
Development Tools (MDT) subproject, for example, provides a growing number
of end-user consumable UML diagram editors - although admittedly most of the
mature subprojects and components in Modeling are currently
infrastructure-related. I'm not sure which timeframe you're making reference
to, but the existence of end-user tools in Modeling has been limited only by
the lack contributors willing/able to build them.
I'm all for innovation and diversity, and as I've said before, we need more
of it - not less - if the Eclipse ecosystem is to contnue to grow and be
successful. Now that the scope of the Tigerstripe proposal has been
narrowed, I suspect the majority of concerns from Modeling project
contributors will have been addressed. I'm looking forward to opportunities
to collaborate as your project moves forward.
Kenn
"Doug Strombom" <dstrombo@cisco.com> wrote in message
news:6fcb1847cb26abae61f5a8f20553a75d$1@www.eclipse.org...
> Hi Kenn,
>
> Thank you for your considered thoughts on the Tigerstripe proposal.
>
> Initially the Tigerstripe team at Cisco had hoped to be invited to
> participate in the Modeling Project. But it seems that the focus there is
> on frameworks and not tools. Also, the goals of the Modeling Project are
> excellent, but the timeframe is different from ours.
> In the course of developing Tigerstripe, we used what was available from
> EMF and GMF at the times that we were making design decisions. The result
> is that all the latest features are not used. There is a dynamic element
> of how required features evolve into standards that needs to be factored
> in. That challenge is not specific to Tigerstripe, but is a general
> problem that the Eclipse Project will need to come to terms with.
> That being said, if there is something in Tigerstripe that the Modeling
> Project likes then we'd be delighted to contribute those to any framework.
>
> Tigerstripe is not set up as an alternative to or in competition with any
> of the excellent frameworks that the Modeling Project offers. In another
> comment I made the case that Eclipse should embrace diversity of modeling
> styles and tools. Tigerstripe is an example of a tool that is good for
> UML2-data-modeling-to-code-generation, that allows certain extensions. I
> can see how you'd want to standardize platforms, but I don't think you
> should attempt to standardize on one tool or one modeling approach.
>
> That some contributors have been able and willing to help build frameworks
> is commendable. That these frameworks could evolve to do more and more is
> a good thing. That the frameworks could even become an integrated
> modeling tool would prove that the frameworks integrate so that's another
> good thing.
> I don't understand those same contributors' concern about Tigerstripe.
> Why not allow innovation in a related project that makes use of (some of)
> the Modeling frameworks? I think that allowing concern about how a
> plethora of projects is causing confusion among Eclipse users to stop good
> efforts or limit innovation would be a shame.
>
> Best Regards,
> Doug Strombom
>
>
>
>
|
|
|
| Re: Feedback [message #561709 is a reply to message #4603] |
Thu, 29 November 2007 01:58 |
| Eclipse User |
|
|
|
Originally posted by: dstrombo.cisco.com
Apologies for repeating the mistake about MDT. I hadn't yet seen your
comment to Eric along the same lines.
Best Regards,
- Doug
|
|
| |
| Re: Feedback [message #561745 is a reply to message #4740] |
Thu, 29 November 2007 15:11 |
Dave Carlson
Messages: 402
Registered: July 2009 |
Senior Member |
|
|
Well, it seems that I'm a bit late to the party :-) I came in to review
this proposal and found quite a flurry of activity. I won't duplicate other
comments, but will add a few thoughts from my tool development perspective.
I found Steve Jerman's comments interesting about tigerstripe's user
profile. Much of my current work has nearly identical tool requirements,
but focused on specifying and implementing HL7 healthcare standards. We
have very large information models, many different user groups that need
perspectives on subsets of the overall domain model, modeling users who are
not toolsmiths but only want/need to capture their clinical knowledge of
healthcare, a tool that enforces our methodology, etc. And we follow a
model-driven approach to generate XML Schemas and other SOA artifacts.
However, I am pushing for compliance with UML2 in all of our modeling
artifacts. Given that tigerstipe is not using UML2, then it is of no
interest to me, even though our goals are nearly identical. For our end
users, I am packaging a distribution that includes only the Eclipse and
modeling features that are needed (for now, only the UML2Tools class diagram
editor, EMF validation framework, the Web Tools XML editors, etc). By
insisting on UML spec compliance in our artifacts, other downstream users
who want to implement these message specs can use other UML tools of their
choice (IBM RSA, Sparx EA, etc). This is very important for our user
ecosystem.
Kenn has already emphasized that UML2Tools is not intended to deliver only
frameworks, but end-user model editors. From my selfish perspective, I
would *very* much welcome your particiapation in testing and contributing to
the completion of the diagram editors that you need, so that we all benefit.
You do not need to include "all of UML", but choose to package only the
model editors needed by your users, e.g. class diagram and object diagram.
For my healthcare users, I am extending these editors with a UML profile for
HL7, customized property tab editors that guide/enforce our methodology,
related wizards, model validation constraints, etc.
Apparently tigerstipe includes capability for publishing documentation of
the model specifications. We have a *huge* need for this in the HL7
healthcare standard specs. If we could define an Eclipse modeling component
for publishing specs from UML2 artifacts, then I would be interested in
contributing to that work. But not interested if it based on non-UML
models.
I found the tigerstipe goals to be very interesting and relevant. But my
preference is for tigerstripe to define its components (based on UML2
artifacts) that may by used and assembled into developer workbenches for
other non-telcom user groups, not a single specialized workbench for
telecom.
Best Regards,
Dave Carlson
www.xmlmodeling.com
|
|
|
| Re: Feedback [message #561765 is a reply to message #4740] |
Thu, 29 November 2007 16:37 |
Eric Dillon
Messages: 103
Registered: July 2009 |
Senior Member |
|
|
Hi Kenn,
Our current use of the UML2 component is on the boundaries: for
import/export into the internal
Tigerstripe representation. In fact, Tigerstripe manipulates UML2 models +
UML2 profiles, they are just not in the format defined in the UML2
component.
There was several reasons why we didn't adopt UML2 component at the time (3y
ago). Not all of them were based on technical considerations as always when
putting initial prototype together, one of them being the storage
requirements (1 file per element in the model for finegrain versioning
reasons), large number of diagrams, for example.
I'm looking in how/when we can migrate to using UML2 at the core of
Tigerstripe (not at the boundaries only as it is now). One of the key things
to take into account is our existing users. More than the integration of the
component, the migration path is what needs to be addressed. However, it IS
a requirement we have as we want to integrate OCL and allow more operations
directly thru an EMF-like API. I need to get back to the latest UML2
component version and cross-check this with of our requirements.
What is sure is that it will need to be phazed transition to avoid problems
for current users.
Now, I don't claim I understand all the details of the UML2 component. So...
I'll come back for advice at least :-)
Eric
"Kenn Hussey" <Kenn.Hussey@embarcadero.com> wrote in message
news:fimga8$26g$1@build.eclipse.org...
> No problem.
>
> So, given that you haven't answered any of my specific questions about the
> differences between the capabilities of Tigerstripe and the components in
> Modeling, any chance you or Eric could comment on how/when you see
> Tigerstripe migrating its "non-standard" components to the latest stable
> components from Modeling? Would this include adopting the UML2 component
> of MDT? Given that the UML2 component existed (as its own project) when
> Tigerstripe was developed, I'm curious as to why it wasn't used in the
> first place. Any feedback you can offer in this regard would no doubt be a
> benefit to the growing community of consumers that are building (or have
> built) robust modeling applications based on UML2.
>
> Kenn
>
> "Doug Strombom" <dstrombo@cisco.com> wrote in message
> news:04f29e2bdaebbf2d696228ce9b25d503$1@www.eclipse.org...
>> Apologies for repeating the mistake about MDT. I hadn't yet seen your
>> comment to Eric along the same lines.
>> Best Regards,
>> - Doug
>>
>
>
|
|
|
| Re: Feedback [message #561785 is a reply to message #4809] |
Thu, 29 November 2007 16:45 |
Eric Dillon
Messages: 103
Registered: July 2009 |
Senior Member |
|
|
Hi Dave,
see some comments inline.
Regards,
Eric
"Dave Carlson" <dcarlson@xmlmodeling.com> wrote in message
news:fimkq9$g4g$1@build.eclipse.org...
> Well, it seems that I'm a bit late to the party :-) I came in to review
> this proposal and found quite a flurry of activity. I won't duplicate
> other comments, but will add a few thoughts from my tool development
> perspective.
>
> I found Steve Jerman's comments interesting about tigerstripe's user
> profile. Much of my current work has nearly identical tool requirements,
> but focused on specifying and implementing HL7 healthcare standards. We
> have very large information models, many different user groups that need
> perspectives on subsets of the overall domain model, modeling users who
> are not toolsmiths but only want/need to capture their clinical knowledge
> of healthcare, a tool that enforces our methodology, etc. And we follow a
> model-driven approach to generate XML Schemas and other SOA artifacts.
>
> However, I am pushing for compliance with UML2 in all of our modeling
> artifacts. Given that tigerstipe is not using UML2, then it is of no
> interest to me, even though our goals are nearly identical. For our end
> users, I am packaging a distribution that includes only the Eclipse and
> modeling features that are needed (for now, only the UML2Tools class
> diagram editor, EMF validation framework, the Web Tools XML editors, etc).
> By insisting on UML spec compliance in our artifacts, other downstream
> users who want to implement these message specs can use other UML tools of
> their choice (IBM RSA, Sparx EA, etc). This is very important for our
> user ecosystem.
I need to clarify that Tigerstripe uses a subset of the UML2 modeling
standard, and only uses the UML2 component from MDT at the boundaries to
import/export from/to other UML2 modeling tools.
For example, in Cisco's case, the model came from a pure UML modeling
commercial environment and is now maintained
in Tigerstripe. There was no loss of information in the conversion, simply a
change of how the actual model is saved on disk
or more precisely in a SVN repository.
>
> Kenn has already emphasized that UML2Tools is not intended to deliver only
> frameworks, but end-user model editors. From my selfish perspective, I
> would *very* much welcome your particiapation in testing and contributing
> to the completion of the diagram editors that you need, so that we all
> benefit. You do not need to include "all of UML", but choose to package
> only the model editors needed by your users, e.g. class diagram and object
> diagram. For my healthcare users, I am extending these editors with a UML
> profile for HL7, customized property tab editors that guide/enforce our
> methodology, related wizards, model validation constraints, etc.
It seems like we have overlapping requirements, and we would like to migrate
to UML2, it sounds we should
be exploring some possible collaboration?
>
> Apparently tigerstipe includes capability for publishing documentation of
> the model specifications. We have a *huge* need for this in the HL7
> healthcare standard specs. If we could define an Eclipse modeling
> component for publishing specs from UML2 artifacts, then I would be
> interested in contributing to that work. But not interested if it based
> on non-UML models.
See my comment above about UML.
>
> I found the tigerstipe goals to be very interesting and relevant. But my
> preference is for tigerstripe to define its components (based on UML2
> artifacts) that may by used and assembled into developer workbenches for
> other non-telcom user groups, not a single specialized workbench for
> telecom.
>
> Best Regards,
> Dave Carlson
> www.xmlmodeling.com
>
>
|
|
|
| Re: Feedback [message #561824 is a reply to message #2416] |
Mon, 03 December 2007 16:10 |
| Eclipse User |
|
|
|
Originally posted by: gunther.walther.nsn.com
Kenn Hussey wrote:
> 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.
One of the potential benefits to the Eclipse Community would be that with
Tigerstripe being the current de-facto modeling tool for OSS/J and MTOSI
teams the tool would bring a lot of interest from the whole
Telecommunication industry with it.
> 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...
Not sure it is about growing the Tigerstripe community. This could be done
elsewhere. The tool reduced the work e.g. the Order Management API by 50%
and this is enough for us to think it is valuable enough to contribute to
it. But imho this proposal is more about getting the synergies between the
communities realized.
|
|
|
Goto Forum:
Current Time: Sat Dec 21 15:09:54 GMT 2024
Powered by FUDForum. Page generated in 0.05538 seconds |
] 
Search
Help
Register
Login
Home
