Class model semantics

Class Model Semantics

xUML class model semantics are an application of relational theory for the purposes of system and requirements analysis. And by “theory”, we’re referring to a branch of mathematics founded on set theory, functions and predicate logic. This is distinct from relational databases, which are an application of relational theory for quite different purposes. Whereas an RDBMS will be manipulated with some variant of SQL (Structured Query Language), our action language will instead be based on C.J. Date’s Tutorial D language. The advantage of this approach is that it gives us a simpler, leaner, more mathematical set of operations and structures for accessing and manipulating data. For this reason, Scrall doesn’t incorporate the awkward SQL’ishness of tool supported Shlaer-Mellor action languages. Instead we can take advantage of powerful nested expressions and other easily assembled building blocks.

Here is a brief summary of relational semantics relevant to action language.

A class is a named set definition. In the relational world this corresponds to a relvar (relational variable). A class defines a set of ordered pairs (a, t) where a is an attribute and t is a type (data type). We often visualize a class as a table header with a column for each (a,t) pair.

Every attribute has an associated type which establishes the finite set of possible values that may be assigned to that attribute. Rather than refer to (a,t) pairs, from now on we’ll just refer to attributes with the understanding that each has some assigned type.

An instance supplies a value for each attribute of a class defined table header. We usually visualize an instance as a row in the table. Row order and column order have no significance since no ordering has been defined on the corresponding set elements.

An identifier is a set of one or more attributes belonging to the same class such that values supplied for those attributes result in the selection of zero or one instance of the class.

Every class has at least one identifier.

An identifier is understood to be irreducible such that if any attribute is omitted, it is no longer an identifier.

A super identifier is an identifier combined with one or more additional attributes from the same class. These are usually not marked unless you use them to enforce constraints in a relationship.

A table consists of some header with a set of attributes. This includes the possibility of an empty set! A zero-attribute table is not only possible, but useful as an intermediate result in an activity. For example, sometimes you restrict an instance set based on some criteria, but don’t project on any of the attributes. The returned result is a zero-attribute table with either one or zero instances which corresponds to a true/false meaning. (You can’t have more than one empty instance returned since duplicate rows are never allowed in a table).

Note that a table can be created from a class by filling it with all attributes of that class and all instance data. It is useful to construct temporary non-class tables during the processing within an activity. For example, you might want a table of all Aircraft with only tail number and altitude values as part of a computation.

A tuple is a row of values in a table. In other words, it is a set of values where each corresponds to a header attribute-type pair.

An instance reference set is a table whose header is defined by an identifier with any number, including zero, of associated tuples / rows.

An instance variable is a variable that holds as its value an instance reference set. So an instance variable represents a set of instances of some class including possibly the empty set.

A table variable holds a set of tuples / rows corresponding to a header which may or may not correspond to any particular class. Tables are often formed by taking subsets of a class’s attributes and combining them across relationships with other class attribute subsets.

A scalar variable holds a single non-table value such as an integer, or arbitrarily complex structured value. A scalar is considered opaque in the sense that it cannot be accessed or parsed via table (relational) operations. Type specific operations, however, can be defined which can access designated components or apply unit conversions.

All relationships on the class model are formalized with referential attributes.

Actions are supported which make it possible to select and manipulate instance data and traverse relationships to find related instances.