1 / 67

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

面向特征的领域建模技术 (Feature-Oriented Domain Modeling). 梅 宏 北京大学 信息科学技术学院软件研究所 高可信软件技术教育部重点实验室 2008 年 2 月 25 日－交通大学，新竹. 领域工程与应用工程. 主要内容. 主要问题 1 DRM 的结构 2 DRM 的建立 3 基于 DRM 的 ARM 的建立 4 基于 DRM 的 DSSA 的设计. Domain Analysis. Domain Design. DSSA. DRM. Requirements Analysis. ARM.

gelsey
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 面向特征的领域建模技术(Feature-Oriented Domain Modeling) 梅 宏 北京大学 信息科学技术学院软件研究所 高可信软件技术教育部重点实验室 2008年2月25日－交通大学，新竹

  2. 领域工程与应用工程

  3. 主要内容 • 主要问题 • 1 DRM的结构 • 2 DRM的建立 • 3 基于DRM的ARM的建立 • 4 基于DRM的DSSA的设计 Domain Analysis Domain Design DSSA DRM Requirements Analysis ARM

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

  5. DRM的结构 • 使用 特征模型 作为DRM • 基本思想 • 把 特征 作为问题空间的基本实体 • 使用 特征 以及 特征间的关系 刻画问题空间 Problem space Feature Relation between features Feature-oriented view of the problem space

  6. 特征 • 什么是特征？ • 从外延来看：一个特征描述了一种具有用户/客户价值的软件特点。 • 从内涵来看：一个特征是由一组紧密关联的单个需求构成的单元。

  7. Features The Constraint Views The Interaction Views The Refinement Views 特征模型 • 三种视图 记录了特征间的交互关系 记录了特征间的约束关系 FM 记录了特征间的精化关系 特征模型= 特征+ 关系(精化+ 约束+ 交互)

  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) • 精化 是一种存在于 不同 粒度/抽象层次 的特征之间的关系 • 不同 粒度/抽象层次 的特征 通过精化关系形成层次式的结构 • 层次结构提供了一种描述复杂系统的手段

  10. 三种精化关系 • 分解(Decomposition) • 把一个特征精化为一组作为其构成成分的子特征称为 分解 • 属性化(Characterization) • 识别出一个特征具有的属性型特征 称为 属性化 • 特殊化(Specialization) • 把一个特征精化为一个包含更多细节的特征 称为 特殊化

  11. 三种精化关系 • 简单示例 整体 编辑 Decomposition 部分 粘贴 删除 拷贝 实体 图元移动 Characterization 行为属性 移动模式 移动约束 Specialization Specialization 虚框移动 整体移动 水平约束 垂直约束

  12. 约束关系(Constraints) • 约束 是一种特征间的 静态依赖关系 • 更严格而言，约束是不同特征的绑定状态之间的依赖关系 • 约束提供了对特征模型的剪裁结果进行验证的手段 • 剪裁是对特征模型进行复用的手段 • 约束有助于验证剪裁结果的完整性和一致性

  13. 约束关系 • 几种不同类型的约束 • 二元约束(Binary Constraints) • 组约束(Group Constraints) • 绑定谓词(Binding Predicates) • 组合约束(Composite Constraints)

  14. 二元约束 • requires • mutual-requires • excludes requires(A, B: Feature) =def (A.Binding-State = bound)  (B.Binding-State = bound) mutual-requires(A, B: Feature) =def require(A, B) AND require (B, A) 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) requiresmultiple-bound(D, E)

  18. Basic Constraints: (require) (mutual require) (exclude) Group Constraints: (Mutex - Group) (None - Group) (All - Group) Binding Predicates: (single - bound) (multiple - bound) (all - bound) Composite Constraints: 图形化约束标记

  19. 图形化约束标记 • 简单示例 Constraints: Graphical Notation: A require E, C exclude F ， mutex - group (A, B, C), single - bound (A, B, C) require D.

  20. 交互关系 • 交互 是一种特征间的 动态依赖关系 • 交互 是 约束 在软件系统运行时刻的体现 • 交互提供了将各个相对独立的成分组装生成系统的手段 • 即：系统 = 构成成分 + 构成成分之间的交互 • 同时，关注交互和约束之间的追踪关系

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

  22. Invoke –调用 在每一个预先设置的时间点上尝试从预先设定的邮件服务器上收取邮件 尝试从预先设定的邮件服务器上收取邮件 定时邮件收取 invoke 邮件收取 邮件收取用例 invoke 当用户点击特定的UI构件时，尝试从预先设定的邮件服务器上收取邮件

  23. Meta-level configure –元层配置 这是一个运行时刻绑定的特征 Meta-level configure 定时邮件收取 配置器 定时邮件收取 根据用户的请求设定 定时邮件收取 的绑定状态，即在 bound 和 undecided 两个状态之间切换

  24. Read rules Write rules 过滤规则集合 <<资源容器>> Resource configure –资源配置 根据预先设定的过滤规则对收到的邮件进行过滤 根据用户的请求修改邮件过滤规则 邮件过滤配置器 邮件过滤器 Resource configure

  25. Notify –通知 • 对特征 A 和 B, “A notify B”表示: • A 向 B 发送一条消息，以指明某种条件已满足或某事件已发生。 Notify A B

  26. Flow –流 垃圾箱 邮件解密 邮件过滤 邮件收取 Flow Flow Put into 收件箱 Read rules 过滤规则集合

  27. 二元交互分类框架 • 二元交互中的角色 • Trigger • Triggee

  28. 二元交互分类框架 DIMENSION 1: Trigger是否于 Triggee 发生直接的交互. VALUES : Direct(直接), Indirect(间接). DIMENSION 2: Trigger和 Triggee是否存在如下的约束 requires (trigger, triggee). VALUES : Explicit(显式), Implicit(隐式).

  29. 二元交互分类框架 DIMENSION 1 invoke notify direct meta-level configure DIMENSION 2 implicit explicit resource configure flow indirect

  30. 领域需求模型(DRM)的建立 相关研究成果发表于 [COMPSAC03]. Domain related resource Domain Analysis DRM

  31. 几种具体类型的特征 • 功能 (Function) • 输入和输出之间的关系 • 行为特点 (Behavior Characteristic) • 对从输入到输出的变换过程的限制 • 服务 (Service) • 一组相关的功能以及行为特点构成的单元 • 用例 (Use-Case) • 用户和软件之间的交互序列 • 质量属性 (Quality) • 对软件的非功能性需求

  32. Service Layer Quality Section Use-Case Section Function Layer Behavior Characteristic Layer Constraint Section Interaction Section 一种更具体的特征模型

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

  34. 基于DRM的ARM的建立 相关研究成果发表于 [ICFEM04]. DRM The Reuse context Requirements Analysis ARM

  35. 基于DRM的ARM的建立 • ARM的生产过程是对 DRM进行复用的过程 • 这种复用是通过 定制 达到的 • 剪裁：从 DRM 中选择一组符合当前复用上下文的特征 • 扩充：把 特定于当前应用的需求 添加到剪裁后的DRM中 DRM The Reuse context Requirements Analysis ARM

  36. 基于DRM的ARM的建立 • 复用过程 在绑定时间1 做出的剪裁决策 DRM Partially-Customized Feature Model 1 在绑定时间2 做出的剪裁决策 Partially-Customized Feature Model 2 Customization 在绑定时间N 做出的剪裁决策 ARM Partially-Customized Feature Model N 在绑定时间N+1 做出的剪裁决策

  37. 剪裁决策 A Removed Feature 删除 An Undecided Feature A Bound Feature 绑定

  38. 基于DRM的ARM的建立 • 一个问题 • 目前的研究 缺乏对 非完全绑定的特征模型 进行验证的有效手段 • 后果 • 增加了定制过程的困难性 • 在当前绑定时间中做出的错误的剪裁决策得不到及时的检查，从而进一步向后续的绑定时间传播

  39. 对所有待绑定的特征至少存在一种绑定结果，其满足特征间的对所有待绑定的特征至少存在一种绑定结果，其满足特征间的 • 约束关系。 准则1 • 在不破坏特征间约束关系的前提下， • 每一个待绑定的特征都有被绑定的可能。 准则2 • 在不破坏特征间约束关系的前提下， • 每一个待绑定的特征都有被删除的可能。 准则3 三条验证准则

  40. I CRSet: I |= i=1,..., n Ci 准则1 • f UFSet, I CRSet: • I |= (i=1,..., n Ci ) (f.Binding-State = bound) 准则2 • f UFSet, I CRSet: • I |= (i=1,..., n Ci ) (f.Binding-State = removed) 准则3 三条验证准则

  41. 基于DRM的DSSA的设计 相关研究成果发表于 [MODELS05], [REJ06]

  42. A cluster of specifications Responsibility Operationalized into Assigned to Features Dependencies between Features Components Interactions between Components GAP (THE PROBLEM SPACE) (THE SOLUTION SPACE) 基于DRM的DSSA的设计 • 在设计阶段如何利用特征模型中的信息 • 我们的途径:

  43. 三个重要的层次 • 需求层 • 单个需求 被聚集成具有更大粒度的特征 • 一个特征包含了一组紧密关联的单个需求 • 规约层 • 规约 是对 需求的 操作化(Operationalization) • 软件开发人员按照规约去编写软件，从而满足需求 • 规约 被聚集成具有更大粒度的责任(Responsibility) • 一个责任包含了一组紧密关联的规约 • 实现层 • 该层中包含了预先编程实现的软件构件，使用这些构件能够快速实现特定的责任 • 称之为 基础设施构件

  44. 基于DRM的DSSA的设计

  45. Feature Interaction 1 Operationalized - into Direct - Interaction 1..* Resource Container Responsibility Direct - Interaction 基于DRM的DSSA的设计 • A：特征的操作化 • 每一个特征分别被操作化为 一组责任 以及 责任之间/责任与资源容器之间 的交互

  46. 基于DRM的DSSA的设计 • B：资源容器分析 • 从特征之间的间接交互中发现资源容器 • 资源容器往往是间接交互的特征之间的媒介 • 从特征的描述中发现资源容器 Feature Interaction Resource Container

  47. 基于DRM的DSSA的设计 • 通过 A.特征操作化 和 B.资源容器分析，特征以及特征之间的交互被转化为 责任、资源容器、以及 直接的交互 1..* Requirement Feature Interaction 1 The Requirement Level Operationalized The Specification Level - into Direct - Interaction 1..* Responsibility Resource Container Direct - Interaction

  48. 基于DRM的DSSA的设计 • C：种子构件创建 • 对于每一个特征，在规约层上建立一个对应的实体，称为 种子构件 • 种子构件 解决了 构件的“原罪问题”，即：构件从哪里来 • 在后继活动中，将对种子构件进行进一步的合并，以获取更大粒度的构件 Feature 1 1 Component Seed

  49. 基于DRM的DSSA的设计 • D：责任分配 • 把 责任 分配到 种子构件 上 • 从这种意义上，特征构件 可以被视为 责任容器 • 根据责任分配的结果可以区分两种类型的责任 • 核心责任 (Core-Responsibility) • 附加责任 (Added-Responsibility) Added * Responsibility Core * Responsibility Component Seed Responsibility

  50. <<Feature>> A <<Feature>> B Operationalized into Operationalized into AR1 AR2 AR3 BR3 BR2 BR1 Assigned to Assigned to <<Component Seed>> AC <<Component Seed>> BC AR1 AR2 BR2 BR1 AR3 BR3 核心责任和附加责任 : Core-Responsibility : Added-Responsibility

More Related