首页 诗词 字典 板报 句子 名言 友答 励志 学校 网站地图
当前位置: 首页 > 教程频道 > 软件管理 > 软件开发 >

用例兑现、用例场景和领域模型[1]【转】

2012-07-22 
用例实现、用例场景和领域模型[1]【转】? ? 上一篇说到我们经过初步的业务分析,得到了用户、业务用例以及业务

用例实现、用例场景和领域模型[1]【转】

? ? 上一篇说到我们经过初步的业务分析,得到了用户、业务用例以及业务场景模型。这三项工作成果形成了基本的需求框架,并圈定了业务范围。这时应当做一份基线。


??? 当然,第一份基线所包括的内容是非常粗的,要达到完整的需求说明还有更多工作要做。这一篇就来说说详细的需求过程和产出物,以及这些成果对需求的贡献。在开始之前,还是提醒读者下载实例,本文下面只会从实例中挑选很少一部分来说明,对照实例读者将能更好的理解。


??? 上一篇确定了业务用例,以及业务场景。该场景只描述了业务框架,接下来要对业务用例进行场景分析。用例场景分析要用到三种视图,业务用例实现视图、业务用例场景、业务实体模型(领域模型),每个业务用例还应当写一份用例文档,也称为用例规约(UseCase Specification)。若有非功能性需求,例如性能要求,吞吐量要求等,还应当写一份补充用例规约。用例规约将在下一篇描述。


??? 首先是业务用例实现视图。并非所有的业务用例都一定要最终在系统中实现,因此,这个视图的含义是表达由需求范围到系统范围的映射关系。这个视图没什么技巧,也可以省略,不过笔者建议不要省略。需求应当保持过程的连续和可追溯性,这是软件过程可控的重要保证。
针对每个业务用例实现,应当对用例的实现过程进行场景模拟。上一篇是业务场景,而用例实现既然已经谈到“实现”,则应当将计算机包括进来,从人-机交互的视角来模拟业务场景。这是概念模型的一种,表达用户的实际业务在计算机环境下是如何实现的,给用户一个初步印象,告诉他们将来他们将怎样来做业务。请注意,虽然计算机已经参与需求描述,但是要尽量避免使用计算机术语,因为这时的文档仍然属于需求文档,是要与用户交流的,太多的计算机术语会大大降低用户对需求的理解能力。霍金在写时间简史时曾经说过,在书中加入哪怕一个数学公式,都会让书的销量减半。业务用例场景是概念模型的一种,但不是概念模型的全部。概念模型本篇不打算讨论,简单说一下,概念模型主要包括业务架构和系统原型。

?
??? 用例场景有另一个重要意义,是帮助系统分析员发现和定义业务实体。业务实体一般来说就是调研时用户所提供的各类表单或报表,但在很多情况下,并非每一份表单就是一个业务实体,所有业务表单也不一定涵盖全了所有业务实体。很多系统分析员声称业务实体的发现过程是全凭经验的,到底有哪些业务实体,靠经验进行提取。笔者要说,经验固然重要,但经验有一个最大的缺陷---不能重复和验证。即,这些实体是怎么从业务中提取出来的?它们是怎样参与业务的?这些实体已经足够支持业务了吗?凭经验分析者无法通过文档将这个提取过程记录下来,而脑子里的东西是无法共享和传承的,越大的团队,越复杂的项目,尤其是横向结构的项目组结构下,这个缺陷越严重。很多人觉得用UML和RUP描述的需求总是一块块分离的,不知道是怎么出来的,觉得很乱,原因就在于此。实际上,RUP做需求,每一步都是可验证和回溯的。用例实现视图是一个例子,这里也是一个例子。?

热点排行