EXPRESS G the graphical language

Owned by Former user (Deleted)
Last updated: Sept 14, 2017

Notations for simple data types

The notation for an EXPRESS simple data type is a rectangular solid box with a double vertical line at the right end of the box. The name of the data type is enclosed within the box, as shown in Figure 10.

Figure 10: Notations for EXPRESS simple data types

 

Symbols for defined data types

The symbol for a defined data type consists of a dashed box enclosing the name of the TYPE, as shown in Figure 11.

Figure 11: Notation for an EXPRESS defined data type.

 

Notations for constructed data types

The notations for the EXPRESS constructed data types, SELECT and ENUMERATION, are dashed boxes. The name of the data type is enclosed within the box as shown in Figure 12.

Figure 12: Notations for EXPRESS constructed data types

 

The symbol for a SELECT data type consists of a dashed box with a double vertical line on the left.

The symbol for an ENUMERATION data type consists of a dashed box with a double vertical line on the right. EXPRESS-G does not provide for the representation of the enumerated list.

EXPRESS only allows the SELECT and ENUMERATION data types to be used as a representation of a defined data type. EXPRESS-G provides abbreviated notation whereby the defined data type name is written within the dashed box representing the SELECT or ENUMERATION, instead of the data type name, and the defined data type symbol is not given as seen in Figure 13

Figure 13: Abbreviated notations for the EXPRESS constructed data types when used as a representation of defined data types.

 

Alternatively, EXPRESS constructed data types may also be presented in conjunction with defined data types as illustrated in Figure 14. It is worth noting that the notations illustrated in the upper half of the Figure 14 are the equivalent of the notation shown in the lower half.

Figure 14: Example of alternative methods for representing an ENUMERATION

 

Notations for entity data types

The symbol for an entity data type consists of a solid box enclosing the name of ENTITY, as shown in Figure 15.

Notations for functions and procedures

EXPRESS-G does not support any notation for either FUNCTION or PROCEDURE definitions.

Notations for rules

EXPRESS-G does not support any notation for a RULE definition. The names of entities that are parameters in a RULE may be flagged with an asterisk.

Figure 15: Notation for an EXPRESS entity data type.

 

Notations for schemas

The symbol for a SCHEMA (Figure 16) is a rectangular solid box with the name of the SCHEMA in the upper half, which is divided from the lower half of the box by a horizontal line. The lower half of the symbol is empty.

Figure 16: Notation for a schema.

 

Relationship

Figure 17 illustrates four different styles of line used in EXPRESS-G to denote a relationship.

Figure 17: Relationship line styles

 

A relationship for an optional attribute of an entity data type is presented as a dashed line. A schema- schema reference is presented as a dashed line. An inheritance relationship (i.e., a subtype and supertype relationship) is presented as a thick line. All other relationships are presented as normal with solid lines. Relationships are bi-directional, but one of the two directions is emphasized. If an entity A has an explicit attribute that is entity B, the emphasized direction is from A to B. In EXPRESS-G, the relationship is marked with an open circle in the emphasized direction, in this case, at the B end of the line. For an inheritance relationship, the emphasized direction is toward the subtype, i.e., the circle is at the subtype end of the line.  Relationship directions in a diagram are illustrated in Figure 18, the diagram consists of six entity data types, two defined data types and one simple data type. Entity address has two subtypes (in a one of relationship), namely personal_adress and organizational_adress. The entity organizational_adress has a required attribute, which is a defined data type called text, which is a STRING data type. The entity organizational_adress also has an entity as an attribute, which is a set of (not shown in the diagram) the entity data type organization. The entity organization has an optional attribute, which is a STRING data type called identifier.  The entity data type personal_adress has a set of (not shown in the diagram) the entity data type person as its attribute. The supertype organization has organization_employee as a subtype, and organization_employee has a list of (not shown in the diagram) the entity data type person as its attribute.

Figure 18: Diagram illustrating relationship direction

 

It is worth noting that:

  • Although the example diagrams show only straight relationship lines, lines may follow any path (e.g., they may be curved).

  • It may not always be convenient to lay out a diagram without some of the relationship lines crossing each other. The means of distinguishing crossing points is left to the author of the diagram.

Page references

When there is a relationship between definitions on separate pages, the relationship line on the two pages is terminated by a rounded box. The rounded box contains a page number and a reference number, as shown in Figure 19. The page number is the number of the page where a referenced definition occurs. The reference number is used to distinguish between multiple references on a page. The composition symbol on the page where the reference originated contains the name of the referenced definition. The rounded reference box on the referenced page may contain a parenthesized list of the page numbers where references originated.

NOTE - The use of page referencing is shown in Figure 1 and Figure 2. The rounded box labeled 2,1 from the person indicates that the definition is to be found on page 2 of the diagram as reference 1. On page 2 of the diagram as shown in Figure 1: Page 1 of 2 of a complete entity level diagram of an abstraction of a person.

Figure 2, the round box symbol reference into date indicates that this definition is referenced from another definition on another page of the diagram.

The number in parentheses indicates that the referencing item is to be found on page 1 of the diagram.

Figure 19: Notations for page references

 

Inter- schema references

A rounded box enclosing the name of the definition qualified indicates inter- schema references by the schema name, as shown in Figure 20. A dashed rectangular box encloses definitions accessed from another schema via an EXPRESS REFERENCE statement. If the definition is renamed, the new name may be placed within the box below the rounded box. A solid rectangular box encloses definitions accessed from another schema via an EXPRESS USE statement. If the definition is renamed, the new name may be placed within the box below the rounded box.

NOTE - The use of inter- schema references is shown in Figure 24.

Figure 20: Notations for inter-schema references

 

Entity level diagrams

EXPRESS-G may be used to represent the definitions, and their relationships, within one schema. The components of this diagram consist of simple data types, defined data types, entity data types, and relationship symbols, together with role and cardinality information as appropriate, which represent the contents of a single schema.

Role names

In EXPRESS an attribute of an entity data type is named for the role of the data type being referenced when an instance participates in the relationship established by the attribute. The text string representing the role name may be placed on the relationship line connecting the entity data type symbol to its attribute symbol.

Cardinalities

The attributes of entity and defined data types can be represented by aggregation data types (i.e., LIST, SET, BAG and ARRAY). In EXPRESS-G, an aggregation is indicated on the relationship line for the attribute, following the attribute name. Only the first letter of the aggregation data type (i.e., A, B, L or S) is used and the ‘OF’ symbol is omitted. If an aggregation is not specified, the cardinality is one for a required relationship and zero or one for an optional attribute.

Constraints

EXPRESS-G provides no methods for defining constraints, other than cardinalities. The fact that something is constrained within an EXPRESS data specification may be denoted by preceding the name of thing with an asterisk (*) symbol. The following rules apply:

  • if an entity is a parameter in an EXPRESS RULE, the name of the entity may be preceded by an asterisk;

  • if an attribute of an entity is constrained by either a UNIQUE clause or a WHERE clause within the entity, the name of the attribute may be preceded by an asterisk;

  • if a defined type is constrained by a WHERE clause, the name of the defined type may be preceded by an asterisk;

  • if an aggregation data type is constrained by a UNIQUE keyword, the first letter of the aggregation may be preceded by an asterisk.

Figure 21: An entity level diagram illustrating the direction of a relationship

 

Constructed and defined data types

A select data type is represented by the select data type symbol (see Figure 12). A defined data type is represented by the type definition symbol (see Figure 11) enclosing the name of the definition, the representation data type definition, and a relationship line from the defined data type definition to the representation data type definition. The cardinality of the representation may be placed on the relationship. It is worth noting that:

  • EXPRESS-G does not provide a mechanism for nothing the enumeration items.

  • A defined data type representation can be seen in the string type in Figure 20.

Entity data types

EXPRESS-G uses the solid box symbol (see Figure 15) for ENTITY definitions. The box encloses the name of the entity data type. In EXPRESS-G an ENTITY may:

  • be part of an acyclic inheritance graph;

  • have explicit attributes;

  • have derived attributes;

  • have inverse attributes.

Each explicit or derived attribute in an EXPRESS entity gives rise to a relationship in the corresponding EXPRESS-G diagram. The role name of the attribute may be placed on the relationship line, together with the cardinality, which follows the attribute name. A derived attribute is distinguished from an explicit attribute by preceding the name of the attribute by the characters DER enclosed in parentheses, i.e., (DER) In the case of where there is an inverse attribute defined for an attribute, the name and cardinality of the attribute is placed on the opposite side of the relationship line to the attribute name of which it is an inverse. The characters INV enclosed in parentheses, i.e., (INV), precede the name. It is worth noting that:

  • Typical entity level diagrams are shown in Figure 1 and Figure 21.

  • The indication of domain rules applied to attributes can be seen on the roles husband and maiden- name in Figure 1.

  • An example of entities constrained by Rules is shown for the male and female entities in Figure 1.

Subtype/supertype

Thick solid lines connect the entities forming an inheritance graph. The circled end of the relationship line denotes the subtype end of the relationship. When a supertype is ABSTRACT the characters ‘ABS’, enclosed by parentheses, i.e., (ABS), precede the name of the entity within the entity symbol box. EXPRESS-G provides a limited notation for indicating the logical structure of an inheritance graph. The ONEOF relation may be indicated by a branching relationship to each other, together with the digit 1 being placed at the branching junction. It is worth noting that:

  • The diagram in Figure 22 shows that the entities Communication, Mail, e_mail and Fax are subtypes of the supertype Document. No implications can be made about the logical relationships between these subtypes (i.e., AND or ANDOR). An instance of super possibly has no subtypes because it is not ABSTRACT. The entities Sale_communication and Support_communication are in a ONEOF relationship to each other.

  • Figure 23 provides an EXPRESS-G diagram showing Phone_book_index as being an Abstract Supertype.

Figure 22: An entity level diagram illustrating super-type and sub-type relationship

 

EXPRESS permits the re-declaration of supertype attributes within a subtype provided the re-declaration attribute is a specialization of the supertype attribute type. In EXPRESS-G a re-declared attribute is represented in the same manner as its supertype attribute, but with the addition of the characters RT (re-declared type) enclosed in parentheses, i.e., (RT), before the name of the attribute.

Figure 23: An entity level diagram illustrating re-declaration

 

Figure 22 illustrates some of the forms of attribute re-declaration. Entity sub_a re-declares the attribute attr from its supertype to be a subtype of its supertype attribute. Entity sub_b has an optional attribute of type NUMBER. In its subtype, this is re-declared to be required attribute of a REAL type. Inter- schema references When a definition in the current schema refers to a definition in another schema, the inter- schema reference symbol is used and contains the qualified name of the definition. Figure 24 shows entity level diagrams of (extract of) three schemas. The complete diagram (the aircraft schema) consists of three schemas, aircraft, aircraft_components and design_data, and one of the aircraft schema entities is a subtype of supertypes defined in the two referenced schemas. Since an entity level diagram only consists of those things defined in a single schema, the representation of the aircraft schema in this example requires the inter-schema references shown.

 

Figure 24: An entity level diagram illustrating inter-schema referencing

 

Schema level diagrams

A schema level diagram consists of the representation of multiple schemas and their interfaces. The contents of an EXPRESS-G schema level diagram are limited to the schemas comprising the diagram and the schema interfaces. The following are included:

  • schemas that refer to another schema by means of USE;

  • schemas that refer to another schema by means of REFERENCE;

  • names of things that are referenced or used.

A normal width relationship line presents the USE interface from the using schema to the used schema, with an open circle denoting the used schema. A dashed relationship line shows the REFERENCE interface from the referencing schema, with an open circle denoting the referenced schema. Definitions that are used or referenced may be shown as a list of names adjacent to the relevant relationship line. The rename of a definition is indicated by following the original name of the definition by a greater than (>) sign and a rename. A diagram with two schemas is shown in Figure 25. The top schema has an interface to the geom schema. In particular, the top schema references the surface and uses the curve and points definitions from the geom schema. The point definition is renamed node in the top schema.

Figure 25: Schema level diagram

 

If a schema level diagram extends over more than one page and the schema interfaces cross the page boundaries, then the page referencing symbols are used. Figure 26 shows a schema level diagram consisting of several schemas.

Figure 26: A complete schema level diagram

 

Complete EXPRESS-G diagrams

In EXPRESS-G a complete diagram is one that, within the limits of the EXPRESS-G notation, accurately represents all the definitions, relationships and constraints using either an entity level or schema level diagram.

Complete entity level diagram

Diagrams that present a complete diagram of single schema have contents defined by the following rules:

  • Each page shall have a title starting with the words: Complete entity level diagram of.

  • Each page is numbered in the form Page X of N, where N is the total number of pages forming the diagram, and X us the particular page number;

  • All entity data types, defined data types, and simple type symbols used within the single schema are displayed;

  • Schema symbols do not appear;

  • All relationships, attributes names, and cardinalities are displayed;

  • All attributes, including explicit, derived and inverse attributes are displayed;

  • All inheritance (i.e., subtype/ supertype) relationships are displayed;

  • All ABSTRACT supertypes are marked;

  • All ONEOF subtype relations are marked;

  • All definitions used or referenced from another schema are presented by the rounded box symbols, together with the surrounding rectangular boxes of the appropriate style (solid for used definitions and dashed for referenced definitions).

  • Any rename is presented in the relevant inter- schema reference symbol;

  • All entities that are constrained by a RULE are marked with an asterisk (*);

  • All attributes that are marked with an asterisk (*);

  • All defined types that are constrained are marked with an asterisk (*);

  • All aggregation types that are constrained are marked with an asterisk (*).

All entity-entity relations not marked with an inverse attribute are interpreted to have a cardinality of zero or more. No logical structuring can be inferred from an unmarked subtype relation, except that is not a ONEOF relation.

Complete schema level diagram

Diagrams that present a complete schema level diagram has contents defined by the following rules;

  • Each page is titled, with the starting title with the words: “Complete schema level diagram of...”;

  • Each page is numbered in the form Page X of N, where N is the total number of pages forming the diagram, and X is the particular page number;

  • All schemas used are displayed;

  • Entity, type and simple symbols shall not be displayed;

  • All schema-schema relationships, USE and REFERENCE, are displayed;

  • The names of all definitions that are either used or referenced are attached to the relevant relationship line, together with any renames. If no names are attached to a relationship line, this is interpreted to mean that the entire schema is used or referenced.

When developing models or displaying diagrams, it is useful to be able to display diagrams at varying levels of abstraction. For example, not all attributes are given on the diagram, or role names may not be shown. This is outside the scope of EXPRESS-G, but is recommended that the level of abstraction be agreed and documented before development starts. Further, it is recommended that the diagram titles reflect the abstractions being used.