Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
hekate:hekate_process [2009/07/14 20:37]
kinio
hekate:hekate_process [2019/06/27 15:49] (current)
Line 22: Line 22:
 The process is involves the following the stages described below. The process is involves the following the stages described below.
  
-  * Main File: hekate_case_NAME:​start +  * Main wikipage: hekate_case_NAME:​start 
-    * //__what should contain this file? Some links to other case pagesmaybe something more?​__// ​ --- //[[kinio4444@gmail.com|Krzysztof Kaczor]] 2009/07/14 19:41//+ 
 +The main wikipage includes ​other subpagessee  [[hekate:​cases:​hekate_case_skel:​start]]
  
 ===== Description ===== ===== Description =====
Line 33: Line 34:
   * Input: users'​s descriptions   * Input: users'​s descriptions
   * Output: text-based description   * Output: text-based description
-  * Files: hekate_case_NAME:​description+  * Wikipages: hekate_case_NAME:​description
   * Remarks: the [[:​hekate:​hekate_process#​encoding]] of this stage is non existant, KD can be considered FIXME   * Remarks: the [[:​hekate:​hekate_process#​encoding]] of this stage is non existant, KD can be considered FIXME
  
Line 48: Line 49:
   * Input: text-based description   * Input: text-based description
   * Output: possible attributes, properties, etc   * Output: possible attributes, properties, etc
-  * Files: hekate_case_NAME:​conceptualization+  * Wikipages: hekate_case_NAME:​conceptualization
   * Remarks: ​   * Remarks: ​
     * the [[:​hekate:​hekate_process#​encoding]] of this stage is non existant, KD can be considered FIXME     * the [[:​hekate:​hekate_process#​encoding]] of this stage is non existant, KD can be considered FIXME
Line 60: Line 61:
   * Input: text-based description,​ conceptualization   * 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.)   * 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.)
-  * Files: hekate_case_NAME:​vocabulary+  * Wikipages: hekate_case_NAME:​vocabulary
   * Remarks: ​   * Remarks: ​
-    * the [[:​hekate:​hekate_process#​encoding]] of this stage is non existant, KD can be considered FIXME +    * 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 vocabulry! (see UServ, etc)+    * in some cases the original design can contain some vocabulary! (see UServ, etc)
 ==== Original Rules ==== ==== Original Rules ====
 In a case where an already designed system is being modeled, some ready rules can be provided. In a case where an already designed system is being modeled, some ready rules can be provided.
Line 72: Line 73:
   * Output: observations?​ FIXME   * 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//     * //__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//
-  * Files: hekate_case_NAME:​rules+  * Wikipages: hekate_case_NAME:​rules
   * Remarks: ​   * 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.     * In the [[business rules]] approach number of rule types are identified, that do not map in a straightforward way to the HeKatE logical design.
-===== Analysis ​===== + 
-  * //__ this section is defined in the template below but not here __//  --- //​[[kinio4444@gmail.com|Krzysztof Kaczor]] 2009/07/14 20:35//+==== Observations ​====
  
 ===== Conceptual design ===== ===== Conceptual design =====
Line 86: Line 87:
  
   * Input: previous information,​ description   * Input: previous information,​ description
-  * Files:  +  * Wikipages:  
-    * hekate_case_NAME:​ard_design +    * //hekate_case_NAME:​ard_design// 
-    * hekate_case_NAME:​ard_design.png (all levels) +  * Files: 
-    * hekate_case_NAME:​ard_diagram.png +    * //hekate_case_NAME:​hekate_case_NAME-mdl.pl// the main Varda file used to build the model 
-    * hekate_case_NAME:​ard_diagram.dot +    * //hekate_case_NAME:​hekate_case_NAME-[1-90-9]-ard.{png,dot,pdf}// (separate levels in three formats) 
-    * hekate_case_NAME:​tph_diagram.png +    * //hekate_case_NAME:​hekate_case_NAME-[1-90-9]-tph.{png,dot,pdf}// (separate levels in three formats) 
-    * hekate_case_NAME:​tph_diagram.dot +    * //hekate_case_NAME:​hekate_case_NAME-[1-90-9]-mdl.{png,dot,pdf}// (separate levels in three formats) 
-    * hekate_case_NAME:​ard_model.png (sha!+    * //hekate_case_NAME:​hekate_case_NAME-ard.{png,dot,pdf}// (the last level) 
-    * hekate_case_NAME:​ard_model.dot (sha!+    * //hekate_case_NAME:​hekate_case_NAME-tph.{png,​dot,​pdf}// ​(the last level
-    * hekate_case_NAME:​hekate_case_NAME-ard.hml+    * //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: ​   * Output: ​
      * The output of this stage is the low-level [[ARDplus]] diagram with //physical attributes//,​ plus attribute domains, and types description.      * The output of this stage is the low-level [[ARDplus]] diagram with //physical attributes//,​ plus attribute domains, and types description.
Line 101: Line 105:
   * Remarks: ​   * Remarks: ​
      * test new shell in VARDA      * test new shell in VARDA
-     * test set-based representation in VARDA+     * test set-based representation in VARDA (experimental feature, disabled by default!)
      * compare VARDA with HJEd      * 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 ==== ==== General Conceptual Design ====
 In a general case, the ARD diagram is built using the vocabulary previously identified. In a general case, the ARD diagram is built using the vocabulary previously identified.
  
-//DEFAULT CASE//+This is a case where no explicit original rules where present.
  
 ==== Directed Conceptual Design ==== ==== Directed Conceptual Design ====
Line 114: Line 126:
 The lowest ARD level should match the structure of the original rule-base. The lowest ARD level should match the structure of the original rule-base.
  
-FIXME+//DEFAULT CASE//
  
 ==== Refined Conceptual Design ==== ==== Refined Conceptual Design ====
Line 121: Line 133:
 The goal is to improve the original design with the HeKatE approach. The goal is to improve the original design with the HeKatE approach.
  
-FIXME 
  
-===== Physical ​Attribute Specification =====+===== Attribute Specification =====
 This is actually the partial output of the [[:​hekate:​hekate_process#​conceptual design]] 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. 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 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.+It is also a point, where the formalized [[:​hekate:​attributes|attribute specification]] can be shared with other systems, tools and approaches.
  
-FIXME +  ​* Input: previous ard design, the hekate_case_NAME:​hekate_case_NAME-ard.hml file prepared with VARDA
-  * now possible only in hqed +
-  * provide xslt for wiki export (WTF!) +
- +
- +
-  ​* Input: previous ard design+
   * Files: ​   * Files: ​
-    * hekate_case_NAME:​hekate_case_NAME-atts.hml+    * //hekate_case_NAME:​hekate_case_NAME-att.hml//
   * Output: physical att specs in HML   * Output: physical att specs in HML
   * Remarks: ​   * Remarks: ​
Line 142: Line 148:
      * this should be compatible with the attributive logic concepts and definitions.      * this should be compatible with the attributive logic concepts and definitions.
  
-===== Structuralization ​=====+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]] Using a partial output of the [[:​hekate:​hekate_process#​conceptual design]]
-that is only the apropriate ​[[hekate markup language|ARDML]] dependencies.+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. In this stage a fully or semi automated generation of the XTT table schemas (rule prototypes) is performed.
Line 151: Line 175:
 The inference structure (table-to-table links) is also built which serve as a guideline for future XTT processing order. The inference structure (table-to-table links) is also built which serve as a guideline for future XTT processing order.
  
-The algorithm is given in the //ECAI submission// FIXME.+The //output// of this stages is the XTT schemes structure with the use of the HML.
  
-The //output// of this stages is the XTT schemes structure [[:​hekate:​hekate_process#​encoding|encoded]] with the use of the [[XTTML]]. +  ​* Input: previous ard design in hml, //​hekate_case_NAME:​hekate_case_NAME-att.hml//​
- +
-  ​* Input: previous ard design in hml+
   * Files: ​   * Files: ​
-    * hekate_case_NAME:​hekate_case_NAME-prot.hml+    * //hekate_case_NAME:​hekate_case_NAME-prt.hml// 
 +    * //​hekate_case_NAME:​hekate_case_NAME-prt.{png,​dot,​pdf}// ​
   * Output: xtt tabs prototypes   * Output: xtt tabs prototypes
   * Remarks: ​   * 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 ===== ===== Logical design =====
 In this stage the actual design of the [[XTT]] tables is put forward. In this stage the actual design of the [[XTT]] tables is put forward.
Line 168: Line 196:
   * Input: xtt prototype   * Input: xtt prototype
   * Files: ​   * Files: ​
-    * hekate_case_NAME:​hekate_case_NAME-xtt.hml +    * //hekate_case_NAME:​hekate_case_NAME-xtt.hml// 
-    * hekate_case_NAME:​hekate_case_NAME-rt.pl +    * //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-cb.pl (callbacks)+    * //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:   * Output:
     * The //output// of this stages is the full XTT structure [[:​hekate:​hekate_process#​encoding|encoded]] with the use of the [[HML]].     * The //output// of this stages is the full XTT structure [[:​hekate:​hekate_process#​encoding|encoded]] with the use of the [[HML]].
   * Remarks: ​   * Remarks: ​
-    * compare xtt proto generation by varda and hqed! +    * while making screenshots try to minimize their size (in terms of unused screen space), maximize readability ​
-      * //__maybe it should be moved to structuralization?​__//​ --- //​[[kinio4444@gmail.com|Krzysztof Kaczor]] 2009/07/14 19:39//+
     * where callbacks are written?     * where callbacks are written?
  
-===== On-Line ​Analysis =====+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: 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: Show functions of:
-  * HQEd +  * HQEd (quality checks, e.g. domains) 
-  * HalVA+  * HalVA (verification)
  
-  * Input: full xtt design+  * Input: full xtt design, //​hekate_case_NAME:​hekate_case_NAME-xtt.hml//​
   * Files: ​   * Files: ​
-    * hekate_case_NAME:​hekate_case_NAME-halva1-9.hml (differnet cases) ​FIXME+    * //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?   * Output: reports?
   * Remarks: ​   * Remarks: ​
- 
 ===== Physical Design ===== ===== Physical Design =====
 The executable design generation. The executable design generation.
Line 198: Line 230:
  
  
-  * Input: full xtt design+  * Input: full xtt design, //​hekate_case_NAME:​hekate_case_NAME-rt.pl//​
   * Files: ​   * Files: ​
-    * hekate_case_NAME:hekate_case_NAME-rt.pl FIXME +    * FIXME, at least basic input callbacks 
-  * Output: ​reports?+  * To launch<​code>​gox(<​state>,​ [<​tables>​],​ <​inference process>​).</​code>​ e.g. <​code>​gox(init,​ ['​Table2',​ '​Table3'​],​ ddi).</​code>​ 
 +  * 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: <​code>​ traj_id(ID),​io_export_trajectory('​file.txt',​ ID).</​code>​
   * Remarks: FIXME   * Remarks: FIXME
     * different inference modes?     * 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.
  
  
Line 221: Line 268:
   * LLK: Drools   * LLK: Drools
  
-====== Integration ====== +==== Encoding ====
-The stages are integrated with: +
-  * knowledge encodings +
-  * transformations +
-  * other? +
- +
-FIXME +
-This needs filling! +
- +
-===== Encoding ​=====+
 Currently XML encodings to be used: Currently XML encodings to be used:
   * ATTML   * ATTML
Line 237: Line 275:
 The are now integrated into //HML// the [[Hekate Markup Language]]. The are now integrated into //HML// the [[Hekate Markup Language]].
  
-===== Knowledge Markups ​=====+==== Knowledge Markups ====
 Aspects: Aspects:
   * ATTML <-> RDF   * ATTML <-> RDF
Line 246: Line 284:
   * ontologies <-> ARDML   * ontologies <-> ARDML
  
-===== Transformations ===== 
 FIXME FIXME
 HatHoR 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 ====== ====== Tools ======
-Current tools: +Current tools, see [[:hekate:​HaDEs]].
-  * VARDA +
-  * HJEd +
-  * HQEd +
-  * HeaRT +
-  * HaThoR+
  
  
 ====== Case Template ====== ====== Case Template ======
- +See [[:​hekates:​cases:​hekate_case_skel:​start|skeleton case]]
-<​code>​ +
-====== 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 ===== +
- +
-</​code>​+
hekate/hekate_process.1247596656.txt.gz · Last modified: 2019/06/27 16:00 (external edit)
www.chimeric.de Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0