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 14:57] jsi08 |
pl:miw:2009:present:ardplus_present [2019/06/27 15:50] (aktualna) |
||
|---|---|---|---|
| Linia 18: | Linia 18: | ||
| * the KE process is different from the classic software engineering (SE) process | * the KE process is different from the classic software engineering (SE) process | ||
| * important difference between SE and KE is that the former tries to model how the system works, while the latter tries to capture and represent what is known about the system | * important difference between SE and KE is that the former tries to model how the system works, while the latter tries to capture and represent what is known about the system | ||
| - | * The KE approach assumes that information about how the system works can be inferred automatically from what is known about the system | + | * the KE approach assumes that information about how the system works can be inferred automatically from what is known about the system |
| ===== Introduction ===== | ===== Introduction ===== | ||
| Linia 67: | Linia 67: | ||
| The main concepts behind ARD+ are: | The main concepts behind ARD+ are: | ||
| - | * **attributive logic** based on the use of //attributes// for denoting certain properties in a system (ali-book-springer), [[hekate:bib:hekate_bibliography#ali2007flairs-granular|ali2007flairs-granular)]]. | + | * **attributive logic** based on the use of //attributes// for denoting certain properties in a system (ali-book-springer), [[hekate:bib:hekate_bibliography#ali2007flairs-granular|ali2007flairs-granular)]], |
| - | * **functional dependency** is a general relation between two or more attributes (or attribute sets), called "dependent" and "independent"; the relation is such as in order to determine the values of the dependent attributes, the values of the independent ones are needed. | + | * **functional dependency** is a general relation between two or more attributes (or attribute sets), called "dependent" and "independent"; the relation is such as in order to determine the values of the dependent attributes, the values of the independent ones are needed, |
| - | * **graph notation** provides simple, standard, yet expressive means for knowledge specification, and transformation. | + | * **graph notation** provides simple, standard, yet expressive means for knowledge specification, and transformation, |
| - | * **visualization** is the key concept in the practical design support, provided by this method. | + | |
| ===== Preliminary Concepts ===== | ===== Preliminary Concepts ===== | ||
| - | * **gradual refinement** is the main design approach, where the design is being specified in number of steps, each step being more detailed than the previous one. | + | * **visualization** is the key concept in the practical design support, provided by this method, |
| - | * **structural transformations** are //formalized//, with well defined syntax and semantics. | + | * **gradual refinement** is the main design approach, where the design is being specified in number of steps, each step being more detailed than the previous one, |
| - | * **hierarchical model** captures all of the subsequent design steps, with no semantic gaps; it holds knowledge about the system on the different abstraction levels [[hekate:bib:hekate_bibliography#gjn2007iwk|(gjn2007iwk)]]. | + | * **structural transformations** are //formalized//, with well defined syntax and semantics, |
| + | * **hierarchical model** captures all of the subsequent design steps, with no semantic gaps; it holds knowledge about the system on the different abstraction levels [[hekate:bib:hekate_bibliography#gjn2007iwk|(gjn2007iwk)]], | ||
| * **knowledge-based approach** provides means of the //declarative// model specification. | * **knowledge-based approach** provides means of the //declarative// model specification. | ||
| - | Based on these concepts, a formalization of the method is put forward in the following section. | ||
| - | ===== ARD+ Method ===== | + | ===== Syntax ===== |
| - | ** ** | + | |
| - | ==== Syntax ==== | + | |
| - | The ARD+ method aims at capturing relations between //attributes// in terms of //Attributive Logic// (AL)(ali-book-springer),([[hekate:bib:hekate_bibliography#ali2007flairs-granular|ali2007flairs-granular]]),([[hekate:bib:hekate_bibliography#gjn2008ruleapps|gjn2008ruleapps]]). | + | * the ARD+ method aims at capturing relations between //attributes// in terms of //Attributive Logic// (AL)(ali-book-springer),([[hekate:bib:hekate_bibliography#ali2007flairs-granular|ali2007flairs-granular]]),([[hekate:bib:hekate_bibliography#gjn2008ruleapps|gjn2008ruleapps]]) |
| - | It is based on the use of //attributes// for expressing knowledge about facts regarding world under consideration. | + | * based on the use of //attributes// for expressing knowledge about facts regarding world under consideration |
| - | A typical atomic formula (fact) takes the form ''A(o) = d'', where ''A'' is an attribute, ''o'' is an object | + | * typical //atomic formula// (fact) takes the form ''A(o) = d'', where ''A'' is an attribute, ''o'' is an object and ''d'' is the current value of ''A'' for ''o'' |
| - | and ''d'' is the current value of ''A'' for ''o''. | + | * more complex descriptions take usually the form of conjunctions of such atoms and are omnipresent in the AI literature |
| - | More complex descriptions take usually the form of conjunctions of such atoms and are omnipresent in the AI literature. | + | |
| - | === Attribute === | + | ===== Syntax: Attribute ===== |
| Let there be given the following, pairwise disjoint sets of symbols:\\ | Let there be given the following, pairwise disjoint sets of symbols:\\ | ||
| Linia 102: | Linia 98: | ||
| where ''o ∈ O''. | where ''o ∈ O''. | ||
| + | |||
| + | ===== Syntax: Attribute ===== | ||
| A generalized attribute $A<sub>i</sub>$ is a function (or partial function) of the form ''A<sub>i</sub>:o → 2<sup>D<sub>i</sub></sup>'', where ''2<sup>D<sub>i</sub></sup>'' is the family of all the subsets of D<sub>i</sub>, to let the attribute take more than a single value at a time. | A generalized attribute $A<sub>i</sub>$ is a function (or partial function) of the form ''A<sub>i</sub>:o → 2<sup>D<sub>i</sub></sup>'', where ''2<sup>D<sub>i</sub></sup>'' is the family of all the subsets of D<sub>i</sub>, to let the attribute take more than a single value at a time. | ||
| Linia 108: | Linia 106: | ||
| ''A<sub>i</sub>: A<sub>i</sub> → D<sub>i</sub>''. | ''A<sub>i</sub>: A<sub>i</sub> → D<sub>i</sub>''. | ||
| - | === Conceptual Attribute === | + | ===== Syntax: Conceptual Attribute ===== |
| A conceptual attribute //A// is an attribute describing some general, abstract aspect of the system | A conceptual attribute //A// is an attribute describing some general, abstract aspect of the system | ||
| Linia 117: | Linia 115: | ||
| Conceptual attributes are being //finalized// during the design process, into, possibly multiple, physical attributes, see Def. [[#finalization_transformation|finalization]]. | Conceptual attributes are being //finalized// during the design process, into, possibly multiple, physical attributes, see Def. [[#finalization_transformation|finalization]]. | ||
| - | === Physical Attribute === | + | ===== Syntax: Physical Attribute ===== |
| A physical attribute //a// is an attribute describing an aspect of the system with its domain defined. | A physical attribute //a// is an attribute describing an aspect of the system with its domain defined. | ||
| Linia 125: | Linia 123: | ||
| Physical attributes cannot be finalized, they are present in the final rules capturing knowledge about the system. | Physical attributes cannot be finalized, they are present in the final rules capturing knowledge about the system. | ||
| - | === Property === | + | ===== Syntax: Property ===== |
| ''P'' is a non-empty set of attributes representing knowledge about certain part of the system being designed. | ''P'' is a non-empty set of attributes representing knowledge about certain part of the system being designed. | ||
| Such attributes //describe// the property. | Such attributes //describe// the property. | ||
| - | === Simple Property === | + | ===== Syntax: Simple Property ===== |
| ''PS'' is a property which consists of (is described by) a //single// attribute. | ''PS'' is a property which consists of (is described by) a //single// attribute. | ||
| - | === Complex Property === | + | ===== Syntax: Complex Property ===== |
| ''PC'' is a property which consists of (is described by) //multiple// attributes. | ''PC'' is a property which consists of (is described by) //multiple// attributes. | ||
| - | === Dependency === | + | ===== Syntax: Dependency ==== |
| A dependency ''D'' is an ordered pair of properties | A dependency ''D'' is an ordered pair of properties | ||
| ''D<sub>1,2</sub>=[P<sub>1</sub>, P<sub>2</sub>]'', | ''D<sub>1,2</sub>=[P<sub>1</sub>, P<sub>2</sub>]'', | ||
| where ''P<sub>1</sub>'' is the independent property, and ''P<sub>2</sub>'' depends functionally on ''P<sub>1</sub>''. | where ''P<sub>1</sub>'' is the independent property, and ''P<sub>2</sub>'' depends functionally on ''P<sub>1</sub>''. | ||
| - | === Derivative === | + | ===== Syntax: Derivative ===== |
| ''V'' is an ordered pair of properties, such as: | ''V'' is an ordered pair of properties, such as: | ||
| ''V=[P<sub>1</sub>, P<sub>2</sub>]'', | ''V=[P<sub>1</sub>, P<sub>2</sub>]'', | ||
| where ''P<sub>2</sub>'' is derived from ''P<sub>1</sub>'' upon transformation. | where ''P<sub>2</sub>'' is derived from ''P<sub>1</sub>'' upon transformation. | ||
| - | === DPD === | + | ===== Syntax: DPD ===== |
| A Design Process Diagram is a triple | A Design Process Diagram is a triple | ||
| ''R=[P,D,V]'' where ''P'' is a set of properties, ''D'' is a set of dependencies and ''V'' is a set of derivatives. | ''R=[P,D,V]'' where ''P'' is a set of properties, ''D'' is a set of dependencies and ''V'' is a set of derivatives. | ||
| - | === ARD+ === | + | ===== Syntax: ARD+ ===== |
| An Attribute Relationship Diagram\\ | An Attribute Relationship Diagram\\ | ||
| ''G'' is a pair\\ | ''G'' is a pair\\ | ||
| Linia 159: | Linia 158: | ||
| The diagram constitutes a //directed graph// with possible cycles. | The diagram constitutes a //directed graph// with possible cycles. | ||
| - | === TPH === | + | ==== TPH ==== |
| A Transformation Process History ''TPH'' is a pair: | A Transformation Process History ''TPH'' is a pair: | ||
| ''TPH=[P,V]'' if there is a //DPD// ''G=[P,D,V]''. | ''TPH=[P,V]'' if there is a //DPD// ''G=[P,D,V]''. | ||
| Linia 165: | Linia 164: | ||
| The ''TPH'' can be expressed as a directed graph with properties being nodes and derivatives being edges. | The ''TPH'' can be expressed as a directed graph with properties being nodes and derivatives being edges. | ||
| - | ==== Transformations ==== | + | ===== Transformations ===== |
| - | Diagram transformations are one of the core concepts in the ARD+. | + | * diagram transformations are one of the core concepts in the ARD+ |
| - | They serve as a tool for diagram specification and development. | + | * they serve as a tool for diagram specification and development |
| - | For the transformation ''T'' such as ''T: G<sub>1</sub> → G<sub>2</sub>'', where ''G<sub>1</sub>'' and ''G<sub>2</sub>'' are both diagrams, the diagram ''G<sub>2</sub>'' carries more system related knowledge, is more specific and less abstract than the ''G<sub>1</sub>''. | + | * for the transformation ''T'' such as ''T: G<sub>1</sub> → G<sub>2</sub>'', where ''G<sub>1</sub>'' and ''G<sub>2</sub>'' are both diagrams, the diagram ''G<sub>2</sub>'' carries more system related knowledge, is more specific and less abstract than the ''G<sub>1</sub>'' |
| - | All of the transformations regard //properties//. | + | * all of the transformations regard //properties// |
| - | Some transformations are required to specify additional //dependencies// or introduce new //attributes// though. | + | * some transformations are required to specify additional //dependencies// or introduce new //attributes// though |
| - | A transformed diagram ''G<sub>2</sub>'' constitutes a more detailed //diagram level//. | + | * a transformed diagram ''G<sub>2</sub>'' constitutes a more detailed //diagram level// |
| - | === Finalization Transformation === | + | ===== Finalization Transformation ===== |
| - | Finalization ''TF'' is a function | + | * finalization ''TF'' is a function which transforms a //DPD// ''R'' into ''R<sub>TF</sub>'' by transforming a simple property ''PS'' consisting of a single conceptual attribute into a ''P<sub>new</sub>'', where the attribute belonging to ''PS'' is substituted by one or more conceptual or physical attributes belonging to ''P'' |
| - | which transforms a //DPD// ''R'' into ''R<sub>TF</sub>'' by transforming a simple property ''PS'' consisting of a single conceptual attribute into a ''P<sub>new</sub>'', where the attribute belonging to ''PS'' is substituted by one or more conceptual or physical attributes belonging to ''P''; | + | * appropriate dependencies must be transformed as well and a derivative has to be introduced |
| - | appropriate dependencies must be transformed as well and a derivative has to be introduced. | + | * it introduces more attributes (more knowledge) regarding particular property |
| + | * an interpretation of the substitution is, that new attributes belonging to ''P'' are more detailed and specific than attributes belonging to ''PS'' | ||
| - | It introduces more attributes (more knowledge) regarding particular property. | + | ===== Split Transformation ===== |
| - | An interpretation of the substitution is, that new attributes belonging to ''P'' are more detailed and specific than attributes belonging to ''PS''. | + | * a split transforms a //DPD// ''R'' into ''R<sub>TS</sub>'' by transforming a complex property ''PC'' into some number of properties (a set) ''P<sub>new</sub>''; appropriate dependencies and derivatives must be introduced |
| + | * this transformation introduces new properties and defines functional relationships among them | ||
| - | === Split Transformation === | + | ===== Attribute Disjunction ===== |
| - | A split transforms a //DPD// ''R'' into ''R<sub>TS</sub>'' by transforming a complex property ''PC'' into some number of properties (a set) ''P<sub>new</sub>''; appropriate dependencies and derivatives must be introduced. | + | * attribute sets belonging to each of the properties ''P<sub>1</sub> ... P<sub>r</sub>'' have to be disjoint |
| - | This transformation introduces new properties and defines functional relationships among them. | + | ===== Attribute Matching ===== |
| + | * all attributes ''PC'' consists of have to belong to properties ''P<sub>1</sub>, ... P<sub>r</sub>'' | ||
| + | * no new attributes can be introduced for properties ''P<sub>1</sub> ... P<sub>r</sub>'' | ||
| + | * such introduction is possible through //finalization// only (see Def. [[#Finalization_Transformation|finalization]]) | ||
| - | === Attribute Disjunction === | + | ===== Attribute Pool ===== |
| - | Attribute sets belonging to each of the properties ''P<sub>1</sub> ... P<sub>r</sub>'' have to be disjoint. | + | * all attributes ''PC'' consists of have to belong to ''[P<sub>1</sub>, ... P<sub>r</sub>]'' |
| - | === Attribute Matching === | + | ===== Dependency Inheritance ===== |
| - | All attributes ''PC'' consists of have to belong to properties ''P<sub>1</sub>, ... P<sub>r</sub>''. | + | * all dependencies in ''D<sub>PC</sub>'' have to be covered by dependencies in ''D<sub>new</sub>'' |
| - | No new attributes can be introduced for properties ''P<sub>1</sub> ... P<sub>r</sub>''. | + | * if a ''PC'' depends on some property ''P<sub>x</sub>'' (or some property depends on it), such a dependence must be stated (in ''D<sub>new</sub>'') regarding at least one of the elements from ''P<sub>new</sub>'' and ''P<sub>x</sub>'' |
| - | Such introduction is possible through //finalization// only (see Def. [[#Finalization_Transformation|finalization]]). | + | |
| - | === Attribute Pool === | + | ===== Transformation Limit ===== |
| - | All attributes ''PC'' consists of have to belong to ''[P<sub>1</sub>, ... P<sub>r</sub>]''. | + | * a number of transformations in a single design step is limited to //one per property// |
| + | * it means that a property can be either //split// or //finalized// but not both | ||
| - | === Dependency Inheritance === | + | ===== Refactoring ===== |
| - | All dependencies in ''D<sub>PC</sub>'' have to be covered by dependencies in ''D<sub>new</sub>''. | + | |
| - | If a ''PC'' depends on some property ''P<sub>x</sub>'' (or some property depends on it), such a dependence must be stated (in ''D<sub>new</sub>'') regarding at least one of the elements from ''P<sub>new</sub>'' and ''P<sub>x</sub>''. | + | |
| - | === Transformation Limit === | + | * during the design process some properties or attributes can be missed or treated as not important, hence not included in the diagram |
| - | A number of transformations in a single design step | + | * refactoring allows to incorporate such artifacts or remove unnecessary ones |
| - | is limited to //one per property//. | + | * refactoring consists in modifying any of the existing transformations: //finalization// or //split// in a particular ARD+ diagram |
| - | It means that a property can be either //split// or //finalized// but not both. | + | |
| - | ==== Refactoring ==== | + | ===== Finalization ===== |
| + | * a //Finalization Refactoring// consist in adding or removing an attribute, modifying a past finalization transformation | ||
| + | * removing an attribute ''A<sub>r</sub>'' results in removing it from all already defined complex properties; if there is a simple property which regards such an attribute, it should be removed then | ||
| + | * the //Finalization Refactoring// with adding an attribute implies that at some point a split has to be performed on a property involving the new attribute; appropriate dependencies between the property which consists of the introduced attribute and other properties have to be stated as well; this constitutes a //Split Refactoring// | ||
| - | During the design process some properties or attributes can be missed or treated as not important, hence not included in the diagram. | + | ===== Split ===== |
| - | Refactoring allows to incorporate such artifacts or remove unnecessary ones. | + | * //Split Refactoring// regards: |
| - | Refactoring consists in modifying any of the existing transformations: //finalization// or //split// in a particular ARD+ diagram. | + | * adding or removing properties upon already defined splits, |
| + | * rearranging already defined dependencies. | ||
| - | === Finalization === | + | * Removing a property implies that all other properties that were split from it, even transitionally, have to be removed. |
| - | A //Finalization Refactoring// consist in adding or removing an attribute, modifying a past finalization transformation. | + | * Adding a property leads to defining its dependencies, between the property and other already defined ones. |
| - | Removing an attribute ''A<sub>r</sub>'' results in removing it from all already defined complex properties. | + | ===== Split ===== |
| - | If there is a simple property which regards such an attribute, it should be removed then. | + | |
| - | The //Finalization Refactoring// with adding an attribute implies that at some point a split has to be performed on a property involving the new attribute. | + | * Adjusting dependencies can be based on: |
| - | Furthermore, appropriate dependencies between the property which consists of the introduced attribute and other properties have to be stated as well. | + | * defining dependencies between the property and other existing properties at the //most detailed// diagram level, or |
| - | This constitutes a //Split Refactoring// | + | * 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. [[#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. | ||
| - | === Split === | + | ===== Semantics ===== |
| - | In general a //Split Refactoring// regards: | + | * the semantics of ARD+ will be explained and visualized using a reworked //Thermostat example//, discussed in (ali-book-springer), ([[hekate:bib:hekate_bibliography#gjn2005:kkio|gjn2005:kkio]]) |
| - | * adding or removing properties upon already defined splits, | + | * the //goal of the system// is to set the temperature in the office to the given set-point, based on the current time |
| - | * rearranging already defined dependencies. | + | |
| - | Removing a property implies that all other properties that were split from it, even transitionally, have to be removed. | + | ===== Semantics ===== |
| - | Adding a property leads to defining its dependencies, between the property and other already defined ones. | + | |
| - | In general adjusting dependencies can be based on: | + | * a property always consists of a set of attributes, these attributes identify such a property uniquely |
| - | * defining dependencies between the property and other existing properties at the //most detailed// diagram level, or | + | * the single most important concept in ARD+ is the concept of the //property functional dependency// |
| - | * adjusting appropriate past split transformations gradually (at previous diagram levels) to take this new property into consideration. | + | * in order to evaluate a dependent property, all independent properties have to be evaluated first |
| + | * in order to calculate dependent property attribute values, independent properties attribute values have to be calculated first | ||
| + | * property described by ''Temperature'' depends on a property described by ''Time'' | ||
| - | In the first case the dependencies are defined for the most detailed diagram level only. | + | ===== Semantics ===== |
| - | Since there is a hierarchical design process (see Sec. [[ardplus#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. | + | * identifying all possible properties and attributes in a system could be a very complex task |
| - | Stopping this process at more general level than the most detailed one, generates appropriate splits in all more detailed levels automatically. | + | * transformations (see [[#transformations|transformation]]) allow to gradually refine properties, attributes and functional dependencies in the system being designed |
| + | * this process ends when all properties are described by //physical attributes// and all functional dependencies among properties are defined | ||
| - | ==== Semantics ==== | + | ===== Semantics ===== |
| - | The semantics of ARD+ will be explained and visualized using a reworked //Thermostat example//, discussed in (ali-book-springer), ([[hekate:bib:hekate_bibliography#gjn2005:kkio|gjn2005:kkio]]). | + | |
| - | The goal of the system is to set the temperature in the office to the given set-point, based on the current time. | + | |
| - | + | ||
| - | A property always consists of a set of attributes, these attributes identify such a property uniquely. | + | |
| - | The single most important concept in ARD+ is the concept of the //property functional dependency//. | + | |
| - | It indicates that in order to evaluate a dependent property, all independent properties have to be evaluated first. | + | |
| - | It means, that in order to calculate dependent property attribute values, independent properties attribute values have to be calculated first. | + | |
| - | It indicates that a property described by ''Temperature'' depends on a property described by ''Time''. | + | |
| - | + | ||
| - | Identifying all possible properties and attributes in a system could be a very complex task. | + | |
| - | Transformations (see [[#transformations|transformation]]) allow to gradually refine properties, attributes and functional dependencies in the system being designed. | + | |
| - | This process ends when all properties are described by //physical attributes// and all functional dependencies among properties are defined. | + | |
| An example of the //finalization// is given in Figures: | An example of the //finalization// is given in Figures: | ||
| Linia 259: | Linia 253: | ||
| {{ hekate:ard-finalization-ex1.png?273x140 }} | {{ hekate:ard-finalization-ex1.png?273x140 }} | ||
| - | The top diagram represents the system before the finalization. | + | * the top diagram represents the system before the finalization |
| - | The property described by attribute ''Time'' is finalized. | + | * the property described by attribute ''Time'' is finalized |
| - | As a result new attributes are introduced: ''Date'', ''Hour'', ''season'', ''operation''. | + | * as a result new attributes are introduced: ''Date'', ''Hour'', ''season'', ''operation''; the outcome is the bottom diagram |
| - | The outcome is the bottom diagram. | + | |
| - | Semantics of this transformation is that the system property described by a //conceptual attribute// ''Time'', can be more adequately described by a set of more detailed attributes: ''Date'', ''Hour'', ''season'', ''operation'', which more precisely define the meaning ''Time'' in the design. | + | ===== Semantics ===== |
| - | The two latter attributes are //physical// ones, used in the final rule implementation. | + | |
| - | Finalization of properties based on such attributes is not allowed. | + | * semantics of this transformation is that the system property described by a //conceptual attribute// ''Time'', can be more adequately described by a set of more detailed attributes: ''Date'', ''Hour'', ''season'', ''operation'', which more precisely define the meaning ''Time'' in the design |
| + | * the two latter attributes are //physical// ones, used in the final rule implementation | ||
| + | * finalization of properties based on such attributes is not allowed | ||
| + | |||
| + | ===== Semantics ===== | ||
| An example of //simple finalization// is given in Figure: | An example of //simple finalization// is given in Figure: | ||
| Linia 271: | Linia 269: | ||
| {{ hekate:ard-finalization-ex2.png?292x100 }} | {{ hekate:ard-finalization-ex2.png?292x100 }} | ||
| - | A property described by a //conceptual attribute// //Temperature// is finalized into a property described by a single //physical attribute// ''thermostat_settings''. | + | * a property described by a //conceptual attribute// //Temperature// is finalized into a property described by a single //physical attribute// ''thermostat_settings'' |
| - | In other words, a general concept of temperature, represented by ''Temperature'', is to be represented by an attribute ''thermostat_settings''. | + | * in other words, a general concept of temperature, represented by ''Temperature'', is to be represented by an attribute ''thermostat_settings'' |
| - | Another ARD+ transformation is the //split//. | + | ===== Semantics ===== |
| - | An example is given in Figure: | + | |
| + | Another ARD+ transformation is the //split//. An example is given in Figure: | ||
| {{ 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. | + | |
| - | Furthermore 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 ===== | ||
| During the split, some of the properties can be defined as functionally independent. | During the split, some of the properties can be defined as functionally independent. | ||
| Linia 289: | 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 296: | 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 349: | 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 356: | 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 366: | 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 373: | 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 386: | 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 409: | 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 ===== | ||
