Open ronaldtse opened 4 years ago
@w00lf can you help refine the language?
Class notation:
class MyClass {
header 'my header'
attribute my_attribute
- attribute my_private_attribute
method my_method
}
class Relationship {}
class DirectRelationship {}
DirectRelationship -> Relationship
class Relationship {
+ attribute relatedElement
}
class Element {}
Relationship#relatedElement ->|union| '1..*' Relationship
Undirected relation:
class a {}
class b {}
a -- b
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 {}
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
/
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...
/
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?
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)?
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
?
What if we don't want to show specific generalization or aggregation?
Let's discuss this in #37.
@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.
@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 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
@ronaldtse, done, moved file to adoc, merge into master
Thanks @w00lf ! If this ticket is done, feel free to close.
https://www.omg.org/spec/UML/20161101/PrimitiveTypes.xmi
The LutaML UML syntax can be:
@URI
represents an attributeURI
of the package.desc "..."
adds a comment to the object (primitiveType, class, association...)