| |
ATARIX | CAESAR | EXACT |
WSWL |
| |
|
 |
ATARIX |
| |
The increasing growth
in size and complexity of portals calls for a systematic way to
portal development that allows to face the stringent demands imposed
on these systems. These demands range from integrating heterogenous
data sources to navigation and adaptability concerns. |
| |
AtariX is a tool for
Web portal development built around a set of XMLdocuments. AtariX
enables the highlevel description of a Web portalalong distinct
orthogonal dimensions. Each concern is separately described in a
document: how data is integrated and described (the content document),
the topology of links (the navigation document), the layout of each
element (the presentation document), how previous apects can
dinamically vary based on the current session click stream (the
adaptation document) and how control which content has been visited
(the tracking document). A distinctive feature of this approach is
that it is ontology-centric, that is, the content document defines a
set of concepts (as XML tags) to be used as a vocabulary for the
other documents. For instance, navigation is not defined in terms of
pages but concepts, regardless of how these concepts are finally
presented. Hence, we have termed this approach "tag-centric". This
enables an abstract construction of the portal independent of how it
is finally delivered,facilitating maintenance and portal evolution. |
| |
More information about
the AtariX
project |
| |
|
|
|
CAESAR |
| |
There has been some
discussion on whether it is preferable to first determine processing
and from it obtain data, or focus on data and from it derive
processes. We are inclined towards the former option. First,
evidence shows that users tend to explain themselves in terms of
what they do rather than the data required to do it. Second, DBMS
technology is evolving to manage not only the data features of the
domain but also the behavioral ones as illustrated by object-oriented
and active DBMSs. |
| |
In spite of the
ongoing evolution of DBMS, Entity/Relationship (E/R) techniques are
still widely used without substantial changes since they were
initially conceived. E/R schemas as conceptual models, are clearly
lacking a behavioral counterpart. |
| |
CAESAR is a process-directed
tool for elicitating behavioral conceptual models: As an analysis
tool, it aims at determining, understanding and communicating
business information requirements, from which the specification of
the final system can be obtained. Broadly speaking, the tool has two
main interfaces: one for requirement elicitation, and other for
system specification (i.e. conceptual model construction). |
| |
Requirements are
expressed by the set of use-cases which should be supported by the
system. They state the expected functionality of the system to be
built in order to process appropriately these use cases. Each use
case abstracts different ways of interacting with the system to
achieve a similar aim. It is a user-level, black-box view of the
system. It shows the response of the system to external stimuli, but
does not show how the system actually achieves the goal. There are
no internal objects visible, just the system itself and the actors
originating them. In CAESAR, the informal, English description of
use-cases is formalized by using interaction diagrams. Although
described graphically by the analyst, use cases are internally
represented through an ad-hoc language where the main features of
each interaction diagram (i.e. actors, stimuli, notifications,
exceptional alternatives, context, etc) are accounted for. |
| |
Once relevant use
cases have been collected, system specification begins.Specification
is expressed as the set of high-level stimuli which are needed to
support the use cases. These stimuli are then described, verified
and validated. |
| |
Stimulus description
follows the pre/post-condition approach. Pre-conditions state
realistic settings for the stimulus to happen (i.e. it is the
environment who guarantee their satisfaction) and as such, they are
not the concern of the system. However, they describe the context
where the system will function, and help to cope with requirement
evolution. Post-conditions indicate the effect on the system state
as a result of the happening of the stimulus. At this stage, the
system state is expressed as the set of data needs required to
fulfil the use-cases. Each data need belongs to a type (e.g.
enumerated, value-based or switching) which determines the set of
effects applicable to this data (e.g. the operations reset, increase
and decrease are available for the enumerated type). |
| |
Once stimuli have been
described, verification begins, i.e., the process of checking for
contradictions, inconsistencies or incompleteness (e.g. analyst can
ascertain whether both stimuli correspond to the same phenomena but
differently named by the stakeholders, or data needs where only some
operations are applied: a counter which is only increased, but no
stimuli decreases it). |
| |
Clicking on the check
button makes the system to display a set of warning messages which
draw the attention of the analyst. |
| |
Once the conceptual
model has been described in terms of stimuli, the model has to be
validated, i.e. its accurateness has to be checked against the users'
intended requirements. Validation is achieved through animation,
i.e. by providing explanations about the results of model execution.
The event calculus is used to formalize the model (executability). |
| |
Broadly speaking,
animation is a two-step process. First, the user stimulates the
system in meaningful ways, and later on the system is queried to
explain the obtained results. Queries can address why the current
system state holds, how some intended effects can be achieved, and
what would have happened if some other stimulus was given. Here, the
utilization of use-cases is proposed to provide a first guide to
checking whether the model correctly reflects the intended use of
the system. After all, use-cases serve to identify the requirements
and thus, the conceptual model should be checked (at least) against
these use-cases. Besides, use-cases provides a first guide to
ascertaining the kind and order of meaningful stimulus flows rather
than stimulating the system randomly. CAESAR offers a list of the
use cases identified during requirement elicitation, and the user
can create as many scenarios (i.e. use cases instances) as
appropriate. In this way, the user is no longer left alone, but a
framework is provided to determine significant sequences of stimuli. |
| |
Summing up, the CAESAR
outcome is intended to be a set of correct and valid set of stimuli
that serve as a starting point for database specification. |
| |
|
|
|
EXACT |
| |
Active Database
Management Systems (DBMS) introduces an active dimension from which
a large number of applications can be benefited. Most active DBMSs
provide a fixed execution model for this dimension. EXACT is a rule
manager which provides a range of execution models for the active
dimension, from which the designer can choose the one that best fits
the semantics of the concept to be supported. EXACT has been
implemented for the object-oriented DBMS ADAM. |
| |
Experience using
active rules in database systems shown that implement, debug or
maintain large rule bases it is not a straigthforward task. It is
important to provide debugging and explanation facilities for two
reasons: |
| |
- Inform which rules were fired during the execution of an
operation (increasing the user´s confidence and understanding of
the system)
- Help the designer to refine and analyze interactions among
rules at execution time.
|
| |
The idiosyncrasies of
the rule's flow of control, where the rules to be fired cannot be
known in advance, introduce some different requirements from those
found for conventional programming. DEAR is a graphical debugger
implemented for the EXACT system. Special attention was paid in
making explicit the context in which rules were fired. Rules also
have been used as the implementation mechanism of more abstract
statements (e.g. integrity constraint languages). DEAR was extended
in order to explain the flow of execution, taken into account the
level of abstraction from where the active component was expresed. |
| |
|
|
|
WSWL |
| |
Most Web sites offer loosely-coupled services
where the role of the site is almost restricted to be a front-end
for service enactment. If the number of services is large, the
designer should struggle to provide a sense of coherence and unity
among the services that can be accomplished throughout the site.
This is far from being straightforward as control-flow and data-flow
dependencies between services must be enforced. So far, these
aspects are directly hard-coded and scattered around the site. This
hinders not only development, but most important, maintenance and
evolution of the site. Such situation stems from the lack of
abstractions that impede current web programming. |
| |
To overcome this
situation, this work proposes a separate and declarative
specification of the dependencies that regulate services enactment
in web applications: the workview. A workview indicates the
dependencies that harness the set of services that can be invoked
from a site. This notion allows to distinguish service dependencies
between how and where these services are enacted. Therefore, it
affords service designers and page designers the freedom to work
independently which can speed up the whole development process.
These ideas have been realised in an implementation using JSP custom
tags. |
| |
More information about
the WSWL project. |
| |
|
