1、用例视图

在需求分析将分为4个小节来说，分别是涉众分析、业务分析、概念分析以及系统分析。

涉众分析

1.1 涉众分析

1.1.1边界

1.1.1.1定义

边界是可大可小的，由建模者主观臆定。边界决定了视界，会导致你看到的东西是不同的。因而在收集需求和开发软件的过程中，为了更接近真相，我们需要不停的变换边界，改变视界，从更多的侧面去描述同个信息，以求最大程度的符合真实的需求。
边界是无形的。大到业务建模，小到接口设计都能发挥重要作用。学会灵活使用边界，用边界决定抽象层次和视角，进而排除边界外大量的杂音来降低复杂程度。

1.1.1.2边界图例子

下图是：客户服务边界。在此边界的业务目标是：为客户提供创新的定制服务。从这个边界来看，客户和收货人是在边界之外的。他们是业务主角。其他的涉众例如供应商、配送事业部、计划财务部、营销事业部和仓储事业部都是仓储运输的内部工作人员，位于边界以内，换句话说，他们是业务工人。

例如我们在看：内部管理边界。此时我们的业务目标是规范企业内部管理，提高企业工作效率和管理效能。此时的配送事业部、仓储事业部、计划财务部和营销事业部是在边界之外的。此时他们是这个边界的业务主角而非业务工人。

1.1.2涉众

1.1.2.1定义

在需求分析开始时候。我们会了解下需求相关的业务概况和业务目标。而在了解务概况和业务目标后，系统分析员最先要做的事情不是去了解业务的细节，而是去发现与这个目标相关的人和物。英文把这种人和物称为Stakeholder。有的资料翻译为干系人，有些测喜欢涉众这种翻译。本文档我们解释为涉众。
涉众是与要建设的业务相关的一切人和事。但是要注意一点，涉众不等于用户，通常意义上的用户是指系统的使用者，而这仅是涉众的一部分。

1.1.2.2涉众分析方法

此节点将分享一些对于大部分管理类软件中如何寻找软件项目的涉众的方法。
1、 业主:
业主是系统建设的出资方、投资者。大多数情况向业主就是系统的需求提出者和使用者，即业务方。一般业主关心的是建设成本、建设周期以及建成后的效益。虽然看上去与系统需求没什么大的关系，但是，建设成本、周期将直接影响你可以使用的技术，选用的软件架构，可以承受的系统范围。
2、 业务提出者：指业务范围、业务模式和业务规则的制定者，一般是业务方的高层人物。业务提出者的系统建设的最高纲领。
3、 业务管理者：指实际管理和监督业务执行的人员，一般是指中层干部，他们起到将业务提出者的一直付诸实施，并监督底层员工工作。一般是系统的主要用户之一。
4、 业务执行者：指底层的业务操作人员，是与计算机直接交互最多的人员。他们最关心的是系统给他们带来的方便性，会怎么样改变他们的工作模式。
5、 第三方：与业务相关但是非业务方的其他人或者事。例如购物网站系统，交易双方都是通过网上银行完成支付的，则网上银行就是一个涉众。
6、 承建方： 老板。
7、 相关的法律法规：国家或者地方法律法规。
8、 用户：用户是个抽象的概念，指预期的系统使用者。用户一般是上述涉众的代表。

1.1.2.3涉众分析报告

通过章节1.2的方法，系统分析员对项目范围内的涉众进行调查和访谈，形成涉众分析报告。
涉众概要首先为每个涉众编号，然后说明涉众的基本信息和涉众在系统中的角色。涉众分析的时候，最重要的是准确的描述涉众情。比如购物网站系统，况和他们对系统建设的期望，而不是进入业务细节。开始，涉众可能不完善，但是，可以在任何情况补充和完善涉众分析报告。
可以采用表格形式编写涉众概要，例如：

 

1.1.2.4涉众分析例子

通过前面涉众分析中定义、分析方法以及得到的分析报告，再结合我们的仓储业务，我们得到下图中的涉众任务关系图：

业务分析

1.2业务分析

1.2.1业务主角

1.2.1.1主角选取方法

根据涉众分析报告或者是涉众人物关系图，我们很容易得到备选的涉众列表。其次我们在根据所定义的边界，寻找那些站在边界外的涉众。用主角的定义审查这些备选的涉众在此边界内的行为模式，从而找出符合定义的涉众二形成业务主角。
并非所有涉众都会成为业务主角。只有那些直接与系统交互的涉众才能成为业务主角，另外，涉众利益可以被多个不同的业务主角代表，这表示一个涉众可以衍生出多个业务主角。

1.2.1.2业务主角例子

在下图中通过客户服务边界中客户和收货人这两个涉众进行分析得出。收货人可能衍生出：政府机关、企业收货人和个人收货人。另外，客户、政府机关、企业收货人和个人收货人也可能不直接与系统交互而是委托客服人员与系统交互。所以客服人员作为代理人也是客户服务的业务主角。

客户服务业务主角

通过对业务的边界、业务目标等分析。我们得出：
仓储事业部涉众主角分析得到：配货主管、配货员、叉车驾驶员、收货人和收获主管；
营销事业部涉众主角分析得到：业务员；
计划财务部涉众主角分析得到：财务人员；
配送事业部涉众主角分析得到：发送主管；
另外还存在系统管理员和物流经理这两个角色。

内部管理服务业务主角

1.2.2业务用例

1.2.2.1定义

我们习惯上理解的需求指的是系统需求，也就是软件需求规格说明书里所描述的内容。它与计算机硬件是紧密相关的，受制于计算机环境。在同一过程中，系统需求只是整个需求过程的一部分，仅仅说明计算机里面实现的那一部分需求。软件需求源于业务需求。
业务用例是用例版型中的一种，专门用于需求阶段的业务建模。与其他用例的版型不同 的是，也用例专门用于业务建模。而业务建模是针对客户业务的模型，也就是现在客户的业务是怎么来建立模型的。严格来说业务建模与计算机系统建模无关，它只是业务领域的一个模型，通过业务模型可以得到业务范围，帮助需求人员理解客户业务，并在业务层面上和客户达成共识。
业务主角站在边界之外，背负着涉众赋予的业务目标。要如何完成这些业务目标呢？业务主角需要做完这件事情，接着做完那件事情…..这样才能达到目标。对于系统来说，每一件事情就是一个业务用例。每个业务用例都体现了业务主角的一个系统期望，而所有这些期望则完成边界所代表的业务目标。

1.2.2.2构成和特征

业务用例获取方式很多，可以通过岗位手册，业务流程指南，职务说明等一些文件获取，也可以从涉众分析中获得灵感。另外一种重要方法是业务主角访谈。可以通过以下问题引导业务主角代表说出他们的业务需求：
 对系统的期望是？
 打算在这个系统做哪些事情？
 做这个事情的目的是？
 完成这些事情的有什么结果？

业务用例可以概括来说就是：某某做什么事情。

下图为业务用例的构成图示：

业务用例特征：
 用例是相对独立的：它不需要与其他泳衣交互而独立完成参与者的目的。
 用例的执行结果对参与者来说说可以观测的和有意义的：
 用例必须由一个参与者发起；
 用例必然是以动宾短语形式出现的；
 一个用例就是一个需求单元、分析单元、设计单元、测试单元，甚至部署单元；

1.2.2.3业务用例例子

客户服务业务用例概括图

1.2.3业务建模

一个完整的业务模型包括：
 业务用例视图
 业务用例场景
 业务用例规约
 业务规则
 业务对象模型
 业务用例实现视图
 业务用例实现场景
 包图
其中，业务用例在获取业务用例的时候已经基本完成了。

1.2.3.1用例场景活动图

业务用例场景用来描述业务用例在该业务的实际过程中是如何做的，绘制业务用例场景可以使用以下这些工具。例如，如果想强调参与改业务的各种参与者的职责和活动，可以选择活动图来描述。如果想强调业务完成时间顺序，可以选择时序图来描述。如果想强调与该业务的各参与者之间的交互过程，可以选择用协作图来描述。

场景隐含两个基本要求，一是必须忠实于真实业务，二是一个场景只能描述业务的一种执行方式。也就是说不能带有“设计”思想在里面，或者视图“抽象”和“优化”业务过程执行。同时，不要试图在一个场景里面把所有业务内容都包括进来。绘制一副充满判断分支的活动图。
以客户下达入库指令业务用例为例子，描述这个业务用例的用例场景。

客户下达入库指令业务用例活动图

1.2.3.2业务用例时序图

大多数情况下，时序图用于描述对象之间按一定顺序互通消息而完成一个特定的目标。在业务用例场景这一情况下，由于我们这时还没有业务对象，一般来说业务对象要到领域模型或者概念建模阶段才会定义出来。这个时候我们考虑业务主角和业务工人这类特殊的业务对象。
在绘制活动图是以业务主角和业务工人为泳道来绘制的，以此类推，时序图也将业务主角和业务工人作为对象来绘制。

客户下达入库指令时序图

1.2.3.3业务对象模型

1.2.3.4业务用例实现

业务用例实现视图展现业务用例有哪些实现途径。
业务用例是业务需求，而业务用例实现则是业务的实现路径，从软件工程的角度说，这个视图展现了需求的可追溯特点。在实际工作中，如果一个业务用例用例只有一个实现途径，那么绘制业务用例实现视图似乎不是那么必要，但是如果一个业务用例有多重实现途径，则应当绘制业务用例实现视图来组织实现业务的那些业务对象和业务过程。

例如我们的下达入库指令这个业务用例的实现方式有两种实现方式。B2C客户和B2G客户的下达入库指令。

下达入库指令业务用例实现视图

1.2.3.5业务用例实现场景

业务用例实现场景的建模方法与业务用例场景有着微妙的差别。业务用例场景用于说明业务怎么样执行，当缺少表达如何“实现”的机制。例如，一项业务中需要对文件进行保存，但是如何保存可以有多种实现方式，可以扫描成图片，可以做成pdf文件等等。这种实现机制就是在业务用例实现场景中描述的。虽然描述的都是同样的业务要求，但是着力点不同。通常，建立计算机系统的目的就是让用户通过人机交互来完成业务，因此，在业务用例实现时应当着重描述如何通过人机交互来完成业务。

业务用例实现场景

1.2.3.6业务用例模型

一个业务用例可能有多个业务用例场景，每个业务用例场景对应一个业务用例实现；每个业务用例实现要实现它所对应的业务场景中的多个业务环节，因而一个业务用例实现场景也是由多个实现过程组成的。

业务用例模型图

概念分析

1.3概念分析

我们已经捕获了需求，然而这些需求还处在“原料”阶段。捕获需求后可以直向后扔给设计人员。但是信息在传递的时候难免发生失真。设计人员可能误解甚至丢失需求中的重要信息，导致设计重心偏差。
一种好的方法是将需求向后传递的过程之前进行一些需求分析工作。这些工作又需求人员和设计负责系统设计或者架构设计的人员一起来完成。在进行需求分析可能要完成的工作包括建立概念模型、建立业务架构和开发系统原型。

1.3.1 建立概念模型

1.3.1.1 定义

概念用例模型位于先启阶段，有时也在精化阶段，是业务用例建模的一个子集。在实际工作中，尤其系统规模较大时，业务用例的粒度也相应的较大，通常一个业务用例所鞥描述的业务和粗略。二系统用例由于必须适应软件开发的需要，其粒度需要较小。从粗粒度到很细的粒度显然比较困难。而如果视图缩小业务用例粒度，则有会导致业务用例数据激增。
这时，我们可以采用一种方法来“分解”那些较大的业务用例，从总找到关键和核心的工作单元，针对这些工作单元建立模型来简化业务。这中“分解”行动所产生的结果就是概念用例。用例是“原子”性的，所以“分解”其实是抽象出概念用例通过包含、泛华、扩展关系连接到基本业务用例。
概念用例的选择条件：关键业务用例，核心业务用例或者是粒度比较粗的业务用例。
注意点：概念模型是针对需求中的关键业务，或者说是业务核心来建立的，所以前提是需求人员已经把握了需求，并能从复杂的需求中找出支撑起整个业务的那条主线。并且，概念模型贵于精准而非全面。

概念用例模型

1.3.1.2 获取概念用例

在业务用例中我们分析出了好多的业务用例，全部扔过来，是否无从下手？但是，需求人员应该告诉你：尽管这么多的业务用例，但是，仓储管理最核心的业务是管理指令，根据指令配货，发货、送货和收货收取费用。这是仓储的业务主线，这是我们可以根据业务主线分析，挑选出一些关键业务用例：

关键业务用例

上述挑选出来的业务用例就是我们接下来要进行分析的输入。

1.3.1.3 分析概念用例

当概念用例被确定出来后，接下来就是对概念用例进行分析。分析过程与业务用例的建模过程别无二致，仍然是绘制概念用例的场景图（活动图，时序图），然后从中找到关键的对象，最后为这些关键对象绘制一些协作图说明这些对象之间的关系和交互场景。
此时我们的视角需要从系统给的角度或者说抽象的角度来分析概念用例模型，因为我呢的目的是要搭起从业务到系统的桥梁。

1.3.1.4 概念用例场景

在分析概念用例的时候，我们得到业务用例–下达入库指令是由：生成入库指令、月台预约、月台收货、拆零质检和上架构成的。我们可以对这些小用例绘制场景图。每个都需要绘制场景图。例如：生成入库指令。

生成入库指令场景

系统分析

1.4 系统分析

1.4.1系统用例

业务需求是通过业务模型描述的，以业务用例场景和业务用例规约为主要文档，描述在现实中的业务是怎么样的。系统需求则是通过系统模型描述的，以系统用例和用例规约为主要文档，描述系统如何映射到现实中的业务。而从业务需求到系统需求的过程大概如下图演变。

从业务需求到系统需求演变图

1.4.1.1获取系统用例

系统用例从何而来？普遍的理解是从勾引我用例细化而来。然而这个细化过程缺很少有人说的清楚。从用例的含义来看，业务用例描述业务，而系统用例描述系统，显然二者目的也是不同的。含义不同，目的不同的两个东西，怎么回事细化关系呢？
实际上，从业务用例到系统用例，更适当的说法是抽象关系，或者是映射关系。可以说从业务用例中抽象出系统用例，也可以说把业务用例映射到系统用例。
抽取的方式其实类似概念用例。要找到系统用例，首先分析业务用例场景，从业务用例场景当中抽出那些可以在计算机当中实现的单元来。业务用例场景通常被描述为某某做什么，然后某某又做什么。。。。。。，而这些谁做什么就是系统用例的来源。
例如我们来分析下达入库指令的业务用例场景。
1、客服人员下达入库指令
这个备选用例可以用计算机来实现吗？应该是可以的。客服人员直接在计算机上填写下达入库指令并保存。所以可以列入系统用例。
2、收货主管月台预约
这个备选用例中收货主管需要制定月台预约计划，然后通知月台预约结果。所以这个可以列入系统用例中。
3、送货司机送货到仓库
这个送货应该是开车吧货物送到某个地方。属于人工行为。所以不能列入系统范围。
4、安排收货任务
收货主管需要在电脑中录入安排计划。打印收货小条这个是属于安排收货任务时要做的。所以打印收货小条可以包含在安排收货任务中。
5、送货司机送货到指定月台
这个应该也是个人工行为。所不属于系统范围。
6、收货员到货查验
收货员到后查看货物的是否完好，这个是人用眼睛在看的。所以是人工行为。不属于系统范围。
7、收货员到货登记
收货员将验收后的货物登记到系统中。这个是属于系统范围的。
其他的例子不在描述。我们通过上述的方式分析抽象得到我们的系统用例。

系统用例

归纳：
经过以上几个实例分析，可以看出从业务用例场景当中抽象出备选的系统用例，并且判断这些备选的系统用例是否应当被纳入系统的基本方法。具体的来说这些方法包括：
映射:备选用例不加修改直接采纳为系统用例。
抽象：不能直接作为系统用例，需要进行写抽象，找到备选用例在计算机当中正在要做的的事情。
合并：备选用例不具备独立性时，必然是其他某个时间的组成部分。例如打印收货小条是安排收货任务的部分，因此被合并到安排收货中。
拆分：有时候业务用例场景中一个备选用例粒度很大，在这个备选用例当中包含几件事情，就需要进行拆分。系统用例应当只描述一次完整的计算机交互过程。
演绎：有时候会遇到业务用例场景当中找不到的备选用例，或者备选用例看上去并不合适用计算机来实现的时候。但是我们能预见某个可能的系统用例潜伏在这个场景中，我们就需要使用演绎法将它找出来。

1.4.1.2系统用例描述

描述系统用例的方法和描述业务用例的方法如出一辙，描述系统用例的过程，也就是系统建模过程。对比业务建模过程，系统建模所采用的工具仍然是用例场景、用例规约、对象模型、用例实现、用例事项场景。
与业务建模不同的是，我们的视觉和建模目的已经从原来的描述业务、理解业务便成理解系统、描述系统。两者的差别在于引入了计算机。之前描述的是原来的业务是什么样的，工作人员怎样完成业务，而现在应该变成计算机怎么做，工作人员怎么操作计算机。
我们选取下达入库指令为例子来讲解如何描述系统用例。

下达入库指令系统用例活动图

1. 客服人员需要创建入库指令，计算机则展示入库指令录入界面；
2. 客服人员录入客户资料，计算机校验客户信息，查询信用记录；
   1) 如果有不良记录，则异常终止；
3. 客服人员录入其他指令并提交，计算机则校验指令并生成指令接着启动月台愉悦环节并结束。
   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。