MétaCan
Menu
Back to cohort
Record W19581405

Developpement logiciel par transformation de modeles

2010· dissertation· en· W19581405 on OpenAlexaff
Ghizlane El Boussaidi

Bibliographic record

Venuenot available
Typedissertation
Languageen
FieldComputer Science
TopicAdvanced Software Engineering Methodologies
Canadian institutionsUniversité de Montréal
Fundersnot available
KeywordsComputer scienceSoftware engineeringArtifact (error)Software designArchitectural patternSoftware developmentEngineering design processContext (archaeology)Software design patternSoftware design descriptionSoftware development processSoftwareSystems engineeringEngineeringArtificial intelligenceProgramming language
DOInot available

Abstract

fetched live from OpenAlex

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 machine prediction

Teacher imitation

Not 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.

metaresearch head score (Codex)0.010
metaresearch head score (Gemma)0.023
Version: metacan-v3-hybrid-931329e0061cValidation status: machine_predicted_unvalidated
Candidate categoriesnone
Consensus categoriesnone
DomainCandidate signal: none · Consensus signal: none
Study designCandidate signal: Theoretical or conceptual · Consensus signal: Theoretical or conceptual
GenreCandidate signal: Methods · Consensus signal: Methods
Teacher disagreement score0.051
Threshold uncertainty score0.110

Distilled classifier scores by category (both heads)

CategoryCodexGemma
Metaresearch0.0100.023
Meta-epidemiology (narrow)0.0050.003
Meta-epidemiology (broad)0.0030.011
Bibliometrics0.0060.004
Science and technology studies0.0030.010
Scholarly communication0.0150.012
Open science0.0040.005
Research integrity0.0070.022
Insufficient payload (model declined to judge)0.0120.005

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.

Opus teacher head0.031
GPT teacher head0.305
Teacher spread0.274 · how far apart the two teachers sit on this one work
Validation statusscore_only:v0-immature-baseline · verbatim from the scoring run: score_only means the number may rank works, and no category label ships from it

Classification

machine, unvalidated

Machine predicted; a candidate call from one source (direct Gemma or distilled Codex), not a consensus.

The models applied no category: nothing in the taxonomy fit this work.
Study designTheoretical or conceptual
Domainnot available
GenreMethods

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".

Quick stats

Citations0
Published2010
Admission routes1
Has abstractyes

Explore more

Same topicAdvanced Software Engineering MethodologiesFrench-language works237,207