think in UmL(三)

在实践中思考！

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

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

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

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

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

系统设计：系统分析与系统设计的差别、护色剂模型、接口设计、包设计。如果系统中的许多功能具备相似的实现模式，则没有必要逐一的建立设计模型，一个经典的设计模型就可以起到知道开发的作用。而对于复杂的、特殊的功能，则应当建立设计模型。这样做的好处是借由分解模型高于实现的稳定性，大大节省了维护量。同时给程序以学习和提高的机会。

自顶向下原则避免平行化无层次分包；职能集中原则是尽量将于一组业务功能有关的类分在同一个包里，否则就会出现职责不清的问题；互不交叉原则就是包与包之间尽量独立，不要让他们产生相互依赖关系。

开发：生成代码、分工策略。纵向分工策略是指一位开发人员负责将某项业务功能从软件架构层次的最高层一直实现到最底层的分工策略，实际上是以拥立为基础的分工策略，开发人员每人负责几个系统用例的实现。软件过程清晰自然，有利于开发计划制定，工作效率相对较高，不利于软件长期演进战略实施，培训成本高，对软件框架和规范的要求高，资源利用率底。横向分工策略是指我们获得基于用例的工作量估计以后，并不是以用例为工作包进行计划编制和资源指派，而是以软件架构层次为基础，重新估算每个软件构架层次上的工作量，并将开发资源指派到每个层次上去。适合于软件的长期演进，培训成本较小，资源利用率较高，失去用例驱动的清晰性，项目计划制定相对困难，项目沟通压力大。

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

好的程序不仅好用还好维护，可塑性好，这就需要我们做好每一步。