Home » Archived » Tigerstripe » Proposed re-phrasing of the proposal
| Proposed re-phrasing of the proposal [message #4182] |
Wed, 28 November 2007 15:15  |
 Eric Dillon
Messages: 103
Registered: July 2009 |
Senior Member |
|
|
Hi all,
thanks much for all the feedback.
I have tried to digest all the comments and I think I need to re-phrase the
proposal in a number of areas to address some of your concerns and make it a
bit more "crisp". We are not trying to overlap with any existing project,
nor trying to re-invent the wheel. We certainly don't want to create
confusion in the community.
It seems the proposal was received as being a lot broader than it really is.
In particular, the truth is that our current user community is based in the
Telecom vertical, and that some of the technologies and implementation
choices were certainly driven by this fact (even if the same choices would
be different now based on the availability of some of the existing modeling
sub-projects).
So, as stated in some of the comments, I think it would make sense to
re-center the proposal on the Telecommunications Vertical, state that the
project uses technologies and techniques that are taylored to that industry,
yet that we intend to adopt more of the Modeling components over time and
feedback accordingly.
So I intend to rephrase the proposal as follows. I'm hoping this will clear
all concerns and provide a good base to start working together.
Regards,
Eric
------------------------
1. - in the "Background section",
1.1 - in the 3rd paragraph, rephrase
"...Moreover, generic-purpose UML modeling tools offer UML modeling
environment that is too broad.
With experience it becomes clear that constraining the model with tight
conventions and rules is necessary to control
the quality of the generated code or specification for a specific
industry, technology or domain."
by
"...Moreover, generic-purpose UML modeling tools offer too much flexibility
to non-experienced UML modelers. When working with large distributed teams,
it becomes clear that the modeling tool needs to guide and constrain the
users according to the target domain. This typically goes beyond UML
profiles and require tight naming conventions and validation rules accross a
model to ensure the quality of the generated code or specification, in
particular in the Telecommunications Industry".
1.2. - in the 4th paragraph, rephrase
"Tigerstripe was born two years ago to address this need of a single,
integrated environment dedicated to generic MDD."
by
"Tigerstripe was born two years ago to address this need of a single,
integrated environment dedicated to MDD in the Telecommunications Industry:
in particular, Tigerstripe was first adopted by Telecommunications standard
bodies for Operational and Business Support Systems management interfaces."
2. in the "Scope section", re-phrase the objectives as follows:
- contribute an extensible toolset for Model-Driven Development targeting
the Telecommunications Vertical, with extension points supporting the
generation of application code, APIs, specifications or documentation. The
initial version was built using a combination of existing Eclipse components
and proprietary technology to address the specific needs of this industry.
- integrate additional components of Eclipse projects into the existing
environment to enhance the existing MDD environment or replace proprietary
technologies as appropriate.
- provide an extensible framework, and solicit contributions so that
industry specific models can be developed, maintained and exchanged.
Tigerstripe's initial user community is expected to be in the Telecoms'
industry.
- provide additional tools, samples and ideas that allows integration of
Tigerstripe with other existing environments.
We intend to migrate existing parts of the software to the latest frameworks
supported by the Modeling top-level project. In particular, we intend to use
more of the EMF and UML2 frameworks where applicable to complement the
current technology in use, and allow easier model sharing between users. As
we proceed we will feedback requirements as experienced in our Telecom
industry vertical.
3. in the "Description Section", re-phrase the following:
"UML2 modeling capabilities through a graphical editor for Class Diagrams or
Instance Diagrams"
by
"A subset of UML2 features with Class Diagrams and Instance Diagrams"
|
|
|
| Re: Proposed re-phrasing of the proposal [message #4393 is a reply to message #4182] |
Wed, 28 November 2007 17:55  |
Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Eric,
Thanks for being so responsive. I hope that no one will take any of
these discussions as personal criticism. I'd really like if in the long
term I'd be able to work more closely with you folks and with you in
particular.
Eric Dillon wrote:
> Hi all,
>
> thanks much for all the feedback.
>
> I have tried to digest all the comments and I think I need to re-phrase the
> proposal in a number of areas to address some of your concerns and make it a
> bit more "crisp". We are not trying to overlap with any existing project,
> nor trying to re-invent the wheel. We certainly don't want to create
> confusion in the community.
>
> It seems the proposal was received as being a lot broader than it really is.
> In particular, the truth is that our current user community is based in the
> Telecom vertical, and that some of the technologies and implementation
> choices were certainly driven by this fact (even if the same choices would
> be different now based on the availability of some of the existing modeling
> sub-projects).
>
> So, as stated in some of the comments, I think it would make sense to
> re-center the proposal on the Telecommunications Vertical, state that the
> project uses technologies and techniques that are taylored to that industry,
> yet that we intend to adopt more of the Modeling components over time and
> feedback accordingly.
>
> So I intend to rephrase the proposal as follows. I'm hoping this will clear
> all concerns and provide a good base to start working together.
>
> Regards,
> Eric
> ------------------------
>
> 1. - in the "Background section",
> 1.1 - in the 3rd paragraph, rephrase
> "...Moreover, generic-purpose UML modeling tools offer UML modeling
> environment that is too broad.
> With experience it becomes clear that constraining the model with tight
> conventions and rules is necessary to control
> the quality of the generated code or specification for a specific
> industry, technology or domain."
> by
> "...Moreover, generic-purpose UML modeling tools offer too much flexibility
> to non-experienced UML modelers. When working with large distributed teams,
> it becomes clear that the modeling tool needs to guide and constrain the
> users according to the target domain. This typically goes beyond UML
> profiles and require tight naming conventions and validation rules accross a
> model to ensure the quality of the generated code or specification, in
> particular in the Telecommunications Industry".
>
So what does this imply in terms of using the UML2 model directly and
basing the editor on UML2 Tools effort? Is it sufficient to use only a
subset of the existing larger UML2 model and surfacing only a subset of
the diagramming capabilities? Or will it always be necessary to use a
different API which implies that things like OCL, QVT, and many other
technologies won't directly apply?
> 1.2. - in the 4th paragraph, rephrase
> "Tigerstripe was born two years ago to address this need of a single,
> integrated environment dedicated to generic MDD."
> by
> "Tigerstripe was born two years ago to address this need of a single,
> integrated environment dedicated to MDD in the Telecommunications Industry:
> in particular, Tigerstripe was first adopted by Telecommunications standard
> bodies for Operational and Business Support Systems management interfaces."
>
This certainly help make clear the industry vertical aspect. I
understand that UML is very complex, and to be not so politically
correct, in my opinion its rather overly complex, and that this high
level of complexity makes it more difficult to convince folks that
modeling isn't just an ivory tower exercise. I.e., I understand all too
well the reasons for your approach. But I still see it as problematic
to produce specialized flavors of UML since such an approach creates a
schism that's not easy to mend. And imagine if the flavors start to
blossom based on industry verticals. We could be like Baskin-Robbins
only not in a good way.
> 2. in the "Scope section", re-phrase the objectives as follows:
> - contribute an extensible toolset for Model-Driven Development targeting
> the Telecommunications Vertical, with extension points supporting the
> generation of application code, APIs, specifications or documentation. The
> initial version was built using a combination of existing Eclipse components
> and proprietary technology to address the specific needs of this industry.
> - integrate additional components of Eclipse projects into the existing
> environment to enhance the existing MDD environment or replace proprietary
> technologies as appropriate.
> - provide an extensible framework, and solicit contributions so that
> industry specific models can be developed, maintained and exchanged.
> Tigerstripe's initial user community is expected to be in the Telecoms'
> industry.
> - provide additional tools, samples and ideas that allows integration of
> Tigerstripe with other existing environments.
>
This sounds much more focused. It's a good thing.
> We intend to migrate existing parts of the software to the latest frameworks
> supported by the Modeling top-level project. In particular, we intend to use
> more of the EMF and UML2 frameworks where applicable to complement the
> current technology in use, and allow easier model sharing between users. As
> we proceed we will feedback requirements as experienced in our Telecom
> industry vertical.
>
> 3. in the "Description Section", re-phrase the following:
> "UML2 modeling capabilities through a graphical editor for Class Diagrams or
> Instance Diagrams"
> by
> "A subset of UML2 features with Class Diagrams and Instance Diagrams"
>
>
>
I guess I'm quite anxious to understand if this means using the UML2
model directly. I hate to keep harping on that point. But to me part
of the value of MDD is that all the different things folks are doing
today will all be applicable to the models being created by tigerstripe...
Thanks for bearing with us!
|
|
|
| Re: Proposed re-phrasing of the proposal [message #4532 is a reply to message #4393] |
Wed, 28 November 2007 20:02 |
Eric Dillon
Messages: 103
Registered: July 2009 |
Senior Member |
|
|
"Ed Merks" <merks@ca.ibm.com> wrote in message
news:fika2k$ase$1@build.eclipse.org...
> Eric,
>
> Thanks for being so responsive. I hope that no one will take any of
> these discussions as personal criticism. I'd really like if in the long
> term I'd be able to work more closely with you folks and with you in
> particular.
I think we are getting there :-).
>
> Eric Dillon wrote:
>> Hi all,
>>
>> thanks much for all the feedback.
>>
>> I have tried to digest all the comments and I think I need to re-phrase
>> the proposal in a number of areas to address some of your concerns and
>> make it a bit more "crisp". We are not trying to overlap with any
>> existing project, nor trying to re-invent the wheel. We certainly don't
>> want to create confusion in the community.
>>
>> It seems the proposal was received as being a lot broader than it really
>> is. In particular, the truth is that our current user community is based
>> in the Telecom vertical, and that some of the technologies and
>> implementation choices were certainly driven by this fact (even if the
>> same choices would be different now based on the availability of some of
>> the existing modeling sub-projects).
>>
>> So, as stated in some of the comments, I think it would make sense to
>> re-center the proposal on the Telecommunications Vertical, state that the
>> project uses technologies and techniques that are taylored to that
>> industry, yet that we intend to adopt more of the Modeling components
>> over time and feedback accordingly.
>>
>> So I intend to rephrase the proposal as follows. I'm hoping this will
>> clear all concerns and provide a good base to start working together.
>>
>> Regards,
>> Eric
>> ------------------------
>>
>> 1. - in the "Background section",
>> 1.1 - in the 3rd paragraph, rephrase
>> "...Moreover, generic-purpose UML modeling tools offer UML modeling
>> environment that is too broad.
>> With experience it becomes clear that constraining the model with tight
>> conventions and rules is necessary to control
>> the quality of the generated code or specification for a specific
>> industry, technology or domain."
>> by
>> "...Moreover, generic-purpose UML modeling tools offer too much
>> flexibility to non-experienced UML modelers. When working with large
>> distributed teams, it becomes clear that the modeling tool needs to guide
>> and constrain the users according to the target domain. This typically
>> goes beyond UML profiles and require tight naming conventions and
>> validation rules accross a model to ensure the quality of the generated
>> code or specification, in particular in the Telecommunications Industry".
>>
> So what does this imply in terms of using the UML2 model directly and
> basing the editor on UML2 Tools effort? Is it sufficient to use only a
> subset of the existing larger UML2 model and surfacing only a subset of
> the diagramming capabilities? Or will it always be necessary to use a
> different API which implies that things like OCL, QVT, and many other
> technologies won't directly apply?
To start with we have defined a "base" UML2 profile that is focused on
Interfaces, Managed Objects, amongst other things.
For example, we don't expose "UML Classes" we expose "Managed Entities",
which are in fact UML Classes with a "Managed Entity" stereotype. Our
editors are aware of that, won't let you draw associations that "don't make
sense" in our vertical. I guess this could be expressed as OCL statements
that would need to be validated/enforced in realtime.
In terms of diagraming capabilities, we don't really worry yet about
behavioral aspects. Class diagrams (and instance diagrams
for documentation purpose) are enough. GMF gave us a good base, but we had
to work a lot to get to the synchronization/perfomance level we needed (250+
diagrams on a 1500+ element model).
I may not be up2date on the latest achievements of the UML2 project, and
there is probably a real base for us to consider.
Yet, our large scale requirements are demanding.
>> 1.2. - in the 4th paragraph, rephrase
>> "Tigerstripe was born two years ago to address this need of a single,
>> integrated environment dedicated to generic MDD."
>> by
>> "Tigerstripe was born two years ago to address this need of a single,
>> integrated environment dedicated to MDD in the Telecommunications
>> Industry: in particular, Tigerstripe was first adopted by
>> Telecommunications standard bodies for Operational and Business Support
>> Systems management interfaces."
>>
> This certainly help make clear the industry vertical aspect. I
> understand that UML is very complex, and to be not so politically correct,
> in my opinion its rather overly complex, and that this high level of
> complexity makes it more difficult to convince folks that modeling isn't
> just an ivory tower exercise. I.e., I understand all too well the reasons
> for your approach. But I still see it as problematic to produce
> specialized flavors of UML since such an approach creates a schism that's
> not easy to mend. And imagine if the flavors start to blossom based on
> industry verticals. We could be like Baskin-Robbins only not in a good
> way.
Don;t think we've re-invented the wheel here :-). We have used UML2 profiles
that we hid away from users.
New icons... that's it.
>> 2. in the "Scope section", re-phrase the objectives as follows:
>> - contribute an extensible toolset for Model-Driven Development targeting
>> the Telecommunications Vertical, with extension points supporting the
>> generation of application code, APIs, specifications or documentation.
>> The initial version was built using a combination of existing Eclipse
>> components and proprietary technology to address the specific needs of
>> this industry.
>> - integrate additional components of Eclipse projects into the existing
>> environment to enhance the existing MDD environment or replace
>> proprietary technologies as appropriate.
>> - provide an extensible framework, and solicit contributions so that
>> industry specific models can be developed, maintained and exchanged.
>> Tigerstripe's initial user community is expected to be in the Telecoms'
>> industry.
>> - provide additional tools, samples and ideas that allows integration of
>> Tigerstripe with other existing environments.
>>
> This sounds much more focused. It's a good thing.
>> We intend to migrate existing parts of the software to the latest
>> frameworks supported by the Modeling top-level project. In particular, we
>> intend to use more of the EMF and UML2 frameworks where applicable to
>> complement the current technology in use, and allow easier model sharing
>> between users. As we proceed we will feedback requirements as experienced
>> in our Telecom industry vertical.
>>
>> 3. in the "Description Section", re-phrase the following:
>> "UML2 modeling capabilities through a graphical editor for Class Diagrams
>> or Instance Diagrams"
>> by
>> "A subset of UML2 features with Class Diagrams and Instance Diagrams"
>>
>>
>>
> I guess I'm quite anxious to understand if this means using the UML2 model
> directly. I hate to keep harping on that point. But to me part of the
> value of MDD is that all the different things folks are doing today will
> all be applicable to the models being created by tigerstripe...
Another point of contention we had was that we need to support multiple dev
teams on large models. In particular we wanted a very fine grain persistence
mechanism (i.e. one file per element in the model). This is probably
something that is workable with references, across projects and libraries
(we allow for "compiled models" like java .jar that can only be extended
with specific rules) we opted for our own cooking for simplicity at the
time. Once again, something I'd like to explore again at the right time.
That being said we do provide an export mechanism allowing to spit out a
UML2 model (using the UML2 model), so in a sense we're partly there.
>
> Thanks for bearing with us!
I believe the discussion has already been very fruitful.
|
|
| | |
| Re: Proposed re-phrasing of the proposal [message #561635 is a reply to message #4182] |
Wed, 28 November 2007 17:55 |
Ed Merks
Messages: 33263
Registered: July 2009 |
Senior Member |
|
|
Eric,
Thanks for being so responsive. I hope that no one will take any of
these discussions as personal criticism. I'd really like if in the long
term I'd be able to work more closely with you folks and with you in
particular.
Eric Dillon wrote:
> Hi all,
>
> thanks much for all the feedback.
>
> I have tried to digest all the comments and I think I need to re-phrase the
> proposal in a number of areas to address some of your concerns and make it a
> bit more "crisp". We are not trying to overlap with any existing project,
> nor trying to re-invent the wheel. We certainly don't want to create
> confusion in the community.
>
> It seems the proposal was received as being a lot broader than it really is.
> In particular, the truth is that our current user community is based in the
> Telecom vertical, and that some of the technologies and implementation
> choices were certainly driven by this fact (even if the same choices would
> be different now based on the availability of some of the existing modeling
> sub-projects).
>
> So, as stated in some of the comments, I think it would make sense to
> re-center the proposal on the Telecommunications Vertical, state that the
> project uses technologies and techniques that are taylored to that industry,
> yet that we intend to adopt more of the Modeling components over time and
> feedback accordingly.
>
> So I intend to rephrase the proposal as follows. I'm hoping this will clear
> all concerns and provide a good base to start working together.
>
> Regards,
> Eric
> ------------------------
>
> 1. - in the "Background section",
> 1.1 - in the 3rd paragraph, rephrase
> "...Moreover, generic-purpose UML modeling tools offer UML modeling
> environment that is too broad.
> With experience it becomes clear that constraining the model with tight
> conventions and rules is necessary to control
> the quality of the generated code or specification for a specific
> industry, technology or domain."
> by
> "...Moreover, generic-purpose UML modeling tools offer too much flexibility
> to non-experienced UML modelers. When working with large distributed teams,
> it becomes clear that the modeling tool needs to guide and constrain the
> users according to the target domain. This typically goes beyond UML
> profiles and require tight naming conventions and validation rules accross a
> model to ensure the quality of the generated code or specification, in
> particular in the Telecommunications Industry".
>
So what does this imply in terms of using the UML2 model directly and
basing the editor on UML2 Tools effort? Is it sufficient to use only a
subset of the existing larger UML2 model and surfacing only a subset of
the diagramming capabilities? Or will it always be necessary to use a
different API which implies that things like OCL, QVT, and many other
technologies won't directly apply?
> 1.2. - in the 4th paragraph, rephrase
> "Tigerstripe was born two years ago to address this need of a single,
> integrated environment dedicated to generic MDD."
> by
> "Tigerstripe was born two years ago to address this need of a single,
> integrated environment dedicated to MDD in the Telecommunications Industry:
> in particular, Tigerstripe was first adopted by Telecommunications standard
> bodies for Operational and Business Support Systems management interfaces."
>
This certainly help make clear the industry vertical aspect. I
understand that UML is very complex, and to be not so politically
correct, in my opinion its rather overly complex, and that this high
level of complexity makes it more difficult to convince folks that
modeling isn't just an ivory tower exercise. I.e., I understand all too
well the reasons for your approach. But I still see it as problematic
to produce specialized flavors of UML since such an approach creates a
schism that's not easy to mend. And imagine if the flavors start to
blossom based on industry verticals. We could be like Baskin-Robbins
only not in a good way.
> 2. in the "Scope section", re-phrase the objectives as follows:
> - contribute an extensible toolset for Model-Driven Development targeting
> the Telecommunications Vertical, with extension points supporting the
> generation of application code, APIs, specifications or documentation. The
> initial version was built using a combination of existing Eclipse components
> and proprietary technology to address the specific needs of this industry.
> - integrate additional components of Eclipse projects into the existing
> environment to enhance the existing MDD environment or replace proprietary
> technologies as appropriate.
> - provide an extensible framework, and solicit contributions so that
> industry specific models can be developed, maintained and exchanged.
> Tigerstripe's initial user community is expected to be in the Telecoms'
> industry.
> - provide additional tools, samples and ideas that allows integration of
> Tigerstripe with other existing environments.
>
This sounds much more focused. It's a good thing.
> We intend to migrate existing parts of the software to the latest frameworks
> supported by the Modeling top-level project. In particular, we intend to use
> more of the EMF and UML2 frameworks where applicable to complement the
> current technology in use, and allow easier model sharing between users. As
> we proceed we will feedback requirements as experienced in our Telecom
> industry vertical.
>
> 3. in the "Description Section", re-phrase the following:
> "UML2 modeling capabilities through a graphical editor for Class Diagrams or
> Instance Diagrams"
> by
> "A subset of UML2 features with Class Diagrams and Instance Diagrams"
>
>
>
I guess I'm quite anxious to understand if this means using the UML2
model directly. I hate to keep harping on that point. But to me part
of the value of MDD is that all the different things folks are doing
today will all be applicable to the models being created by tigerstripe...
Thanks for bearing with us!
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Proposed re-phrasing of the proposal [message #561671 is a reply to message #4393] |
Wed, 28 November 2007 20:02 |
Eric Dillon
Messages: 103
Registered: July 2009 |
Senior Member |
|
|
"Ed Merks" <merks@ca.ibm.com> wrote in message
news:fika2k$ase$1@build.eclipse.org...
> Eric,
>
> Thanks for being so responsive. I hope that no one will take any of
> these discussions as personal criticism. I'd really like if in the long
> term I'd be able to work more closely with you folks and with you in
> particular.
I think we are getting there :-).
>
> Eric Dillon wrote:
>> Hi all,
>>
>> thanks much for all the feedback.
>>
>> I have tried to digest all the comments and I think I need to re-phrase
>> the proposal in a number of areas to address some of your concerns and
>> make it a bit more "crisp". We are not trying to overlap with any
>> existing project, nor trying to re-invent the wheel. We certainly don't
>> want to create confusion in the community.
>>
>> It seems the proposal was received as being a lot broader than it really
>> is. In particular, the truth is that our current user community is based
>> in the Telecom vertical, and that some of the technologies and
>> implementation choices were certainly driven by this fact (even if the
>> same choices would be different now based on the availability of some of
>> the existing modeling sub-projects).
>>
>> So, as stated in some of the comments, I think it would make sense to
>> re-center the proposal on the Telecommunications Vertical, state that the
>> project uses technologies and techniques that are taylored to that
>> industry, yet that we intend to adopt more of the Modeling components
>> over time and feedback accordingly.
>>
>> So I intend to rephrase the proposal as follows. I'm hoping this will
>> clear all concerns and provide a good base to start working together.
>>
>> Regards,
>> Eric
>> ------------------------
>>
>> 1. - in the "Background section",
>> 1.1 - in the 3rd paragraph, rephrase
>> "...Moreover, generic-purpose UML modeling tools offer UML modeling
>> environment that is too broad.
>> With experience it becomes clear that constraining the model with tight
>> conventions and rules is necessary to control
>> the quality of the generated code or specification for a specific
>> industry, technology or domain."
>> by
>> "...Moreover, generic-purpose UML modeling tools offer too much
>> flexibility to non-experienced UML modelers. When working with large
>> distributed teams, it becomes clear that the modeling tool needs to guide
>> and constrain the users according to the target domain. This typically
>> goes beyond UML profiles and require tight naming conventions and
>> validation rules accross a model to ensure the quality of the generated
>> code or specification, in particular in the Telecommunications Industry".
>>
> So what does this imply in terms of using the UML2 model directly and
> basing the editor on UML2 Tools effort? Is it sufficient to use only a
> subset of the existing larger UML2 model and surfacing only a subset of
> the diagramming capabilities? Or will it always be necessary to use a
> different API which implies that things like OCL, QVT, and many other
> technologies won't directly apply?
To start with we have defined a "base" UML2 profile that is focused on
Interfaces, Managed Objects, amongst other things.
For example, we don't expose "UML Classes" we expose "Managed Entities",
which are in fact UML Classes with a "Managed Entity" stereotype. Our
editors are aware of that, won't let you draw associations that "don't make
sense" in our vertical. I guess this could be expressed as OCL statements
that would need to be validated/enforced in realtime.
In terms of diagraming capabilities, we don't really worry yet about
behavioral aspects. Class diagrams (and instance diagrams
for documentation purpose) are enough. GMF gave us a good base, but we had
to work a lot to get to the synchronization/perfomance level we needed (250+
diagrams on a 1500+ element model).
I may not be up2date on the latest achievements of the UML2 project, and
there is probably a real base for us to consider.
Yet, our large scale requirements are demanding.
>> 1.2. - in the 4th paragraph, rephrase
>> "Tigerstripe was born two years ago to address this need of a single,
>> integrated environment dedicated to generic MDD."
>> by
>> "Tigerstripe was born two years ago to address this need of a single,
>> integrated environment dedicated to MDD in the Telecommunications
>> Industry: in particular, Tigerstripe was first adopted by
>> Telecommunications standard bodies for Operational and Business Support
>> Systems management interfaces."
>>
> This certainly help make clear the industry vertical aspect. I
> understand that UML is very complex, and to be not so politically correct,
> in my opinion its rather overly complex, and that this high level of
> complexity makes it more difficult to convince folks that modeling isn't
> just an ivory tower exercise. I.e., I understand all too well the reasons
> for your approach. But I still see it as problematic to produce
> specialized flavors of UML since such an approach creates a schism that's
> not easy to mend. And imagine if the flavors start to blossom based on
> industry verticals. We could be like Baskin-Robbins only not in a good
> way.
Don;t think we've re-invented the wheel here :-). We have used UML2 profiles
that we hid away from users.
New icons... that's it.
>> 2. in the "Scope section", re-phrase the objectives as follows:
>> - contribute an extensible toolset for Model-Driven Development targeting
>> the Telecommunications Vertical, with extension points supporting the
>> generation of application code, APIs, specifications or documentation.
>> The initial version was built using a combination of existing Eclipse
>> components and proprietary technology to address the specific needs of
>> this industry.
>> - integrate additional components of Eclipse projects into the existing
>> environment to enhance the existing MDD environment or replace
>> proprietary technologies as appropriate.
>> - provide an extensible framework, and solicit contributions so that
>> industry specific models can be developed, maintained and exchanged.
>> Tigerstripe's initial user community is expected to be in the Telecoms'
>> industry.
>> - provide additional tools, samples and ideas that allows integration of
>> Tigerstripe with other existing environments.
>>
> This sounds much more focused. It's a good thing.
>> We intend to migrate existing parts of the software to the latest
>> frameworks supported by the Modeling top-level project. In particular, we
>> intend to use more of the EMF and UML2 frameworks where applicable to
>> complement the current technology in use, and allow easier model sharing
>> between users. As we proceed we will feedback requirements as experienced
>> in our Telecom industry vertical.
>>
>> 3. in the "Description Section", re-phrase the following:
>> "UML2 modeling capabilities through a graphical editor for Class Diagrams
>> or Instance Diagrams"
>> by
>> "A subset of UML2 features with Class Diagrams and Instance Diagrams"
>>
>>
>>
> I guess I'm quite anxious to understand if this means using the UML2 model
> directly. I hate to keep harping on that point. But to me part of the
> value of MDD is that all the different things folks are doing today will
> all be applicable to the models being created by tigerstripe...
Another point of contention we had was that we need to support multiple dev
teams on large models. In particular we wanted a very fine grain persistence
mechanism (i.e. one file per element in the model). This is probably
something that is workable with references, across projects and libraries
(we allow for "compiled models" like java .jar that can only be extended
with specific rules) we opted for our own cooking for simplicity at the
time. Once again, something I'd like to explore again at the right time.
That being said we do provide an export mechanism allowing to spit out a
UML2 model (using the UML2 model), so in a sense we're partly there.
>
> Thanks for bearing with us!
I believe the discussion has already been very fruitful.
|
|
| | |
Goto Forum:
Current Time: Thu Dec 12 16:40:34 GMT 2024
Powered by FUDForum. Page generated in 0.03936 seconds |