Implementing FOP Framework 2003. 11. 11. SNU. RTOSLAB. Jiyong Park

Contents New Features of FOP Framework Implementation Plan Modularize non object-oriented artifacts Modularize code scattered across multiple programs Implementation Plan Survey of AspectJ plug-in in eclipse

New Features of FOP Framework Simple system Single program written in OO language Complex system Non-OO language makefile, HTML, C, perl, … Multiple collaborating program kernel, bootloader, shell, libraries, … Realistic!!

Simple System Complex System single program class A class B class C class D feature X simple crosscut Simple System single program single program Advanced Crosscut class A class B makefile perl script feature X Complex System

Example of Advanced Crosscut (1) Event monitoring feature in Linux calls.h eventmon.c makefile process.c … .c logger.c test.c event monitoring feature Linux kernel test program logger daemon library library kernel logger daemon test sequence generating program

Example of Advanced Crosscut (2) XIP support If XIP is supported, then –X flag should be turned on when compiling an application simple crosscut applications C source C source C source makefile makefile makefile kernel advanced crosscut

Modularize Non Object-Oriented Artifacts

New Concept of Artifact Previous, a feature consists of fragments of class Now, a feature consists of fragments of artifact An artifact consists of fragments of contents Examples of artifact java class, C++ class, C module, makefile, perl script, manual page, HTML page, and arbitrary type of files Examples of contents attributes and method in class targets and actions in makefile functions in perl script paragraphs in manual page Non OO Artifacts

How to Modularize Non OO Artifacts (Previous Solution) Transform an artifact to an equivalent class file: myMake class myMake { void main { action A; action B; action C; } void common { action X; action Y; action Z; … main: common action A action B action C common action X action Y action Z …

How to Modularize Non OO Artifacts (Previous Solution) Feature A Feature B Result class myMake { void main { action A; action B; action C; } void common { action X; action Y; action Z; … class myMake { void main { action A; action B; } void common { action X; action Y; … class myMake { void main { action C; } void common { action Z; …

Limitations of Previous Solution There is no general conversion rule from arbitrary language to OO language We lose characteristics of source artifact ex. Cannot express dependency list file: myMake ??? class myMake { void main (common) { action A; action B; action C; } void common { action X; action Y; action Z; … main: common action A action B action C common action X action Y action Z … ???

Limitations of Previous Solution We lose characteristics of source artifact ex. Cannot express order file: myMake file: myMake file: myMake main: common action A action B action C common action X action Y action Z … main: common action A action C common action X action Z … main: common ???? common …

New Solution We lose characteristics of source artifact  Expose each type of artifacts to the feature (Do not convert to a class) There is no general conversion rule from arbitrary language to OO language  Provide a merging rule for each artifacts For each artifacts A UML structure for the artifact Merging rule specification

Merging Rule Specification Example: Makefile UML Structure Merging Rule Specification feature name … 1 merge (feature f1, f2) { makefile m1, m2; feature f3; for each m1 in f1 { for each m2 in f2 { if (m1.name = m2.name) put merge(m1, m2) to f3; else put m1, m2 to f3;} } return f3; merge (makefile m1, m2) { target t1, t2; makefile m3; for each t1 in m1 { for each t2 in m2 { if (t1.name = t2.name) put merge(t1, t2) to m3; else put t1, t2 to m3;} } return m3; * merge (makefile t1, t2) { action a1[], a2[]; target d1[], d2[]; makefile t3; put sort (a1 in t1, a2 in t2) to t3 put sort (d1 in t2, d2 in t2) to t3 return t3; } makefile name … 1 * depends target name … * <<ordered>> 1 * action action: String …

(a) Feature1 (b) Feature2 feature feature name = feature1 makefile makefile name = myMake name = myMake target target target target target name = main … name = common … name = clean … name = main … name = common2 … 1 2 depends 3 2 1 1 1 1 action action action action action action: compile X action: compile Y action: delete X action: compile A action: compile B (a) Feature1 (b) Feature2

(c) Feature3 = Figure1 U Figure2 makefile name = myMake target target target target name = main … name = common … name = clean … name = common2 … merge 1 2 3 2 1 1 1 1 action action action action action: compile X action: compile Y action: delete X action: compile B action action: compile A (c) Feature3 = Figure1 U Figure2

Example: Java Class, Plain Text feature feature name … name … 1 1 * * java_class plain_text name … name … 1 1 1 * * attribute method paragraph name type … name return type … name 1 1 <<ordered>> <<ordered>> * * code fragment sentence code: String … sentence: String

Sorting <<ordered>> Relationship Each <<ordered>> relationships are numbered unique ID ID = xxxxx.yyyyy ID is unique across a feature Sorted by xxxxx yyyyy is used to represent ‘replace’ ID management is done by tool.

feature X feature Y method M method M 2 4 5.1 1 3 5 7 code frag. A code frag.B code frag. C code frag.D code frag.E code frag. F code frag.G merge feature X U Y method M 1 2 3 4 5.1 7 code frag. A code frag.E code frag.B code frag. F code frag.G code frag.D code frag. C replaced

Modularize Code Scattered Across Multiple Programs

Concept Extension to feature Feature that contains features that are crosscutting individual programs. Each feature has information in which it is applied. feature name: String location: String belongs

Example directory feature Feature POSIX_thread feature / name = POSIX_thread location = / kernel libraries utilities thread … feature Pthread app X name = thread location = kernel thread … base feature name = thread location = libraries/pthread feature Feature POSIX_thread feature name = base location = utilities/app_X

(b) Feature POSIX_thread / / kernel libraries utilities kernel libraries utilities process scheduling filesystem libC interface signal … thread … C library shell Pthread app X stdlib string … base … thread … base (a) Feature lib_C (b) Feature POSIX_thread / kernel libraries utilities merge process scheduling filesystem libC interface signal thread … C library Pthread shell app X stdlib string … thread … base base (c) Feature lib_C U POSIX_thread

Implementation Plan

Architecture of The FOP Framework Viewer /Editor ???? ???? Views AFM (Abstract Feature Model) Merging Rule Model Merge Engine Structural Analyzer Builders Artifact Sources (.java, .c, makefile,…) Configs (.config) Feature Sources (.ftr) Artifact Meta Data (UML diagram, Merge rule) used Resources edits

Implementation Plan Core Framework Define feature, config, artifact meta data file format XML based Structural Analyzer Read and update resources Merge Engine Merge features Give information to viewer Viewer/Editor Integrated in IDE

Several Ways to Implement FOP Embed in existing IDE eclipse – Plug-in Development Environment is available JBuilder … Build a standalone framework

How AspectJ is Integrated with IDE

Future of AspectJ 7 year old technology Dynamic weaving Usage Previous, weaving .java files at compile-time Current, weaving .class files at link-time Future, weaving .class files at run-time Usage Mostly for distributed enterprise application AspectJ is mostly used for capturing logging, transaction, session management, …

Future Work Implementing FOP Framework Research Define resource files in XML (for .java) Define core API set Research Incremental adoption of FOP to existing works

AFM (Abstract Feature Model) Viewer /Editor Views AFM (Abstract Feature Model) Merging Rule Model Merge Engine Structural Analyzer Builders Artifact Sources (.java, .c, makefile,…) Configs (.config) Feature Sources (.ftr) Artifact Meta Data (UML diagram, Merge rule) Resources