This is an old revision of the document!
The HeKatE Design Process
The HeKatE project aims at providing an integrated design process described below.
Introduction
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:
TBC = To Be Considered
WIP = Work In Progress
= guess what
Stages
The process is involves the following the stages described below.
The main wikipage includes other subpages, see hekate_case_skel
Description
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
Conceptualization
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:
Vocabulary
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.
Original Rules
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.
Observations
Conceptual 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.
General Conceptual Design
In a general case, the ARD diagram is built using the vocabulary previously identified.
Directed Conceptual Design
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
Refined Conceptual Design
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.
Attribute Specification
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:
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 loaded to HQED, the attribute domains, etc. should be specified, 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
.
provide xslt for wiki export (WTF!)
Prototyping
Using a partial output of the conceptual design
that is only the apropriate 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:
Logical design
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-rt.pl (with callbacks!)
hekate_case_NAME:hekate_case_NAME-cb.pl (callbacks
please verify if callbacks can be kept in the same file as the rt)
hekate_case_NAME:hekate_case_NAME-xtt.png (color screenshot, xtt struct only (no editor window!))
hekate_case_NAME:hekate_case_NAME-hqd.png (hqed color screenshot, with the xtt struct only (with editor window!))
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?
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:
Physical Design
The executable design generation.
The XTT representation has a clear, well-defined Prolog representation.
This representation is fully automatically generated from the XTT design.
UML Serialization
Java Serialization
SemWeb Serialization
WTF: daal
MKL: swrl!
JSJ?
Rule Engine Implementation
Integration
The stages are integrated with:
knowledge encodings
transformations
other?
This needs filling!
Encoding
Knowledge Markups
Aspects:
ATTML ↔ RDF
RIF ↔ ARD
RIF ↔ XTT
SWRL ↔ XTT
ontologies ↔ ATTML
ontologies ↔ ARDML
HatHoR
Current tools:
VARDA
HJEd
HQEd
HeaRT
HaThoR
Case Template
====== Introduction ======
===== Description =====
===== Conceptualization =====
==== Vocabulary ====
==== Original Rules ====
===== Analysis =====
===== Conceptual design =====
==== General Conceptual Design ====
==== Directed Conceptual Design ====
=== Full ARD Model ===
==== Refined Conceptual Design ====
===== Physical Attribute Specification =====
===== Structuralization =====
===== Logical design =====