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
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 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.
Alloy newbie here.
I really like creating constraints in Alloy and having the analyzer check that the model is valid per the constraints.
But I ask myself, “Are these constraint definitions mere mental gymnastics, or will they help build better software?”
Let’s take a specific example. In a model of an email client’s address book one might define this constraint for adding a new entry into the address book:
The address mapping in the new book b’ is equal to the address
mapping in the old book b, with the addition of a link from the
name to the address. This constraint is expressed in Alloy as:
b'.addr = b.addr + n->a
That is beautiful.
But I am struggling to see its relevance when the add operation is implemented in code. For instance, I implemented the add operation in Common Lisp:
(defun add (b n a)
"Add a new entry, (n a), to address book b"
(adjoin (list n a) b :key #'first))
In words: “Here is a definition of a function named add which has three parameters: b, n, and a (book, name, address). Use the Common Lisp set function, adjoin, to add the list (n a) to b.”
That function seems to correctly implement a simple add function.
What do I do with the constraint that I defined in Alloy? Should I write additional code that expresses the constraint? In pseudo-code: [1]
(defun add (b n a)
"Add a new entry, (n a), to address book b"
(adjoin (list n a) b :key #'first)
Check that nothing has changed in the
address book except that it now has
a n->a mapping)
Writing such code seems like a lot of work, with no apparent benefit.
So my question is this: When implementing an Alloy model in code, what should I do with the constraints that are defined in Alloy?
Also, is there a tutorial which describes how to convert Alloy models to code, including a description of how Alloy constraint definitions are used in code?
Thank you.
[1] Note: I realize that there is a language extension called Screamer for constraint programming in Common Lisp
I believe the question stems from a minor misunderstanding of the goals and capabilities of some of the modeling languages like Alloy and touches some of the fundamental aspects of formal methods, verification and software modeling. Probably good resources to get a background story that would make things more clear include books like Calculus of Computation, as well as the book about Alloy you've mentioned.
Constraints are first-class citizens of the Alloy modeling language. The idea is that constraints reflect the semantics of the code one wants to model (and check properties about). Thus, from one perspective, Alloy program represents the code itself and there is no need for writing additional code (e.g. in a functional language) or mixing declared constraints with code. However, Alloy programs cannot be directly executed; rather, they can only be used to produce models according to such programs (i.e. sets of constraints).
More specifically, the Alloy constraint b'.addr = b.addr + n->a, might, under an appropriate interpretation, indeed capture the behavior of the add operation in Lisp, so that checking some properties that involve the constraint corresponds to checking whether those properties hold for the given operation in Lisp. This is the standard (and, arguably, intended) use of Alloy for modeling and verification of software. (In addition, Alloy is frequently used to model systems that don't have clear mappings into programs, like certain kinds of cyber-physical systems [1].) Note that this of course entails that the model one writes in Alloy must correctly model the program at hand (with respects to its semantics), in order for the checking of properties to make sense.
As mentioned, Alloy itself cannot produce executable code (such as the one you've given, written in Common Lisp). However, there are multiple approaches that use Alloy and models that Alloy generates to produce fragments of code or test cases. (Again, according to the specific program at hand.) In addition, an extension of Alloy, called Alloy* [2], which adds the possibility of solving higher order constraints within Alloy (quantification over relations) can be used to generate programs; actual code that performs the operation and accepts different inputs (similarly to the add function, according to the model). Again, such programs are represented with Alloy models and one needs to (perform additional effort to) translate those models into programs in some desired programming language.
Having that said, note that some (verification) systems indeed allow you to mix specifications with code, where specifications might be: written in the same way as the code that is to be executed (like in the verification/synthesis framework Leon [3]); or written in a distinct language (from the language of executable code), while the specifications are bound to code by some other means (like annotations in Dafny [4]).
[1] Kang, Eunsuk, et al. "Model-based security analysis of a water treatment system." Proceedings of the 2nd International Workshop on Software Engineering for Smart Cyber-Physical Systems. ACM, 2016.
[2] Milicevic, Aleksandar, et al. "Alloy*: A general-purpose higher-order relational constraint solver." Proceedings of the 37th International Conference on Software Engineering-Volume 1. IEEE Press, 2015.
[3] Blanc, Régis, et al. "An overview of the Leon verification system: Verification by translation to recursive functions." Proceedings of the 4th Workshop on Scala. ACM, 2013.
[4] Leino, K. Rustan M. "Dafny: An automatic program verifier for functional correctness." International Conference on Logic for Programming Artificial Intelligence and Reasoning. Springer Berlin Heidelberg, 2010.
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.
Several questions about UML:
Do I include the main class in my UML diagram?
If I do include it, and it instantiates objects, do I draw an empty arrow (such as ->) from my main class to the classes it instantiates?
When do I use the diamond vs. the arrow?
I'm just curious about those 3 things... While an article would also be very helpful, could someone address those three questions?
Thank you so much.
Do I include the main class in my UML diagram?
There are many types of UML diagrams, but I suspect here you mean a class diagram. The answer to your question is literally: if you want to. The beauty of UML is that you can make many diagrams, that vary in detail. Some diagrams will show just a few classes, some many. The idea is that you diagram different parts of the system, at different views, for different audiences. Diagram as much or as little as you like. If you are making a very small application with just a few classes, then it probably will make sense to show the main class. Give it a stereotype or use a comment that identifies it as a "main application class."
If I do include it, and it instantiates objects, do I draw an empty arrow (such as ->) from my main class to the classes it instantiates?
You certainly may, again "if you want to," There will be a dependency here in a way: the main class "depends on" the other classes because it uses them somehow. That is, if main class A instantiates objects of class B, then class A needs class B to compile, so you may show this as a dependency if you wish.
When do I use the diamond vs. the arrow?
The diamond shows aggregation or composition and is used as follows: if class A has a field of class B, then an arrow from A to B with a diamond on the A side is called for. The "plain arrow" just shows a relatively unspecificed dependency. You can use it from class A to class B when class A uses, somehow class B. Perhaps a method of class A uses an instance of class B as a local variable. No containment (composition or aggregation) of a B in an A is implied with the plain dependency.
It seems that you are not an UML expert but this is not a problem. What I would recommend is to simply reverse engineer your code into class diagrams and then add your own notes inside a yellow rectangle having a connector linked to what you consider important.
You will get a graphical representation of your code and would be able to add value comments without having real UML knowledge.
UML class diagram is really simple and can cover all needs of a project. If you don't know UML then just do class diagram by reversing your code and enjoy :-)