Files
logseq/pages/Missione STAF 2025.md
T

10 KiB

tags:: #todoist-task, STAF, ADMIN/MISSIONI, Attended Event, STAF date:: 09-06-2025 - 13:52 progress:: {{renderer :todomaster}}

  • Admin

    collapsed:: true
    • L'evento inizia il 10 di Giugno e termina il 13 collapsed:: true
      • ECMFA 10,11
      • SLE 12, 13
        • Il 13 fino alle 14:00
        • Potrei pensare di ripartire il 13 Giugno
        • Il 12 ci potrebbe essere il meeting del SC di SLE
        • Partieri il 10 e tornare il 13
    • image.png{:height 361, :width 252}
  • Notes

    • Keynote at STAF 2025

      collapsed:: true
      • Modeling and LLMs in Continuous Software Engineering

        • Anne Koziolek, Karlsruhe Institute of Technology Germany
        • Abstract:
          • The notion of continuous software engineering extends practices like continuous integration to view the entire software development lifecycle as a continuous, interconnected flow of activities. At the same time, recent advances in large language models (LLMs) have revolutionized the way machines process natural language—language that plays a central role throughout software engineering, from requirements elicitation and design discussions to documentation.
          • In this talk, I will outline a vision for the role of models in continuous software engineering, focusing particularly on their use in design activities. I will argue that models will remain central to software engineering, even in an era of AI-assisted development, and explore what future design assistants might look like. One key capability of such assistants will be the ability to establish and use trace links between artifacts. I will present recent results showing how LLMs, combined with heuristic techniques, can achieve high precision and recall in this task.
          • Looking ahead, I will share our vision for how model-driven techniques can support more agile development of cyber-physical systems, and our ideas how LLMs can contribute to realizing the long-standing goal of model consistency. Finally, time permitting, I will also reflect on the use of LLMs in navigating software engineering literature and research data.
        • Notes
          • Cost-efficient modeling
            • automated extrection of models from other artefacts
            • Automated model consistency to enable cost-efficient evolution
            • Natural language as one view of the system to be keto consistent
          • NoRBERT for Requirements classification 2020
          • Models in Continuous Software ENgineering
            • At the beginning the ideal process was the waterfall one. But it seems does not work proprely in most cases. Specifications and implementations are inevitably interwined. This because:
              • hierarchical intertwinement: high-level design decisions inform lower-level requirements
              • technical feasibility: non-feasible requirements are useless
              • validation: what you see is what you require.
            • Iterative planning then!
              • {{renderer :mermaid_68493348-7f45-4787-95d3-54066d1c01fd, 3}} collapsed:: true
                • graph LR
                      A[Learn] --> B[Plan]
                      B --> C[Build]
                      C --> A
                  
              • Agile manifesto, 2001
              • How to support cost-efficient modeling?
            • LLMs
    • A metascience study of the low-code scientific field - Jordi Cabot at STAF 2025 - ECMFA

      collapsed:: true
      • Can the low-code popularity to help the community grow?
        • Looking for win-win
      • lens.org has been used to collect articles
        • Nowadays there are more low-code papers than those using the MD* keywords
        • How can you be sure that arxiv papers are duplicates of papers published somewhere else? #question
      • Facts
        • Decline in the size of the modeling community
          • Low-code compensate that
          • Rebrand MODELS with Lowcode?
          • Becuase of the so different keywords like MDE/MDA/MBD/.,,, we look so fragmented
      • Majority of low-code papers are applications
    • An internal DSL for Graphical Modeling Tools Based on GLSP - Georg Hinkel - ECMFA

      collapsed:: true
      • Requirements of the language
        • GLSP- specific
          • Recurring concepts like layout information
        • Support for 1:n correspondences
        • Avoid separate graphical models #question This is similaro to Eugenia isn't it?
          • Source of complexity in existing editors
        • Metadata support
          • Editor wants to know possible targets of and edge statically
        • Integrated Protocols Support
      • Used the same technology as NMF Syncronizations
    • User-modeling in MDE - an SLR - ECMFA

      collapsed:: true
      • To facilitate the development of personalized applications
    • Who will create the languages of the Future? - OOPSLE

      collapsed:: true
      • Jordi Cabot
      • Abstract: Software is eating the world. Which means that we need good languages to write all this software. And, often, come up with “new” languages to be able to efficiently target new software domains and technologies. In this talk, we will explore the changing landscape of language engineering and discuss how Artificial Intelligence and low-code/no-code techniques can play a role in this future by helping in the definition, use, execution, and testing of new languages. Even empowering non-tech users to create their own language infrastructure. Maybe without them even realizing. https://conf.researchr.org/profile/staf-2025/jordicabot
      • Questions
        • Is there still the need for new DSLs?
        • Implicit or Explicit DSLs?
          • It depends on the ROI
        • Do I need to create the DSL myself?
          • Vibe coding !?!?
          • VIBE DSLing
            • vs VIDE Modeling
              • Instead of going from NL to code, aske LLMs to create a DSL for me and then use the DSL to develop applications with the generated DSL
          • Moody et al. "Phisics of notation"
        • PRD - Product Requirement Document
          • A Product Requirement Document (PRD) is a document that outlines the functional and non-functional requirements of a product that is being developed. It serves as a communication tool between the product team, stakeholders, and developers, guiding the development process and ensuring that all parties are aligned on the goals and specifications of the product. The PRD typically includes information such as user stories, features, technical specifications, constraints, and acceptance criteria. It is an essential document in the product development process, helping to ensure that the final product meets the needs and expectations of its users.
      • Resources
    • Let's make abstraction engineering fun again! - A. Cicchetto - OOPSLE