用例驱动设计 |
您所在的位置:网站首页 › 建立用例模型的步骤分为 › 用例驱动设计 |
用例驱动设计
引言1 需求获取1.1 前期准备1.2 获取业务1.3 提炼规则1.4 获取非功能需求
2 需求分析2.1 领域分析2.2 概念分析2.3 整理业务架构
3 系统分析3.1 发掘系统用例3.2 设计业务规则3.3 梳理系统用例实现3.4 设计系统架构
4 系统设计4.1 建立设计模型4.2 建立开发视图
5 编码实现6 测试交付总结升华
引言
用例驱动设计是一种有效的软件工程化设计的方法论之一。整个过程分为需求获取、需求分析、系统分析、系统设计、编码实现、测试交付五个阶段。每个阶段环环相扣,形成一个迭代周期。 1 需求获取整个需求获取阶段可以分为前期探索、获取业务、提炼规则、获取非功能需求四部分。 1.1 前期准备
最后,以领域包图去分类归档上面的视图。归类方法有按业务模块、按业务目标、业务过程、按业务部门等方式。此外,业务用例重业务而非实现、不应有计算机相关的专业术语;业务用例实现可以有计算机相关概念、但不能深入到计算机的内部逻辑。 1.3 提炼规则业务是说明系统能为用户做什么,而业务规则是说明用户希望系统怎么做。规则分为全局规则、交互规则和内禀规则。 全局规则 全局规则是对整个系统的约束性要求。需要输出到补充规约中。交互规则 交互规则是对业务用例的约束,需要输出到前面的业务用例规约报表中,其中的前置条件、后置条件和业务规则都属于交互规则。内禀规则 内禀规则是对业务对象的约束,例如员工管理系统中,员工电话号码必须为11位。需要输出到后面的业务对象描述文档中。 1.4 获取非功能需求非功能需求是指系统满足用户业务功能之外的特性,包括安全性、可靠性、互操作性、健壮性等。对每项非功能需求都需要输出非功能需求报表。 2 需求分析整个需求分析阶段可以分为领域分析、概念分析和建立业务架构三部分。领域分析和概念分析最终都通过分析模型输出最终的模型视图。 2.1 领域分析领域分析的目标是建立领域模型。更确切地说,就是定义合适的业务对象,使之满足前面的业务用例。 领域分析的方法论很多,最常见的领域分析步骤如下: 概念分析就是建立概念模型,为系统分析和设计提供铺垫。领域模型主要针对技术问题,而概念模型只针对业务。整个概念分析步骤如下: 前面业务用例模型解释了业务细节、领域模型为业务问题提供了解决方案、概念模型提供了业务骨架,而建立业务架构就是对需求深入分析,抽象出相对独立的业务模块、形成自洽的业务构件。 整理业务架构的方法没有统一,主要考验架构师的抽象思维和边界思维。不过一般都从概念模型入手。最终以组件图的方式输出核心业务架构视图。此外,还有必要以领域包图等方式去呈现每个业务组件包含的分析类。 3 系统分析需求分析以业务为中心分析并建立业务架构,那么系统分析阶段将围绕着系统为边界分析并建立系统架构,业务架构是拼图单元、系统架构就是拼图方法。整个系统分析阶段可以分为发掘系统用例、设计业务规则、梳理系统用例实现、设计系统架构四部分。 3.1 发掘系统用例
系统用例与业务用例不同的是,系统用例围绕着系统怎么实现业务的抽象过程、但不深入具体实现细节;而业务用例围绕着用户怎么完成业务、不涉及系统边界。 系统用例与业务用例实现相比,虽然业务用例实现场景中带有计算机术语、但不深入计算机怎么实现业务;但系统用例场景包含计算机怎么实现业务功能的抽象流程。 3.2 设计业务规则设计规则就是将系统中的共性规则抽取出来,通过抽象出统一的设计去拥抱需求变化。对全局规则、交互规则、内禀规则分层次进行设计,以设计类方式呈现。 全局规则 全局规则对整个系统均有效,交给工程师处理对系统的风险比较高,所以必须在系统分析阶段给出方案设计。例如,日志系统对于各个模块都需要使用,而且日志系统对日志的记录等级怎么划分、日志开关等等,都必须由系统分析阶段敲定。所有的全局规则以设计类方式输出全局规则设计视图,并对全局规则的所有操作都以对象时序图方式输出全局规则实现视图。交互规则 交互规则作用于系统用例场景,也需要在系统分析阶段设计出交互规则设计视图,并对交互规则的所有操作都以对象时序图方式输出交互规则实现视图。通常,还需要对所有的交付规则设计管理库,输出包括交互规则管理设计视图和交互规则管理实现视图。内禀规则 内部规则只作用于单个业务对象,影响的范围比较小,理论上可以由工程师自己搞定。例如前面的电话号码只有11位的内禀规则,当信息录入的时候,编码时对不是11位数字的电话号码输入给予提示!但是,个人认为架构师或资深工程师有必要提供规则引擎、或选择通用的规则匹配库,提供给开发人员降低开发成本。 3.3 梳理系统用例实现
整个系统设计阶段可以为建立设计模型、建立开发视图两部分。 4.1 建立设计模型
整个编码实现阶段可以分为约定开发规范、执行编码两阶段。 约定开发规范 约定开发规范是包括制定编码规范、约定开发语言、编译器版本、三方库版本、代码仓库管理等等。执行编码 由于前面已定义了明确的功能边界,所以开发过程中会并行开展,这个阶段需要以设计模型为参考编写功能实现,还需要编写模块单元测试。此外,有可能效率高的成员提前完成了功能、但依赖另一个成员负责的功能还未开发完成,这时还需要针对依赖的模块编写fake代码进行回环测试。 6 测试交付测试阶段以系统用例为基准,进行黑盒测试、直到最后所有的功能全部正常。这个过程中,会出现修改BUG的情况。因此,为了规避修正新问题引发之前已修复的问题再现,需要最后做一次全部功能的回归测试,且全部顺畅测试通过才可以正式对外交付。 总结无论是用例驱动,还是领域驱动,最终都需要建立架构模型,虽然起点不一样、但终点相同;领域驱动更强调以领域模型为中心去设计,而用例驱动需要以用例为中心去分析。 用例驱动更需要架构师的业务和系统分析能力很好。正所谓:遇到青铜,则造成面向功能实现;遇到王者,就能以架构高度实现。因为用例驱动更取决于架构师的个人能力、相对领域驱动没那么多经验可以借鉴,这也是很多公司采用领域驱动的原因。如果说领域驱动是借鉴和发扬积累的领域经验、而用例驱动是发明和探索新的领域经验。 对于一些没有成熟解决方案的领域,需要通过用例驱动迭代出领域模型。领域驱动的初步模型一般是用例驱动迭代而成的,即便是你一开始就是在领域驱动,那么你一定是站在公司或前辈积累下的成熟领域经验的肩上,第一个吃螃蟹的人一定是值得感谢的。 升华对于前面的六个过程,其实,在工程实践中可根据实际情况进行精简。以研发基础中间件为例: 需求获取 这一阶段除了前期准备之外,其他的步骤可以省去;分析阶段 可以将需求分析和系统分析两个阶段合二为一;系统设计 这一阶段,可以根据项目情况省去建立设计模型、只保留建立开发视图;编码测试 不用想,这两个阶段是必不可少。 |
今日新闻 |
点击排行 |
|
推荐新闻 |
图片新闻 |
|
专题文章 |
CopyRight 2018-2019 实验室设备网 版权所有 win10的实时保护怎么永久关闭 |