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) - 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) - 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. 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
