I read the posts in
association owned by classifier and association owned by relationship in UML
Setting the association end ownership in UML: What does it mean with respect to generated code in visual paradigm (or in other UML tools)?
http://www.uml-diagrams.org/association.html
but the difference between "navigation" and "ownership" of associations of UML class diagrams is still unclear to me. Moreover, UML 2.5 was released in the meantime.
The specification states the following:
Association ends owned by classes are always navigable, while those
owned by associations may be navigable or not.
This means, that the example c below is invalid. Examples a and b are valid, in both cases the right end is navigable. However, in example b the left end is not navigable.
Am I right?
What is the semantic difference between navigation and ownership? Is navigation a "generic" way of accessing the opposite class while ownership enforces a class to have an attribute?
The specs say
Dot notation is used to denote association end ownership, where the dot shows that the Class at the other end of the line owns the Property whose type is the Class touched by the dot.
So a and b are valid and c is strange. Assuming left begin class A and right being class B. In case a A owns a property that is of type B and thus it can navigate to it. Case b explicitly adds the information that A can navigate to B which is already obvious by using the dot. In case c B owns a property of type A (and therefore can navigate). Additionally you indicate navigation from A to B without showing ownership. So that's strange.
Ownership just says there is something (a pointer) to navigate to the other object. To cite the specs (p. 126):
Navigation arrows may be shown, but if shown, they shall agree with the navigation of the Association’s ends.
and later (p. 201):
In practice, it is often convenient to suppress some of the arrows and crosses that signify navigability of association ends. A conforming tool may provide various options for showing navigation arrows and crosses. As with dot notation, these options apply at the level of complete diagrams.
Show all arrows and crosses. Navigation and its absence are made completely explicit.
Suppress all arrows and crosses. No inference can be drawn about navigation.
Suppress all crosses. Suppress arrows for Associations with navigability in both directions, and show arrows only for Associations with one-way navigability. In this case, the two-way navigability cannot be distinguished from situations where there is no navigation at all; however, the latter case occurs rarely in practice.
Navigation does not have a real use (in most cases). You show navigation by adding role names which make clear that A sees B as role. There's a notation with a cross near the end which explicitly forbids navigation. This might be useful in some cases.
It might be noted that the specs are rather silent about "navigation" (just grep the occurrences) compared to "ownership" (which is used quite a bit more). This is probably to account to the fact that the ownership had been introduced recently.
Related
In UML, is it possible to draw an aggregation where the component object can access the composite object? Like in this image, but with only one association line, so the association end touching A would have a diamond and an arrow.
If that isn't possible, the diagram I drawn is valid? If not, why?
Another point of view, navigability is important to show how is it possible to navigate in the model and how to access to instances.
Another point is about OCL, if navigability is not defined some OCL queries will be hard to write.
Specification describes (p 198): Navigability means that instances participating in links at runtime (instances of an Association) can be accessed efficiently from instances at the other ends of the Association. The precise mechanism by which such efficient access is achieved is implementation specific. If an end is not navigable, access from the other ends may or may not be possible, and if it is, it might not be efficient.
And about Property class (p 149): The query isNavigable() indicates whether it is possible to navigate across the property. body: not classifier->isEmpty() or association.navigableOwnedEnd->includes(self).
So to model or not navigability is important.
If you want to have navigability in both side, the following image shows that:
But in section 6 of the specifiation, it is written:
An association with neither end marked by navigability arrows means that the association is navigable in both directions.
Arrow notation is used to denote association end navigability. By definition, all class-owned association ends are navigable. By convention, all association owned ends in the metamodel are not navigable.
So the following schema is the same than the above one. This is tricky but it seems true.
Of course that's possible.
If you want to save space, you can use a single line for the association:
Here's my personal opinion about navigability: The navigational arrow is not needed as the existence of the property owner implies that already.
P. 110 of the specs:
When a Property is owned by a Classifier other than an Association via ownedAttribute, then it represents an attribute of the Classifier.
P. 200:
Navigability notation was often used in the past according to an informal convention, whereby non-navigable ends were assumed to be owned by the Association whereas navigable ends were assumed to be owned by the Classifier at the opposite end. This convention is now deprecated. Aggregation type, navigability, and end ownership are separate concepts, each with their own explicit notation. Association ends owned by classes are always navigable, while those owned by associations may be navigable or not.
But what is an association that is just named? It's a useless construct so far. What you intend is to finally create attributes in either classes - by means of properties in which case you add this (new) dot. To me this is simply over-constructed and impractical. Who is really using those dots? In EA you have to open sub-menus to make them appear. For me (and probably most UML readers) a role name represents a property and this an attribute in the other side. That's just "(my) human logic" behind that proposition. So, my practical approach:
Use simple connectors for association
Eventually add (non-) navigability (crosses and) arrows
Later add role names to indicate the use of attributes at the other end (rather than adding a typed attribute to the class' list).
And that's it. Just forget that silly dot that's a) hard to produce (in EA) and b) even harder to recognize.
Once again: this last part here is my recommendation for practical modeling.
When class is associated with another, like Flight in the linked image, which has zero or one Plane associated with it, should this not be reflected in the class' attributes?
That is, shouldn't class Flight in this example have an assignedPlane field alongside its flightNumber, departureTime and so on... otherwise how can Flight be said to 'be aware' of its associated Plane?
No.
Showing an association in diagram is equivalent to having an attribute of a specific class. If there is an association(with a role) then this role is an attribute of respective Class.
For reference please see the Figure 9.12 (with description) in section 9.5.5 of UML 2.5 specification.
If you would have an attribute 'assignedPlane : Plane' in class Flight, then the role 'assignedPlane' on the association would be redundant. But merely having the role 'assignedPlane' on the association does not imply that class Flight is aware of it. If Flight would be implemented as a Java class or a class in any other OO programming language, it is not clear from your class diagram whether or not class Flight has any reference to (or knowledge of) the assignedPlane.
If you want to communicate to your audience that class Flight owns a reference called 'assignedPlane' to zero or one instance of Plane, then you could add a thick dot (or a small filled circle) at the end of the association. Here is an example from the UML 2.5 specification:
In this example, 'size' is an attribute of Window, although it is displayed as an association. If you would have a class diagram that shows all attributes of Window, then 'size : Area' would be one of them.
The dot notation is a relatively new notation and it is not widely used. Instead, many designers use the arrow notation, also shown in figure 9.12. According to UML, this so-called navigability arrowhead specifies that the associated instance of Area can be accessed efficiently from Window, irrespective of how and why this is the case. Most designers would assume that it means that Window has an attribute 'size : Area', but strictly speaking, this is not what the UML specification says.
Using both the arrow and the dot, as in figure 9.12, is valid, but redundant.
I'm working on a Python+Gtk3 application with a fancy-looking GtkTreeView:
This is great for sighted users, but here's what Orca (the screen reader) says for a row in that tree view:
"Image, Devhelp, Collapsed, 9.2 MB"
A few problems, of course. First, it doesn't mention the checkbox for each row because I'm packing three cell renderers into a column. The three are available, but for some reason Orca doesn't mention the checkbox when it's buried that deep. Meanwhile, the image it mentions is the one on the far left, which is usually empty but sometimes a "restart required" indicator. Naturally, a blind user, much like a sighted user, couldn't care less that it is an image.
What I would like to do is to poke at the accessibility objects that describe this table in order to make them a little more helpful. Using Accerciser, I can see that these exist, but they all seem to be implemented with private, undocumented classes (like GtkTreeViewAccessible), and they don't look terribly extensible, but I'm hoping I'm wrong. Knowing that the treeview's accessible object is an AtkTable at some level, I did the following to set an accessible description for the image cell in the Backup row:
access = self.treeview_update.get_accessible()
cell_access = access.ref_at(0,0)
cell_access.set_image_description("Requires system restart")
(Orca still says "Image" after speaking the description, but I'll assume it knows what it's doing).
However, that code isn't very nice. When I call access.ref_at, I'm making particular assumptions about how GTK is mapping cell positions to rows and columns in the ATK object. I'm also limited to calling that when I first populate the tree, and I'm not sure if that is particularly sane.
So there's my problem: I would like to add accessible descriptions for my tree view cells in a nice way that won't break unexpectedly. How can I do that?
I'm having trouble understanding this documentation for the search/6 function in the eclipse constraint programming framework.
I understand that the choice parameter basically affects the value ordering.
It also seems like the selection method chooses the variable ordering, but I don't entirely understand all the options for it.
I don't really understand the other parameters so I was wondering if someone could explain them in words. I have a pretty good understanding of the theory of constraint logic programming so feel free to refer to those concepts. I just don't understand a lot of the CS lingo in that documentation (arity, etc.)
Thank you
I'll try to answer it as briefly as possible, since search/6 is one of the most complex predicates you can find in the ECLiPSe system.
Any more detailed follow-up questions would probably better be asked in the ECLiPSe user mailing list, though.
The search/6 predicate is a generic predicate for controlling the search for a solution of a CLP problem. It allows the user to control the shape of the search tree (the order of variables along the branches, the order of the branches, and the portion of the search tree that is visited). The predicate has 6 parameters: search(+L, ++Arg, ++Select, +Choice, ++Method, +Option). (+ and ++ denote the mode of the parameter)
The first two parameters go together. L is either a list of variables or a list of terms. If it's the former, the Arg must be 0, if it's the latter, then Arg denotes the position of the variables that should be instantiated during the search, e.g.:
search([A,B],0,input_order,indomain,complete,[]).
or
search([p(1,A),p(2,B)],2,input_order,indomain,complete,[]).
In both cases, the variables A and B are instantiated during search.
The third parameter is the selection method. This method is used by search/6 to select the next variable from the list L to instantiate.
The simplest option is input_order: the search simply iterates of the variables in the list. In the examples above, it would instantiate A first, then B. The other options consider the domain size and/or the number of constraints attached to the variables, and make the selection accordingly. E.g., first_fail chooses the variable with the smallest domain. If the current domain of A is [1,2,3] and B has the domain [1,3], then B will be selected and instantiated first. If more than one variable has the same smallest domain size, then the first of these by input order will be selected. Selection methods that take the domain size into account achieve a dynamic variable ordering, since the domain sizes will change (shrink) during search, depending on the amount of propagation that the constraints achieve.
The other selection methods should now be self-explanatory.
It is also possible to define your own selection method, provided that the predicate that implements it has arity 2, i.e., has two parameters. The predicate must take a variable as input and calculate some criterion value. The variable with the smallest criterion value will be selected.
The fourth parameter is the choice method. Once a variable is selected, the choice method controls the order in which the values in its domain are tried during search.
The simplest option is indomain, which chooses the values in the variable's current domain in ascending order. I.e., if variable A has the domain [1,3,5], then the search will initially bind A to 1, on backtracking bind it to 3, and finally to 5. indomain_middle will start with 3, then 1, then 5.
The more complex choice methods (i.e., other than indomain) will remove a tried value on backtracking, i.e., basically add additional constraints like A#\=1. This will cause additional propagation which may in turn allow earlier detection of infeasibilities. You can see the effect when running the n-queens example from the search/6 documentation that you linked to in your question.
Again, it is also possible to define your own choice method. The predicate must be of arity 1 or 3. If the arity is 1, then the predicate takes one variable as input and binds it to a value (or makes some other choice which alters the domain of the variable). If the arity is 3, then you can use the two additional parameters to pass along some state information which you can use to make the choice.
The fifth parameter is the search method. This controls the size of the section of the search tree that the search should explore (whereas the selection method controls the order of the variables along the branches of the tree, and the choice method controls the order of the branches in the search tree).
The simplest option is complete, which searches the tree left-to-right until the tree is exhausted. All other options (apart from symmetry breaking) are incomplete search methods, i.e., there will be branches in the search tree that are left unexplored. If the solution is on the leaf of such an unexplored branch, then it will not be found. You have to make sure that selection and choice methods shape the search tree in a way that the incomplete search method is able to find the solution. The option bbs, for instance, restricts the number of backtracks that can be made during search. If that number is exhausted, then the search will stop.
Symmetry breaking will only exclude branches that are equivalent (symmetrical) to other branches, in some way.
The sixth parameter is a list of possible additional options, described in the search/6 documentation. Normally, you won't need them.
I am building a c interpreter. My AST uses the composite-pattern. To check semantics and perform actions, I wanna use the visitor-pattern. Now there's one problem. This is an grammar rule of the c-preprocessor: if-section = if-group [ elif-groups ] [ else-group ] endif-line. The visitor of if-section needs information about the child nodes, to know which groups have to be skipped. In the visitor-pattern, every "visit"-method returns void. So I can't get any information about these nodes (only with adding information to the nodes, but that's ugly ...). Are there any opportunities?
You've nailed the problem: you have to have additional information above and beyond the raw data that comprises the AST.
You can associate all of that extra information with just individual tree nodes: if you do that, you'll end up building what is called an attributed tree. In theory (and if you work at), you make this idea work completely. Your visitor may have to inspect/update the information associated with not only the AST node it is visiting, but that of key children and parents.
In practice, it is useful to build auxiliary data structures (e.g., symbol tables) which can consulted by the visitor (and updated) as it walks the tree. You end up with kind of degenerate attributed tree: you associate symbol table chunks with AST nodes that form scopes.
You've artificially constrained your visitor from returning any value; if you didn't do that, a child visitor could pass useful values to a parent visitor, enabling the parent to do less ad hoc reaching down the tree.
In your problem statement, you have not constrained your visitor from passing values down to children, so you can pass down useful values. An extremely useful value to pass is the symbol table associated with the surrounding scope, so that children visitors don't have to climb back up the tree to find the scoping node, and the associated symbol table.