[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cme-dev] comments on experience with CME UI
|
Hi - regarding the comments on extraction/composition and the ui:
>>Also, when you create a new concern by extraction or composition, the
result ends up only under the Workspace concern. If extraction and
composition apply only >>to units, then I understand that the result
should end up at least under the Workspace. However, it seems to me that
users will most of the time want to extract or >>compose into a new
concern elsewhere in the concern space (say, under Features). It would be
nice to have the ability to target the new concern to both the >>Workspace
and to some number of additional concerns.
>> With composition I believe this is possible, by
de-selecting 'compose immediately' in the wizard. Extraction creates a
project and contents from a
>>user-defined concern. It seems to me that it makes sense
that this would go into the workspace, otherwise it would just be copying
part of the model to
>>another place in the model.
Extraction and Composition are not fully implemented in the ui as yet. At
the moment you cant extract (or the ui doesn't drive anything at the
moment) and composition only follows the demo scenario i.e. you can't
deselect "compose immediately" and you can only compose through merging
rather than any of the other options. As for the result of composition
ending up under Features, then yes, it should do (or we always planned it
to), however, we didn't get this working in the demo time frame.
Thanks, Helen
Sian
January/UK/IBM@IB
MGB To
Sent by: cme-dev@xxxxxxxxxxx
cme-dev-admin@ecl cc
ipse.org
Subject
Re: [cme-dev] comments on
10/08/2004 16:48 experience with CME UI
Please respond to
cme-dev
Hi Stan,
Thanks for your comments - it's really great to have some solid feedback.
I've inlined some responses in blue. Some of the points are undisputably
bugs, in which case I have marked them as such. I will investigate these
and either fix them or raise bugs in the near future. Some things I was
less sure about. These should probably be discussed on one of our calls -
maybe the next one you can make, unless others want to annotate this e-mail
further.
Thanks again for all the input,
Sian
Stan Sutton
<suttons@xxxxxxxxxx>
Sent by: To
cme-dev-admin@eclipse.o cme-dev@xxxxxxxxxxx
rg cc
Mark N Wegman <wegman@xxxxxxxxxx>,
Vivek Sarkar <vsarkar@xxxxxxxxxx>
09/08/2004 22:22 Subject
[cme-dev] comments on experience with
CME UI
Please respond to
cme-dev
Hi All,
I've been playing around with the CME UI as part of an effort to see to
what extent I can capture Cosmos concern models in Conman. As a result, I
now have some experience in using the UI and have some feedback to report.
My comments are listed below.
I realize that some of my comments address well-known limitations of the
current UI, and that many of the limitations in the UI have good reason for
being (i.e., we haven't needed to fix them for the demo). I don't intend
to belabor those issues. Still, I would seriously like to be able to use
the UI to do serious concern modeling, so I've tried to be thorough in my
observations, at least with respect to my own experience.
If it's not clear otherwise, I do like the overall look and feel of the UI
and I generally enjoy working in it. I would really like to be able to do
more with it!
Regards,
Stan
1. When you add a concern under an existing concern, the tree item
above the added item collapses completely. This is only a minor
inconvenience if you're just adding one or two new concerns that are just
one or two levels down from the root of the item, but it's a real problem
if you're adding a large number of concerns (which you have to do one at a
time) that are four or five (or more) levels down.
Bug
2. At the top level the concern model is divided into three parts:
Workspace, Contained Relationships, and Features, but through the UI a
user can add new concerns only under Features. I can see that this
simplifies the UI (in some obvious ways and in some ways that are probably
not obvious to me). However, in practice people will want to add concerns
that do not represent features. For example, I want to add top-level
concerns to represent the Cosmos schema and (under those) elements of
particular Cosmos concern models. The Cosmos schema does not correspond to
a feature, and actually "features" may be a category some levels down into
a Cosmos model. Thus it would be useful to allow users to add new concerns
at the top level of the Conman concern space.
This seems reasonable to me, but I'd like to discuss it
before making the changes. I believe we did it this way in the initial
version for simplicity, using the same reasoning that decided to only
include certain options for composition and to pre-load a
set of existing concerns (the workspace) etc.
3. I was able to add new concerns (specifically the root of a Cosmos
schema) at the top level of the Conman concern space (i.e., at the same
level as Features, etc.) by modifying the ConmanBuilder class in
org.eclipse.cme.ui.internal.builder. When I do this, the new elements show
up appropriately in the UI (which is good). However, when I right-click on
these items, the selections available on the context-sensitive menus are
not the same as the selections available on items under Features, although
I expect that they should be (and it would be more useful if they were).
The following table compares the available selections under Features and
under the new top-level item that I added. (Note: In order to get around
this limitation on the functionality of context-sensitive menus for new
top-level parts of the concern model, I ended up inserting the Cosmos
schema, i.e., the CosmosElements item, under Features as well as at the top
level of the model. In this way I can view the Cosmos elements at the top
level of the model and work with it under Features.)
This would be a bug if we were allowing users to add other
concerns.... It will need to be implemented if we decide to implement 2.
-----------------+ ---------|
Und | | Under | |
er | | New | |
Exi | | Top-Le | |
sti | | vel | |
ng | | Item | |
Top | | "Cosmo | |
-Le | | sEleme | |
vel | | nts" | |
Ite | | | |
m | | | |
"Fe | | | |
atu | | | |
res | | | |
" | | | |
-------------------+-----------------+----------------------+---------|
| Roo| One | Two | Menu selections | Root | One | Two | Menu |
| t | level | level| | | level| levels| selectio|
| | down | s | | | down | down | ns |
| | | down | | | | | |
|----+-------+------+-----------------+-------+------+-------+---------|
| Fea| | | New concern, | Cosmos| | | Search |
| tur| | | Search for | Elemen| | | for |
| es | | | | ts | | | |
|----+-------+------+-----------------+-------+------+-------+---------|
| | Cosmos| | Delete, | | Conce| | Add to |
| | Elemen| | New concern, | | rns | | concern,|
| | ts | | Extract concern,| | | | Search |
| | | | Compose new | | | | for |
| | | | concern, | | | | |
| | | | Search for | | | | |
|----+-------+------+-----------------+-------+------+-------+---------|
| | | Conce| Same as above | | | Logica| Same as |
| | | rns | | | | lConce| above |
| | | | | | | rns | |
|----+-------+------+-----------------+-------+------+-------+---------|
4. The "Search for" selection in the context-sensitive menus
contains options that are really only appropriate to Java (or Java-like)
units. They don't apply to other sorts of units, packages, or to concerns
in general. However, I would probably like to do some "quick searching"
for concerns in a Cosmos schema, for example, according to the sorts of
relationships that apply to Cosmos model elements. This all suggests a
couple of things: a) It would be nice to make unavailable those search
selections that are nonsensical for a particular type of item, and b) it
would be nice to have a mechanism by which appropriate kinds of search
could be added for a particular type of item (for all I know, such a
mechanism may already exist and it may just need to be made more evident).
I think it's a bug that menu options aren't greyed out for
certain selections. We would probably need to provide an extension point
for plug-ins to be able to contribute other menu items, like the package
explorer does. To discuss?
5. Empty packages are not shown under the Workspace concern in the
Concern Explorer view. They do show up in the Package Explorer view. I
would like them to show up in the Concern Explorer view because I want to
use the UI to populate them with selected units.
I'm fairly sure this would be a conman or a loaders change
rather than a UI change.
6. Another limitation of the UI that those familiar with it will
already know is that you can't use the UI to create relationships among
concerns. But I would really like to be able to do this. (Note also that
I'm interested in relationships that apply directly between concerns, not
just relationships that may apply between units and be propagated to
concerns that contain those units.)
I'm not sure why we decided not to allow this, does anyone
remember? I think it may have been for simplicity again.
7. Limitations (and other features) of Add To Concern
1. Relationships under Contained Relationships can be added to a
concern, but relationships elsewhere cannot be (and these are the same
relationships, just accessed from different parts of the model). Apart
from being inconsistent, this is problematic because the relationships
under Contained Relationships are disorganized and difficult to work with.
Thus users are actually likely to want to work with relationships,
including adding them to concerns, starting in other parts of the model.
Bug?
2. Similarly, units under Workspace can be added to a concern, but
units elsewhere cannot be (and these are the same units, just accessed from
different parts of the model). The units under the Workspace are
well-organized by the workspace project/package structure, but users can be
expected to want to work with units under concerns in other parts of the
model as well.
I believe it was felt that it would be confusing to allow
users to add units from user-created concerns into other concerns, however
this may be a bug.
3. It's not possible to add a concern to another concern, but this
is an entirely sensible and useful thing to do.
4. An exception to points 2 and 3 above is that a unit or a concern
that is the target of a relationship can be added to a concern, even if the
relationship itself (and possibly the concern that contain the
relationship) cannot be. (So, for instance, if you find a concern Foo
under Features, you cannot right-click on it and add it to another concern,
whereas if you find concern Foo as the target of a relationship somewhere
else under Features, you can right-click on it and add it to another
concern.)
Bug
8. Also, when you create a new concern by extraction or composition,
the result ends up only under the Workspace concern. If extraction and
composition apply only to units, then I understand that the result should
end up at least under the Workspace. However, it seems to me that users
will most of the time want to extract or compose into a new concern
elsewhere in the concern space (say, under Features). It would be nice to
have the ability to target the new concern to both the Workspace and to
some number of additional concerns.
With composition I believe this is possible, by
de-selecting 'compose immediately' in the wizard. Extraction creates a
project and contents from a user-defined concern. It seems to me that it
makes sense that this would go into the workspace,
otherwise it would just be copying part of the model to another place in
the model.
9. It would be useful to be able to copy and move concerns, units,
and relationships--at least those that are not tied to some physical
structure (like the workspace) or intensional specification.
Bug (probably a feature enhancement), although copying
could be quite a big job.
10. It doesn't seem possible to change the name of a concern (but I
don't get all of my concern names right the first time).
Bug (enhancement)
11. The regular Eclipse search (flashlight button) doesn't work in
the Concern Explorer view. The search operation is available, but it
doesn't seem to work properly in general, at least, not in the Concern
Explorer view. And there are things that can be searched in the Package
Explorer view that apparently can't be searched in the Concern Explorer
view, namely projects, packages, and units.
Should this work? The searches Eclipse provides will only
work on concrete files. What were you trying to use it for?
12. There's some flaky behavior in the handling of scopes in the CME
Search view, especially in the relationship between scopes in the query
wizard and scopes in the main CME Search window:
Bug x 4
1. In the main CME Search window, if you set the scope of a query to
be Workspace or Entire Concern Model, and then invoke the query wizard to
specify and run a query, then the scope set in the main window determines
the scope over which the query is evaluated, even if the scope is set
differently in the query wizard
2. In the main CME Search window, if you set the scope of a query to
Other Concerns, and then invoke the query wizard to specify and run a
query, then the query is evaluated with respect to the Entire Concern
Model, regardless of how the scope is set in the query wizard
3. In the main CME Search window, if you set the scope of a query to
Entire Concern Model or to Workspace and then invoke the query wizard, the
query wizard comes up with the scope set in the same way. However, in the
main window, if you set the scope to Other Concerns, then the wizard
sometimes (but not always) comes up with the scope set to Entire Concern
Model. (I don't know what determines whether this last bit works correctly
or not.)
4. This is unlike the above items, but it seems possible to run a
query against Other Concerns without having specified any other concerns.
The behavior in that case seems to be Entire Concern Model (but I'm not
sure whether this is intended)
