系统分析经验（一）系统功能结构图 VS 用例图

前提　　

　　本文中所讲的系统分析经验是以瀑布模型为前提，并以需求分析->系统架构->系统设计->编码实现->测试->验收部署->维护->终止维护的软件开发流程为基础的。

系统功能结构图

　　抽象与分解是结构化分析与设计中的核心，通过抽象，我们可以将拥有复杂功能的软件项目抽象成两个字：系统。然后再将系统逐层分解成子系统、子系统的功能模块、功能模块中的业务数据和业务方法，最终使得系统达到可以实现的程度。

　　虽然这种方法直观易懂且实用，但是我要说明的是，如果你采用面向对象的思想来进行系统的开发，那么使用系统功能结构图进行需求分析，我是不推荐的。发挥这种分析技术最优性能的思想是面向过程的思想，因为如果使用的是面向过程的思想，则系统功能结构一旦定下来，就意味着开发人员可以工作了。

　　还有一个问题是，使用这种方式，只能够得出系统拥有哪些功能以及系统的层次结构，但是却不能够得出谁需要哪些功能，这样就会导致分析人员分析出的一些功能，其实上用户并不需要，或者分析得并不准确。

　　例如，假设存在一个仅仅面向学生使用的教务系统，学生可能会使用它来查询自己的成绩、查看课程表、选课、选专业方向、浏览消息公告等。对于这样一个系统，你很难想象，系统分析师会分析出注册这么个功能来。如果读到这里，你还觉得没问题的话，可能是因为这种分析思想实在是太自然了吧，因为站在系统的角度，系统存在着用户，那么系统存在用户注册的功能是很正常的啊!但是，请尝试这样来考虑：

　　如果学生能够自己注册的话，那么一个学生可能会注册多个用户，又或者会有学生没有注册的情况，当然系统可以进行控制，不过作为学校来讲，学校有哪些学生都是固定了的，既然这样，完全可以让学校来进行统一的创建和发放用户账号，并确保数据的正确和完整。

用例图

　　紧接着上面讨论的教务系统，如果使用用例图来进行需求分析，就会变成这样：

  

　　从图2中可以明确得出系统有哪些参与者，以及每个参与者所能够使用的功能。或许看到这里，你可能会觉得只是功能的名字改变了而已，功能的数量还是不变嘛。

　　其实，按照图1的分析，系统最终会得出：用户注册和用户登陆这两个功能，然后一般系统管理员都会有对用户的CRUD操作，那么系统的功能就有6个。但是如果按照图2来进行分析，系统管理员的CRUD加上用户登陆，功能就只有5个，这时就会发现，系统除去了一个多余和重复的功能。（对于本系统而言）

应用时机

　　我觉得，两种方式都可以用在系统分析阶段，唯一不同的是，使用用例图来进行需求分析，当需求分析完毕后，使用系统功能结构图进行整理，这样可以方便系统架构师或系统设计师大致了解到系统有哪些功能以及系统功能的层次结构。

总结

　　一句话：最重要的是应用思想的时机。