一，面向方案的需求

  • 可以直接导出设计方案的需求

  • 定义系统需要实现的属性和特性(功能特点，操作)

  • 比目标、场景更详细。目标与场景不一定是所有涉众的共识，可能存在冲突；面向方案的需求已达成共识，冲突已解决.

    目标、场景与面向方案的需求比较

    面向方案的需求与目标、场景的关系

  • 面向方案的需求主要包括数据视图，功能视图，行为视图

    • 数据视图
      • 数据视图定义软件需要管理的数据/信息。主要描述数据的静态方面，包括实体，实体之间的关系，属性，与系统相关的属性类型等
      • 数据视图并不考虑对数据的操纵
      • 常使用实体关系图描述数据视图
    • 功能视图
      • 功能视图定义系统需要提供的处理过程(功能)、每一个处理过程中对于数据的操纵、处理过程之间的输入/输出关系(信息流)
      • 行为视图关注系统的总体行为，定义系统所接收的外部激励、系统的响应以及二者之间的关系。行为视图也描述系统可能的状态及状态之间的迁移。
      • 常使用数据流图描述功能视图。
    • 行为视图
      • 常用状态图描述行为视图。

二，领域模型的概念

  • 领域模型指问题领域中重要概念及其关联的集合。也称为概念模型。
  • 领域模型中的概念也称为问题域对象。领域模型也称为问题域对象模型。
  • 描述问题域中的“事物”或“产品”（即用名词表示的东西）
  • 领域模型可以在业务建模活动中产生，也可以从场景需求中提炼。
  • 领域模型 != 数据模型
  • 数据模型中，只包含需要持久保存的数据对象。但领域模型中可以存在需求中没有要求记录其相关信息的类，也不排除没有属性的概念类。
  • 领域模型澄清问题领域的名词术语和概念，促使开发者真正理解需求
  • 领域模型为下一步的设计打基础。设计模型中有一部分类直接从领域模型得到。这既提高了模型之间的可跟踪性，缩小了设计模型与领域的语义差别，又有利于提高效率。

三，领域模型的意义

  • 有利于理解问题领域中的有关概念、词汇和它们之间的关系
  • 设计模型中的软件类的名称要源于领域模型中的概念类的名称，
  • 设计模型中的类定义以及类和类之间的关联必须在理解领域模型后才能进行设计。
  • 领域模型是“可视化字典”，直观地表示了领域的重要抽象、领域词汇及其关联信息。

四，识别和记录领域对象

  • 识别领域对象的方法：

    • 方法1：重用和修改现有的模型。许多领域中都已存在已发布的甚至是绘制精细的领域模型或数据模型(这些数据模型可以修改为领域模型)
    • 方法2：使用概念分类列表，头脑风暴获得
    • 方法3：通过识别用例中的名词短语寻找概念类

  • 用例举例：

主成功场景（或基本流程）：

1. 顾客携带所购商品或服务到POS机付款处进行购买交易。
1. 收银员开始一次新的销售交易。
1. 收银员输入商品标识。
1. 系统逐条记录出售的商品项目,并显示 该商品的描述、价格和累计额.价格通过一组价格规则来计算。  收银员重复3—4步直到结束.
1. 系统显示总额和所计算的税金.
  1. 收银员告知顾客总额并提请付款数.
  2. 顾客支付，系统处理支付。
  3. 记录完整的销售信息,并将销售和支付信息发送到外部的账务系统（进行账务处理并计算提成）和库存系统（更新库存）。
  4. 系统打印票据.
  5. 顾客携带所购商品和票据（如果有）离开。

扩展（或替代流程）：……

7a.现金支付:

​ 1.收银员输入收取的现金额.

​ 2.系统显示找零金额,并弹出现金抽屉.

​ 3.收银员放入收取的现金,并给顾客找零.

​ 4.系统记录该次现金支付.

领域对象有： Sale(销售项)、Cashier(收银员)、CashPayment(现金支付)、Customer(顾客)、SalesLineItem(销售项条目)、Item(商品项)、Register(销售点终端)、ProductCatalog(产品目录)、 ProductDescription(产品规格说明)、 Store(商店)、Ledger(销售记录)

  • 记录领域对象的问题：

    • 适当地命名（领域对象是具体存在的事物或动作）
    • 添加属性（以需求为导向取舍，也可从用例出发寻找）
    • 分析相互间的关联（可能很复杂，但开始时可以少考虑，逐步深入）
    • 用图表示（UML中的类图）

五，领域模型举例

  • 建立领域模型的思路：

    • 根据用例描述识别领域对象
    • 识别对象的属性
    • 识别对象的关联
    • 画领域类图
    • 记录领域模型到词汇表中

领域类图

六，领域模型经验

  • 准则1：绘制类图的草图
  • 准则2：敏捷方法中，一般不需要使用CASE工具维护长周期的领域模型。
  • 准则3：一般不需要报表对象（其信息重复），要看业务中是否有特别用途。
  • 准则4：使用领域术语。地图绘制者总是使用地域现有名称标注地图。排除无关或超出范围的特性，不凭空增加事物。
  • 准则5：对非现实世界（抽象世界）建模时，使用该领域专家的核心词汇或概念。
  • 准则6：如果某概念X不是现实世界中的数字或文本，那么X可能是概念类而不是属性。
  • 准则7：使用描述类表示事物（商品、零件、服务等）的属性。而业务项目中，不用重复包含事物属性。

重点！！！

  • 面向方案的需求是目标和场景描述的进一步细化，将作为设计的主要输入
  • 与目标、场景需求不同，面向方案的需求已解决冲突，描述更多细节
  • 面向对象的方法所对应的面向方案的需求文档主要有领域模型、系统顺序图、操作契约等。
  • 领域模型重点掌握概念，领域对象的识别，领域对象的描述和表示。