码迷,mamicode.com
首页 > 其他好文 > 详细

think in UmL(三)

时间:2015-10-30 22:58:05      阅读:302      评论:0      收藏:0      [点我收藏+]

标签:

   在实践中思考!

   在这一部分中,书中作者用实际的案例讲述了从一个个实际项目的可行性分析阶段倒是现阶段的整个过程,让我们奖赏部分学到的UML知识点在实践中的得到学习。

   当我们拿到一个项目的时候首先要做的就是“准备工作”。(1)了解问题领域:软件是一种工具,是用来辅助人们解决某一问题的。软件的价值就在于它能够符合问题领域的需要,并达到人们解决问题的期望。(2)做好涉众分析:在了解业务概况和业务目标以后,系统分析员最先要做的事情不是去了解业务的细节,而是发现与这个目标相关的人和物,在课堂上我们已经学习了上下文图,将系统看作一个黑匣子,列出与系统相关的人物、甚至是时间地点、其他系统等,其中的人即是系统的利益相关者。(3)规划业务范围:这是一个很重要的部分,必须要考虑到人力物力财力。(4)整理好你的思路(5)客户访谈技巧:获取需求困难的一大原因是沟通,当与客户沟通是最好是携带一个笔记本,随时记下客户的需求,必须要有反馈与确认的过程,以免造成不必要的损失。

   获取需求。(1)定义边界:如果不能决定好系统的业务范围,你的系统将无限制的扩大。(2)发现主角:只有那些直接与系统交互的涉众才能被成为主角,业务主角区别于参与者,不应当被过分的抽象化和虚拟化。(3)获取业务用例:对于系统来说,每一件事便是一个用例,每个业务用例都体现了业务主角的一个系统期望,而所有的这些期望则完成边界所代表的业务目标。(4)业务建模(5)领域建模(6)提炼业务规则:全局规则、内禀规则、分类业务规则、(7)获取非功能性需求:系统必须具有满足客户的工作所需的功能,要有一定的可靠性、安全性和可维护性,要保持可扩展的接口,要能与各种各样的旧系统、外部系统、易购系统打交道,客户总希望自己的系统是业界领先的不论是在技术上还是内容上,个性化。不过实际上,非功能需求也正是围绕着后四层次中提到的那些需求展开的。

   需求分析:关键建模分析、业务架构、系统原型。

   系统分析:确定系统用例、分析业务规则、用力实现、软件架构和框架、分析模型、组建模型、部署模型。

   系统设计:系统分析与系统设计的差别、护色剂模型、接口设计、包设计。

   开发:生成代码、分工策略。

   测试:质量保证——新世界需要稳健运行、设计和开发测试例。

   

think in UmL(三)

标签:

原文地址:http://www.cnblogs.com/xiangwo/p/4924542.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!