ddiruscio/logseq
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
f8ba9351b2ec9bfbc4ea46134d02b2c65cfe7ece
logseq/pages/Missione STAF 2025.md
T

15 KiB
Raw Blame History

tags:: #todoist-task, STAF, ADMIN/MISSIONI, Attended Event 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

    • My first day at staf

      collapsed:: true

      • Modeling and LLMs in Continuous Software Engineering

        collapsed:: true
        • 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

      • Keynote at STAF 2025

      • 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? - Jordi Cabot at OOPSLE

        • 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
        • Slides: Could an LLM create a full Domain-Specific Language?
        • Questions collapsed:: true
          • 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.

        • There are some slides that can be interesting to shows during Preparazione Intervento PINKAMP #todoist-task #SERVICES/PINKAMP

        • Resources

      • Let's make abstraction engineering fun again! - A. Cicchetti - OOPSLE

        collapsed:: true
        • Ha fatto una presentazione su JJODEL di fatto, ma non mi ha fatto impazzire.

      • Wrap-up

        collapsed:: true
        • List of open problems
        • Are they solved?
        • Are you satisfied by existing solutions?
        • There will be post-proceedings on the event
          • We will get info via a call for papers
            • Kind of workshop report in a Dagshtul like format

    • Second day at STAF / SLE

      • Keynote at sle da Thorsten Berger (A new DSL textbook in town!)

        collapsed:: true
        • Abstract: collapsed:: true
          • DSLs are the ultimate abstraction in software engineering. While programming languages have – since the advent of computers – continuously increased their level of abstraction, they are still limited to the domain of computing, with their instances containing many technicalities. Unlike programming languages, DSLs reflect a given application domain, ideally abstracting away anything beyond it. Recognizing their strengths, the programming-language and the software-engineering community introduced many technologies for engineering DSLs. While well-polished widely-used DSLs have existed for a long time (e.g., SQL, regular expressions, HTML), language engineering technologies have made great progress over the last two decades, allowing developers who are not language or compiler experts to create their own DSL – in order to increase the level of automation for their projects.
        • Link:
        • Questions: collapsed:: true
          • I guess when you started writing the book chatgtp was not available yet. Do you think the book should be refine to incoroporate the adoption of LLMs for teaching purposes? During your talk you presentated guidelines, principles, exercises. How do you think LLMs can help students to improve their learning experience and then do you think a second edition of the book is mandatory at this point? #question
        • Some notes:
          • http://dsl.design book
          • DIfferent examples of DSLs have been shown by including in the discussion also teaching experiences, guidelines, and principles
            • Da verificare la metaclasse InstanceSpecification in UML che permette di modellare istanze di metaclassi allo stesso livello
          • Quality assurance of metamodels
            • Definition of metamodel consistency, parsimonious metamodels, etc.
          • Immagine WhatsApp 2025-06-12 ore 09.47.39_90e9dd50.jpg{:height 535, :width 524}
          • external vs internal DSL

      • LLM4SE Workshop

        collapsed:: true
Reference in New Issue View Git Blame Copy Permalink