UML syntax: Packageable element, ElementImport, PackageImport

[ronaldtse]

Packageable element

• A packageable element is a named element that can belong directly to a package.
  • Example: an operation cannot belong to a package, bua a class may.
• The visibility statement is mandatory for a packageable element.

ElementImport

• The act of importing an element is called ElementImport and is a relationship between a namespace and a packageable element that resides in another namespace.
• The referenced element can then be addressed directly by its (unqualified) name. In addition, an optional alias name can be specified.

PackageImport

• The act of importing a package is called PackageImport; it is semantically equivalent to the import of a single element from that package.
• We cannot specify an alias name here.

<<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:

package Order {
  import_package <<access>> Customer
  import_package Types
}

package Billing {
  import_package <<import>> Order
}

package Customer {
  import_package <<access>> via(BankAccount) "Banking Information"
}

package Types {
  class "Postal address" {
    +Name
    +Street
  }

  class -Date
  class "Banking Information"
}

[w00lf]

@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

[ronaldtse]

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.

[w00lf]

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.

[ronaldtse]

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?

[w00lf]

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?

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

[ronaldtse]

Maybe we need to differentiate between model keywords and processing keywords, but until we have to, let's omit that difference for simplicity?