G E O M A T I C A

VISUAL MODELLING OF SPATIAL DATABASES:TOWARDS SPATIAL PVL AND UML- Yvan Bédard, Centre of Research in Geomatics

Laval University, Québec City, Québec

This paper deals with today’s state of the art in spatial database modelling. In particular, it discussesvisual languages and related research. Major trends are described and an innovative language, termed sec-ond generat ion, based on a new concept cal led Spat ial PVL is presented. This Plug-in for Visual Languagesis used to extend the object-oriented s tandard language UML, and is implemented in a new freeware CASEtool called Perceptory.

Cet article traite de l'état actuel de la technologie dans la modélisation de bases de données à référencespat iale . Plus particulièrement i l porte sur les langages visuels et sur la recherche s'y rapportant . On y décrit lestendances principales et on y expose un langage innovateur, qualifié de deuxième généra t ion fondé sur unnouveau concept appelé PVL spat ial . Ce plugicie l de langages visuels complète le langage à obje ts s tandardUML et est présenté dans un nouveau gratuiciel d’out i l CADRE appelé Perceptory.

IntroductionThe last twenty years have witnessed wide-

spread development of spatial databases using GIS(geographic information systems) or CAD technolo-gies (computer-aided design) coupled with RDBMS(relational database management systems). Recentevolution of technology has introduced several al ter-nat ive methods for spat ial database building, includ-ing universal servers with spatial modules and view-ers, spatial engines or components accessed throughan API (application programming interface), Webservers with map viewing capabilities, data ware-houses, and mult idimensional databases. Especial lycomponent-based system development is rapidlychanging the way we implement spatial databases.The traditional two-tier client/server architecturesare being replaced by more complex, distributedmult i - t ier archi tectures . This diversi ty of solut ions, astronger integration with mainstream informationtechnologies, as well as the increasing complexity ofsystem architectures, are driving spatial databasedevelopers towards the general adoption of visualdatabase modell ing.

Visual database modelling helps us to under-stand and to describe more precisely the intendedcontent of a cl ient’s database. I t also helps us to mas-ter the complexity of the problem, to facilitate theexchange and the validation of ideas, to improve theprogramming process, and to ease the maintenanceof the system. In other words, database models canbe thought of as thinking tools, communicationtools , development tools , and documentat ion tools .

Database models are called conceptual whenthey depict the cl ient’s database purpose and phys-ical when they describe i ts software implementat ion.Underlying strategies used in these multi-level E/R(Entity/Relationship) and OO (Object Oriented)database modelling processes are described byBatini et al. [1992]; Cook and Daniels [1994b];Rumbaugh [ 1996]; Bédard [ 1999]. An example ofthe conceptual level database model is presented inFigure 1. I ts schema and dictionary are based on theOracle Enti ty/Relat ionship language, or formalism.

The objective of this paper is to present today’strends in spatial database modelling and to intro-duce a second generation of visual languages andCASE tools. The paper starts with an overview ofthe present state of the art of spatial database mod-elling focussing on the 1990s and onwards, intro-ducing the first generation of visual languagesdeveloped for spatial databases. Then follows adescription of the major trends influencing the waywe will build spatial database models in the nearfuture. These trends are used to introduce an inno-vative concept called Spatial PVL (Plug-in forVisual Languages). The first Spatial PVL is pre-sented. Finally, we show how a second-generationvisual language for spatial databases can be inte-grated into the Unified Modeling Language (UML)and can be implemented into a new CASE toolcalled Perceptory.

GEOMATICA Vol. 5 3 No. 2, 1999. pp. 169 to 186 1

0 B u s i n e s s U n i t sB u s i n e s s T e r m i n o l o g yD o c u m e n t sE n t i t i e s@aLOT

c! E n t t t i e s B u s i n e s s!Zl U U n i q u e Identifier En t rB c? RelationshipsEl 62 A t t r i b u t e s

FTI XI ClVlC NUMBER

g xrASSESSED_VALUE

El U S y n o n y m sB I PERSONU DatastoresC l D a t a I t e m s0 B u s i n e s s F u n c t i o n scl EventsC l E x t e r n a l sU Objec t ives

Cl Locations0 Critical Success Factors0 Key Performance Indicator13 Problems

Cl User De f ined Se ts

Text:EB Description

@NotesATM. lJMlSWM 1 AREA, POINT

SPATIAL COMf’OSlTlON ALTERNATEGEOMETRY 1 AREA, IF >6OOM’

‘! GEOMETRY 2 PoarT,R~6esM’

Ym BUILDING# CIV IC-NUMBER

, # STREET-NAMEo NUMBER-FLOORo YEARo ASSESSED-VALUE

is located on

I contains

‘HLOT# CADASTRAL-NUMBERo ASSESSED-VALUEOAREA

R\ owns

PERSON# FIRST-NAME# LAST-NAMEo JOB-TITLEo ADDRESS

Figure 1: Extract of an Entity/Relationship conceptual database model and dictionary (Oracle Designer/2000 extended with a Spatial PVL).

170

The First Generation of VisualLanguages for Spatial Databasesand the New Trends

Several visual modelling languages exist, themost recent ones relying on the object-oriented (OO)paradigm. Popular examples include Coad andYourdon [1991a, 1991b]; Rumbaugh et al. [1991];Shlaer and Mellor [1991]; Jacobson et al. [1993];Martin and Ode1l [1993]; Booch [1994b]; Cook andDaniels [ 1994]. The last three years have seen a uni-fication of efforts to develop the Unified ModelingLanguage (UML) (see Booch et al . [ 1999] for a com-plete description). UML is a de facto and officialstandard recognized by the Object ManagementGroup. The only contender to UML is the OpenModeling Language (OML) described by Firesmithet al. [1998]. However, OML doesn’t benefit fromthe same momentum as UML does, and it looks likeUML is taking industry and academia by s torm.

UML is intended for any type of softwaredevelopment. It can be used for databases irrespec-tive of whether the implementation is done withOO or other database technology (as with mostGISs). In the latter case, OO models simply mustbe translated into database units such as tables,columns, and keys.

Research in recent years has made databasemodelling more efficient than ever before, withseveral researchers focussing their work on spatialdatabases. The most important achievementsinclude the following: (see Claramunt et al. [ 1997]for a comparison of the OO solutions).

l CONGOO [Pantazis and Donnay 1996]l Geo-ER [Hadzilacos and Tryfona 1997]l Geo-OM [Tryfona et al. 1997]l GeoOOA with its modelling software [Kösters

et al. 1997]l MADS with its modelling software [Parent et

al. 1997]

I G E O M A T I C A

l Modul-R with its modelling software and auto-matic code generator 1989; Pageau and Bédard 1992; Caron et al.1993; Bédard et al. 1996]

l POLLEN [Gayte et al. 1997]

These researchers have extended existing lan-guages or developed new languages to overcome anumber of problems of applying non-spatial mod-elling languages to spatial databases. The mostimportant problems include inefficient modellingof the objects’ possible geometries, of their geo-metric evolution over time, of their spatial aggrega-tion and generalization, and of their spatial integri-ty constraints. Additional concerns include thesearch for the efficient separation or merging of theusers’ view and the programmer’s view, of thesemantic view and the geometric view, of attributedata and geometric data, of the map objects and themap aesthetic artefacts, and of the geometric dataand their metadata. In many cases, the search forspatial solutions comes not from the impossibilityto use non-spatial languages, but from the desire toimprove significantly the efficiency of non-spatiallanguages. For example, reductions of 25% to 50%in model size are frequent with good spatially-aware solutions, significantly reducing effortsrequired to build and edit a database model, whileimproving its readability.

Some solut ions inc luded visual model l ing sof t -ware, or CASE tools (Computer-Assisted SoftwareEngineering). The fundamental concepts relatingCASE tools to spatial databases have been describedby Bédard and L.arrivée [ 1992]; Bédard [ 1999]. Themost popular CASE tools also have been comparedwith regard to their appropriateness for spatial data-bases by Pouliot et al. [1997]. Popular CASE toolsusually offer limited extension capabilities, theirgraphical and reporting capabil i t ies are minimal, andnone of them provide automatic code generation forGIS or other spatial database technologies. Thisexplains why researchers have found it necessary todevelop their own spat ia l CASE tools .

From an historical and Canadian perspective, i tis of interest to know that Modul-R and Orion,developed at Laval University Center for Researchin Geomatics, were respectively the first formalismand the first CASE tool ever developed specificallyfor spatial databases. Different versions of Modul-R were developed between 1988 and 1995. Theversions were supported by a CASE tool calledOrion [Pageau and Bédard 1992]. Seven years ago,Orion allowed one to draw a spatially-extendedconceptual E/R schema of a desired spatial data-base, to fill the integrated spatial data dictionary,and to generate automatically the database code for

Intergraph’s GIS solution. Modul-R has been usedin about ten countries by practi t ioners and academ-ics. Its spatial component is a de facto standard inQuebec and we argue that it has influenced otherspatially-extended formalisms.

In spite of the success of Modul-R, the mostrecent trends in computer sciences and data model-l ing motivated us in 1997 to replace this proprietaryformalism by the second-generation language pre-sented in this paper. Recognition of the need for asecond-generation language emerged from thestudy of the scientific and commercial literature inconjunction with more than 15 years of involve-ment with real-world projects. The latter has pro-vided the opportunity to learn important facts aboutspatial database development, and to integratepragmatic findings with theoretical principles. Thefollowing ten trends summarize our understandingof present and expected s i tuat ions :

Trend 1: From relational and E/R modellingtowards OO modelling:

The once dominating E/R modelling paradigmrapidly is being replaced by the OO paradigm. Thearrival of UML is one of the main justifications forobserving this trend. We note that UML has atremendous momentum and offers the opportuni ty toend the multiplicity of formalisms. Note howeverthat this t rend applies only for the conceptual level ofdatabase modell ing. At the physical level of databasemodelling, the relational formalism continues to beused widely because relational DBMSs continue todominate the market. We may expect changes in thenext 2 or 3 years as users migrate towards the newestRDBMS versions which offer a hybrid object-rela-t ional capabi l i ty .

Trend 2: From several method-specific OO lan-guages towards a unique standard OO language:UML

More than twenty popular OO languages weredeveloped at the beginning of the 1990s, each withtheir specific constructs and graphical notat ion. Thissituation has evolved towards a more unified lan-guage following the joint effort by Booch et al.[1996; 1999] and other methodologists . This unif ica-tion through UML rapidly became a worldwide defacto standard. It is now an official standard recog-nized by the Open Management Group (the maininternational standardization body for OO).

Trend 3: From “closed” languages towardsextendible languages

The previous generation of languages had to beused “as is”. Consequently, CASE tools offered nopossibility to add new constructs, nor to enrich theformalism for specific purposes (such as spatial

. . . the oppor-tunity to learn

importantfacts about

spatial data-base devel-

opment, . . .

171

G E O M A T I

The advan-tage of spa-tial plug-insis that theyallow one tokeep work-ing with astandardlanguageformalism...

172

database design). The only exceptions were themetaCASE tools, i.e. CASE tools made to buildCASE tools. MetaCASE tools did support severalvisual languages, and allowed one to modify them,or to create a new one from scratch. However, usingmetaCASE tools was a very laborious and expensivealternative. UML, on the other hand, has built-inextension capabilities, as does OML (UML’s pri-mary competitor). Built-in extension capabilitiesallow one to include new domain-specific classes ofobjects, associations, etc. in the formalism whileremaining compatible with the core formalism. Suchmechanisms can be used, for example, to extendUML for spatial database development.

Trend 4: From aspatial languages towards spa-tially-aware languages:

Spatially-aware languages have become arecent research focus in academia, industry, andstandardization bodies such as the OpenGISConsortium and IS0 TC211. A standard visualmodelling language would have major impacts ondatabases designed for spatial querying, spatialanalysis, spatial data exchange and system interop-erability. A growing interest in spatially-aware lan-guages by the geomatics community over the lastthree years is an indication of a maturing market.

Trend 5: From spatially-aware languagestowards spatial plug-ins for standard languages:

This trend follows the general trend in com-puter sciences towards component-oriented devel-opment, software plug-ins for the Web, cartridgesand datablades for universal servers. This trend facil-itates the addition of specialized modules to coregeneric software. A plug-in approach is used byUML with regard to extensions, and by the SpatialPVL proposed in this paper. The advantage of spatialplug-ins is that they al low one to keep working witha standard language formalism while adding a sim-ple spatial extension, lowering the learning curve incomparison to learning a new spat ial formalism.

Trend 6: From an expected multiplicity of spatialextensions towards a unique open standard spatialextension:

Any extension built with UML constructs isnot part of the standard UML; only the UML exten-sion mechanism is. Thus spatial extensions wouldnot be part of the UML standard. We consider thatit is highly probable that other Spatial PVL will bedeveloped besides the one proposed in the presentpaper. Hopefully, initial discussions in geomaticsstandardization bodies (e.g. OpenGIS Consortium,IS0 TC211) will result in an official standardextension compliant with UML. This would be acommon sense approach.

C A

Trend 7: From expensive/limited CASE toolstowards inexpensive/rich CASE tools and visualmodelling capabilities embedded in softwaredevelopment environments:

In the 1980s and beginning of the 1990sCASE tools were at the same level of complexityand price as market-leading GISs. They were diffi-cult to use and to maintain, sometimes as diff icul t asthe system they described. They were CPU inten-sive, plagued by restr ic ted import /export l imitat ions,and offered very limited graphics and reportingcapabilities. Automatic code generation was notalways available, and when available, it wasrestricted to a small number of DBMSs and pro-gramming languages. Nowadays, similar to the GIStrends, excellent packages are available at lowprices. They are easy to use, run on small PCs, andare easier to support . The import/export capabili t iesare more developed and some CASE tools caninteroperate from a standard repository. We alsofind visual modelling tools embedded within soft-ware development environments (for example asubset of the Rational Rose CASE tool embeddedwithin Microsoft Visual Studio).

Trend 8 : From “informal and poor dictionary”towards “formal and rich dictionary”:

This trend results from cognitive research,experimentation, and the arrival of metadata stan-dards for spatial databases. The desire by someresearchers to include every geometric detail in thespatial database schema doesn’t correspond to cog-nitive research results. Diagrams are useful for glob-al analysis and the study of interrelationships (forexample for design and validation purposes). On theother hand, textual documents are better suited forspecific, detailed information. An analysis of thedocuments produced by large geomatics organiza-tions confirms this t rend. An analysis of the way spa-tial database developers have used Modul-R isanother example. Experienced spatial databasedevelopers involved in large, real-l ife projects don’tput many details into database schemas. They writethe detai ls in natural language in the dict ionary or inthe technical data-acquisition documents .Furthermore, if today’s traditional CASE dictionar-ies seem poor from a spatial database designer’spoint of view, the development of ISO spatial meta-data standards and the increased flexibil i ty of UML-compliant CASE tools will facilitate the inclusion ofsuch informat ion into the CASE dict ionary.

Trend 9: From a data-only paradigm towards amultimedia paradigm:

This trend has two aspects. The first one, whicharises mostly from Web applications and universalservers, is to have visual languages support ing the

G E O M A T I C A 1

modelling of multimedia databases. We need thecapabili ty to include in database schema all the piecesof information desired by the client, whatever theirmedia (image, paper document, Web site, video,aerial photography, digital sound or . . . the usualdatabase field). Today’s languages allow only forthe modelling of information stored in explicit tra-ditional database fields, not in images, recordedsounds, videos, scanned documents, Web sites, etc.New generations of formalisms, or new extensions toUML, must add this capability as universal serversand Web sites increase their penetration of the mar-ket. “One outstanding challenge is organizing amult imedia data model so that different media aboutthe same topic can be analysed together” [Thomsen1999]. The second aspect of this trend is to havemultimedia CASE tools, i.e. tools which allow theuser to record verbal comments about a class ofobjects, to store scanned photography of an excep-tional situation explaining the seemingly bizarrecardinality of a relationship, and to store a draftdrawing i l lustrat ing the defini t ion of a at t r ibute. Suchcapabili t ies are very useful for spatial databases.

Trend 10: From idealistic software engineeringpractices towards pragmatic modelling:

This trend has been observed through years ofexperience. “Every new technology promises toreduce development times and increase successrates of projects, but experienced software engi-neers tend to be justifiably skeptical of suchclaims” [Pooley and Stevens 1999]. In fact, model-l ing is sometimes perceived as an end in i tself whileit is only a means to an end. This results in over-modelling and overspecifying before program-ming. We also observe that there is a certain levelof detail where experienced systems analysts anddesigners start having problems in understandingthe model. “There is a limit to how much a humancan understand at any one time ” Pooley andStevens [1999]. There is also a limit to what usershave the time to formalize within their time andbudget constraints . We observed that humans and,surprisingly, the database users, generally have a‘soft’ understanding of the data they deal with;there are rarely rigourous definitions of objects,attributes, geometries, etc. Humans are used toworking with some fuzziness. “I t is not always pos-sible or desirable to capture every nuance andrestriction in a model: similarly, there is always adanger in producing a convoluted model that cap-tures every small detail at the expense of generalunderstandability” [Booch et al. 1996]. In addition,we noticed the psychological phenomena calledsatisficing [Davis and Olson 1985] for databaseanalysts and designers who regularly st ick with the

first database model satisfying them, and who tryl i t t le to f ind the very bes t solut ion.

Finally, automatic code generation providesusable results only if the database models are verydetailed and rigourous; this rarely fits within theabove-described reality, and explains why mostdevelopers use CASE tools as schema drawing toolsonly (or to document the system once developed,using backward engineering CASE capacities).Thus, the perfect and true model leading to perfectcode appears to be more a myth than a reality andconsequently, today’s database analysts and develop-ers have more realist ic expectat ions about modell inglanguages and CASE tools; the hype of the early1990s is over.

With regards to these trends, most spatially-aware visual modelling languages could be consid-ered as first-generation solutions . These first-gener-ation languages are academic method-specific solu-t ions not in sync with the recent t rends, nor with thegroundbreaking component-based paradigm.Although such a f irst generation of spatial languageswas necessary to build scientif ic knowledge, i ts over-all l imited use by experienced practi t ioners and aca-demics may indicate usability problems, theoreticalproblems, a lack of appropriate tools, a lack of inte-gration with mainstream visual languages, or a per-ceived l imited return on investment for their users. I tis our opinion that most of these problems apply tomost of the exis t ing so lu t ions .

In view of such a fact, and after a decade ofacademic work, it is time for a new generation ofsolutions to stem from the developed theory andpractical experimentation. The present paper intro-duces such a second-generation solution. This solu-t ion involves two aspects which are presented in thenext two sect ions respectively:

1. applying the generic PVL concept to create aspatial extension for visual modelling lan-guages, that is a Spatial PVL; and

2. integrating this Spatial PVL into a visual mod-elling language, in our case the UML ClassModel, and implementing the result in a CASEtool; cal led Perceptory.

An Innovative Solution:The First Spatial PVL

Spatial PVL stands for Spatial Plug-in forVisual Languages; i t is a generic concept created tosupport the development of second-generation solu-t ions. This sect ion introduces our PVL. I t has been inuse for 18 months. It has been tested in three largeprojects . I t rel ies on four strategic orientat ions:

. . . the perfectand true

model lead-ing to perfect

codeappears tobe more a

myth than areality.. .

173

I G E O M A T I C A ~

. bui lding on the PVL concept : this a l lows for theindependence of the solution from any visualmodelling language while remaining plugableinto the users’ favori te language and tool;

l relying on a symbiotic HLS approach (Human+ Language + Software) to design our SpatialPVL : this increases chances to overcome thelimited popular i ty of f i rs t -generat ion solut ions;

l adhering to the other major trends mentionedpreviously : this should lead to a better andmore popular solution; and

l targeting a level of abstraction located at thehigh end of the conceptual database modelsspectrum (i.e. an analysis level closer to theclient’s view than usual) : this would help tominimize the problem facing most modellinglanguages, i.e. the problem of being tooabstract for the cl ients .

The following paragraphs explain each of thestrategic or ientat ions.

Building on the PVL ConceptThe fifth trend presented earlier in this paper

indicated how the plug-in approach and the compo-nent-based paradigm is changing the panorama ofsystems developers. This trend also influenced thelatest visual modelling languages (e.g. UML andOML with their built-in extension mechanisms). Itallows one to add specialized modules to a coregeneric language in order to fit particular needs.This plug-in approach is the basis of the SpatialPVL concept described here.

From a technological point of view, such a solu-t ion is more in sync with today’s open, standard-ori-

This lowers ented “not-only-GIS” database development.

the learningConsequently, i t appears that a plug-in type of solu-tion which is simple and independant from any for-

curve and malism represents the best scientific and pragmatic

facilitates the solut ion. Accordingly, the solut ion proposed in the

acceptancepresent paper offers only a spatial extension to visu-al modelling languages, no underlying new model-

of the spatial ling language. This way, users can integrate effec-

extension.t ively the proposed solut ion into the language theyalready use, or into the one required by the client’s

174

methodology. This lowers the learning curve andfacil i tates the acceptance of the spatial extension.

To better illustrate this concept, we thoughtabout different terminologies such as ‘cartridge’,‘module’, ‘extension’, ‘component’, ‘add-on’,‘add-in’, ‘dialet’ (dialect + applet), etc. We decidedto call the proposed solution Visual Languages (Spatial PVL) because the con-cept and the word are more widely known, i.e. theyare known by everyone surfing the World Wide

Web, including our target audience. In addition, itconveys very well the basic principle.

PVLs are not pieces of software but rather verysmall extensions for visual modelling languages.They include basic constructs with a graphicalnotation and a grammar (usage rules). PVLs can beused manually, in CASE tools, word processors,databases, and so on; some can even be used in nat-ural languages. In fact, similarly to database car-tridges, categories of PVL can be developed (e.g.the Temporal PVL and Multimedia PVL includedin Perceptory).

A PVL approach provides several advantages.First , the very nature of the plug-in concept ensuresthat such extensions are intended by design to besmall, simple and plugable to any visual language.Second, i t a l lows one to keep working with the visu-al modelling language that one knows best. Third,we expect that most PVLs will also be plugable tonon-visual languages and to different categories oftools. Fourth, different categories of PVL can bedeveloped as a family of solutions, and can be 100%compatible among themselves (such as the Spatial,Temporal and Multimedia PVLs in Perceptory),al lowing one to s imultaneously use complementaryPVLs with a minimum of training and problems.Final ly , PVLs are used only when needed.

Nevertheless, like any language, the PVL con-structs, graphical notations and grammar must belearned. In spite of their simplicity, they must bemastered to be used properly in more complex sit-uations. Furthermore, some software tools mayhave no possibility to use certain PVLs, either as aresult of a limited tool or of a poor PVL design.Finally, PVLs are additions to more complete visu-al languages, thus the quali ty of the design of a spa-t ial database depends f irst of al l on the mastering ofthe full language; the PVLs do not ensure goodmodels, they simply make them easier to build, editand read (whether the models are good or bad),although they may include some constructs andrules facilitating the validation of a model.

Symbiotic ApproachFrom a scientific and practical point of view,

when one thinks of an efficient visual model l ing lan-guage, one must take into considerat ion the completeHLS modelling environment (Human + Language +Software). Developing a language in isolat ion of theother components of the modelling environmentmay resul t in an interest ing technical solut ion; how-ever, i t may fai l to be used properly by humans or i tmay be supported inadequately by software tools. Inother words, new solut ions must be bui l t around thesymbiosis between the visual modelling language

G E O M A T I C A

and its users into their context and with their tools.Such considerations refer to a more complete scien-tific approach when one remembers that the limita-tions related to modelling always relate to both themodelling process (including tools) and the mod-ellers (including context) [ B é d a r d 1987].Interest ingly, this approach has led our PVL towardssimplification and a certain elegance.

Several research methods can be used to devel-op a solution supporting this symbiotic HLSapproach. One way is to analyse what peopleunders tand and use f rom exis t ing solut ions wi thin atypical development context. Another way is to trydifferent variations of the proposed language, and toselect the most effective ones. A third way is to testwith large and complex database schemas, and seehow people do these or react to them. A fourth wayis to present models and dictionaries to a variety ofpeople, from programmers, to application experts, totheir bosses, and to study their reactions and level ofunderstanding. A fif th way is to mode1 spatial data-bases in very diverse fields of application, and to seehow the language can express different categories ofsi tuat ions. A sixth way is to t ry modifying a year-olddatabase model, which we have done, and to iden-tify the diff icult ies encountered. A seventh way is totry modifying a database model made by someoneelse, ident i fying the diff icul t ies in doing so.

We have used all seven research methods pre-sented above on an empirical basis, relying on infor-mal observation during and after experimentation.These experimental observat ions and modell ing testsincluded large and complex spatial databases such asthe Canada National Topographic Database (i ts f irstand second generations), Quebec Provincial 1:20 000Topographic Database, Quebec Provincial RoadNetwork Database, British Columbia Road NetworkDatabase, Quebec Provincial Official AdministrativeBoundaries Database, Q u e b e c ProvincialTopographic and Administrat ive 1:250 000 Database,Montmorency Forest database, and Eco-RechercheEnvironmental Database as well as smaller projectsin climatology, urban facilities management, trans-portation security, cadastre, property assessment,and spatial data cataloguing with metadata. Suchprojects involved multiscale considerations, multi-representation and generalization, Web distribu-tion, metadata, alternate geometries, facultativegeometries, complex objects, automatic updating,temporal issues, topological relat ionships, and spa-tial integrity constraints. Over the years, the tech-nologies involved included Oracle, Informix,Access, DBase, FoxPro, Intergraph TIGRIS,Intergraph MGE, Intergraph Geomedia, ESRIArcView, MapInfo, PAMAP, Intergraph GeomediaWebMap, and Autodesk MapGuide as well as visual

modelling tools like Oracle Designer/2000 andObjectMaker, p lus diagramming tools such as Vis ioa n d FlowCharter.

This variety of experiences occurred withingovernmental, private and academic projects. Theyhave strongly influenced our choices in the selec-tion of the basic constructs of the proposed SpatialPVL, in its level of detail, in its graphical notation,and in its balance between graphical and textualinformation.

Regarding this latest issue, we relied on researchin cognit ive sciences which has shown that graphicshelp to develop global views and to show interdepen-dancies between the elements of a system, while textsare better for specific details . Cognitive sciences alsohave shown that combining both graphical and textu-

. . . balancebetween

graphicalal languages is necessary to achieve a clear under- and textualstanding of a topic. Nevertheless, the difficulty when is set todesigning a PVL is to decide which parts of themodel should be presented graphically, which parts facilitate. . .should be described textually, and where there shouldbe overlap. Several possibi l i t ies exist . We must lookfor the highest richness of expression necessary tosimplify the modelling of a spatial database whilekeeping it easily readable.

In the Spatial PVL proposed in the presentpaper, the balance between graphical and textual isset to facilitate the drawing of the database schemaand the integration of the PVL into commercialCASE tools . This s trategic choice led us to keep thegraphical information to a minimum, and to insertspecific details, spatial integrity constraints andexceptional situations in a textual form into the dic-tionary. This should also encourage the acceptanceand use of the Spatial PVL. One must realize thatthe graphical notation is often and mistakenly per-ceived as the entire language, and if i t is not accept-ed, the rest of the language won’t be. As stated byPooley and Stevens [1999], “the chosen languageshould be . . . easy enough to use, so that the model-ling language aids clear thought rather than gett ingin the way”. Such simplicity is a key issue for theacceptance of the proposed solution.

Adhering to Major TrendsIn addit ion to the previously noted trends 3, 5, 8

and 10 which are at the centre of the Spatial PVLdeveloped, other trends contributed to deliver a bettersolution. Some trends influenced, to a lesser degree,our Spatial PVL (trend 9) while others contr ibuted toour CASE Perceptory ( trends 1,2,7,9). For us, i t wasimportant to identify and work towards these t rends,which we expect to shape the future of spatial data-base modelling. This allowed us to figure out thecharacterist ics of the second-generation solution we

175

I G E O M A T I

were looking for, and to stop investing in trend 4(spatially-aware languages) which seems to have arather difficult future.

Higher Level of Abstraction

The Spatial PVL proposed in this paper hasbeen developed for ‘data models’ and 'object classmodels’ as these are the primary models used todesign databases in the E/R and OO paradigmsrespectively. We also decided to focus on the con-ceptual level since this is where we found the great-est challenges and the highest needs to facil i tate thespatial database modell ing process. In other words,we wanted to facil i tate the analysis phase of spatialdatabase development by supporting a slightlyhigher level of abstraction than usual in order tobetter reflect the users’ perceptions of their reality.From our point of view, this is an area where non-spatial languages fall short on efficiency for spatialdatabases.

We have observed that people often have diffi-culties in understanding database models, forexample the clients’ application specialists whoparticipate in the so-called Database TechnicalCommittee. We also have observed that databaseanalysts and designers rarely master the full powerof a visual language. They frequently limit them-selves to the basic constructs because they find theoverall language too complex or they don’t see theut i l i ty of us ing a l l i t s cons t ructs .

Facing such a reality and in accordance withour symbiotic approach, we targeted the famous7+2 psychological threshold, i.e. humans can onlymaster 7+2 elements at once [Miller 1956]. Inaccordance with this principle, the developedSpatial PVL includes only the key constructs in the

C A I

graphical notat ion and hides several complexit ies inthe dictionary (for example the intricacies of linesvs. oriented lines vs. polylines, and metric vs.topology, spatial integrity constraints, complicatedshapes). The proposed Spatial PVL also eliminatesthe explicit graphical representation of rarely metaspects (e.g. 3-D objects).

In spite of such simplifications to encouragehigher levels of abstraction, the Spatial PVLremains expressive enough to present clearly thekey geometric information relevant to the applica-t ion specia l is t :

l does the user want to have this class of objectrepresented on the map?

l if yes, using what geometry?. is this geometry derived from other geometries?

The Developed Spatial PVLSeveral possibilities exist for developing a

Spatial PVL. The Spatial PVL presented in thispaper has a small set of basic constructs (3) with aminimum number of variations (7). Nevertheless, ithas a very high richness of expression. These con-structs and variat ions are presented in Figures 2 and3 respectively.

The pictograms of our Spatial PVL aredesigned to be inserted into the database schema.They may be inserted at different places for differ-ent visual languages, for example within the box ofan entity type or object class on either side of itsname, or at either the top or the bottom of the box.The Spatial PVL constructs could also be repre-sented by geometric fields instead of pictograms(dimension, combination, derivation, cardinality),or in a geometry section under the method sectionof object classes. In fact, this Spatial PVL allowssome degree of liberty with the graphical notation

@ O-dimensional shape (example for hydrants&hen they are all represented by a point)q 1 -dimensional shape (example for road segments when they are all represented by a line)El 2-dimensional shape (example for lakes when they are all represented by a polygon)

Figure 2: The three basic constructs of the developed Spatial PVL with their graphical notation (called ‘pictograms’).

Derived shape (example for a municipality centroid derived from other geometric information, i.e. the municipality polygon)

Figure 3: The seven variations of the Spatial PVL with examples of graphical notation.176

I G E O M A T I C A /

as long as i t remains consis tent with the constructs .This choice is strongly influenced by the limita-tions of the CASE tool being used. In our ownimplementation of the Spatial PVL, we place thepictograms on the left side of the name of objectclasses having a geometry. We also use the pic-togram for the attributes which vary spatially with-in an object (as perceived by the user), then weplace them after the name of the attribute.

The following paragraphs explain the detai ls ofthe Spatial PVL.

Simple geometry: As indicated in Figure 2, weinsert a spatial pictogram when the client wants tohave the posit ion and shape of an object class on themap. Most of the time, an object class has a simpleshape which is 0-D, 1-D or 2-D. For example, theshape of every t ire hydrant may be a point, the shapeof every road segment a l ine and the shape of everylake a polygon. In this case, the tire hydrant objectclass will have the 0-D pictogram (Figure 2, line l),the road segment the 1-D pictogram (Figure 2, line2) and the lake the 2-D pictogram (Figure 2, line 3).This means that every instance of those classes wil lhave exactly one instance of such a geometry.

With regards to three-dimensional objects,they are represented by their orthogonal projectionon the surface of the earth and the 3-D details aredescribed textually in the dictionary. The assump-tion is that three-dimensional objects practicallynever occur in spatial databases.

No geometry: One must remember that not allclasses of objects have spat ial pictograms, only thosewhich have an explicit geometry have pictograms(see the entity type PERSON in Figure 1).

Facultative geometry: If the shape of an objectinstance is fucul ta t ive based on certain criteria, thenwe add the 0,l cardinality next to the pictogram(Figure 3, line 3). For example, a building may begiven a geometry only if its area is larger than 1hectare, otherwise it is a non-spatial object. Onemust know here that the default cardinality for sim-ple shapes is 1,1 - and that we do not write it.

Simple aggregate geometry: The geometry ofa class of objects may also be an aggregation ofshapes. If these shapes are of the same dimension,we simply add the 0,N or 1 ,N cardinal i ty next to thepictogram. For example, road networks are com-posed of several lines, consequently the RoadNetwork class has the 1-D pictogram followed by al,N cardinality (Figure 3, line 3).

Complex aggregate geometry: If the aggre-gation involves shapes of different dimensions ( i .e . acomplex geometry) this can be depicted by insert ingthe appropriate symbols within the pictogram box.For example, a hydrographic network is an aggrega-tion of several lines (rivers) and polygons (lakes)

and consequently its pictogram box includes a 1-Dand a 2-D symbol (Figure 3, line 1). This pictogrambox is not followed by the cardinality l,N becausewe decided to make the l,N cardinality the defaultfor complex shapes. (In fact, we have never encoun-tered a complex shape with a 1,1 cardinality).Nevertheless, there could be other cardinali t ies.

Alternate geometry: When each occurence ofa class of objects has a shape of either one dimen-sion or the other but never both, then we use thealternate pictogram. The alternate geometry is rep-resented simply by the concatenation of the possi-ble pictograms (Figure 3, line 2). There is no spacebetween the pictograms and their ordering has nomeaning. For example, when a building is repre-sented by either a point if its area is smaller than 1hectare or by a polygon if its area is larger than 1hectare, then it has the 0-D and 2-D pictogramsadjacent to each other (see Figure 1 for this exam-ple). This is the exclusive ‘OR’ as opposed to theaggregated shapes which represent the ‘AND’.

Any possible geometry: If a class of objectsmay have any combination of shapes, then we usethe wildcard pictogram (the asterisk, Figure 3, line5). For example, an object class such as ‘HistoricalFeature’ may be a point (e.g. a statue), a line (e.g. anhistoric street), a polygon (e.g. a park), a polygonwith a line (e.g. an historic place including adjacentstreets) , or a set of disjoint polygons (e.g. a group ofbuildings). We use this wildcard when we assumethat every geometry is possible , without restr ic t ions.

Complicated geometry: If an object has ageometry which is too complicated to express withthe pictogram, or a limited set of possible geome-tries, then we use the complicated shape pictogram(the exclamation point, Figure 3, line 6). A firstexample is the object class ‘Bus network’ which isrepresented by a complex aggregation of lines(road segments), points (bus stops) and polygons(parking). It can be considered a complicatedgeometry, and can be represented by the exclama-tion pictogram. A second example is the objectclass ‘Property’ which could be a polygon (a lot), apoint or a polygon (a small or large building), a line(a single private street), or an aggregation of lines(a small private street network). We use the excla-mation pictogram when it becomes a tricky job toindicate graphically the geometry of an objectclass. We have a rule of thumb suggesting the useof this pictogram when more than 2 pictograms arerequired to describe the proper geometry of anobject class. We then use the database dictionary toexplain all the possibilities and limitations.

Derived geometry: Sometimes, the shape of aclass of objects may be derived from the shapes ofother classes of objects (county polygons are

Theassumption

is that three-dimensional

objectspractically

never occurin spatial

databases.

177

G E O M A T I C A

derived from municipal polygons). The shape mayalso be derived from another shape of the sameclass (a building centroid used for small-scale mapscan be derived from the large-scale polygon for thebuilding). Such derived shape is represented byitalicized pictograms (Figure 3, line 7). The deriva-tion rule must be described in the dictionary. Alltypes of geometry may be derived.

If we can derive the shape of only a part of theoccurences and need to digi t ize/measure the others,then we still use the italicized pictograms but weindicate the proper information in the dictionary.This happens frequently for large territories. Forexample, we could have large-scale digital mapswith building polygons only in the South of theprovince, then digitize building centroids fromsmall-scale paper maps in the North.

Multiple geometries: The client may alsorequire that a class of object has more than one shapefor each occurence. Such mult ip le shapes may hap-pen when a second shape of an occurrence of objectis derived from its first shape (the buildings repre-sented by a centroid and a polygon). I t may also hap-pen when a second shape is collected in addit ion tothe first shape of the same occurence of object(municipalities represented by a polygon and by a

point located downtown, such point being non-deriv-able and different from a centroid). There are no lim-its to the number of different shapes an object classor an attribute may have. To indicate such multiplegeometries, we simply insert all the needed pic-tograms (Figure 3, line 4) with their cardinality ifnecessary. However, we insert a space between thesepictograms to differentiate the mult iple shapes fromthe alternate shapes (which use adjacent pic-tograms). Multiple geometries usually are requiredfor mult iple representat ions at mult iple scales .

Geometry of attributes: So far, we have usedthe spatial pictograms for the geometry of objectclasses or for entities. However, it may happen thatwe want to describe the spatial distribution of anat t r ibute wi th in an objec t wi thout spl i t t ing the objectinto sub-objects (at least, from the point of view ofthe client). For example, in transportation, it is acommon rule to use a linear referencing system forcertain road attributes such as “number of lanes”(start ing from intersection A, the road has 4 lanes upto a distance of 200 m; then 2 lanes from the distance200 m to the distance 1800 m). When the clientrequires such spatial distribution of an attributewithin an object class, we simply use the previous-ly presented pictograms next to the name of the

II*C3BUILDING

civic-numberstreet-namenumber-flooryear

assessed-value

Figure 4: Inserting the geometry ‘Area’ into the ‘Lot’ object class with Perceptory.178

G E O M A T I C A

ELEMENT GEOMETRIQUES O U R C E

ENTITÉ ADMINISTRATIVE

4ccinposs 3,Nse c-se de 3.N ,

date chmg code géo TN0

date chang désig TA

LMUNlClPALlTÉ

RÈGLE DÉRlVATlON ÉLÉMENT GÉOMÉTRIQUE-----..**. . .-a

Figure 5: Example of a spatial database schema in Perceptory.

attribute. This indicates that we will insert in thedatabases all the data necessary to know where theattribute changes its values within an object. Thisalso is useful for at t r ibutes with a continuous spat ialdistribution within an object (for example elevationdata changing at every point within a polygon).

Since we use the Spatial PVL at the conceptu-al level, the client doesn’t have to see how we willimplement the spatiality of an attribute (for exam-ple the creation of sub-objects vs. dynamic seg-mentation). After all, this implementation dependson the technology used, and on programmingstrategies, but i t should remain as t ransparent to thecl ient as possible.

Finally, the Spatial PVL suggests including thedetails of a database schema into textual informa-tion within the dictionary. In other words, one caninclude in the dictionary all the information neededto complete the key constructs provided by thegraphical notation. Consequently, the content ofthis dictionary can be very rich. It provides the

opportunity to include many ISO TC211 spatialmetadata, and to be more precise about spatial def-initions, semantics, and constraints (see extracts inFigures 6, 7 and 8). Although the level of detail isleft to the user, minimum detail must be specified tovalidate a database model. This minimum includesthe semantic defini t ion of object classes, at t r ibutes,functions and relat ionships. I t also includes the spa-tial definitions of the object classes and of theattributes, the attribute domains, the functionsemantics and all derivation rules.

A formal dictionary provides a structured wayof entering detailed information and producing richreports . Without being exhaustive, let’s say that thedictionary of our Spatial PVL includes definitionsof feature types, feature attributes, feature functionsand feature relationships (using ISO TC211 vocab-ulary). The proposed graphical and textual compo-nents of such a Spatial PVL have already been usedin real projects. Based on a comparison with non-spat ia l formal isms publ ished by Bédard et al.[ 1996]

179

G E O M A T I C A

concerning the ancestor of our Spatial PVL (Modul-R spatial language), the use of pictograms simplif iesthe visual modell ing of spat ial databases in the orderof 40% for OO and 65% for E/R models. In addition,this Spat ial PVL faci l i ta tes the thinking process andthe reading of the database models, leading to easierdiscussion with clients and programmers. Suchresul ts are among the most important benefi ts of thisresearch since they lead to a more efficient spatialdatabase development process.

Perceptory : An InnovativeUML-Based Visual ModelingTool with PVLs

Finally, the rules to implement a conceptualmodel built with the proposed Spatial PVL dependon the specific software used. In general, i t is ratherstraightforward (it has been done for recent projectsus ing ArcInfo with Oracle, Access with Java on theWeb, Intergraph MGE with Oracle, IntergraphGeomedia and MapInfo). Such formal rules also arebeing implemented in an automatic code generatorfor Oracle 8 Spatial Cartridge. This will be includ-ed in the in-house developed freeware CASE toolpresented in the next sect ion.

Using the proposed Spatial PVL, one canimprove to a certain point today’s commercialCASE tools for the development of spat ial databas-es (as we do for teaching purposes; see Figure 1).However, there is also a need for researchers todevelop their own solut ions for R&D purposes andfurther innovations. In this section, we introducesuch an in-house visual modelling tool calledPerceptory. I t is an innovat ive solut ion plugging ourSpatial PVL into the Unified Modeling Language(UML) Class Model.

This CASE tool was developed for high-levelconceptual class models of spatio-temporal databas-es with multimedia capabilities (this paper presentsthe spatial aspect). From a technical point of view,Perceptory extends the UML language using UML’s

ÉLÉMENT GÉOMÉTRlQUESOURCE I

n o m entité a d m

d a t e c h a n g n o m entité

j d a t e c h a n g g e o m ent i té

d a t e c h a n g n o région

Figure 6: Perceptory user interface for the database dict ionary (Semantics tab) .

180

I G E O M A T I C A I

Paquetage

Définition

Réseau hydrique

“Terre entièrement entourée d'eau” (DEGQ, 98)

Référence spatiale

Pictogramme: pJ

L’ile se compose de primitives d'îleEchelle 1 /250 000 et 1 /20 000:Une île est toujours située dans un lac ou un cours d’eau surfacique.surfacique: > lOO m2

Règle dérivation La géométrie est dérivée de la primitive d’île &.

Détails:

Figure 7: Perceptory defaul t output for the database dict ionary.

‘stereotype’ construct [Booch et al. 1999]. However, Complex, etc.) or even the ‘Complicated’ andPerceptory has a special way of presenting these ‘Wildcard’ pictograms. This is a much simpler userstereotypes to the user, a way which is easier to interface than what can be implemented withimplement and to use when a large number of spatial extended commercial CASE tools.stereotypes is needed (in our case, one for each pic- This same pop-up menu also is used to inserttogram, each combination of pictograms, each attributes and operations into the object class boxPVL). Figure 4 shows how to add the geometry or to enter and read the content of the dictionary.‘Area’ to an object class (Lot) by using the ‘Area Figure 5 shows an example of a spatial database(simple)’ command; this command inserts the 2-D schema designed with Perceptory while Figure 6pictogram into the object class box, on the left side gives an idea of the details of the dictionary for anof the name ‘Lot’. Similarly, one could select from object class. There is one form to fill for each tab:the mouse right-button pop-up menu the command Semantics, Spatial definition, Temporal definition,to insert the 0-D or 1-D simple pictograms, or to Spatial evolution, Media, Attribute, Functions.insert ‘Other’ less frequent pictograms (Alternate, Similar forms are found for each attribute, each

G E O M A T I C A I

domain, each function and each relationship.Figure 7 presents a normal output for an objectclass while Figure 8 shows an ISO output. Thiscontent is a superset of ISO TC211 (which are writ-ten in a different colour in Figure 5).

Perceptory complies with the major trends andstrategic choices identified earlier. It adds a fewnon-spatial graphical notations as well as aTemporal PVL and a Multimedia PVL. Perceptoryis a free template developed for VISIO Standard(www.visio.com), i t is downloadable fromhttp://sirs.scg.ulaval.ca/yvanbedard. It was devel-oped as a VISIO template for several reasons:

l VISIO Standard’s low cost makes it affordablefor s tudents ;

l it is programmable in Visual Basic forApplication instead of a proprietary language;

l its database engine is the same as Access (thusdirectly accessible via Access for extra queryingand reporting flexibility);

l it is a full and simple MS-Office compatiblegraphics package already used for general pur-poses; and

l it is highly popular and a very flexible solutionallowing us to highl ight , colour , modify or add tothe database schema whatever graphical elementor note we want.

The integrity constraints of the database arewritten in the dictionary. These constraints can bewritten in the Object Constraint Language (OCL),[Warmer and Kleppe 1998], in natural language(such as English or French) or with any other lan-guage since it is stored in a text field. The spatialintegrity constraints are managed by a specificmodule. Following testing in real projects with an

FEATURE TYPE:

Feature Type Name: railwayFeature Type Definition: Roadbed with rails on which trains andother equipment can travelFeature Type Code: 934Feature Type Aliases:Feature Functions Name: maximum lengthFeature Attributes Name: railway gaugeFeature Relationship Names: railway share with O,N, railway shareby, railway Est un type de, railway GenName4

Feature Funct ion:

Feature Function Attribute Names: Bridge length, Bridge CategorieObject Feature Type Names: BridgeFeature Function Textual Description: Action of calculate maximum length ofa railwayFunctional Language: SQLFeature Function Formal Definition: Calculate . . . .

Feature Attribute:

Feature Attribute Name: railway gaugeFeature Attribute Definition: size of gauge usedFeature Attribute Code: 9341Feature Attribute Value Data Type: CharacterFeature Attribute Value Measure Unit:Feature Attribute Value Domain Type: 1 [enumerated)

Feature Attribute Value Domain:Feature Attribute Value:

Feature Attribute Value Label code Definition----------------___---------- - - - - ----------Generic/unknown 0 Value indicating that an

attribute is not applicable or that it is impossible to determineNarrow 1 NullSpecial 2 Null

Figure 8: Perceptory IS0 TC211 output for the database d ic t ionary .

G E O M A T I C A

Figure 9: Prototype module to enter, in the dictionary, the spatial integrity constraints between two object classes.

early prototype (Figures 9 and l0), this module isbeing translated and integrated within Perceptory.

Perceptory is the first standard-oriented, UML-based visual modell ing tool for spatial databases. I tis easy to use and very flexible. In addition, it isfree of charge for those who already own the low-cost VISIO diagramming software. Furthermore, itsMultimedia PVL allows one to design a databasewhere spatial information is not only obtainablefrom vector map and tabular data, but also fromaerial photographs, satellite images and free-textdocuments (like legal and technical descriptions ofproperties). Finally, its Temporal PVL allows oneto express the desired existence of object classesand associations, as well as the evolution of attrib-utes and the spatial evolution of object classes.Such capabilities enrich the modelling possibilitiesof the spatial database designer.

Discussion and ConclusionWe find that visual modelling languages and

their CASE tools offer an elegant solut ion to support

a spatial database development process. Whilemastering a modelling language is necessary todevelop complex databases and to design efficientsystems, mastering a CASE tool is not as critical tothe success of a project. Pouliot et al. [1997] havedescribed different visual modelling tools for thedevelopment of spatial databases, including non-CASE tools. For example, there are the simple andinexpensive drawing packages (such as CorelDraw)and traditional diagrammers (such as VISIOStandard and FlowCharter). The latter help to drawthe database schema, but the dictionary typically hasto be written into a word processor. However, thereare no links between the schema and the database,leading to possible inconsistencies. On the otherhand, these packages are widely available and easyto use. They present a minimal solution for the casu-al users. Perceptory has been developed to run insuch packages while overcoming their l imitat ions.

For the more advanced users, there are the tra-ditional commercial CASE tools. Some CASEtools support only one modelling language whileothers support several. Most provide automatic

183

G E O M A T I C A

Contraintes d’intégrité spatiale

I 1-I I I I

Commentaire pour I’objet île

LUm ile ddt 6%‘~ ircluse dms un 01 I

Fin du rapport I

Figure 10: Printout of the spatial integrity constraints for a class of objects (prototype).

184

code generation for SQL and popular programminglanguages (but not for spatial databases engines norGIS). These are the traditional CASE tools used byexperienced database developers. However, oneneeds to extend such tools with a Spatial PVL toincrease the efficiency of analysts and program-mers. For example, we extended OracleDesigner/2000 with our Spatial PVL by adding aspecial font with our pictograms (available athttp://sirs.scg.ulaval.ca/yvanbedard) a n d b yextending the dictionary (Oracle Repository). Theschema shown in Figure 1 was done with such anextension, and this solution has the advantage ofbeing available from a commercial product withminimum addition. However, such a solution is notas smooth and elegant as Perceptory since exten-sion capabil i t ies of t radi t ional CASE tools are of tenquite limited and the learning curve rather steep.

Another and similar solution would be toexpand on CASE tools by replacing the pictogramsby an object class naming convention and byadding attributes in the dictionary to specify thedimension, combination, cardinality and derivabili-ty of the geometry. This is perhaps the most stan-dard and universal way of proceeding. However, itwould be complex and confusing to use this solu-tion for the at tr ibutes as well as for the object class-es and their associations. Also, such a solution isnot as intuitive nor as complete as what is offeredby Perceptory. Only highly extendible CASE toolscould provide a serious solution of this type.

Nevertheless, this is a solution we will investigatemore seriously with the new breed of CASE toolsbased on UML.

The last possibility is to build your own CASEtool. Here one has the choice between differentsolutions: first to develop everything from scratchwith a programming language like C++, second tobuild on top of a software component, third to pro-gram a diagramming tool such as VISIO, andfourth to code a metaCASE tool (i.e. a CASE toolbuilt especially to build CASE tools). Up to twoyears ago, the lat ter solution was the best and onlypractical one. It was the most widely used solutionby large organizations having their own in-housedevelopment method. This is also what we didseven years ago with Modul-R see Pageau andBédard [ 19921 and what we suggested in publica-tions written prior to the Fall of 1997 (see for exam-ple Bédard [1999] but remember that the manu-script was written in the Spring of 1997).

Since the integration of VBA within VISIO, wehave had access to VISIO objects and we coulddevelop a rich solution with a minimum investmentin programming. We found several other advantagesto switching from an expensive/proprietary/rigidsolution to an affordable/open/flexible solution.They are readily available to students and the largergeomatics community, and have a simple learningcurve, reusability of tools for all kinds of drawingbesides database models, reusability of tools forseveral visual modelling languages in the

G E

Professional version of VISIO, and even completeCASE tools in the Enterprise version. This explainswhy we changed our strategy and opted for a some-what surprising solution: programming VISIO withVBA. The results of the last 18 months have rein-forced our posi t ion.

Nevertheless, CASE tools are not the mostimportant part of spatial database design.Successfully developing spatial databases requiresthe mastering of a visual language to understandthe users’ needs and to master the design of robustsolutions. To this end, we have enriched tradit ionallanguages by developing a Spatial PVL. Createdfrom theoretical and empirical findings, this visuallanguage extension has been tested in real projects.Integrating the proposed Spatial PVL into one’smodelling language provides additional guidanceand rigour to the analysis , design and programmingof a spatial database. I t bet ter supports the thinkingand technical processes as well as encourages con-sis tent communicat ion and documentat ion.

Finally, an implementation of this solution in aPVL-oriented UML-based free VISIO templatecalled Perceptory represents an innovative solution.Our first studies and experiences suggest that theproposed Spatial PVL as well as Perceptoryimprove the development process when comparedto first-generation solutions. In addition, theireffectiveness and simplicity help to overcome thelimited popular i ty of f i rs t -generat ion solut ions. Theintroduction of a second-generation solutionappears very timely when one observes today’sconvergence of spatial database management tech-nologies with mainstream technologies and systemdevelopment methods.

ReferencesBatini, C., S. Ceri and S.B. Navathe. 1992. Conceptual

Database Design, an Entity-Relationship Approach.Benjamin Cummings.

Bédard, Y. 1987. A Study of Data Using aCommunication Based Conceptual Framework ofLand Information Systems, Updated Version. LeGéomètre Canadien/The Canadian Surveyor, 40(4),p. 449-460.

Bédard, Y. 1999. Principles of Spatial Database Analysisand Design. In: Geographical Information Systems:Principles, Techniques, Management andApplications, 2nd ed. Edited by Maguire,Goodchild, Rhind & Longley. John Wiley & Sons,USA (in press).

Bédard, Y., C. Caron, Z. Maamar, B. Moulin and D.Vallière. 1996. Adapting Data Models for theDesign of Spatio-Temporal Databases. ComputerEnvironment and Urban Systems: an InternationalJournal, 20(l), pp. 19-41.

O M A T I C A

Bédard, Y. and F. Paquette. 1989. ExtendingEntity/Relationship Formalism for SpatialInformation Systems. 9th International Symposiumon Automation in Cartography (AUTO-CARTO 9)American Congress on Surveying and Mapping,April 2nd-7th, Baltimore, p.818-827.

Bedard, Y. and S. Larrivéeée. 1992. Développement dessystèmes d’information à réference spatiale: versl’utilisation d’ateliers de génie logiciel. CISMJournal ACSGC, 46(4), p. 423-433.

Booch, G. 1994. Object-Oriented Analysis and Designwith Applications, 2nd ed. Benjamin Cummings.

Booch, G., J. Rumbaugh and I. Jacobson. 1996. TheUnified Modeling Language for Object-OrientedDevelopment, Documentation Set Version 0.9Addendum. Rational Software Corporation,California.

Booch, G., J. Rumbaugh and I. Jacobson. 1999. TheUnified Modeling Language User Guide. ObjectTechnology Series, Addison-Wesley

Caron, C. and Y. Bédard. 1993. Extending the IndividualFormalism for a More Complete Modeling of UrbanSpatially Referenced Data. Computer Environmentand Urban Systems: an International Journal, 17(4),p.337-346.

Claramunt, C., S. Coulondre and T. Libourel. 1997.Autour des méthodes orientées-objet pour la con-ception des SIG. Revue internationale de géoma-tique, 7(3-4), pp.233-257.

Coad, P. and E. Yourdon. 1991a. Object-OrientedAnalysis, 2nd Ed. Prentice Hall.

Coad, P. and E. Yourdon. 199 1 b. Object-Oriented Design.Prentice Hall.

Cook, S. and J. Daniels. 1994a. Software Isn’t The RealWorld. Journal of Object-Oriented Programming.May, pp.2-28.

Cook, S. and J. Daniels. 1994b. Designing ObjectSystems: Object-Oriented Modelling withSyntropy. Prentice Hall.

Davis, G.B. and M.H. Olson. 1985. ManagementInformation Systems: Conceptual Foundations,Structure, and Development. 2nd Edition, McGraw-Hill.

Firesmith, D.G., B. Henderson-Sellers and I. Graham. 1998.The OPEN Modelling Language (OML) ReferenceModel. Prentice Hall, Englewood Cliffs, USA.

Gayte, O., J.P. Cheylan, T. Libourel and S. Lardon. 1997.Conception des systèmes d’information sur I’envi-ronnement. Ed. Hermes, Paris.

Hadzilacos, T. and N. Tryfona. 1997. An ExtendedEntity-Relationship Model for GeographicApplicat ions. SIGMOD Record, 26(3).

Jacobson, I., M. Christerson, P. Jonsson and G.Overgaard. 1993. Object-Oriented SoftwareEngineering. Addison-Wesley.

Kösters, G., B.U. Page1 and H.W. Six. 1997. GIS-Applicat ion Development with GeoOOA.International Journal of GIS, l1(4). pp. 397-335.

Martin, J. and J.J. Odell. 1993. Principles of Object-Oriented Analysis and Design. Prentice Hall.

Miller, G.A. 1956. The Magical Number Seven, Plus orMinus Two: Some Limits on our Capacity for

185

G E O M A T I C A

Yvan Bédard

Processing Information. The Psychological Review,63(2), pp.81-97.

Moody, D. 1996. The Seven Habits of Highly EffectiveData Modelers. Database Programming and Design,October, pp57-64.

Pageau, J. and Y. Bédard. 1992. Conception d’un outilCASE pour la modélisation des données à référencespatiale. Actes de la Conference canadienne sur lesSIG, Ottawa, du 24 au 26 mars, p. 381-392

Pantazis, D. and J.P. Donnay. 1996. La conception deSIG-méthode et formalisme. Ed. Hermes, Paris.

Parent, C., S. Spaccapietra, E. Zimanyi, P. Donini, C.Plazanet, C. Vangenot, N. Rognon and PA. Crausaz.1997. MADS, modèle conceptuel spatio-temporel.R e v u e Internationale d e Gé omatique, 7(3-4),pp.317-352.

Pooley, R. and P. Stevens. 1999. Using UML: SoftwareEngineering with Objects and Components. ObjectTechnology Series, Addison-Wesley; Booch,Jacobson and Rumbaugh Series Editors.

Pouliot, J., N. Rognon, Y. Bédard and F. Golay. 1997. Dela selection à la mise en oeuvre d’outils de conceptionpour les SIRS. Revue inte rnationale de géomatique,7(3-4), pp.259-277.

Rumbaugh, J. 1996. Layered Additive Models: Design asa Process of Recording Decisions. Journal of Object-Oriented Programming, March-April, pp. 2 l-48.

Rumbaugh, J., M. Blaha, W. Premerlani, F. Eddy and W.Lorensen. 1991. Object-Oriented Modeling andDesign. Prentice Hall.

Shlaer, S and S. Mellor. 1991. Object Lifecycles:Modeling the World in States. Prentice Hall.

Thomsen, E. 1999. Framing the Usual Suspects.Intelligent Enterprise, Decision Support Chronicle,January 5th issue, pp. 26-29.

Tryfona, N., D. Pfoser and T. Hadzilacos. 1997.Modeling Behavior of Geographic Objects: anExperience with the Object Modeling Technique.CASE’97, Barcelona.

Warmer, J. and A. Kleppe. 1998. The Object ConstraintLanguage: Precise Modeling with UML.

AcknowledgmentsThe author wishes to thank the Natural

Sciences and Engineering Research Council ofCanada for financing this research. The author alsowishes to thank the Ministry of Natural Resourcesof Québec, and Natural Resources Canada (CITS-Geomatics Canada) for their contribution to ourmost recent projects, as well as the following grad-uate students and research assistants for their par-ticipation in the design and development ofPerceptory: Suzie Larrivée, Marie-Josée Proulx,Stephane Daudelin, Christian Mattel, ClementNolette, Pierre Normand. Finally, the author alsothanks the anonymous reviewers for their valuablecomments and suggestions.

Author

Yvan Bédard is a professor at Lava1University Geomatics Sciences Department, since1986. He teaches GIS, Spatial Database andSystem Development courses. He was theFounding-Director of the Centre for Research inGeomatics (CRG) and the Scientific Director of theCentre for the Development of Geomatics. He is anactive member of the CRG and of the newly creat-ed Canadian Network of Centres of Excellence inGeomatics (GEOID) headed at Laval. Dr. Bédardhas been involved in several major R&D projects,often with industry and governments, in Canadaand abroad. He has presented papers in almost 300journals and conferences.

186