From Odp
(Difference between revisions)
|
|
Line 2: |
Line 2: |
| {{Graphical representation header}} | | {{Graphical representation header}} |
| {{Graphical representation | | {{Graphical representation |
- | |ImageName=Fig_view_inheritance_structure.png | + | |ImageName=Fig_view_in |
| }} | | }} |
| {{Architectural OP General Template | | {{Architectural OP General Template |
Line 45: |
Line 45: |
| |RelatedTo=Normalization, Classes As Property Values, Multiple Inheritance | | |RelatedTo=Normalization, Classes As Property Values, Multiple Inheritance |
| }} | | }} |
- | {{Graphical representation | + | {{Additional information header}} |
| + | {{Include image |
| |ImageName=Fig_avizienis_fault_4.jpg | | |ImageName=Fig_avizienis_fault_4.jpg |
| }} | | }} |
| | | |
- | {{Graphical representation | + | {{Include image |
| |ImageName=Fig_avizienis_fault_5a.jpg | | |ImageName=Fig_avizienis_fault_5a.jpg |
| }} | | }} |
| | | |
- | {{Graphical representation | + | {{Include image |
| |ImageName=Fig_avizienis_fault_5b.jpg | | |ImageName=Fig_avizienis_fault_5b.jpg |
| }} | | }} |
| | | |
- | {{Graphical representation | + | {{Include image |
| |ImageName=Fig_fault_f1_f2_asserted_prot4x.png | | |ImageName=Fig_fault_f1_f2_asserted_prot4x.png |
| }} | | }} |
Revision as of 13:19, 3 March 2010
This pattern has been certified.
Related submission, with evaluation history, can be found here
| If you are a member of quality committee please visit the
evaluation section
If you are author of this proposal or you want to contribute to this pattern's review, you can:
In general, it could be useful to visit the evaluation section to have information about the evaluation process of this proposal
Current revision ID: 8528
|
Graphical representation
Diagram
(this article has no graphical representation)
General information
Description
Problem description
| There are ontology domain concepts that are difficult to represent due to the complexities in their definition and the presence of multiple alternative criteria to classify their abstractions.
|
Solution description
| Introduce the following types of classes:
- Criterion_i: These classes represent each one of the alternative abstraction criteria of the TargetDomainConcept (Criterion1, Criterion2, Criterion_i in the Figure above). The list of classes may not be exhaustive or pairwise disjoint.
- Ci_Class_x: These classes refine each abstraction criteria class (C1_Class1, ..., C2_Class1, ..., Ci_Class_i in the Figure above). The list of classes may not be exhaustive or pairwise disjoint.
- CiClass_xCjClass_y, Ci_Class_xClass_y: These classes participate in multiple inheritance relationships combining different refinements from the alternative abstraction criteria classes (C1Class3_C2Class2 and C1_Class1Class2 in the Figure above).
|
Implementation workflow
|
|
Reusable component
|
|
Example
Problem example
|
|
Solution example
| Figure above in particular, shows a matrix representation of all types of faults which may affect a system during its life. Implicitly, the figure reveals several alternative criteria for the classification of faults:
- A first criterion can be derived from the left column of the matrix (listing the basic view points from Figure 2: Development/Operational Faults, Internal/External Faults and so on). This column represents the values of the eight basic viewpoints which lead to the elementary fault classes.
- A second criterion can be abstracted from the bottom row (listing numbers 1 to 31). This row represents the 31 likely combinations of fault classes out of the 256 possible.
- A third criterion is implicit at the top row, representing the three major partially overlapping groupings of faults: Development, Physical and Interaction.
- A fourth criterion can be seen at the bottom row, labeled Examples, containing nine illustrative examples of fault classes.
|
Consequences
| Inter- and Intra-criterion Multiple Inheritance.
There is an interesting feature regarding the types of multiple inheritance relations that can take place in the context of a View Inheritance pattern. These types of multiple inheritance relationships can be characterized as:
- Inter-criterion, when the parent classes involved in the multiple inheritance relation are subclasses of different abstraction criteria. The class C1Class3_C2Class2 in Figure 1 is an example of this type of inheritance because one of its parent classes, C1_Class3, is a refining concept of Criterion1 and the other parent class, C2_Class2, is a refining concept of Criterion2.
- Intra-criterion, when the parent classes involved in the multiple inheritance relation are subclasses of the same abstraction criterion. The class C1_Class1Class2 is an example of this type of inheritance because all of its parents classes, C1_Class1 and C1_Class2, are refining concepts of the same criterion, Criterion1.
- Intra- and inter-criterion, when there are at least two parents involved in the relation that are subclasses of the same abstraction criterion and there is at least one more different parent that is a subclass of a different abstraction criterion. An example of this type of inheritance is trivial to extrapolate from the composition of the previous two.
|
Pattern reference
Origin
| Object Oriented:
- Meyer, B.: Object-Oriented Software Construction (Book/CD-ROM) (2nd Edition). Prentice Hall PTR (March 2000)
Ontology:
- Rector, A.L.: Modularisation of domain ontologies implemented in description logics and related formalisms including owl. In: K-CAP '03: Proceedings of the 2nd international conference on Knowledge capture, New York, NY, USA, ACM (2003) 121--128
|
Known use
|
|
Reference
|
|
Related ODP
| Normalization, Classes As Property Values, Multiple Inheritance
|
Additional information
Template:Include image
Template:Include image
Template:Include image
Template:Include image
Scenarios
Scenarios about View Inheritance
No scenario is added to this Content OP.
Reviews
Reviews about View Inheritance
There is no review about this proposal.
This revision (revision ID 8528) takes in account the reviews: none
Other info at evaluation tab
Modeling issues
Modeling issues about View Inheritance
There is no Modeling issue related to this proposal.
References
Add a reference