To jest stara wersja strony!
Eliasz Kańtoch Tomasz Michalski
This case analysis is based on hekate process.
The process is involves the following the stages described below.
The aim of the system is to tell greetings based on the time of day and customer's attributes.
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.
*Greeting is a text that consists of salutation and title of the person. *Salutation is one of the following: Good Morning, Good Afternoon, Good Evening, Good Night. *Title of person is based on status of the person. *Status are age,martial status and gender. *Gender – male albo female *Martial status – married i single
In a case where an already designed system is being modeled, some ready rules can be provided. In the H approach these rules should be considered a mean of conceptualization only. These rules are often informal, or semi-formal. In the business rules approach number of rule types are identified, that do not map in a straightforward way to the H logical design.
Rule: 1 if the Hour is 'between 0 and 11' then Greeting is 'Good morning' Rule: 2 if the Hour is 'between 12 and 17' then Greeting is 'Good afternoon' Rule: 3 if the Hour is 'between 18 and 22' then Greeting is 'Good evening' Rule: 4 if the Hour is 'between 23 and 24' then Greeting is 'Good night'
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.
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 encoded with use of the HeKatE Markup Language.
In a general case, the ARD diagram is built using the vocabulary previously identified.
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.
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.
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.
TBC: at this stage it should be possible to import attributes from other formalized sources, e.g. RIF-based systems.
TBC: this should be compatible with the attributive logic concepts and definitions.
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 algorithm is given in the ECAI submission 
.
The output of this stages is the XTT schemes structure encoded with the use of the XTTML.
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.
WIP: The application of the XTT+ a.k.a. GREP extensions should be considered here, with:
Things that seem to be needed, in the final verision, but too complex now:
Things considered to complex for the first implementation are:
The output of this stages is the full XTT structure encoded with the use of the XTTML.
In this stage the logical description of the XTT is used to conduct a formal analysis of selected formal properties such as:
WIP currently only some old experiences form the original XTT are available.
TBC Several aspects, cases, classes, levels should be considered, e.g.:
The executable design generation.
The XTT representation has a clear, well-defined Prolog representation. This representation is fully automatically generated from the XTT design.
WIP currently only some old experiences form the original XTT are available.
TBC Integration of BLOBS, data structures, lists, etc, has to be considered. So is the use and integration of the HOP.
WIP An object-oriented serialization of the XTT is to be provided. It should match UML on the diagram level, and Java on the code level.
WIP Current naive idea is to map
WIP Generate rules for some well-established rule engines, such as Drools.
The stages are integrated with:
This needs filling!
Currently XML encodings to be used:
The are now integrated into HML the Hekate Markup Language.
Aspects:
Current tools:
====== 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 =====
