[logseq-plugin-git:commit] 2025-06-11T07:37:02.480Z

2025-06-11 09:37:03 +02:00
parent df9cc48418
commit 68fe3868f4
1 changed files with 13 additions and 0 deletions
@@ -11,5 +11,18 @@ boox-notes:: ![BOOX Notes](../assets/../../onyx/TabUltraCPro/Notepad/JOURNALING.
 					- 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.
+							-
+							-
 				-
 			-