Differences

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

Link to this comparison view

hekate:hekate_concepts [2007/11/26 14:27]
gjn created
hekate:hekate_concepts [2019/06/27 15:49]
Line 1: Line 1:
-====== Introduction ====== 
-//HeKatE// is about researching and effectively applying selected //knowledge engineering//​ methods in practical //software engineering//​. 
- 
-We aim at improving: 
-  * design methods and //​process//,​ 
-  * automated implementation,​ 
-  * automated, possibly formal analysis and verification. 
- 
-We aim at providing methods and tools in the areas of: 
-  * knowledge representation,​ for the visual design, 
-  * knowledge translation,​ for the automated implementation,​ 
-  * knowledge analysis, for the formal verification. 
- 
-====== Motivation ====== 
- 
-For an extended version see 
- 
-Knowledge-based systems (KBS) are an important class of intelligent systems originating from the field of Artificial Intelligence. 
-In AI, //rules// are probably the most popular choice for building knowledge-based systems, that is the so-called rule-based expert systems. ​ 
-Building real-life KBS is a complex task. 
-Since their architecture is fundamentally different from classic software, typical Software Engineering approaches cannot be applied efficiently. 
-Software Engineering (SE) does not contribute much concepts in Knowledge Engineering. 
-However, it does provide some important tools and techniques for it.  
-On the other hand some important Knowledge Engineering conceptual achievements and methodologies can be successfully transferred and applied in the domain of Software Engineering. 
- 
-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. 
- 
-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 level at which KE should operate is often referred to as //the knowledge level//. 
- 
-Historically,​ there has always been a strong feedback between SE and computer programming tools. 
-At the same time, these tools have been strongly determined by the actual architecture of computers themselves. 
-For a number of years there has been a clear trend for the software engineering to become as implementation-independent as possible. 
-It could be said, that these days software engineering becomes more knowledge-based,​ while knowledge engineering is more about software engineering. 
-This opens multiple opportunities for both approaches to improve and benefit. 
- 
-The Software Engineering is derived as a set of paradigms, procedures, specifications and tools from pure programming. ​ 
-It is heavily tainted with the way how programs work which is the sequential approach, based on the Turing Machine concept. 
-Historically,​ when the modelled systems became more complex, SE became more and more declarative,​ in order to model the system in a more comprehensive way. 
-It made the design stage independent of programming languages which resulted in number of approaches; the best example is the MDA approach. 
-So, while programming itself remains mostly sequential, designing becomes more declarative. 
- 
-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. ​ 
-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. 
-  * 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. 
- 
- 
-====== Concepts ====== 
- 
-Some of the main concepts behind HeKatE are: 
-  * providing an integrated design and implementation process, thus 
-  * closing the semantic gap, and 
-  * automating the implementation,​ providing 
-  * an executable solution, that includes 
-  * an on-line formal analysis of the design, during the design. 
- 
-HeKatE uses methods and tools in the areas of: 
-  * knowledge representation,​ for the visual design, 
-  * knowledge translation,​ for the automated implementation,​ 
-  * 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. 
-The logic is then encoded with use of a declarative representation. 
-The logic core would be then embedded into a business application,​ or embedded control system. 
-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. 
- 
-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 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. 
-The knowledge base is specified and encoded in the Prolog language. 
-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). 
- 
- 
-====== Methods ====== 
-Currently, the development is focused on the: 
-  * conceptual design method, codename //ARD+// see 
-  * logical design, codename //XTT+// see, also in an extended form as //GREP// see 
-  * knowledge markup, early stage, see 
-  * knowledge translation,​ early stage, see 
- 
-===== ARD+ ===== 
- 
-===== XTT+ ===== 
- 
-===== Markup ===== 
- 
-===== Translation ===== 
- 
-====== Applications ====== 
-The project aims at applications in the fields of: 
-  * Business Logic Applications (ie. [[hekatedev:​business_rules]]) 
-  * General purpose applications 
-  * Control systems -- [[:​mindstorms]] and [[:hexor]] robot control 
-  * Expert Systems 
-  * Databases 
- 
-====== Tools ====== 
-Current developemnt tools include: 
-  * VARDA, an ARD+ design and visualzation tool, see 
-  * HQed, an XTT+ editor, see 
- 
-====== Development ====== 
-HeKatE is currently under heavy development. 
-Members of the team use [[hekatedev:​hekate_development|the development part]]. 
-Stay tuned! 
  
hekate/hekate_concepts.txt · Last modified: 2019/06/27 15:49 (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