1 / 16

Ontology Support for Abstraction Layer Modularization

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.

nuru
Télécharger la présentation

Ontology Support for Abstraction Layer Modularization

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Ontology Support forAbstraction 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.

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

  3. Java Virtual Machine Applets and Applications Java Base Platform Java Base API Java Standard Extension API Java Base Classes Java Standard Extension Classes Java Virtual Machine Porting Interface Adapter Adapter Adapter Browser JavaOS OS OS OS Hardware Hardware Hardware Hardware Network Java on a Smaller OS Java on a JavaOS Java on a Desktop OS Java on a Browser Examples of the Abstraction Layer

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

  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 APIs of Underlying Resources Accesses Abstraction Layer Modularity APIs for Abstraction Layer Traceability Link

  10. Feature Model of Abstraction Layer 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

  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.

More Related