面向特征的领域建模技术 (feature-oriented domain modeling)

1

面向特征的领域建模技术面向特征的领域建模技术(Feature-Oriented Domain Modeling)(Feature-Oriented Domain Modeling)

梅宏梅宏北京大学北京大学

信息科学技术学院软件研究所信息科学技术学院软件研究所高可信软件技术教育部重点实验室高可信软件技术教育部重点实验室

20082008 年年 22 月月 2525 日－交通大学，新竹日－交通大学，新竹

2

Domain Analysis

DRM

Domain Design

DSSA

Domain Implementation

Domain Components

Requirements Analysis

ARM

Software Design

ASSAComponents Composition

Application Specific

Implementation

ApplicationSpecific

Components

Application

Domain Engineering

Application Engineering

Components Adaptation

Adapted Components

DRM: Domain Requirements Model

ARM: Application Requirements Model

DSSA: Domain-Specific Software Architecture

ASSA: Application-Specific Software Architecture

领域工程与应用工程领域工程与应用工程

3

主要内容主要内容Domain Analysis

DRM

Domain Design

DSSA


ARM

• 主要问题– 1 DRM 的结构– 2 DRM 的建立– 3 基于 DRM 的 ARM 的建立– 4 基于 DRM 的 DSSA 的设计

4

领域需求模型领域需求模型 (DRM)(DRM) 的结构的结构相关研究成果发表于 [ICRE05], [REJ06], [SoSyM06] .

5

DRMDRM 的结构的结构• 使用特征模型作为 DRM• 基本思想

–把特征作为问题空间的基本实体–使用特征以及特征间的关系刻画问题空间

Problem space

Feature

Relation between features

Feature-oriented view of the problem space

6

特征特征• 什么是特征？

– 从外延来看：一个特征描述了一种具有用户 /客户价值的软件特点。

– 从内涵来看：一个特征是由一组紧密关联的单个需求构成的单元。

7

特征模型特征模型

FM

• 三种视图

Features

The Refinement Views

The C

onst

rain

t Vie

ws

The In

tera

ction V

iew

s

记录了特征间的精化关系

记录了特征间的交互关系记录了特征间的约束关系

特征模型 = 特征 + 关系 ( 精化 + 约束 + 交互 )

8

特征的属性特征的属性• 名称 (Name)

– 特征的助记符号• 描述 (Description)

– 对特征所指需求的详细叙述• 可选性 (Optionality)

– Optional; Mandatory• 绑定时间 (Binding-Time)

– Reuse-time, Compile-time, Install-time, Load-time, Run-time, …

• 绑定状态 (Binding-State)– Bound; Removed; Undecided

9

精化关系精化关系 (Refinements)(Refinements)

•精化是一种存在于不同粒度 /抽象层次的特征之间的关系–不同粒度 /抽象层次的特征通过精化关系形成层次式的结构

– 层次结构提供了一种描述复杂系统的手段

10

三种精化关系三种精化关系• 分解 (Decomposition)

–把一个特征精化为一组作为其构成成分的子特征称为分解

• 属性化 (Characterization)–识别出一个特征具有的属性型特征称为属性化

• 特殊化 (Specialization)–把一个特征精化为一个包含更多细节的特征称为特殊化

11

三种精化关系三种精化关系编辑

拷贝粘贴删除

图元移动

移动模式移动约束

虚框移动整体移动水平约束垂直约束

Decomposition

Characterization

Specialization Specialization

整体

部分

实体

行为属性

• 简单示例

12

约束关系约束关系 (Constraints)(Constraints)

• 约束是一种特征间的静态依赖关系– 更严格而言，约束是不同特征的绑定状态之间的依赖关系

• 约束提供了对特征模型的剪裁结果进行验证的手段– 剪裁是对特征模型进行复用的手段– 约束有助于验证剪裁结果的完整性和一致性

13

约束关系约束关系• 几种不同类型的约束

– 二元约束 (Binary Constraints)

– 组约束 (Group Constraints)

– 绑定谓词 (Binding Predicates)

– 组合约束 (Composite Constraints)

14

二元约束二元约束• requires

• mutual-requires

• excludes

mutual-requires(A, B: Feature) =def

require(A, B) AND require (B, A)

requires(A, B: Feature) =def

(A.Binding-State = bound) (B.Binding-State = bound)

excludes(A, B: Feature) =def

NOT ((A.Binding-State = bound) AND (B.Binding-State = bound))

15

组约束组约束• mutex-group

– 一组相互排斥的特征

• all-group– 一组相互依赖的特征

• none-group– 一组松散的特征

mutex-group(P: set Feature) =def A, B P : exclude(A, B)

all-group(P: set Feature) =def A, B P : mutual-require(A, B)

none-group(P: set Feature) =def TRUE

16

绑定谓词绑定谓词• single-bound

– 一组特征中只有一个特征处于绑定状态

• multiple-bound– 一组特征中有多个特征处于绑定状态

• all-bound– 一组特征全部处于绑定状态

single-bound(P: set Feature) =def

one A P : (A.Binding-State = bound)

multiple-bound(P: set Feature) =def

some A P : (A.Binding-State = bound)

all-bound(P: set Feature) =def

A P : (A.Binding-State = bound)

17

组合约束组合约束

multiple-bound

all-bound +

single-bound

multiple-bound

+ all-bound

single-bound

requires

mutual-requires

excludes

示例： single-bound(A, B, C) requires multiple-bound(D, E)

18

图形化约束标记图形化约束标记

(require) (mutual require) (exclude)

(single-bound) (multiple-bound) (all-bound)

Composite Constraints:

Basic Constraints:

Group Constraints:

Binding Predicates:

(Mutex-Group) (None-Group) (All-Group)

19

图形化约束标记图形化约束标记• 简单示例

Constraints:

A require E, C exclude F，mutex-group (A, B, C),single-bound(A, B, C) require D.

Graphical Notation:

20

交互关系交互关系•交互是一种特征间的动态依赖关系

–交互是约束在软件系统运行时刻的体现

–交互提供了将各个相对独立的成分组装生成系统的手段•即：系统 = 构成成分 + 构成成分之间的交互

•同时，关注交互和约束之间的追踪关系

21

几种特征之间的交互关系几种特征之间的交互关系• Invoke• Meta-level configure• Resource configure• Notify• Flow

22

Invoke – Invoke – 调用调用

定时邮件收取

邮件收取

邮件收取用例

invoke

invoke

尝试从预先设定的邮件服务器上收取邮件

当用户点击特定的 UI构件时，尝试从预先设定的邮件服务器上收取邮件

在每一个预先设置的时间点上尝试从预先设定的邮件服务器上收取邮件

23

Meta-level configure –Meta-level configure – 元层配置元层配置

定时邮件收取定时邮件收取配置器

Meta-level configure

根据用户的请求设定定时邮件收取的绑定状态，即在 bound 和 undecided 两个状态之间切换

这是一个运行时刻绑定的特征

24

Resource configure –Resource configure – 资源配置资源配置

邮件过滤器邮件过滤配置器Resource configure

根据预先设定的过滤规则对收到的邮件进行过滤

根据用户的请求修改邮件过滤规则

过滤规则集合

Read rulesWrite rules

<< 资源容器 >>

25

Notify –Notify – 通知通知•对特征 A 和 B, “A notify B” 表示 :

– A 向 B 发送一条消息，以指明某种条件已满足或某事件已发生。

A BNotify

26

Flow –Flow – 流流

邮件收取邮件解密邮件过滤

垃圾箱

收件箱

Flow Flow

过滤规则集合

Read rules

Put into

27

二元交互分类框架二元交互分类框架• 二元交互中的角色

– Trigger– Triggee

Trigger Interaction TriggeeA invoke B

A meta-level configure B

A resource configure B

A invoke B

A flow B

28

二元交互分类框架二元交互分类框架

DIMENSION 2: Trigger 和 Triggee 是否存在如下的约束requires (trigger, triggee).

VALUES : Explicit( 显式 ), Implicit( 隐式 ).

DIMENSION 1: Trigger 是否于 Triggee 发生直接的交互 . VALUES : Direct( 直接 ), Indirect( 间接 ).

29

二元交互分类框架二元交互分类框架

DIMENSION 2

DIMENSION 1

dir

ect

ind

irect

explicitimplicit

notify

invoke

resource configureflow

meta-level configure

30

领域需求模型领域需求模型 (DRM)(DRM) 的建立的建立

Domain Analysis

DRMDomain related resource

相关研究成果发表于 [COMPSAC03].

31

几种具体类型的特征几种具体类型的特征• 功能 (Function)

– 输入和输出之间的关系• 行为特点 (Behavior Characteristic)

– 对从输入到输出的变换过程的限制• 服务 (Service)

– 一组相关的功能以及行为特点构成的单元• 用例 (Use-Case)

– 用户和软件之间的交互序列• 质量属性 (Quality)

– 对软件的非功能性需求

32

一种更具体的特征模型一种更具体的特征模型

Behavior Characteristic Layer

Function Layer

Service Layer

QualitySection

Use-CaseSection

Interaction Section

Constraint Section

33

支持工具支持工具

实践应用：在与云南昆明 863 软件企业孵化器的合作中，在办公自动化和公路工程管理等领域中得到了成功的应用

34

基于基于 DRMDRM 的的 ARMARM 的建立的建立

DRM


ARM

The Reuse context

相关研究成果发表于 [ICFEM04].

35

基于基于 DRMDRM 的的 ARMARM 的建立的建立• ARM 的生产过程是对 DRM 进行复用的过程• 这种复用是通过定制达到的

– 剪裁：从 DRM 中选择一组符合当前复用上下文的特征– 扩充：把特定于当前应用的需求添加到剪裁后的 DRM 中

DRM


ARM

The Reuse context

36

基于基于 DRMDRM 的的 ARMARM 的建立的建立

DRM

ARM

Customization

Partially-Customized Feature Model 1

Partially-Customized Feature Model 2

Partially-Customized Feature Model N

在绑定时间 1 做出的剪裁决策

在绑定时间 2 做出的剪裁决策

• 复用过程

在绑定时间 N 做出的剪裁决策

在绑定时间 N+1 做出的剪裁决策

37

剪裁决策剪裁决策

An UndecidedFeature

A RemovedFeature

A BoundFeature

删除

绑定

38

基于基于 DRMDRM 的的 ARMARM 的建立的建立• 一个问题

– 目前的研究缺乏对非完全绑定的特征模型进行验证的有效手段

• 后果– 增加了定制过程的困难性

•在当前绑定时间中做出的错误的剪裁决策得不到及时的检查，从而进一步向后续的绑定时间传播

39

三条验证准则三条验证准则

对所有待绑定的特征至少存在一种绑定结果，其满足特征间的约束关系。

对所有待绑定的特征至少存在一种绑定结果，其满足特征间的约束关系。

准则准则11

在不破坏特征间约束关系的前提下，每一个待绑定的特征都有被绑定的可能。

在不破坏特征间约束关系的前提下，每一个待绑定的特征都有被绑定的可能。

准则准则22

在不破坏特征间约束关系的前提下，每一个待绑定的特征都有被删除的可能。

在不破坏特征间约束关系的前提下，每一个待绑定的特征都有被删除的可能。

准则准则33

40

三条验证准则三条验证准则

I CRSet: I |= i=1,..., n Ci I CRSet: I |= i=1,..., n Ci

准则准则11

f UFSet, I CRSet:

I |= ( i=1,..., n Ci ) (f.Binding-State = bound)

f UFSet, I CRSet:

I |= ( i=1,..., n Ci ) (f.Binding-State = bound)

准则准则22

f UFSet, I CRSet:

I |= ( i=1,..., n Ci ) (f.Binding-State = removed)

f UFSet, I CRSet:

I |= ( i=1,..., n Ci ) (f.Binding-State = removed)

准则准则33

41

基于基于 DRMDRM 的的 DSSADSSA 的设计的设计相关研究成果发表于 [MODELS05], [REJ06]

42

基于基于 DRMDRM 的的 DSSADSSA 的设计的设计

Responsibility

A cluster of specifications

• 在设计阶段如何利用特征模型中的信息• 我们的途径 :

Operationalized intoOperationalized into Assigned toAssigned to

Features

Dependencies between Features

Components

Interactions between ComponentsGAP

(THE PROBLEM SPACE) (THE SOLUTION SPACE)

43

三个重要的层次三个重要的层次• 需求层

– 单个需求被聚集成具有更大粒度的特征• 一个特征包含了一组紧密关联的单个需求

• 规约层– 规约是对需求的操作化 (Operationalization)

• 软件开发人员按照规约去编写软件，从而满足需求– 规约被聚集成具有更大粒度的责任 (Responsibility)

• 一个责任包含了一组紧密关联的规约• 实现层

– 该层中包含了预先编程实现的软件构件，使用这些构件能够快速实现特定的责任

– 称之为基础设施构件

44

基于基于 DRMDRM 的的 DSSADSSA 的设计的设计

Direct-I nteraction

Requirement1..*

Component SeedCore Responsibility

Added Responsibility

Responsibility

Conceptual Component

Resource Container

1..*

Op

era

tion

aliz

ed

-into

*

1

1

*

Direct-I nteraction

*

I nfrastructure Component

Depend-on

The Requirement Level

The Specification Level

The Implementation Level

*

Feature

Direct-I nteraction

I nteraction

Refinement

45

基于基于 DRMDRM 的的 DSSADSSA 的设计的设计• A ：特征的操作化

– 每一个特征分别被操作化为一组责任以及责任之间 /责任与资源容器之间的交互

Direct-Interaction

Interaction

Responsibility

1..*

Op

era

tion

alize

d-into

1

Feature

Resource Container

Direct-Interaction

46

基于基于 DRMDRM 的的 DSSADSSA 的设计的设计• B ：资源容器分析

– 从特征之间的间接交互中发现资源容器•资源容器往往是间接交互的特征之间的媒介

– 从特征的描述中发现资源容器

Interaction

Resource Container

Feature

47

基于基于 DRMDRM 的的 DSSADSSA 的设计的设计• 通过 A. 特征操作化和 B. 资源容器分析，特征以及特征之间的交互被转化为责任、资源容器、以及直接的交互

Direct-Interaction

Requirement1..*

Interaction

ResponsibilityResource Container

1..*

Op

era

tion

alize

d-into

1

Feature

Direct-Interaction

The Requirement Level

The Specification Level

48

基于基于 DRMDRM 的的 DSSADSSA 的设计的设计• C ：种子构件创建

– 对于每一个特征，在规约层上建立一个对应的实体，称为种子构件

– 种子构件解决了构件的“原罪问题”，即：构件从哪里来• 在后继活动中，将对种子构件进行进一步的合并，以获取更大粒度的构件

Component Seed

1

1

Feature

49

基于基于 DRMDRM 的的 DSSADSSA 的设计的设计• D ：责任分配

– 把责任分配到种子构件上• 从这种意义上，特征构件可以被视为责任容器

– 根据责任分配的结果可以区分两种类型的责任•核心责任 (Core-Responsibility)•附加责任 (Added-Responsibility)



Responsibility *

*

50

核心责任和附加责任核心责任和附加责任<<Feature>>

A<<Feature>>

B

<<Component Seed>>AC

<<Component Seed>>BC

AR1 AR2 AR3

Operationalized into

BR3 BR2 BR1

Operationalized into

AR1 AR2

AR3

Assigned to

BR2 BR1

BR3

Assigned to

: Core-Responsibility : Added-Responsibility

51

基于基于 DRMDRM 的的 DSSADSSA 的设计的设计• E ：概念构件分析

– 把种子构件 /资源容器聚集成更大粒度的单元，称为概念构件• 把具有较紧密联系的种子构件 /资源容器聚集成概念构件• 把具有相同相同交互上下文的种子构件聚集成概念构件

Direct-Interaction



Responsibility


Resource Container *

*

Direct-Interaction

*

*

Direct-Interaction

52

基于基于 DRMDRM 的的 DSSADSSA 的设计的设计• F ：基础设施构件分析

– 分析概念构件的实现上下文，发掘出对其实现有益的基础设施构件


Infrastructure Component

Depend-on

53

一个简单的示例一个简单的示例• 一个简单的文档编辑软件

– 特征 1 ： Save•将当前文档保存到磁盘上

– 特征 2 ： Copy•将当前文档中被选择的文字拷贝到粘贴板上

– 特征 3 ： Cut•将当前文档中被选择的文字剪切到粘贴板上

– 特征 4 ： Paste•将粘贴板上的文字粘贴到当前文档光标所在位置

– 特征 5 ： Un/Re-do•根据用户的请求，撤销 / 重做那些未被存盘的编辑操作

54

一个简单的示例一个简单的示例• 特征间的交互分析

<<Feature>>Save

<<Feature>>Copy

<<Feature>>Cut

<<Feature>>Paste

<<Feature>>Un/Re-do

Notify2

3

4

5

1

Resource configure

Resource configure

Resource configure

55

• 种子构件建立<<Component Seed>>

Save

<<Component Seed>>Copy

<<Component Seed>>Cut

<<Component Seed>>Paste

<<Component Seed>>Un/Re-do

2

3

4

5

1

56

• 特征操作化；资源容器分析；责任分配

<<Component Seed>>Save





Copy

Cut

Paste

Save

<<Resource Container>>Clipboard

2

3

4

5

1

6

: Core Responsibility : Added Responsibility

57

• 交互分析






Copy

Cut

Paste

Save


write

write

read

2

3

4

5

1

6


58

• 特征 Un/Re-do 的操作化；资源构件分析；责任分配






Copy

Cut

Paste

Save Inform Saved

Undo Redo

Clear URI

Record URI

Record URI

Record URI


write

write

read

<<Resource Container>>

Un/Re-do Info(URI)

2

3

4

5

1

6

7


59

• 交互分析






Copy

Cut

Paste

Save Inform Saved

Undo Redo

Clear URI


Un/Re-do Info(URI)

Record URI

Record URI

Record URI


inform

write

write

read

write

write

write

consume

consume

clear

2

3

4

5

1

6

7


60

• 概念构件分析






Copy

Cut

Paste

Save Inform Saved

Undo Redo

Clear URI


Un/Re-do Info(URI)

Record URI

Record URI

Record URI


inform

write

write

read

write

write

write

consume

consume

clear

2

3

4

5

1

6

7


61

• 概念构件及其之间的交互

<<Conceptual Component>>Clipboard


<<Conceptual Component>>Edit




<<Conceptual Component>>URI

<<Resource Container>>URI

<<Conceptual Component>>Save


<<Conceptual Component>>Un/Re-do


62

• 概念构件分析






Copy

Cut

Paste

Save Inform Saved

Undo Redo

Clear URI


Un/Re-do Info(URI)

Record URI

Record URI

Record URI


inform

write

write

read

write

write

write

consume

consume

clear

2

3

4

5

1

6

7


63

• 概念构件及其之间的交互

<<Conceptual Component>>Un/Re-do



<<Conceptual Component>>Edit








64

• 基础设施构件分析



<<Infrastructure Component>>Clipboard Component

(Provided by OS)

<<Conceptual Component>>URI


<<Infrastructure Component>>Stack Component(Provided by API)

Depend-on

Depend-on



<<Infrastructure Component>>I/O Component

(Provided by OS)

Depend-on

65

支持工具支持工具

下一阶段：基于责任的软件体系结构转换为 UML2.0 中的软件体系结构，从而实现与工业标准的兼容

特征的操作化视图

特征模型视图

责任到构件的分配视图

66

总结总结

67

总结总结A.使用特征模型组织需求以及需求之间

的关系；B.利用约束实现对需求的有效剪裁与复

用；C.利用特征到责任的操作化和责任的聚合实现从特征模型到软件体系结构的过渡；

面向特征的领域建模技术 (feature-oriented domain modeling)

Documents