FCL: Automatically Detecting Structural Errors in Framework-Based Development
Bibliographic record
Abstract
Although they are intended to support and encourage reuse, object-oriented application frameworks are difficult to use. The architecture and implementation details of frameworks, because of their size and complexity, are rarely fully understood. Instead, faced with a framework problem, developers must somehow learn just enough about the parts of the framework required for their task and ask for assistance or muddle through using a trial-and-error approach. In many cases, they misuse the framework by not learning what the framework designer had in mind as the proper solution to their problem. This thesis investigates both the feasibility and the effectiveness of tools support for the problem: The idea is to formalize the patterns to which the code structure of the application should conform, and thereafter detect violations of such patterns with an automated checker program. To capture the know-how knowledge about frameworks use, we introduce the notion of framework constraints: framework constraints are rules that frameworks impose on the code of framework-based applications. The tool consists of a specification language and an associated checker. The specification language, FCL (Framework Constraints Language), is defined to formally specify framework constraints. The semantics of FCL is based on a first-order logic extended with set and sequence operations. Essentially, framework constraints can be regarded as framework-specific typing rules conveyed by FCL specifications and thus can be enforced by techniques analogous to those of conventional type checking. Several case studies have been conducted to evaluate the approach. These include a part of the MFC (Microsoft Foundation Classes) framework, the law of Demeter, Scott Meyers' C++ guidelines, and the Observer design pattern. Lessons in terms of both the strengths and the limitations of FCL are reported.
Fetched live from OpenAlex and de-inverted. Abstracts are not stored in this database: the inverted indexes are 8.6 GB of the frame’s 9.3 GB of text, and the host has 13 GB free.
How this classification was reachedexpand
Full frame machine prediction
Teacher imitationNot calibrated prevalence, not ground truth. Human validation pending. The Gemma side is a direct model label for every work in the frame, read from the title-only record. The Codex side is a classifier learned from the 10,348 direct Codex labels and calibrated to design-weighted sample rates; fields without enough sample support carry no Codex call. Candidate is the union of the two sides; consensus is their intersection. These outputs are machine_predicted_unvalidated and are not human labels.
Distilled classifier scores by category (both heads)
| Category | Codex | Gemma |
|---|---|---|
| Metaresearch | 0.010 | 0.049 |
| Meta-epidemiology (narrow) | 0.002 | 0.001 |
| Meta-epidemiology (broad) | 0.001 | 0.002 |
| Bibliometrics | 0.007 | 0.002 |
| Science and technology studies | 0.001 | 0.002 |
| Scholarly communication | 0.003 | 0.005 |
| Open science | 0.004 | 0.004 |
| Research integrity | 0.002 | 0.002 |
| Insufficient payload (model declined to judge) | 0.003 | 0.001 |
Machine scores (provisional)
The two teacher heads of the student model, read on this work. A score orders the frame for review; it never asserts a category, and the validation status ships verbatim with every row.
Baseline scores from an immature model (maturity gate not passed, 7 training rounds). Scores rank; they never assert a category.
score_only:v0-immature-baseline · verbatim from the scoring run: score_only means the number may rank works, and no category label ships from itClassification
machine, unvalidatedMachine predicted; a candidate call from one source (direct Gemma or distilled Codex), not a consensus.
How this classification was reached, model by model and score by score, is at the end of the page under "How this classification was reached".