Ontology Support for Abstraction Layer Modularization

Ontology Support forAbstraction Layer

Modularization

Hyun Cho, Jeff GrayDepartment of Computer

ScienceUniversity of Alabama

[email protected]@cs.ua.edu

Jules White

Bradley Dept. of Electrical and Computer Engineering

Virginia Tech

Support by NSF CAREER.

1

Overview of Presentation

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

2

Examples of the Abstraction Layer

Porting Interface

Hardware

OS

Browser

Adapter

Hardware

Adapter

OS

Hardware

Adapter

OS

Hardware

JavaOS

Java Virtual Machine

Java Base Classes Java Standard Extension Classes

Java Base API Java Standard Extension API

Applets and Applications

Java ona Browser

Java ona Desktop OS

Java ona Smaller OS

Java ona JavaOS

Network

Java

Base

Platform

Java Virtual Machine

3

Examples of the Abstraction Layer (cont.)

GIGA Platform Mobile platform developed by SK Telecome in South

Korea

4

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

5

Construct the abstraction layer using ontology

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.

6

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

7

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()

8

Process of Ontology Support for Abstraction Layer Modularization

Natural Language ProcessingTokenizer

APIs

Annotate the tokens

Ontology Processing

Identify API relationshi

p

Classify the tokens

Feature Model

for Abstraction Layer

Accesses Abstraction

Layer Modularity

API Generato

r

APIs for Abstraction

Layer

APIs of Underlying Resources

Traceability Link

Domain Feature Model

9

Feature Model of Abstraction Layer

OS

Process

Thread Task

Synchronization

Mutex

File

Semaphore

... ...

...

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...

void cyg_mutex_init ( cyg_mutex_t )::eCosvoid cyg_mutex_destroy ( cyg_mutex_t *mutex )::eCosSEM_ID semMCreate ( int options )::VxWorksSTATUS semMGiveForce( SEM_ID semId )::VxWorksHANLDE CreateMutex( LPSECURITY_ATTRIBUTES lpMutextAttributes, BOOL bInitialOwner, LPCTSRT lpName)::WinCE...

ProcessConditional

Variable

10

datatype VariableName::PackageName:APIName

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

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

12

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

13

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

14

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.

15

Support by NSF CAREER.

16