I have some models with date attributes and I want to include ocl for validation and derivation.
Searching on the internet I found some articles and papers referring to date.isBefore(date) or date.before(date) methods but these methods are not recognized in OCL.
Additionally I would like to define derivation such as derivation: endDate + 10;.
Do I have to redefine a Date class with all methods I need ?
Any material or link related to it is welcome.
Given that OCL does not define Date, the authors' should have gone the long way round in order to formally define isBefore (and pages are a scarce resource in academic writing ;)
A few “primitive types” including numbers and strings are predefined
in UML [RJB98*, p. 394]. The availability of other types like date and
money is “system-dependent”. In any case, the semantics of primitive
types has to be defined outside UML.
(Richters Mark. A Precise Approach to Validating UML Models and OCL Constraints, Universität Bremen, p. 33, 86)
[RJB98] Rumbaugh, Jacobson, and Booch. The Unified Modeling
Language Reference Manual. Addison-Wesley, 1998.
While I'm not proficient in EMF, According to this link any Java datatype can be used in your models by declaring it as
the instance type of an EDataType for your Ecore model. (See also this reference)
Related
I work in the aviation industry, and I am trying to understand this UML diagram. I did a little bit of UML in college. Can you help me to interpret this diagram?
What is the difference between << extend >> and << select >>?
What do the big black arrows mean?
I didn't understand how to read the graph.
«extend»and «select» are stereotypes which were given a certain meaning in the domain of that model. Usually a profile is used to define the sterotypes and their meaning. So the best is you contact the author of the diagram and ask about it. There is no general answer. It looks a bit like these are meant to be requirements.
The "black arrows" with the lozenge are associations that are given a composite aggregation attribute. The lozenge-side is responsible for the lifetime of the other side. Means it will destroy them when it is destroyed itself.
Fun note about the «class» (as per comment from Axel Scheithauer from p. 99 of UML 2.5:
If the default notation is used for a Classifier, a keyword corresponding to the metaclass of the Classifier shall be shown in guillemets above the name. The keywords for each metaclass are listed in Annex C and are specified in the notation for each subclass of Classifier. No keyword is needed to indicate that the metaclass is Class.
So putting that keyword there is like painting "car" on a car to make it a car, obviously.
I could see there are some common definitions of the graphical items in Modelica language, but I can't find the definitions in Modelica Standard Library, so these definitions are built-in types?
Those types, and the records in that chapter, are internal to the specification.
Additionally having unit="mm" as for DrawingUnit is not recommended for normal types, as the idea is to use SI-types without any prefix.
I do not understand the meaning of class in Modelica context.
From the Modelica Tutorial, version 1.4 on https://modelica.org/publications.html:
In Modelica, the basic structuring element is a class. There are seven restricted classes with specific names, such as model...". Anyone have a simpler explanation? I am very new to Modelica.
If you open the Modelica library in a tool like Dymola or OpenModelica, everything you see in the package or library browser are classes.
As soon as you use one of these classes, e.g. with drag and drop in the diagram layer, you create a new component of this class type.
The instantiated component is not a copy of the class, but a reference to it. Therefore, if you update the class definition, you also update the behavior of all components that are instances of this class.
There are several kinds of classes available. The most general class is actually called class, but it’s not used very often.
It has no restrictions, so it can contain everything that is possible with Modelica: equations, algorithms, public and protected components, etc.
There are more specific class types, which restrict the usage. This helps to make correct use of a class. A function or a record for example cannot be simulated.
The most important restricted class types are:
package: used to group other classes
model: typically used for components with physical connectors and for examples which are simulated
block: used for components with causal connectors (only inputs and outputs, so everything you have in Modelica.Blocks)
function: used for function calls, comparable to other programming languages
record: often used to contain data sets for other components (which allows to quickly change a complete data set)
connector: used to define the interface variables which are needed to connect different components of a domain (e.g. v and i in the electric domain)
type: typically used to define physical quantities like mass, length or time with their unit (e.g. all units in the package Modelica.Units)
More information can be found in chapter 4.6 of the Modelica specification: Specialized Classes
This is just a collection of links to prove that there is an ongoing discussion on class within the Modelica Association:
class still a valid Modelica class type to use?
model no longer identical to class
What is the usage recommendation for class?
Restricted class for parameter record with initial equation
Is there a tool that can generate diagrams (similar to Doxygen using Graphviz) but in the formats described by this paper: Lisp Looks Different
Program Style Distribution: Determine which programming style (Functional, OO, Imperative or Macro) dominates a software package, also to determine the size of complexity in each package.
Class Method Relation View: Visualizes the relationships between classes and methods (in Lisp, classes and methods are separated). The goal is to identify possible independent or loosely coupled components of the system.
Generic Concer View: Helps to identify and locate cross-cutting concerns associated with generic functions.
Class Type View: Helps to identify different types of classes, based on their structure, more precisely on the attributes to methods ratio.
tio
For the meaning of the colors and shapes, please refer to the document. It would be nice if there are equivalent tools for other languages as well.
Have you looked at Mondrian, which the paper cites was what was used to generate those diagrams?
More generally, have you looked at Moose, of which Mondrian is but a part?
I'm not sure I've seen one that produces diagrams exactly like those above, but there are quite a few more software visualization tools around.
Obvous first step: contact the paper's authors and ask what tools they used, and do they have any code they can share.
Does any programming language provide such a thing?
Where could this be used?
For example:
note that somethingStrange is not a class, its an instance (its underlined) and this is an object diagram
Spec (section 7.3.22) says:
An instance specification is depicted using the same notation as its classifier, but in place of the classifier name appears an underlined concatenation of the instance name (if any), a colon (‘:’) and the classifier name or names.
The convention for showing multiple classifiers is to separate their names by commas.
So im stuck with "multiple classifiers".
Any language with extensional rather than intensional typing will allow such constructs.
For example, in RDF two sources could make claims about a web resource which are completely conflicting, or in a 'duck type' language an object could have all the characteristics of two otherwise unrelated types.
Extensional languages classify objects by their properties - if it has prongs it's a fork, if it's got a handle and a bowl it's a spoon, if it has both prongs and a bowl it is both a fork and a spoon.
The difference between such languages and class oriented intensional languages such as C++/Java/C# to which UML is more commonly applied, is that you don't need a spork class to define things which are both spoons and forks - whether things belong to a classifier is defined by whether they meet the requirements of the classifier.
That's multiple inheritance if you're referring to classes (except that you should use solid edges for generalization), nothing wrong with that ;)
Note that an interface is also a classifier, so also the text of your question needs a bit of refinement -- nothing wrong with generalizing more than one interface, after all.
It's is a Dependency.
Dependency is a weaker form of relationship which indicates that one class depends on another because it uses it at some point of time. One class depends on another if the latter is a parameter variable or local variable of a method of the former. This is different from an association, where an attribute of the former is an instance of the latter.
In other words your somethingStance class will use both Cat and Panzer
The below it is just an example of how it might look like
Public class SomethingStrange{
public Cat CatDependency{get;set;}
public Panzer PanzerDependency{get;set;}
}
UML does allow an object to be instance of several different classes (even if they are unrelated) at the same time. The fact that this is not the normal convention and not supported by programming languages is a different issue. UML tries to be as broad as possible even if specific technologies only can implement a subset of it.