This shows you the differences between two versions of the page.
|
hekate:hekate_process [2009/11/18 11:23] kkluza |
hekate:hekate_process [2019/06/27 15:49] |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ====== 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: | ||
| - | * knowledge-based, | ||
| - | * based on the abstraction-specification relation, | ||
| - | * hierarchical, | ||
| - | * integrated, | ||
| - | * formalized. | ||
| - | |||
| - | Abbreviations used: | ||
| - | * TBC = To Be Considered | ||
| - | * WIP = Work In Progress | ||
| - | * FIXME = guess what :-) | ||
| - | ====== Stages ====== | ||
| - | |||
| - | The process is involves the following the stages described below. | ||
| - | |||
| - | * Main wikipage: hekate_case_NAME:start | ||
| - | |||
| - | The main wikipage includes other subpages, see [[hekate:cases:hekate_case_skel:start]] | ||
| - | |||
| - | ===== 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. [[wp>structured english]]. | ||
| - | |||
| - | * Input: users's descriptions | ||
| - | * Output: text-based description | ||
| - | * Wikipages: hekate_case_NAME:description | ||
| - | * Remarks: the [[:hekate:hekate_process#encoding]] of this stage is non existant, KD can be considered FIXME | ||
| - | |||
| - | |||
| - | ===== 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: | ||
| - | * the [[:hekate:hekate_process#encoding]] of this stage is non existant, KD can be considered FIXME | ||
| - | * in some cases the original design can contain some concepts! | ||
| - | |||
| - | ==== 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. | ||
| - | |||
| - | |||
| - | * 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 [[:hekate:hekate_process#encoding]] of this stage is non existent, KD can be considered FIXME | ||
| - | * in some cases the original design can contain some vocabulary! (see UServ, etc) | ||
| - | ==== 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? FIXME | ||
| - | * //__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?__// --- //[[kinio4444@gmail.com|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. | ||
| - | |||
| - | * 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''. FIXME | ||
| - | * 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 [[:hekate:hekate_process#encoding|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. | ||
| - | |||
| - | ==== General Conceptual Design ==== | ||
| - | 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. | ||
| - | |||
| - | ==== Directed Conceptual Design ==== | ||
| - | In a case where the [[hekate_process: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 [[hekate_process: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 [[:hekate:hekate_process#conceptual design]] | ||
| - | in a //standalone// form, that is only the appropriate [[:hekate:hekate_process#ATTML]] encoding. | ||
| - | It is a natural input for the next stage. | ||
| - | It is also a point, where the formalized [[:hekate:attributes|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 | ||
| - | - loaded to HQED, | ||
| - | - //warning//: conceptual atts should be removed, since the are not present in the xtt itself | ||
| - | - types need to be defined! | ||
| - | - attributes need to be assigned to the new domains | ||
| - | - 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 - [[hekate:cases:howto#attribute_specification|HOWTO description]] | ||
| - | |||
| - | ===== Prototyping ===== | ||
| - | |||
| - | Using a partial output of the [[:hekate:hekate_process#conceptual design]] | ||
| - | that is only the appropriate [[hekate markup language|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. | ||
| - | |||
| - | |||
| - | ===== 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-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 {{:hekate:callbackslibrary.zip|NetBeans project}}, take a look at {{:hekate:hekatecases:hekate_case_thermostat:hekate_case_thermostat-clb.pl|ThermostatCalbacks}} to see how to use them. Also you will have to install JPL extension to launch Java code from within HMR. See [[https://ai.ia.agh.edu.pl/wiki/student:msc2009_xtteng:jpl?s[]=jpl&s[]=quest|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 [[:hekate:hekate_process#encoding|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. \\ | ||
| - | 8-) HQEd allow for image compression: Tools->Settings->XTT Options->Scene. The default compresion level is 0%:!: | ||
| - | |||
| - | ===== Formal Analysis ===== | ||
| - | 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: | ||
| - | |||
| - | ===== 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. | ||
| - | |||
| - | |||
| - | * Input: full xtt design, //hekate_case_NAME:hekate_case_NAME-rt.pl// | ||
| - | * Files: | ||
| - | * FIXME, at least basic input callbacks | ||
| - | * Output: reports? trajectories | ||
| - | * Remarks: FIXME | ||
| - | * different inference modes? | ||
| - | |||
| - | |||
| - | ===== Integration ===== | ||
| - | This stage involves integrating the XTT logic with the environment with: | ||
| - | * callbacks | ||
| - | * knowledge encodings, translations | ||
| - | * UML representation | ||
| - | * Java serialization | ||
| - | * other? | ||
| - | |||
| - | FIXME | ||
| - | |||
| - | ==== Callbacks ==== | ||
| - | A minimal step here is to write callback for HeaRT in Prolog, XPCE, Java, Python. | ||
| - | |||
| - | |||
| - | ==== UML Serialization ==== | ||
| - | * KKL: ARD+XTT | ||
| - | * JSJ? | ||
| - | |||
| - | ==== Java Serialization ==== | ||
| - | * LLK: Java Serialization x2 | ||
| - | |||
| - | ==== SemWeb Serialization ==== | ||
| - | * WTF: daal | ||
| - | * MKL: swrl! | ||
| - | * JSJ? | ||
| - | |||
| - | ==== Rule Engine Implementation ==== | ||
| - | * LLK: Drools | ||
| - | |||
| - | ==== Encoding ==== | ||
| - | Currently XML encodings to be used: | ||
| - | * ATTML | ||
| - | * ARDML | ||
| - | * XTTML | ||
| - | The are now integrated into //HML// the [[Hekate Markup Language]]. | ||
| - | |||
| - | ==== Knowledge Markups ==== | ||
| - | Aspects: | ||
| - | * ATTML <-> RDF | ||
| - | * RIF <-> ARD | ||
| - | * RIF <-> XTT | ||
| - | * SWRL <-> XTT | ||
| - | * ontologies <-> ATTML | ||
| - | * ontologies <-> ARDML | ||
| - | |||
| - | FIXME | ||
| - | HatHoR | ||
| - | |||
| - | ===== Summary ===== | ||
| - | 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 | ||
| - | |||
| - | ====== Tools ====== | ||
| - | Current tools, see [[:hekate:HaDEs]]. | ||
| - | |||
| - | |||
| - | ====== Case Template ====== | ||
| - | See [[:hekates:cases:hekate_case_skel:start|skeleton case]] | ||
