-
Notifications
You must be signed in to change notification settings - Fork 0
Terminology
Here’s some terminology used throughout this document.
These refer to the right and left hand sides of an assignment expression.
This is the model execution (MX) domain. The MX domain “understands” xUML and is able to run the models efficiently on some class of platform such as embedded, cloud, etc. The book [Models to Code] explains the concept in depth.
The greater UML standard defines both signals and events. A signal is something you send and an event is something that happens. One kind of thing that can happen is the arrival of a signal delivered to some instance. A time event is another kind of event, for example, in the greater UML.
In xUML, the only kind of thing that can happen is an event. And all events are triggered by the delivery of a signal. Time isn’t special, it is just the arrival of a signal at a designated time or some delay.
Consequently, in xUML, the terms signal and event can be used interchangeably.
When describing a method or state activity, this refers to the class upon which the method or state is defined.
An instance of a class. Also an object. The terms may be used interchangeably. We generally avoid use of the term “object” as it is so often confused with its implementation counterpart.
The instance that is executing the activity (state, method, operation). It is typically used when describing the starting point of relationship navigation.
An instance that belongs to some class other than the local class.
A set of one or more attributes of some class such that a set of values suppled for each of these attributes will match either zero or one object in the associated class population. For example, Waypoint attributes Latitude and Longitude, supplied with values should select either one or zero Waypoint instance assuming the two attributes, taken together, constitute an identifier.
An identifier is irreducible so the terms “identifier” and “irreducible identifier” are synonymous. This means that for the set of attributes that comprise an identifier, there is no proper subset that conforms to the identity constraint. It is taken from the relational theory definition of a key.
This is a set of referential attributes that refer to components of an identifier such that all components of the identifier are targets of the referential attributes. More formally, assume we have some identifier with attribute components (i1, i2 .. iN). A reference is a set of attributes (r1, r2 .. rN) such that r, where a is some number of the set element, refers to i. For example, a Mission Following Aircraft may have the attributes Next Waypoint Latitude and Next Waypoint Longitude which, taken together, form a reference to a Waypoint.
A class’s identifier, populated with attribute values serves as a reference to an instance of that class. A value pair corresponding to the Latitude, Longitude identifier of a Waypoint serves as a reference to some instance of Waypoint if there is, in fact, an instance of Waypoint at the specified location.
An attribute that refers to some identifier attribute of a class on the opposite side of an associated relationship is referential. For any given instance on the referring side, the value of the referential attribute must match an existing value for the referenced identifier attribute for some instance on the other side of the relationship.
Thus Mission Following Aircraft.Next Waypoint Latitude is a referential attribute since for any instance of Mission Following Aircraft, the value of Next Waypoint Latitude must match the value Waypoint.Latitude for some instance of Waypoint.
A super identifier is a reducible identifier. So it is an identifier with one or more additional attributes taken from the same class. By contrast, the identifier we mostly use in xUML is an irreducible identifier in the sense that if any attribute is removed, it is no longer an identifier at all.
In rare circumstances you may want to build a reference to a super identifier instead of an identifier to include some referential attribute that helps us express a constraint. The term “super identifier” is analogous to the relational theory definition of a superkey.
Assume Tail Number is the identifier of the class Aircraft. Given some value for Tail Number, NX1334Q, let’s say, exactly zero or once instance of Aircraft will be selected. The same could be said of the super identifier Tail Number + Airspeed. NX1334Q + 340 knts will still yield zero or one instance of Aircraft. But a super identifier is reducible in that we can remove Airspeed and still have a valid identifier.
The number of instances that can participate in an association. 1:1..* = one to many, 1:1 = one to one
This term indicates that one side of a multiplicity could involve zero instances. Thus 1:0..* means that there can be zero instances mapped on the many side. In other words if there is a 0 on a multiplicity side, it is conditional.
Copyright 2020, 2021, 2022, 2023 © Leon Starr under MIT Open Source License
- Why they are problematic
- Instance attribute creation values
- Boolean values
- Special values
- Enumerated values
- Action block
- Statement
- Single line action
- Multiple dependent actions on a single line
- An action spread across multiple lines
- A conditional group of single line actions
- Comments
- Finding instances
- Attribute access
- Creation and deletion
- Subclass migration
- Creating a table from a class
- Creating a table with a definition
- Converting a table into a class
- Set operations on tables
- Set comparisons on tables
- Join
- Rename
- Extend
- Aggregation
- Rank
- Image
- Input values
- Signatures and name doubling
- Output values
- Execution order
- Sequential execution
- Conditional execution
- Signals
- Scrall has no for_each action
- Iteration