UML syntax: Associations

[ronaldtse]

Associations

• Def.- An association describes a set of tuples of typed instances.
• The multiplicity of an association specifies how many objects of the opposite class an object can be associate with.
• If this number is variable, we state a range, that is, the minimum and maximum values.
• A minimum of 0 means that the relationship is optional (the relationship exists, nevertheless, but the number of elements is 0).

Association-Notation & Semantics

• Roles and Constraints: an association is represented by a straight line between the participating properites. At least two properties participate in an association.

Proposal:

class Customer {
}

class CustomerAccount {
}

class BookingPosition {
  -bpos:
}

Customer [1] <-(belongs to) [1] CustomerAccount#+account

CustomerAccount [1] <>-> [*] BookingPosition#-bpos

Association name

• Each association can be given a name an a reading direction within a small filled triange.
• The reading direction does not refer to the navigability of the association.
• At either end of the association, role names can be added to describe in more detail what roles the objects have within the relationship.
• These roles are the names of properties (for example, attributes), which belong to the association or to one of the participating classes.
• Is possible to add visibility information to either end of the association.
• If an association end is declared private (-), then the object itself (i.e. the operations of this object) can use the association, but neighboring classes have no access (like a private attribute).

Proposal:

class Company
class Employees
class Managers {
  generalization Employees
}
class Workers {
  generalization Employees
}

association {
  Company ->(subsets employee) Managers.bosses[1..*]
}

association {
  Company -> (union) Employees./employee
}

association {
  Company ->(subsets employee) Employees.workers[*]
}

[w00lf]

Associations

• Def.- An association describes a set of tuples of typed instances.
• The multiplicity of an association specifies how many objects of the opposite class an object can be associate with.
• If this number is variable, we state a range, that is, the minimum and maximum values.
• A minimum of 0 means that the relationship is optional (the relationship exists, nevertheless, but the number of elements is 0).

Association-Notation & Semantics

• Roles and Constraints: an association is represented by a straight line between the participating properites. At least two properties participate in an association.

Proposal:

class Customer {
}

class CustomerAccount {
}

class BookingPosition {
  -bpos:
}

Customer [1] <-(belongs to) [1] CustomerAccount#+account

CustomerAccount [1] <>-> [*] BookingPosition#-bpos

Association name

• Each association can be given a name an a reading direction within a small filled triange.
• The reading direction does not refer to the navigability of the association.
• At either end of the association, role names can be added to describe in more detail what roles the objects have within the relationship.
• These roles are the names of properties (for example, attributes), which belong to the association or to one of the participating classes.
• Is possible to add visibility information to either end of the association.
• If an association end is declared private (-), then the object itself (i.e. the operations of this object) can use the association, but neighboring classes have no access (like a private attribute).

Proposal:

class Company
class Employees
class Managers {
  generalization Employees
}
class Workers {
  generalization Employees
}

association {
  Company ->(subsets employee) Managers.bosses[1..*]
}

association {
  Company -> (union) Employees./employee
}

association {
  Company ->(subsets employee) Employees.workers[*]
}

Does this mean that we need to support both arrows syntax and generalization, aggregation keywords in diagram objects? In https://github.com/lutaml/lutaml-uml/issues/8#issuecomment-668652515 it is mentioned that we should support implicit association syntax if an attribute has a type equal to one of the defined before classes, why can't we use this syntax instead?

[ronaldtse]

Does this mean that we need to support both arrows syntax and generalization, aggregation keywords in diagram objects?

That's what I was suggesting, maybe it's a good idea.

Does this mean that we need to support both arrows syntax and generalization, aggregation keywords in diagram objects? In #8 (comment) it is mentioned that we should support implicit association syntax if an attribute has a type equal to one of the defined before classes, why can't we use this syntax instead?

We do have to differentiate between implicit and explicit syntax because of referencibility.

But the "implicit" syntax is only for convenience.

In the beginning we probably should first support the explicit syntax:

association {name, optional} {
  // type {type of association}
  type uses

  // end {entity} {end attributes}
  // end {entity}#{property} ({end label}) {end attributes} [cardinality]
  end Managers#+bosses {subsets Employee} [1..*]
}

How about this?

class Association {
  +association:
}
class Type {
  +endType:
}

association AssociatingTypeAndAssociation {
  type uses
  from Association#+association {subsets relationship}[*]
  to Type#+/endType {readOnly, subsets relatedElement} [1..*]
}

[ronaldtse]

@w00lf I think if we can reproduce the diagrams in UML spec then we should have achieved most of the UML syntax.

[w00lf]

association syntax was implemented in the gem.