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:

• knowledge-based,
• based on the abstraction-specification relation,
• hierarchical,
• integrated,
• formalized.

Abbreviations used:

• TBC = To Be Considered
• WIP = Work In Progress
• = guess what

The process is involves the following the stages described below.

• Main wikipage: hekate_case_NAME:start

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.

• Input: users's descriptions
• Output: text-based description
• Wikipages: hekate_case_NAME:description
• Remarks: the encoding of this stage is non existant, KD can be considered

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.

• Input: text-based description
• Output: possible attributes, properties, etc
• Wikipages: hekate_case_NAME:conceptualization
• Remarks:
  • the encoding of this stage is non existant, KD can be considered
  • in some cases the original design can contain some concepts!

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.

• Input: text-based description, conceptualization
• Output: possible relations between attributes, properties, etc (At this stage some loose semantic relations can be identified. Some methods that could be used here are SBVR, ontologies, etc.)
• Wikipages: hekate_case_NAME:vocabulary
• Remarks:
  • the encoding of this stage is non existent, KD can be considered
  • in some cases the original design can contain some vocabulary! (see UServ, etc)

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.

• Input: original rules from the case study, tables, etc, possibly a control structure in case of drools
• Output: observations?
  • there are constraints in Hekate Rule Format (i.e. avr in conditional context is not allowed). Maybe such observations should contain information concerning this constraints? — Krzysztof Kaczor 2009/07/14 19:45
• Wikipages: hekate_case_NAME:rules
• Remarks:
  • In the business rules approach number of rule types are identified, that do not map in a straightforward way to the HeKatE logical design.

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.

• Input: previous information, description
• Wikipages:
  • hekate_case_NAME:ard_design
• Files:
  • hekate_case_NAME:hekate_case_NAME-mdl.pl the main Varda file used to build the model
  • hekate_case_NAME:hekate_case_NAME-[1-90-9]-ard.{png,dot,pdf} (separate levels in three formats)
  • hekate_case_NAME:hekate_case_NAME-[1-90-9]-tph.{png,dot,pdf} (separate levels in three formats)
  • hekate_case_NAME:hekate_case_NAME-[1-90-9]-mdl.{png,dot,pdf} (separate levels in three formats)
  • hekate_case_NAME:hekate_case_NAME-ard.{png,dot,pdf} (the last level)
  • hekate_case_NAME:hekate_case_NAME-tph.{png,dot,pdf} (the last level)
  • hekate_case_NAME:hekate_case_NAME-mdl.{png,dot,pdf} (the last level)
  • hekate_case_NAME:hekate_case_NAME-ard.hml
  • hekate_case_NAME:hekate_case_NAME-hjd[1-9].png (HJEd color screenshots, make them visible)
• a script to generate the above files is available with VARDA and is called varda-case-gen.
• Output:
  • The output of this stage is the low-level ARDplus diagram with physical attributes, plus attribute domains, and types description.
  • This output as a whole is encoded with use of the HeKatE Markup Language.
• Remarks:
  • test new shell in VARDA
  • test set-based representation in VARDA (experimental feature, disabled by default!)
  • compare VARDA with HJEd

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.

• Input: previous ard design, the hekate_case_NAME:hekate_case_NAME-ard.hml file prepared with VARDA
• Files:
  • hekate_case_NAME:hekate_case_NAME-att.hml
• Output: physical att specs in HML
• Remarks:
  • at this stage it should be possible to import attributes from other formalized sources, e.g. RIF-based systems.
  • this should be compatible with the attributive logic concepts and definitions.

Currently (as of 09.2009) the only tool support is with HQEd. So the file generated with VARDA should be

1. loaded to HQED,
2. warning: conceptual atts should be removed, since the are not present in the xtt itself
3. types need to be defined!
4. attributes need to be assigned to the new domains
5. and the new file should be saved and uploaded/submitted.

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

• types' names should be different from attribute names!
• types' names can have plural form, e.g. type “weekdays” might be used for the attribute “day”
• types' names should be meaningful!

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.

• Input: previous ard design in hml, hekate_case_NAME:hekate_case_NAME-att.hml
• Files:
  • hekate_case_NAME:hekate_case_NAME-prt.hml
  • hekate_case_NAME:hekate_case_NAME-prt.{png,dot,pdf}
• Output: xtt tabs prototypes
• Remarks:
  • compare xtt proto generation by varda and hqed! → report any differences in the wiki, report bugs in CVStrac, if any.

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.

• Input: xtt prototype
• Files:
  • hekate_case_NAME:hekate_case_NAME-xtt.hml
  • hekate_case_NAME:hekate_case_NAME-clb.pl HMR file generated by HQEd that includes callbacks (HQEd does not support callbacks deffinitons, so they have to be defined 'manually'). For GUI callbacks see this NetBeans project, take a look at ThermostatCalbacks to see how to use them. Also you will have to install JPL extension to launch Java code from within HMR. See this for Howto.
  • hekate_case_NAME:hekate_case_NAME-xtt.png (screenshot, xtt struct only (no editor window!), B/W View+ File→Export_scene_view→PNG, hqed export sets no compression!, try to compress the fily siply by convert hqedscene.png newfile.png)
  • hekate_case_NAME:hekate_case_NAME-hqd.png (hqed color screenshot, with the xtt struct (with editor window!), try printscreen in GNOME)
• Output:
  • The output of this stages is the full XTT structure encoded with the use of the HML.
• Remarks:
  • while making screenshots try to minimize their size (in terms of unused screen space), maximize readability
  • where callbacks are written?

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:

• HQEd (quality checks, e.g. domains)
• HalVA (verification)

• Input: full xtt design, hekate_case_NAME:hekate_case_NAME-xtt.hml
• Files:
  • hekate_case_NAME:hekate_case_NAME-hva[1-90-9].hml (differnet cases) files with anomalies that HalVA detects
  • hekate_case_NAME:hekate_case_NAME-hva[1-90-9].txt (differnet cases) files with HalVA reports
  • hekate_case_NAME:hekate_case_NAME.tex the full XTT description in LaTeX
• Output: reports?
• Remarks:

The executable design generation.

The XTT representation has a clear, well-defined Prolog representation. This representation is fully automatically generated from the XTT design.

• Input: full xtt design, hekate_case_NAME:hekate_case_NAME-rt.pl
• Files:
  • , at least basic input callbacks
• To launch:

  gox(<state>, [<tables>], <inference process>).

  e.g.

  gox(init, ['Table2', 'Table3'], ddi).

• Output: Trajectories projections. Trajectory is the system inference path. After every inference process invocation new trajectory is generated. The trajectory can be identified by ID, to obtain ID of recently generated trajectory use traj_id(ID) predicate. The ID variable will be unified with an ID of the last trajectory. To save trajectory projection to a file use io_export_trajectory(Filename, TrajID) predicate. If you want to save most recent trajectory type this in Prolog console:

   traj_id(ID),io_export_trajectory('file.txt', ID).

• Remarks:
  • different inference modes?

This stage involves integrating the XTT logic with the environment with:

• callbacks
• knowledge encodings, translations
• UML representation
• Java serialization
• other?

A minimal step here is to write callback for HeaRT in Prolog, XPCE, Java, Python.

• KKL: ARD+XTT
• JSJ?

• LLK: Java Serialization x2

• WTF: daal
• MKL: swrl!
• JSJ?

• LLK: Drools

Currently XML encodings to be used:

• ATTML
• ARDML
• XTTML

The are now integrated into HML the Hekate Markup Language.

Aspects:

• ATTML ↔ RDF
• RIF ↔ ARD
• RIF ↔ XTT
• SWRL ↔ XTT
• ontologies ↔ ATTML
• ontologies ↔ ARDML

HatHoR

In this stage designer experiences and observations should be captured.

Some of the questions to be answered might be:

• was the case easy to model, if not, why
• was the HeKatE methodology helpfull, how, if not, why
• is it possible to suggest some improvements to the methodology
• was the HeKatE designed simplified compared to the original one
• what are the benefits of the HeKatE approach in this case

Current tools, see HaDEs.

See skeleton case