Post on 17-Jan-2018
description
Ontology Support forAbstraction Layer
ModularizationHyun Cho, Jeff Gray
Department of Computer Science
University of Alabamahcho7@crimson.ua.edu
gray@cs.ua.edu
Jules WhiteBradley 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 Machine3
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
APIsAnnotate
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