Factores de riesgo del embarazo adolescente

This chapter has presented an architectural pattern for SDIs that allows to model them as federations of communities in terms of the enterprise language of the ISO RM-ODP. This pattern proposes a systematic approach to model the purpose, expected behaviour and policies of an SDI, starting from the communities that compose it and the relation- ships among them. These relationships may be hierarchical, but other arrangements are allowed if needed. The pattern includes a minimum set of SDI components com- monly found in the bibliography, and others that have been found necessary under the guidelines provided by the enterprise language of the RM-ODP.

Architects and designers may apply this pattern as it is to produce an enterprise architectural view of a given SDI, or they may extend and refine some of its elements if needed. In any case, the use of this pattern provides a starting point founded on solid concepts, provided by the RM-ODP, and a way to facilitate the exchange of knowledge about SDI models.

To test the applicability of this pattern to a complex SDI, and also as an example of use, the INSPIRE directive has been analyzed. It has been shown that most components and rules addressed by INSPIRE are similar to those proposed in the pattern, or are specializations that can be modelled extending them.

the implications of that is that SDIs cannot be fully designed and then implemented. SDIs are complex systems in constant change, with many different components, and where many actors, with different interests, necessities and degrees of autonomy, are constantly interacting. We thus expect that the pattern proposed in this work can be useful to model SDIs to a certain extent (i.e. fundamental roles, policies, interactions etc.), that is enough to set up an ‘SDI game board’ where the evolving interactions among its communities, actors, objects etc. can take place, an be followed. Further research is needed to validate this point, and also to evaluate other conceptual frame- works, especially systems of systems and federations of systems [152], which can prove themselves useful to tackle the complexity that is inherent to SDIs.

A Component & Connector

Architectural Style for Spatial

Data Infrastructures

3.1

Introduction

From different points of view, Spatial Data Infrastructures (SDIs) have some charac- teristics of digital libraries [138] and of Information Infrastructures (IIs) [74]. From the II point of view, an SDI may be formed by several interconnected systems that could be seen as SDIs themselves. When one of these systems is responsibility of one organization, it is usually not considered as the piece of an infrastructure, but as an information system which must adhere to certain rules and principles, to facilitate its interaction with others, and which has its own requirements and organization. This aspect of SDIs must be taken into account when addressing its design, creation, and maintenance and it is the main focus of this section.

The original definitions of SDIs already include, directly or indirectly, the neces- sity to provide search, visualization and data download services [78]. Nevertheless the current research trends in the evolution of distributed interoperable Geographic Infor- mation Systems (GIS), based on standard [83, 16] and semantically enabled [104, 112], geographic Web services [43], have made some authors argue that SDIs will soon in- clude all kind of geographic Web services [14, 177]. This trend will produce SDIs more and more complex. One way to cope with this complexity is to have the appropriate

mechanisms to describe these infrastructures in architectural terms.

There are several previous works which propose reference and/or architectural mod- els for SDIs. Among the most relevant ones it is worth mentioning the description of the USA National SDI [58]; the proposal in [70] about the Canadian infrastructure and the initial proposals for the European SDI established in [91]. All these architectural models share the same problems:

• They are focused on the allowed components for the architecture and they barely mention, when they are mentioned, other elements of an architecture, as the types of relationships among the components, their visible properties or necessary constraints.

• There are non-obvious overlappings among the different architectural models. Components with different names but similar roles are common.

• They are not completely grounded in well-known architectural models. A Service Oriented Architecture (SOA) [53] is commonly mentioned as the basis, but this architectural model fails to capture many components included in these models like applications or data repositories; no other references to software architecture models are provided.

As the documented reference models for SDI architectures in the bibliography do not follow any kind of common structure or pattern, comparing them, or verifying that a GIS follows one of these architecture reference models, is difficult and ad hoc. In this chapter, an SDI architectural style is defined to capture the current knowledge about SDI architectural models while avoiding the problems of the currently published models.

The rest of this chapter is structured as follows: Firstly an architectural style for SDI is defined, after analyzing the architectures proposed by six SDI and geographic services reference models, following the ‘Views and Beyond’ proposal [45]. In section 3.3 three real SDI projects with published architectural descriptions are studied to determine their compatibility with the proposed style. The next section offers an ar- chitectural description of one of these projects, following the proposed style, to highlight

the benefits of its use. In the final section some important issues are highlighted and conclusions are drawn.