My teacher uses exclamation marks and question marks before method names in UML class diagrams to distinguish between commands (!) and queries (?):
As I've never seen this before, I wonder whether it's actually used in practice or not and what the actual meaning is.
Basically, commands are methods that don't have a return type whereas queries are methods that do have, so I consider these symbols to be redundant. Moreover I couldn't find anything about this notation on the internet.
I'd really appreciate a clarification.
This is no official notation. Besides the fact that prefixing things which are obvious through their signature is pointless, it will just confuse readers which are not familiar with that kind of notation.
As remarked by Anna Vopureta and Thomas Kilian, the notation used by your teacher is not standard UML. But as pointed out in the article of Martin Fowler recommended by Anna Vopureta, and missing in the asnwer of Thomas Kilian, it makes sense to distinguish between those operations/methods with return value that represent pure queries (not changing the state) and those that do not (due to state changes).
So, we have to deal with three cases:
operations/methods without return value
operations/methods with return value
changing the state
not changing the state (pure queries)
A pure query method can be expressed in a UML class diagram by appending the operation property query in curly braces to the operation declaration.
In your example the correct operation declarations would be
+foo()
+bar1(): int
+bar2(): int {query}
Related
I'm taking a Data Analysis course, we're covering UML class diagrams. I keep getting confused by the terminology of methods (operations) and constructors. What is the difference between a method and a constructor? Any explanation would be greatly appreciated, the light bulb for this just hasn't lit yet and hope some outside perspectives will help. Thank you in advance!
Some of the confusion has historical reasons where terms were defined only partially (or not at all). The current UML spec 2.5 defines on p. 114
9.6.3.1 Operations
An Operation is a BehaviorialFeature of an Interface, DataType, or Class. An Operation may be directly invoked on instances of its featuringClassifiers. The Operation specifies the name, type, Parameters, and Constraints for such invocations.
Sounds a bit like blurb, but basically this is what a programmer would call a function.
Method in contrast (which formerly has been used alternatively to Operation) is defined on p. 13
For example, an operation owned by a class may have a related method that defines its detailed behavior.
So the method is the "how to" of an operation and can be described by various means like e.g. a StateMachine and more.
Finally a Constructor is a certain operation which by is executed during initialization of an object. On p. 15:
Therefore, when modeling the detailed behavior of the instantiation of a classifier, it is a modeler responsibility to ensure that the modeled behavior carries out the proper initialization of any attributes with default values once the object is created. (This is often done by encapsulating the instantiation behavior for a class in a constructor operation – see sub clause 11.4 – in which case the initialization of the attributes becomes an implicit postcondition for the constructor.)
I don't understand what the relationship between the two tables in the linked picture mean. And how can I code it?
It's with
virtual public Propriete Proprietes { get; set; }
Geert writes true things, but I think, you need more practical advice.
That one-directional arrow means, that the Enquette class has a field or method, that are of the class Propriete. In 99% it is a simply field of that type. Contemporary standard offers to use a point on the other side of the line for this.
The fact, that the arrow has no name on it, often means that the name of the field is propriete, or Propriete, according to the style accepted by the language and your company. (it is not required in UML standard, but it is widely used). According to the last paragraph of the question, it seems, your company uses this rule, too.
The fact, that there is no arrow on the other end of the line, does not mean, that there is no field or method in Propriete class that has a class of Enquette. (Though it meant that in 90-ties). It merely means we haven't decided yet if there are such fields or not. Or maybe, we consider it to be not important. I.e. it is undefined. The known lack of such connection must be shown by a cross instead of an arrowhead.
So, somewhere in Enquette you have a line:
Propriete propriete;
or
Propriete* Propriete; //if you are in C++
or even maybe
Propriete** Propriete;
or cited by you
virtual public Propriete Proprietes { get; set; } // apparently, C#
It could be either static/class field or instance field - it is not defined in the diagram.
And in the class Propriete there can exist the line:
Enquete enquete; // or some of the mentioned variants
And you are leaving the decision about its existence to the coder.
Notice, that a line without arrowheads means that really there are fields (or methods) for both ends. Simply we don't draw arrowheads at all if the line should show two of them.
So, really, you have a mistake in the question. It is NOT an unidirectional relationship. It is an unidirectional arrow showing a relationship, that MAY BE unidirectional.
The arrow at the end of the Association between the Classes (not tables) indicates that this end is navigable.
This is defined as an operation the Property at the end of the Association. The definition in UML 2.5 specs says:
isNavigable() : Boolean
The query isNavigable() indicates whether it is possible to navigate across the property.
body: not classifier->isEmpty() or association.navigableOwnedEnd->includes(self)
Furthermore it says about the Association Notation:
An open arrowhead on the end of an Association indicates the end is
navigable. A small x on the end of an Association indicates the end is
not navigable.
And about the Navigability on an Association
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 to conclude something to keep in mind because this convention is still often used:
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.
So now you should know what it means. How to code it depends on the programming language, the company standards, the architectural layer, your creativity, etc..
I was running a tutorial today, and a we were designing a Class diagram to model a road system. One of the constraints of the system is that any one segment of road has a maximum capacity; once reached, no new vehicles can enter the segment.
When drawing the class diagram, can I use capacity as one of the multiplicities? This way, instead of having 0..* vehicles on a road segment, I can have 0..capacity vehicles.
I had a look at ISO 1905-1 for inspiration, and I thought that what I want is similar to what they've called a 'multiplicity element'. In the standard, it states:
If the Multiplicity is associated with an element whose notation is a text string (such as an attribute, etc.), the multiplicity string will be placed within square brackets ([]) as part of that text string. Figure 9.33 shows two multiplicity strings as part of attribute specifications within a class symbol. -- section 9.12
However, in the examples it gives, they don't seem to employ this feature in the way I expected - they annotate association links rather than replace the multiplicities.
I would rather get a definitive answer for the students in question, rather than make a guess based on the standard, so I ask here: has anyone else faced this issue? How did you overcome it?
According to the UML specification you can use a ValueSpecification for lower and upper bounds of a multiplicity element. And a ValueSpecification can be an expression. So in theory it must be possible although the correct expression will be more complex. Indeed it mixes design and instance level.
In such a case it is more usual to use a constraint like this:
UML multiplicity constraint http://app.genmymodel.com/engine/xaelis/roads.jpg
In an XML schema you can mark an element as nillable meaning it can take an explicit NULL value. See nillable and minOccurs XSD element attributes for a great explanation.
What I'm curious about is why is it called nillable? I always see nillable and think it's a typo!
EDIT
I appreciate that nil is a synonym for null. What I'm wondering is why nil was chosen, rather than the more common (in computer science) null. Particularly as it should really be nilable (note the single L)!
What I'm wondering is why nil was chosen, rather than the more common (in computer science) null
This depends on which part of computer science you're coming from!
If you look at programs written in functional languages, you'll see nil every where, and very seldom null. And as it happens, XML and all it's siblings such as XSLT are closely related to functional languages.
Nil has the same language roots as null. Nil comes from the Latin for nihil which means "nothing". "Null", while related, comes from the Latin for "none" (literally 'ne-' meaning "not" and 'ullus' meaning "anything"). While they are similar in meaning, they have some slightly nuanced differences.
In practical usage, 'null' is far more common stateside while 'nil' is more common in Europe. Most people tend to use them interchangeably in software development terms but in language usage 'nil' is more common, in my experience.
It comes from nil which is another term for null, used in XML. I don't think that there is any specific reason the one the be preferred over the other in different programming languages. It is just an expression. It is used in some sports too, to express 0. http://en.wikipedia.org/wiki/Nil
If memory serves, it's called "nillable" because (some of) the SQL people in the room became concerned about possible confusion between the relevant concept in XSD and the relevant concept in SQL. They threatened to lie down in the road to stop the proposal unless the name was changed. So the WG changed the name.
(On the orthographic question, I think nilable would invite pronunciation with a long 'i'; I believe that both American and British English regularly double final single consonants following a short stressed vowel. Cf. 'tag', 'tagging', 'tagged', 'taggable'.)
This term we are using XML WSDL. If nillable is true, then we can also use null value in parameter. I used this and it worked for me.
I'm confronted with the task of implementing algorithms (mostly business logic style) expressed as flowcharts. I'm aware that flowcharts are not the best algorithm representation due to its spaghetti-code property (would this be a use-case for CPS?), but I'm stuck with the specification expressed as flowcharts.
Although I could transform the flowcharts into more appropriate equivalent representations before implementing them, that could make it harder to "recognize" the orginal flow-chart in the resulting implementation, so I was hoping there is some way to directly represent flowchart-algorithms as (maybe monadic) EDSLs in Haskell, so that the semblance to the original flowchart-specification would be (more) obvious.
One possible representation of flowcharts is by using a group of mutually tail-recursive functions, by translating "go to step X" into "evaluate function X with state S". For improved readability, you can combine into a single function both the action (an external function that changes the state) and the chain of if/else or pattern matching that helps determine what step to take next.
This is assuming, of course, that your flowcharts are to be hardcoded (as opposed to loaded at runtime from an external source).
Sounds like Arrows would fit exactly what you describe. Either do a visualization of arrows (should be quite simple) or generate/transform arrow code from flow-graphs if you must.
Assuming there's "global" state within the flowchart, then that makes sense to package up into a state monad. At least then, unlike how you're doing it now, each call doesn't need any parameters, so can be read as a) modify state, b) conditional on current state, jump.