1. Ontology Support for Abstraction Layer Modularization Hyun Cho, Jeff Gray Department of Computer Science University of Alabama hcho7@crimson.ua.edu gray@cs.ua.edu Jules White Bradley Dept. of Electrical and Computer Engineering Virginia Tech Support by NSF CAREER. 1

2. Overview of Presentation  Overview of Abstraction Layer  Overview of Ontology  Issues in Abstraction Layer Modularization  Research Approach  Conclusion 2

3. 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 on a Browser Java on a Desktop OS Java on a Smaller OS Java on a JavaOS Network Java Base Platform  Java Virtual Machine 3

4. Examples of the Abstraction Layer (cont.)  GIGA Platform  Mobile platform developed by SK Telecome in South Korea 4

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

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 7

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

9. Process of Ontology Support for Abstraction Layer Modularization Natural Language Processing Tokenizer APIs Annotate the tokens Ontology Processing Identify API relationship Classify the tokens Feature Model for Abstraction Layer Accesses Abstraction Layer Modularity API Generator APIs for Abstraction Layer APIs of Underlying Resources Traceability Link Domain Feature Model 9

10. Feature Model of Abstraction Layer 10 datatype VariableName::PackageName:APIName ReturnType APIName:: PackageName

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

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 13

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 14

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

16. Support by NSF CAREER. 16