UML syntax: Example of OMG PrimitiveTypes XMI

[ronaldtse]

https://www.omg.org/spec/UML/20161101/PrimitiveTypes.xmi

The LutaML UML syntax can be:

# Original:
# <uml:Package xmi:type="uml:Package" xmi:id="_0" name="PrimitiveTypes"
# URI="http://www.omg.org/spec/PrimitiveTypes/20161101">
#
package PrimitiveTypes {
  @URI "http://www.omg.org/spec/PrimitiveTypes/20161101"
}

primitiveType <PrimitiveTypes>::Boolean {
  desc "Boolean is used for logical expressions, consisting of the predefined values true and false."
}

primitiveType <PrimitiveTypes>::Integer {
  desc "Integer is a primitive type representing integer values."
}

primitiveType <PrimitiveTypes>::Real {
  desc "Real is a primitive type representing the mathematical concept of real."
}

primitiveType <PrimitiveTypes>::String {
  desc "String is a sequence of characters in some suitable character set used to display information about the model. Character sets may include non-Roman alphabets and characters."
}

primitiveType <PrimitiveTypes>::UnlimitedNatural {
  desc "UnlimitedNatural is a primitive type representing unlimited natural values."
}

• @URI represents an attribute URI of the package.
• desc "..." adds a comment to the object (primitiveType, class, association...)

[ronaldtse]

@w00lf can you help refine the language?

[w00lf]

Class notation:

class MyClass {
   header 'my header'
   attribute my_attribute
   - attribute my_private_attribute
   method my_method
}

Direct relation:

class Relationship {}
class DirectRelationship {}
DirectRelationship -> Relationship

Relation through the attribute:

class Relationship {
   + attribute relatedElement
}
class Element {}
Relationship#relatedElement ->|union| '1..*' Relationship

[w00lf]

Undirected relation:

class a {}
class b {}
a -- b

[ronaldtse]

You probably mean

class Relationship {}
class DirectRelationship {}
DirectRelationship -|> Relationship

Because DirectRelationship "generalizes" Relationship.

This is why it's confusing with arrows. I'd much rather use the word "generalize" to define the relationship.

For "method" I think we should use myMethod() (this is the convention as Operation in UML).

For the undirected relationship it is easier like this:

class Relationship {
   +/relatedElement: Element[1..*] {union}
}
class Element {}

[w00lf]

You probably mean

class Relationship {}
class DirectRelationship {}
DirectRelationship -|> Relationship

Because DirectRelationship "generalizes" Relationship.

This is why it's confusing with arrows. I'd much rather use the word "generalize" to define the relationship.

For "method" I think we should use myMethod() (this is the convention as Operation in UML).

For the undirected relationship it is easier like this:

class Relationship {
   +/relatedElement: Element[1..*] {union}
}
class Element {}

Why do we use / here +/relatedElement: Element[1..*] {union}?

This is why it's confusing with arrows. I'd much rather use the word "generalize" to define the relationship.

If we planing to use import statements separate association syntax will be preferable, because we can import all needed classes first and then define their relations, or do you mean something like this?

class Relationship {}
class Element {}

Relationship generalize Element

[ronaldtse]

/ indicates "a derived attribute".

I think replacing the arrow with a keyword could also be useful.

If we planing to use import statements separate association syntax will be preferable, because we can import all needed classes first and then define their relations,

However, I don't think this provides benefit...

e.g.

class A {
  foo: Bar[1]
}
class B

Already requires parsing class A with an opening to B before B is parsed. So whether Relationships are defined before or after classes don't seem to make any difference...

[w00lf]

/ indicates "a derived attribute".

I think replacing the arrow with a keyword could also be useful.

If we planing to use import statements separate association syntax will be preferable, because we can import all needed classes first and then define their relations,

However, I don't think this provides benefit...

e.g.

class A {
  foo: Bar[1]
}
class B

Already requires parsing class A with an opening to B before B is parsed. So whether Relationships are defined before or after classes don't seem to make any difference...

Ok, lets stick with ucd syntax then:

class Relationship {
   +/relatedElement: Element[1..*] {union}
   generalizes Component
   aggregation Component *
}
class Element {}

Also, can there be a situation when we declare attribute with type but don't want to show the relationship between? Example:

class Relationship {
   +/relatedElement: Element
}
class Element {}

We will need to always create association line in that case?

[ronaldtse]

Great question!

In UML model definition, these are equivalent:

class A
class B
A#foo -> B[1]

class A {
  foo: B[1]
}
class B

It is only the diagram that differs.

When we create the "view", perhaps we have the option of whether these associations are shown. (e.g. show generalization, aggregation but not simple association)?

[w00lf]

Great question!

In UML model definition, these are equivalent:

class A
class B
A#foo -> B[1]

class A {
  foo: B[1]
}
class B

It is only the diagram that differs.

When we create the "view", perhaps we have the option of whether these associations are shown. (e.g. show generalization, aggregation but not simple association)?

What if we don't want to show specific generalization or aggregation?

[ronaldtse]

What if we don't want to show specific generalization or aggregation?

Let's discuss this in #37.

[w00lf]

@ronaldtse i have created a documentation file called LUTAML.md in branch feature/lutaml-ascii-syntax. Let's add the next LutaML items we agree upon in it.

[ronaldtse]

@w00lf tree, let's do it. We also prefer AsciiDoc, so let's use that.

We can just use master, keeping documentation in a separate branch isn't that helpful.

[w00lf]

@w00lf tree, let's do it. We also prefer AsciiDoc, so let's use that.

We can just use master, keeping documentation in a separate branch isn't that helpful.

Got you, moving it to master and converting to asciidoc

[w00lf]

@ronaldtse, done, moved file to adoc, merge into master

[ronaldtse]

Thanks @w00lf ! If this ticket is done, feel free to close.