ArchitecturalODPAuthor
|
Benedicto Rodriguez-Castro +,
Hugh Glaser +
|
ArchitecturalODPConsequence
|
'''Inter- and Intra-criterion Multiple Inh … '''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. from the composition of the previous two.
|
ArchitecturalODPDomain
|
General +
|
ArchitecturalODPExample
|
Figure above in particular, shows a matrix … 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. ne illustrative examples of fault classes.
|
ArchitecturalODPName
|
View Inheritance +
|
ArchitecturalODPOrigin
|
Object Oriented:
* Meyer, B.: Object-Orien … 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 re, New York, NY, USA, ACM (2003) 121--128
|
ArchitecturalODPProblem
|
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.
|
ArchitecturalODPRelated
|
Normalization +,
Partition +,
ClassAsPropertyValue +,
Submission:MultipleInheritance +
|
ArchitecturalODPSolution
|
Introduce the following types of classes:
… 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). ''C1_Class1Class2'' in the Figure above).
|
GraphicallyRepresentedBy
|
Fig view inheritance structure.png +
|
Modification dateThis property is a special property in this wiki.
|
5 September 2010 18:15:15 +
|
SubmittedBy
|
BenedictoRodriguezCastro +,
HughGlaser +
|
Categories |
ArrchitecturalOP +,
ProposedArchitecturalOP +
|