第9章 软件自动化技术

1、第9章 软件自动化技术宁夏医科大学 杨德仁大纲 导言 软件配置 软件重用 软件产品线 *开源软件AndroMDA MDA自动化机制 MDA原理 MDA建模过程 MDA模型自动化技术：UML、MOF和QVT xUML - Executable UML导言 软件自动化包括两部分： 文档设计（模型建立）自动化。 程序设计自动化 软件设计自动化Software design automation进程 在软件研制过程中将仍由手工进行的某些阶段加以自动化的过程以及所采用的技术。 软件的研制由提出问题开始，经历需求定义，设计，实现和测试等阶段。这些阶段是一系列描述的演变，从最初的问题描述逐步精化，纸质能用某

2、一特定语言描述如何实现这一目标。 软件设计自动化旨在使这一转换过程自动化，使软件设计者以更自然，更高级的语言告诉计算机要做什么，而不必详细地规定如何去做。 利用软件自动设计工具，可以在设计过程中减少人为错误，提高目标软件的可靠性，并缩短软件研制的周期，节省人力资源。 导言 软件设计自动化的概念是逐渐发展变化的。 在计算机技术发展初期，编译程序是软件设计自动化的局部体现。 计算机辅助软件工程（CASE）技术的发展在实现软件设计自动化的道路上跨出了重要一步。 软件设计自动化的全面实现和实用化尚非短期能够达到。 JEE 框架代码的自动生成 ER图到数据库表的自动生成 软件配置 软件配置 软件配置项：

3、软件生存周期各个阶段活动的产物（artifacts），经审批后即为软件配置项。 软件配置项包括： 与合同、过程、计划和产品有关的文档和资料； 源代码、目标代码和可执行代码； 相关产品， 软件工具、库内的可重用软件、外购软件及顾客提供的软件等。软件重用 在软件开发中，基于新环境和功能要求，可以对以往成熟软件系统的局部修改和重组，保持整体稳定性，以适应新要求。这样的软件称为可重用软件。 据统计，开发新应用系统，40%60%的代码是重复以前类似系统的成分，重复比例有时甚至更高。 软件重用能节约软件开发成本，真正有效地提高软件生产效率。 软件重用 1968年NATO软件工程会议上提出可复用库的思想。

4、软件重用：利用事先建立好的软部件创建新软件系统的过程。 蕴含着软件重用： 系统地开发可重用的软部件：代码、分析、设计、测试数据、原型、计划、文档、模板和框架等等。 系统地使用这些软部件，作为模块，建立新系统。软件重用 重用方式 横向重用：指重用不同应用领域中的软件元素，例如数据结构、分类算法、人机界面构件等。标准函数库是典型和重用的原始的横向重用机制，标准函数库也是最常用的横向重用。 纵向重用：指在具有较多共性的应用领域之间进行软部品重用。 在截然不同的领域之间实施软件重用非常困难，潜力不大，所以纵向重用才广受瞩目，并成为软件重用技术的真正所在。 纵向重用活动的主要包括以下几个步骤： 首先进行

5、域分析。根据应用领域的特征及相似性预测软部件的可重用性。 然后进行软部品的开发。一旦确认了软部件的重用价值，即可进行开发并进行一般化，以便它们能够适应新的类似的应用领域。 最后，软部件及其文档即可进入软部品库，成为可供后续项目使用的可重用资源。软件重用技术 库函数 对象（类集成） 模板 设计模式 构件 构架 框架软件重用技术 模板 模板（模具）；如文档模板，网页模板等，利用模板可以快速建立软件产品。 模板把不变的封装在内部，对可能变化的部分提供了通用接口，由使用者来对这些接口进行设定或实现。 设计模式 不断重复发生的问题，该问题的解决方案的核心和解决方案实施的上下文。 设计模式命名一种技术，共

6、享一系列模式的开发者拥有共同的语言来描述他们的设计。 重用设计信息。 软件重用技术 构件构件 是抽象的系统特征单元，具有封装性和信息隐蔽，其功能由它的接口定义。 可以是原子的，也可以是复合的。因此它可以是函数，过程或对象类，也可以是更大规模的单元。一个子系统是包含其它构件的构件。 是可配置和共享的,这是基于构件开发的基石，且构件之间能相互提供服务。软件重用技术 构架构架 构架是与设计的同义理解，是系统原型或早期的实现。 构架是高层次的系统整体组织。 构架是关于特定技术如何合作组成一个特定系统的解释。软件重用技术 框架：框架：为软件搭建“架子”。 基于重用角度：介于构件和构架之间。 构件、框架和

7、构架之间区别在于：对重用的支持程度的不同： 构件是基础，是基于构件开发的最小单元。构件重用包括可重用构件的制作和利用可重用构件构造新构件或系统， 框架和构架包含多个构件。这些构件使用统一的框架（构架）接口，使得构造一个应用系统更为容易。 框架重用包括代码重用和分析设计重用，一个应用系统可能需要若干个框架的支撑，从这个意义上来说，框架也是“构件”，框架又是一类特定领域的构架。 构架重用不仅包括代码重用和分析设计重用，还有抽象层次更高的系统级重用。 框架和构架的重用层次更高，比构件更为抽象灵活，但也更难使用。软件重用形式 源代码模块或者类级重用，最基本的软件重用形式。 二进制形式的重用。如组件重用

8、。 组装式重用。比如：把好几个应用程序的功能集成在一起。例如，要建立个门户站，登陆用户既可以查询天气情况，又可以查看股市行情，还可以在线购物。这些功能由不同网络应用服务供应商提供，通过这种组装式重用，就可以非常容易地把上述功能都集成到新的门户站点中。 分析级别重用。 设计级别重用。 软件文档重用。软件产品线Software product lines 软件产品线 具有一组可管理的公共特性的软件密集性系统的合集，这些系统满足特定的市场需求或任务需求，并且按预定义的方式从一个公共的核心资产集开发得到。 如何提高生产的经济效益呢？ 首先每个产品都由来自公共资产库中的组件组成，然后按照预先定义的变化机

9、制，如参数化或继承，对这些组件进行必要的裁剪，添加任何必须的新组件，根据一个产品线范围内的公共架构来组装这些组件。 构建一个产品（系统）主要工作是组装和繁衍，而不是创造；主要的活动是集成而不是编程。每条软件产品线都有一个预先定义的指南或计划，用来定义确切的产品构建方法。 MDA原则：MDA建模过程及模型表示 BM：定义业务模型：做什么业务？用例图 分析BM的具体流程，得到活动图，其中用到和得到的数据表单就是业务对象（原始类图）可信息化部分就是系统用例（CIM），确认责任 探索CIM的逻辑实现机制，得到系统用例规范（叙述、文本，用例的逻辑实现）图示化系统用例规范，得到鲁棒图（PIM），用路径分流

10、责任(RDD) 从PIM得到PSM转换（RDD）: 基于鲁棒图，落实责任，得到序列图（为类分配方法）； 参考原型界面，序列图，进化类图; 基于类图，形成数据库表模式MDA模型自动转化技术 MDA标准 UML OCL MOF QVT 形式化机制？元模型示例：活动图NoImageNoImage OMG Unified Modeling Language (OMG UML) Version 2.5 2013年版本，831页One of the primary goals of UML is to advance the state of the industry by enabling object

11、 visual modeling tool interoperability. However, to enable meaningful exchange of model information between tools, agreement on semantics and syntax is required. UML meets the following requirements: A formal definition of a common MOF-based metamodel that specifies the abstract syntax of the UML. T

12、he abstract syntax defines the set of UML modeling concepts, their attributes and their relationships, as well as the rules for combining these concepts to construct partial or complete UML models. A detailed explanation of the semantics of each UML modeling concept. The semantics define, in a techn

13、ology-independent manner, how the UML concepts are to be realized by computers. A specification of the human-readable notation elements for representing the individual UML modeling concepts as well as rules for combining them into a variety of different diagram types corresponding to different aspec

14、ts of modeled systems. OMG Meta Object Facility (MOF) Core Specification Version 2.5 What is significant about MOF2 is that we have unified the modeling concepts in MOF2 and UML2 and reused a common metamodel in both the MOF2 and UML2 specifications. The major benefits of this approach include: Simp

15、ler rules for modeling metadata (just understand a subset of UML class modeling without any additional notations or modeling constructs). Various technology mappings from MOF (such as XMI, JMI, etc.) now also apply to a broader range of UML models including UML profiles. Broader tool support for met

16、amodeling (any UML modeling tool can be used to model metadata more easily). How Many Meta Layers? One of the sources of confusion in the OMG suite of standards is the perceived rigidness of a Four layered metamodel architecture that is referred to in various OMG specifications. Note that key modeli

17、ng concepts are Classifier and Instance or Class and Object, and the ability to navigate from an instance to its metaobject (its classifier). This fundamental concept can be used to handle any number of layers (sometimes referred to as metalevels). The MOF 2 Reflection interfaces allow traversal acr

18、oss any number of metalayers recursively. Note that most systems use a small MOF Core Specification, v2.0 9 number of levels (usually less than or equal to four). Example numbers of layers include 2 (generic reflective systems - Class/Object), 3 (relational database systems - SysTable/Table/Row), an

19、d 4 (UML 2 Infrastructure, UML 1.4, and MOF 1.4 specification - MOF/UML/User Model/User Object). MOF 1 and MOF 2 allow Meta Object Facility (MOF), v2.5 7 any number of layers greater than or equal to 2. MOF is designed as a four-layered architecture. It provides a meta-meta model at the top layer, c

20、alled the M3 layer. This M3-model is the language used by MOF to build metamodels, called M2-models. The most prominent example of a Layer 2 MOF model is the UML metamodel, the model that describes the UML itself. These M2-models describe elements of the M1-layer, and thus M1-models. These would be,

21、 for example, models written in UML. The last layer is the M0-layer or data layer. It is used to describe real-world objects. Beyond the M3-model, MOF describes the means to create and manipulate models and metamodels by defining CORBA interfaces that describe those operations. Because of the simila

22、rities between the MOF M3-model and UML structure models, MOF metamodels are usually modeled as UML class diagrams. A supporting standard of MOF is XMI, which defines an XML-based exchange format for models on the M3-, M2-, or M1-Layer. 为了描述某一特定的模型，需要描述组成该类模型的建模结构集，MOF能对建模结构进行描述。MOF的4层元建模架构提供一组建模元素以

23、及使用这些元素的规则： 实例层：信息是由我们希望描述的数据组成，这些数据通常是用户数据，主要职责是描述信息领域中的详细信息。 模型层：模型层是由元数据组成，元数据是描述信息层的数据，元数据的集合被称作为模型。模型层的主要职责是为描述信息层而定义的一种“抽象语言”(即没有具体语法或符号的语言)。信息层的数据，即用户数据，是模型层的一个实例。 元模型层：由元一元数据组成，元一元数据定义了元数据的结构和语义，元一元数据的集合被称作为元模型。元模型层的主要职责是为了描述模型层而定义的一种“抽象语言”，是对模型层的抽象。即模型层描述的内容通常要比元模型层描述的内容丰富、详细。模型是元模型的实例。数据词典

24、中的元数据是对数据模型的描述。 元元模型层：元元模型层是由元元数据的结构和语义的描述组成，这层的主要职责是为了描述元模型而定义的一种“抽象语言”。元元模型的定义要比元模型更加抽象、简洁。一个元元模型可以定义多个元模型，而每个元模型也可以与多个元元模型相关联。通常所说的相关联的元模型和元元模型共享同一个设计原理和构造，这也不是绝对的准则。每一层都需要维护自己设计的完整性。一个元模型是元元模型的一个实例。Metamodeling architecture MOF is a closed metamodeling architecture; it defines an M3-model, which

25、 conforms to itself. MOF allows a strict meta-modeling architecture; every model element on every layer is strictly in correspondence with a model element of the layer above. MOF only provides a means to define the structure, or abstract syntax of a language or of data. For defining metamodels, MOF

26、plays exactly the role that EBNF plays for defining programming language grammars. MOF is a Domain Specific Language (DSL) used to define metamodels, just as EBNF is a DSL for defining grammars. Similarly to EBNF, MOF could be defined in MOF. In short MOF uses the notion of MOF:Classes (not to be co

27、nfused with UML:Classes), as known from object orientation, to define concepts (model elements) on a metalayer. MOF may be used to define object-oriented metamodels (as UML for example) as well as non object-oriented metamodels (as a Petri net or a Web Service metamodel). As of May 2006, the OMG has

28、 defined two compliance points for MOF: In June 2006, a request for proposal was issued by OMG for a third variant, SMOF (Semantic MOF). The variant ECore that has been defined in the Eclipse Modeling Framework is more or less aligned on OMGs EMOF. Another related standard is OCL, which describes a

29、formal language that can be used to define model constraints in terms of predicate logic.EMOF Classes EMOF Data TypesEMOF Types The QVT specification depends on the following two OMG specifications: MOF 2.4.1 Core Specification: /spec/MOF/2.4.1/PDF OCL 2.4 Specification: http:/www.o

30、/spec/OCL/2.4/PDF The language dimension consists of the three named language levels: Core: The Core language includes the ability to insert black-box implementations via MOF operations as specified. Relations: The Relations language includes the ability to insert black-box implementations via

31、 MOF operations as specified. Operational: The Operational Mappings language. The Query, View, Transformation (QVT) is a specification. It defines a standard way to transform source models into target models by model transformation rules.It standardizes the model transformation by splitting model tr

32、ansformations into a two level architecture: a relations meta-model and a core meta-model. The relations meta model specifies, in a user-friendly way, a model transformation as a set of relations that must hold for a successful model transformation. It supports complex object pattern matching and ob

33、ject template creation. It creates trace classes and trace instances to record the transformation execution. The core meta-model is defined using minimal extensions to the essential MOF (EMOF) and Object Constraint Language (OCL). It defines a transformation as a set of mappings and defines trace cl

34、asses explicitly as MOF models. It also creates and deletes trace instances explicitly. Compared to the relations meta-model, its semantics can be defined more simply. The core model may be implemented directly or used as a reference for the semantics of relations models. The relations meta-model ca

35、n be mapped to the core meta-model, using the transformation language itself. The QVT specification has a hybrid declarative/imperative nature, with the declarative part being split into a two-level architecture. We start by explaining the two-level architecture of the declarative part, as it forms

36、the framework for the execution semantics of the imperative part. Two Level Declarative Architecture The declarative parts of this specification are structured into a two-layer architecture. The layers are: A user-friendly Relations metamodel and language that supports complex object pattern matchin

37、g and object template creation. Traces between model elements involved in a transformation are created implicitly. A Core metamodel and language defined using minimal extensions to EMOF and OCL. All trace classes are explicitly defined as MOF models, and trace instance creation and deletion is defin

38、ed in the same way as the creation and deletion of any other object. Relationships between QVT metamodels Relationships between QVT metamodels QVT defines three domain-specific languages, namely Relations, Core and Operational Mapping. The Relations and Core are declarative languages at two differen

39、t abstraction levels, the relations meta-model level and the core meta-model level. The Relations language has a textual and a graphical concrete syntax. The Core language is as powerful as the Relations language, though with simpler semantics. The Operational Mapping language is an imperative langu

40、age that extends both Relations and Core. Its syntax provides constructs commonly found in imperative languages, such as loops and conditions. It is able to define unidirectional transformations using the imperative approach. In addition, it can be used to complement relational transformations by im

41、plementing the relations with imperative operations.Relationships between QVT metamodels Imperative Implementations In addition to the declarative Relations and Core Languages that embody the same semantics at two different levels of abstraction, there are two mechanisms for invoking imperative impl

42、ementations of transformations from Relations or Core: one standard language, Operational Mappings, as well as non-standard Black-box MOF Operation implementations. Each relation defines a class that will be instantiated to trace between model elements being transformed, and it has a one-to-one mapp

43、ing to an Operation signature that the Operational Mapping or Black-box implements. Relationships between QVT metamodelsOperational Mappings Language This language is specified as a standard way of providing imperative implementations, which populate the same trace models as the Relations Language.

44、It provides OCL extensions with side effects that allow a more procedural style, and a concrete syntax that looks familiar to imperative programmers. Mappings Operations can be used to implement one or more Relations from a Relations specification when it is difficult to provide a purely declarative specification of how a Relation is to be populated. Mappings Operations invoking other Mappings Operations always involves a Relation for the purposes of creating a trace between model elements, but this can be implicit, and an entire transformation can be written i