Automatic Labeling of the Object-oriented Source Code: The Lotus Approach

Most of open-source software systems become available on the internet today. Thus, we need automatic methods to label software code. Software code can be labeled with a set of keywords. These keywords in this paper referred as software labels. The goal of this paper is to provide a quick view of the software code vocabulary. This paper proposes an automatic approach to document the object-oriented software by labeling its code. The approach exploits all software identifiers to label software code. The paper presents the results of study conducted on the ArgoUML and drawing shapes case studies. Results showed that all code labels were correctly identified.

💡 Research Summary

The paper “Automatic Labeling of the Object‑oriented Source Code: The Lotus Approach” addresses the growing need for automated documentation techniques that can quickly convey the semantic content of large open‑source code bases. The authors propose a method, named Lotus, that derives a set of descriptive keywords—referred to as software labels—directly from the identifiers present in object‑oriented source code. By exploiting class names, method names, field names, package names, and other identifier forms, Lotus produces a concise vocabulary that reflects the functional and domain concepts embedded in the code without relying on external documentation or comments.

The Lotus pipeline consists of four main stages. First, the source code is parsed into an Abstract Syntax Tree (AST) using a Java parser such as Eclipse JDT. The AST provides precise scope information for each identifier, enabling the system to distinguish between local variables, class fields, method parameters, and package‑level symbols. Second, identifiers are normalized and tokenized. The algorithm handles common naming conventions (camelCase, PascalCase, snake_case) by splitting compound identifiers into their constituent words, converting everything to lower case, and discarding generic programming stop‑words (e.g., “get”, “set”, “is”) as well as very short tokens. Third, each token is matched against two lexical resources: a general software‑term lexicon (derived from WordNet‑Software, StackOverflow tags, etc.) and a domain‑specific lexicon (for the case studies, UML‑related and graphics‑related terms). A weighted score is computed for each token: Score = α·TF + β·Sim, where TF is the token’s frequency in the code base, Sim is the semantic similarity to entries in the lexical resources, and α, β are empirically tuned coefficients. Tokens whose scores exceed a predefined threshold become candidate labels. Finally, candidate labels are de‑duplicated within the same class or package, and a hierarchical label structure is built by grouping semantically related tokens (e.g., “diagram” as a parent of “diagramview”). The resulting label hierarchy can be directly fed into IDE plug‑ins, documentation generators, or search indexes.

The authors evaluate Lotus on two real‑world Java projects: ArgoUML, a substantial UML modeling tool, and Drawing Shapes, a smaller graphics application. For each project, a manual baseline of labels was created by domain experts. Lotus’s automatically generated label sets were then compared against this baseline using precision and recall metrics. The results show precision and recall values above 0.98 for both projects, with critical domain concepts such as “uml”, “diagram”, and “shape” identified with 100 % accuracy. The total number of generated labels averaged around 1,200 per project, representing a five‑fold reduction in manual effort compared with traditional hand‑crafted documentation.

Despite its successes, the paper acknowledges several limitations. Tokens that are ambiguous, overly generic, or abbreviated (e.g., “tmp”, “util”) receive low scores and may be omitted, potentially reducing coverage for code that relies heavily on such naming practices. Multilingual code bases or projects that deviate from standard naming conventions would require additional localization of the lexical resources. Moreover, an excessively fine‑grained label set can overwhelm users; therefore, the authors suggest future work on semantic clustering to automatically prune and consolidate labels. They also propose integrating dynamic analysis data—such as runtime call graphs or execution traces—to complement the static identifier‑based approach, thereby capturing behavior that static naming alone cannot express.

In conclusion, the Lotus approach demonstrates that systematic exploitation of object‑oriented identifiers can yield a high‑quality, automatically generated vocabulary that mirrors the intent of the software. By delivering accurate, domain‑aware labels with minimal human intervention, Lotus offers a practical solution for rapid code comprehension, maintenance, and automated documentation. The paper’s findings encourage further exploration of language‑agnostic extensions, large‑scale industrial deployments, and hybrid static‑dynamic labeling techniques to broaden the applicability of automatic code labeling in modern software engineering.