Bibliographic record
Abstract
Software engineering researchers have long tried to understand the software process development to mechanize it or at least to codify its good practices. We identify two major approaches to characterize the process. The first approach—known as transformational—sees the process as a sequence of property-preserving transformations. This idea was recently adopted by the OMG’s model-driven architecture (MDA). The second approach consists in identifying and codifying proven solutions to recurring problems. Research on architectural styles, frameworks and design patterns are part of this approach. Our research recognizes the complementarity of these two approaches, in particular in the design step. Indeed within the model-driven development context, we view software design as the process of applying codified solution patterns to input models. Software design is typically defined in terms of architectural design and detailed design. Architectural design aims at organizing the software in modules or components that meet a set of non-functional requirements while detailed design is—in some way—concerned by the contents of the identified components. Architectural design relies on architectural styles which are principles of organization to optimize certain quality requirements, whereas detailed design relies on design patterns to assign responsibilities to classes. Both architectural styles and design patterns are design artifacts that encode proven solutions to recurring design problems. While these design artifacts are documented, the decision to apply them remains essentially manual. Besides, once a decision has been made to use a design artifact, there is no adequate support to apply it to existing models. As design patterns present an “easier” problem to solve, and because architectural styles implementation relies on design patterns, our strategy for addressing these issues was to try to solve the problem for design patterns first, and then tackle architectural styles. Hence, in this thesis, we propose an approach for representing and applying design patterns. Our approach is based on an explicit representation of the problems solved by design patterns. Indeed, and explicit representation of the problem solved by a pattern enables to: (1) better understand the pattern, (2) recognize the opportunity of applying the pattern by matching the representation of the problem against the models of the considered system, and (3) specify declaratively the application of the pattern as a transformation of an instance of the problem into an instance of the solution. To verify and validate the proposed approach, we used it to represent and apply several design patterns. We also conducted practical tests on models generated from open source systems. Keywords. Design patterns, Design problems, Pattern matching, Model marquing, Model transformation, Meta-modelling.
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 distilled prediction
Teacher imitationNot calibrated prevalence, not ground truth. Human validation pending. Learned from the 10,348 direct Codex labels and 10,348 direct Gemma labels. Candidate is the union of thresholded teacher heads; consensus is their intersection. These outputs are machine_predicted_unvalidated and are not human labels or direct frontier model labels.
Codex and Gemma teacher scores by category
| Category | Codex | Gemma |
|---|---|---|
| Metaresearch | 0.000 | 0.000 |
| Meta-epidemiology (narrow) | 0.000 | 0.000 |
| Meta-epidemiology (broad) | 0.000 | 0.000 |
| Bibliometrics | 0.000 | 0.000 |
| Science and technology studies | 0.000 | 0.000 |
| Scholarly communication | 0.000 | 0.000 |
| Open science | 0.001 | 0.000 |
| Research integrity | 0.000 | 0.000 |
| Insufficient payload (model declined to judge) | 0.000 | 0.000 |
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 teacher head, 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".