<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>A Software Framework for the Automated Production of Schematic Maps</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Joao Mourinho</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Teresa Galvao</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Joao Falcao e Cunha</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Fernando Vieira</string-name>
          <xref ref-type="aff" rid="aff1">1</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Jose Pacheco</string-name>
          <xref ref-type="aff" rid="aff1">1</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>Faculdade de Engenharia da Universidade do Porto</institution>
          ,
          <addr-line>4200-465 Porto</addr-line>
        </aff>
        <aff id="aff1">
          <label>1</label>
          <institution>OPT - Optimizacao e Planeamento de Transportes</institution>
          ,
          <addr-line>4200 Porto</addr-line>
        </aff>
      </contrib-group>
      <fpage>57</fpage>
      <lpage>64</lpage>
      <abstract>
        <p>Schematic Maps are mainly used for depicting transportation networks. They are generated through a schematization process where irrelevant details are eliminated and important details are emphasized. This process, being manually performed by teams of expert designers, is expensive and time consuming. Such manual execution is unsuitable for the production of schematic maps for location-based services or ondemand schematic maps, as near real-time and user-centered properties are needed. This work proposes GeneX, a framework that can support the automated generation of schematic maps. The framework and the new algorithms developed were able to completely eliminate erroneous map point placement, and to decrease by 33% the contention for map point placement, producing schematic maps without human intervention in soft real time.</p>
      </abstract>
      <kwd-group>
        <kwd>Schematic Maps</kwd>
        <kwd>Software Framework</kwd>
        <kwd>Public Transportation</kwd>
      </kwd-group>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>-</title>
      <p>
        Schematic maps have been increasingly used in response to the need of
better and simpler maps to describe complex transport networks. This apparent
simplicity is achieved through a simplification process called “schematization
process” where choices are made regarding the level of detail and simplification.
A special type of schematic map, called spider map, has also appeared recently.
It presents innovative features such as a spider structure improve visual
presentation, user learning and spatial context communication. Schematic maps, by
their inherent simplicity and symbolic meaning are good maps for being used in
the transportation area as they are far more intuitive than conventional maps [
        <xref ref-type="bibr" rid="ref1">1</xref>
        ].
In fact as people travel more often, they need flexible and easy to understand
maps which may take in account their context [
        <xref ref-type="bibr" rid="ref2">2</xref>
        ]. Automation in the production
of maps is a key factor to achieve flexibility to tailor maps to user context, as
it happens with Location-Based Services [
        <xref ref-type="bibr" rid="ref3">3</xref>
        ]. There is the need, then, to develop
a software framework which could support efficiently and comprehensively the
automated generation of schematic maps. In this paper we propose and describe
a software framework which serves as an engine to the generation and test of
schematic maps.
      </p>
    </sec>
    <sec id="sec-2">
      <title>Schematic and Spider Maps</title>
      <p>
        Some authors define schematic map as “an easy-to-follow diagrammatic
representation based on highly generalized lines which is in general used for showing
routes of transportation systems, such as subways, trams and buses, or for any
scenario in which streams of objects at nodes in a network play a role” [
        <xref ref-type="bibr" rid="ref4">4</xref>
        ]. One
remarkable schematic map applied to a transportation network was the Harry
Beck’s London Underground diagram. Beck’s map was considered both bold and
innovative, as for the first time lines were drawn either horizontally, vertically
or diagonally at 45. This map also uses differential zoom scaling and although
it gives the traveler some clues about the terrain features (ex: river) and his/her
location, it does not mimic the geography of London. Spider maps are special
schematic maps. Like schematic maps, the stops and lines of the transportation
network correspond to vertices and edges. However, they have enhanced features
such a spider architecture, thus having a specific set of characteristics which sets
them apart from schematic maps. Spider maps pay special attention to context
in order to enhance user learning and ease of use. A spider map such as the one
depicted in figure 1, comprehends three components:
– Hub: Describes the area in which the user is, as well as the surrounding
area with a higher degree of detail (buildings, roads, etc). The hub, as it is
the central part of the spider map, is the first component the user will look
at, as it makes uses of “focus and context” [
        <xref ref-type="bibr" rid="ref5">5</xref>
        ] and detail focusing techniques.
      </p>
      <p>The hub may not comply with the 0/45/90 degrees line orientation.
– Lines: The lines follow the orthogonal orientation of the traditional schematic
maps, and describe the paths of the transport network where the user can
go through while being at the zone depicted by the hub.
– Stops: The stops are the destinations accessible to the user from the hub.</p>
      <p>
        Visual simplicity of schematic maps is achieved through a sequential
decision process regarding the level and nature of detail and schematization. In
practice, this “schematization process” is still a manual process carried away
by teams of expert designers. The automation of the schematization process
requires effective and efficient algorithms to achieve, in one hand, high quality
schematic maps which can be understood by people and, in the other hand, a
time-efficient process. Through schematization, certain map details are
emphasized while others are deemphasized. It is fundamental to present the smallest
amount of information the user needs to learn the map to decrease user learning
time. Therefore information shall be reduced to its basic components to achieve
that goal. There are some studies regarding the automated drawing of schematic
maps [
        <xref ref-type="bibr" rid="ref7">7</xref>
        ] [
        <xref ref-type="bibr" rid="ref8">8</xref>
        ] [
        <xref ref-type="bibr" rid="ref9">9</xref>
        ] [
        <xref ref-type="bibr" rid="ref10">10</xref>
        ], nevertheless these studies tend to focus only some areas of
the problema and do not make a multidisciplinary approach. They mostly focus
on the schematization process [
        <xref ref-type="bibr" rid="ref11">11</xref>
        ]. Nollenburg [
        <xref ref-type="bibr" rid="ref12">12</xref>
        ] [
        <xref ref-type="bibr" rid="ref13">13</xref>
        ] makes a deep research
on the discrete mathematical foundations which are the basis of the algorithms
used in the drawing of schematic maps and makes some brief considerations
about their implementation. Nevertheless, his studies do not cover the human
perception factors nor a concrete computer framework for drawing schematic
maps. Silvana Avelar [
        <xref ref-type="bibr" rid="ref1">1</xref>
        ] [
        <xref ref-type="bibr" rid="ref4">4</xref>
        ] presents a broader study, by including some human
perception factors and studies the schematic maps on demand. She goes further
on by presenting a framework for electronic schematic maps which can answer
user queries and studies the automated generation of schematic maps.
Nevertheless, the study of the human perception factors is limited to what she calls the
“aesthetic factors”. Most of the algorithms to design schematic maps retain a
common structure [
        <xref ref-type="bibr" rid="ref14">14</xref>
        ]. They use a graph to model the transportation network,
in which the vertices represent stops or turning points and the edges represent
the paths between two turning points.
3
      </p>
    </sec>
    <sec id="sec-3">
      <title>The GeneX Framework</title>
      <p>In this section, we present the GeneX framework which was developed through a
collaboration research performed by a team involving collaborators from FEUP
(http://www.fe.up.pt), OPT (http://www.opt.pt), STCP (http://www.stcp.pt),
FWT (http://www.fwt.co.uk), INEGI (www.inegi.up.pt), and that was funded
by INEGI. The GeneX framework is a software application designed to support
the following objectives:
1. The automatic generation of electronic schematic maps for complex
transportation networks in bounded time, through the flexible use and
parameterization of schematization algorithms
2. To serve as a test lab to support the research of schematic maps.</p>
      <p>By merging and processing different kinds of external information
(transportation networks, geographic and constraint information) through the use of
state-of-the-art algorithms, the framework generates schematic maps
automaticaly. The framework produces an SVG 3 file which can be used directly, printed
in paper or further processed. The framework alsos produce a statistics file to
measures several parameters about the framework functioning.
3 The Scalable Vectorial Graphic is XML language to describe vectorial bidimentional
graphics. It is an open format created by the World Wide Web Consortium</p>
      <sec id="sec-3-1">
        <title>Software Engineering Life Cycle model</title>
        <p>
          The requirements elicitation and validation was performed together with the
project stakeholders, as part of a Joint Application Development (JAD) model
[
          <xref ref-type="bibr" rid="ref15">15</xref>
          ]. The contributions provided by the partners were highly regarded: from the
experts in information systems for transportation services (OPT), in
optimization algorithms (INEGI) and map design (FWT), to the final users of the system
(STCP). The development of this framework was considered, since the begining,
an interdisciplinar subject in which knowledge from several areas of the science
need to be integrated. Regarding functional requirements, the framework should
be capable of producing schematic and spider maps in a fully automated way,
about any location the user may select, using several schematization algorithms.
The framework should be able to obtain data through the use of a common
standard protocol data schema shared by the stakeholders. Another requirement
was that the producton of schematic maps should be time-bounded (by setting
deadlines or iterations number), to make it able to support Location-based
services. In order to serve as a test lab, the framework should allow the choice of
the algorithm and its parameters. The framework should also support different
schematization algorithms (genetic, linear, tabu search, GRASP, etc) and
provide a common protocol to implement them. This set of functional requirements
needs to be supported by a set of non-funcional requirements, which
comprehends usability, performance and interoperability. Usability is fundamental as
the schematic maps produced by the framework have a strong user learning
component: the maps produced, as well all possible interactions should be as
intuitive as possible to be quickly learned and understood by their users. The
designers and the final user team members provide insightful highlights in this
area. To be able to support location-based services, the framework should execute
the algorithm and produce the correspondent schematic map in near real time.
Therefore, the framework was designed to perform as a soft real-time system [
          <xref ref-type="bibr" rid="ref16">16</xref>
          ].
A standardized transport network data specificication was implemented and a
common interface for the algorithms was designed to achieve interoperability.
Extensive use of reusable components [
          <xref ref-type="bibr" rid="ref17">17</xref>
          ] [
          <xref ref-type="bibr" rid="ref18">18</xref>
          ] was also made. The framework
was developed by using C# Language, as a modern Object Oriented language
which supported the requirement list.
3.2
        </p>
      </sec>
      <sec id="sec-3-2">
        <title>Architecture and Data Model</title>
        <p>The architecture of the framework follows a modular structure, with two main
modules: the data preparation module and the algorithm execution module.
Figure 2 shows the GeneX framwork package diagram, depicting its components.</p>
        <p>
          The data aquisition and preparation module is responsible for preparing the
data to be used by the algorithm execution module. The user selects graphically
the location where he wants the spider/schematic map to be centered (hub).
The module then extracts raw data from the transport network database and
organizes it into a data structure by using the Spider Map Library. The spider
map library is a complex set of C# classes that support the serialization and
communicaton of the spider and schematic map structure. The algorithm
execution module reads the XML file and transforms the data into an internal data
structure (to improve component reuse by the schematization algorithms). At
the user interface, the user can choose the schematization algorithm (from the
AlgLib algorithms package) to execute and its options and performance
measurement metrics. The business logic is then responsible for calling and executing the
algorithm and to produce the final result, which can be an SVG (Scalable Vector
Graphics) or a binary file containing serialized data. The SVG file is produced
by using a library that allows the conversion of a spider map data structure in
an SVG file called Abstract Graphs Library [
          <xref ref-type="bibr" rid="ref6">6</xref>
          ].
3.3
        </p>
      </sec>
      <sec id="sec-3-3">
        <title>The HPPO Algorithm</title>
        <p>The AlgLib package provides a foundation for the execution and configuration
of the schematization algorithms. Each algorithm has to implement the same
communication interface functions, in order to be used by the execution module:
– spiderMap execute(spiderMap, parameterList ) performs the
execution of the algorithm. The arguments are the spider map XML structure
that was opened by the execution module, and the algorithm parameter list,
already set up by the user. This function returns a spiderMap data structure
which is the processed spider/schematic map. That structure can then be
output to a SVG or serialized binary file.
– parameterList getParameters() the module calls this parameter function
to get the list of the algorithm parameters that can be set by the user.</p>
        <p>We have implemented a preliminary schematization algorithm that we called
“Heuristic Point Placement Optimization” (HPPO). HPPO, aligns map points
(corresponding to the transportation network stops and stations) to a regular
grid, by positioning each map point in the nearest grid intersection. For high
density or non regular density transportation maps, map station contention for
grid intersections will happen. In this case, the HPPO smartly solves the
contention through an heuristic algorithm. By using regular expressions, the point
labels are also taken into account when placing network vertices, by determining
the similarity degree of node labels in conjunction with its geographic location
in order to produce a decision about the location to plot the node where the
contention arises. The use of regular expressions is based in a finite-state automaton
which scans strings in order to find the degree of similarity. We are not only
relying in geographical information, but merging knowledge from different science
fields theory to make a higher quality judgement on how to solve the contention,
such as computer science and operations research. For each map point, HPPO
starts by checking if the nearest grid intersection is empty. If it is, then there
is no contention and the point is plotted there. If the grid intersection is not
empty, then we have a contention. This means that the geographical coordinates
of the nodes are equal, or at least, within the same decision range concerning
the square grid resolution. The automaton also tells us the degree of similarity.
If the degree of similarity is higher than the predefined threshold level, then we
assume that both nodes refer to the same location. In this case, they should be
both plotted in the same grid intersection. If the degree of similarity is lower
than the threshold, then it is important to distinguish them and plot them in
different grid intersections while maintaining the topological relation between
them. In this case, we get the topological relation between the two points (based
on their coordinates) and try to move the node to the adequate grid intersection.
It was found that preserving the topological relation between map points is of
fundamental importance when developing map design frameworks. If contention
happens again (what can happen in a highly crowded map or with a loose square
grid), then we have two options: or we may continue this cycle recursively until
the topological relation is violated, or we may decide if we shall plot the node
into the suggested grid intersection. To limit the processing time, we discarded
the recursive approach in our algorithm. Being so, we analyse the proposed grid
intersection. If contention happens again we check the degree of label similarity
through our automaton, and if is higher than the threshold, we plot the point
there. If not, we analyse both the first and the actual grid intersections suggested
and we add the node where there are less nodes plotted. The pseudoalgorithm
is described in figure 3.
4</p>
      </sec>
    </sec>
    <sec id="sec-4">
      <title>Results</title>
      <p>The GeneX Framework was able to generate in a fully automated way schematic
and spider maps for every location requested. It is also a very important tool as a
test lab for the schematization algorithms that are being developed. Although the
framework is still under development and the algorithms in the AlgLib are being
improved and enhanced, it is already being used for the production of schematic
and spider maps. Maps produced with this framework are already available for
public use in the cities of Porto and Lisbon. Concerning our HPPO algorithm,
it showed good results, as it can be observed in figure 4. Other advantage of
HPPO is that if different nodes refer to the same place, this algorithm can ignore
contention and plots them correctly in the same grid intersection (grouping). In
addition, all the topological relations are still preserved.</p>
    </sec>
    <sec id="sec-5">
      <title>Conclusions and Future Work</title>
      <p>The GeneX framework was used to produce spider maps that are being used in
the cities Porto and Lisbon, it has proved effective in generating spider maps.
Nevertheless, these maps were not completely produced by an automated
process, as some manual changes were necessary to improve the visual appearance,
which is the most difficult aspect to model in the algorithms. The quality of the
results of the HPPO algorithm is quite good, showing a significant decrease in
bad cells. The algorithms need to be perfected in order to increase the quality of
the results and to make them directly usable (without any manual processing).
The algorithms need to further improve aspects such as visual line distiction,
stop label organization and geographical constraints. Some development of the
framework is also needed to support Location-based services, such a “request
manager” which can feed user requests to the framework and reply to them.
Other issues that need further study are the adaptation of the resulting maps
to different devices. All this work also needs to be complemented and validated
with usability tests and analysis.</p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          1.
          <string-name>
            <surname>Avelar</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          :
          <article-title>Schematic Maps on Demand: Design, Modeling and Visualization</article-title>
          .
          <source>PhD thesis</source>
          , Swiss Federal Institute of Technology Zurich (
          <year>2002</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          2.
          <string-name>
            <surname>Porathe</surname>
            ,
            <given-names>T.</given-names>
          </string-name>
          :
          <article-title>User-Centered Map Design</article-title>
          .
          <source>Design</source>
          (
          <year>2007</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          3.
          <string-name>
            <surname>Steiniger</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Neun</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Edwardes</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          :
          <article-title>Foundations of location based services</article-title>
          . (
          <year>2006</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          4.
          <string-name>
            <surname>Avelar</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Hurni</surname>
            ,
            <given-names>L.</given-names>
          </string-name>
          :
          <article-title>On the Design of Schematic Transport Maps</article-title>
          . Cartographica: The
          <source>International Journal for Geographic Information and Geovisualization</source>
          <volume>41</volume>
          (
          <year>2006</year>
          )
          <fpage>217</fpage>
          -
          <lpage>228</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          5.
          <string-name>
            <surname>Bogen</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Brandes</surname>
            ,
            <given-names>U.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Ziezold</surname>
          </string-name>
          , H.:
          <article-title>Visual Navigation with Schematic Maps</article-title>
          .
          <source>Visual Information Communication</source>
          (
          <year>2010</year>
          )
          <fpage>65</fpage>
          -
          <lpage>84</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          6.
          <string-name>
            <surname>OPT: Abstract Graphs Library Specification (Internal Report)</surname>
          </string-name>
          (
          <year>2009</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          7.
          <string-name>
            <surname>Cabello</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Deberg</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Vankreveld</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          :
          <article-title>Schematization of networks</article-title>
          .
          <source>Computational Geometry</source>
          <volume>30</volume>
          (
          <year>2005</year>
          )
          <fpage>223</fpage>
          -
          <lpage>238</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          8.
          <string-name>
            <surname>Cabello</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Kreveld</surname>
            ,
            <given-names>M.V.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Sciences</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Box</surname>
            ,
            <given-names>P.O.</given-names>
          </string-name>
          :
          <article-title>Schematic Networks: An Algorithm and its Implementation</article-title>
          . In Richardson, D.,
          <string-name>
            <surname>Oosterom</surname>
          </string-name>
          , P., eds.
          <source>: 10th International Symposium on Spatial Data Handling (SDH)</source>
          , Ottawa, Springer (
          <year>2002</year>
          )
          <fpage>475</fpage>
          -
          <lpage>486</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref9">
        <mixed-citation>
          9.
          <string-name>
            <surname>Barkowsky</surname>
            ,
            <given-names>T.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Latecki</surname>
            ,
            <given-names>L.J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Richter</surname>
            ,
            <given-names>K.</given-names>
          </string-name>
          f.:
          <source>Schematizing Maps : Simplification of Geographic. Cognition</source>
          <volume>8</volume>
          (
          <year>2000</year>
          )
          <fpage>41</fpage>
          -
          <lpage>53</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref10">
        <mixed-citation>
          10.
          <string-name>
            <surname>Anand</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Avelar</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Ware</surname>
            ,
            <given-names>J.M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Jackson</surname>
            ,
            <given-names>M.:</given-names>
          </string-name>
          <article-title>Automated schematic map production using simulated annealing and gradient descent approaches</article-title>
          .
          <source>Technology</source>
          (
          <year>2000</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref11">
        <mixed-citation>
          11.
          <string-name>
            <surname>Ware</surname>
            ,
            <given-names>J.M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Taylor</surname>
          </string-name>
          , G.E.,
          <string-name>
            <surname>Thomas</surname>
            ,
            <given-names>N.</given-names>
          </string-name>
          :
          <source>Automated Production of Schematic Maps for Mobile Applications. Transactions in GIS 10</source>
          (
          <year>2006</year>
          )
          <fpage>25</fpage>
          -
          <lpage>42</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref12">
        <mixed-citation>
          12. N¨ollenburg, M.:
          <article-title>Automated drawing of metro maps</article-title>
          .
          <source>PhD thesis</source>
          , Universitat
          <string-name>
            <surname>Karlsruhe</surname>
          </string-name>
          (
          <year>2005</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref13">
        <mixed-citation>
          13. N¨ollenburg,
          <string-name>
            <given-names>M.</given-names>
            ,
            <surname>Wolff</surname>
          </string-name>
          ,
          <string-name>
            <surname>A.</surname>
          </string-name>
          :
          <article-title>A Mixed-Integer Program for Drawing High-Quality Metro Maps</article-title>
          .
          <source>Graph Drawing</source>
          <volume>3843</volume>
          (
          <year>2006</year>
          )
          <fpage>321</fpage>
          -
          <lpage>333</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref14">
        <mixed-citation>
          14.
          <string-name>
            <surname>Dong</surname>
            ,
            <given-names>W.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Guo</surname>
            ,
            <given-names>Q.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Liu</surname>
          </string-name>
          , J.:
          <article-title>Schematic road network map progressive generalization based on multiple constraints</article-title>
          .
          <source>Geo-spatial Information Science</source>
          <volume>11</volume>
          (
          <year>2008</year>
          )
          <fpage>215</fpage>
          -
          <lpage>220</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref15">
        <mixed-citation>
          15.
          <string-name>
            <surname>Scacchi</surname>
          </string-name>
          , W.:
          <article-title>Process Models in Software Engineering</article-title>
          .
          <source>October</source>
          (
          <year>2001</year>
          )
          <fpage>1</fpage>
          -
          <lpage>24</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref16">
        <mixed-citation>
          16.
          <string-name>
            <surname>Laurini</surname>
            ,
            <given-names>R.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Servigne</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Nol</surname>
          </string-name>
          , G.:
          <article-title>Soft real-time GIS for disaster monitoring</article-title>
          , Springer-Verlag (
          <year>2005</year>
          )
          <fpage>465</fpage>
          -
          <lpage>480</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref17">
        <mixed-citation>
          17.
          <string-name>
            <surname>Neighbors</surname>
            ,
            <given-names>J.M.:</given-names>
          </string-name>
          <article-title>The Draco approach to constructing software from reusable components</article-title>
          .
          <source>IEEE Transactions on Software Engineering</source>
          <volume>10</volume>
          (
          <year>1984</year>
          )
          <fpage>567</fpage>
          -
          <lpage>574</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref18">
        <mixed-citation>
          18.
          <string-name>
            <surname>Goguen</surname>
            ,
            <given-names>J.A.</given-names>
          </string-name>
          :
          <article-title>Reusing and interconnecting software components</article-title>
          .
          <source>Computer</source>
          <volume>19</volume>
          (
          <year>1986</year>
          )
          <fpage>16</fpage>
          -
          <lpage>27</lpage>
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>