UML构件面向分析与设计-uml面向对象分析与设计

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

UML构件面向分析与设计

1.分析模型

　　首先看一下UML构件面向分析与设计，我们是通过对用例的分析，从而形成分析模型(AnalysisModel)来完成分解的工作的。

　　分析模型采用MVC模式，在系统架构和框架的约束下，来分析用例的实现的。在分析过程中，将使用UML的语言来描述系统中的人、事、物、规则(actor，boundary，engity，control)之间的交互和动作的。通过使用UML的时序图将是将用例中所包含的业务处理流程表示出来，一方面能够对功能进行粒度较细的分解，另一方面又能有效的指导设计与实现。

　　在分析工作中，有以下主要的产出：

　　分析类—业务领域中建模的主要概念，代表了系统设计中的类或子系统的抽象。分析类代表“系统中具备职责和行为的事物”的初期概念模型。这些概念模型最终将演进为设计模型中的类和子系统。

　　用例实现—演示分析类的实例如何交互以实现由用例所说明的系统行为。用分析类及交互图(协作图、顺序图)来表示。

　　1.1寻找分析类

　　分析类的构造型可分为以下几种：边界类(BoundryClass)、控制类(ControlClass)、实体类(EntityClass)。

　　边界类是一种用于对系统外部环境与其内部运作之间的交互进行建模的类。这种交互包括转换事件，并记录系统表示方式（例如接口）中的变更。

　　控制类用于对一个或几个用例所特有的控制行为进行建模。控制对象（控制类的实例）通常控制其他对象，因此它们的行为具有协调性质。

　　实体类是用于对必须存储的信息和相关行为建模的类。实体对象（实体类的实例）用于保存和更新一些现象的有关信息，例如：事件、人员或者一些现实生活中的对象。

　　考虑参与者“故障派单人”执行用例“派发故障单”这个场景。用MVC的模式对该用例进行分析：故障派单人需要在某个界面上(边界类)，录入故障信息，然后提交给业务逻辑处理(控制类)；业务逻辑负责保存故障工单信息(实体类)。经过对用例“派发故障单”的分析，我们得到以下的分析类：

　　1.2用例实现

　　UML构件面向分析与设计中用例实现是描述如何在设计模型内部利用协作对象来实现一个特定的用例。对于每个用例，都可以用一个或多个交互图来描述它的参与对象以及它们之间的交互。多数情况下，我们使用序列图来说明对象如何通过交互来执行全部或部分用例的行为。

　　序列图对设计人员特别重要，因为它们明确了构件在调用流程中的角色，因而可以为确定构件的责任和接口提供基本的输入。

　　通过对用例“派发故障单”的分析，我们绘制作了以下的顺序图：

　　可以看到，顺序图是以交互为主线，将交互过程中各交互对象识别出来，并由上至下、从左到右，以时间发送为序，将交互关系表示为一个二维图的。纵向是时间轴，时间沿竖线向下延伸。横向轴代表了在协作中各独立交互对象。

　　1.3分析模型与EOS构件

　　绘制出上面基本的顺序图之后，我们还需针对“派发故障单业务逻辑”进行细化。将业务逻辑中的处理操作的步骤分析出来，将其中的操作分散在各构件包中，并将构件包调用关系在顺序图上描绘出来。

　　在这里我们先对构件包的概念和分包的原则进行阐述。

　　EOS构件包是由六种构件(业务构件、展现构件、页面构件、数据构件、运算构件、工作流构件)（或者其中的几种）组成，是EOS系统发布、复用的基本单位，它由一组相关的EOS构件组成，能够完成相对独立、完整的业务功能。EOS构件包中可以包含一个或多个的EOS构件，它相当于一组有关系的构件的容器或命名空间(Namespace)。

　　UML构件包分包原则：

　　1.相关性：从应用功能维度上，每个构件包实现了一组具有相关性的业务功能。在划分构件包过程中，始终要考虑在构件包中的构件在业务上是否有相关性。如对工单(数据或流程)的一系列操作，从业务角度看，是具有高度的相关性，因此可以形成一个工单构件包。

　　2.公共性：实际上构件包可以理解为业务功能分解后的功能模块。对业务功能分解之后，往往能抽取出一些具有公共性的操作，比如附件管理、记录日志、查询待办工单等等。这些操作不直接与业务相关，但能提供给业务流程各个环节中复用。因此可以形成一个通用构件包。

　　根据对某故障流程的分析，按照业务功能相关性的原则，我们将业务逻辑分为以下五大构件包：

　　工单构件包：提供与故障工单相关功能的一组构件包，例如：设置工单状态，获取故障工单信息，获取工单处理情况等等；

　　任务单构件包：提供与任务单相关功能的一组构件包，例如：设置任务单状态，分派任务单，保存任务单等等；

　　通用构件包:提供在其他构件包调用到的通用功能的一组构件包，例如：上传附件，管理附件权限，发送短信，保存工单时限设置等等；

　　接口构件包：提供与接口解析相关功能的一组构件包，例如：自动派单，半自动派单，草稿生成工单，告警工单处理状态实时通知等等；

　　统计构件包:提供与KPI相关功能的一组构件包，例如：统计故障处理及时率，统计故障一次处理完成率，统计故障一级解决率等等。

　　对于同一个系统，不同的人对于构件包分包都可能有不同的拆分结果。我们需要在多种分包方案中选择一种"***"（或"较佳"）的结果。一个好的分包方案应该能够容易被业务分析人员、系统设计人员及系统开发人员等所理解。

　　针对“派发故障单业务逻辑”，我们进行再次分析，结合流程特点和业务功能，重新绘制新的顺序图，将派发过程中“工单构件包”、“通用构件包”等协作交互表达出来。首先，在请求派单阶段，系统在显示派单信息录入界面，需要自动匹配告警监控网管信息和告警级别；其次，如果派单人在派单界面上进行“抄送”操作，系统需要显示抄送人员列表供其选择；再次，如果派单人进行“上传附件”操作，系统需要提供附件上传功能；***当派单人选择提交派单，系统将调用工单构件包中的保存故障单信息功能构件，在此保存故障单信息的过程中，还需调用通用构件包中的获取工单时限设置、获取工单派单对象，完成保存后还需调用完成工作项、设置流程活动的参与者、设置流程的流转条件等。

　　如下图所示，在派发故障单过程，我们经过分析抽取出以下细粒度的功能：匹配告警监控网管信息、映射网管告警级别、获取抄送人员、上传附件、保存故障单信息、获取工单时限设置、获取工单派单对象、完成工作项、设置流程活动的参与者、设置流程的流转条件。

　　根据“派发故障单”的用例实现顺序图，我们将顺序图上的操作功能映射到功能跟踪矩阵。映射的一般原则是，由界面(派发故障单页面)开始的操作功能映射为功能点，如“获取抄送人员”，“上传附件”等；由构件包（工单构件包、通用构件包等）开始的操作映射为功能分解，如“获取工单时限设置”、“获取工单派单对象”。映射完成的功能跟踪矩阵，如下图所示：

　　这样我们经过用例分析，和用例实现分析，逐步细化的得到了系统功能跟踪矩阵。

　　对所有的用例进行分析，并绘制出顺序图之后，我们将获得如下构件包图：

　　以上的UML构件包图，共有五个构件包，每个构件包中都包含若干个操作功能，每一个操作功能都可以映射成一个独立的业务处理逻辑构件。这些构件涵括了某故障流程各环节中处理的功能。以该用例模型为基础，能有利于我们形成功能分解矩阵，也能有利于我们识别可复用构件。

【编辑推荐】