Open ronaldtse opened 4 years ago
@ronaldtse i think we better use separate association defninition:
package Order {
}
package Billing {
}
package Customer {
}
package Types {
class "Postal address" {
+ attribute Name
+ attribute Street
}
- class Date
class "Banking Information"
}
Customer >>| access | Order
Types >> Order
Order >> Billing
"Banking Information" >>|access:BankAccount | Customer
Where >>
is an import notation, additional ||
marks can give additional info about import type and via which attribute
First of all I personally find the separate association definition very difficult to understand because the ascii arrows are too different and separate from the entity definitions. If I have a choice, I will always use the in-class relation definitions.
The second thing is that there needs to be a "full syntax" for associations too. e.g. an association can be a generalization of another association , which is not possible to express in the plantuml type arrow syntax.
First of all I personally find the separate association definition very difficult to understand because the ascii arrows are too different and separate from the entity definitions. If I have a choice, I will always use the in-class relation definitions.
The second thing is that there needs to be a "full syntax" for associations too. e.g. an association can be a generalization of another association , which is not possible to express in the plantuml type arrow syntax.
Ok, got you, lets introduce then import_package
notation as you mentioned before.
Ok, got you, lets introduce then import_package notation as you mentioned before.
I wonder if we should use just import
instead of import_package
? Maybe there are no other things we can import
?
File inclusion could use include
while package import can be import
?
Ok, got you, lets introduce then import_package notation as you mentioned before.
I wonder if we should use just
import
instead ofimport_package
? Maybe there are no other things we canimport
?File inclusion could use
include
while package import can beimport
?
As I mention in #12 i think we need to use hashbang or any other symbols for file imports, that way we don't need to remember difference
Maybe we need to differentiate between model keywords and processing keywords, but until we have to, let's omit that difference for simplicity?
Packageable element
ElementImport
PackageImport
<<access>>
and<<import>>
<<import>>
: The visibility is public; for example, the postal address for Order. The public import is a transitive relationship: if A imports B and B imports C, then A is indirectly importing C too.<<access>>
: The visibility is private, not public: Customer is visible in Order but not in Billing. The private import is not transitive.Proposal: