Aspectos generales de la violencia en Colombia: de la violencia de los años

As mentioned in Section 3.3, there are document types, such as module interface denitions and successive implementations, which include redundant information and should, therefore, be implemented using views. The rationale for using a view mechanism for vertical data integration is then to have several virtual abstract syntax graphs denitions for the dierent document types with slightly dierent node and edge types and dierent available operations, while only one common representation of the graph is stored persistently. In this subsection, we discuss how the common persistent representation should be dened and how views should be constructed on top of such a representation.

The structure and available operations of virtual abstract syntax graphs are implemented in a virtual schema in the same way as discussed for plain schemas. The rest of the tool architecture, therefore, will not be aected by the fact that virtual syntax graphs are not stored persistently. Thus, each virtual node type is implemented in a virtual class of the virtual schema. Each edge type starting from the virtual node type is declared by a pair of instance variables in the connected virtual classes.

The structure of the common persistent representation of several virtual abstract syntax graphs must be dened in a common conceptual schema. Therefore, a base class must be available in the conceptual schema for each virtual class of each view that will be constructed on top. Note that several virtual classes may have the same base class, also there may be base classes that are only used in some views, while they are hidden from other views. Moreover, instance variables must be available in each base class for each instance variable of those virtual classes that were derived from the base class. Again one instance variable of the base class might be used for instance variables of several virtual classes.

A virtual schema is then dened based on such a conceptual schema. Virtual classes are derived from base classes. During that process instance variables of the base class, which should not be visible in the virtual class, are hidden. Operations that were available in the base class can be hidden as well. In addition, the virtual class denition can dene new operations, for

instance to implement dierent parsing or unparsing schemes for the virtual abstract syntax graph.

To illustrate the use of views in the

O

2 ODBS, we dene two views on top of a conceptual

schema as an example. The views partly implement the two virtual syntax graphs depicted in Figure 3.2 on Page 25. The conceptual schema dening the structure of the real syntax graph of that example contains the class denitions given below.

schema Module_schema; base Module_base1;

name AllModules:DocumentVersionTable;

class OperationList inherit Increment class Operation inherit Increment type tuple(opl:list(Operation)) type tuple(name:OpName,

method pl:ParamList,

public init(f:Increment) com:Comment,

public collapse, vd:VarDeclList,

public expand, st:StatementList)

public add(o:Operation,after:Operation), end; public insert(o:Operation,before:Operation) end;

class Procedure inherit Operation class Function inherit Increment

method type tuple(typ:UsingType)

public init(f:Increment), method

public collapse, public init(f:Increment),

public expand, public collapse,

end; public expand

end;

class StatementList inherit Increment class VarDeclList inherit Increment type tuple(sl:list(Statement)) type typle(vl:list(Statement))

method method

public init(f:Increment), public init(f:Increment),

public collapse, public collapse,

public expand, public expand,

public add(s:Statement,after:Statement), public add(s:VarDecl,after:VarDecl), public insert(s:Statement,before:Statement) public insert(s:VarDecl,before:VarDecl)

end; end;

...

Based on this conceptual schema, consider an excerpt of the denition of virtual classes in two views. The rst is a view for the module interface tool and the second denes a view for the module implementation tool displayed in Figure 2.1. The two view denitions implement the virtual node types displayed in Figure 3.2.

virtual schema Interface_view virtual schema Source_view

from Module_schema; from schema Module_schema;

virtual class IOperationList virtual class SOperationList

from OperationList; from OperationList;

inherit Increment; ... inherit Increment; ...

virtual class IOperation virtual class SOperation

from Operation; from Operation;

inherit Increment; inherit Increment; ...

hide attribute vd,st; ...

virtual class IProcedure virtual class SProcedure

from Procedure; from Procedure;

inherit IOperation; ... inherit SProcedure; ...

virtual class IFunction virtual class SFunction

from Function; from Function;

inherit IOperation; ... inherit SProcedure; ...

hide class VarDeclList; virtual class SVarDeclList

from VarDeclList; inherit Increment; ... hide class StatementList; virtual class SStatementList

from StatementList; inherit Increment; ...

The rst two lines declare two new views, namelyInterface viewandSource view, based on the

common schema Module schema. The declaration ofInterface view hides classesVarDeclList

and StatementList from the view. Consequently, the instance variables vd and st imple-

menting syntactic edges between operations and variable declarations or statement list nodes, respectively, are hidden in the view as well. On the other hand, view Source viewimplements

virtual node types for variable declarations and statement lists, as they occur in syntax graphs of programming languages. Consequently, Source view does not hide the respective instance

variables from class SOperation.

As an example of how dierent methods are dened for two virtual classes, we consider the two virtual classes that were derived from class Functionin more detail.

virtual class IFunction virtual class SFunction

from Function; from Function;

inherit IOperation; inherit SProcedure;

method method

public unparse:string, public unparse:string,

public parse:string, public expand_var_decl,

public expand_type(s:string):boolean, public expand_stmt_list, public change_type(s:string):boolean end;

end; end;

Both virtual classes declare an unparse method with the same signature. The implementa- tions of these methods, however, dier in that they implement dierent unparsing schemes of functions. Moreover, the view denitions enforce changes to interfaces of functions to be performed in the design, since Source viewdoes not oer any methods for changing a func-

tion's interface. The Source view denition of a function, however, does provide methods for

expanding variable declarations or the statement list implementing the body, which are not available in the interface view.

Each view must declare a counterpart to the named object dened in the conceptual schema in order to get a common root for all virtual abstract syntax graphs. This root is, for instance, used as a starting point for navigations through the virtual abstract syntax graph. This

starting point is dened as a virtual named object in the view. Its contents may be restricted by an object-oriented query to a subset of real objects. During this query, real objects are transferred into virtual objects by conversion functions.

The example below denes the virtual named object for the Interface view. It selects all

modules that exist in the database, translates them into modules of the interface view and includes them in the virtual named object AllInterfaces.

virtual schema Interface_view from Module_schema; virtual name AllInterfaces:set(IModule);

has value

select As_IModule(d)

from d in AllModules->VALUES();

We can also explain now why virtual abstract syntax graphs, which are implemented with views as outlined above, can be updated. The required updates are the creation of a new virtual node, changes of virtual node attributes, the creation and the deletion of a virtual edge and the deletion of a virtual node. The creation of a virtual node requires the creation of a new virtual object in the view. To create the new object we apply the new operator to

a virtual class, for instance IFunction. The newoperator invokes the constructor. The view

mechanism, in turn, has generated the constructor for IFunction in such a way that it rst

creates a new object of the base class Function. This creation implies the execution of the

constructor of Function, which, in turn, properly initialises all instance variables of the base

object. That means that, during the creation of a virtual object, not only the instance variables for the virtual object, but also the instance variables that are hidden in the view are properly initialised. In the example, the constructor would also initialise instance variables vd and st,

although they are not visible in the view. In RDBS views, this is not the case due to the lack of appropriate object constructors. Finally, the constructor of the virtual class stores a reference to the base object in the virtual object. This reference is, in fact, the only instance variable that is really stored in the virtual object. Any other instance variable access or modication is mapped to an instance variable access or modication of the real object, which is identied by the stored reference. Node attribute changes and the creation and deletion of edges are implemented in terms of such instance variable modications. They persist because they are eectively mapped to changes of instance variables in the real object. Suppose, for example, that we want to create a new edge between a virtual function and a virtual parameter list in the interface view. We then have to assign the virtual parameter list object to instance variable

pl of the virtual function. The view mechanism will eectively assign the base object of the

virtual parameter list to the instance variable plof the base object of the virtual function. In

this way the update persists in the database and is also visible in the implementation view. Deletion of a virtual object from the view is simply done by assigning the undened value of nil to the reference that referred to the object. In the persistent representation, the garbage collector of the database takes care that any objects without references to them are deleted. In short, the view mechanism of

O

2facilitates vertical data integration. Using this mechanism,

a number of tools can share a conceptual schema in a controlled way. While sharing the schema, tools also share the persistent representation of syntax graphs. Using the

O

2 view

mechanism, it is then possible to declare dierent virtual schemas based on the conceptual schema, one for each tool, and implement dierent structures and behaviours of the same persistent representation.

In document Memorias de la violencia política en la narrativa de jóvenes escolares del sur del departamento de Casanare (página 56-67)