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 :
|
|
| The
Schema identification
section includes the following elements : |
 |
| |
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.
|
|
|
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.
 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
|
|
|
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.
|
|
|
|
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.
|
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
|
 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. |
|
|
|
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.)
|
|
|
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. |
| |
|
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). |
|
|
 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
 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.
Last update:
2005-06-06
|
|
