用UML构件进行面向构件分析与设计-uml构件图

用UML构件进行面向构件分析与设计

本文提出了如何使用UML构件和用例分析技术进行面向构件的分析与设计。在一些大型的项目开发环境中，由于各开发设计人员的经验不一，采用通用的标准的方法来进行需求分析、功能分解，能够使整个团队以及开发过程获益。

　　以下以某业务流程为例，概要介绍如何使用本方法，进行分析，以及如何分解得到EOS构件。详细的用例分析技术、分析模型技术由下文进行阐述。

　　本文附带一个UML构件分析的样例模型，以供参考。(在Rose中导出来的，html版本，用IE可以直接浏览)。

　　1用例分析

　　用例方法首先描述了系统有哪些外部参与者（抽象成为Actor），这些参与者与系统发生交互；针对每一参与者，用例方法又描述了系统为这些参与者提供了什么样的服务（抽象成为UseCase），或者说系统是如何被这些参与者使用的。所以从用例图中，我们可以得到对于系统的一个总体功能的集合。

　　与传统的功能分解方式相比，用例方法完全是从外部来定义系统的功能，它把需求与设计完全分离开来。用例定义了系统功能的使用环境与上下文，每一个用例描述的是一个完整的系统服务。用例方法比传统的功能分解方法更易于被用户所理解，它可以作为开发人员和用户之间针对系统需求进行沟通的一个有效手段。

　　1.1寻找参与者(Actor)

　　用UML构件进行面向构件分析与设计时参与者是指所有存在于系统外部并与系统进行交互的人或其他系统。通俗地讲，参与者就是我们所要定义系统的使用者。寻找参与者可以从以下问题入手：

　　谁使用系统的主要功能？

　　谁负责处理流程中的环节？

　　谁从系统获取信息？

　　谁负责维护、管理并保持系统正常运行？

　　系统需要和哪些外部系统交互？

　　有时候我们需要在系统内部定时地执行一些操作，如当任务到达时自动发送通知短信、当任务超出处理时限自动发送催办通知、定期地生成统计报表等等。从表面上看，这些操作并不是由外部的人或系统触发的，应该怎样用用例方法来表述这一类功能需求呢？对于这种情况，我们可以抽象出一个系统时钟或定时器参与者，利用该参与者来触发这一类定时操作。

　　以派发故障单环节为例，故障派单人负责使用派单功能，因此需要派单人这个参与者。经过对某流程各环节的分析，我们识别出以下参与者：

　　1.2寻找用例(UseCase)

　　用UML构件进行面向构件分析与设计时找到参与者之后，我们可以根据参与者来确定系统的用例。主要是看各参与者需要系统提供什么样的服务，或者说参与者是如何使用系统的。寻找用例可以从以下问题入手（针对每一个参与者）：

　　参与者是否在系统中创建、修改、删除、访问、存储数据？

　　参与者如何驱动流程的流转，对流程中的环节进行了哪些操作？

　　参与者是否会将外部的某些事件通知给该系统？

　　系统是否会将内部的某些事件通知该参与者？

　　在用例的抽取过程中，必须注意：用例必须是由某一个参与者触发而产生的活动，即每个用例至少应该涉及一个参与者。如果存在与参与者不进行交互的用例，就可以考虑将其并入其他用例；或者是检查该用例相对应的参与者是否被遗漏。反之，每个参与者也必须至少涉及到一个用例，如果发现有不与任何用例相关联的参与者存在，那么该参与者可能是一个多余的模型元素，应该将其删除。

　　在用例建模过程中必须注意参与者和用例的名称应该符合一定的命名约定，如参与者的名称一般都是名词，用例名称一般都是动宾词组等。

　　用例分析就是分析什么人做什么事，描述做事要描述详细到什么程度呢？这就是粒度问题。一个用例的粒度是否合适，是以该用例是否完成了参与者的某个目的为依据的。举个例子，某人去图书馆，查询了书目，出示了借书证，图书管理员查询了该人以前借阅记录以确保没有未归还的书，最后借到了书。从这段话中能得出多少用例呢？用例分析是以参与者为中心的，因此用例的粒度以能完成参与者目的为依据。这样，实际上适合用例是：借书。只有一个，其它都只是完成这个目的过程。现实情况中，一个大型系统和一个很小的系统用例粒度选择会有一些差异。这种差异是为了适应不同的需求范围。一般来说，一个系统的业务用例定义在多于10个，少于50个之间，否则就应该考虑一下粒度选择是否合适了。

　　对于同一个系统，不同的人对于参与者和用例都可能有不同的抽象结果，因而得到不同的用例模型。我们需要在多个用例模型方案中选择一种"最佳"（或"较佳"）的结果，一个好的用例模型应该能够容易被不同的涉众所理解，并且不同的涉众对于同一用例模型的理解应该是一致的。

　　以派发故障单环节为例，参与者“故障派单人”需使用派单功能，来完成对故障工单派发的目的，因此形成派发故障单这个用例。

　　经过对某流程各个环节的分析，我们抽取出以下用例：

　　以上的用例模型，除了从流程环节功能分析得到的用例外，还有一部分是从通用功能角度分析而来的，如：查看日志，查看流程图等等。

　　1.3用例分析与功能分解矩阵

　　用UML构件进行面向构件分析与设计过程中经过以上分析获得的用例模型，一方面是用标准的需求分析方法对流程环节的功能进行了描述，另一方面也为我们进行下一步骤的功能分解打下了扎实的基础。

　　在建设用例模型的过程中，我们以流程名称建立一级包名，以环节名称建立二级包名，如下图所示：

　　在将用例模型映射到功能跟踪矩阵的过程中，一般的规则是：一级包名映射到一级模块，二级包名映射到二级模块，用例名称映射到三级模块。以用例模型为基础，我们将用例包名和用例名称映射到功能跟踪矩阵中，得到如下的功能跟踪矩阵：

请关注下节用UML构件进行面向构件分析与设计介绍。

【编辑推荐】