4.4.5 补充约束
用例的**在于描述功能需求,但对于系统来说,还存在很多功能之外的东西。如本章开篇就提到的非功能需求。还有其他一些诸如数据项的定义、业务规则、设计约束等内容。本书中把它们统称为补充约束。因此在采用用例模型进���需求建模时也需要把这些补充约束记录到相应的文档中。根据不同的情况有以下两种处理策略。
·与特定用例相关的补充约束,作为该用例文档的一部分来描述。
·一些全局性的补充约束,单独形成一份独立的文档,如RUP中的“补充需求规约”
文档。
对于不同的项目而言,补充约束有不同的方面。本节**讲解以下四种补充约束的表示方法:数据需求、业务规则、非功能需求和设计约束。
1. 数据需求
数据需求是指与该用例相关的一些数据项的说明。数据需求类似于结构化方法中的数据模型,与之不同的是,数据需求只关注当前用例。
数据需求的描述方法比较灵活,可以采用叙述性的文字来描述,如“房间的状态可能有:空闲、已预订、占用”。也可以采用以下系统化的方法,如数据字典的方式来定义,如“注册信息一用户名十密码+E-mail+{电话)*”。有时候,当一个用例涉及的数据项很多而且比较复杂时,也可以采用实体关系图的方式进行系统的描述。
当然这些数据项往往与用例的事件流相关,如:某个事件流中的某一步会产生或使用这些数据项。此时,应该将这些数据项与事件流建立联系;可以对每个数据项进行编号,再在前面的事件流中记录这些编号,数据需求的编号可使用前缀“D-”(Data)来表示。详细的例子参见第4.4.7节中的案例。
2. 业务规则
业务规则是指与业务相关的业务逻辑和操作规则,这些逻辑和规则对系统实现有一定的影响。有三类业务规则,即事实、推理规则和约束。事实是指业务中普遍认可的规则,为保证用户和开发方的共识,可以将这类规则记录到用例文档中。推理规则是指业务中的一些逻辑推理方法。约束是指在业务推理中的一些限制条件。下面的例子分别说明了这三种业务规则。
事实:设备是资产的一种。
推理:如果过了计划中的交货日期,货物还没有送到,即为“未按时送货”。
约束:合同总金额不能超出买方的信用额度。
……