This shows you the differences between two versions of the page.
| Next revision | Previous revision | ||
|
hekate:hekate_concepts [2007/11/26 14:27] gjn created |
hekate:hekate_concepts [2019/06/27 15:49] (current) |
||
|---|---|---|---|
| Line 14: | Line 14: | ||
| ====== Motivation ====== | ====== Motivation ====== | ||
| - | For an extended version see | + | For an extended version see [[:hekate:bib:hekate_bibliography#gjn2007flairs-hekate]] |
| Knowledge-based systems (KBS) are an important class of intelligent systems originating from the field of Artificial Intelligence. | Knowledge-based systems (KBS) are an important class of intelligent systems originating from the field of Artificial Intelligence. | ||
| Line 26: | Line 26: | ||
| What makes KBS distinctive is the separation of knowledge storage (the knowledge base) from the knowledge processing facilities. | What makes KBS distinctive is the separation of knowledge storage (the knowledge base) from the knowledge processing facilities. | ||
| In order to store knowledge, KBS use various knowledge representation methods, which are //declarative// in nature. | In order to store knowledge, KBS use various knowledge representation methods, which are //declarative// in nature. | ||
| - | |||
| The knowledge engineering process, should //capture// the expert knowledge and //represent// it in a way that is suitable for processing. | The knowledge engineering process, should //capture// the expert knowledge and //represent// it in a way that is suitable for processing. | ||
| The actual structure of a KBS does not need to be system specific it should not ,,mimic'' or model the structure of the real-world problem. | The actual structure of a KBS does not need to be system specific it should not ,,mimic'' or model the structure of the real-world problem. | ||
| Line 44: | Line 43: | ||
| It could be summarized, that constant sources of errors in software engineering are: | It could be summarized, that constant sources of errors in software engineering are: | ||
| - | * The //Semantic Gap// between existing design methods, which are becoming more and more declarative, and implementation tools that remain sequential/procedural. | + | * The //Semantic Gap// between existing design methods, which are becoming more and more declarative, and implementation tools that remain sequential/procedural. |
| - | This issue results in the problems mentioned below. | + | * //Evaluation problems// due to large differences in semantics of design methods and lack of //formal// knowledge model. They appear at many stages of the SE process, including not just the correctness of the final software, but also validity of the design model, and the transformation from the model to the implementation. |
| - | * //Evaluation problems// due to large differences in semantics of design methods and lack of //formal// knowledge model. | + | |
| - | They appear at many stages of the SE process, including not just the correctness of the final software, but also validity of the design model, and the transformation from the model to the implementation. | + | |
| * The so-called //Analysis Specification Gap//, which is the difficulty with proper formulation of requirements, and transformation of the requirements into an effective design, and then implementation. | * The so-called //Analysis Specification Gap//, which is the difficulty with proper formulation of requirements, and transformation of the requirements into an effective design, and then implementation. | ||
| * The so-called //Separation Problem//, which is the lack of separation between Core Software Logic, software interfaces and presentation layers. | * The so-called //Separation Problem//, which is the lack of separation between Core Software Logic, software interfaces and presentation layers. | ||
| Line 65: | Line 62: | ||
| * knowledge translation, for the automated implementation, | * knowledge translation, for the automated implementation, | ||
| * knowledge analysis, for the formal verification. | * knowledge analysis, for the formal verification. | ||
| - | |||
| A principal idea in this approach is to model, represent, and store the logic behind the software (sometimes referred to as business logic) using advanced knowledge representation methods taken from KE. | A principal idea in this approach is to model, represent, and store the logic behind the software (sometimes referred to as business logic) using advanced knowledge representation methods taken from KE. | ||
| Line 72: | Line 68: | ||
| The remaining parts of the business or control applications, such as interfaces, or presentation aspects, would be developed with a classic object-oriented or procedural programming languages such as Java or C. | The remaining parts of the business or control applications, such as interfaces, or presentation aspects, would be developed with a classic object-oriented or procedural programming languages such as Java or C. | ||
| The HeKatE project should eventually provide a coherent runtime environment for running the combined Prolog and Java/C code. | The HeKatE project should eventually provide a coherent runtime environment for running the combined Prolog and Java/C code. | ||
| + | |||
| + | {{ :hekate:hekate-design-big.png |Figure: The HeKatE architecture}} | ||
| From the implementation point of view HeKatE is based on the idea of multiparadigm programming. | From the implementation point of view HeKatE is based on the idea of multiparadigm programming. | ||
| The target application combines the logic core implemented in Prolog, with object-oriented interfaces in Java, or procedural in ANSI C. | The target application combines the logic core implemented in Prolog, with object-oriented interfaces in Java, or procedural in ANSI C. | ||
| - | |||
| The Semantic Gap problem is addressed by providing declarative design methods for the business logic. | The Semantic Gap problem is addressed by providing declarative design methods for the business logic. | ||
| There is no translation from the formal, declarative design into the implementation language. | There is no translation from the formal, declarative design into the implementation language. | ||
| Line 81: | Line 78: | ||
| The logical design which specifies the knowledge base becomes an application executable by a runtime environment, combining an inference engine and classic language runtime (e.g. a JVM). | The logical design which specifies the knowledge base becomes an application executable by a runtime environment, combining an inference engine and classic language runtime (e.g. a JVM). | ||
| + | {{ :hekate:hekate-hybrid-big.png |Figure: The concept of the HeKatE application}} | ||
| ====== Methods ====== | ====== Methods ====== | ||
| Currently, the development is focused on the: | Currently, the development is focused on the: | ||
| - | * conceptual design method, codename //ARD+// see | + | * conceptual design method, codename //ARD+// see [[:hekate:bib:hekate_bibliography#gjn2008flairs-ardformal]] |
| - | * logical design, codename //XTT+// see, also in an extended form as //GREP// see | + | * logical design, codename //XTT+//, also in an extended form as //GREP// see [[:hekate:bib:hekate_bibliography#]], and [[:hekate:bib:hekate_bibliography#ali2008flairs]] |
| - | * knowledge markup, early stage, see | + | * knowledge markup, early stage, see [[:hekate:bib:hekate_bibliography#gjn2007cms-knowtrans]], |
| - | * knowledge translation, early stage, see | + | * knowledge translation, early stage, see [[:hekate:bib:hekate_bibliography#gjn2007cms-knowtrans]]. |
| + | |||
| + | |||
| ===== ARD+ ===== | ===== ARD+ ===== | ||
| + | For a more complete description of ARD+ see | ||
| + | * [[:hekate:bib:hekate_bibliography#gjn2008flairs-ardformal|formal description]]. | ||
| + | * [[:hekate:bib:hekate_bibliography#gjn2008flairs-ardprolog|Prolog tool]]. | ||
| + | * [[:hekate:bib:hekate_bibliography#gjn2008flairs-userv|UServ example]]. | ||
| + | |||
| + | The ARD (Attribute Relationships Diagrams) method aims at capturing relations between //attributes// in terms of //Attributive Logic//. | ||
| + | //Attributes// denote certain system //property//. | ||
| + | A //property// is described by one or more attributes. | ||
| + | ARD captures //functional dependencies// among these //properties//. | ||
| + | A simple property is a property described by a single //attribute//, while a complex property is described by multiple //attributes//. | ||
| + | It is indicated that particular system property depends functionally on other properties. | ||
| + | Such dependencies form a directed graph with nodes being properties. | ||
| + | |||
| + | There are two kinds of attributes adapted by ARD: //Conceptual Attributes// and //Physical Attributes//. | ||
| + | A //conceptual attribute// is an attribute describing some general, abstract aspect of the system to be specified and refined. | ||
| + | Conceptual attribute names are capitalized, e.g.: WaterLevel. | ||
| + | Conceptual attributes are being //finalized// during the design process, into, possibly multiple, physical attributes. | ||
| + | A //physical attribute// is an attribute describing a well-defined, atomic aspect of the system. | ||
| + | Names of physical attributes are not capitalized, e.g. theWaterLevelInTank1. | ||
| + | Physical attributes cannot be finalized, they are present in the final rules capturing knowledge about the system.\\ | ||
| + | |||
| + | {{:hekate:ard-finalization-ex1.png?500|Figure: General Finalization of an Attribute}} {{:hekate:ard-finalization-ex2.png?500|Figure: Simple Finalization of an Attribute}} | ||
| + | |||
| + | There are two transformations allowed during the ARD+ design. | ||
| + | These are: //finalization// and //split//. | ||
| + | //Finalization// transforms a simple property described by a conceptual attribute into a property described by one or more conceptual or physical attributes. | ||
| + | It introduces a more specific knowledge about the given property. | ||
| + | //Split// transforms a complex property into a number of properties and defines functional dependencies among them. | ||
| + | |||
| + | {{:hekate:ard-split-dep1.png?500|Figure: Dependent Split}} {{:hekate:ard-split-indep1.png?500|Figure: Independent Split}} | ||
| + | |||
| + | During the design process, upon splitting and finalization, the ARD model grows. | ||
| + | This growth is expressed by consecutive diagram levels, making the design more and more specific. | ||
| + | This constitutes the //hierarchical model//. | ||
| + | Consecutive levels make a hierarchy of more and more detailed diagrams describing the designed system. | ||
| + | The implementation of such hierarchical model is provided through storing the lowest available, most detailed diagram level at any time, and additional information needed to recreate all of the higher levels, the so-called //Transformation Process History// (TPH). | ||
| + | It captures information about changes made to properties at consecutive diagram levels. | ||
| + | |||
| + | An example of a complete ARD+ design (the lowest level) is shown below. | ||
| + | |||
| + | {{:hekate:ard-therm-01.png|Figure: ARD design example}} | ||
| + | |||
| + | Based on the ARD, rule prototypes, complying with XTT, can be automatically generated as it is showed below. | ||
| + | |||
| + | {{:hekate:thermostat-varda-xtt.png|:hekate:thermostat-varda-xtt.png}} | ||
| ===== XTT+ ===== | ===== XTT+ ===== | ||
| + | The //XTT// (//EXtended Tabular Trees//) knowledge representation, has been proposed in order to solve some common design, analysis and implementation problems present in RBS. | ||
| + | In this method three important representation levels has been addressed: | ||
| + | * //visual// -- the model is represented by a hierarchical structure of linked extended decision tables, | ||
| + | * //logical// -- tables correspond to sequences of extended decision rules, | ||
| + | * //implementation// -- rules are processed using a Prolog representation. | ||
| + | |||
| + | On the visual level the model is composed of extended decision tables. | ||
| + | A single table is presented below. | ||
| + | |||
| + | {{:hekate:xttp-table.png|Figure: Single XTT Table}} | ||
| + | |||
| + | The table represents a set of rules, having the same attributes. | ||
| + | XTT rule includes two main extensions compared to classic RBS: | ||
| + | 1) non-atomic attribute values, used both in conditions and decisions, | ||
| + | 2) non-monotonic reasoning support, with dynamic assert/retract operations in decision part. | ||
| + | Every table row correspond to a decision rule. | ||
| + | Rows are are interpreted from top row to the bottom one. | ||
| + | Tables can be linked in a graph-like structure. | ||
| + | A link is followed when rule (row) is fired. | ||
| + | |||
| + | The structure below, corresponds to the ARD+ design presented above. | ||
| + | {{:hekate:xtt-structure-therm.png|Figure: An Example of an XTT structure}} | ||
| + | |||
| + | On the logical level a table corresponds to a number of rules, processed in a sequence. | ||
| + | If a rule is fired and it has a link, the inference engine processes the rule in another table. | ||
| + | The rule is based on an //attributive language//. | ||
| + | It corresponds to a //Horn// clause: | ||
| + | Rules are interpreted using a unified knowledge and fact base, that can be dynamically modified during the inference process using Prolog-like assert/retract operators in rule decision part. | ||
| + | Rules are implemented using Prolog-based representation, | ||
| + | using terms, which is a flexible solution | ||
| + | However, it requires a dedicated meta-interpreter. | ||
| + | |||
| + | Currently the base XTT is being extended on the syntax level to provide a better expressiveness towards XTT+, or to be applied for more general cases into GREP, see [[:hekate:bib:hekate_bibliography#gjn2007inap]] | ||
| + | |||
| + | Another area of development includes formalism extensions, such as temporal and fuzzy, see [[:hekate:bib:hekate_bibliography#ali2008flairs]] | ||
| + | |||
| ===== Markup ===== | ===== Markup ===== | ||
| + | [[Hekate Markup Language]] considers the following sublanguages: | ||
| + | * ATTML (Attribute ML), for attribute only markup | ||
| + | * ARDML (ARD ML) for conceptual design markup | ||
| + | * XTTML (XTT ML) for logical design markup | ||
| + | The aim at: | ||
| + | * knowledge interchange | ||
| + | * RIF compliance | ||
| + | * R2ML interoperability (at XTT level) | ||
| + | |||
| + | See [[:hekate:bib:hekate_bibliography#gjn2007cms-knowtrans]] for some general ideas. | ||
| + | More details at: [[Hekate Markup Language]]. | ||
| + | |||
| ===== Translation ===== | ===== Translation ===== | ||
| + | There are the following scenarios considered regarding knowledge transformation for: | ||
| + | * interoperability purposes, | ||
| + | * execution purposes, | ||
| + | * validation and verification purposes, | ||
| + | * visualization purposes. | ||
| + | See | ||
| + | [[:hekate:bib:hekate_bibliography#gjn2007cms-knowtrans]]. | ||
| + | for some general ideas. | ||
| + | |||
| + | |||
| + | |||
| + | ====== Process ====== | ||
| + | The [[HeKatE process]] is: | ||
| + | * hierarchical, | ||
| + | * integrated, | ||
| + | * multiaspect. | ||
| + | |||
| + | For some ideas see below, more info available at [[HeKatE Process]]. | ||
| + | |||
| + | {{:hekate:new-proc.png|Figure: HeKatE methodology}} | ||
| + | |||
| + | {{:hekate:hlc-beta.png|Figure: HeKatE Process}} | ||
| ====== Applications ====== | ====== Applications ====== | ||
| Line 101: | Line 217: | ||
| * Business Logic Applications (ie. [[hekatedev:business_rules]]) | * Business Logic Applications (ie. [[hekatedev:business_rules]]) | ||
| * General purpose applications | * General purpose applications | ||
| - | * Control systems -- [[:mindstorms]] and [[:hexor]] robot control | + | * Control systems -- [[:mindstorms:start]] and [[misc:hexor]] robot control |
| * Expert Systems | * Expert Systems | ||
| * Databases | * Databases | ||
| + | |||
| + | ===== Cases ===== | ||
| + | There are several benchmark system design cases considered as the HeKatE testbed. | ||
| + | |||
| + | |||
| + | ==== Thermostat ==== | ||
| + | A classic //control system// case form the AI book by M. Negnevitsky, called the //Thermostat// | ||
| + | is currently being modeled, see [[Hekate Case Thermostat]] and [[:hekate:bib:hekate_bibliography#gjn2008flairs-ardprolog]]. | ||
| + | |||
| + | ==== UServ ==== | ||
| + | A classic //business rules// case form the BR Forum Product Derby 2005, | ||
| + | (see [[http://www.businessrulesforum.com/2005_Product_Derby.pdf|The Product Derby PDF]]), | ||
| + | called the //UServ// is currently being modeled. | ||
| + | See [[:hekate:bib:hekate_bibliography#gjn2008flairs-userv]] | ||
| ====== Tools ====== | ====== Tools ====== | ||
| - | Current developemnt tools include: | + | Current development tools include: |
| - | * VARDA, an ARD+ design and visualzation tool, see | + | * VARDA, an ARD+ design and visualization tool, see [[:hekate:bib:hekate_bibliography#gjn2008flairs-ardprolog]] |
| - | * HQed, an XTT+ editor, see | + | * HQed, an XTT+ editor, see [[:hekate:bib:hekate_bibliography#gjn2007cms-destls-accepted]] |
| ====== Development ====== | ====== Development ====== | ||
| Line 114: | Line 244: | ||
| Members of the team use [[hekatedev:hekate_development|the development part]]. | Members of the team use [[hekatedev:hekate_development|the development part]]. | ||
| Stay tuned! | Stay tuned! | ||
| + | |||
