新项目终于步入系统分析阶段了，经过了许多的业务用例分析，我们把需求、业务、业务处理流程基本理清，对项目要做什么事、能做什么事更有把握了。业务分析的初衷就是这样，如何把较复杂的系统需求把握清楚，把业务需求分门别类，让一个门外汉一看就知道这个系统能够做成什么事。
现在我们就要做系统分析，系统分析是对业务分析的细化、抽象、泛化等等的工作。下面针对“扒项目”的历程(一)：业务分析中，“查询A系统数据业务用例实现”这一业务用例实现来看看能提取出什么样的系统分析结果。
关键词：项目管理, 项目立项, Enterprise Architect, EA, 系统分析
摘要：新项目过来，面对已经完成的业务分析，如何从业务分析结果，来进一步完成系统分析，从而得到系统分析成果，这个能力是急需掌握的。系统分析的目的是这样，如何把一个较复杂的系统描述的清晰易懂，如何让一个新人来依着系统用例分析，就可以独立完成代码的编写工作，如何让业务逻辑、实现架构确定，让代码的逻辑控制在代码范围内。下面从一个简单的“查询A系统数据业务用例实现”开始，来介绍一个业务用例的系统分析过程。下图如有引用，请标明来源http://www.cnblogs.com/wgp13x/p/3838078.html。
下面是"查询A系统数据业务用例实现"的泳道图。若要从《需求规格说明书》开始得到它，请看
“扒项目”的历程一(业务分析)，业务分析流程 http://www.cnblogs.com/wgp13x/p/3824964.html。
图1-业务用例实现图
1、我们对应着本业务用例实现，新建了一个文件夹，命名为“查询A系统数据系统用例”，专门用于存放它派生出来的系统用例实现们，下面讲述派生的过程。
2、首先我们尝试一下“抽象”。查询A系统可能和查询B系统，步骤相当，我们可以把它们抽象成一种，叫作“查询本地系统”，通过“抽象”我们能得到下面的系统分析。
下面就是“查询本地系统”的系统用例实现图，它采用“交互图”的方式展现。我们把“交互”过程中涉及到的实例们抽象为四种类型“用户”、“控制”、“边界”、“实体”。我们可以看到，本系统用例实现涉及到一个“用户”：系统；两个“边界”：“索引服务”和“数据存储”，涉及到一个“控制”：“访问本地结构化数据处理”。
如果要得到查询结果，需要“系统”按规定提交查询请求，然后经过“访问本地结构化数据处理”处理，依次提交请求到“索引服务”和“数据存储”中，才能得到查询结果。
图2-查询本地系统系统用例实现图
3、然后就是不停的试探“细化”。在图1-业务用例实现图中，存在“显示查询A类数据界面”这一过程，我们觉得这一过程过于粗略，完全可以作为独立的系统用例进行分析，如此就得到了“显示查询A类数据界面”系统用例实现图。然后，我们可以进行进一步的“抽象”，“显示查询A类数据界面”和“显示查询B类数据界面”过程完全一致，所以我们把这个系统实现图更名为“显示查询本地系统数据界面”。
下面的就是“显示查询本地系统数据界面”的系统用例实现图。可以看到，它涉及的用户为“操作员”，边界有“客户端”，控制有“查询界面控制器”、“数据服务”，实体有“元数据对象”，采用的是MVC设计模式。它们之间通过函数调用或者消息通信的方式，来进行交互，这样一来实例之间的接口定义就很清晰了。
图3-显示查询本地系统数据界面系统用例实现图
我们把“查询数据库”这一过程也拿出来“细化”、系统分析了一番。系统分析可以涉及到具体的系统架构、代码使用框架、设计模式等如此具体化的实现技术，以至于你需要在系统用例实现图中将它清楚的描述出来。这一系统用例是如此的普遍，以至于我们把它移到新的文件夹下，Common下，Common下还放置了“数据入库”、“文件入库”等基本的系统用户实现图。
图4-查询数据库系统用例实现图
下面还有“显示查询结果界面”的系统用例实现，与以上大同小异，“交互图”便不再贴出。
如此一来，一个业务用例实现图可以通过种种手段，剖析成数个系统用例实现图，一个框架被填充入了一块块的肉，这个业务用例被描述得更加清楚了，甚至于代码实现、数据接口都可以基本确定。
我们做系统分析的初衷也是这样，如何把一个较复杂的系统描述的清晰易懂，如何让一个新人来依着系统用例分析，就可以独立完成代码的编写工作，如何让业务逻辑、实现架构确定，让代码的逻辑控制在代码范围内，这便是系统分析的目的。
在做系统分析的同时，数据存储的设计也在进行着。数据存储的设计过程也可以帮助我们认清项目的难度、梳理系统实现方式。
这真的是“大象”式的软件工程，如果有论述不到位、理解不准确的地方，希望读者能及时指出，谢谢。
来自王安琪(http://www.cnblogs.com/wgp13x/)
“扒项目”的历程(二)：系统分析