《大象 Thinking in UML》学习笔记（十）——需求分析

版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/bit_kaki/article/details/79850657 一、关键概念分析
关键概念是指支撑起客户整个业务架构的那条主线，在UML方法里，就是由一些关键的业务用例构成。
需求分析就是要找到这些关键的业务用例，并且对它们进行分析，建立概念模型，依据概念模型搭建业务架构，然后为了验证这个架构或者进行技术可行性分析开发出系统原型。

概念模型始于业务用例，是针对需求中的关键业务，或者说业务核心来建立的。
概念模型是需求转入系统之间的桥梁。

获取概念用例
概念模型的构建是通过围绕业务主线，从业务用例当中挑选出一些业务用例进行关键概念分析。

当关键业务用例挑选出来之后，根据业务主线的需要，为这些业务用例找出概念用例。

分析概念用例
分析概念用例的过程也业务用例建模一样，仍然是绘制概念用例的场景图（活动图、时序图等），然后从中找到关键的对象，最后再为这些关键对象绘制一些协作图以说明这些对象之间的关系和交互场景。

建立概念模型
每分析清楚一个概念用例，就能得到它的关键对象。
关键对象都是一些实体对象，需要采用MVC模式进行分析，用这三个元素建立实现用例场景的对象模型。

每个概念模型表示一个功能，各个概念模型之间通过软件架构联系起来。

领域模型和概念模型
概念模型不一定针对业务，针对的是问题，这些问题可以与业务无关。
概念模型是只针对业务的，它要解决的问题从业务理解向系统理解转化之前，通过概念建模来在项目早起发现并解决问题。


二、业务架构
一个基本原则：技术服务于业务。
业务架构，实际上就是对需求细致分析和深刻理解的基础上，抽象出若干相对独立的业务模块，形成自洽的业务构件。
从概念模型入手，根据找到业务主线找到每个大的业务构件，再通过领域模型分解为小的构件,再根据概念模型找到各个小的构件之间的依赖关系。
每个业务构件的产生都来自于各类模型和场景，都是“功能点”的集合。
业务构件可以封装业务实体以及对业务实体的处理，也可以只封装处理逻辑。
业务架构是拼图单元的话，软件架构就是拼图的方法，可以说业务架构+软件架构=业务系统。

建模的价值，关于每种模型的价值，可以更深的感受下：

三、系统原型
抛弃型原型，就是当原型目的达到后，原型的使命也就结束了。主要用于验证核心业务的理解是否正确。
渐进型原型，从开发原型时，就考虑将来要在它基础上逐步完善，乃至形成最终系统。主要用于吧核心业务、业务架构和软件架构结合起来。 阅读更多