|
使用UML工具进行建模，是公认的需求分析的好方法。那它如何与我们实施GJB5000需要编写的软件研制任务书、需求规格说明结合呢？ 下面就是建模和编写软件任务书结合的建议。 使用UML可以建立业务模型、分析模型和设计模型。对于软件研制任务书来说，它所对应的模型应当是业务模型。 什么是业务模型？ 业务模型就是使用模型来反映用户在现实中的需求。我们可以把业务模型理解成用户需求的一种可视性更好、表达更清晰的表现形式。使用业务模型来表述用户需求，要比我们在软件研制任务书中只使用文字来表述，更清晰、准确，更容易与用户达成对需求的一致理解。 一个完整的业务模型包括以下一些内容：
我们在软件研制任务书中要描述功能需求、性能需求、接口需求，如果使用模型来描述，那么至少要使用到用例视图、用例场景、用例规约等内容（后面业务对象模型一般只针对关键业务才建立，而用例实现视图和实现场景与用例视图和场景只是所站的角度不同）。
我们在编写软件研制任务书的时候，会用一段简短的文字可概括软件的一个又一个功能需求。而对于每个功能需求，我们要给它划分边界，找出业务主角，给出用例视图。 用例视图是通过展现业务的主要参与者（或称业务主角）及其在业务中的主要操作（或称用例）来表述功能需求的。比如某供电系统的业务用例视图如下：
用例场景是用来描述该用例在该业务的实际过程中是如何做的。用例场景可以使用活动图、时序图或协作图来描述。 例如某供电系统的申请永久用电有低压用户和高压用户两种场景。如果用活动图来表示低压用户的场景，如下图所示： 如果用时序图来表示低压用户的场景，如下图所示： 如果用协作图来表示低压用户的场景，如下图所示： 这3种图的区别是：活动图强调的是角色的职责和活动，时序图强调的是时间顺序，协作图强调的是角色间的交互过程。编写时可以根据需要选择。
用例规约是用文字来描述业务用例场景，它通常包括用例名称、用例描述、执行者、前置条件、后置条件、主过程描述、分支过程描述、异常过程描述、业务规则、涉及的业务实体等内容。 某供电系统的用例规约如下图所示： 用例规约是对视图的有效补充，它包含了更多的信息，而且篇幅短小、井井有条。 总之，利用UML建立业务模型，并且将业务模型融入到软件研制任务书中，将会使得软件研制任务书表述更清晰，对用户需求确认也会有很大帮助。 这正是： 针对业务来建模，视图场景和规约 模型融入任务书，理解确认好处多 参考书目：大象：Thinking in UML（第二版），谭云杰，中国水利水电出版社 作者简介：王小双，长期从事GJB5000推广、实施、评价、改进的工作，创建《软件工程之思》微信公众号，一直在《软件工程之思》分享GJB5000、CMMI、软件工程的知识和感悟。现致力于GJB5000咨询以及软件过程改进、软件工程能力提升的研究工作。 |
|
|
