Information Technology Reference
In-Depth Information
digital imaging technologies and the later for ordinary users. We should note
at this point that Act. 3 and Act. 4 can be performed in any order or in par-
allel. For example, performing Act. 4 before Act. 3 allows one to reduce the
dependencies that have to be captured, e.g. we will not have to analyze the
dependencies of
Image Viewer
because that module is already known
from both profiles.
Act. 5
Exploit the intelligibility-related services according to the needs.
We can
answer questions of the form:
which modules are going to be affected if we
remove the
3D Studio
from our system
? The answer to this question is
the set
{
t
|
t
>3
D Studio
}
. As another example, we can answer questions of
the form:
which are the missing modules, if an ordinary user u wants to
render the 3D image
Illusion.3ds
? In general such services can be
exploited for identifying risks, for packaging, and they could be articulated
with monitoring and notification services.
Act. 6
Evaluate the services in real tasks and curate accordingly the reposi-
tory.
For instance, in case the model fails, i.e. in case the gap is empty but
the consumer is unable to understand the delivered module (unable to per-
form a task), this is due to dependencies which have not been recorded. For
example assume that an ordinary user wants to render a 3D image. To this
end we deliver to him the intelligibility gap which contains only the module
3D Studio
. However the user claims that the image cannot be rendered.
This may happen because there is an additional dependency that has not
been recorded, e.g. the fact that the
matlib
library is required to render a
3D model correctly. A corrective action would be to add this dependency
(using the corresponding activity, Act. 3). In general, empirical testing is a
useful guide for defining and enriching the graph of dependencies
8.2.5 Relaxing Community Knowledge Assumptions
DC profiles are defined as sets of modules that are assumed to be known from the
users of a Designated Community. According to Axiom 1 the users of a profile will
also understand the dependencies of a module and therefore they will be able to
perform all tasks that can be performed. However users may know how to perform
certain tasks with a module rather than performing all of them. For example take the
case of Java class files. Many users that are familiar with Java class files know how
to run them (they know the module denoting the Java class files and they understand
its dependencies regarding its runability, i.e. the module
JVM
), but many of them do
not know how to decompile them.
In order to capture such cases, we must define DC profiles without making
any assumptions about the knowledge they convey (as implied from Axiom 1).
No assumptions about the modules of a profile means that the only modules
that are understandable from the user
u
of the profile are those in the set
T(u)
.
Additionally the only tasks that can be performed are those whose modules and
