Różnice między wybraną wersją a wersją aktualną.
| Both sides previous revision Poprzednia wersja Nowa wersja | Poprzednia wersja | ||
|
pl:miw:2009:present:ardplus_present [2009/05/12 19:28] jsi08 |
pl:miw:2009:present:ardplus_present [2019/06/27 15:50] (aktualna) |
||
|---|---|---|---|
| Linia 226: | Linia 226: | ||
| * defining dependencies between the property and other existing properties at the //most detailed// diagram level, or | * defining dependencies between the property and other existing properties at the //most detailed// diagram level, or | ||
| * adjusting appropriate past split transformations gradually (at previous diagram levels) to take this new property into consideration. | * adjusting appropriate past split transformations gradually (at previous diagram levels) to take this new property into consideration. | ||
| - | * In the first case the dependencies are defined for the most detailed diagram level only; since there is a hierarchical design process (see Sec. [[ardplus#Hierarchical_Model|Hierarchical Model]]), these changes are taken into consideration at previous levels automatically. | + | * In the first case the dependencies are defined for the most detailed diagram level only; since there is a hierarchical design process (see Sec. [[#Hierarchical_Model|Hierarchical Model]]), these changes are taken into consideration at previous levels automatically. |
| * The second case implies that the designer updates appropriate past splits in a gradual refinement process; stopping this process at more general level than the most detailed one, generates appropriate splits in all more detailed levels automatically. | * The second case implies that the designer updates appropriate past splits in a gradual refinement process; stopping this process at more general level than the most detailed one, generates appropriate splits in all more detailed levels automatically. | ||
| Linia 278: | Linia 278: | ||
| {{ hekate:ard-split-dep1.png?353x136 }} | {{ hekate:ard-split-dep1.png?353x136 }} | ||
| - | * the top diagram shows a situation before, and the bottom one after, the //split transformation// | + | * the top diagram shows a situation before, and the bottom one after, the //split transformation// |
| - | * this //split// allows to refine new properties and define functional dependencies among them | + | * this //split// allows to refine new properties and define functional dependencies among them |
| - | * a property described by attributes: ''Date'', ''Hour'', ''season'', ''operation'', is split into two properties described by ''Date'', ''Hour'', and ''season'', ''operation'' appropriately | + | |
| - | * there is a functional dependency defined such as ''season'' and ''operation'' depend on ''Date'' and ''Hour'' | + | ===== Semantics ===== |
| + | |||
| + | * a property described by attributes: ''Date'', ''Hour'', ''season'', ''operation'', is split into two properties described by ''Date'', ''Hour'', and ''season'', ''operation'' appropriately | ||
| + | * there is a functional dependency defined such as ''season'' and ''operation'' depend on ''Date'' and ''Hour'' | ||
| ===== Semantics ===== | ===== Semantics ===== | ||
| Linia 290: | Linia 293: | ||
| {{ hekate:ard-split-indep1.png?306x154 }} | {{ hekate:ard-split-indep1.png?306x154 }} | ||
| - | Properties described by ''season'' and ''operation'' are functionally independent. | + | * properties described by ''season'' and ''operation'' are functionally independent |
| + | |||
| + | ===== Semantics ===== | ||
| The ARD+ design process based on transformations leads to a diagram representing properties described only by ''physical attributes''. | The ARD+ design process based on transformations leads to a diagram representing properties described only by ''physical attributes''. | ||
| Linia 297: | Linia 302: | ||
| {{ hekate:ard-therm-01.png?420x151 }} | {{ hekate:ard-therm-01.png?420x151 }} | ||
| - | All properties of the designed system are identified. | + | * all properties of the designed system are identified |
| - | Each of them is described by single //physical attribute//. | + | * each of them is described by single //physical attribute// |
| - | All functional dependencies are defined as well. | + | * all functional dependencies are defined as well |
| - | Each transformation creates a more detailed diagram, introducing new attributes (//finalization//) or defining functional dependencies (//split//). | + | ===== Semantics ===== |
| - | These more detailed diagrams are called //levels of detail// or just //diagram levels//. | + | |
| - | In the above examples, transitions between two subsequent levels are presented. | + | |
| - | A complete model consists of all the levels capturing knowledge about all //splits// and //finalizations//. | + | |
| - | ==== Hierarchical Model ==== | + | * each transformation creates a more detailed diagram, introducing new attributes (//finalization//) or defining functional dependencies (//split//) |
| + | * these more detailed diagrams are called //levels of detail// or just //diagram levels// | ||
| + | * in the above examples, transitions between two subsequent levels are presented | ||
| + | * a complete model consists of all the levels capturing knowledge about all //splits// and //finalizations// | ||
| - | During the design process, upon splitting and finalization, the ARD+ model grows, becoming more and more specific. | + | ===== Hierarchical Model ===== |
| - | This process constitutes the //hierarchical model//. | + | |
| - | Consecutive levels make a hierarchy of more and more detailed diagrams describing the designed system. | + | |
| - | The purposes of having the hierarchical model are: | + | * during the design process, upon splitting and finalization, the ARD+ model grows, becoming more and more specific; this process constitutes the //hierarchical model// |
| - | * gradual refinement of a designed system, and particularly, | + | * consecutive levels make a hierarchy of more and more detailed diagrams describing the designed system |
| - | * identification where given properties come from, | + | * the purposes of having the hierarchical model are: |
| - | * ability to get back to previous diagram levels for refactoring purposes, | + | * gradual refinement of a designed system, and particularly, |
| - | * big picture of the designed system. | + | * identification where given properties come from, |
| + | * ability to get back to previous diagram levels for refactoring purposes, | ||
| + | * big picture of the designed system. | ||
| - | The implementation of such hierarchical model is provided through storing the lowest available, most detailed diagram level, and, additionally, information needed to recreate all of the higher levels, so called //Transformation Process History//, TPH for short (see Def. [[#TPH|TPH]]). | + | ===== Hierarchical Model ===== |
| - | The TPH captures information about changes made to properties at consecutive diagram levels. | + | * the implementation of such hierarchical model is provided through storing the lowest available, most detailed diagram level, and, additionally, information needed to recreate all of the higher levels, so called //Transformation Process History//, TPH for short (see Def. [[#TPH|TPH]]) |
| - | These changes are carried out through the transformations: split or finalization. | + | * the TPH captures information about changes made to properties at consecutive diagram levels; these changes are carried out through the transformations: split or finalization |
| - | The TPH forms a tree structure then, denoting what particular properties is split into or what attributes a particular property attribute is finalized into, according to Def. [[#TPH|TPH]]. | + | * the TPH forms a tree structure then, denoting what particular properties is split into or what attributes a particular property attribute is finalized into, according to Def. [[#TPH|TPH]] |
| + | |||
| + | ===== Hierarchical Model ===== | ||
| An example TPH for the transformation is given in Figure: | An example TPH for the transformation is given in Figure: | ||
| {{ :hekate:final-tph.png }} | {{ :hekate:final-tph.png }} | ||
| - | It indicates that a property described by an attribute ''Time'' is refined into a property described by attributes: ''Date'', ''Hour'', ''season'', ''operation''. | + | * it indicates that a property described by an attribute ''Time'' is refined into a property described by attributes: ''Date'', ''Hour'', ''season'', ''operation'' |
| + | |||
| + | ===== Hierarchical Model ===== | ||
| Another TPH example for the split transformation is given in Figure: | Another TPH example for the split transformation is given in Figure: | ||
| {{ :hekate:split-tph.png }} | {{ :hekate:split-tph.png }} | ||
| - | It indicates that a property described by attributes: ''Date'', ''Hour'', ''season'', ''operation'' is refined into two properties described by: ''Date'', ''Hour'' and ''season'', ''operation'' attributes respectively. | + | * it indicates that a property described by attributes: ''Date'', ''Hour'', ''season'', ''operation'' is refined into two properties described by: ''Date'', ''Hour'' and ''season'', ''operation'' attributes respectively |
| + | ===== Hierarchical Model ===== | ||
| - | Having a complete TPH and the most detailed level (namely ARD+), which constitute the //DPD// (according to Def. [[#DPD|DPD]]) it is possible to automatically recreate any, more general, level. | + | * having a complete TPH and the most detailed level (namely ARD+), which constitute the //DPD// (according to Def. [[#Syntax: DPD|DPD]]) it is possible to automatically recreate any, more general, level |
| ===== Rule Prototyping Algorithm ===== | ===== Rule Prototyping Algorithm ===== | ||
| - | The goal of the algorithm is to automatically build prototypes for rules from the ARD+ design ([[hekate:bib:hekate_bibliography#gjn2008aaia|gjn2008aaia]]). | + | * the goal of the algorithm is to automatically build prototypes for rules from the ARD+ design ([[hekate:bib:hekate_bibliography#gjn2008aaia|gjn2008aaia]]). |
| - | The targeted rule base is structured, grouping rule sets in decision tables with explicit inference control. | + | * the targeted rule base is structured, grouping rule sets in decision tables with explicit inference control; it is especially suitable for the XTT rule representation |
| - | It is especially suitable for the XTT rule representation. | + | * this approach is more generic, and can be applied to any forward chaining rules |
| - | Moreover, this approach is more generic, and can be applied to any forward chaining rules. | + | |
| - | The input of the algorithm is the most detailed ARD+ diagram, that has all of the physical attributes identified | + | ===== Rule Prototyping Algorithm ===== |
| - | (in fact, the algorithm can also be applied to higher level diagrams, generating rules for some parts of the system being designed). | + | |
| - | The output is a set of //rule prototypes// in a very general format (''atts'' stands for attributes): | + | * the input of the algorithm is the most detailed ARD+ diagram, that has all of the physical attributes identified (in fact, the algorithm can also be applied to higher level diagrams, generating rules for some parts of the system being designed) |
| + | * the output is a set of //rule prototypes// in a very general format (''atts'' stands for attributes): | ||
| <code> | <code> | ||
| Linia 350: | Linia 360: | ||
| </code> | </code> | ||
| - | The algorithm is //reversible//, that is having a set of rules in the above format, it is possible to recreate the most detailed level of the ARD+ diagram. | + | * the algorithm is //reversible//, that is having a set of rules in the above format, it is possible to recreate the most detailed level of the ARD+ diagram |
| + | |||
| + | ===== Rule Prototyping Algorithm ===== | ||
| In order to formulate the algorithm some basic subgraphs in the ARD+ structure are considered. | In order to formulate the algorithm some basic subgraphs in the ARD+ structure are considered. | ||
| Linia 357: | Linia 369: | ||
| {{ hekate:ard-case0.png?100x112 }} \\ | {{ hekate:ard-case0.png?100x112 }} \\ | ||
| {{ hekate:ard-case1.png?100x112 }} | {{ hekate:ard-case1.png?100x112 }} | ||
| + | |||
| + | ===== Rule Prototyping Algorithm ===== | ||
| Now, considering the ARD+ semantics (functional dependencies among properties), the corresponding rule prototypes are as follows: | Now, considering the ARD+ semantics (functional dependencies among properties), the corresponding rule prototypes are as follows: | ||
| Linia 367: | Linia 381: | ||
| rule: a, b, c | d | rule: a, b, c | d | ||
| + | |||
| + | ===== Rule Prototyping Algorithm ===== | ||
| In a general case a subgraph in Figure: | In a general case a subgraph in Figure: | ||
| Linia 374: | Linia 390: | ||
| is considered. | is considered. | ||
| - | Such a subgraph corresponds to the following rule prototype: | + | * such a subgraph corresponds to the following rule prototype: |
| <code> | <code> | ||
| rule: alpha, beta, gamma, aa | bb | rule: alpha, beta, gamma, aa | bb | ||
| rule: aa | xx, yy, zz | rule: aa | xx, yy, zz | ||
| </code> | </code> | ||
| + | |||
| + | ===== Rule Prototyping Algorithm ===== | ||
| Analyzing these cases a general prototyping algorithm has been formulated. | Analyzing these cases a general prototyping algorithm has been formulated. | ||
| Linia 387: | Linia 405: | ||
| * find all properties ''F'', that ''T'' depends on: \\ let ''F<sub>T</sub> = [F<sub>Ti</sub>: D(F<sub>Ti</sub>,T), F<sub>Ti</sub> ≠ F]'', | * find all properties ''F'', that ''T'' depends on: \\ let ''F<sub>T</sub> = [F<sub>Ti</sub>: D(F<sub>Ti</sub>,T), F<sub>Ti</sub> ≠ F]'', | ||
| * find all properties which depend on ''F'' and ''F'' alone:\\ let ''T<sub>F</sub>=[T<sub>Fi</sub>: D(F,T<sub>Fi</sub>), T<sub>Fi</sub> ≠ T, ¬∃ T<sub>Fi</sub>: (D(X,T<sub>Fi</sub>), X ≠ F )]'' | * find all properties which depend on ''F'' and ''F'' alone:\\ let ''T<sub>F</sub>=[T<sub>Fi</sub>: D(F,T<sub>Fi</sub>), T<sub>Fi</sub> ≠ T, ¬∃ T<sub>Fi</sub>: (D(X,T<sub>Fi</sub>), X ≠ F )]'' | ||
| + | |||
| + | ===== Rule Prototyping Algorithm ===== | ||
| + | |||
| * if ''F<sub>T</sub> ≠ ∅, T<sub>F</sub> ≠ ∅'' then generate rule prototypes: | * if ''F<sub>T</sub> ≠ ∅, T<sub>F</sub> ≠ ∅'' then generate rule prototypes: | ||
| <code> | <code> | ||
| Linia 410: | Linia 431: | ||
| * if there are any dependencies left goto step 1. | * if there are any dependencies left goto step 1. | ||
| - | Rule prototypes generated by the above algorithm can be further optimized. | + | ===== Rule Prototyping Algorithm ===== |
| - | If there are rules with the same condition attributes they can be merged. | + | |
| - | Similarly, if there are rules with the same decision attributes they can be merged as well. | + | |
| - | For instance, rules like: | + | |
| - | <code> | + | |
| - | rule: a, b | x ; rule: a, b | y | + | |
| - | </code> | + | |
| - | can be merged into a single rule: ''rule: a, b | x, y'' | + | |
| - | The practical support form the ARD+ design method, including logical modelling, visualization, and the prototyping algorithm has been implemented in the VARDA. | + | * rule prototypes generated by the above algorithm can be further optimized |
| + | * if there are rules with the same condition attributes they can be merged; if there are rules with the same decision attributes they can be merged | ||
| + | * for instance, rules like: ''rule: a, b | x ; rule: a, b | y'' can be merged into a single rule: ''rule: a, b | x, y'' | ||
| + | * the practical support form the ARD+ design method, including logical modelling, visualization, and the prototyping algorithm has been implemented in the VARDA | ||
| ===== Design Tool Prototype ===== | ===== Design Tool Prototype ===== | ||
| ===== SPOOL ===== | ===== SPOOL ===== | ||
