Transcript Ontology Support for Abstraction Layer Modularization

1
Ontology Support for
Abstraction Layer Modularization
Hyun Cho, Jeff Gray
Department of Computer Science
University of Alabama
[email protected]
[email protected]
Jules White
Bradley Dept. of Electrical and
Computer Engineering
Support by NSF CAREER.
Virginia Tech
Overview of Presentation
2





Overview of Abstraction Layer
Overview of Ontology
Issues in Abstraction Layer Modularization
Research Approach
Conclusion
Examples of the Abstraction Layer
3

Java Virtual Machine
Applets and Applications
Java
Base
Java Base API
Java Standard Extension API
Java Base Classes
Java Standard Extension Classes
Java Virtual Machine
Platform
Porting Interface
Adapter
Browser
OS
Hardware
Network
Java on
a Browser
Adapter
OS
Adapter
JavaOS
OS
Hardware
Hardware
Hardware
Java on
a Desktop OS
Java on
a Smaller OS
Java on
a JavaOS
Examples of the Abstraction Layer (cont.)
4

GIGA Platform

Mobile platform developed by SK Telecome in South Korea
Benefits and issues of abstraction layers
5



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
Ontologies
6

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.
Criteria for Introducing Ontologies
7


Large amounts of data
Complex data structures


Diverse sources



Inheritance, containment and many relationships
Many legacy systems
Sources using different formats
Requirement for formal proofs

Contracts and policy enforcement
Characteristics of APIs
8

APIs can be decomposed into multiple semantic units


APIs are structured with a hierarchy and can be represented
as a Tree


Ex.) OS APIs: Thread Management, Memory Management, I/O
Management
Java APIs, Microsoft Foundation Class
APIs follow a naming convention

Noun only: Normally constructor/destructor


Verb followed by noun


Socket(), Array()
createProcess(), deleteProcess()
Verb only

add(), append()
Process of Ontology Support
for Abstraction Layer Modularization
9
Domain Feature
Model
Natural Language
Processing
Ontology
Processing
Annotate the
tokens
Classify the
tokens
Identify API
relationship
APIs of
Underlying
Resources
Accesses
Abstraction Layer
Modularity
Tokenizer APIs
Traceability Link
Feature
Model for
Abstraction
Layer
API
Generator
APIs for
Abstraction
Layer
Feature Model of Abstraction Layer
10
OS
Process
Thread
Task
...
Process
Synchronization
Mutex
...
Semaphore
File
...
Conditional
Variable
Mutex
Cyg_mutex_t *mutex::eCos:cyg_mutex_init
/* mutex to initialize */
SEM_ID semId::VxWorks:semMGiveForce
/* semaphore ID to give */
LPSECURITY_ATTRIBUTES lpMutextAttributes::WinCE:CreateMutex
...
datatype VariableName::PackageName:APIName
void cyg_mutex_init ( cyg_mutex_t )::eCos
void cyg_mutex_destroy ( cyg_mutex_t *mutex )::eCos
SEM_ID semMCreate ( int options )::VxWorks
STATUS semMGiveForce( SEM_ID semId )::VxWorks
HANLDE CreateMutex( LPSECURITY_ATTRIBUTES lpMutextAttributes, BOOL bInitialOwner, LPCTSRT lpName)::WinCE
...
ReturnType APIName:: PackageName
Measurement of Abstraction Layer Modularity

Object-Oriented Metrics

Weighted methods per class (MWC)



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 class complexity by summing the complexity of each method
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.476493, Jun 1994
11
Coupling between object classes (CBO)
12


Measure the number of other classes to which the class is
coupled
Excessive coupling indicates weakness of class encapsulation,
or modularity
Response for class (RFC)
13



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
Lack of cohesion metric (LCOM)
14

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
Conclusions
15





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.