The HeKatE project aims at providing an integrated design process described below.
This is an integrated design process, based on the concept of the executable design where the “design” means building a complete system.
Some basic features of this process are:
Abbreviations used:
The process is involves the following the stages described below.
The main wikipage includes other subpages, see hekate_case_skel
The first stage is a general natural language description. A “story” that a customer tells the designer.
The transition from this stage requires some basic NL (Natural Language) processing, possibly through simple NL parser or semi-formalization, e.g. structured english.
In this stage some primary concepts are identified. These can be attributes, properties, objects (in the general sense), or rules.
The output of this stage is a preliminary list of possible attributes, properties. The list may be somehow structured, or formalized. Though, it is not mandatory.
In a general case, the concepts are identified by the designer and captured with use of some simple high-level representation. This is a preliminary attribute identification.
In a case where an already designed system is being modeled, some ready rules can be provided. In the HeKatE approach these rules should be considered a mean of conceptualization only. These rules are often informal, or semi-formal.
The conceptual design stage is the beginning of the formalized hierarchical process. Based on the concepts, or vocabulary, the ARD properties and attributes are being identified, as well as functional dependencies between them stated.
See the ARDplus design for the detailed specification.
varda-case-gen
. HOWTO
There is a script that generates the file hekate_case_NAME:ard_design
To use it, try:
cd hekatecases/hekate_case_mycase ; ../wikigen-ard
It generates the page to the stdout, you can paste it to the wiki using a webbrowser.
In a general case, the ARD diagram is built using the vocabulary previously identified.
This is a case where no explicit original rules where present.
In a case where the original rules were provided, the physical attributes identified during the design should match the original rules. The lowest ARD level should match the structure of the original rule-base.
DEFAULT CASE
This is also a case where the original rules were provided. However, the design is not aimed at matching the original rule-base. The goal is to improve the original design with the HeKatE approach.
This is actually the partial output of the conceptual design in a standalone form, that is only the appropriate ATTML encoding. It is a natural input for the next stage. It is also a point, where the formalized attribute specification can be shared with other systems, tools and approaches.
Currently (as of 09.2009) the only tool support is with HQEd. So the file generated with VARDA should be
Please note: at this stage some general attributes can be provided.
So having the thermostat_setting
one can define a named type temperature
which is a numeric with a given domain, and then define the thermostat_setting
having the type temperature
.
Types Best Practices
BETA version of XSLT translator from HML 2 wiki table is provided in CVS - HOWTO description
Using a partial output of the conceptual design that is only the appropriate ARDML dependencies.
In this stage a fully or semi automated generation of the XTT table schemas (rule prototypes) is performed. Using the lowest ARD level XTT schemes are generated. The inference structure (table-to-table links) is also built which serve as a guideline for future XTT processing order.
The output of this stages is the XTT schemes structure with the use of the HML.
HINT: as of now, simply link the prt files produced automatically by VARDA, try to build a proto with HQED - report differences if they exist.
In this stage the actual design of the XTT tables is put forward. Tables are filled with rules, and extra, fine-grained links can be added (row-to-row) links.
See the XTT design for the detailed specification.
convert hqedscene.png newfile.png
)
REMARK: if you design several versions, variants of the XTT structure, store them with the above names with numbers or _comment before the file extension.
HQEd allow for image compression: Tools→Settings→XTT Options→Scene. The default compresion level is 0%
In this stage the logical description of the XTT is used to conduct a formal analysis of selected formal properties such as:
Show functions of:
The executable design generation.
The XTT representation has a clear, well-defined Prolog representation. This representation is fully automatically generated from the XTT design.
gox(<state>, [<tables>], <inference process>).
e.g.
gox(init, ['Table2', 'Table3'], ddi).
traj_id(ID),io_export_trajectory('file.txt', ID).
This stage involves integrating the XTT logic with the environment with:
A minimal step here is to write callback for HeaRT in Prolog, XPCE, Java, Python.
Currently XML encodings to be used:
The are now integrated into HML the Hekate Markup Language.
Aspects:
HatHoR
In this stage designer experiences and observations should be captured.
Some of the questions to be answered might be:
Current tools, see HaDEs.
See skeleton case