UML软件工程组织

1、概述
实时监控应用软件（CTS）开发过去采用的是结构化方法，采用的编程语言也是汇编语言、FortranAda等结构化编程语言。也曾有过分析和设计阶段采用结构化方法，编程实现采用面向对象语言的尝试。

采用面向对象方法（UML）完整的实现监控实时应用软件是首次尝试，收到了较好的成效。

UML（统一建模语言）是美国Rational公司创造的面向对象开发中一种通用的、统一的图形化模型语言。

它于1997年11月被美国OMG小组批准成为面向对象开发的行业标准语言。UML标准的树立统一了面向对象的建模方法，消除了对象建模差别。Rational公司的旗舰产品之一Rational Rose提供了对这一行业标准语言的充分支持。

Rose是一个面向对象的软件分析设计建模工具，可以创建基于UML标准的模型，图形化地对软件系统结构加以描述和定义，并且通过建立的模型直接生成代码框架。

同时，还可以从开发者编的应用系统中直接逆向生成模型。下面将就实时监控应用软件的分析设计是如何使用Rational Rose来实现的作一简要介绍：

2、UML模型 CTS是监控系统的中心，它主要用来控制测量设备实时跟踪和测量飞行目标，实时处理测量结果，并兼有显示、打印、记录等功能。它和测量设备的关系如图1所示。

实时应用软件通过数据包和测量设备交换信息。软件实时性要求较高，在每个采样周期内，必须完成该周期的数据处理工作，也要有一定的人工干预能力。实时应用软件模型用来描述软件各层次的各个方面，它包括Use Case图、类图、序列图、状态图、分布图和组件图。

2.1 Use Case图Use Case 也称为用例、使用情况，它是系统分析人员从用户使用的观点来看系统功能、功能之间的关系以及用户与功能之间的关系。它是系统功能以及用户与功能之间的关联，利用 Use Case系统分析人员对系统的功能和行为加以描述。CTS的Use Case图如图2所示。CCP为前端通信处理机，Operator为操作员，Interrupt为操作台命令产生的中断。Simulation 模拟状态，用于软件调试和操作员训练。 Task：实战状态，用于实战任务。 Abnomity ：异常处理，应急状态。 SimpleServer：打印、记盘等服务。CommuniciateProcess：从CCP接收测量设备传来的数据包之后解包，然后按要求将多帧数据重新组织成一帧转发到CCPDataProcess：将CommuniciateProcess接收的数据依据处理要求进行挑点处理，利用 CommuniciateProcess解包后的数据计算轨道、平滑外推和预报等。DisplayProcess：将挑点后的数据按指定的要求在不同的显示服务器上以文字、数字或图象形式显示。将 DataProcess的处理结果在指定的显示服务器显示。所有Use Case的工作都必须在指定的时间周期内完成。2.2 类图

类图是系统的逻辑结构，是模型的核心部分。它描述了系统中的类及类之间的关系，类图描述系统的静态结构。类包是子系统中相关类的集合，包类似于 Peter/Coord 方法中的主题词（ subject ）。图 3 描述了 CTS 的类包。

类包 DisplayProcess 、 DataProcess 、 CAbnormity 和 CommunicateProcess 是我们自己开发的，是系统的核心，其余的类包是由 Microsoft 提供的。 DisplayProcess 类包包含了显示所需要的所有和 MFC 有关的类， DisplayProcess 类包中的类都是从 MFC 派生的，一般都增加了 CTS 系统所需要的特性。 DisplayProcess 类包中的类及类之间的关系如图 4 所示。

　图4 DisplayProcess 类包中的类及类之间的关系
CommunicateProcess 类包包含了通信处理所需要的类及类之间的关系，如图 5 所示。图中 CFrameFormat 类为数据帧格式类是所有帧格式类的父类，它有两个子类： CRecvFrameFormat 和 CSendFrameFormat 。 CRecvFrame- Format 类（从 CCP 接收的帧格式）是 CRecvHead 类（接收帧头）和 CDevice- Format 类（设备数据格式）的聚集。 CSendFrameFormat 类（向 CCP 发送的帧格式）的数据区包括 Device1 ～ Device3 帧格式中的内容。 CReceive 类为接收类， CSendTo 类为向 CCP 发送数据类。

图5 CommunicateProcess类包中的类及类之间的关系

DataProcess 类包是 CTS 类包中的核心部分包括了数据处理所需的所有类，这个类包较复杂这里只给出部分类图，如图 6 所示。 CGdFeature 类是数据处理部分的类它有两个最主要的操作：轨道积分和坐标转换， CTheoryGd （理论轨道）， CPracticeGd （实际轨道）， CCoordinatePoint （轨道坐标）， CRate （目标速度）。

6 DataProcess类包中的部分类及其关系，CAbnormity类包包含异常处理以及操作台应急处理所需要的类，类图略。

　

2.3 序列图

CTS 的动态特性用序列图表示，序列图用来描述一个软件的运作顺序（场景），一个 Use Case 包含多个软件的运作场景。序列图用来刻画 Use Case 图，一个 Use Case 可以有多个序列图，每个场景用一个序列图刻画。合作图与序列图等价，可以由序列图转化得到，两者各有优缺点。序列图对于实时系统的时间要求刻画的很好，但结构不明显；合作图的对象间关系明显但它用消息顺序号表示时间，时间表示不清楚，不太适用于实时系统。 CommuniciateProcess 的序列图如图 7 所示。

图 7 CommuniciateProcess 的序列图

2.4 状态图

CTS 的动态结构主要用来描述活类的动态特性，使用 Rational Rose 的状态图 StateDiagram 来描述。行为导致了状态的迁移，状态图用来显示一个给定类、给定事件的状态。每个状态图都与一个类或一个 Use Case 相关联。状态图刻画软件系统的行为视点，它基于有穷状态自动机的图示机制。一个状态图包括一个类在生命周期内的状态转换和描述。限于篇幅只给出 CTS 的 CGdFeature 类的状态图，如图 8 所示。

图8 CGdFeature类状态图

2.5 组件图

逻辑模型表示了系统的逻辑结构，每个逻辑模型都应有一个或多个到物理实现－组件图的映射。组件图显示了物理上组件（主程序、包和任务）之间的依赖关系以及和逻辑模型之间的映射关系。组件的设计和系统的运行环境以及逻辑模型的结构有关。如果是分阶段开发的话，组件设计应属于详细设计。

2.6 软件分布图

软件系统需要和硬件环境一起工作，软件分布图也表示了硬件设备和它们的界面，以及硬、软件的协同工作。 CTS 的软件分布图表示了执行程序、计算机节点以及设备的布局。 CTS 的分布图如图 9 所示。图中 Main 和 Backup 分别表示主用和备用计算机，只有主用计算机向 CCP 输出，但主备机均接收 CCP 来的数据。

图 9 CTS 软件分布图

3 实现

在系统的逻辑设计（模型）和组件设计（模型）完成之后，便可以进入编程。 CTS 的编程实现采用 Microsoft 的 VC 语言， Rational Rose C 对 VC 有专门的支持。编程实现主要是利用 Rose 的生成和反向生成工具根据系统的设计模型来完成的。它包括三大步骤，每个步骤又包括多个过程。

3.1 系统设置

系统设置主要用来设置 Rose 的特性和目录，它包括四步，这里就不详述了。

3.2 开始一个新的VC 项目

在开始 VC 编程时，首先创建 VC 应用程序，此时应遵循以下步骤：
使用VC 的Application Wizards 为应用生成框架

创建Rose 分析器Analyzer 下的项目，加入VC 创建的文件
定位头文件，关闭不含类也不能由分析器生成和反向重新生成的文件的Regenerate 属性，并向Rose 输出初始模型。

在 Rose 下打开 .red 文件

反向生成的模型不带特性，选rosevcpp.pty 文件作为新的特性文件，最后把模型保存为 .mdl 文件。

　

3.3 增加类、数据成员和成员函数

把 Rose 模型中的类增加到 VC 应用程序中可分为两种情况：一种是不使用 VC 的 Class Wizard 支持机制的类（如信息映射），一种是使用此机制的类。

前一种情况比较简单，它正是在 Rose 中生成代码，然后把这些文件加入 VC 项目中即可。对于后一种情况，其步骤大致如下：
　
在 VC 中创建新类，然后将新类的文件加入 Rose 的 Analyzer 对应的项目中。

在分析器Analyzer 中进行特性设置以反映项目当前的变化。
在分析器Analyzer 中输出文件。向已经存在的文件中添加数据成员和成员函数的方法与添加类的方法相同。
4、结束语从应用的结果看，总的来说，使用 UML 进行监控实时应用软件开发取得了比较好的效果，与以前使用的结构法方法相比有明显的优势。我们体会，这主要表现在以下几个方面：
1.Use Case 是系统分析人员从用户的视角出发、从功能边界描述目标软件系统，这从模型上规范了对需求的描述，也能够和后面的设计较好地衔接，比以前纯粹的文字描述要好一些。用
2. 逻辑设计代替功能模块设计和实体－关系设计，解决了以前的功能和数据分离的问题，以及模块中数据的组织问题。
3. 用状态图在较高的层次上描述了系统的动态结构。
4. 由于同时使用了文档生成工具，使得系统设计和文档、程序代码保持一致，较好的解决了极易造成的文档和实现不一致的现象。这一点非常重要。