1.4 系统分析
1.4.1系统用例
业务需求是通过业务模型描述的，以业务用例场景和业务用例规约为主要文档，描述在现实中的业务是怎么样的。系统需求则是通过系统模型描述的，以系统用例和用例规约为主要文档，描述系统如何映射到现实中的业务。而从业务需求到系统需求的过程大概如下图演变。
从业务需求到系统需求演变图
1.4.1.1获取系统用例
系统用例从何而来？普遍的理解是从勾引我用例细化而来。然而这个细化过程缺很少有人说的清楚。从用例的含义来看，业务用例描述业务，而系统用例描述系统，显然二者目的也是不同的。含义不同，目的不同的两个东西，怎么回事细化关系呢？
实际上，从业务用例到系统用例，更适当的说法是抽象关系，或者是映射关系。可以说从业务用例中抽象出系统用例，也可以说把业务用例映射到系统用例。
抽取的方式其实类似概念用例。要找到系统用例，首先分析业务用例场景，从业务用例场景当中抽出那些可以在计算机当中实现的单元来。业务用例场景通常被描述为某某做什么，然后某某又做什么。。。。。。，而这些谁做什么就是系统用例的来源。
例如我们来分析下达入库指令的业务用例场景。
1、客服人员下达入库指令
这个备选用例可以用计算机来实现吗？应该是可以的。客服人员直接在计算机上填写下达入库指令并保存。所以可以列入系统用例。
2、收货主管月台预约
这个备选用例中收货主管需要制定月台预约计划，然后通知月台预约结果。所以这个可以列入系统用例中。
3、送货司机送货到仓库
这个送货应该是开车吧货物送到某个地方。属于人工行为。所以不能列入系统范围。
4、安排收货任务
收货主管需要在电脑中录入安排计划。打印收货小条这个是属于安排收货任务时要做的。所以打印收货小条可以包含在安排收货任务中。
5、送货司机送货到指定月台
这个应该也是个人工行为。所不属于系统范围。
6、收货员到货查验
收货员到后查看货物的是否完好，这个是人用眼睛在看的。所以是人工行为。不属于系统范围。
7、收货员到货登记
收货员将验收后的货物登记到系统中。这个是属于系统范围的。
其他的例子不在描述。我们通过上述的方式分析抽象得到我们的系统用例。
系统用例
归纳：
经过以上几个实例分析，可以看出从业务用例场景当中抽象出备选的系统用例，并且判断这些备选的系统用例是否应当被纳入系统的基本方法。具体的来说这些方法包括：
映射:备选用例不加修改直接采纳为系统用例。
抽象：不能直接作为系统用例，需要进行写抽象，找到备选用例在计算机当中正在要做的的事情。
合并：备选用例不具备独立性时，必然是其他某个时间的组成部分。例如打印收货小条是安排收货任务的部分，因此被合并到安排收货中。
拆分：有时候业务用例场景中一个备选用例粒度很大，在这个备选用例当中包含几件事情，就需要进行拆分。系统用例应当只描述一次完整的计算机交互过程。
演绎：有时候会遇到业务用例场景当中找不到的备选用例，或者备选用例看上去并不合适用计算机来实现的时候。但是我们能预见某个可能的系统用例潜伏在这个场景中，我们就需要使用演绎法将它找出来。
1.4.1.2系统用例描述
描述系统用例的方法和描述业务用例的方法如出一辙，描述系统用例的过程，也就是系统建模过程。对比业务建模过程，系统建模所采用的工具仍然是用例场景、用例规约、对象模型、用例实现、用例事项场景。
与业务建模不同的是，我们的视觉和建模目的已经从原来的描述业务、理解业务便成理解系统、描述系统。两者的差别在于引入了计算机。之前描述的是原来的业务是什么样的，工作人员怎样完成业务，而现在应该变成计算机怎么做，工作人员怎么操作计算机。
我们选取下达入库指令为例子来讲解如何描述系统用例。
下达入库指令系统用例活动图
- 客服人员需要创建入库指令，计算机则展示入库指令录入界面；
- 客服人员录入客户资料，计算机校验客户信息，查询信用记录；
1) 如果有不良记录，则异常终止； - 客服人员录入其他指令并提交，计算机则校验指令并生成指令接着启动月台愉悦环节并结束。
1) 如果指令校验错误，客服人员在修改提交指令信息。
1.4.1.3状态图
状态图显示一个状态机。状态机用于对模型元素的动态行为进行建模，更具体的说，就是对系统行为中受事件驱动的方面进行建模。通常使用状态图来说明业务角色或者业务实体可能的状态—-导致状态转换的事件和状态转换引起的操作。状态图常常会简化对类的设计的确认。对于类的对象所有可能的状态，状态图都显示它可能接收的消息、将执行的操作和再次之后类的对象所处的转态。
例如我们图书馆的图书。刚采购回来是我们的图书状态是：购入状态。接着工作人员会建将图书编辑入册此时图书的状态转移为：待借状态。接着学生们可以发生借书的行为，图书的状态跟着修改为:借出状态。学生们将书本归还后则图书状态有变为:检查状态。如果无损坏也没有过期则再次被列入待借目录状态变为：待借状态，而如果有损坏或者过期行为则图书状态变为：废弃状态，然后结束。
状态图
1.4.2系统用户
ps：在1.4.2系统用户分析完毕后直接跳过1.4.3小节，进入到第二章节。
在下达入库指令的系统用例中，我们得到的就不单单是原先的客服人员，还有收货主管、收货员以及叉车驾驶员。这里的用户就是将来会直接操作系统的角色。
系统用户图
1.4.3系统用例实现
1.4.3.1用例和用例实现关系
在前面的学习已知，所谓用例实现就是用例的实现方式。用例只描述了系统应该做什么，是系统需求，是一个设想。用例实现的目的就是实现系统需求，将设想变为实现。我们采用的是面向对象的方法，要将设想变为现实，就要用对象之间的交互来实现设想。有了对象，我们就距离可运行系统更近一步了。
一个用例可能有多种实现方式，每个用例实现都是设想的一种实现方式，虽然实现方式和过程不同，但是目的相同。都是为了达到用例所规定的系统目标。为了表示出用例实现和她所实现用例的关系，可以用下图来表示实现到需求之间的追溯关系。
用例和用例实现关系图
1.4.3.2用例实现
在用例确定来看系统需求之后就直接进入系统设计阶段，进行类设计、表设计等。但是深入想一下会发现用例和类似乎有一道沟，我们不知道类是在呢么被推倒出来的。
实际上，设计模式中的类是可以被推倒出来的。用例实现正式跨越从系统需求到设计模式之间的那倒桥梁。
用例场景和用例规约是我们实现用例的基础，而我们所采用的工具则是分析模型。分析模型是采用MVC模式，将用例场景中描述的业务分解为边界、控制和实体，用三个元素实现用例场景的对象模型。
用例实现建模需要经历三个步骤：
第一步，我们需要在用例场景中发现和定义实体对象。这些实体对象代表我们将要操作的业务数据。在用例场景中，每一个活动都是由动词+名次构成的，这些名次就是我们要寻找的实体。
第二步，需要用控制类来操作和处理实体对象中的数据。在初步实现用例时，我们可以简单的为每个实体对象增加一个控制对象。每个控制对象操作一个实体对象，它默认包含所有对该实体对象的处理逻辑。
第三步，我们需要用边界对象来构造接收外部指令的界面。边界对象负责接收来自系统外部的指令，并将指令传达给控制对象，控制对象根据指令执行相应的逻辑，然后将结果返回给边界对象。最后再有边界对象将结果展示给外部。
我们以下图下达入库指令业务场景为例。
下达入库指令系统用例活动图
为了找到我们所需要的分析类对象，我们来一步一步分析场景当中的活动。
创建新的入库指令
这是一条在系统外部发出的指令，我们需要使用边界对象来接收它。
展现入库指令录入界面
这是一段处理逻辑，我们需要用控制对象来处理它，并且将结果反映到边界对象。
录入客户资料
这是人工活动，客户资料看上去就是一个备选的实体对象。不过经过分析，它实际上是入库指令单实体对象。
校验客户信息，查询信用记录
这是一条业务规则。由业务规则管理器来处理它。
录入指令其他信息
这个和录入客户资料是一样的。
提交指令
这是一条在系统外部发出的指令，我们需要使用边界对象来接收它。
校验指令
这是一条内部逻辑，我们将在程序逻辑当中处理它，所以也是由控制对象来处理的。
生成指令
这是一段程序处理逻辑，我们需要用控制器对象来处理它。指令编号只是指令单号对象的一个属性，不作为单独的实体对象。另外生成指令中还包括保存指令单步骤，这是一段程序处理逻辑，我们需要用控制器对象来处理它。同时入库指令是一个合适的实体对象，封装了要处理的业务数据。
启动月台预约环节
这是一段程序处理逻辑，我们需要用控制器对象处理。
显示结果
这是一段程序处理逻辑，我们需要用控制器对象处理，并且将结果反映到边界对象。
根据以上分析我们将下达入库指令活动图场景实现出来，得到下图的时序图。
下达入库指令实现
1.4.3.3分析类图
至此，用例实现场景绘制完毕。在绘制过程中，我们得到一些关键对象以及这些关键对象的方法。接下来我们将这些关键对象集中在一个图里面，定义他们的关系，就得到了分析类图。
分析类
用边界对象、控制对象和实体对象实现场景后，我们就得到了分析类图。用分析对象实现用例场景过程实际上就是类的推导过程。现在，我们得到了初始的类以及关键的类方法，可以说已经从需求开始步入了系统设计。虽然这些类看上去还有些粗糙，但是他们的确已经完全脱离了需求视觉，进入系统视觉了。
这些类就是我们进行系统设计、建立设计模式的基础。在分析类和软件架构、软件框架的基础上，我们很容易得到设计类。
1.4.3.4关键方法描述
对于一些方法中的业务逻辑比较复杂的，可以考虑给单独的方法也绘制一个活动绘制图。在活动图的绘制时，活动图上面的不是角色了，而是具体的类。
例如下面是个主对象查询子对象的方法。其中主对象是CcTest06，子对象是CcTest06Detail。
