Modelling Stencil  (version 2003.0.0.1, juin 2005)

From the start, Perceptory has been conceived to integrate the concept of spatial and spatiotemporal PVLs (developed in Bédard 1999) to the components of the version 1.4 UML formalism 1 class model which are used in our projects on a conceptual level. Compared to the original UML formalism, Perceptory only keeps the elements which we feel are useful for databases on a conceptual level and this after reflecting on more than 10 years of experimenting with different formalisms in many concrete projects. The elements explicitly supported by the Perceptory modelling stencil include a very large majority of UML elements which include, of course, the basic elements (package, class, attribute, operation, association, generalization). Other UML elements are supported in an optional mode and some non standard components have been added (cf. Table of the UML components supported by Perceptory, non supported or added).

Each of the components supported by Perceptory is explained in great detail. All throughout the text, we distinguish the manipulations that are unique to the UML formalism from those that are specific to our adaptation of the formalism in Perceptory. Therefore, we present these two aspects so it is easier to identify what is commonly used in the UML and what is unique to our work methods (i.e. internal manipulations). This distinction is presented as follows :

UML: Semantics of UML formalism version 1.4

Internal: Specific semantics used by our work group

These elements are explained in the following pages starting with Project and Schema. As for the more specific group of manipulations unique to spatial or spatiotemporal PVLs, they are described in the Spatial and SpatioTemporal PVL section.

Finally, these pictograms refer to others interesting sections of Perceptory Website.

Perceptory Tutorial
Frequently asked questions (FAQ)

1 For more information on the UML formalism, go to the following address http://www.rational.com/uml/ where you can download documents explaining the formalism or go to the suggested references in this site.


Perceptory stencil components

When you start up Perceptory, you will see two types of elements appear: the modelling stencil and the Schema windows to identify the model.

The modelling stencil includes the following elements :
package
class
enumeration domain
(stereotyped class)
association
generalization
comments

 

 

The Schema identification section includes the following elements : sche.bmp (86454 bytes)
 

 

SCHEMA
The schema window allows the user to describe the schema is to be created. A project can have many schemas who each correspond to a Visio file (ex. a federative schema and some personalized views of this schema.

sche.bmp (86454 bytes)
Project Name: Name that identify the project in the schema.
File Name: File name which store the schema.
Schema Name: Indicates the name of the schema in the data dictionary.
Version: Version number of this schema's last version.
Organization: Organization name of the producer.
Version Date: Date of this schema's last version.
Individual: Individual name of the producer.    
Some complementary information is added to the object class dictionary (ex. project schedule, spatial reference system, contextual information). This is where we indicate the metadata which applies to the Project dataset. The object class dictionary can be accessed by the Open Dictionary command of the right mouse button.
Creating a new schema and define language parameters

 CLASS

From the database standpoint, it is the grouping of a set of tangible phenomena, living beings, concepts or events in reality which are classified as being of the same category and for which we can manage the same information or do the same operations. Any individual object (ex. building on 143 St.-Jean Street) is an instance or an occurrence of it's class (ex. the building class which groups together all the house, commerce, industry occurrences.

The class is made up of three sections which respectively contain : its name and stereotype, its attributes and its operations. The last two sections only appear if they have contents.

Stereotype: The stereotype allows to specify a particular role for a class. Perceptory supports stereotype: metaclass, stereotype and data type. The stereotyped class 'enumeration domain' exists directly into the stencil and must be used to define enumerated domains.

class name : This section contains the name of the class. Perceptory writes the name directly in capital letters in the model, no matter how it is written in the dictionary. cf. example 1 : BUILDING. The name of the class is preceded by a slash " / " when the class instances are derived (i.e. created from or made up of other elements of the model) ex. /CONSTRUCTION which would be derived from the HOUSE, COMMERCE and INDUSTRY classes. It is not necessary for the set of instances to be derived to use the slash (ex. derived for a territory and captured for the rest of the territory). Therefore, this distinction must be made in the object class dictionary in the deviation rule field.

attribute and derived attribute : The attribute can be derived. A derived attribute is made up of other elements of the model. Ex. age of the building deducted from the date of construction. The derived attribute is written with an slash "/". (cf. example 1: age).
operation : Process which can be done to describe the object's behavior. (cf. example1: MarketValueCalculations)



example 1


Add modelling class into the model
Create an attribute or operation
Deriving a class or an attribute

data typed attribute: The attributes can be associated to a data type. Those attributes are composed by a set of simpler attributes. The data type name is written after the (:) following the attribute name into the class.
cf. example1: The address attribute may be associated to the data type
'address' defined by the civic number, street name, city and postal code. This allows the user to reduce considerably the number of attributes in a class and normalized this group of attributes according to a specific type.

Create a data type for an attribute.

multiplicities added to attribute: Multiplicities can be added to the attribute. The functionality is used to avoid repeating the same attribute more than once in the class when it's number is unknown at this stage of modelling, or to avoid making it into a separate class. An attribute is not necessary when it has a minimal cardinality of 0.


Adding multiplicities to attribute

cf. example 1 : The address attribute 1.2 means that a two-story building can have an address for each apartment on the different floors, if it is on a corner. 

ENUMERATION DOMAIN

The stereotype 'enumeration domain' allows to define domain values which is the set of possible values for an attibute. The stencil allows to automatically access to forms which allow to defin each values composing the domain.

cf. Exemple 2. The enumeration domain 'utilization' is associated to the attribute utilization of the class building . It allows to limit the possible values of this attribute to those defined in this stereotyped class.


exemple 2
Create an enumeration domain

 ASSOCIATION, AGREGATION AND COMPOSITION

ASSOCIATION:
The association represents the structural relationships between object classes. It is represented by a line between two classes and this line can optionally integrate a verbal form, active or passive, to its environment to give a specific sense to the relationship.

AGREGATION:
An aggregation represents a non-symmetrical association in which one of the extremities plays a predominant role in relationship to the other extremity. There can be no 0 in the aggregate (parent) multiplicities (there always has to be at least one child).

COMPOSITION:
A composition represents an association in which one extremity makes up the other extremity. It is a MAKES UP relationship which is of a physical or material nature. The aggregate (parent) multiplicity can only be worth 0 or 1. This means that the composite can only be used to compose 0, or 1 compound element.

 

Association names: The orientation of the names of the association is optionally indicated by a triangle pointing towards the class designated by the verbal form. However, Perceptory automatically puts the triangles when the relationship is created.
There can be 2 or more associations of different types between the same two classes. (cf. example 3: TO LIVE IN and TO HAVE between person and building.

The association can be recursive, i.e. affect only one class. (cf. example 3. BUILDING which is near a HOUSE.

The association can be derived from other associations. The name of the association is then proceeded by a slash " / ". (cf. example 3. TO BE NEIGHBORS between people is derived from the relationships TO BE OWN between buildings and TO LIVE IN between people.)

 

example 3

The aggregation is represented in the schema by a link with a little white diamond on the aggregate's side.

There exists multiple aggregation where one element is aggregated into 2 superior elements.

The composition is represented by a link with a little black diamond on the composite's side.

Creating an association
Deriving an association.

Multiplicities: Indicate the maximum and minimum number of occurrences of other class objects that can be linked to an occurrence of a class object. In that case, the cardinality is indicated following the name of the association. (cf. example 3: BUILDING is lived in by 0,N people.)

Adding multiplicities to association

Association-class: An association class is added to an association when this association has attributes of operations (cf. example 3: contract number for OWNING, there can be many different contracts between the same people and the same buildings);

A class of this type is treated like any other class and can therefore interact with other relationships in the model.


Creating association-class

 
Constraint (for one or more associations): A constraint is any semantic relationship between modelling elements. It is an expression that specifies the role or scope of one or more modelling elements in an object class model.
The constraint can affect only one relationship or a group of relationships

If the need arises, a black triangle indicates the meaning of the constraint.

Here are some examples of a values that can take a constraint that applies to an association :

{sub-set}: indicates that an association is included in another association (cf. example 3: the occurrences of the relationship LIVES IN represent a sub set of the occurrences of the OWNS relationship, which entails that the owners must live in one of their houses.

{or-exclusive}: specifies that for a given object, only one association among a group of associations is possible. (cf. example 4: a PARCEL is occupied by a PARK or a HOUSE or nothing, but never both at the same time.

{ordinate}: that the object represented by the association follow a precise order. (cf. example 3: PERSON owns HOUSE i.e. the owner acquires the houses in a specific order and the creation of the association occurrences follows the order of acquisitions.

example 4


example 5

Role: It is the extremity of an association that describes how a class sees another through an association. It is places at the extremity of an association (cf. example 5: the association between person (landlord) and person (tenant).

N.B. Often, using role can change the multiplicities of the associations concerned (cf. example 5: a person cannot have a and/or 0, N (for he is the landlord himself). However, the "tenant" always has at least one "landlord" (otherwise, he would not be a tenant.) The multiplicity indicated is the one which applies to the role, as in 1.N in our case.

Association-class: an association class is added to an association when you want to manage the spatial and temporal aspects of the association. That us when the PVLs are used in Perceptory.
Role: Technically, we use the role or name of the relationship to avoid any ambiguities that could come up during the applications of the multiplicities.
Aggregation/composition: Even though aggregations and compositions are supported by Perceptory, in reality, we do not make distinctions between the two. The scientific literature and our experience has demonstrated the ambiguity of the distinction between these two types of associations. Generally, we use the aggregation to represent the relationship because very often an obvious relationship of aggregate and component is apparent.

 GENERALIZATION/SPECIALIZATION

Generalization designates a classification relationship between a more general element (a super-type or a super-package) and one or more specific elements (sub-type or sub-package). It is a TO BE relationship which goes from the sub-type to the super-type. In the UML formalism, generalization and specification are considered like synonyms and are treated under the same generalization vocabulary. Perceptory does the same.


exemple 6

The generalization only applies to classes.
A super-type can have numerous sub-types and one sub-type can have numerous super-types; the generalization is called multiple for these last sub-types.
The attributes, operations and defined constraints are integrally inherited in the sub-types. Consequently, the defined cardinalities and associations on the super-type will affect the sub-types.
The super-type of a generalization can be abstract, i.e. only directly non instanciable; it does not make objects but server as a more general specification to sub-types. Every objects comes from sub-types. Its name is then in ITALICS (cf. example 6: BUILDING).
A class can be generalized simultaneously using many criteria.
Numerous constraints can apply to a generalization. They are indicated in brackets on the horizontal line of the generalization.
By default, a generalization is said to be {exclusive} or {disjointed}, i.e. that the object of the super-type as best the instance of a sub-type.
The {inclusive} or {bordering} constraint indicates that an object is built from a class obtained by a mix of one or more super-types (cf. example 6: a building can be both a house and a business at the same time.)
an {incomplete} generalization indicates that there are other possible sub-types for the generalization (incomplete list). Three points (...) can also be used to express this constraint. (cf. example 6: the list of sub-types could continue with teaching, recreational or religious establishments ...)
a {complete} generalization means that all possible sub-types are listed (complete list).

 

Adding generalization into the model

 

 PACKAGE

A package is an organizing element in the object class model it is a general mechanism to separate the models in themes or to regroup some elements of the model. The Package corresponds to a subset of models and posses different elements like the classes and the relationships. The Package is represented by a graphic symbol of a "folder".


example 7

The package has a name. It is written in capital letters in Perceptory (cf example 7: INDIVIDUALS or BUILDING)
A schema can have a combination of packages and other modelling elements (classes, relationships, etc.)
A package can have other packages, with no limits as to the number of times it can be interlocked;
The relationship (association, aggregation and generalization) between the elements included in the packages are possible.

Package:

In Perceptory, packages have links to the dictionary. It is possible to give name and description to the package.

All package elements which exist in a schema are now listed into the dictionary drop-down menu of other modelling elements. However, the user must consequently manually insure the coherence between the dictionary content and the model by adding in the dictionary, if desired, the name of the package for included elements.


Adding package into the model

COMMENTS

The comments serve to link brief formal comments to enlighten an element of the schema. These comments can be attached to the element of the schema with the connector included on the Comment object.

Adding comments into the model

 

Last update: 2005-06-06

Perceptory website

Dr Yvan Bédard Website

Contact