面向对象的需求分析与设计过程实践汇总.docx
《面向对象的需求分析与设计过程实践汇总.docx》由会员分享，可在线阅读，更多相关《面向对象的需求分析与设计过程实践汇总.docx（43页珍藏版）》请在冰点文库上搜索。
面向对象的需求分析与设计过程实践汇总
面向对象的需求分析与设计
2011年7月31日
15:
37
UML是一种用于制定软件系统构成要素和交互方式标准的语言。
UML涉及6大主要方面-从用例模型、动态和逻辑模型到最终的物理部署模型。
一个典型基于UML的开发过程大致如下：
一、RA需求分析
二、RD需求开发
三、AD概要设计
四、DD详细设计及实现
五、过程控制
六、系统测试
1RA需求分析
2011年8月13日
13:
54
由产品经理负责，主要任务：
建立业务过程模型。
∙建立业务过程模型，（同时明确业务过程的输入、输出、过程定义）
分析并建立业务流程。
业务过程模型被用来定义发生在企业的业务活动和业务过程，并且是建立用例模型的基础。
一般来说业务过程模型比一个软件系统所能实现的更多（比如：
业务模型包括人力和其他过程）。
1.1业务流程建模
2011年7月31日
20:
42
介绍
有两个备受关注的UML扩展，它们进一步强化了对业务过程和相关结构的建模。
第一个是业务过程建模标注BPMN，它已经成为业务过程建模与设计的新标准。
第二个是Eriksson-PenkerProfile，虽然不那么流行，但在可视化、业务过程间通信、以及企业（组织）内部的信息流方面，仍然是独一无二的。
本文将对这两种扩展提供深入介绍，阐述如何在EnterpriseArchitect中使用它们以及他们所用的通用模型结构。
业务过程建模标注（BPMN）
BPMN定义了一种业务过程图（BPD），该图是基于一种专门绘制流程图技术，用于业务过程的图形化建模。
一个BPMN模型是由一组简单图构成，每一个图又包含一组图形元素。
流程元素
1.活动（Activity）：
一个活动是业务过程中执行的一个作业，用圆角矩形表示。
2.事件（Event）：
一个事件是在业务过程的流程中发生的，并影响业务过程中活动的执行顺序与执行时间的事情。
事件用带有不同边界的小圆表示，以区别初始事件（细实线）、中间事件（双实线）和终止事件（粗实线）。
在图形内部显示图标以便于区分触发器和事件结果。
3.关口（Gateway）：
关口用来控制顺序流如何在过程内进行合并和分岔。
关口可用来表示判断点，可以表示一个或多个路径在此处不能通过。
关口也可以表示一条路径在此分岔。
4.顺序流：
顺序流用来表示活动在业务过程中的执行顺序。
顺序流用有实箭头的线表示。
5.消息流：
一个消息流用来表示两个实体之间的消息流向。
实体用池来表示，消息用虚线在源端连接浅颜色的圆并在目标端连接箭头。
6.关联：
关联是用流对象将信息与制品联系起来。
关联采用虚线表示并在目标端有或者没有箭头，根据需要而定。
泳道（分割
7.泳池：
表示一个业务过程中的参与者。
一个参与者可能是业务实体或者角色。
泳池表示了对业务过程的一种划分。
8.泳道：
是泳池的再划分，用于组织和分类泳池内的活动。
过程要素
9.数据对象：
一个数据对象对一个业务过程没有直接的影响，但提供信息给相关的过程。
数据对象用一个上角折叠的矩形来表示。
10.组：
组提供了对过程内的元素进行分组的非正式手段，用虚线的矩形表示。
11.注解：
注解提供一种机制使得BPMN的模型建立者为BPMN模型的用户提供附加信息。
它是用一个开口的矩形表示，注解文字写入其中。
BPMN示例
例1:
上面的图展示了BPMN的几个主要功能。
特别是将一任务过程进行层次分解成较小的任务。
以及能表示循环结构和外部事件干扰正常过程流程。
"上行活动"和"下行活动"是连接触发的中间事件，换句话说，是页面间承上启下的连接器。
"对每个供应商重复执行"是一循环活动，它对每一个供应商重复执行所包含的三个活动，或者直到时间限制已到。
固定在活动下边沿的终止事件是一时间事件触发器。
例2:
上面的图表示一个业务过程由一个事件开启，在本例中，一个消息触发器产生一个事件，该事件通知业务过程活动组处于活动状态。
该图也显示一个由时间事件控制的循环，并显示一个决策关口（在本例中是“异或”决策关口）控制什么时候循环该结束。
例3:
该图例示使用泳池来表达过程间的交互以及使用消息流连接器来表示消息在泳池间进行传递的方法
Eriksson-Penker业务建模Profile
本节介绍业务过程模型所使用的术语与图标。
并简要介绍一些基本UML建模语言概念以及如何在EA的业务过程建模中如何使用它们。
一个业务过程：
12.有一个目标
13.有指定的输入
14.有指定的输出
15.使用资源
16.有按某种顺序进行的一组活动
17.可能影响多个组织单元，造成横向组织影响
18.为客户创造某种价值，客户可能是内部的，也可能是外部的。
过程模型
一个业务过程是一个活动的集合，用于为特定的客户或市场产生指定的输出。
与产品所强调的“过程是什么”不同，业务过程强调作业在组织内部是如何进行的。
指定在不同时间和地点的作业活动顺序，带有一个开始和一个结束，并清楚地定义输入和输出：
一个动作结构。
始于对象信息供应链。
供应链是指连接到过程的信息或对象在处理阶段没有被使用完。
例如，订单模板可能重复使用，并提供特定样式的新订单。
作为这个活动的一部分，这个模板不会更改和被消耗光。
19.始于对象资源的供应链：
一个输入供应链是指所连接的对象或资源将在处理过程中被消耗。
例如，当消费者的订单在被处理后，它们将标记为完成并签字，并且每个资源仅使用一次。
20.终于对象目标的目标链：
一个目标链是指连接到业务过程的对象描述业务过程的目标。
目标是执行活动的业务宗旨。
21.对象流连接对象输出
22.始于事件的对象流：
一个对象流连接是指在一个业务过程一些对象被传递。
它强调对在实体之间或过程之间所传递信息的控制。
目标
一个业务过程有一些定义完备的目标。
这也是组织制定业务过程的原因所在。
并且这些目标的制定代表组织的整体利益和满足组织的业务需要。
业务过程始于过程的目标链：
一个目标链是指连接到业务过程的对象用于描述该过程的目标。
目标是执行活动的宗旨。
信息
业务过程使用信息执行和完成它们的活动。
信息不象资源，在过程中是不可消费的，它被用来做过程转换。
信息或许来自外部，或许来自客户，或来自内部组织，甚至是其它过程所产生。
连接到业务过程的信息项：
一个供应链是指连接到过程的信息和对象在处理阶段不会被使用完。
例如，订单模板可能一用再用，一提供某种特定类型的新订单。
作为该活动的一部分，模板是不会改变或耗尽的。
输出
典型地，一个业务过程将产生一个或多个多业务有价值的输出，输出可能供内部使用，也可能是为了满足外部需求。
输出可能是物理对象（如一份报告或者发票），可是一种从原始资源到安排的转换，也可能是一个全体的业务处理结果，如完成处理一份订单请求。
一个业务过程的输出可能是下一个业务过程的输入，或者作为请求项或触发项来触发新活动。
资源
资源是一个业务过程的输入，并且不像信息，在业务过程处理中要被消耗。
例如：
火车每天运行服务和实况记录，服务资源将随着处理记录火车运行时刻的不断进行而被用完。
连接到业务过程的资源：
一个输入连接是指所连接的对象或资源在处理过程中被消耗。
例如：
当消费者的订单在被处理后，它们将标记为完成并签字，并且每个资源（订单）仅使用一次。
源文档<
1.1.1业务流程建模的目标
2011年8月9日
22:
34
1描述组织结构\各自职责
2按活动顺序和参与的角色来描述业务流程、流程关联的信息
1.1.2业务流程建模的输出
2011年8月9日
22:
36
1组织结构树
2业务协作流程图
1明确参与协作的活动主体，最好是岗位
2体现PDCA，谁计划、谁执行、谁检查、谁处置
3明确开始和结束
4明确与事件相伴的业务信息。
1.1.3业务流程建模的方法
2011年8月9日
23:
13
1建立组织结构树
2使用活动图描述复杂的业务流程
3用类图定义已知的业务数据
4
1.1.4业务需求采集分析的方法
2011年8月10日
0:
09
∙以组织结构为线索，按层次描述企业部门、岗位、工作职责、工作步骤的组成情况，罗列出每个人的本职工作；
∙以业务种类为线索，按环环紧扣模式描述每个业务种类的具体业务流程，这些流程体现了部门间的、人之间的业务往来情况；
∙以工作交接为线索，沿着相关的业务流程，收集相应的业务数据（单据与报表），详尽描述这些数据的内容及其之间的关系。
2RD需求开发
2011年8月13日
13:
53
由产品研发经理负责，主要任务：
建立系统用例模型，详细描述每个用例、建立领域模型、提出系统界面原型
1.建立系统用例模型，并将用例关联至业务过程
映射用例模型到业务过程模型以精确定义你要提供的功能，并且是站在业务用户角度考虑的。
每增加一个用例时，将创建一个从适当的业务过程到该用例的可跟踪链接（如：
一个实现链接）。
这个映射清楚地表达新系统将提供什么样的功能来满足业务过程中所描述的业务需求。
这种映射也确保系统中每个用例都是有用的。
1.详细描述每个用例、可能的话编写该用例的系统测试用例
完善用例-包括需求，约束、复杂程度、注释及情形。
这些信息清楚地描述用例做什么，如何做以及执行时的相关约束。
这个过程要保证用例始终满足业务过程的需求，包括每个用例的系统测试定义，该定义为该用例定义了接收标准。
也包括了一些用户可接受的测试脚本：
这些脚本定义了用户将如何进行测试和测试接收的标准。
1.建立领域模型
有了业务过程模型的输入与输出和用例的详细信息，就可以开始构建领域模型（高级业务对象）、顺序图、协作图和用户接口模型。
这些图描述新系统中的要素以及这些要素之间的相互作用和用户执行用例时所需各种情形的接口。
1.明确其他非功能性需求
在完成上述工作的同时，需要获取一些额外的需求并整理成文档。
例如：
非功能性需求，性能需求，安全需求，义务需求，发布计划等。
将这些需求在模型内部进行整合并随模型的进展而更新。
1.提出系统界面原型
2.系统动态行为分析
2.1系统用例
2011年7月31日
23:
36
需求分析阶段需要针对未来的系统建立系统用例模型，更偏向于系统将要实现的功能。
系统用例模型描述了系统自动化工作后的过程，演示了系统的需求，描述了系统的功能。
系统用例比业务用例要详细，一般把各系统划分成子系统，用不同的包来建模。
目前我们完成的税企通V1.2版需求分析就是做了系统用例模型
1用例模型
用例从使用系统的角度描述系统中的信息,即站在系统外部观看系统的功能,不考虑系统内部对该功能的具体实现方式。
建立用例模型的主要工作：
找出角色、找出用例、描述用例、用例间的关系处理、验证模型、
问题1：
用例模型中用例的颗粒度大小多少为合适？
问题2：
我识别出的用例更偏向于功能组、或者功能点。
2识别角色
注意：
角色向用例发送消息或者接收用例反馈的消息。
从这句话来看，用例模型中还应该包含对消息的初步分析。
3识别用例的方法
1某个角色要求系统为其提供什么功能？
该角色需要做哪些工作？
2角色需要阅读、创建、销毁、更新或存储系统中的哪些信息？
4用例描述
已经有许多标准的用例描述写法
问题：
通过那种工具可以将用例描述的文本内容也糅合到用例模型中去？
可以考虑PD，但PD的RQM仍不是非常熟悉。
1在需求分析阶段的第一个任务，提出系统用例列表
基于业务需求我们往往只能提出一个大的功能组的设想和一部分功能组的组成功能的设想。
这妨碍着我们继续展开需求分析工作。
行动建议1：
在需求分析的早期，尽可能的和客户就功能列表达成一致意见。
我的实践1：
在这个时期，用例间的关联关系可以不必非常准确的定义。
我的实践2：
可以使用layouttools来自动完成用例的图形化排布。
达成目标1：
构建出系统用例列表、并就每个用例（获至少功能组）定义出优先级来。
达成目标2：
定义出每种用户角色所关联的功能组来。
PS使用技巧：
可以用右键菜单【viewdiagramasalist】来列表展示图中所有元素
效果如下图所示
2在需求分析阶段的第二个任务，根据功能组的划分和用例的优先级进行开发顺序的排布。
例如：
在我们项目中将采用多个版本迭代开发实现的方式，将一个复杂系统的80个用例划分为8个版本实现。
每个版本只实现其中的10个用例或者2个功能组。
这样进行项目计划的排定和任务的安排。
下图显示了我们产品在V1.2版拟定开发的功能组和用例。
行动建议：
1在版本规划中系统的前几个版本最好完成系统的最基本功能或最主要的业务功能。
例如，系统的权限、角色、用户管理、主要的业务流程。
我的实践：
1将系统用例中已经完成的用例元素拖拽到对应的版本包中，形成链接即可。
2为了保证需求不蔓延或业务需求的可追溯性，在完成用例的需求分析之后，将该用例与某个业务需求进行关联，如下图所示，从而跟踪需求。
SettheTypeofrelationship（ImplementsorGeneralizesfromthedrop-downlist.
达成目标：
用例模型描述的是新系统规划的功能。
它表示用户（人或机器）和系统之间交互的离散单元。
该交互是一个有意义的独立单元，如：
创建账户，浏览帐户信息。
每一个用例描述建立在规划系统中的功能，它可以包含另一个用例功能或用自己的行为扩展另一个用例。
一个用例描述通常包括：
∙描述用例的常规注释和说明
∙需求-用例必须提供给最终用户正式的需求。
如：
"能更新订单"。
它们都对应构造方法中建立的功能规范，并建立用例执行动作和给系统提供值的约定。
∙约束-用例运行所遵循的正式规则和限制，它们定义了什么能做，什么不能做。
包括：
∙预置条件是用例运行以前就已经发生了。
如：
"创建订单"必须发生在"修改订单"之前。
∙后置条件是用例完成后必须为真，如：
"订单修改和一致性检查"。
∙常量在用例的整个运行过程中始终为真，如：
一个订单一直有客户号。
∙情形–用例执行时各步骤正式有序的描述，或用例实例化过程中事件发生的流程。
它包含多种情形来应付特殊环境和可选择的处理方式。
它们通常由文本建立和对应于顺序图的文本表达。
∙情形图-描绘工作流的顺序图;类似于情形，但是图形化描述。
∙附加属性，如实施阶段，版本号，复杂性程度，构造型和状态。
执行者
用例通常与执行者关联，执行者可以是人或机器实体，用于系统交互来执行有意义的工作从而帮助他们完成目标。
执行者参与的用例定义了它们在系统中总体的作用和动作的范围。
包含和扩展用例间的关系
一个用例可以包含另一个用例功能做为它自身正常运行的一部分。
通常假设在用例运行时被包括的用例每次都会被调用。
例如：
在修改选定订单前，列出一份客户订单表，每次"修改订单"用例执行时，"列出订单"用例被调用执行。
一个用例可以被一个或多个其它用例包含。
通过将通用的行为提炼成可以多次重复使用的用例，有助于降低功能重复级别。
通常，在特别情况下，一个用例可以扩展另一个用例的行为。
例如：
如果一个用户在修改一个特别类型的客户订单之前，该用户必须得到某种更高级别的许可，然后“获得许可”用例将有选择地扩展常规的“修改订单”用例。
顺序图
顺序图提供随时间变化，对象交互的图形化描述。
通常用来表现一个用户或执行者，对象和组件，以及它们在用例执行过程中之间的交互。
一个顺序图典型地表示一个单独的用例情形或事件流。
顺序图可以出色的显示文档使用情形，既可以记录早期分析的所需对象，也可以在稍后的设计阶段验证对象。
它显示一个对象到另一个对象的消息流，这些消息流对应着一个类和对象支持的方法和事件。
下面顺序图例示了左侧的用户或执行者初始化事件和消息流，它们对应于用例情形。
在最终模型中，对象间传递的消息变成类的操作。
执行图
用例是对所构造系统将有功能的正式描述。
与用例关联的执行图用来设计元素（如：
组件和类）和实现用例在新系统中的功能。
这为系统设计者，客户和团队，这些实际建立系统的人，提供了高级别可跟踪能力。
组件和类连接的用例列表说明了必须被组件执行的最少功能。
上图说明用例"Login"实现需求"1.01LogOntothewebsite"。
也显示组件"BusinessLogic"和"ASPPages"组件实现部分或全部"Login"功能。
进一步细化可显示"Login"界面（一个网页来实现"Login"用例。
这些执行和实现连接定义了从正式需求，到用例，直至组件和界面的可跟踪能力。
2.2用例描述与系统测试用例
2011年8月13日
14:
04
2.3概念模型
2011年8月11日
18:
33
概念模型的建立不应该从数据库存储的角度来考虑，而应该从业务对象角度来考虑。
2.4非功能性需求
2011年8月13日
14:
04
2.5系统界面原型
2011年8月13日
14:
05
界面原型建模
在需求分析阶段，所有功能的界面原型建模需要完成的工作，需达到的标准：
1界面元素、颜色、字体大小、布局风格、交互方式、功能排布、输入输出模式
2需要确定并遵循【界面设计规范】
3界面原型建模工具：
可以使用RP、（VISIO？
）
4需要描述控件的动作事件、状态的变化控制
2.6动态行为分析
2011年8月13日
13:
26
一、工作流程
用活动图可以进一步详细描述部分用例的工作流程。
在需求分析阶段，可以用活动图来描述如何通过用例来完成某项业务流程。
活动图中的每一个活动都可以建立与某个用例之间的关联
存在问题：
对于常见的管理任务、管理员工之类的业务入口应该与几个活动进行关联？
二、消息与对象交互
采用时序图来描述系统概念对象是如何通过消息按照时间顺序交互的。
它首先关心客户所关心的高级信息。
这时候概念对象还没有映射类，消息还没有映射成操作。
这些图是让系统分析人员、系统用户和其他对业务流程感兴趣的人了解系统的逻辑流程。
其次，它在与用户在业务流程达成共识后，将对象映射成类。
3AD系统概要设计
2011年7月8日
0:
35
概要设计也称为架构设计。
由产品研发经理（或高软）负责，主要任务：
建立系统的逻辑视图、明确类的层次结构、类的定义、必要时进行类行为的描述。
边界类V、控制类C、实体类M
3.1定义系统的物理架构。
通过部署视图来定义系统的物理架构。
这项工作可以提前开始以便于掌握系统的物理结构特性-使用什么样的硬件、操作系统、网络规模、接口与支持软件，来构成新系统，和系统部署在那里，以及出现灾难性故障时的系统恢复，系统可靠性、系统备份与支持等方面所使用的参数。
随着模型开发的不断进展，物理系统模型应该不断更新以反映所开发系统的实际情况。
3.2建立系统的逻辑视图
通过类图（明确类的属性、方法）来实现
在领域模型、用户接口模型和情形图的基础上，开始建立对象类模型。
这是制定系统中对象的明确规范：
数据、属性、行为和操作。
使用继承机制，可将领域对象抽象为类层次结构。
处理各种情形的消息一般被映射到类的操作。
如果使用一个现存的框架或设计模式，则可能导入现存模型的元素到新系统中。
为每一个类定义单元测试、集成测试和系统测试。
测试目的：
1）类的功能是否如所定义的，2）类与其它类及组件的交互是否如期望的。
3.3建立系统的部署视图、开发视图（组件图）
当开发类模型时，可能需要将它分解成包和组件。
一个组件代表一个可使用的软件块，它是一个类或者多个类的数据和行为的结合，并严格定义一个对外提供服务的接口。
所以，从类模型的角度看，构造组件模型就是定义类的逻辑包。
对于每一个组件，需要定义集成测试，以证实组件的接口满足规范要求，即与其它软件元素的关系。
3.4数据库设计
架构设计
1常用的架构技术为分层MVC等
思考：
对于我们这个BS+CS架构的产品而言，CS部分的客户端程序如何将表示层和业务逻辑层分开？
是一个问题，特例化的考虑是从函数名称和归类上予以区分，所有业务逻辑层的函数以单独的程序文件和函数来实现。
所有表示层的处理放置到其他程序文件或函数中去。
Web应用则基本采用MVC或者扩展层数（增加持久化层）的的架构
另外一个思考：
如果将CS客户端程序的C端的业务处理采用JAVA来构筑成为服务的形式，则C端的表示层通过调用接口来找到特定业务逻辑，从而完成三层的划分。
但这样做是否值得？
考虑SOA思想及重用的概率则再casebycase地讨论
存在问题：
对于类的不同状态，在不同阶段应该如何去展现？
3.5系统逻辑视图
2011年8月13日
14:
41
主要任务为建立系统所有的类图，其中定义了类的属性、操作，以及类操作之间的关系
第一阶段：
目标：
建立系统功能的逻辑结构
方法：
以多层嵌套包+底层类图的展现形式来设计系统所有的类。
指南1：
子系统为顶层包、下属的模块为次级包、最底层包为模块的功能。
最底层的功能包将包括实现某个功能所涉及的边界类、控制类、实体类，仅需定义出类名称即可。
指南2：
通过分析用例，定义出该用例涉及到当前底层功能包的边界类、控制类、实体类
说明：
一个用例可能涉及到多个底层的功能包。
第二阶段
目标：
初步实现系统用例
步骤1：
在【系统功能结构】的基础上，定义出每个类所拥有的操作。
步骤2：
定义并描述这些类的操作之间的互动关系。
可以通过为最底层包的每个功能绘制时序图来实现。
绘制时序图的建议颗粒度是用例中的某个事件（可能是初始化表示、可能是点击某个按钮触发的画面迁移）。
指南1：
在这个过程中可能发现某些类为系统通用的方法，则抽取出来单独建立一个包（包中为共通类以及类的操作）。
指南2：
为了便于开发，可建立边界类与界面原型的关联关系。
指南3：
也可在分析完所有用例的所有类的操作之后将这些类进行分包、分层构筑成（有层次的）系统逻辑视图模型
3.6数据库设计
2011年8月13日
14:
51
1数据库所有表的概要设计
定义出数据库中所有表以及表的大部分字段的名称、属性以及非空项、主键、外键等。
2描述数据间的相互关系
数据表间的三种关系：
组装关系、分类关系、关联关系
要求：
全面建立所有数据的关系，尽可能消除孤立数据
3.1概要设计
2011年8月9日
22:
43
1描述软件的全部结构
2描述软件总体运行过程
3定义出系统中所有的边界类、控制类和实体类
实体对象：
这些对象保存信息,最终可能映射成数据库中的表和字段.例:
学生***,1020航班等.
边界对象：
位于系统与外部世界之间的边界上.窗体或窗体与应用程序的接口
控制对象：
是可选的对象,控制用例的流程
4描述出信息或数据的流动情况
用边界类、控制类和实体类来构造出时序图
5定义好模块间的数据传递
例如：
父级模块传递给子级模块的数据和子级模块返回的数据
3.2概要设计的方法
2
升级会员 