in UML there is Dependency relationship,However I read the following quote:
dependency indicates a semantic relationship between two or more elements
what does semantic relationship mean in the above sentence?
means that this kind of relationship is bounded by some kind of semantic definition between the elements, meaning that this semantic definition defines the UML relationship and gives it meaning. Always remember two kind of relationships: functional and semantic.
Related
This is a list of the data types for uml primitive types. What are all the uml data types? It doesn't have to be primitive types.
Boolean
Integer
UnlimitedNatural
String
Real
On p. 69 of UML 2.5 you will find
These literals have been defined to satisfy definitions used in the UML meta model itself (the section on this details these literals). You are free to add whatever you need on your own.
Datatypes are defined on p. 165:
UML makes use of PrimitiveType (any kind of forumla) and Enumeration (like shown in www.admiraalit.nl's answer). However, to make a list of all of them would be exhaustive and pointless, I guess. Rather you would define your own DataTypes to your needs.
UML is a language to define your own classes, data types etc. Yes, UML defines some classes and data types itself, but only those needed to define UML.
The notion of DataType is defined in section 10.2 of the UML 2.5 specification. The primitive types you have mentioned are indeed data types defined by UML (in chapter 21). In addition, UML defines a number of enumerations. Primitive types and enumerations are both special kinds of data types. One example of an enumeration defined in UML is VisibilityKind (section 7.8.24).
UML does not define general purpose data types like Date other than the primitive types you have mentioned. If you want to use Date as a data type, you can define it in your model, or re-use an exisiting profile. Some teams using UML have a convention that standard data types from a particular programming language or database system can be used as data types in UML.
I know the following:
OCL is a constraint language that to specify constraints on my class diagram models
I know, that in the OMG world for class diagrams there are 3 levels of models: M1 (model), M2 (meta-mode), M3 (meta-meta model)
M3: defines what a class diagram is and what it consists of
M2: Is the meta-model of my problem/domain (e.g.: meta-model of a shelf that contains books)
M3: is the model instance (e.g: a Shelf that contains two specific books)
What i would like to know:
Is there a a common meta-model for class diagrams and OCL; basically something that defines the relationship between model elements and constraints
I suppose it should somehow be defined at M1 level
I am asking because:
I would like to define a meta-model for a constraint language (lightweight OCL) that would allow for me to reason about my model elements (books on the shelf).
How would i connect the meta-models of my domain and of my constraint language?
The OCL specification [1] defines a metamodel for OCL, however there are a variety of problems that mean that practical tools have to 'improve' upon it in proprietary ways. The new Pivot variant of Eclipse OCL prototypes solutions to OMG specification problems and produces an XMI serialization that is credible. It uses an Xtext grammar [2] that you might use as a starting point. This will reveal how much semantic resolution is necessary to resolve the parts of "a.b.c.d". Not easy.
The common metamodel [3] for Pivot OCL is autogenerated by a merge of UML and OCL contributions.
Since OCL may be used to constrain stereotypes or metamodels or even run-time, OCL can be between and pair of Mn/Mn+1 levels.
If you succeed in coming up with an accurate complete lightweight parser, please share.
[1] https://www.omg.org/spec/OCL/2.4
[2] https://git.eclipse.org/c/ocl/org.eclipse.ocl.git/tree/plugins/org.eclipse.ocl.xtext.essentialocl/src/org/eclipse/ocl/xtext/essentialocl/EssentialOCL.xtext
[3] https://git.eclipse.org/c/ocl/org.eclipse.ocl.git/tree/plugins/org.eclipse.ocl.pivot/model/Pivot.ecore
I am part of a working group that is developing an IEEE standard. The problem domain of the standard is expressed as an object-oriented model. The model is independent of any particular implementation language but does use UML to express aspects of the model. In many places in the text there are references to "instances of Foo" where Foo is an abstract class. What is really meant is, "instances of any instantiable subclass of Foo".
It has always been my experience that the "instances of Foo" was understood to mean "instances of any instantiable subclass of Foo". Is this understanding something that most people versed in object-oriented models would share? If so, is there some good reference that we can point to that would support this understanding? If this isn't something that is commonly understood then we need to change a lot of text, but that's the way it goes.
The question has two aspects, firt what is correct in senso of UML and second how is it understood in reality.
Let us start with the simpler aspect. The UML standard clearly states that any instance of a classifier is also an instance of any of its generalizations
An instance of a Classifier is also an (indirect) instance of each of
its generalizations. Any Constraints applying to instances of the
generalizations also apply to instances of the Classifier.
This just gives a very static view on it. But and is not the compelete answer, because it does not say anything about how the instances can be used dynamically. But the standard also states that any instance can be used as an instance of any its generalized classifiers:
Type conformance means that if one Type conforms to another, then any
instance of the first Type may be used as the value of a TypedElement
whose type is declared to be the second Type. A Classifier is a Type,
and conforms to itself and to all of its generalizations.
So in that case the standard is quite clear.
Second aspect, the reality. In reality most of the practically applied OOP languages support polymorphism. Simplified spoken, any object of class can be treated as if it were an object of any of its super classes. Thus most people intepretete it like you meant it.
Therefore I would propose to use it in the proposed way in your standard and additionally write this in an introductionary chapter as an help for interpretation.
All refernces are to OMG UML 2.5.1.
Having just gone back (again) to the OMG standard for UML and searched through it again I found this text:
An instance of a Classifier is also an (indirect) instance of each of
its generalizations.
Furthermore, in clause 9.7.5 it uses the text
each instance of Person
in reference to a model shown in Figure 9.22.
In Figure 9.22, class Person is abstract. I think this pretty clearly resolves this in favor of , "instances of Foo," being completely correct and acceptable.
In the Alloy well-know book by Daniel Jakson he writes about three different styles in specifying constraints in Alloy: 1) predicate calculus 2) navigational style, and 3) relational calculus. (Section 3.1, page 34)
The theory behind the first and the last ones are somehow clear to to me as the first is the conventional first order logic when we take relations as predicates; and the last is relational calculus in which everything is taken as a relation and constraints are specified by employing the equation symbol and some algebraic operations (without quantifiers). In the book, it is said that the second one has the most expressive power (page 35).
My Question:
What is the theory behind the second one (i.e., navigational style)? Where should I look for (and under which terminology) to gain more information regarding this one in theory.
The motivation for the navigational style is that you want something between predicate calculus, which has no operations on sets or relations, so is very awkward and verbose to use in practice (and also less expressive due to the lack of transitive closure), and relational calculus, as pioneered by Tarski, which gives you relational operators but has no quantifiers, which is quite unnatural for most people (but which allows some beautifully succinct ways to express properties). The navigational style comes between the two, and gives you both set/relation operators and quantifiers, so in this sense -- informally at least, and probably formally too if you defined the three sublanguages carefully -- it's more expressive than either. At the same time, I had in mind that most people are comfortable with simple first order quantifiers but aren't so comfortable with relational join, and tend therefore to write formulas in which expressions denote sets. You can think of each of these expressions as starting at some atom, denoted by a quantified variable, and then "navigating" along relations to get larger and larger expressions that denote sets of atoms. This is how I think of an expression like me.parents.children : you start with me, navigate to my parents, then from them to their children -- and the result is the set containing me and my siblings. In my experience, this navigational style is what most people gravitate naturally towards.
It's true that if you had to pick one style of the three that matched OCL, it would be this navigational style, although it's true that OCL has a very much more complex semantics (due to various coercions and flattenings that happen automatically at each step), where in Alloy the semantics is just standard sets and relations. The syntax is probably more influenced by object oriented languages like Java, even though they don't have the kind of relational image that Alloy has (that is, if you have a field f and can write x.f, you can't write xs.f for the set of all objects that are mapped to by f from the objects in the set xs!). Note however that there is no special syntax here; these are just styles of usage of the same operators.
When I wrote this page in the book, I thought it would give readers some useful intuitions, but it seems to have just caused more confusion!
In Appendix E - Alternative Approaches, Daniel Jackson discusses OCL, which has a navigational style. I would assume he borrowed the syntax from it, as he discusses it as related work that precedes Alloy.
I have a situation where class A has a B and cannot exist without the B, but B can exist completely independent from the A.
From the perspective of A this is a composition relationship, but from the perspective of B this is an aggregate relationship.
What do I do??
If A is composed of B, it is association with composed end on A class side. Composition and aggregation are types of association ends. It is possible to have composition on the one side and aggregation on the other side.
You can identify composition by answering question.. is Class A composed of class B ? If yes, it is composition on class A side... example: Is computer composed of memory, CPU etc ? All computer components are in composition with computer.
Example for aggregation: particular chair is placed in room. It is aggregation, because the room is not composed of chair (room is composed of walls, window etc.). But chair can be in composition with furniture placed in room.
In common usage, an association would not be both composition and aggregation and it depends on the application. A taxi/tire relationship would be composition with the black filled diamond adjacent to the taxi. The tire can exist in a parts department independent of the taxi, but a taxi cannot be dispatched without 4 tires. The parts department can exist without tires so that would be aggregation.
Your abstract example is either an aggregation or a composition, where the parts are separable (in the sense that they do not existentially depend on the aggregate). You didn't make any statement about the exclusivity of your B parts. If they cannot be shared among two or more A's, then your association between A and B is a composition.
Notice that it's a widespread mistake to think that composition is defined as an aggregation where the composite existentially depends on the component. The UML Specification states that this is typically, but not necessarily, the case for compositions. Rather what defines a composition is that the components are exclusive parts that are not shared with other composites.
See also my answer to a related SO question.