面向对象的需求分析与设计-过程实践资料

1、面向对象的需求分析与设计2011年7月31日15:37UML是一种用于制定软件系统构成要素和交互方式标准的语言。UML涉及6大主要方面- 从用例模型、动态和逻辑模型到最终的物理部署模型。 一个典型基于UML的开发过程大致如下： 一、RA需求分析二、RD需求开发三、AD概要设计四、DD详细设计及实现五、过程控制六、系统测试1 RA需求分析2011年8月13日13:54由产品经理负责，主要任务：建立业务过程模型。 建立业务过程模型，（同时明确业务过程的输入、输出、过程定义）分析并建立业务流程。业务过程模型被用来定义发生在企业的业务活动和业务过程，并且是建立用例模型的基础。一般来说业务过程模型比一个

2、软件系统所能实现的更多（比如：业务模型包括人力和其他过程）。1.1业务流程建模2011年7月31日20:42介绍有两个备受关注的UML扩展，它们进一步强化了对业务过程和相关结构的建模。第一个是业务过程建模标注BPMN，它已经成为业务过程建模与设计的新标准。第二个是 Eriksson-Penker Profile，虽然不那么流行，但在可视化、业务过程间通信、以及企业（组织）内部的信息流方面，仍然是独一无二的。 本文将对这两种扩展提供深入介绍，阐述如何在Enterprise Architect 中使用它们以及他们所用的通用模型结构。 业务过程建模标注（BPMN）BPMN 定义了一种业务过程图（BP

3、D），该图是基于一种专门绘制流程图技术，用于业务过程的图形化建模。一个BPMN 模型是由一组简单图构成，每一个图又包含一组图形元素。 流程元素1. 活动（Activity）：一个活动是业务过程中执行的一个作业，用圆角矩形表示。 2. 事件（Event）：一个事件是在业务过程的流程中发生的，并影响业务过程中活动的执行顺序与执行时间的事情。事件用带有不同边界的小圆表示，以区别初始事件（细实线）、中间事件（双实线）和终止事件（粗实线）。在图形内部显示图标以便于区分触发器和事件结果。 3. 关口（Gateway）：关口用来控制顺序流如何在过程内进行合并和分岔。关口可用来表示判断点，可以表示一个或多个路

4、径在此处不能通过。关口也可以表示一条路径在此分岔。 4. 顺序流：顺序流用来表示活动在业务过程中的执行顺序。顺序流用有实箭头的线表示。 5. 消息流：一个消息流用来表示两个实体之间的消息流向。实体用池来表示，消息用虚线在源端连接浅颜色的圆并在目标端连接箭头。 6. 关联：关联是用流对象将信息与制品联系起来。关联采用虚线表示并在目标端有或者没有箭头，根据需要而定。 泳道 (分割7. 泳池：表示一个业务过程中的参与者。一个参与者可能是业务实体或者角色。泳池表示了对业务过程的一种划分。 8. 泳道：是泳池的再划分，用于组织和分类泳池内的活动。 过程要素9. 数据对象：一个数据对象对一个业务过程没有直

5、接的影响，但提供信息给相关的过程。数据对象用一个上角折叠的矩形来表示。 10. 组：组提供了对过程内的元素进行分组的非正式手段，用虚线的矩形表示。 11. 注解：注解提供一种机制使得BPMN的模型建立者为BPMN模型的用户提供附加信息。它是用一个开口的矩形表示，注解文字写入其中。 BPMN 示例例 1: 上面的图展示了BPMN的几个主要功能。特别是将一任务过程进行层次分解成较小的任务。以及能表示循环结构和外部事件干扰正常过程流程。 上行活动和下行活动是连接触发的中间事件，换句话说，是页面间承上启下的连接器。 对每个供应商重复执行 是一循环活动，它对每一个供应商重复执行所包含的三个活动，或者直到

6、时间限制已到。固定在活动下边沿的终止事件是一时间事件触发器。 例 2: 上面的图表示一个业务过程由一个事件开启，在本例中，一个消息触发器产生一个事件，该事件通知业务过程活动组处于活动状态。该图也显示一个由时间事件控制的循环，并显示一个决策关口（在本例中是“异或” 决策关口）控制什么时候循环该结束。 例 3: 该图例示使用泳池来表达过程间的交互以及使用消息流连接器来表示消息在泳池间进行传递的方法 Eriksson-Penker 业务建模 Profile本节介绍业务过程模型所使用的术语与图标。并简要介绍一些基本UML建模语言概念以及如何在EA的业务过程建模中如何使用它们。 一个业务过程： 12.

7、有一个目标 13. 有指定的输入 14. 有指定的输出 15. 使用资源 16. 有按某种顺序进行的一组活动 17. 可能影响多个组织单元 ，造成横向组织影响 18. 为客户创造某种价值，客户可能是内部的，也可能是外部的。 过程模型一个业务过程是一个活动的集合，用于为特定的客户或市场产生指定的输出。与产品所强调的“过程是什么”不同，业务过程强调作业在组织内部是如何进行的。指定在不同时间和地点的作业活动顺序，带有一个开始和一个结束，并清楚地定义输入和输出：一个动作结构。 始于对象信息供应链。供应链是指连接到过程的信息或对象在处理阶段没有被使用完。例如，订单模板可能重复使用，并提供特定样式的新订单

8、。作为这个活动的一部分，这个模板不会更改和被消耗光。 19. 始于对象资源的供应链： 一个输入供应链是指所连接的对象或资源将在处理过程中被消耗。例如，当消费者的订单在被处理后，它们将标记为完成并签字，并且每个资源仅使用一次。 20. 终于对象目标的目标链： 一个目标链是指连接到业务过程的对象描述业务过程的目标。目标是执行活动的业务宗旨。 21. 对象流连接对象输出 22. 始于事件的对象流：一个对象流连接是指在一个业务过程一些对象被传递。它强调对在实体之间或过程之间所传递信息的控制。 目标一个业务过程有一些定义完备的目标。这也是组织制定业务过程的原因所在。并且这些目标的制定代表组织的整体利益和

9、满足组织的业务需要。 业务过程始于过程的目标链：一个目标链是指连接到业务过程的对象用于描述该过程的目标。目标是执行活动的宗旨。 信息业务过程使用信息执行和完成它们的活动。信息不象资源，在过程中是不可消费的，它被用来做过程转换。信息或许来自外部，或许来自客户，或来自内部组织，甚至是其它过程所产生。 连接到业务过程的信息项：一个供应链是指连接到过程的信息和对象在处理阶段不会被使用完。例如，订单模板可能一用再用，一提供某种特定类型的新订单。作为该活动的一部分，模板是不会改变或耗尽的。 输出典型地，一个业务过程将产生一个或多个多业务有价值的输出，输出可能供内部使用，也可能是为了满足外部需求。输出可能是

10、物理对象（如一份报告或者发票），可是一种从原始资源到安排的转换，也可能是一个全体的业务处理结果，如完成处理一份订单请求。 一个业务过程的输出可能是下一个业务过程的输入，或者作为请求项或触发项来触发新活动。 资源资源是一个业务过程的输入，并且不像信息，在业务过程处理中要被消耗。例如：火车每天运行服务和实况记录，服务资源将随着处理记录火车运行时刻的不断进行而被用完。 连接到业务过程的资源：一个输入连接是指所连接的对象或资源在处理过程中被消耗。例如：当消费者的订单在被处理后，它们将标记为完成并签字，并且每个资源（订单）仅使用一次。 源文档 业务流程建模的目标2011年8月9日22:341描述组织结构

11、各自职责2按活动顺序和参与的角色来描述业务流程、流程关联的信息业务流程建模的输出2011年8月9日22:361 组织结构树2 业务协作流程图1明确参与协作的活动主体，最好 是岗位2体现PDCA，谁计划、谁执行、谁检查、谁处置3明确开始和结束4明确与事件相伴的业务信息。业务流程建模的方法2011年8月9日23:131 建立组织结构树2使用活动图描述复杂的业务流程3用类图定义已知的业务数据4业务需求采集分析的方法2011年8月10日0:09 以组织结构为线索，按层次描述企业部门、岗位、工作职责、工作步骤的组成情况，罗列出每个人的本职工作； 以业务种类为线索，按环环紧扣模式描述每个业务种类的具体业务

12、流程，这些流程体现了部门间的、人之间的业务往来情况； 以工作交接为线索，沿着相关的业务流程，收集相应的业务数据（单据与报表），详尽描述这些数据的内容及其之间的关系。2 RD需求开发2011年8月13日13:53由产品研发经理负责，主要任务：建立系统用例模型，详细描述每个用例、建立领域模型、提出系统界面原型1. 建立系统用例模型，并将用例关联至业务过程映射用例模型到业务过程模型以精确定义你要提供的功能，并且是站在业务用户角度考虑的。每增加一个用例时，将创建一个从适当的业务过程到该用例的可跟踪链接（如：一个实现链接）。这个映射清楚地表达新系统将提供什么样的功能来满足业务过程中所描述的业务需求。这种

13、映射也确保系统中每个用例都是有用的。 1. 详细描述每个用例、可能的话编写该用例的系统测试用例完善用例-包括需求，约束、复杂程度、注释及情形。这些信息清楚地描述用例做什么，如何做以及执行时的相关约束。这个过程要保证用例始终满足业务过程的需求，包括每个用例的系统测试定义，该定义为该用例定义了接收标准。也包括了一些用户可接受的测试脚本：这些脚本定义了用户将如何进行测试和测试接收的标准。 1. 建立领域模型有了业务过程模型的输入与输出和用例的详细信息，就可以开始构建领域模型（高级业务对象）、顺序图、协作图和用户接口模型。这些图描述新系统中的要素以及这些要素之间的相互作用和用户执行用例时所需各种情形的

14、接口。 1. 明确其他非功能性需求在完成上述工作的同时，需要获取一些额外的需求并整理成文档。例如：非功能性需求，性能需求，安全需求，义务需求，发布计划等。将这些需求在模型内部进行整合并随模型的进展而更新。1. 提出系统界面原型2. 系统动态行为分析2.1系统用例2011年7月31日23:36需求分析阶段需要针对未来的系统建立系统用例模型，更偏向于系统将要实现的功能。系统用例模型描述了系统自动化工作后的过程，演示了系统的需求，描述了系统的功能。系统用例比业务用例要详细，一般把各系统划分成子系统，用不同的包来建模。目前我们完成的税企通V1.2版需求分析就是做了系统用例模型1用例模型用例从使用系统的

15、角度描述系统中的信息,即站在系统外部观看系统的功能,不考虑系统内部对该功能的具体实现方式。建立用例模型的主要工作：找出角色、找出用例、描述用例、用例间的关系处理、验证模型、问题1：用例模型中用例的颗粒度大小多少为合适？问题2：我识别出的用例更偏向于功能组、或者功能点。2识别角色注意：角色向用例发送消息或者接收用例反馈的消息。从这句话来看，用例模型中还应该包含对消息的初步分析。3识别用例的方法1某个角色要求系统为其提供什么功能？该角色需要做哪些工作？2角色需要阅读、创建、销毁、更新或存储系统中的哪些信息？4 用例描述已经有许多标准的用例描述写法问题：通过那种工具可以将用例描述的文本内容也糅合到用

16、例模型中去？可以考虑PD，但PD的RQM仍不是非常熟悉。1在需求分析阶段的第一个任务，提出系统用例列表基于业务需求我们往往只能提出一个大的功能组的设想和一部分功能组的组成功能的设想。这妨碍着我们继续展开需求分析工作。行动建议1：在需求分析的早期，尽可能的和客户就功能列表达成一致意见。我的实践1：在这个时期，用例间的关联关系可以不必非常准确的定义。我的实践2：可以使用layout tools来自动完成用例的图形化排布。达成目标1：构建出系统用例列表、并就每个用例（获至少功能组）定义出优先级来。达成目标2：定义出每种用户角色所关联的功能组来。PS使用技巧：可以用右键菜单【view diagram

17、as a list】来列表展示图中所有元素效果如下图所示2在需求分析阶段的第二个任务，根据功能组的划分和用例的优先级进行开发顺序的排布。例如：在我们项目中将采用多个版本迭代开发实现的方式，将一个复杂系统的80个用例划分为8个版本实现。每个版本只实现其中的10个用例或者2个功能组。这样进行项目计划的排定和任务的安排。下图显示了我们产品在V1.2版拟定开发的功能组和用例。行动建议：1在版本规划中系统的前几个版本最好完成系统的最基本功能或最主要的业务功能。例如，系统的权限、角色、用户管理、主要的业务流程。我的实践：1将系统用例中已经完成的用例元素拖拽到对应的版本包中，形成链接即可。2为了保证需求不蔓

18、延或业务需求的可追溯性，在完成用例的需求分析之后，将该用例与某个业务需求进行关联，如下图所示，从而跟踪需求。Set the Type of relationship (Implements or Generalizes from the drop-down list. 达成目标：用例模型描述的是新系统规划的功能。它表示用户（人或机器）和系统之间交互的离散单元。该交互是一个有意义的独立单元，如：创建账户，浏览帐户信息。每一个用例描述建立在规划系统中的功能，它可以包含另一个用例功能或用自己的行为扩展另一个用例。一个用例描述通常包括： 描述用例的常规注释和说明 需求 - 用例必须提供给最终用户正式的

19、需求。如： 能更新订单。它们都对应构造方法中建立的功能规范，并建立用例执行动作和给系统提供值的约定。 约束 - 用例运行所遵循的正式规则和限制，它们定义了什么能做，什么不能做。包括： 预置条件是用例运行以前就已经发生了。如：创建订单 必须发生在修改订单 之前。 后置条件是用例完成后必须为真，如：订单修改和一致性检查。 常量在用例的整个运行过程中始终为真，如：一个订单一直有客户号。 情形 用例执行时各步骤正式有序的描述，或用例实例化过程中事件发生的流程。它包含多种情形来应付特殊环境和可选择的处理方式。它们通常由文本建立和对应于顺序图的文本表达。 情形图 - 描绘工作流的顺序图;类似于情形，但是图

20、形化描述。 附加属性，如实施阶段，版本号，复杂性程度，构造型和状态。 执行者 用例通常与执行者关联，执行者可以是人或机器实体，用于系统交互来执行有意义的工作从而帮助他们完成目标。执行者参与的用例定义了它们在系统中总体的作用和动作的范围。包含和扩展用例间的关系一个用例可以包含另一个用例功能做为它自身正常运行的一部分。通常假设在用例运行时被包括的用例每次都会被调用。例如：在修改选定订单前，列出一份客户订单表，每次 修改订单用例执行时， 列出订单用例被调用执行。 一个用例可以被一个或多个其它用例包含。通过将通用的行为提炼成可以多次重复使用的用例，有助于降低功能重复级别。通常，在特别情况下，一个用例可

21、以扩展另一个用例的行为。例如：如果一个用户在修改一个特别类型的客户订单之前，该用户必须得到某种更高级别的许可，然后“获得许可” 用例将有选择地扩展常规的“修改订单” 用例。顺序图 顺序图提供随时间变化，对象交互的图形化描述。通常用来表现一个用户或执行者，对象和组件，以及它们在用例执行过程中之间的交互。一个顺序图典型地表示一个单独的用例情形或事件流。顺序图可以出色的显示文档使用情形，既可以记录早期分析的所需对象，也可以在稍后的设计阶段验证对象。它显示一个对象到另一个对象的消息流，这些消息流对应着一个类和对象支持的方法和事件。下面顺序图例示了左侧的用户或执行者初始化事件和消息流，它们对应于用例情形

22、。在最终模型中，对象间传递的消息变成类的操作。执行图 用例是对所构造系统将有功能的正式描述。与用例关联的执行图用来设计元素（如：组件和类）和实现用例在新系统中的功能。这为系统设计者，客户和团队，这些实际建立系统的人，提供了高级别可跟踪能力。组件和类连接的用例列表说明了必须被组件执行的最少功能。上图说明用例Login实现需求1.01 Log On to the website。也显示组件Business Logic和ASP Pages组件实现部分或全部Login功能。进一步细化可显示Login界面(一个网页来实现Login用例。这些执行和实现连接定义了从正式需求，到用例，直至组件和界面的可跟踪能

23、力。2.2 用例描述与系统测试用例2011年8月13日14:042.3 概念模型2011年8月11日18:33概念模型的建立不应该从数据库存储的角度来考虑，而应该从业务对象角度来考虑。2.4 非功能性需求2011年8月13日14:042.5 系统界面原型2011年8月13日14:05界面原型建模在需求分析阶段，所有功能的界面原型建模需要完成的工作，需达到的标准：1界面元素、颜色、字体大小、布局风格、交互方式、功能排布、输入输出模式2需要确定并遵循【界面设计规范】3 界面原型建模工具：可以使用RP、（VISIO？）4需要描述控件的动作事件、状态的变化控制2.6 动态行为分析2011年8月13日1

24、3:26一、工作流程用活动图可以进一步详细描述部分用例的工作流程。在需求分析阶段，可以用活动图来描述如何通过用例来完成某项业务流程。活动图中的每一个活动都可以建立与某个用例之间的关联存在问题：对于常见的管理任务、管理员工之类的业务入口应该与几个活动进行关联？二、消息与对象交互采用时序图来描述系统概念对象是如何通过消息按照时间顺序交互的。它首先关心客户所关心的高级信息。这时候概念对象还没有映射类，消息还没有映射成操作。这些图是让系统分析人员、系统用户和其他对业务流程感兴趣的人了解系统的逻辑流程。其次，它在与用户在业务流程达成共识后，将对象映射成类。3 AD系统概要设计2011年7月8日0:35概

25、要设计也称为架构设计。由产品研发经理（或高软）负责，主要任务：建立系统的逻辑视图、明确类的层次结构、类的定义、必要时进行类行为的描述。 边界类V、控制类C、实体类M3.1 定义系统的物理架构。通过部署视图来定义系统的物理架构。这项工作可以提前开始以便于掌握系统的物理结构特性-使用什么样的硬件、操作系统、网络规模、接口与支持软件，来构成新系统，和系统部署在那里，以及出现灾难性故障时的系统恢复，系统可靠性、系统备份与支持等方面所使用的参数。随着模型开发的不断进展，物理系统模型应该不断更新以反映所开发系统的实际情况。 3.2 建立系统的逻辑视图 通过类图（明确类的属性、方法）来实现在领域模型、用户接

26、口模型和情形图的基础上，开始建立对象类模型。这是制定系统中对象的明确规范：数据、属性、行为和操作。使用继承机制，可将领域对象抽象为类层次结构。处理各种情形的消息一般被映射到类的操作。如果使用一个现存的框架或设计模式，则可能导入现存模型的元素到新系统中。为每一个类定义单元测试、集成测试和系统测试。测试目的：1）类的功能是否如所定义的，2）类与其它类及组件的交互是否如期望的。 3.3 建立系统的部署视图、开发视图（组件图）当开发类模型时，可能需要将它分解成包和组件。一个组件代表一个可使用的软件块，它是一个类或者多个类的数据和行为的结合，并严格定义一个对外提供服务的接口。所以，从类模型的角度看，构造

27、组件模型就是定义类的逻辑包。对于每一个组件，需要定义集成测试，以证实组件的接口满足规范要求，即与其它软件元素的关系。 3.4 数据库设计架构设计1常用的架构技术为分层MVC等思考：对于我们这个BS+CS架构的产品而言，CS部分的客户端程序如何将表示层和业务逻辑层分开？是一个问题，特例化的考虑是从函数名称和归类上予以区分，所有业务逻辑层的函数以单独的程序文件和函数来实现。所有表示层的处理放置到其他程序文件或函数中去。Web应用则基本采用MVC或者扩展层数（增加持久化层）的的架构另外一个思考：如果将CS客户端程序的C端的业务处理采用JAVA来构筑成为服务的形式，则C端的表示层通过调用接口来找到特定

28、业务逻辑，从而完成三层的划分。但这样 做是否值得？考虑SOA思想及重用 的概率则再casebycase地讨论存在问题：对于类的不同状态，在不同阶段应该如何去展现？3.5 系统逻辑视图2011年8月13日14:41主要任务为建立系统所有的类图，其中定义了类的属性、操作，以及类操作之间的关系第一阶段：目标：建立系统功能的逻辑结构方法：以多层嵌套包+底层类图的展现形式来设计系统所有的类。指南1：子系统为顶层包、下属的模块为次级包、最底层包为模块的功能。最底层的功能包将包括实现某个功能所涉及的边界类、控制类、实体类，仅需定义出类名称即可。指南2：通过分析用例，定义出该用例涉及到当前底层功能包的边界类、

29、控制类、实体类说明：一个用例可能涉及到多个底层的功能包。第二阶段目标：初步实现系统用例步骤1：在【系统功能结构】的基础上，定义出每个类所拥有的操作。步骤2：定义并描述这些类的操作之间的互动关系。可以通过为最底层包的每个功能绘制时序图来实现。绘制时序图的建议颗粒度是用例中的某个事件（可能是初始化表示、可能是点击某个按钮触发的画面迁移）。指南1：在这个过程中可能发现某些类为系统通用的方法，则抽取出来单独建立一个包（包中为共通类以及类的操作）。指南2：为了便于开发，可建立边界类与界面原型的关联关系。指南3：也可在分析完所有用例的所有类的操作之后将这些类进行分包、分层构筑成（有层次的）系统逻辑视图模型

30、3.6 数据库设计2011年8月13日14:511数据库所有表的概要设计定义出数据库 中 所有表以及表的大部分字段的名称、属性以及非空项、主键、外键等。2描述数据间的相互关系 数据表间的三种 关系：组装关系、分类关系、关联关系要求：全面建立所有数据的关系，尽可能消除孤立数据 3.1概要设计2011年8月9日22:431描述软件的全部结构2描述软件 总体运行过程3 定义出系统中所有的边界类、控制类和实体类实体对象：这些对象保存信息,最终可能映射成数据库中的表和字段.例:学生*,1020航班等.边界对象：位于系统与外部世界之间的边界上.窗体或窗体与应用程序的接口控制对象：是可选的对象,控制用例的流

31、程4描述出信息或数据的流动情况用边界类、控制类和实体类来构造出时序图5定义好模块间的数据传递例如：父级模块传递给子级模块的数据和子级模块返回的数据3.2概要设计的方法2011年8月12日15:191 6建立初步的数据库模型，包括表的属性、类型6.1建立数据库模型的方式方法：可以将所有实体类拷贝到数据库模型包里，名称可以一致6 为数据库模型中的所有表与实体类之间建立关联关系。存在问题：用例的实现如何体现？实践1： 在创建实体类的时候可以基于既有的概念模型进行，这样原来概念模型内的注释就可以保留下来。实践2：在数据库设计之初，最好基于实体类继续拷贝，并作为一个新的实体来粘贴，从而保证设计思路的延续

32、。4 DD详细设计及实现2011年8月9日22:43介绍：由高软或中软负责,主要任务：以用例为分配单位，针对组成用例的所有类和界面：细化用户界面定义、细化数据库设计、提出用例的每个类的方法定义、完成针对类的单元测试、针对用例的集成测试。步骤1：详细设计和开发 将用例分配给开发人员，来定义用户界面、数据库设计、同时针对实现该用例的每个类，完成单元测试、用例内的集成测试、以及根据已经定义的用例系统测试用例进行系统测试。步骤2：构造系统：将模型的分散模块分配给一个或多个开发者。如果采用用例驱动的方法构造系统，这将意味分配一个用例给开发小组，让他们构造用户界面，业务对象，数据库表以及执行该用例所必须的

33、相关组件。在构造每个用例时，应该同时完成单元测试、集成测试和系统测试。如果采用组件驱动的方法构造系统，则需将各个组件分配给开发小组。1设计用户界面及其画面迁移关系2进行数据库的逻辑设计 定义主外键、保持数据一致性定义数据表所有属性值的长度、具体类型建立关联表、消除多对多连接关系3进行数据库的物理设计 定义表的索引、优化数据检索垂直分割数据表，优化数据存取定义视图、存储过程，为编程提供方便需要细化确认界面、数据库设计、主要任务：对类的关键方法进行算法的设计。伪代码：如果 任务的状态=1 则任务新增成功否则 如果任务的xxx ze4设计模块针对关键模块，写出实现逻辑的算法5. 生成程序 5 过程控

34、制2011年8月18日18:18由产品研发经理负责，主要任务：需求变更监控、缺陷跟踪1缺陷跟踪对照模型中的元素，跟踪查找出现在测试阶段的缺陷。如：查看针对用例的系统测试缺陷，查看针对对象类的单元测试缺陷等等，跟踪相关模型元素的修改以防止范围漫延。 2需求变更、定时评价系统随着工作进展不断更新和完善模型-每次修改模型或完善模型，都要评价所做的修改或改善对后续工作的影响。在模块设计中使用反复式工作方法，评介当前构造的模块，新到达的需求，以及开发过程发现的任何问题。 6 系统测试2011年8月18日18:18由产品测试部人员负责，主要任务：系统测试UML入门培训2011年8月9日23:15EA使用技

35、巧2011年7月20日23:191 The fastest and simplest way to create elements directly on a diagram is to press Spacebar or Insert on the diagram2 If you are creating several elements of one type, after creating the first just press Shift+F3 or Ctrl+click to create the next element of that type.EA中的需求跟踪矩阵2011年8

36、月2日20:46一、我的理解：在EA中可以通过对视图中的元素设定父元素，从而实现跟踪矩阵。二、在软件工程中我们需要关注的需求跟踪关系主要有2个层次或关联关系：1从业务需求到系统用例2从系统用例的usecase到概要设计的class3从系统用例usecase到界面原型screen的关联EA中的界面原型2011年8月2日23:42目前已知的，EA创建的use interfac 图，可以精确定义出用户界面，但无法导出为页面EA中的版本控制2011年8月12日15:29当模型中的包结构发生改变时（例如增加了某个分支包或者删除了已有的包），需要如下操作最常用的EA中的版本控制命令如下：UML系统建模与分

37、析设计2011年8月7日8:50系统建模预分析设计技术的演变2011年8月7日8:501.3软件开发模型瀑布模型渐增模型（迭代模型）原型法模型螺旋模型目前实践的是迭代模型2011年8月7日8:502011年8月7日8:502011年8月7日8:502011年8月7日8:50面向对象的软件工程2011年8月13日16:08OOA的定义用面向对象方法分析问题域，建立基于对象、消息的业务模型，形成对客观世界和业务本身的正确认识。生成业务对象的动、静态模型和抽象类(问题域OOD的定义针对OOA给出的问题域模型，用面向对象方法设计出软件基础架构（概要设计）和完整的类结构（详细设计），以实现业务功能。生成

38、对象类的动、静态模型（解决域）1概述2011年8月13日16:081对象的定义对象: := 。其中，ID是对象的标识，MS是对象中的操作集合，DS是对象的数据结构，MI是对象受理消息名的集合。2消息的定义消息就是对象提供某个外部操作的规格说明。消息通常由3部分组成：接收消息的对象；消息名称；零或多个变量；3多态性的定义多态性是指子类对象可以象父类对象那样使用，同样的消息既可以发送给父类对象也可以发送给子类对象2UML概述2011年8月13日16:23对于非功能性需求在UML、或者面向对象软件工程中应该如何去考虑并实现？UML的九种模型图2011年8月13日16:40 需求分析阶段用用例；分析阶

39、段用类图；实现阶段用动态模型；构造阶段用OO编程语言。 各种模型图在软件开发过程中的应用范围标准建模过程用例图2011年8月13日16:28从用户角度描述系统的行为，并指出各功能的操作者如何寻找用例1 Actor希望系统提供什么功能2 活动者在系统中访问哪些信息 (创建, 存储, 修修改, 删除等?3 外部的哪个变化将要被告知系统？4 系统的那个事件将要被告知活动者？5 系统将要怎样维护?6系统是否存储和检索信息，如果是，这个行为有哪个Actor触发7存在影响系统的外部时间吗需求分析时用例的颗粒度系统执行该动作序列来为Actor产生一个可观察的结果值所以对于 Actor来说：检索任务、创建任务

40、、修改任务、删除任务这些都属于用例，而【管理任务】只是一个集成的入口，应该不是用例。如何检查用例的完整性是否考虑了每个操作者如何使用系统.每个操作员向系统提供了什么信息.每个操作员从系统接收了什么信息.是否考虑了维护问题,要有人启动和关闭系统.是否标示了系统要交互的所有外部系统.每个外部系统从系统接收什么信息和系统发送什么信息?一个好的 use case必须传递 某种事物的值给 an actor.业务需求到系统用例的跟踪系统用例描述时所需填写的模板内容前提条件列出开始使用案例之前必须满足的条件.例如:前提条件可能是另一个使用案例已经执行或用户具有运行当前使用案例的权限.主事件流和其他信息流o

41、使用案例如何开始o 使用案例的各种路径o 使用案例的正常(主流程o 使用案例主事件流(其他事件流的变形o 错误流o 使用案例如何结束-1 事件流中的步骤：最小粒度应该是系统或活动者的某个动作或做出的响应，例如：执行【查询】，给出XX提示等等。-2 主事件流、其他事件流、错误事件流如何书写：示例：主事件流示例：其他事件流示例：错误流用例建模易犯的错误只描述了用户的交互，而忽略了系统的反应。写了功能需求，而不是使用事件流文档。类图 2011年8月13日16:27类图：展示对象类、接口、及其相互合作与关联类图用于定义系统中的类，包括描述类之间的联系(如关联、依赖、聚合等以及类的内部结构，即类的属性和

42、操作类的接口对应于需求要求的服务构件图(组件图2011年8月13日16:27构件图：描述部件的物理结构以及各部件之间的依赖关系PS：构件图可以看到某个需求变更或代码调整对系统造成的影响。配置图2011年8月13日16:28配置图定义系统中软硬件的物理构架时序图2011年8月13日16:29重点描述消息发生的事件顺序。用以显示对象之间在时间顺序方面的动态合作关系。因此，如果强调时间和顺序，应当使用顺序图。顺序图的要素对象：对象、对象的生命线、激活的对象和对象的删除。消息：简单消息、同步消息、异步消息、返回消息。条件、注释体和注释连接。如何创建时序图.寻找对象.寻找角色. 将消息加进框图时序图的作

43、用分析人员可以从Sequence框图看到处理流程。开发人员可以看到需要开发的对象和对这些对象的操作。测试人员可以看到过程的细节，并根据这个过程开发测试案例。包图2011年8月13日16:32包图由包或类组成，主要表示包与包、或包与类之间的关系。包图用于描述系统的分层结构状态图2011年8月13日16:33状态图描述一类对象的所有可能的状态以及事件发生时状态的转移条件活动图2011年8月13日16:34活动图描述为满足用例要求所要进行的活动以及活动间的约束关系。使用活动图可以很方便地表示并行活动。对于侧重于工作流过程的应用系统，活动图非常有用活动图2011年8月13日16:35着重描述对象间的通

44、信方面的动态合作关系。因此，如果强调通信关系，则可以选择合作图基础-用例图2011年7月12日23:03 用例图中的关系参与者与用例之间关联关系用例与用例之间包含关系 (include延伸关系 (extend泛化关系 (generalization参与者与参与者之间泛化关系 (generalization 用例 表现从外部看到的系统功能（行为）。 为系统的外部（用户等）实现的业务目标的系统功能称为用例。 系统内部处理（粒度详细的处理）不属于用例。 关联表现参与者与用例间的关系。（功能与用户的关系） 包含（include）表示一个用例为另一个用例的部分功能。 可以说:扩展是对用例功能的扩充【身份

45、验证】在【用户忘记密码】的场景下，被【找回密码】用例扩展了，也可以说【找回密码】用例使用了【身份验证】用例。基础-活动图2011年7月12日23:39 表现处理的顺序基础-类图2011年7月12日23:57 可视性o 表现属性或操作向外部公开的级别public（向外部公开）protected（仅向子类公开）private （不公开） package（同一包内公开） 泛化与特化o 泛化o 把类抽象化作成其他的类。o 特化 把类具体化做成其它的类。o 特化的类将继承元类的所有属性，操作，关系等。 聚集表现类之间存在全体部分的关系。 组合o 表现类间具有很强的全体部分关系。o 全体销毁了，部分也将被销毁。o o 关联类表现类间关联的信息。 依存o 表现某一个类临时使用其它的类。（仅在某个