LSPS Documentation
A data type model comprises all user-defined data types called records along with their relationships. The purpose of records and their relationships is to define the data structure that accommodates the business data used in your model.
A record represents a complex data type, such as, a person, product, service, etc.
On runtime, a record is used as a blueprint for its instances, which represent business objects: While an Invoice record defines the structure of an invoice, a particular invoice is represented by an instance of the Invoice record: the instances are created when the new operator is encountered; for example, you can create a person record instance of the Person record as new Person("Doe", "John", date(1982, 1, 14)). For further information on the behavior of operators when a record is involved, refer to the Expression Language guide.
The structure of a record is defined by a set of fields, for example, a record Persona could have the fields surname, firstName, and dob.
A record can inherit fields and properties from another record: it can become the subtype of a record. In such an inheritance relationship, it is frequently required that the supertype record be never instantiated: to apply this restriction, a record is defined as abstract. On the other hand, if a record cannot be used as a supertype, it is marked as final.
To prevent any changes to a record instance, a record is read-only. The record instance can be initialized and deleted during runtime; however, neither the record instance nor instances of its subtypes can be modified. Note that read-only records can only be targets of data relationships, not their sources.
If a record should not be accessible from model instances, it can be marked as a system record. System records cannot be instanced or modified from model instances. Such operations can be performed only by custom objects implemented in Java in your LSPS application code.
A structure of a record is defined by its record fields with each field being of a particular data type. Simple data types should be used preferably.
Inheritance is an oriented relationship between two records in which the source Record is a more specific record than the target record, for example, the Person record as a supertype of the NaturalPerson and LegalPerson Records. The subtype record adopts all fields of the supertype record and the supertype's supertype records, etc. Hence a subtype is able to substitute its supertype in any operation valid for the supertype.
A inheritance relationship cannot be cyclic, for example, if type T has subtype V, the subtype V cannot have T as its subtype.
A subtype record inherits all fields of its supertypes. Hence a supertype can be used instead of its subtype. Let's assume a record 'Person' with fields date_of_birth and mothertongue. This record is the supertype of the record Employee. The Employee subtype contains the date_of_birth and mothertongue fields inherited from Person, and additional salary and position fields. Wherever the Person type is used, the Employee type can be used; however, not vice versa since the salary and position values would be missing.
If a record field is read-only, its value is set on model instantiation and cannot be changed during runtime. The setting is preserved when inherited, that is, if record A contains a read-only field A and record B is the supertype of record A, then the inherited Field remains read-only.
The record import mechanism serves for importing records defined in an imported module or in another data type definition. Such imported records are referred to as record imports.
Record imports unlike records have the following limitations:
Note: These rules do not apply if the shared record of the record import is defined in another data type definition of the same module.
A data relationship serves to establish logical connections between two records: the relationship defines the properties of navigation to either ends. Though one end is designated as the Target and the other as the Source end of the relationship, the relationship works both ways equally and properties of the navigations to either end are defined for both ends (they are symmetrical).
A relationship can be cyclic; that is, the source and target can be the same record. For example, an employee might need to be in a relationship with another employee where both are represented by instances of the same Employee record.
Note: Read-only records can only be targets of data relationships, but not their sources. This prevents a possible inconsistency of data.
Data relationships define the following:
Example: The records Author and Book are connected with a relationship. The end pointing to the Book is named "books" so you can navigate from the Author record to the Book record. Hence when you define a variable of the Author type, you can define as part of the definition also the Author's book. The relationship end pointing to the Author does not have a name. Therefore, you cannot create a Book with its Author.
Single: only one record instance of the record can be on this end of the relationship.
For example, let's assume Sport Shoes and Production Batch records: a pair of shoes is produced as part of only one batch; hence the relationship from the Sport Shoes to the Production Batch has Single multiplicity.
Set: multiple different record instances can be on this end of the relationship.
In the example, this would be the multiplicity on the relationship end pointing to the Sport Shoes.
If the relationship connects two shared records, the Set multiplicity can define the Order By property. The property defines the database column that is used to order the related record instances. If no value is specified, the instances are ordered according to the primary key. For example, if the shared record Person has a navigable Set relation to the shared record Citizenship and defines the Order by property as countryCode, then the Citizenship record instances fetched as related record instances by the expression Person.citizenship will the ordered according to the countryCode.
Note: If one end defines the List multiplicity and the other end a Single multiplicity, then for every item of the List exactly one item in the other end is available. Such a relationship does not handle situations where one entity is available multiple times in the list. In this case, a join table is needed.
A composition is a "target-is-part-of-source" relationship: the value at the target end cannot exist by itself, that is, without a source value. If the source value is removed, all its target values are removed.
The source end of a composition relationship must be of the single multiplicity, while the target end can be of any multiplicity: when the value at the source end is deleted, the values at the target end are deleted as well–cascade delete takes place.
The record instances in a relationship are deleted depending on the relationship multiplicity as follows:
null. 
null. 
Shared records serve to persist data: Instances of shared records are persisted in a database, unlike instances of common records and hence survive their context. Any readings, modifications, and deletions of shared record instances are immediately reflected in the mapped database entry.
A shared record is mapped to a database table and its fields are mapped as the table columns. Note that if a fields of a shared record is of a different type than the Boolean, Integer, Decimal, String or Date type, you need to define the BLOB size so that a sufficient space is reserved in the underlying database column for the data (for information on LSPS implementation of shared records and the related mapping and fetching mechanisms refer to Process Design Suite User Guide.
Enumeration is a special data type that holds literals. The literals represent the possible literal values of the enumeration object and are called in the form <enumeration_name>.<literal_name>. The comparison operators =, !=, <, >, <=, >= can be used on the literals of the same enumeration type. Since the literals are arranged as a list of values, comparing enumeration literals is based on comparing their indexes: The order depends on the order of the literal as modeled in the enumeration.
Enumerations don't engage in relationships: they cannot be targets or sources of inheritance or data relations.
In addition to the common modeling element attributes, an enumeration defines the Deprecated flag, which signalizes that the enumeration will be removed in the next version of the model or application. In Living Systems® Process Design Suite, if the attribute is true, the validation displays an information message that the enumeration is deprecated.
