首页> 外文OA文献 >Raising the Level of Abstraction in Behavioral Modeling, Programming Patterns and Transformations
【2h】

Raising the Level of Abstraction in Behavioral Modeling, Programming Patterns and Transformations

机译:在行为建模,编程模式和转换中提高抽象水平

摘要

Since the very beginning of software development there was an unstoppable demand for higher productivity, better quality and more complex software systems. If the problem to be solved by the software system has a high complexity, solving it will inevitably also be complex. This inherent complexity is often referred to as essential complexity. The way software is developed however also causes some complexity. Better software development processes and better software building techniques, for example (programming) languages, reduce this complexity. Lower expressiveness and less abstraction introduce unnecessary and avoidable challenges that is often referred to as accidental complexity.The goal of this work is to contribute to the reduction of accidental complexity of building software systems. Improvements on three different places in the development process are proposed:• Programming Patterns: properties and associations are typically accompanied with requirements restricting the values properties or objects an object can be associated with. Three different types of requirements are identified to facilitate the (re-)definition of requirements at different positions in the class hierarchy. Value Requirements restrict the values independent of the state of the object. State Requirements restrict allowed combinations of values of different properties and associations. Transition Requirements restrict transitions to new values in view of current values. A separation of concerns between the development of methods describing requirements and the methods describing the state changes is reached by encapsulating the description of the requirements in their own inspectors. A family of patterns describes how all methods describing the state and behavior of a property or association collaborate. Finally, a first step towards a language extension to avoid the technical code of the patterns is presented.• Behavioral Modeling: conceptual models introduce accidental complexity when they contain technical aspects in order to describe real-world facts. Such complexity is introduced by enforcing (“locking in”) decisions that should have been made in a later activity in the software development process. UML and OCL lack expressive constructs to reason about event occurrences, even more so when the historical aspect of such occurrences becomes important. This work presents a new operator, the #-operator, that allows analysts to treat events as first-class citizens. By assigning a property, that represents the execution time, to events, it becomes possible to model historical event information without the need to introduce irrelevant facts in the conceptual model. A conceptual model never describes the whole universe, but is always a description of a subset of real-world facts. The decision to model a given fact as an object or as an event depends on the selected subset of real-world facts. A guiding principle assists the analyst in his decision-making: if the lifetime of a fact is of importance then the fact should be modeled as an object. Otherwise, if the fact is instantaneous, the fact should be modeled as an event.• Transformations: generally, multiple languages are used during the development of a software system. Each language is formally defined by a metamodel. These metamodels serve as the basis to define transformations between the different models. Different metamodels mostly have common structural constructs and associated functionality: a framework offering constructs to build hierarchical composition structures is developed to avoid the need repeat this work over and over again. A distinction is made between parent/child relations to specify interdependencies and dependee/dependant relations to specify unidirectional dependencies. Next to these constructs, the framework offers a metamodel-independent transformation approach. The knowledge of how to transform concrete metamodel elements is decoupled from the managing algorithm. Developers of a transformation provide strategies to transform concrete model elements, while the framework is responsible for tasks as execution order, managing cross-model consistency, model validity,
机译:自软件开发之初以来,就一直存在对更高生产率,更高质量和更复杂软件系统的不可阻挡的需求。如果要由软件系统解决的问题具有很高的复杂性,则解决该问题不可避免地也将是复杂的。这种固有的复杂性通常称为基本复杂性。然而,软件的开发方式也引起一些复杂性。更好的软件开发流程和更好的软件构建技术(例如(编程)语言)可以降低这种复杂性。较低的表现力和较少的抽象性引入了不必要的和可避免的挑战,这些挑战通常被称为偶然复杂性。这项工作的目的是为降低构建软件系统的偶然复杂性做出贡献。提出了在开发过程中三个不同地方的改进:编程模式:属性和关联通常伴随有限制值的属性或对象可以与对象关联的要求。确定了三种不同类型的需求,以促进(重新)定义类层次结构中不同位置的需求。值要求限制了与对象状态无关的值。状态要求限制了不同属性和关联的值的允许组合。转换要求根据当前值将转换限制为新值。通过将需求的描述封装在自己的检查器中,可以将描述需求的方法的开发与描述状态变化的方法之间的关注点分离。模式族描述了描述属性或关联的状态和行为的所有方法如何协作。最后,提出了避免语言的技术代码的语言扩展的第一步。•行为建模:概念模型在包含技术方面以描述现实中的事实时会引入意外的复杂性。通过强制执行(“锁定”)本应在软件开发过程中的后续活动中做出的决策来引入这种复杂性。 UML和OCL缺乏用于解释事件发生的表达性构造,尤其是在此类事件的历史方面变得重要时,更是如此。这项工作提出了一个新的运算符#运算符,该运算符使分析人员可以将事件视为头等公民。通过为事件分配表示执行时间的属性,可以对历史事件信息进行建模,而无需在概念模型中引入无关紧要的事实。概念模型从不描述整个宇宙,而始终是对真实世界事实的子集的描述。将给定事实建模为对象还是事件的决定取决于实际事实的选定子集。指导原则可帮助分析师进行决策:如果事实的生命周期很重要,则应将事实建模为对象。否则,如果事实是瞬时的,则应将事实建模为事件。•转换:通常,在软件系统的开发过程中使用多种语言。每种语言都由元模型正式定义。这些元模型充当定义不同模型之间转换的基础。不同的元模型大多具有共同的结构构造和相关的功能:开发了一个提供构造分层结构结构的构造的框架,以避免需要一遍又一遍地重复此工作。在用于指定相互依赖关系的父子关系与用于指定单向依赖关系的受抚养人/受抚养人关系之间进行区分。除了这些构造,框架还提供了独立于元模型的转换方法。如何转换具体的元模型元素的知识与管理算法分离。转换的开发人员提供了转换具体模型元素的策略,而框架则负责执行顺序,管理跨模型一致性,模型有效性,

著录项

  • 作者

    Delanote Geert;

  • 作者单位
  • 年度 2014
  • 总页数
  • 原文格式 PDF
  • 正文语种 nl
  • 中图分类

相似文献

  • 外文文献
  • 中文文献
  • 专利

客服邮箱:kefu@zhangqiaokeyan.com

京公网安备:11010802029741号 ICP备案号:京ICP备15016152号-6 六维联合信息科技 (北京) 有限公司©版权所有
  • 客服微信

  • 服务号