OOSE软件工程参考手册
版权所有侵权必究
修订记录
分发记录
目录
目录 (3)
1.1 业务规划 (4)
1.2 分析用例建模 (13)
1.3 分析对象建模 (20)
1.4 系统架构规划 (29)
1.5 定义系统边界（0层设计） (59)
1.6 划分系统模块（1层设计） (60)
1.7 定义Design时序图 (61)
1.8 类详细设计 (61)
1.9 方法实现设计 (62)
1.10 界面实现设计（可选） (63)
1.11 物理数据库模型设计 (63)
“需求是软件的灵魂，错误的需求、不清楚的需求、结构凌乱的需求都会影响项目的成功。做好需求，是项目成功的必要条件。”
需求分析流程图
1.1 业务规划
1.1.1 搜集用户需求
①确定需求调研计划
“需求”，通常应该在前面添加两个字，即“用户”，顾名思义，用户提供的需求被称为用户需求。
步骤1：确定需求调研的范围
当前项目的需求范围已经在SOW被明确指定了，在SOW中描述的分配需求中，并非所有的需求都是需要调研的。一般情况下，如果与客户业务活动相关的需求，比如说：“商品采购流程，就需要向商品采购人员进行调研”。一些需求，属于信息化系统的常见解决方案，那么不需要向客户调研，而是在需求分析阶段直接将业内成熟方案推荐给客户。
步骤2：确定需求调研的目标
需求的来源是多种多样的，一般情况下包括下面几种情况：
客户的信息化需求
现有的系统没有信息化手段支持，那么希望提供信息化手段来支撑现有的业务。现有信息化系统的改进建议
客户的业务已经有信息化系统支撑，但是还存在一定的改进空间。即通过信息系统的优化，可以进一步提高客户的工作效率或改进客户的工作质量。
同行业最佳实践经验
这样的需求不直接来源于客户，而是来源于行业专家的建议，或同行业类似的业务系统。
如果需求从人获取，需求调研范围中不同的业务模块是由不同的人负责的，所以需要指定不同部分的人作为调研对象。
如果需求是来自于旧系统的改进意见，可以直接参考已经成档案的文件。
如果需求来源于旧系统，那么可以直接引用旧系统的数据定义，这些数据定义可以在系统界面、系统文档、系统数据库中获取。
如果需求来源于同类系统，那么可以直接从同类系统中引用界面定义、数据定义、功能定义。
步骤3：确定需求调研形式
需求调研形式包括多种方式，常见的形式如下：
需求调研表
系统分析员预先制定标准的需求调研表，根据需求调研目标创建不同的需求调研表实例，通过邮件或其它方式发送到调研对象。
需求访谈
系统分析员直接与调研对象（一般是客户或目标用户）进行交流，启发客户（或用户）说明其对目标系统的期望特征。
资料搜集
直接从客户处获取已经记录的与系统需求相关的文档，比如说已经成档的系统问题记录、系统改进需求。
系统功能抽取
直接运行相关系统，分析该系统，从该系统中抽取合适的流程定义、功能定义、界面设计和数据定义。
步骤4：确定需求调研时间计划
此处安排需求调研活动的时间，在确定需求访谈计划时，需要与访谈对象协商时间。
②需求访谈
步骤1：准备需求访谈表格
在需求访谈前，需要预先识别访谈时需要搜集的特征类型，然后准备需求调研表格。
步骤2：约定需求访谈时间
根据需求调研计划，打电话与客户确认需求调研时间。
步骤3：需求访谈
在约定的时间与客户见面，就你关心的问题和客户关心的问题进行磋商，认真记录客户提出的与系统相关的期望、问题或建议。
在访谈过程中，因为时间关系，不需要马上编写需求访谈报告，而是快速的做一些记录就可以了。
步骤4：整理需求访谈报告
在访谈接受后，编写需求访谈报告，并且从中标识用户需求。在需求访谈报告编写出来后，需要发送给被访谈者。
③编写用户需求
经过前面的需求调研，用户需求已经浮出水面了，需要系统分析员根据前面的需求访谈整理成标准的用户需求文档。
步骤1：创建用户需求文档
此处选择《TPL-BSW-OR.xlt》，创建生成《BSW-[PID]-OR.xls》
步骤2：编写用户需求
根据需求调研的结果，逐条填写到《BSW-[PID]-OR.xls》中。
④用户需求确认
步骤1：召开需求评审临时会议
此处可以不发送需求评审通知，可以召开非正式的用户需求评审会议，会议的主题是评审用户需求。
步骤2：由系统分析员解说用户需求
用户逐条解说用户需求，解说的主要目的是与相应客户交流，双方对用户需求的理解是否一致，如果存在理解不一致的地方，双方需要进行沟通，改经用户需求描述。
1.1.2 识别业务主角
步骤1：目标客户组织结构建模
抽象描述客户实际组织结构，如果客户需要重新规划其组织结构，则以规划后的组织结构为准。
在描述组织结构时,需要描述下列信息：
角色（岗位）定义
角色是组织结构中一个工作岗位的抽象描述，每个角色都有一个唯一标识，那就是角色名称，角色名称不能重复。
通过一段话说明角色的责任、权利和技能，此处只是进行综合性的描述。
组织单位定义
如果客户角色比较多，那么按照角色职能的相似性或相关性，将多个角色定义在一个组织单位中。
步骤2：识别系统的用户范围
并非所有的组织角色都是我们的服务对象，这里需要确定哪些角色在我们的服务范围内。
识别系统的范围，一个方面是系统分析员积极的给用户建议，另外也要听取用户的意见。
系统用户(角色)过多，必然导致系统功能庞大，实施的成本、周期、风险都会相应增加。
步骤3：在Rose中定义组织结构模型
打开Rational Rose,创建“A.组织建模”
打开Rational Rose工具，在“Use Case View”中添加包“A.组织建模”。
Rose组织建模示意图
添加角色
打开“A.组织建模”，选择“main Diagram”，添加角色。此处的角色类型可以Business Actor和Business Worker两种类型。
Business Actor,系统用户或间接用户，但是该用户不属于客户的组织结构编制。
Business Worker,系统用户，属于客户组织结构的一部分。
Business Actor示意图
Business Worker示意图
添加组织单元
根据系统用户的组织结构，定义不同的组织单元。
组织单元定义示意图
1.1.3 业务用例建模
根据工作任务书中的分配需求描述，确定当前业务用例模型中哪些业务模块应该包含在需求分析范围之中。
步骤1：在Rose中创建“B.业务用例模型”
打开Rose，在Use Case View中创建包，并且该包命名为“B.业务用例模型”。
业务用例模型
步骤2：创建业务模块包
打开“B.业务用例模型”，为每个业务模块创建业务用例包。
业务用例包模型示意图
步骤3：创建每个包中的业务用例
打开业务模块包，根据业务规划结果创建每个业务用例，并且在用例图中添加业务用户和业务用例之间的关系。
业务用例示意图
步骤4：完成业务用例描述
选择相应的业务用例，在Document框中输入该业务用例的概要性描述。
业务用例描述示意图
在下图所示的用例模型中，选择“1.1 测试案例录入流程”作为本项目的需求分析
范围。
业务用例模型示意图
步骤5：创建业务用例活动图
每个业务用例都提供了相应的业务活动图，每个活动图中反应了角色、活动、实体对象之间的关系。本步骤确认业务活动图中哪些业务活动应该在纳入本次需求范围中。
为了进一步准确的描述业务用例，需要定义该业务用例的流程图。
创建业务用例活动图实例
选择业务用例右键菜单“new->Activity Diagram”，创建出业务用例实例。
在活动图中添加泳道
为当前业务用例中的每个业务角色创建一个业务泳道。
添加开始节点、业务活动、终结节点，并且定义这些节点之间流程关系。
每个活动图只能有一个开始节点，终止节点可以有多个。
描述开始节点、活动节点、终止节点
此处简要描述每个节点的涵义。开始节点指的时业务流程启动的前臵条件，终止节点指的是业务流程结束的后臵条件。
创建活动的输入及输出对象
在业务活动图中，每个业务活动都有输入及输出数据，这些输入数据及输出数据都定义为业务实体。如果在一个业务活动图中相同的业务实体出现多次，那么使用实体状态区分出不同业务实体实例的差异。根据业务描述添加每个业务实体对象的关键特征。
业务用例活动图示意图
业务对象示意图
1.2 分析用例建模
1.2.1 分析用例建模
在确定用例建模的边界后，需求分析的对象也就确定了。遵循下列操作过程一步一步创建出分析用例模型。
步骤1：在“Use Case View”创建“C.分析用例模型”
打开Rose，在“Use Case View”中创建分析用例模型。
步骤2：根据业务用例包创建分析用例包
每个业务用例包在分析用例模型中都有对应的包，而且采用相同的包名。
下图所示是根据业务用例包模型创建的分析用例包模型，这两个模型的定义是一样的。
分析用例包示意图
步骤3：为每个选择的业务用例创建对应包名
每个选择的业务用例，都包括一个或多个分析用例。这里为每个业务用例创建一个对应的包名。
例如，在业务用例模型中，“1.1测试案例录入流程”是一个业务用例，在分析用例模型中则创建一个对应的包“1.1测试案例录入流程”。
分析用例包示意图
步骤4：在包中创建分析用例
业务活动对应到分析用例。一般情况下一个业务活动会包括一个或多个子活动。根据子活动的不同性质，子活动可以直接定义为分析用例，也可以定义为分析用例的场景。
业务用例活动图示意图
将业务用例活动图中的节点对应创建一个分析用例。
分析用例示意图
步骤5：指定分析用例的业务角色
在业务用例活动图中，已经定义了每个活动节点的执行角色。所以分析用例的执行角色与业务活动图中活动节点对应的执行角色是一致的，在分析用例模型图中引入业务角色，并且建立业务角色与分析用例的对应关系。
步骤6：分析用例简要描述
在业务用例活动图中，一般情况下已经提供了活动节点的描述。这里只是简单的拷贝就可以了。如果没有提供描述，那么这里需要补充用例的简要描述。
用例简要描述指的是：什么角色、在什么情况下、采取什么行动、达到什么样的目标。
比如说，针对“创建测试用例”这个用例，简要描述如下：测试人员在编写测试案例时，直接通过测试管理系统创建一条新测试用例记录，测试人员在系统界面中录入测试用例信息，然后直接将信息保存到测试管理系统数据库中。
步骤7：分析用例详细描述
列出使用当前系统功能的角色
此处可以包括一个或多个业务角色；在分析用例模型中已经指出了使用系统功能的业务角色。
如果有多个业务角色都使用本系统功能，可以考虑定义一个这些业务角色的抽象父类。
用例简要描述
在用例建模时已经提供了简要描述，可以拷贝到需求规格说明书中。
前臵条件
前置条件指的用户使用当前系统功能时系统必须满足的状态。如果当前系统功能是业务流程中的一个节点，那么上一业务流程节点的输出就是当前系统功能的前置条件。
一般情况下，用户登录系统，具有相应的功能授权是使用软件系统功能的通用条件，不必再在系统前置条件中描述。
后臵条件
后置条件，指的是用户执行完当前系统功能后，系统处于的状态，以及在该状态下当前用户或其它用户可以继续操作的系统功能。
一般情况下，不同的场景其后臵条件有所不同，这需要在场景描述中详细说明。
1.2.2 分析场景建模
步骤1：定义分析场景、即实现用例
每一个分析用例，用于系统状态不同、或是用户的选择不同，系统会提供不同的处理流程，每个处理流程即是一个分析场景。
在系统功能设计时，由于用户操作错误、系统状态错误而引起的系统例外只是作为备选事件流程。
我们在用例UML模型中，在用例元素中为每个场景定义一个时序图，并且对该时序图命名。
步骤2：创建实现用例US时序图
在US时序图中，选择当前功能的角色作为用户，添加一个系统对象，然后逐步定义用户和系统之间的交互过程。
US时序图的创建过程，实际上也是一个系统功能的细节设计过程，它定义用户和系统之间的交互活动以及这些活动之间的顺序，明确指定了用户和系统各自的责任。
US时序图
步骤3：US时序图交互信息说明
在US时序图上，确认用户之间的每条交互线的信息要求是否明确，比如说：用户输入数据，那么需要明确输入哪些数据，这些数据有什么要求；系统显示信息给用
户，需要指明显示哪些信息。
步骤4：场景规范化描述
场景规范化描述就是利用规范化的文字说明场景的相关信息，描述步骤一下。场景信息描述
通过下列表格实现场景的规范化描述：
基本事件流
动作序列主角动作系统响应1
2
3
…
备选事件流1
1
2
场景描述表格
基本事件流指的是，在假设系统状态正常，用户输入正确的情况下，用户和系统之间的交互流程。
备选事件流指的是，在系统状态异常或用户输入错误的情况下，用户和系统之间的刘交互流程。
无论是基本事件流还是备选事件流信息，在前面创建US时序图已经具备了基本描述，这里只是将图形中的信息抽取出来形成文档。
场景时序图
此处是将场景时序图图片拷贝出来粘贴到文档中。
界面原型
界面原型指的是，参与到本场景中的系统界面的剪辑图，此部分直接拷贝系统界面原型中的图片。
本信息在分析对象模型完成后补充。
输入数据
输入数据指的是本场景执行时，用户应该为系统提供的输入信息，包括用户从界面中录入的数据和系统中参与到当前场景执行的数据。
数据来源
SN 数据项名称数据类型数据项格式数据长度数据范围1
2
3
4
数据来源填写方法如下：如果数据来源是用户输入，那么填写“用户输入”；如果数据来源是系统数据，那么指明具体的数据对象名称。
本信息在分析对象模型完成后补充。
输出数据
输出数据指的场景执行完成后，系统给用户的反馈信息，包括回显信息和系统产生的新数据。
数据类型
SN 数据项名称数据类型数据项格式数据长度数据范围1
2
3
4
本信息在分析对象模型完成后补充。
业务规则描述
业务规则描述指的是在本场景时序中，系统处理用户请求时遵循的规则。
本信息在分析对象模型完成后补充。
1.3 分析对象建模
OOA，顾名思义就是面向对象的需求分析。面向对象的需求分析，除了前面描述的用例建模外，另外一个主要任务就是定义参与到系统的三种对象类型：
边界类
边界类，指的是用户和系统之间交互的边界、系统和系统之间交互的边界。用户和系统之间交互的边界就是用户界面,通常是图形用户界面(GUI)。
控制类
控制类，指的是用户与系统交互时，系统的业务处理流程。
实体类
实体类，指的是系统业务逻辑处理时引用到的或保存的数据对象。
1.3.1 制作场景MVC时序图
步骤1：创建MVC时序图实例
针对每个实现用例，创建一个时序图实例，拷贝US时序图内容到当前时序图中。 步骤2：定义系统界面