Notes and comments, constraint rules, keywords on uml diagrams: definitions, description, examples.
Notes can stand on their own, or they can be linked with a dashed line to the elements they are commenting. They can appear in any kind of diagram.
The UML allows us to use anything to describe constraints. The only rule is that we put them inside curly braces ({}) and appears in a rectangle with a folded upper-right corner. Optionally, we can name a constraint by putting the name first, followed by a colon as in syntax constraint ::= '{' [ name ':' ] boolean-expression '}'; for example, {disallow incest: husband and wife must not be siblings}. In UML models, a constraint is an extension mechanism that enables we to refine the semantics of a UML model element. A constraint refines a model element by expressing a condition or a restriction to which the model element must conform. An example of a constraint is a condition such as an attribute having a specific value. A constraint must be enforced in the design of a system. We specify the condition or restriction in the body of the constraint. Typically, constraints do not have names; instead, they are identified by the contents of their bodies. However, some commonly used constraints are identified by names so that the contents of their bodies do not have to be repeated. The XOR constraint is applied when more than one association has a common connection to one class.
we can write the body of a constraint in the following languages:
Natural languages such as English
Programming languages such as Java
Mathematical notations
Object Constraint Language (OCL)
We can add constraints to our model for the following purposes: In models that depict software systems, constraints represent conditions or restrictions that we can find no other way to model. In models that depict time-critical software systems, constraints provide a statement about the relative or absolute value of time during an interaction.
The UML has many varieties of dependency, each with particular semantics and keywords. The basic dependency that I've outlined here is the one I find the most useful, and I usually use it without keywords. To add more detail, we can add an appropriate keyword:
«call» The source calls an operation in the target.
«create» The source creates instances of the target.
«derive» The source is derived from the target.
«instantiate» The source is an instance of the target. (Note that if the source is a class, the class itself is an instance of the class class; that is, the target class is a metaclass).
«permit» The target allows the source to access the target's private features.
«realize» The source is an implementation of a specification or interface defined by the target
«refine» Refinement indicates a relationship between different semantic levels; for example, the source might be a design class and the target the corresponding analysis class.
«substitute» The source is substitutable for the target
«trace» Used to track such things as requirements to classes or how changes in one model link to changes elsewhere.
«use» The source requires the target for its implementation.
Search Controller uses Search Engine