Hi Klaas,
thanks to Yves Bernard, a few answers (translated).
Le 03/12/2010 16:56, Topcased user list where issues are discussed a
écrit :
Hi,
[Probably to long to read on a friday evening ;-) ]
While scrolling the 4.2 release notes I revisited bug
#2595<http://gforge.enseeiht.fr/tracker/index.php?func=detail&aid=2595&group_id=52&atid=109>
and thought of some bugs which are still present (or missing features).
It seems to me that topcased currently has a rather huge synchronization
problem for block properties. Below are my findings. Please feel free to
correct me wherever appropriate. (I think) They can be summarized as there
should be a one-to-one, or one-to-two correspondence between associations and
properties. This mail relates (at least) to current bug reports #3047, #2595,
#3399.
- "Property" creation
1/ As far as I can understand the spec, it seems to me that creating an(y)
assocation between blocks b1 and b2 should result in creating a property in the
model tree under the appropriate blocks. Currently this is only the case when
creating a composite association, but it should happen with _any_ association:
Let's say a create an association between block b1 and b2, then
* A composite association (owner b1) results in a part property in b1 (OK)
* A shared association (owner b1) should result in a reference property in
b1 (currently does not happen)
* A unidirectional association (owner b1) should result in a reference
property (currently does not happen)
* An doubledir or undirected association should result in 2 reference
properties, both in b1 and b2 (currently does not happen)
2/ Similarly, (ie. bidirectionally) I think creating a property as a part of a
block (whether it be created by the outline, or graphically in an IBD should
create the necessary associations. This currently does not happen. For this
case, there seems to be one complication: In the case of reference properties,
it is impossible to estimate whether the user would like to create a directed
or an undirected association. However, in my opinion this is not a good
reason not to create the association. In this case, the documentation should
just mention that a undirected association should be created first (as in point
1 above)
Here is an extract of SysML 1.2 specification:
"The only form of an association end that
SysML allows an association to own directly is an unnamed end used to
carry an inverse multiplicity of a reference
property. This unnamed end provides a metamodel element to record an
inverse multiplicity, to cover the specific case of
a unidirectional reference that defines no named property for navigation
in the inverse direction"
So what you ask is legitimous. But we must care to manage the whole set
of association ends.
What is more questionable and probably to avoid is to create an
association automatically . An association is a classifier that has its
own semantics. Creating an association will result in creating
properties but opposite is not true. Generally users will create an
association when an attribute would be enough and they do that only
because they prefer the graphical notation...
- Property deletion
* Property deletion should result in deleting the assocation too.
* In the special case of deleting a property which is assocated with an
undirected association, this should result in turning the undirected
association into a directed one.
None of this seems currently implemented. Currently, even when _deleting_ the
composite association between two blocks, the property remains part of the
model (the Aggregation attribute changes to none though, and the Association
attribute correctly vanishes). So strictly speaking topcased turns the
deletion of the property into a modification of the property type (part
property changes into reference property)
* An association relationshop can not have less than 2 "memberEnds". So
if you want to delete one property that appears to be one of the two
(last) "membeEnd" of an association, there are two options:
- either forbid this deletion
- else delete the association and the opposite property (/opposite) too
Note : the second point is not conform to the specification as it
forgets to take into account the whole set of properties that define the
association.
- Property modification
* Changing the type of an association should change the Aggregation attribute
of a property.
* If an undirected association is changed into a directed one, a warning should
appear that a property will be deleted.
* If a directed assocation is turned into an undirected one, an extra property
should be created
* Changing the type of a property should probably result in deleting the
current association and creating a new one (to avoid inconsistent diagrams?).
A message could then tell the user that he might need to drag the new
assocation to the diagrams where appropriate.
* It seems that the aggregation type is well managed at property side
* a change in association direction does not remove nor create
properties : they are moved.
* not sure to understand the "inconsistency evoked in the last point.
For Yves, this warning does not seem to be necessary.
Hope it helps a little bit,
regards
raphaël
Thoughts? Am I missing any complications?
If I'm correct, I guess an ocl expert can formulate this mail into 2 lines or
so ;-)
Thx for reading so far and have a nice weekend.
Klaas
_______________________________________________
Topcased-users mailing list
[email protected]
http://lists.gforge.enseeiht.fr/mailman/listinfo/topcased-users
_______________________________________________
Topcased-users mailing list
[email protected]
http://lists.gforge.enseeiht.fr/mailman/listinfo/topcased-users
