Submissions:View Inheritance

From Odp

(Difference between revisions)
Jump to: navigation, search
Line 20: Line 20:
{{Architectural OP Example Template
{{Architectural OP Example Template
|Problem=Matrix representation of Fault in Avizienis et al. [1] used in the ReSIST KB ontology
|Problem=Matrix representation of Fault in Avizienis et al. [1] used in the ReSIST KB ontology
-
 
+
{{Include Image |ImageName=Fig_avizienis_fault_5a.jpg}}
[1] Avizienis, A., Laprie, J.C., Randell, B., Landwehr, C.: Basic concepts and taxonomy of dependable and secure computing. IEEE Transactions on Dependable and Secure Computing 01(1) (2004) 11--33
[1] Avizienis, A., Laprie, J.C., Randell, B., Landwehr, C.: Basic concepts and taxonomy of dependable and secure computing. IEEE Transactions on Dependable and Secure Computing 01(1) (2004) 11--33
-
{{Include Image
+
|Solution=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:
-
|ImageName=Fig_avizienis_fault_5a.jpg}}
+
 
 +
* 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.
 +
}}
 +
{{Architectural OP Reference Template
 +
|RelatedTo=Normalization, Classes As Property Values, Multiple Inheritance
}}
}}
-
{{Architectural OP Reference Template}}
 
{{Scenarios about me}}
{{Scenarios about me}}
{{Reviews about me}}
{{Reviews about me}}

Revision as of 16:16, 29 August 2009


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: 5642

Image:Fig_view_inheritance_structure.png

General information

Name View Inheritance
Also known as
Author(s) Benedicto Rodriguez-Castro, Hugh Glaser
Domain (if applicable)
Submitted by BenedictoRodriguezCastro, HughGlaser


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 Matrix representation of Fault in Avizienis et al. [1] used in the ReSIST KB ontology

Image:Fig_avizienis_fault_5a.jpg

[1] Avizienis, A., Laprie, J.C., Randell, B., Landwehr, C.: Basic concepts and taxonomy of dependable and secure computing. IEEE Transactions on Dependable and Secure Computing 01(1) (2004) 11--33

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


Pattern reference

Origin
Known use
Reference
Related ODP Normalization, Classes As Property Values, Multiple Inheritance


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 5642) takes in account the reviews: none

Other info at evaluation tab

Retrieved from "http://ontologydesignpatterns.org/wiki/Submissions:View_Inheritance"
Personal tools
Quality Committee
Content OP publishers