Ontology Support for Abstraction Layer Modularization

1
Ontology Support forAbstraction Layer
Modularization

• Hyun Cho, Jeff Gray
• Department of Computer Science
• University of Alabama
• hcho7_at_crimson.ua.edu
• gray_at_cs.ua.edu

• Jules White
• Bradley Dept. of Electrical and Computer
  Engineering
• Virginia Tech

Support by NSF CAREER.
2
Overview of Presentation

• Overview of Abstraction Layer
• Overview of Ontology
• Issues in Abstraction Layer Modularization
• Research Approach
• Conclusion

3
Examples of the Abstraction Layer

• Java Virtual Machine

4
Examples of the Abstraction Layer (cont.)

• GIGA Platform
• Mobile platform developed by SK Telecome in South
  Korea

5
Benefits and issues of abstraction layers

• Removes dependencies from underlying resources
• Promote portability and reusability
• Require much effort and time to build an
  abstraction layer
• Same amount of efforts and time may be required
  if a new underlying resource is introduced or the
  supported resources are evolved
• Focus on portability, reusability and reducing
  overhead
• Little attention to the modularity of the
  abstraction layer

Construct the abstraction layer using ontology
6
Ontologies

• An ontology is an explicit description of a
  domain
• concepts
• properties and attributes of concepts
• constraints on properties and attributes

Ontology allows people to share common
understanding of the structure of information and
enable reuse of domain knowledge.
7
Criteria for Introducing Ontologies

• Large amounts of data
• Complex data structures
• Inheritance, containment and many relationships
• Diverse sources
• Many legacy systems
• Sources using different formats
• Requirement for formal proofs
• Contracts and policy enforcement

8
Characteristics of APIs

• APIs can be decomposed into multiple semantic
  units
• Ex.) OS APIs Thread Management, Memory
  Management, I/O Management
• APIs are structured with a hierarchy and can be
  represented as a Tree
• Java APIs, Microsoft Foundation Class
• APIs follow a naming convention
• Noun only Normally constructor/destructor
• Socket(), Array()
• Verb followed by noun
• createProcess(), deleteProcess()
• Verb only
• add(), append()

9
Process of Ontology Support
for Abstraction Layer Modularization
Domain Feature Model
Natural Language Processing
Ontology Processing
Feature Model for Abstraction Layer
API Generator
Tokenizer APIs
Classify the tokens
Annotate the tokens
Identify API relationship
Accesses Abstraction Layer Modularity
APIs for Abstraction Layer
APIs of Underlying Resources
Traceability Link
10
Feature Model of Abstraction Layer
datatype VariableNamePackageNameAPIName
ReturnType APIName PackageName
11
Measurement of Abstraction Layer Modularity

• Object-Oriented Metrics
• Weighted methods per class (MWC)
• Measure class complexity by summing the
  complexity of each method
• Depth of inheritance tree (DIT)
• Measure the length o the maximum path from the
  node to the root of the tree
• Derive the modularity by measuring affected
  classes from a change
• Number of children (NOC)
• Measure the number of direct subclasses
• Coupling between object classes (CBO)
• Response for class (RFC)
• Lack of cohesion metric (LCOM)

Chidamber, S.R.,Kemerer, C.F., "A metrics suite
for object oriented design," Software
Engineering, IEEE Transactions on , vol.20, no.6,
pp.476-493, Jun 1994
12
Coupling between object classes (CBO)

• Measure the number of other classes to which the
  class is coupled
• Excessive coupling indicates weakness of class
  encapsulation, or modularity

13
Response for class (RFC)

• a set of methods that can potentially be executed
  in response to a message received by an object of
  that class.
• Useful to check testability
• Smaller numbers are better
• Larger numbers indicate increased complexity and
  debugging difficulties

14
Lack of cohesion metric (LCOM)

• A measure of the tightness of the code
• Consider a class C with three methods M1,M2 and
  M3.
• Let I1 a , b . c , d , e , I2 a , b ,
  e, and I3 x,y,z.
• I1?I2 is nonempty,
• I1 ?I3 and I2 ?I3 are null sets
• LCOM 2 1 1
• The larger the number of LCOM, the more cohesive
  the class

15
Conclusions

• The approach helps maintain the abstraction layer
  consistently
• A feature model can provide insight the
  modularity and functionality of the underlying
  resources
• The approach is transparent to the implementation
  technology of underlying resources
• Need to find the appropriate measurement to
  predict the modularity in model level
• Generative programming has the potential to
  automate the creation of APIs for the abstraction
  layer.

16
Support by NSF CAREER.