Information Technology Reference
In-Depth Information
a module can be a collection of documents, or alternatively every document in the
collection can be considered as a module.
In order to ensure the intelligibility of digital objects first we have to identify
which are the permissible actions with these objects. This is important because of
the heterogeneity of digital objects and the information they convey. For example
considering a Java source code file
HelloWorld.java
, some indicative actions
we can perform with it are to compile it and read it. To this end we introduce the
notion of tasks. A task is any action that can be performed with modules. Once
we have identified the tasks, it is important, for the preservation of intelligibility,
to preserve how these tasks are performed. The reliance of a module on others for
the performability of a task is captured using dependencies between modules. For
example for compiling the previous file we can define that it depends on the avail-
ability of a java compiler and on all other classes and libraries it requires. Therefore
a rich dependency graph is created over the set of modules.
In what follows we use the following notations; we define
T
as the set of all
modules and the binary relation
>
on
T
is used for representing dependencies.
A relationship
means that module
t
depends on module
t
.
The interpretations of modules and dependencies are very general in order to
capture a plethora of cases. Specifying dependencies through tasks leads to depen-
dencies with different interpretations. To distinguish the various interpretations we
introduce dependency types and we require every dependency to be assigned at least
one type that denotes the objective (assumed task) of that dependency. For exam-
ple the dependencies illustrated at Fig.
8.2
(Sect.
8.1
) are the dependencies of a
software application required for running that application. We can assign to such
dependencies a type such as
_run
.
We can then organize dependency types hierarchically to enable deductions of
the form “
if we can do task A then certainly we can do task B
”. For example if we
can edit a file then we can read it.
If
D
denotes the set of all dependency types, and types
d,d
∈
D,
we shall use
d
to denote that
d
is a subtype of
d
,e.g.
_edit
_read
.
Analogously, and for specializing the very general notion of module to more
refined categories, module types are introduced. For example, the source code of a
program in java could be defined as a module of type
SoftwareSourceCode
.
Since every source code contains text,
SoftwareSourceCode
can be defined as
a subtype of
TextFile
. For this reason module types can be organized hierarchi-
cally. If
C
is the set of all modules and
c,c
∈
d
c
denotes that
c
is a subtype
C
then
c
of
c
.
Since the number of dependency types may increase, it is beneficial to organize
them following an object-oriented approach. Specifically we can specify the domain
and range of a dependency type to be particular module types. For example the
