青岛大学

硕士学位论文

基于UML的MES设备管理构件化研究

姓名：陈伟

申请学位级别：硕士

专业：计算机软件与理论

指导教师：魏长江

20070601
 摘要

软件复用是软件工程的重要领域，被认为是解决软件危机，提高软件生产率和
软件质量，增强软件的开放性和适应性的主要途径。基于构件的软件复用是当前复
用研究的焦点，被视为实现成功复用的关键因素之一。
制造执行系统（ＭＥＳ）是连接企业计划管理层和底层控制之间的桥梁，是企业信
息系统的重要组成部分。传统的ＭＥＳ软件开发难度大，周期长，成本高，软件的
可靠性差，系统的可重构性和可集成性不高。本文以面向构件的软件开发方法，基
于ＵＭＬ对ＭＥＳ软件进行需求分析、构件抽取、分析和设计，并以ＭＥｓ设备管理
系统为例进行详细说明。
基于ＵＭＬ的构件开发方法涉及的关键问题主要有：构件的需求分析（抽取构
件）、构件的分析设计和实现等。本文针对这些关键问题，结合ＭＥＳ设备管理系统
进行了研究和探讨，主要内容包括：
１、分析了软件复用及软件构件技术，及构件抽取。
２、详细论述了基于ＵＭＬ的构件抽取方法。通过用例图描述应用系统的功能特
征，抽取出业务构件，并对过程进行了详细分析。
３、通过描述每个构件中用例的流程，抽取出三种分析类。
４、以设备信息管理模块为例，结合￥９５设备模型，详细说明了业务构件分析
设计的方法和过程。通过用例分析，建立了完整的构件类图，设计了构件模型、构
件规约及业务构件的接口，用序列图表示出了一个业务构件的动态模型，并实现了
一个业务构件。

硕士研究生陈伟（计算机软件与理论）
指导教师 魏长江教授

关键词：构件化；软件复用；Ｉｍ几；ＭＥＳＩ设备管理系统
 Ｒｅｓｅａｒｃｈ ｏｎ ＭＥＳ Ｅｑｕｉｐｍｅｎｔ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ Ｃｏｍｐｏｎｅｎｔ ｂａｓｅｄ
ｏｎＵＭ－Ｌ

Ａｂｓｔｒａｃｔ

Ｓｏｆｔｗａｒｅ ｒｅｕｓｅ ｉｓ ｔｈｅ ｉｍｐｏｒｔａｎｔ ｄｏｍａｉｎ ｏｆ ｓｏｆｔｗａｒｅ ｅｎｇｉｎｅｅｒｉｎｇ．Ｉｔ ｉｓ ｔｈｅ ｍａｉｎ

ａｐｐｒｏａｃｈ ｔｏ ｓｏｌｖｅ ｔｈｅ ｓｏｆｔｗａｒｅ ｃｄｓｉｓ ａｎｄ ｅｎｈａｎｃｅ ｓｏｆｔｗａｒｅ ｐｒｏｄｕｃｔｉｖｉｔｙ，ｑｕａｌｉｔｙ，

ｏｐｅｎｉｎｇ ａｎｄ ａｄａｐｔａｂｉｌｉｔｙ．Ａｓ ｐｒｅｓｅｎｔ，ｔｈｅ ｒｅｓｅａｒｃｈ ａｂｏｕｔ ｓｏｆｔｗａｒｅ ｒｅｕｓｅ ｆｏｃｕｓｅｓ ０１１

ｔｈｅ ｓｏｆｔｗａｒｅ ｒｅＵＳｅ ｂａｓｅｄ ｏｎ ｃｏｍｐｏｎｅｎｔｓ，ｉｔ ｉｓ ｃｏｎｓｉｄｅｒ ａｓ ｏｎｅ ｏｆ ｔｈｅ ｋｃｙ ｆａｃｔｏｒｓ ｔＯ

ｒｅａｌｉｚｅ ｓｕｃｃｅｓｓｆｕｌ． ．

Ｍａｎｕｆａｃｔｕｒｉｎｇ Ｅｘｅｃｕｔｉｏｎ Ｓｙｓｔｅｍ（ＭＥＳ）ｉｓ ｔｈｅ ｂｒｉｄｇｅ ｔｈａｔ ｌｉｎｋｓ ｔｈｅ ｕｐｐｅｒ

ｍａｎａｇｅｍｅｎｔ ｌａｙｅｒ ａｎｄ ｌｏｗｅｒ ｃｏｎｔｒｏｌ ｌａｙｅｒ ｉｎ ａｎ ｅｎｔｅｒｐｒｉｓｅ，ｗｈｉｃｈ ｉｓ ａｎ ｅｓｓｅｎｔｉａｌ

ｐａｒｔ ｏｆ ｔｈｅ ｉｎｆｏｒｍａｔｉｏｎ ｓｙｓｔｅｍ．Ｔｈｅｒｅ ａｒｅ ｍａｎｙ ｐｒｏｂｌｅｍｓ ｉｎ ｔｈｅ ｐｒｏｃｅｓｓ ｏｆ

ｔｒａｄｉｔｉｏｎａｌ ＩＶＩＥＳ ｓｏｆｔｗａｒｅ ｄｅｖｅｌｏｐｍｅｎｔ ｓｕｃｈ ａｓ ｈａｒｄ ｄｅｖｅｌｏｐｉｎｇ ｄｉｆｆｉｃｕｌｔｙ，ｌｏｎｇ

ｄｅｖｅｌｏｐｉｎｇ ｐｅｒｉｏｄ，ｈｉｇｈ ｃｏＳｔ，ｌｏｗ ｒｅｆｉａｂｉｌｉｔｙ，ｂａｄ坨・ｓｔｒｕｃｔｕｒｉｎｇ ａｎｄ ｉｎｔｅｇｒａｔｉｏｎ

ａｂｉｌｉｔｙ．Ｔｈｅ ａｒｔｉｃｌｅ ｃａｐｔｕｒｅｓ ｔｈｅ ｒｅｑｕｉｒｅｍｅｎｔｓ，ｅｘｔｒａｃｔｓ ｔｈｅ ｃｏｍｐｏｎｅｎｔｓ ａｎｄ ｍａｋｅｓ

ｔｈｅ ａｎａｌｙｓｉｓ ａｎｄ ｄｅｓｉｇｎ．Ｂｅｓｉｄｅｓ，ｔｈｅ ａｒｔｉｃｌｅ ｐｒｅｓｅｎｔｓ ｔｈｅ ａｎａｌｙｓｉｓ ｐｒｏｃｅｓｓ ｔｈｒｏｕｇｈ

ＭＥＳ ｅｑｕｉｐｍｅｎｔ ｍａｎａｇｅｍｅｎｔ ｓｙｓｔｅｍ．

Ｔｈｅ ｋｅｙ ｐｒｏｂｌｅｍｓ ｃｏｎｃｅｒａｉｎｇ ｃｏｍｐｏｎｅｎｔｓ ｄｅｖｅｌｏｐｍｅｎｔ ｂａｓｅｄ ｏｎ ＵＭＬ

ｉｎｃｌｕｄｅ ｔｈｅ ｒｅｑｕｉｒｅｍｅｎｔ ａｎａｌｙｓｉｓ ｏｆ ｃｏｍｐｏｎｅｎｔｓ（ｅｘｔｒａｃｔｉｏｎ ｏｆ ｃｏｍｐｏｎｅｎｔｓ），

ａｎａｌｙｓｉｓ，ｄｅｓｉｇｎ ａｎｄ ｒｅａｌｉｚｉｎｇ ｏｆ ｃｏｍｐｏｎｅｎｔｓ．Ｔｈｅｓｅ ｐｒｏｂｌｅｍｓ ａｒｅ ｒｅｓｅａｒｃｈｅｄ ａｎｄ
ｐｒｅｓｅｎｔｅｄ ｃｏｍｂｉｎｉｎｇ ｗｉｔｈ ＭＥＳ ｅｑｕｉｐｍｅｎｔ ｍａｎａｇｅｍｅｎｔ ｓｙｓｔｅｍ ｉｎ ａｒｔｉｃｌｅ．Ｔｈｅ

ｍａｉｎ ｒｅｓｅａｒｃｈ ｃｏｎｔｅｎｔｓ ａｓ ｆｏｌｌｏｗｓ：

１．Ｓｏｆｔｗａｒｅ ｒｅｕｓｅ，ｓｏｆｔｗａｒｅ ｃｏｍｐｏｎｅｎｔｓ ｔｅｃｈｎｏｌｏｇｙ ａｎｄ ｅｘｔｒａｃｔｉｏｎ ｏｆ

ｃｏｍｐｏｎｅｎｔｓ ａｌｅ
ａｎａｌｙｚｅｄ． ・

２．Ｔｈｅ ｍｅｔｈｏｄ ａｂｏｕｔ ｅｘｔｒａｃｔｉｏｎ ｏｆ ｃｏｍｐｏｎｅｎｔｓ ｂａｓｅｄ Ｏｎ ＵＭＬ ｉｓ ｐｒｅｓｅｎｔｅｄ

ｓｐｅｃｉｆｉｃａｌｌｙ．Ｔｈｅ ｐｒｏｃｅｓｓ，ｄｅｓｃｒｉｂｉｎｇ ｔｈｅ ｆｕｎｃｔｉｏｎ ｏｆ ｓｙｓｔｅｍ ａｎｄ ｅｘｔｒａｃｔｉｎｇ

ｃｏｍｐｏｎｅｎｔｓ ａｒｅ ｐｒｅｓｅｎｔｅｄ ｓｐｅｃｉｆｉｃａｌｌｙ ｔｈｒｏｕｇｈ ｕｓｅ ｃａｓｅｓ．

３．Ｔｈｒｅｅ ａｎａｌｙｓｉｓ ｃｌａｓｓｅｓ ａｒｃ ｅｘｔｒａｃｔｅｄ ｔｈｒｏｕｇｈ ｄｅｓｃｒｉｂｉｎｇ ｔｈｅ ＵＳｅ ｃａｓｅ ｆｌｏｗ ｉｎ

ｅｖｅｒｙ ｃｏｍｐｏｎｅｎｔ．
４．Ｔｈｅ ｍｅｔｈｏｄ ｏｆ ｂｕｓｉｎｅｓｓ ｃｏｍｐｏｎｅｎｔｓ ａｎａｌｙｓｉｓ ａｎｄ ｄｅｓｉｇｎ ｉｓ ｐｒｅｓｅｎｔｅｄ

ｓｐｅｃｉｆｉｃａｌｌｙ ｂｙ ｔａｋｉｎｇ ｔｈｅ ｅｑｕｉｐｍｅｒｉｔ ｉｎｆｏｒｍａｔｉｏｎ ｍａｎａｇｅｍｅｎｔ ｍｏｄｕｌｅ ａｓ ｔｈｅ

ｅｘａｍｐｌｅ ａｎｄ ｃｏｍｂｉｎｉｎｇ ｗｉｔｈ￥９５ ｍｏｄｕｌｅ．Ａ ｃｏｕｐｌｅ ｏｆ ｃｏｍｐｏｎｅｎｔｓ ｃｌａｓｓ ｄｉａｇｒａｍｓ

ａｒｅ ｅｓｔａｂｌｉｓｈｅｄ ｔｈｒｏｕｇｈ ｕｓｅ ｃａｓｅ ａｎａｌｙｓｉｓ．Ｔｈｅｎ，ｃｏｍｐｏｎｅｎｔ ｍｏｄｕｌｅｓ，ｓｐｅｃｉｆｉｃａｔｉｏｎ

ａｎｄ ｉｎｔｅｒｆａｃｅ ｏｆ ｂｕｓｉｎｅｓｓ ｃｏｍｐｏｎｅｎｔｓ ａｇｅ

ｄｅｓｉｇｎｅｄ ｂａｓｅｄ ｏｎ ｃｌａｓｓ ｄｉａｇｒａｍｓ．

Ｍｏｒｅｏｖｅｒ，ｄｙｎａｍｉｃ ｍｏｄｅｌｓ ａｒｅ ｐｒｅｓｅｎｔｅｄ ｗｉｔｈ ｓｅｑｕｅｎｃｅ ｄｉａｇｒａｍｓ，ａｎｄ ａ ｂｕｓｉｎｅｓｓ

ｍｏｄｕｌｅ ｉｓ ｒｅａｌｉｚｅｄ．

Ｐｏｓｔｇｒａｄｕａｔｅ ｓｔｕｄｅｎｔ：Ｗｅｉ Ｃｈｅｎ（Ｃｏｍｐｕｔｅｒ ｓｏｆｔｗａｒｅ＆ｔｈｅｏｒｙ）

Ｄｉｒｅｃｔｅｄ ｂｙ Ｐｒｏｆｅｓｓｏｒ：Ｃｈａｎｇ－Ｊｉａｎｇ Ｗｅｉ

Ｋｅｙ Ｗｏｒｄｓ：Ｓｏｆｔｗａｒｅ Ｃｏｍｐｏｎｅｎｔ；Ｓｏｆｔｗａｒｅ Ｒｅｕｓｅ；ＵＭＬ；ＭＥＳ；Ｅｑｕｉｐｍｅｎｔ

Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ
 青岛大学硕：卜学位论文

学位论文独创性声明

本人声明，所呈交的学位论文系本人在导师指导下独立完成的研究成果。文中
依法引用他人的成果，均已做出明确标注或得到许可。论文内容未包含法律意义上
已属于他人的任何形式的研究成果，也不包含本人己用于其他学位申请的论文或成
果。

本人如违反上述声明，愿意承担由此引发的一切责任和后果。

／１ ＾

论文作者签名：ｆ球伽 同期：乒句年少舟髟日
ｌ １

学位论文知识产权权属声明

本人在导师指导下所完成的学位论文及相关的职务作品，知识产权归属学校。
学校享有猷任何方式发表、复制、公开阅览、借阅以及申请专利等权利。本人离校
后发表或使用学位论文或与该论文直接相关的学术论文或成果时，署名单位仍然为
青岛大学。

本学位论文属于：

保密口，在 年解密后适用于本声明。

不保密区
（请在以上方框内打“√”）

日期阳年归怕
馨
论文作者签名

导师签名： －

蹴Ｇ＞每守｛扣
（本声明的版权归青岛大学所有，未经许可，任何单位及任何个人不得擅自使用）
 第一章引言

第一章引言

１．１研究目的和意义

制造执行系统（Ｍａｎｕｆａｃｔｕｒｉｎｇ Ｅｘｅｃｕｔｉｏｎ Ｓｙｓｔｅｍ，ＭＥＳ）是连接企业计划管理层

和底层控制之间的桥梁，是企业信息系统的重要组成部分。ＭＥＳ是美国先进制造研
究机构（Ａｄｖａｎｃｅｄ Ｍａｎｕｆａｃｔｕｒｉｎｇ Ｒｅｓｅａｒｃｈ，ＡｉＲ）在上世纪９０年代提出来的概念，

目的是为了加强制造计划的执行能力１１．３ｌ。它位于企业应用软件的计划层和控制层之
间的执行层，通过把ＥＲＰ（企业资源计划）和车间作业现场设备控制连接起来，以解
决上层生产计划管理与底层生产控制脱节的矛盾，提高企业信息流的连续性和实时
性，为企业实现敏捷制造打下坚实的基础【４ｌ。
ＭＥＳ经过十几年的发展，在系统体系结构、关键技术，功能模块组成等各个
方面都取得了很大的进步，并且随着信息技术的发展，向分布式、网络化、构件化、
集成化和智能化方向发展。但是相比于其他的企业信息系统，ＭＥＳ的起步较晚，有
许多问题还需要进一步研究，研究多、开发少；原型多、实际应用少，投入到实际
工业生产中的应用系统就更少。且通用性差，柔性不足，开发难度大，周期长，成
本高，软件的可靠性差，系统的可重构性和可集成性不高【４】。
造成这些现象的主要原因除了ＭＥＳ系统本身的复杂性外，ＭＥＳ软件构件化研
究的不成熟也是一个重要的原因，本文就是针对ＭＥＳ的重点研究方向一．构件化问
题进行研究。主要研究目标是基于ＵＭＬ，以ＭＥＳ中的设备管理为研究对象，对
ＭＥＳ软件构件化的过程和方法进行深入研究。
本文通过对基于构件的ＭＥＳ软件开发过程的分析研究，建立了一种完整的、
通用性较强的适用于多个行业ＭＥＳ系统的构件化软件开发的方法体系。在构件化
的基础上，以“搭积木”和软件重用来实现不同企业ＭＥＳ系统的各种要求１５ｌ。在对一
个应用实例进行系统分析、功能分析、收集域需求、划分功能模型的基础上，建立
功能构件的对象模型【６ｌ，并对ＭＥＳ软件体系结构模型以构件化的方法进行分析研
究、设计和改进。

通过对ＭＥＳ软件构件化的过程和方法的研究，使ＭＥＳ软件具有更强的可集成
性、可扩展性、重构性，对不同行业领域ＭＥＳ软件的构件化研究提供了有益的方
法研究。本文以ＭＥＳ设备管理为例进行研究分析，对ＭＥＳ领域中的其他资源如人
员、物料管理的软件开发也具有一定的方法和过程的借鉴意义．
 青岛大学硕十学位论文

１．２国内外研究现状

由于ＭＥｓ在企业信息系统中起着承上启下的重要作用，自二十世纪９０年代初
正式提出后，ＭＥｓ的研究和开发已成为企业信息系统研究的重要组成部分，也得到
了国内外企业界和学术界的广泛关注。而由于基于构件的ＭＥＳ具有良好的可重构

性、可复用性、可扩展性和可集成性，可以满足现代制造企业对ＭＥＳ的需求，提
高企业信息系统的效益。因此基于构件的ＭＥＳ成为了研究的一个热点。

１．２．１ ＭＥＳ方面的研究

１、国外

美国是最早提出ＭＥＳ概念的国家，对ＭＥＳ的研究也最多。美国ＡＭＲＣ研究
小组在分析信息技术的发展和ＭＥＳ应用前景的基础上提出了可集成

ＭＥＳ（Ｉｎｔｃｇｒａｔａｂｌｅ ＭＥＳ，Ｉ－ＭＥＳ）１７１，它将模块化思想和组件技术应用到ＭＥＳ的软件
开发中。对象管理组织（Ｏｂｊｅａ Ｍａｎａｇｅｍｅｎｔ Ｇｒｏｕｐ，ＯＭＧ）的制造技术委员会中的
ＭＥＳ／ＭＣ工作组正在致力于建立ＭＥＳ的参考体系结构。为了使得该参考体系结构

具有广泛的代表性，该工作组于１９９７年发布了名为“Ｍａｎｕｆａｃｔｕｒｉｎｇ ＤＴＦ ＲＦＩ－３

Ｍａｎｕｆａｃｔｕｒｉｎｇ Ｅｘｅｃｕｔｉｏｎｓ Ｓｙｓｔｅｍｓ”征求意见书ｌＳｌ，其中列出了希望进一步研究的具

体项目。

日本和欧洲国家也较早开展了ＭＥＳ标准制定和研究工作。日本的制造科学与
技术中心受日本信息技术促进局委托，在电子商业公共基础设施建设项目中，提出

了一个基于ＣＯＲＢＡ、与平台无关的ＯｐｅｎＭＥＳ框架规范Ｉ引。德国的西门予公司开
发了自己的基于工业标准化和软件构件的ＭＥＳ－－ＳｉｅｍｅｎｓＭＥＳ，并已经成功的应用
到各种工业自动化项目。与上层的ＥＲＰ系统和底层的ＳＣＡＤＡ系统也进行了很好的
集成。
（１）国外对ＭＥＳ的研究主要包括如下几个方面：
●适用于各种不同生产环境的专用ＩＶＩＥＳ，如应用于半导体和ＭＥＭＳ车间，
强调调度和资源优化的ＡＨＥＡＤ ＭＥＳＩｌ０Ｊ，适用于ＦＭＳ系统的ＭＥＳ［１１】。

●工具化ＭＥＳ，如以微电子制造虚拟企业为背景的工具化ＭＥＳ系统
ｘ－ｃｒｒｎｃ‘１２’。

●集成化ＭＥＳ，如用于半导体制造企业的ＭＥＳ系统【１３］。
●可集成的ＭＥＳ，如用于虚拟企业的ＮＩＩＰ．ＳＭＡＲＴ［１４］。
●虚拟企业的ＭＥＳ，如ｅ．制造环境下基于虚拟生产线的ＭＥＳ及其自适应监
控系统Ｉ”Ｊ。
●可扩充的ＭＥＳ，如日本信息促进委员会和一些企业伙伴（如ｓｏｆⅨ有限公司
２
 第一章引言

等）支持的ＯｐｅｎＭＥＳ项引圳。
・分布制造执行系缔１１‘”。
●计算机集成制造执行系统【１８ｌ乃至全能制造执行系统１１９１。
（２）为了使ＭＥＳ具有最大的通用性，使ＭＥｓ更加规范，各国和各机构近年为
制定企业信息整合（集成）标准和模型做了大量的工作，但是大多数是针对一种特定
的工作门类、或类似的几种工业门类的。从１９９７年开始ＩＳＡ（美国仪器、系统和自
动化协会）和ＡＮＳＩ（美国国家标准协会）共同发起了编制企业控制系统集成标准的

工作。该标准被定义为￥９５。￥９５标准定义了企业商业系统和控制系统之间的集成，
主要可以分成３个层次，即企业功能部分、信息流部分和控制功能部分。￥９５正在
发展成为被广泛采用的企业控制系统集成标准。
（３）ＭＥＳ作为一种计算机辅助生产管理系统，包含了许多功能模块。制造执行
系统国际联合会（ＭＥＳＡ，ＭＥＳＡｓｓｏｃｉａｔｉｏｎ）通过实践归纳了十一个主要的ＭＥＳ功能
模块，包括：资源配置及控制、生产调度、数据采集、质量管理、过程管理、生产
计划和跟踪、性能分析、作业详细调度、文档控制、人力资源管理、维护管理ｌ列。
ＭＥＳＡ功能模型提出的目的是为不同的ＭＥＳ开发者提供一个标准，使不同工业生
产类型的企业能够根据自身的需要选择开发商的功能模块进行集成。

２、国内

在国内，随着中国经济的快速发展，国家提出利用信息化带动工业化的方针，
制造行业的信息化水平不断提高，高校和研究所也开始研究ＭＥＳ。

我国国家。十五”８６３计划将ＭＥＳ作为重点研究课题进行资助，取得了一批研
究与应用成果。曹江辉１２１Ｊ重点研究了基于ＵＭＬ的制造执行系统层次演化对象建模
技术，提出一种基于软构件的制造执行系统体系框架，并对基于ＣＯＲＢＡ的制造

执行系统的开发进行了深入研究。于海滨等１２２１采用Ａｇｅｎｔ技术、工作流技术和软
件构件技术来进行可集成的制造执行系统的构件和软件系统开发研究。对构件化的
ＭＥＳ开发，蔡宗琰例提出了基于软件构件的可重构制造执行系统的软件体系结构
和实现方法．
随着国内ＭＥＳ研究的不断深入，刘晓冰等［２４１为解决车问生产管理软件通用性
和可移植性差的弊端，研究了可重构的ＭＥＳ。它基于车间生产业务的构件化设计思
想，采用通用对象请求代理结构和多代理技术，提出了适用于制造行业的车间制造

执行系统平台的体系结构，以实现快速重组车间生产业务过程和适应企业敏捷化生
产的需要，增强车间生产管理软件的可扩充性、可重构性和可移植性。南京航空航
天大学、华中科技大学、北京航空航天大学、河北科技大学等国内研究组织都取得
了不少研究成梨笛Ｉ［２６１［２７１１２Ｓｌ。

３
 青岛大学硕士学位论文

目前国内对ＭＥｓ的研究主要集中在ＭＥＳ思想、内涵及体系结构方面，应用系
统开发一般局限在制造执行系统的在具体行业中的单一功能的软件开发及建模。而
且应用水平基本只达到ＭＥＳ技术的早期阶段（专用ＭＥＳ和集成化ＭＥＳ），也缺乏
具体实际工程应用研究。对于ＭＥｓ构件化的研究在国内则更少，水平也处于起步
阶段。任守纲１４】提出了基于构件的ＭＥＳ软件产品线开发思想，这是一种与制造业的
装配流水线比较相似的开发模式，较好的解决了传统的ＭＥＳ软件开发中存在的具
体软件需要定制，通用性不高，复用度不高的缺点。由于我国对ＭＥｓ的研究起步

较晚，因此，与西方发达国家相比，无论是在技术深度与应用广度上都存在较大差
距。

１．２．２ 软件构件化方面的研究

国内外在基于构件的软件复用相关研究和实践方面已经取得了一定的成果。首
先从构件、构件库和构件复用的标准来看，美国军方和政府资助的项目中，已经建
立了若干构件库系统，如ＣＡＲＤＳ、ＡＳＳＥＴ、ＤＳＲＳ等。北大西洋公约组织（ＮＡＴＯ）
针对ＮＡＴＯ、Ｎ＾１Ｄ参与国和承包商制定了一组关于软件复用的标准，其中包括“可
复用构件开发标准”、“可复用软件构件库管理标准”、“软件复用过程标准”１２９－３２］。
其次在构件互操作技术方面，主要有以下三个比较有影响的规范：ＯＭＧ起草与颁
布的ＣＯＲＢＡ、微软公司推出的ＣＯＭ／ＤＣＯＭ、ＳＵＮ发布的ＪａｖａＢｅａｎｓ［３３１。产品线系
统（Ｐｒｏｄｕｃｔ Ｌｉｎｅ Ｓｙｓｔｅｍ）是ＣＭＵ／ＳＥＩ提出的产品开发的组织方式［３４－３６１。产品线集中
体现了软件复用思想。产品线方法可以通过各种可复用软件构件，如需求、需求规
约、构架、代码构件、文档、测试策略和计划、测试案例和数据、开发人员的知识
和技能、过程、方法及工具等，支持最大限度的软件有用。目前国内最具代表性的
产品是北大青鸟软件生产线，青鸟软件生产线是基于构件一构架软件开发技术及系
统。同时支持面向复用的开发和基于复用的开发，为软件复用提供了一个比较全面
的解决方案Ｉｊ“。
基于构件的软件工程极大地变革了传统的开发模式，旨在以即插即用构件的方

式在框架上组建满足用户需求的应用系统，促进了软件行业的分工，即构件生产者
和构件装配者。然而目前的构件技术，尚不能使软件的生产达到类似计算机硬件产
业的工业化水平。而业务构件开发方法代表着软件技术的最掰发展方向，业务构件。
以统一的、独立自治的概念贯穿整个软件产品生命周期，每个业务构件郝能独立于
其它业务构件而存在，被另一构件代替时无需重新编译系统，从而实现真正意义上
的即插即用。业务构件技术为软件生产工业化提供了理论与技术基础，促进了软件
生产工业化。
业务构件技术将以软件构件技术为基础。与软件构件不同的是，业务构件不仅

４
 第一章引言

是在开发时和运行时的一个构件，而且是整个软件生命周期中的构件，业务构件同
时也是一个具体业务概念的软件实现。业务构件不仅是在设计时所标识的、在构造
时所实现的，以及在单元测试及集成测试时所测试的软件产品，而且也是配置时所
看到的产品。每个业务构件相应于一组运行时可独立进行配置的产品，它们可独立
于其它业务构件而存在，可被另一构件所代替而不必重新编译系统，从而实现真正

意义上的即插即用Ｉ删。
业务构件技术为ＭＥｓ软件的开发提供了全新的开发思路。业务构件技术为开
发ＭＥｓ软件提供了一种比面向对象或传统的基于模块的开发技术更为高效、灵活、
功能强大的开发模式，同时也为开发者ＭＥＳ应用系统提供了更简便而灵活的手段。
在ＭＥＳ行业在我国起步不久的情况下，ＭＥｓ软件真正能够做到利用通用构件开发
ＭＥＳ应用系统的产品和开发工具并不多见，大部分仍停留在重用理论的进一步探讨
和实现技术的研究阶段。

１．３主要研究内容与创新点

针对国内外ＭＥＳ和构件化的研究现状分柝，本文通过对软件构件化的研究，

将基于软件构件的软件复用技术引入到ＭＥＳ系统中的一个特定领域的系统开发中
来，以ＭＥｓ中的设备管理为例，借鉴￥９５中提出的设备对象模型，基于ＵＭＬ技术，
以构件化的软件开发思想对系统进行分析和构件抽取．对ＭＥｓ软件构件化的开发
过程与方法进行研究。主要研究内容包括：
（１）对基于ＵＭＬ的ＭＥＳ的构件抽取方法进行了研究。
（２）对如何捕获构件进行了研究并作了详细的需求分析。
（３）以用例驱动的方式对构件进行了分析设计．
（４）对业务构件的规约和接口进行了详细设计．
（５）对￥９５中提出的对象模型进行了研究并在功能结构上进行了改进。
本文的主要创新点：
（１）本文以基于ＵＭＬ并以用例驱动的开发方法，结合￥９５对象模型，对ＭＥＳ
设备管理进行研究分析、构件抽取、设计实现，建立一个通用性较强的开发过程与
方法．对Ⅻ巳ｓ软件的开发，尤其如人员、物料管理的软件开发提供一定的借鉴。
（２）对￥９５中提出的设备对象模型的功能结构以构件化的方法进行了改进。

１．４论文结构和章节安排

本文首先研究了软件构件化、ＭＥＳ软件构件化及其相关技术，其次重点研究
了基于ＵＭＬ的面向构件需求分析和设计方法，其中包括ＵＭＬ知识及基于ＵＭＬ的

５
 青岛大学硕士学位论文

构件抽取方法，基于ＵＭＬ的构件需求分析、设计、实现。并以ＭＥｓ系统中的设备
管理系统为例，通过详细分析其中的一个业务构件，对基于ＵＭＬ的面向构件的软
件开发过程和方法进行了详细的描述。本文各个章节的内容安排如下：
第一章引言

介绍了ＭＥＳ的应用发展情况和软件构件化的发展概况，包括发展过程，发展
现状和国内外研究现状，分析了ＭＥｓ软件开发中存在的问题，提出了基于ＵＭＬ的

通过面向业务构件的方法来进行ＭＥｓ软件构件化的开发。最后给出本文的章节安
排。

第二章软件构件化与ｕＭＬ

介绍和分析了软件构件化及相关技术的概念和研究内容，分析了基于软件构件
／构架的软件开发方法。并介绍了ＵＭＬ和Ｒａｔｉｏｎａｌ统一过程。
第三章基于ＵＭＬ的构件需求分析

研究了基于ＵＭＬ的构件抽取方法，并以ＭＥＳ中的设备管理系统为例，基于
ＵＭＬ对系统进行需求分析，抽取系统的功能特征形成用例模型。通过用例模型识
别系统业务构件，并给出业务构件的抽取过程。最后得到ＭＥｓ设备管理系统的业
务构件模块。

第四章面向构件的分析与设计
依据第三章的需求分析，对抽象出的用例图进行详细分析，以ＲＵＰ用例驱动
的开发方法对系统进行分析设计。通过进行用例分析，抽取出设备管理系统中各个

业务构件的分析类，得到详细类图，对类图进行了详细描述。并以一个业务构件为
例进行动态视图建模。结合Ｓ９５标准中提出的设备分级模型结构进行详细设计，并
对￥９５中的模型结构进行了改进。
第五章构件实现

根据系统分析和构件设计，设计了相关的数据库表，给出了系统的数据模型和
。
部分程序界面。
第六章总结与展望

对本课题的相关研究进行总结，并对今后的发展方向进行展望。

６
 第二章软件构件与ＵＭＬ

第二章软件构件化与ＵＭＬ

软件复用是在软件开发中避免重复劳动的解决方案，其出发点是应用系统的开
发不再采用一切从“零开始”的模式，而是以已有的工作为基础，充分利用过去应
用系统开发中积累的知识和经验，如：需求分析结果、设计方案、源代码、测试计
划及测试案例等，从而将开发的重点集中于应用的特有构成成分。而软件构件技术
是支持软件复用的核心技术。分析传统产业的发展，其基本模式均是符合标准的零
部件（构件）生产以及基于标准构件的产品生产（组装），其中，构件是核心和基础，
“复用”是必需的手段。实践表明，这种模式是产业工程化、工业化的必由之路，
也将是软件产业发展的必由之路ｌ捌。

２．１软件构件

软件构件是能独立的开发、获取、发布的功能单元，能相互作用组成一个功能
系统【蚰ｌ。通常构件应具备以下三个基本性质：
‘

ｌ、复用性（Ｒｅｕｓａｂｉｌｉｔｙ）：复用是构件存在的意义，也是构件技术的目的和发展
的驱动力。

２、封装性（Ｃａｐｓｕｌｉｚａｂｉｌｉｔｙ）：构件是一个自包含的实体，封装了设计的实现的
内容，对外仅通过接口来交互．
３、组装性（Ｃｏｍｐｏｓｉｔａｂｉｌｉｔｙ）：构件通过组装可以形成更大的整体，组装是实现
复用的手段。
构件是指应用系统中可以明确辨识的构成成分，而可复用构件是指具有相对独
立的功能和可复用价值的构件１４¨。可复用构件应具备以下属性：
①有用性：必须提供有用的功能；②可用性：必须易于理解和使用；③质量：
自身及其变形必须能正确工作；④适应性：应该易于通过参数等方式在不同语境中
进行配置；⑤可移植性；应能在不同的硬件平台和软件环境中工作。

２．２基于构件的软件开发技术

软件构件技术是支持软件复用的核心技术，是近几年来迅速发展并受到高度重
视的一个学科分支。软件构件技术是从面向对象技术发展而来的，并很好的发展了
面向对象技术。它的目的是将对象、包括其用户界面、对外接口等属性以及对象的
功能实现封装成一个规范的、标准的、可以方便地被构件容器所操纵和使用的整体，
使其成为一个通用、高效的软件部件。通过软件构件达到全面应用面向对象技术与
概念，成为开发出高效、低成本、可重用软件系统的重要的现实途径Ｉ镯．

７
 青岛大学硕士学位论文

推动构件技术发展的最大动力之一是软件复用，构件技术是目前发展最快的软
件复用技术。基于构件的软件开发技术是一种社会化的软件开发方法，它使得开发
者可将由不同语言、不同供应商开发的构件组合在一起来构造软件。
构件技术必须解决的几个主要问题包括［４３１：
１、构件的抽取。为了实现构件复用，构件必须具有一定的、面向领域的通用

性，构件所提供的功能能为多个系统使用。因此构件的抽取、功能的定义将是要解
决的第一个问题。由于构件技术是在面向对象技术基础上发展起来的，加上面向对
象技术自身的抽象、继承、封装特性，那么采用面向对象的系统分析方法进行构件
的抽取就比较合适了。
２、构件的设计。为了使定义的构件能在不同开发环境被不同的软件开发者
使用，那么构件应具有一个较为通用的接口定义。一个面向特定领域的较为通用的
接口可以处理领域内的大多数功能请求。这里所说的接口是指实现构件功能所对应

的一个个函数（或方法）的参数列表，即输入那些参数，返回什么结果集或值。接口
与功能的实现是相分离的，具有相同接口的构件可以有完全不同的实现方法。可复

用构件的设计原则之一就是：根据接口。而不是根据接口的实现来设计构件。
３、构件的互操作。构件经过分析、设计之后，需要将构件实现，这样才能真
正为软件开发者所使用，那么随之而来的一个问题就是不同开发环境下用不同编程
语言开发出来的构件的互操作。如果不同构件问不能互操作，每个开发商开发出来
的构件仅限于某种特定的编程环境，这将大大限制构件的复用，同时构件间不能互
操作，也大大限制了利用不同的可复用构件制造更大的可复用构件和利用不同的可
复用构件构造新系统。

２．３统一建模语言（ＵＭＬ）

统一建模语言［４４－４刀（Ｕｎｉｆｉｅｄ Ｍｏｄｅｌｉｎｇ Ｌａｎｇｕａｇｅ，ＵＭＬ）是一种通用的可视化建

模语言，用于对软件进行描述、可视化处理、构造和建立软件系统工件的文档。它
记录了与被构建系统的有关的决策和理解，可用于对系统的理解、设计、浏览、配
置、维护以及控制系统的信息。ＵＭＬ适用于各种软件开发方法、软件生命周期的
各个阶段、各种应用领域以及各种开发工具。旨在统一以往建模技术的经验，吸收
当今软件开发的最佳实践从而形成一种标准的方法。ＵＭＬ包括语言概念、表示法
和指导规范，提供了静态、动态、系统环境及组织结构的模型。它可被交互式的可
视化建模工具所支持，这些工具提供代码生成和报表生成的功能。ＵＭＬ标准并没

有定义～种标准的开发过程，但它适用于迭代式的开发过程。它是为支持现今大部
分面向对象的开发过程而设计的。

８
 第二章软件构件与ＵＭＬ

２．３．１ ＵＭＬ的组成

ＵＭＬ中的各种元素和概念之间没有明显的划分界限，为了从不同的角度对系
统进行描述，使用不同的视图来组织和表现ＵＭＬ的各种不同概念和角度。ＵＭＬ提
供了各种图形，比如用例图、类图、时序图、协作图和状态图等，来把这些模型元
素及其关系可视化，让人们可以清楚容易地理解模型。

ＵＭＬ由视图（Ｖｉｅｗ）、图（Ｄｉａ／ｐｒａｍ）、模型元素（Ｍｏｄｅｌ Ｅｌｅｍｅｎｔ）和通用机制
（Ｇｅｎｅｒａｌ Ｍｅｃｈａｎｉｓｍ）等几个部分组成。
视图（Ｖｉｅｗ）是表达系统的某一方面特征的ＵＭＬ建模元素的子集，由多个图构
成，是在某一个抽象层上，对系统的抽象表示。

图（Ｄｉａｇｒａｍ）是模型元素集的图形表示，通常是由弧（关系）和顶点（其他模型元
素）相互连接构成的。
模型元素（Ｍｏｄｅｌ Ｅｌｅｍｅｎｔ）代表面向对象中的类、对象、消息、和关系等概念，
是构成图的最基本的常用概念。
通用机制（Ｇｅｎｅｒａｌ Ｍｅｃｈａｎｉｓｍ）用于表示其他信息，比如注释、模型元素和语义
等。另外，ＵＭＬ还提供扩展机制（ＥｘｔｅｎｓｉｏｎＭｅｃｈａｎｉｓｍ），使ＵＭＬ语言能够适应一

个特殊的方法（或过程），或扩充一个组织或用户。
ＵＭＬ是用来描述模型的，用模型来描述系统的结构或静态特征，以及行为或
动态特征。从不同的视角为系统构件建模，形成系统的不同视图。
ｌ、用例视图（ＵｓｅＣａｓｅＶｉｅｗ），强调从用户的角度看到的或需要的系统功能，
是被称为参与者的外部用户所能观察到的系统功能的模型图．
２、逻辑视图（ＩＪ０９ｉｃａｌ Ｖｉｅｗ），展现系统的静态或结构组成及特征，也称为结构
模型视图（Ｓｔｒｕｃｔｕｒａｌ Ｍｏｄｅｌ Ｖｉｅｗ）或静态视图（Ｓｔａｔｉｃ Ｖｉｅｗ）。
３、并发视图（Ｃｏｎｃｕｒｒｅｎｔ Ｖｉｅｗ），体现了系统的动态或行为特征，也称为行为
模型视图（Ｂｅｈａｖｉｏｒａｌ Ｍｏｄｅｌ Ｖｉｅｗ）或者动态视图（Ｄｙｎａｍｉｃ Ｖｉｅｗ）。 ．

４、组件视图（Ｃｏｍｐｏｎｅｎｔ Ｖｉｅｗ），体现了系统的结构和行为特征，也称为实现
模型视图（Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ Ｍｏｄｅｌ Ｖｉｅｗ）。
５、配置视图（Ｄｅｐｌｏｙｍｅｎｔ Ｖｉｅｗ），体现了系统实现环境的结构和行为特征，也
称为环境模型视图（Ｅｎｖｉｒｏｎｍｅｎｔ Ｍｏｄｅｌ Ｖｉｅｗ）或物理视图（Ｐｈｙｓｉｃａｌ ｖｉｅｗ）．
视图是由图组成的，ＵＭＬ提供了９种不同的图来描述系统的各种结构、元素、
功能及行为等。以下是各个图的详细介绍：

１、用例图（Ｕｓｅ Ｃａｓｅ Ｄｉａｇｒａｍ），描述系统功能；

２、类图（Ｃｌａｓｓ Ｄｉａｇｒａｍ），描述系统的静态结构；

３、对象图（Ｏｂｊｅｃｔ Ｄｉａｇｒａｍ），描述系统在某个时刻的静态结构；
４、时序图（Ｓｅｑｕｅｎｃｅ Ｄｉａｇｒａｍ），按时问顺序描述系统元素间的交互；
９
 青岛大学硕士学位论文

５、协作图（Ｃｏｌｌａｂｏｒａｔｉｏｎ Ｄｉａｇｒａｍ），按照时间和空间顺序描述系统元素间的交
互它们之间的关系；
６、状态图（Ｓｔａｔｅ Ｄｉａｇｒａｍ），描述了系统元素的状态条件和响应；

７、活动图（Ａｃｔｉｖｉｔｙ Ｄｉａｇｒａｍ），描述了系统元素的活动；
８、组件图（Ｃｏｍｐｏｎｅｎｔ Ｄｉａｇｒａｍ），描述了实现系统的元素的组织；

９、配置图（Ｄｅｐｌｏｙｍｅｎｔ Ｄｉａｇｒａｍ），描述了环境元素的配嚣，并把实现系统的
元素映射到配置上。
根据这９种图在不同架构视图中的应用，可以将它们表２．１表示为五种。

表２．１ ＵＭＬ图的分类

视图 图

用户模型视图 用例图

结构模型视图 类图和对象图

行为模型视图 时序图、协作图、状态圈和活动图（动态图）

实现模型视闰 组件圈

环境模型视图 配置图

２．３．２ ＵＭＬ建模意义

模型是对现实豹简化，软件模型是对要解决的闯题的直观的简化，它提供了系
统的蓝图，通过从不同的角度来描述系统，使软件设计和开发人员能更好的理解系
统。
ＵＭＬ是一种通用的可视化国际建模语言，ＵＭＬ适合于各种软件开发方法，给
面向对象的开发过程提供了一种通用的标准建模工具Ⅲｌ，ＵＭＬ能够捕捉系统静态

结构和动态行为的信息。系统被建模成独立对象的集合，它们通过交互实现功能，
从而最终满足外部使用者的需要，静态结构定义了系统中重要对象的属性和操作，
以及这些对象之间的关系。动态行为定义了对象随时间变化的历史和对象为完成目
标而进行的相互通信。从不同但相互联系的角度对系统建模，可以全方位的理解系
统。
ＵＭＬ通过五类视图和九种模型图来说明系统的静态结构和动态行为，可以归
纳为静态建模机制和动态建模机制，静态建模由用例图、类图、对象图、组件图和
配置图来表示，描述系统的组织和结构；动态建模由时序图、协作图、状态图和活
动图来表示，描述系统的行为和动作。基于ＵＭＬ的建模具有通用性和普遍性，开
发人员可以从多个角度更好的理解系统，节省了开发时间。对构造准备、高效的软

件系统具有重要的意义。

１０
 第二章软件构件与ＵＭＬ

Ｒａｔｉｏｎａｌ公司推出的ＲＯＳＥ是目前较好的基于ＵＭＬ的ＣＡＳＥ工具，它把ＵＭＬ
和谐地组装到软件开发过程中，它提供了从需求分析阶段到测试阶段的清晰的ＵＭＬ
表达方法和完善的工具，方便建立起相应的软件模型。

２．４ ＲＵＰ简介

ＵＭＬ的创始人Ｂｏｏｃｈ、Ｒｕｍｂａｕｇｈ和Ｊａｃｏｂｓｏｎ在创建ＵＭＬ的同时，在Ｒａｔｉｏｎａｌ
公司的支持下综合了多种软件开发过程的长处，提出了一种新的面向对象的软件开
发过程，称为Ｒａｔｉｏｎａｌ统一过程（ＲＵＰ）．ＲＵＰ是一种以用例驱动、构架为中心、迭
代和增量的开发过程。它与ＵＭＬ在实际过程开发中的结合，使得对系统的分析和
设计交得直观、清晰，降低了系统的开发风Ｅ甑它还具有控制整个系统的开发过程，
维护系统完整性的优点。
统一过程不仅是一个简单的软件开发过程，它是一个通用的过程框架，它可用
于各种不同类型的软件系统、应用领域、组织、功能级别和不同的项目规模。ＲＵＰ
是基于构件的方法且使用ＵＭＬ作为建模语言来定制软件系统的所有蓝图。
ＲＵＰ可以用以下几个模型表示Ｉ勰ｌ：

●用例模型，包含所有用例及其与用户之间的关系。
・分析模型，它有两方面的作用：更详细地提炼用例；将系统的行为初步分
配给提供行为的一组对象。

・设计模型，将系统静态结构定义为予系统、类和接口，并定义由予系统、
类和接口之间的协作所实现的用例。
●实现模型，包括构件和类到构件的映射．
・实施模型，定义计算机的物理节点和构件到这些节点的映射．
●测试模型，描述用于验证用例的测试用例。
作为过程框架，ＲＵＰ是可裁剪的。它建立了简洁和清晰的过程结构．为开发过
程提供了较大的通用性。在领域应用中，ＲＵＰ可为适应特定组织系统的需要进行裁
剪，可以包括一个或多个描述系统业务语境的领域模型或业务模型．
 青岛大学硕十学位论文

第三章基于ＵＭＬ的构件需求分析

３．１基于ＵＭＬ的构件抽取方法

构件的抽取主要有两种方式，一种是从已有的系统中抽取可复用构件，另一种
是从系统分析、设计的初期就考虑构件，整个系统通过构件组装而成。从已有系统
中抽取构件的缺点是那些系统在设计时没考虑构件复用，整个系统也并不是由构件
组装丽成，因此导致所抽取的构侔并不能真正反映实际系统。而从系统开发初期就
考虑构件的抽取，则避免了具体的限制条件和开发环境的影响，使构件能够自由装
配到不同的应用系统中。
基于ＵＭＬ的构件抽取过程如下：
１、通过Ｕｓｅ Ｃａｓｅ映射系统的需求视图，得到系统的功能模型，将系统的通用
业务构件识别出来；
２、对每个用例进行用例说明，或通过交互图描述用例的流程；
３、通过用例分析得到类图，抽取出完成功能各个边界类、控制类和实体类；
４、分析类图，抽象出以类图表示的业务构件模型。
基于ＵＭＬ的构件抽取过程是一个基于用例迭代的过程，构件的抽取由用例驱

动。用例描述系统的需求，用例说明和交互图则描述用例的流程，通过用例分析识
别出三种不同性质的类：边界类、控制类、实体类。丽类图描述实现用例的类和类
间的关系，构件则是类的抽象。因此，在基于ＵＭＬ的构件抽取过程中，用例图和
类图的建立是最重要的【４３１。图３．１说明了基于ＵＭＬ的构件抽取过程。

迭
代
反
馈

图３．１基于ＵＭＬ的构件抽取过程
 第三章基于ＵＭＬ的构件需求分析

３．１．１用例驱动的需求描述方法

在软件系统开发过程中，需求捕获的目标是发现用户的需求并加以描述。ＵＭＬ
用例图即是专门用于从用户的角度描述系统的功能的视图。所有用例图就构成了用
例模型。用例模型可转化为分析模型、设计模型、实现模型和测试模型等。可以说
分析、设计、实现、测试等活动都是从用例开始的。因此说用例可以驱动整个统一
软件开发的过程Ｉ柙ｌ。
一个软件系统通常要生成多个用例图，以便于系统的分解描述。通过使用用例
观察系统，能够将系统实现与系统目标分开，有助予了鲳整个系统的系统责任，丽
不会沉浸于实现细节，因此便于用户了解系统所能提供的功能，便于系统开发范围
的确定．
使用用例描述系统需求的步骤如下１４３１：
ｌ、识别系统角色。发现角色的基本思路是，从用户角度考虑这个系统建立以
后将在应用单位发挥什么作用。主要考虑系统外部将有哪些事物与它进行交互。所
有的交互都可概括为与系统进行数据信息或控制信息的交换。凡是与系统进行这种
信息交换的外部事物都应看作角色。
２、识别系统中的用例。用例是系统的功能描述。可以通过咨询领域专家，与
最终用户交流明确系统责任。把自己当作系统的一个角色，与设想中的系统进行交
互，以穷举方式考虑每个角色与系统的交互情况，考察每个角色要求系统提供什么
功能，以及角色的每一项输入信息将要求系统做仟么反映．进行什么处理，并以穷
举的方式检查用户对系统的功能需求是否在各个用侧中体现出来。
３、确定系统中角色与用例间的关系。角色与用例的关系反映了角色与系统的
交互，主要是确定角色向系统输入或从系统输出什么信息，至于消息的并发问题将
在系统详细设计中处理．
４、建立系统用例的事件流文档，描述使用用例的逻辑流程，描述系统中的角
色、使用用例及其关系。

３．１．２类图的建立方法

类图表达了系统的静态结构以及完成功能的实体（类、对象等），通常通过识别
类、识别类属性、识掰类方法和识别类阕关系来建立一个类图削．具体步骤为：
ｌ、研究分析问题领域，确定系统的需求。
２、找出对象和对象类，明确他们的含义和责任，确定属性和操作。
３、发现类之间的静态联系。着重分析找出对象类之间的一般和特殊关系，部
分与整体关系，研究类的继承性和多态性，把类之间的静态联系用关联、泛化、聚
合、组合、依赖等联系表达出来，虽然对象类图表达的是系统的静态结构特征，但

１３
 青岛大学硕士学位论文

是应当把对系统的静态分析与动态分析结合起来，更能准确地了解系统的静态结构
特征。
４、设计类与联系。调整和精化已得到的对象类和类之闯的联系，解决诸如命
名冲突、功能重复等问题。

５、绘制对象类图并编制相应的说明。

３．２面向构件的需求分析

３．２．１系统业务需求

为描述系统的行为和结构，首先必须确定系统的功能需求。由于本文以ＭＥＳ
领域中的ＭＥＳ管理为例进行需求分析，构件的抽取和设计。首先来分析ＭＥＳ系统
中设备管理系统的原始功能需求。设备是企业进行生产的主要物质技术基础，有它
自身的运行规律。设备管理作为企业管理的重要组成部分。对企业的其它管理子系
统起着促迸、保障和制约的作用，影响着企业的生产与经营活动１５１ｊ。
ＭＥＳ系统中设各管理系统的作用和目标为了提高企业的市场竞争力和管理水
平，运用计算机和网络技术建立网络数据库，记录设备的运行情况、技术状态、维

修更新情况等信息，为维护保养及维修计划制定提供决策帮助；对设备数据资料进
行规范化管理，并将设备的资金占用情况、设备状态、设备的综合利用率以及设备

的使用、调配和维护等信息实对、准确地提供给管理人员，同时生成各种设备统计
分析报告，为企业经营计划、生产计划和车间作业计划等子系统提供设备运行状况，
以便对企业的长期和短期生产计划进行必要的调整和修正；合理地制定设备检修计
划，以减少偶然事故所造成的经济损失；加强设备履历、日常维护管理和监控，以
提高设备利用率；搞好备品、备件的控制管理，减少库存占有资金；准确、迅速地
为相关部门提供各种设备可靠的统计数据１５羽。
通过以上分析，设备管理系统的功能主要可以划分为四部分：设备基本信息管
理、设备状态管理、设备维护管理、设备台帐管理。以下详细加以分析说明。
ｌ、设备基本信息管理
设备基本信息管理是设备管理系统的基本部分，其他的各功能模块的数据资料
都是以这部分为基础。基本信息主要来源于添加新设备时的资料信息。另外在设备
运行过程中，基本信息情况也可能会发生改变。基本信怠管理主要完成设备基本信

息的录入与修改，如设备的编号、购买时间、生产厂家、型号、规格等，以及对各
种设备的合理分类及科学编码。

由分析可以得知，设备基本信息管理功能有设备分类管理、设备基本信息的维
护（包括设备基本信息录入、设备基本信息修改、设备基本信息删除）、设备基本信

１４
 第三章基于ＵＭＬ的构件需求分析

息查询等功能。

设备类别的基本属性包括编号、名称等。设备基本信息的基本属性包括：设备
名称、设备所属类别、设备编号、设备型号、购买时间、所属部门、自身状态等相
关资料。
２、设备状态管理

设备状态管理主要是对运行过程中的设备进行状态跟踪管理，以实现设备运行
过程中的运行记录、设备事故、设备检查、设备维护等记录的管理。设备状态管理
的操作主要有设备状态的查询、修改、故障诊断、设备运行维护、故障报告维护、
设备运行记录、故障维修记录等。
设备状态的基本属性包括；设备名称、设备状态描述、状态值、故障报告、维
护描述、维护日期、运行记录、维护记录等。
３、设备维护管理
设备维护管理指的是对设备制定的维护计划并执行而不仅是对具体设备的维
修。在设备正常使用后，对设备制定维护计划是重要的，这不仅关系到具体设备的
使用寿命和安全运行，而且会对整个ＭＥＳ系统的其他子系统，比如人力资源和物
料资源的调配产生影响。
设备维护管理主要完成维护计划的制定、审批、下达、检查、记录、查询等操
作，以及添加维护记录、提交维护报告和设备故障分析。
４、设备台帐管理

设备台帐管理主要是给ＭＥＳ系统的上层系统一．ＥＲＰ系统提供设备情况的各种
信息，供上层管理者决策参考。由于系统中所涉及的角色不同，权限不同，设备台
帐管理针对的主要是对设备信息的查询活动。
设备台帐管理包括对设备基本信息的查询、修改；对设备状态的查询、对设备
维修记录的查询，设备的故障维修记录的查询等活动．
设备台帐的主要属性包括：设备名称、所属类别、设备运行状态描述、设备维
护状态描述等。 ．

以上是对ＭＥＳ中设备管理系统的各个功能特征的详细描述。图３．２所示的是
由以上分析所得的设备管理系统的功能图。

１５
 青岛大学硕士学位论文

图３．２设备管理系统功能特征图

３．２．２雨例模型

在ＲＵＰ中，一个核心的特点就是用例驱动。用例是系统中的一个功能单元，
可以被描述为参与者与系统之间的一次交互作用，包括从动作开始执行到返回给用
户执行的结果。我们可以简单的把用例理解为系统提供给使用者的一个功能。
用例视图是被称为参与者的外部用户所能观察到的系统功能的模型图。用例模
型的用途是列出系统中的用例和参与者，描述参与者与用例的交互。这一步的工作，
就是对用户的需求进行仔细分析，确定系统的参与角色，并将需求的功能抽取为一
个个的用例，对每个用例进行详细的描述，最终构造出系统用例模型。
ｌ、捕捉领域词汇
该活动的目的是：定义系统开发过程中使用的领域词汇表或领域模型，统一所

有涉众对翘题所处领域的认识。通过确定与本系统交互的入或外部系统、并表示出
它们的职责，描述系统必须处理的内容的方式，来定义系统的范围。捕捉领域词汇
的具体方法有两种，一种是采用自然语言的方式来获取，另一种是通过领域模型的
方式给出。通过采用何种方式可以视具体项目和团体所熟悉的技能而定【５３ｌ。结合领
域分析中建立领域边界模型的分析方法来捕捉词汇表，通过这样的方法，可以很好
的定义所要分析领域的范围，或者说通过进行领域的上下文分析，分析出所处领域
１６
 第二章基于ＵＭＬ的构件需求分析

与外界元素问及其他构件间的关系，使最终识别的业务构件具有最合适的粒度和能
‘

够发挥最大的功能。
词汇表主要用于定义项目特定的术语，它有助于开发人员对项目中所用的术语
有统一的理解和使用，它也是后续阶段中进行对象抽象的基础【ｓ４１。本文采用自然语
言的方式捕获系统的词汇表。通过对系统的分析，可以捕获以下一些词汇；
（１）设备指企业中参与生产和服务于生产的各种硬件设施。
（２）设备管理员 是指负责设备基本信息维护的人员、负责设备状态管理的人
员。

（３）设备分类指为便于管理，将设备划分为不同的大类。
（４）设备状态指设备运行过程中或者非运行过程（比如检修时）的状态描述。
（５）设备维护指对设备维护计划的所有活动。
（６）设备维护人员指负责对响应维护请求，安排维护作业的人员。
（７）管理层人员 指单位的高层管理人员，主要来查询设备的各种情况。
（８）维护计划指对设备制定的维护计划。
（９）设备基本信息指与设备相关的各种数据及属性。
（１０）维修记录指对设备维修后添加到数据库的维修记录。
（１１）故障记录指设备出现故障后的情况记录。
２、确定系统参与者和用例
确定系统的参与者和用例是基于ＵＭＬ需求分析的重要部分。首先明确参与者
和用例的概念。
系统的参与者是在系统外部与该系统进行交互的人、其他系统或者外部硬件。
代表了必须与系统交换信息的所有事物，包括通常所谓的用户。当参与者使用系统
的时候，系统执行一个用例１４６ｌ。找出参与者有助于确定系统的边界，还有助于理解
系统的目的。
用例（Ｕｓｅ Ｃａ鳓是一组动作序列极其变体的描述，系统执行这些动作序列为特
定的参与者提供一个可观测的、有价值的结果。用例集合即描述了系统的完整功能
Ｉ删。

在企业Ⅻ巨Ｓ软件系统中，使用设备管理系统的人员通常为企业管理人员查询
设备情况；设备管理员利用本系统完成日常的设备信息维护、查询；设备状态的维
护管理。设备维护人员通过系统查询和维护设备维修、故障情况等。系统管理员负
责软件系统的维护和管理。由于与ＭＥＳ软件相交互的软件有上层的ＥＲＰ系统和下
层的与硬件数据采集有关的ＰＣＳ（过程控制系统）。因此，与设备管理系统相关的其
他软件系统有ＥＲＰ、ＰＣＳ等。再通过对以上设备管理系统几部分的功能具体分析，
可以抽象出以下几个参与者：

１７
 青岛大学硕士学位论文

（１）设备管理员 设备管理员包括对基本信息进行维护管理的人员和负责维护
设备状态的人员。其范围包括整个企业管理级别的管理员，也包括在各个分
部门中的设备管理员。其权限有所不同。主要职责分别负责设备基本信息的
维护（添加、删除、修改）和查询，对企业设备进行科学分类；和对设备状态
的维护管理。
（２）设备维护人员 维护人员包括对维护计划的维护人员和对设备维修的人员。
分别完成设备维护计划的制定、修改等操作。和对故障维修情况、维修报告
管理。
（３）管理层人员 管理层人员利用本系统主要完成对设备各种信息的查询。
（４）系统管理员负责维护和管理软件系统。
（５）ＥＲＰ系统在三层结构中与本系统交互的上层软件系统。
（６）ＰＣＳ系统在三层结构中与本系统交互的下层软件系统。
本文主要关注设备管理系统的业务功能，因此，在分析参与者时主要考虑设备
管理员，设备维护人员、和管理层人员。其他参与者在此不作深入研究。
确定用例的方式有两种，一种是根据系统业务模型确定用例，另一种是与客户
访谈和调查得到。根据需求阶段分析的功能模块，再加上其他的功能性需求和非功
能性需求来确定用例。
●功能性需求

除了上面介绍的系统原始需求，即系统的功能特征描述的内容外，功能需求还
包括：①组织机构的管理，用户权限的管理、操作用户、角色管理、系统的登录和
权限控制等。＠与设备管理活动有关的其他需求。
●非功能性需求

针对系统，提出了如下非功能性需求：①系统必须具有较好的开放性，能够通
过标准的技术手段与外部系统进行交互。且能够与ＭＥＳ中的其他子系统很好的交
互。②系统的可用性要求：平均无故障工作时间要大于１万小时。系统平均恢复时
间小于１小时。系统在网络的响应要求：在１００Ｍｂｐｓ速度下，保证１００万数据量表
的查询响应时间不超过２秒：完成一个完整的设备基本信息资料的响应时间不超过
５秒。时间的计算从信息提交开始，到得到响应为止。③系统稳定性要求：由于企
业生产的特殊性，系统必须支持７×２４小时不间断地工作，应用软件中的任一构件
更新和加载时，在不更新与上下构件接口的前提下，不影响业务运转和服务。④其
他的根据具体的企业环境和要求确定的非功能性需求。
３、用例图
根据确定用例的目标、要求和准则，结合对系统的原始需求的分析，对各大功
能模块分别建立用例模型。

１８
 第三章基于ＵＭＥ的构件需求分析

（１）设备基本信息管理的用例图：

划分设备类别

惭№Ｏ－一
Ｉ，一一
．／
，

，ｊ

一ｉ一……一矗 、～一“。 ｊ

设备管理员、 ．
查询设备基本信息
、－９”‘－ａ”●
（ｆｒｏｍ崩ｏｒｓ）
“，，一～
ｆ １

、、～一／
维护设备基本信息
脚∞Ｃ叫

图３．３设备基本信息管理的用例图

设备基本信息用例的描述如下：
・划分设备类别本用例完成对企业所有设备的类别划分，对设备进行科学编
码．这项活动由设备管理员完成。
・查询设备基本信息本用例完成设备基本信息的查询，为不同的参与者提供
有关设备的基本信息。维护设备基本信息完成对设备基本信息的添加、删除、
修改等基本操作。
（２）设备状态管理用例图：

ｏ
：，’维护设备运行状态

Ｃ州
，，’．

’，一７７●●ｏｍ ｔｌｍ

设备管理员
一。 查询设备状杏

蛳＾州 、●ｒⅫｔ■●Ｃ州

ｏ
．ｈ

维护故障报告
曲啊ｎ Ｕ－Ｃ，ｄｍｚ）

圈３．４设备状态管理的用倒图

１９
 青岛大学硕士学位论文

设备状态管理的用例描述如下：
●维护设备运行状态本用例完成对设备运行状态的ｊＩ矗控、记录、查询、修改、
填写处理情况。及对故障维修情况的记录、报告。完成本用例的是负责设备
状态维护的设备管理员。
●查询设备状态设备管理员查询具体设备的状态，以做出判断并对故障处理

提出处理办法。另外，管理层人员通过这项活动以查询设备运行状态。
・维护故障报告设备管理员负责完成对设备故障的诊断、故障的记录、修改
等操作。
（３）设备维护管理的用例图：

ｏ ｏ
，矗询维修记录
～查询设备基本信息
＋７。＿ｍｍ Ｌ－－Ｃ－－一

～Ｔ？二…ｏ
，一，’
如ｍ ＬＩ－ｃ－－－

Ｔ——…－＜ ）

设备维护人员 维护计划
设各管理员

帅ｍ＾∞一 伽ｍⅧ ‘、忡ｍｕ●油＿

提交维修报告
细ｍ‘－ｃ．－● 维护故障维修记录

ｆ∞ｍｔ－Ｃｔ－日

图３．５设备维护管理的用例图

设备维护管理的用例描述如下；
・查询设备基本信息本用例和设备基本信息管理中的查询设备基本信息用
例相同。主要完成设备基本信息的查询，为不同的参与者提供有关设备的基
本信息。包括设备管理员及设备维护人员都与本用例交互。本部分描述与设
备维护相关的部分。
●查询维修记录本用例完成查询具体设备的维修记录情况。
●维护计划本用例主要完成对设备维护计划的维护，包括维护计划的制定、

修改、删除、查询等操作。由设备维护入员发生交互。
●维护故障维修记录主要完成设备维修记录的添加、删除，修改操作。

●提交维修报告完成设备维修后，需要提交维护情况报告。设备管理员响应
本次报告的提交。因此与之发生交互的参与者还有设备管理员。
 第三章基于ＵＭＬ的构件需求分析

（４）设备台帐管理的用例图：

，
’

查询设备状杏
ｏ
查询维修记录

‘｝４。忡ｎｍ叫 舯”ｍ酬
一

～”～一，厂—、、—．４
／／
设备管理员 ＼ ”，’

和ｍ＾州 查询设备基本信息 设备维护人员

阳¨渊 ＃ｌｉｒａ＾ｍ一

图３．６设备台帐管理用例圈

本部分是前面三部分系统中的有关查询的用例集合。主要是为了系统的不同使
用者出于不同查询目的而抽取的专门的台帐查询子系统。因此，各个用例在前面已

经详细描述。在本部分中强调的是与各用铡发生交互的参与者的不同．
综上可以得到整个系统的用例图，如图３．７所示。

Ｑ ｏ
三！！∥／，／Ｉ“莲篙，，，，呈
设备二主＿＿～ｊｏ……一尹要：二一一。
设备管理员、、、 Ｌ 夕………尹，，：、～——一Ｌ 夕
如ｍ掣、｜、 、、、 查询设备基本信息 设备维护人员 维护计划

／如ｍＭ一 柳¨“一

＼，Ｑ、、６
１， 维护故障报告、———一／

／，一—、、蛳Ｌ－ｃ－・・ 提交维修报告
维护故障维惨记录
伽ｎ¨ｃ－－．

圈３．７系统整体的用倒关系图

２ｌ
 青岛大学硕士学位论文

通过分析用例图，抽象出了与设备管理系统交互的参与者：设备管理员、设备
维护人员。
１、设备管理员包括负责基本信息管理的人员和对设备状态维护的人员，设备
基本信息管理员负责对设备进行划分类别，以及对设备基本信息日常维护管理（包
括添加、删除、修改信息）和查询。查询设备基本信息是本系统中最通用的部分，
管理层人员和设备维护人员都要和这个用例发生交互，但获得的权限会不相同。设
备信息管理员同时还要对设备维护人员提交维护报告进行响应，做出处理。设备状

态管理员负责对设备运行状态的查询和维护，及对故障维护报告进行添加、修改、
删除等操作。
２、设备维护人员负责设备维护计划的维护（包括制定、检查、修改、删除等），
维修记录的查询和维护。另外，还要负责根据具体设备的故障和维修情况提交维修
报告。

３．２．３业务构件

１、业务构件识别
在完成了参与者和用例的建模后，接下来需要通过抽象出的用例识别业务构
件，从而建立业务构件列表。本部分的目的是：识别业务构件，并将捕获的功能需
求和非功能性需求分配给每个业务构件。为达到这个目的。需要通过理清各个业务
概念之间的关系，将需求结构化，从而使每个抽象出的用例总是从属于或者分配给
一个业务构件。
通过对ＩＶＩＥＳ中设备管理系统的功能分解，按照设备管理的流程并结合其他相
关的功能，可以形成下图所示的业务构件。

设备基本信息管理 设备状态管理

⑧Ｑ多④ ＼兰竺竺至／＼竺竺／＼竺皇／／

图３．８业务构件图

２２
 第三章基于ＵＭＬ的构件需求分析

如图３．８所示，系统的业务构件分为设备基本信息管理，设备状态管理、设备

维护管理、设备台帐管理四部分。设备基本信息管理有划分设备类别、维护设备信
息、维护设备信息三个用例；设备状态管理包括维护设备运行状态、查询设备状态、
维护故障报告用例；设备维护管理则包括查询设备基本信息、维护计划、维护故障
维修计划、查询维修记录、提交维修报告；设备台帐管理包括查询设备基本信息、
查询设备状态、查询维修记录三个用例。从图中可以看出，查询设备基本信息用例
出现在三个业务构件中。本文的构件分析也以查询设备基本信息为例进行分析设
计。
除了设备管理系统本身的业务功能以外，一个完整的应用系统还应包括角色管
理、用户管理、权限管理、机构管理等功能。本文在此对这几部分不做详细的功能
划分和介绍。
２、可复用资产分析
可复用资产是必须以一定成本获取的。软件对象”，这种资产必须使用多次才
能补偿这种成本。获取可复用资产有不同的途径，选择决策的主要因素最终是经济
原因。两种主要的获取途径是１５５ｌ：
（１）从外部机构购买可复用资产

（２）内部构建可复用资产
作为一条普遍规律，机构应该在不属于自己主要业务线的领域采购可复用组
件。机构应该仅仅内部构建包括以下特性的资产；
（１）对应其核心业务
（２）市场上没有

（３）在质量或成本上有竞争力优势
针对以上识别出的业务构件列表，对各业务构件进行可复用资产分析。在多数
企业信息管理系统已有的构件资产和商用构件库中，通常拥有用户管理、角色管理、
权限管理，机构管理等常用的构件，只是所提供的功能与待开发的系统需求有些可
能完全一致，如角色管理，有些会需要修改才能适应新系统。完全一致的构件可以
在新系统中完整复用；而需要修改的构件则进行扩展或者削减特性后再进行复用．
而对于砸ｓ中的针对具体领域中的具体业务构件，在公共构件库中很难找到
相同或者相似的构件，即没有可复用资产。需要开发的正是这样的业务构件。
３、确定业务构件需求
在前面识别的业务构件基础上，结合用例的需求，整理形成业务构件的需求列
表．
 青岛大学硕士学位论文

表３．１业务构件需求列表

业务构件 功能性需求 非功能性器求 复用分析

设备基本信息 实现对设备基本信息的管 要求２００个终端并发下响 没有复用资产

管理 理，包括：对设备的分类、 应时间不超过３秒．系统

和基本信息的添加、修改、 支持最高１０００个并发。

删除、查询等操作。

设备状态管理 实现对运行过程中的设备 要求２００个终端并发下响 没有复用资产

状态跟踪管理。包括：对设 应时间不超过３秒，系统

备运行状态的记录、设备状 支持最高１０００个并发。

态的维护、故障报告的维护

和故障维修情况的记录。

设备维护管理 实现对设备维护计划的各 要求５００个终端并发下响 没有复用资产

种操作、设备维修记录的添 应时间不超过３秒．系统

加和故障报告的提交。 支持最高１５００个并发。

设备台帐管理 主要实现对设备各种情况 要求５００个终端并发下响 没有复用资产

信息的查询。包括：基本信 应时间不超过３秒，系统

息的查询、设备状态的查 支持最高２０００个并发。

询、设备维修记录的查询。

用户管理 实现对系统操作员的统一 要求５００个终端并发下响 复用资产

管理。 应时间不超过３秒，系统

支持最高２０００个并发。

角色管理 提供对系统中操作角色的 要求８００个终端并发下响 复用资产

定义和管理功能。 应时间不超过３秒，系统

支持晟高２０００个并发。

权限管理 提供系统菜单权限管理的 要求１０００个终端并发下 复用资产

功能。 响应时间不超过５秒，系

统支持最高２０００个并发。

机构管理 提供系统使用者相关组织 要求５００个终端并发下响 复用资产

的管理功能。 应时间不超过３秒，系统

支持最高２０００个并发。
 第三章基于ＵＭＬ的构件需求分析

如表３．１所示，业务需求列表列出了业务构件的名称、功能性需求、非功能性

需求和对构件的复用分析。业务构件不仅包括针对应用系统的应用构件，还包括用
户管理、角色管理、权限管理、机构管理等。各业务构件的功能性需求列出了各个
业务构件在应用系统中实现的具体功能，非功能性需求主要列出了在构件在网络应
用中的并发要求。
 青岛大学硕士学位论文

第四章面向构件的分析与设计

分析与设计阶段是软件开发过程中的关键阶段，在分析阶段，通过精化和组
织需求捕获阶段所描述的需求来对其进行分析。这样做的目的是为了更精确地理
解需求，也是为了得到一个易于维护且有助于确定系统结构的需求描述。分析设
计活动的目的在于Ｉ耜Ｊ：
●将需求转换为未来系统的设计。
●逐步开发强壮的系统构架。

●使设计适合于实施环境，为提高性能而进行设计。

４．１软件架构

设计活动是以构架一系统构架或软件构架（对侧重于软件开发的系统而言）的

概念为中心展开。软件构架不仅是结构，ＩＥＥＥＷｏｒｋｉｎｇＧｒｏｕｐ０１１Ａｒｃｈｉｔｅｃｔｕｒｅ把其
定义为“系统在其环境中的最高层概念”嗣。构架还包括“符合”系统完整性、
经济约束条件、审美需求和样式。它并不仅注重对内部的考虑，而且还在系统的
用户环境和开发环境中对系统进行整体考虑，即同时注莺对外部的考虑。为了讨
论和分析软件构架，必须首先定义构架表示方式，即描述构架重要方面的方式。
建立系统的软件架构，可以为后续的分析和设计活动建立一种结构和分化，
以便开发人员在不同的开发阶段，以及同一开发阶段的不同开发人员，能够聚焦
于系统的不同部分，系统顶层架构是分析和设计阶段成果的载体．系统的顶层架
构一般用ＵＭＬ包图来表示。由于一个ＭＥＳ软件涉及的类非常多，因此在系统的
设计初期引入包图，会使系统更加的有层次，也增强了系统的可维护性。
包是模型的一部分，模型的每一部分必须属于某个包。设计人员可以将模型
的内容分配到包中．组织系统中的包有几种可能的方式，可以用视图、功能或者
选择其它基本原则来规划包。包是一种ＵＭＬ模型中一般的层次组织单元，如果
包的规划比较合理，那么能够反映系统的高层框架一相关系统由子系统和他们之
间的依赖关系组合而成。包之间的依赖关系概括了包的内容之间的依赖关系。
通过对ＭＥＳ设备管理系统的业务功能和用例模型的分析，设备管理系统采
用基于ＷＥＢ的三层的服务；用户界亟，业务逻辑、数据处理。用ＵＭＬ的包图来

表示它们之间的关系。
下图为所示的系统的三层结构。
 第四章面向构件的分析与设计

＜＜Ｌａｙｅｒ＞＞
：Ｕｓｏｒ ｋｔｅｄａｃｅ

Ｂｕｓｉｎｅｓｓ岫‘
１＜＜Ｌａｙｅｒ＞＞

｝＜＜Ｌａｙｅｒ＞＞
ＤａｔａＡｃｃｅｓｓ｛

图４－１系统的三层结构

由于基于构件的开发将系统分为了几个业务构件，对各个业务构件，本文同
样是以垂直的三层体系结构来分析设计，对各个构件中的用例采用三层模式进行
详细分解。

４．２业务构件分析

业务构件分析是针对需求阶段形成的业务构件进行分析，通过对各构件的用
例进行分析，获得角色和用例间的详细调用关系，以及分析类。从而得到各个构
件的类图。用例分析是建立分析模型的重要工作。

４．２．１用例分析

在完成了系统的需求分析后，为迸一步的对用例进行细化，需要进行用例分
析．用例分析的目的是Ｉ删：
●确定执行用例事件流的类。
●使用用例实现，将用例行为分配给那些类。
●确定类的职责、属性和关联关系。
●记录构架机制的使用情况。

４．２．２分析类

业务构件分析就是针对需求阶段形成的业务构件进行分析。类图是面向对象
系统的建模中最常见的图。类图显示了～组类、接口、协作及他们之间的关系。
 青岛大学硕士学位论文

本文用面向构件的开发方法，将各业务构件以三层架构的模式进行分解，抽象出
边界类、控制类、实体类等不同的构件分析类。
分析类代表了对系统设计中的一个或几个类或若予子系统的抽象。这种抽象
具有如下特点：
●分析类侧重于处理功能性需求，而把非功能性需求推迟到后续的设计与
实现活动中将需求标识为类的具体需求时再实现。

●分析类很少根据操作及其特征标记来定义或提供接口，而是通过较高的、
菲形式化层次的职责来定义其行为。
●分析类定义属性，但这些属性还处于较高的层次。
●分析类涉及到关系。
・分析类总能符合三种基本构造型中的一种：边界类、控制类或实体类
１、边界类
边界类是一种用于对系统外部环境与其内部运作之问的交互进行建模的类。
这种交互包括转换事件，并记录系统表示方式（例如接口）中的变更。边界类表示
系统与系统外的某个实体（个人或另一系统）之间的接口。其作用是促成系统与外
界交换信息，并使系统不受外界环境变化的影响。边界类对系统中依赖于参与者
的部分建模，即用于阐明和收集系统的边界需求。每个参与者，用例对都对应着一
个边界类。
边界类对系统中依赖予环境的那些部分进行建模。实体类和控制类对独立于
系统外部环境的那部分进行建模。因此，如果更改ＧＵｌ或通信协议，将只会更改

边界类，对实体类和控制类则毫无影响。常见的边界类有窗口、通信协议、打印
机接口、传感器和终端郴ｌ。
边界类帮助系统接口与系统外部进行交互。边界对象将系统与其外部环境的
变更（与其他系统的接口的变更、用户需求的变更等）分隔开，使这些变更不会对
系统的其他部分造成影响。在查找边界类的时候，关注于有什么信息呈现给用户，
而不是过多的关注于细节１４４Ｊ。一个系统可能会有多种边界类：
・用户界面类…帮助与系统用户进行通信的类
●
系统接口类一帮助与其他系统进行通信的类
・设备接口类一为用来监测外部事件的设备（如传感器）提供接口的类
２、控制类
控制类代表协调、排序、事务处理以及对其它对象的控制，控制类用于对一
个或几个用例所特有的控制行为进行建模。经常用于封装某个具体用例行为的协
调。每个用例对应着一个控制类。控制类将用例的特有行为进行封装。控制类依
赖于用例，独立于环境闱。
 第四章面向构件的分析与设计

控制类用于在系统中协调行为。系统可以在没有控制对象的情况下执行某些
用例（仅使用实体对象和边界对象），尤其是那些只需对已存储信息进行简单处理
的用例。控制类有效地将边界对象与实体对象分开，让系统更能适应其边界内发
生的变更。这些控制类还将用例所特有的行为与实体对象分开，使实体对象在用
例和系统中具有更高的复用性。控制类所提供的行为具有以下特点：
●独立于环境（不随环境的变更而变更）。
Ｏ确定用例中的控制逻辑（事件顺序）和事务．
●在实体类的内部结构或行为发生变更的情况下。几乎不会变更。
●使用或规定若干实体类的内容，因此需要协调这些实体类的行为。
●不是每次被激活后都以同样的方式执行（事件流具有多种状态）．
３、实体类
实体类是用于对必须存储的信息和相关行为建模的类。实体对象（实体类的实
例）用于保存和更新一些现象的有关信息，例如：事件、人员或者一些现实生活中
的对象。实体类通常都是永久性的，它们所具有的属性和关系是长期需要的，有
时甚至在系统的整个生存期都需要。实体对象代表了开发中的系统的核心概念。
实体类表示系统中的信息存储，它们一般用于表示系统所管理的核心概念。实体
对象经常是被动和永久性的。它们的主要职责是存储和管理系统中的信息。
我们经常是从词汇表（在需求阶段制定）和业务领域模型（如果进行了业务建
模，则在业务建模阶段中建立）中找寻到实体类的【嘏ｌ。
以下分别对需求阶段已经分析出的各业务构件的用例图分别进行分析。同时
通过对各用例的分析，也表现了各个业务构件中类的协作关系。

４．２．３业务构件中的用例分析

ｌ、设备基本信息管理
‘首先对设备基本信息管理用例中的各用例进行补充描述。
设备基本信息管理主要完成对设备基本信息的维护及查询管理。其中划分设
备类别用例是设备管理员在划分设备类别界面中，通过划分类别处理程序对设备
进行编号。查询设备基本信息用例是设备管理员、管理层人员、设备维护人员根
据一定的查询条件，在查询界面中提交给系统，由设备信息处理程序处理，并在
计算机上显示查询结果。维护设备基本信息用例则是设备管理员在维护界面中对
设备信息的添加、删除和修改操作．
遵循查找边界类的原则，通过进行用例分析，可以识别出以下边界类：

①划分类别界面：是由参与者设备管理员和划分设备类别这个用例间的交互
而抽象出的边界类。基本事件流程：设备管理员根据一定的规则首先将设备划分
 青岛大学硕士学位论文

成几个大的类别，然后逐级对类别进行细分，对每个类别进行科学编码。具体还
可以再分为输入设备类别和显示分类结果两个边界类，与划分类别界面为依赖的
关系。
②维护信息界面：参与者设备管理员和维护设备基本信息用例的交互。其中
又可细分为添加信息界面、修改信息界面、删除设备界面等三个边界类。
③查询信息界面：两类不同的参与者和查询设备基本信息用例间的交互。从

中可以发现较粗粒度的边界类一．查询信息界面边界类。同时，再根据三类参与者
的不同权限，查询不同的内容。
由控制类约定义和功能可知，每个用例对应着一个控制类，通过对用例图的

分析可以得出三个控制类，对于划分设备类别可以找出划分类别处理这个控制类。
相应地，查询设备基本信息和维护设备基本用例对应的控制类分别命名为查询信

息处理和维护信息处理。
由此，可以从设备基本信息管理这个业务构件中分析出三个控制类：分别是
对应划分设备类别的划分类别处理程序、对应查询设备基本信息的查询信息处理
程序、和对应维护设备基本信息的维护信息处理程序控制类。
根据实体类的概念和查找实体类的方法，以及对用例图的分析我们可以了解
到：对应设备管理员和设备维护人员，可以抽象出一个人员的实体类，这个实体
类根据权限的不同而访问不同的系统功能。对应划分设备类别这个用例，可以抽
象出设备类别实体类；而对应维护和查询设备基本信息两个用例，则都需要用到
设备基本信息数据，因此可以抽象出设备基本信息实体类。
 第四章面向构件的分析与设计

维护信息处理程序

“）边界类和控制类抽取图

鱼
设备类别
Ｑ
设备基本信息

（Ｂ）抽取的实体类

圈４．２设备基本信息管理分析类抽取幽

２，设备状态管理

在维护设备运行状态用例中，主要事件流程是设备管理员查询到具体设备后，
对运行状态进行监控；然后记录设备当前运行情况；对需要改变运行状态的设备
进行状态修改；最后要填写处理情况。然后返回系统。因此。设备管理员和维护
设备运行状态用例问可以抽象出一个维护状态界面豹边界类。在维护故障报告这
个用例中，设备管理员要对指定设备进行故障诊断、然后将故障记录及修改记录。
因此需要有维护故障报告的用户界面来支持设备管理员与维护故障报告用例间的
交互。在查询设备状态用例中，与之交互的是设备管理员和管理层人员两种参与
者，设备管理员包括信息管理员和状态管理员。这些用户在和本用例交互时，输
入要查询的条件，根据每种用户不同的权限，系统应得出不同的查询内容。由此
３１
 青岛大学硕士学位论文

抽象出查询设备状态界面。

根据查找控制类的方法和原则，每个用例对应着一个控制类，对于维护设备
运行状态用例，可以抽象出维护状态处理程序。再根据用例的事件流描述，可以
将这个控制类再细化为：查询信息处理程序和维护程序。由于查询信息处理程序
这个控制类在设备基本信息管理构件中已经抽取过，因此，可以直接将此控制类
引用。
对于查询设备状态用例，可以抽取一个查询状态程序的控制类。查询状态程
序接受设备管理员和其他查询人员输入的查询条｛牛，实现对具体设备运行状态的
查询。对于维护故障报告用例，设备管理员要对指定设备进行故障诊断、然后傲

故障记录及修改记录这些操作，将这些控制抽象成一个处理程序一维护故障报告
程序。再进行细化可以分为：故障诊断程序和维护故障记录程序。

在设备状态管理中，设备管理员使用系统维护设备运行状态时，需要处理的
或者与之有关系的数据包括设备基本信息数据、设备状态数据。查询设备状态时
则需要调用设备状态数据。而在维护故障报告时则需要用到故障记录数据。因此，
通过用例图和以上分析，从维护设备管理的用例中可以抽象出三个实体类：设备
基本信息实体类、设备状态数据实体类、故障记录数据实体类。
 第四章面向构件的分析与设计

ｏ
查询信怠处理程序
ｏ
维护程序
Ｒ 歹
、 ，

维护状态处理程序
ｌ

雏毋故障报寺程序

６
教障诊断程序 维护故障记录程序
ｂ
（．｜Ｉ）边界类和控制类抽取图

●
设备基本信息
量
设备状态数据
Ｑ
故障记录数据

∞抽取出的实体类

田４．３设备状态管理分析类抽取圈

３、设备维护管理
以下是对维护管理用例图中各用例的补充描述。
①查询设备基本信息。本用例和设备基本信息管理构件中的查询设备基本信

３３
 青岛大学硕士学位论文

息用例相同。不同的是，对于不同的人员查询信息时，需要对应此类人员相应的
权限和查询内容。
②查询维修记录。从数据库的维修记录表中得到设备的具体维修记录情况。
③维护计划。通过系统调用文件，完成设备维护计划的制定、修改、删除、
查询等操作。计划以文件的方式存储而不是以数据库的方式。
④维护故障维修记录。向数据库中添加维修记录数据，及从数据库中调用数
据加以修改和删除。
⑤提交维修报告。由维护人员以文件的方式完成维修报告，提交给系统，设
备管理员访闯报告文件。
通过以上的分析，根据查找边界类的方法和原则，每个参与者和用例的交互
都对应着一个边界类，可以找出几个边界类：查询信息界面、查询维修记录界面、
维护计划界面、维护维修记录界面、提交维修报告接口。其中对于管理层人员和
设备维护人员，对应的查询信息界面和查询维修记录界面两个边界类是相同的，
不同的是根据两类人员权限的不同所查询的内容会有所不同。权限分配不属于本
文讨论范围，在此不作深入讨论。

提交维修报告接ＩＺｌ

圈４．４设备维护管理边界类抽取图

通过对设备维护管理系统抽象出的五个用例的分析和用例补充说明，根据每
个用例对应着一个控制类的原则，可以找到以下几个控制类：查询信息处理程序；
查询维修记录程序；维护计划处理程序；维护故障维修记录程序；提交维修报告

３４
 第四章面向构件的分析与设计

程序。其中维护计划处理程序又包含制定计划程序、修改计划程序、删除计划程
序和查询计划程序。

＠
查询设备基本信息
ｏ
查询维修记录
。
提交维修报告
脚Ｕ∞Ｃ∞哪
怖Ｕｓｅｃａｗ） 脚ｕｏ・ｃａｍ）
ｌ
０
６一 ６一 ｏ
维护故障维修记录

ｌ
，
篇舌
，，维护妒处辈序、、
， ’ ’‘
ｏ
提交维修报告程序

制定计划
６０
修改计划删除计划查询计划

图４．５设备维护管理控制类抽取简图

分析设备维护管理中查询设备基本信息用例，相关联的参与者通过查询信息
用户界面浏览的内容是从数据库中调出的设备基本信息数据，同样的，在查询设
备维修记录用例和维护故障维修记录用例中，需要用到的数据是都是设备维修记
录数据，需要从数据库中调用此数据。由此分析，可以从中得到两个实体类：“设
备基本信息”，“设备维修记录”．
对于维护计划用例，和参与者直接关联的实体类是“维护计划”；对于提交维
修报告用例，可以得到“维修报告”这个显而易得的实体类。这两个实体类不存
储在数据库中，而是以文件的方式存储和应用。
 青岛大学硕士学位论文

鱼
设备基奉信息
鱼
设备维修记录
鱼
维护计划
鱼
维修报告

图４．６设备维护管理抽取的实体类

４、设备台帐管理
由台帐管理的用例图可以看出，台帐管理业务构件中的三个用例均是在前面
各个业务构件中已经分析过的。本部分仅是为了构件化的需要。将各业务构件中
的查询部分组织起来形成台帐管理系统，但其中的参与者、用例及之间的交互与
前面三部分中分析的相同。
因此，对于边界类的查找，将三种查询用例和参与者间的交互抽象出三个用
户界面。即在前三个系统分析中已经发现的三个边界类：查询信息界面、查询状
态界面、查询维修记录界面。同样地，控制类可以找到：查询信息处理程序、查
询状态处理程序、查询维修记录程序三个。而实体类则包括设备基本信息、设备
状态数据、设备维修记录。

Ｑ 岭
查询状态界面

（Ａ）边界类

查０

《一ｅｏ一量一鱼
设各基奉信息
怠重
设备状态数据
ｏ一愈量
设备维修记录

（ｃ）实体类

图４．７设备台帐管理分析类

４．２．４业务构件类图

确立系统的类图是建立系统的分析模型中重要的工作。类反映了一种面向对
象方法看待物理世界的观点，它是面向对象的标志。ＵＭＬ的最终目标是识别出所
有必须的类来，分析这些类之间的关系，从而通过编程语言来实现这些类，并最

３６
 第四章面向构件的分析与设计

终实现整个系统。类图显示了一组类、接口、协作及他们之间的关系，类图是用
来描述系统中类的静态结构的。
建立类图，需要定义类之间的关系，类问的关系主要有以下几种：关联、依
赖、泛化、实现。
通过对几个业务构件的分析，以下给出了设备基本信息管理、状态管理、维
护和台帐管理的类图。

卜◇
ＢａｓｅｔＯｏＦｏｒｍ

—ｔ竺！竺℃１
／’啊ｅｗＥＣｂｓｓｎ 、、

～ｅｗｅａｓｅ－ｏ＇０
７

ＣｌａｓｓｈＳ／Ｆｏｎｎ
∥６
Ｍａｉｎｔａｉｎｔ＇ｄｏＦｏ呷
卜＠
ＩｎｑｕｌｒｅｌｎｆｏＦｏｒｍ

Ｃｌａｓｓｉｆ，Ｃｏｍｏｂｒ
口ｊ、＿Ｑ ｒｈｏ
ＥＣｌａｓｓ ＭａｉｎｔａｉｎｌｒｄｏＣｏｒｍｏｌｅｒ Ｂａｓｅｂｌｏ
、园 叩ｏ
ｈｑ岫甘－佃Ｃｏ帆●盯

圈４．８设备基本信息管理类圈

在基本信息管理类图中，ＢａｓｃｌｎｆｏＦｏｒｍ边界类所反映的是信息管理构件的主
界面。要实现基本信息管理，还必须有三个分界来支持完成：Ｃｌａｓｓ的Ｆｏｒｍ（设备
分类管理界面）、ＭａｉｎｔａｉｎｌｎｆｏＦｏｒｍ（基本信息维护界面）、ＩｎｑｕｉｒｅＦｏｒｍ（查询界面）。
其中ＭａｉｎｔａｉｎｌｎｆｏＦｏｒｍ包括设备的添加、删除、和修改等基本操作界面。三个分
界面与ＢａｓｅＩｎｆｏＦｏｒｍ是聚合的关系．Ｂ翘ｓｃ［ａｆｏＦｏｒｍ对应Ｏａｓｓｉｆ）ｒＦｏｒｍ和
ＭａｉｎｔａｉｎｌｎｆｏＦｏｒｍ的多重性关系都是０．．１，是因为对于设备类别的管理和信息维护

管理只有有管理权限的设备管理员有权使用。而对应ＩｎｑｎｉｒｃｌｎｆｏＦｏｒｍ，则由于会
有不同的人员查询信息，因此多重性为ｏ．．・．

ＣｌａｓｓｉｆｙＦｏｒｍ类所表示的操作界面，分别有一个ＯａｓｓｉｆｙＣｏｎｔｒｏｌｌｅｒ控制类（设
备分类控制程序）和ＥＣｌａｓｓ实体类（设备类别）相对应，它们之间的多重性都是ｌ

与１关系。ＥＬ＇ｌａｓｓ类和ＣｌａｓｓｉｆｙＣｏｎｔｒｏｌｌｅｒ类间是依赖的关系。分别和

３７
 青岛大学硕士学位论文

ＭａｉｎｔａｉｎｌｎｆｏＦｏｒｍ和ＩｎｑｕｉｒｅｌｎｆｏＦｏｒｍ相联系的控制类是ＭａｉｎｔａｉｎｌｎｆｏＣｏｎｔｒｏｌｌｅｒ和

ＩｎｑｕｉｒｅｌｎｆｏＣｏｎｔｒｏｌｌｅｒ。而由于ＢａｓｃＩｎｆｏ是两个控制类都需要的实体类，因此，
ＢａｓｅＩｎｆｏ依赖于两个控制类。每个分界面类与控制类和实体类的多重性都是１和
１的关系。

卜∥７量№。竽
毋＿ｉ●再删￡
ｏＩ－一⑦～键Ｌ＼！？一笔甲删
～～ｅｆ洲一“８一‘、“◇
艘嚣灞

◇
ＩｎｑｄｒｅＺｑｋ，‘３０ｍｏｌｅｒ
沏蕃车僖雇管理鞠梓’

圈４．９设备状态管理类图

在设备状态管理类图中，ＳｔａｔｕｓＦｏｒｍ边界类代表的是状态管理构件的主界面。
它由三个分界面聚合而成：ＭａｉｎｔａｉｎＳｔａｔｕｓＦｏｒｍ（维护状态界面）、

ＩｎｑｕｉｒｅＳｔａｔｕｓＦｏｒｍ（查询状态界面）和ＭａｉｎｔａｉｎＦａｉｌｕｒｅＲｅｐｏｒｔＦｏｒｍ（维护故障报告界
面）。三个界面由于操作用户和权限的因素而使多重性不同，分别为１对应：ｏ．．・，
０．．‘，０。ｌ。

一个ＭａｉｎｔａｉｎＳｔａｔｕｓＦｏｒｍ边界类与一个ＭａｉｎｔａｉｎＳｔａｔｕｓＣｏｎｔｒｏｌｌｅｒ（维护状态控

制程序）控制类和一个ＳｔａｔｕｓＩｎｆｏ（设备状态）实体类分别有多重性为一对一的联
系。而ＭａｉｎｔａｉｎＳｔａｔｕｓＣｏｎｔｒｏｌｌｅｒ控制类则依赖ＩｎａｕｉｒｅＩｎｆｏＣｏｎｔｒｏｌｌｅｒ控制类（查询信
息程序，来自于基本信息管理构件）和Ｍａｉｎｔａｉｎ控毒８类（维护程序）来完成对状态

的维护。Ｍａｉｎｔａｉｎ类和Ｓｔａｔｕｓｌｎｆｏ类问是依赖的关系。与ｌｎｑｕｉｒｅＳｔａｔｕｓＦｏｒｍ边界类
（查询状态界面）相关联的ｌｎｑｕｉｒｅＳｔａｔｕｓＣｏｎｔｒｏｌｌｅｒ控制类（查询状态程序）同样依赖
于Ｓｔａｔｕｓｌｎｆｏ实体类完成操作。在ＭａｉｎｔａｉｎＦａｉｌｕｒｅＲｅｐｏｒｔＦｏｒｍ界面中，ＦａｉｌｕｒｅＲｅｐｏｒｔ
实体类则依赖ＭａｉｎｔａｉｎＦａｉｌｕｒｅＣｏｎｔｒｏｌｌｅｒ控制类（维护故障控制程序）．三个部分边
 第四章面向构件的分析与设计

界类和它们对应的控制类和实体类间的多重性关系是１和１的关系。

卜◇
％
罢 ＭａｉｎｔｅｍｍｅＰｌｅＮ：ｏｎｎ

‘．，

◇ ｝１
＇

零
蛳
⑦
”◇ Ｍ柚—睢ｒ啪Ｍ峭嘲ｄＣ
ｏｍ口ｔｈ
，／
｝ ，

ｌ ｂ，，，。

、◇
呐＿糟Ｍ旧ｂ∞｜ｄＣ埘州 ＭａｉｎｔａｉｎＦｌｅｅ州ｌ
ｅｒ

图４．１０设备维护管理类图

设备维护管理类图中的维护主界面（ＥＭａｉｎｔａｉｎＦｏｒｍ）包括五个部分：
ｌｎｑｉｕｒｅｌｎｆｏＦｏｒｍ（查询信息界面）、ＩｎｑｕｉｒｅＭｔＲｅｃｏｒｆＦｏｒｍ（查询维修记录界面）、
ＭａｉｎｔｅｎａｎｃｅＭｔＲｅｃｏｒｄＦｏｒｍ（维护维修记录界面）、ＭａｉｎｔｅｎａｎｃｅＰｌａｎＦｏｒｍ（维修计划
界面）、ＤｅｌｅｖｅｒｙＭｔＲｅｐｏｒｔ（提交维修报告）．主边界类与五个分边界类问的关系是
聚合的关系，多重性根据不同的访问人员分别是１对应于ｏ．．・，ｏ．。・，Ｏ。１，ｏ．．１，
ｏ．．・。

对维护管理类图，由于篇幅的关系，本文只分析其中一部分关联类。查询信
息界面所关联的查询控制程序和设备信息类都是来自于设备基本信息管理构件，
它们间的关系在基本信息管理构件中有详细分析．ＩｎｑｕｉｒｃＭｔＲｃｘ：ｏｒｍＦｏｎｎ边界类
和ＩｎｑｕｉｒｅＭｔＲｅｃｏｒｄＣｏｎｔｒｏｌｌｅｒ控制类（查询维修记录程序）、ＭａｉｎｔａｉｎＲｅｃｏｒｄ实体类
（维修记录）相关联；多重性是１和１关系．ＭａｉｎｌｅｎａｎｃｅＭｔＲｅｃｏｒｄＦｏｒｍ和
ＭａｉｎｔｃｎａｎｃｅＭｔＲｅｃｏｒｄＣｏｎｔｒｏｌｌｅｒ控制类（维护维修记录程序）、ＭａｉｎｔａｉｎＲｅｃｏｒｄ实体
类（维修记录）相关联。多重性是１和１。而ＩｎｑｕｉｒｅＭｔＲｅｃｏｒｄＣｏｎｔｒｏｌｌｅｒ和
ＭａｉｎｔｅｎａｎｃｅＭｔＲｅｃｏｒｄＣｏｎｔｒｏｌｌｅｒ两个控制程序都需要依赖ＭａｉｎｔａｉｎＲｅｃｏｒｄ实体类
完成功能。
 青岛大学硕士学位论文

一一１ ”１⑦
Ｖ・。ｌ壤∥《辫

＠ —姗．维护管理构嚆Ｊ

ｏ
－田Ｕ嘻Ｓ妇■＿Ｃｏ啪－阿 Ｓｔａｔｍｌｒ／ｏ

—蛳状蠢管理掏件）舯ｍ状杏管理构件Ｉ

图４．１１设备台帐管理类图

设备台帐管理的类图是各个构件类图中与查询功能相关的类集合，主要是完
成各类用户需要的查询功能。其中类的相互关系在以上的各个构件类图中已经作
了详细说明。

通过对以上类图的分析，可以得到系统的七个实体类：设备类别、设备基本
信息、设备状态数据、故障记录数据、设备维修记录、维护计划、维修报告。下
图是几个实体类的属性及关系。

ｊ—
一 ～晰 钆一，
／
ｒ—
］■｜｝ｌ，■＿千、

故障记录
鞋嘲——
岛Ｆ酬ｕｒ喇
—ｄ２＞Ｆａｉｌｕｒｅ＇ｌｉｍｅ
ｊｂＦ酬ｕｆｅＴｙ弦ｉ
●…１。。１。‘１１’——
岛…

圈４．１２实体类及类问关系
４０
 第四章面向构件的分析与设计

需要说明的是，设备类别和设备两个类的ＥＣｐｒｏｐｅｒｔｙ和Ｅｐｒｏｐｅｒｔｙ分别指的
是设备类别和设备的属性，在这个图中是对属性的总体概括，在详细设计时，本
文引用￥９５中的设备对象模型标准，将设备类别和设备的属性单独作为两个类来
进行处理。通过这样的方法，可以提高系统的可扩展性，增强系统的灵活性。如
在数据库结构设计完成后，因为某些原因需要增加类的属性，在传统的已经将表
设计好了的情况下，只能将数据库的结构作出修改才能完成，而在这样的设计下，
可以将新的属性作为Ｐｒｏｐｅｒｔｙ的一个记录添加即可达到相同的目的。
￥９５标准中指出，设备资源模型用于定义设备和设备等级，定义设备的描述，
定义设备的能力，定义设备能力测试、测试结果和结果的有效时间段，以及定义
和跟踪设备维护请求［５７－５９１．本部分抽取设备类和设备的关系模型图。以下是对设
备类别和设备两个类的类图、两个类之间的关系的详细说明。

圈４．１３设备类别和设备类的关系类图
类图说明：

１、一个设备类别（ＥｑｕｉｐｍｃｎｔＣｌａｓｓ）是为了调度和计划，将一些具有相同特性
的设备进行分组定义。任何一台设备都可能属于零个或多个设备类别．
２、每一个设备类别可能有零个或多个可识别的属性
（ＥｑｕｉｐｍｅｎｔＣｌａｓｓＰｒｏｐｅｒｔｙ）。
３、设备Ｅｑｕｉｐｍｅｎｔ是指ＩＶＩＥＳ系统各个分级结构中的具体设备。它可能是企

４１
 青岛大学硕士学位论文

业级的设备，也可以是生产单位、生产线、工作单元、处理单元或者单元中的设
备。

４、一个设备Ｅｑｕｉｐｍｅｎｔ可能有零个或多个设备属性（ＥｑｕｉｐｍｅｎｔＰｒｏｐｅｒｔｙ）・这
些属性指定了设备属性值，并关联到设备分类属性。设备属性可能包括计量单位。
在前面的讨论中，设备的详细属性，如设备名称、设备型号、购买时间、所属部

门等等，均可以添加到设备属性（ＥｑｕｉｐｍｅｎｔＰｒｏｐｅｆｔｙ）中ｔ
通过前面章节对用例的分析，本文将￥９５的设备模型在原有基础上进行了改

进，将设备类别类（Ｆ＿ｑｕｉｐｍｅｎｔＣｌａｓｓ）和设备类（Ｅｑｕｉｐｍｅｎｔ）增加了增加、删除、修
改等维护操作。这几个方法分别为：

对应设备类别类（ＥｑｕｉｐｍｅｎｔＣｌａｓｓ）的三个方法：
ＡｄｄＥｃｌａｓｓ ０：

ＤｅｌｅｔｅＥｃｌａｓｓ（）：

ＭｏｄｉｆｙＥｃｌａｓｓ（）：
对应设备类（Ｅｑｕｉｐｍｅｎｔ）的三个方法：
ＡｄｄＥｑｕｉｐｍｅｎｔ（）：
ＤｅｌｅｔｅＥｑｕｉｐｍｅｎｔ（）：
ＭｏｄｉｆｙＥｑｕｉｐｍｅｎｔ（）：
而对查询功能，则增加了一个（ＥＯｓｅａｒｃｈ）类，来实现设备类别和具体设备的
信息查询。ＥＯｓｅａｒｃｂ类包含三个方法：
ＢｏｎｏｗｅｒＩｎｆｏｒｍａｔｉｏｎ０：主要显示查询到的设备类别信息或者具体设备信息。

ＧｅｔＥｑｕｉｐｍｅｎｔＣｌａｓｓ（）：得到设备类别的信息。

ＧｅｔＥｑｕｉｐｍｅｎｔ（）：得到设备信息。

４．３业务构件设计

４．３．１构件分解

在前面的构件分析中，初步完成了对四个反映业务需求的业务构件分析，将
四个业务构件中边界类、控制类、实体类进行了详细抽取与说明，并且将各分析
类映射到各系统的类图中，形成了各个构件的详细类图表示。同时这也是从业务
层面向技术层砸过渡的阶段，体现了实现的大致模型。在业务构件设计阶段，刚
需要以技术实现的视角，精确完成业务构件的构件分析；并完成各个业务构件的
接口定义。通过对各个业务构件的细化分析，我们可以知道，在四个业务构件中，

设备基本信息管理中的基本信息查询是最通用的一个业务功能，无论是基本信息
管理，维护管理、状态管理，都会与之相关联．因此，设备基本信息查询可以抽
 第四章面向构件的分析与设计

取为几个业务构件功能中的共性部分。因此限于篇幅，并且为了分析的清晰性，
本文以设备基本信息管理中的设备信息查询为例进行说明。
通过对以上查询设备基本信息的分析。以及抽取出的分析类：查询信息界面
（边界类）、查询信息处理程序（控制类）、设备基本信息（实体类）。可以得出查询
过程的构件分解类图。

卜ｏ………ｏ
查询信息界面 查询信息处理程序
ｏ
设备基本信息

图４．１｛查询设备信息构件分解图

然而，仅仅按照这三个类的交互，很难看出系统细节的交互。因此，可以对
各个部分再进行分解：对于。查询信息用户界面”，再加入“查询信息结果”．形
成新的设备信息查询边界类—信息查询显示控制。而对于查询信息处理程序，也
同样进行分解，再细分为：“建立查询条件”和“查询记录”．得到的新的设计图
如图４．１５所示。

磊一
霉
匿，、国、鲴
图４．１５查询设备信息构件细化分解图

通过分析，与设备信息管理有关的接口除了查询外，还可以扩展出其他几个
接口．如添加设备信息、修改设备信息、删除设备信息等维护信息接口，对应于
设备类趴，还可以扩展出归属设备类鄹接口。
在此基础上，再进行其他接口的定义，以及对业务构件的非功能特性的描述，
最终形成设备信息管理的业务构件设计图。由于篇幅原因，本文在业务构件模型
图中仅是对设备信息查询业务进行了协作分析，在完整的应用中，还包括添加信
息、修改信息、删除信息、类别管理等部分的协作关系图。业务构件提供的接口
 青岛大学硕士学位论文

包括维护信息和归属类别。维护信息接口包括：查询信息、添加信息、修改信息、
删除信息等功能。如图４．１６所示。

图４．１６业务构件模型图

以下程序段是设备维护接口的定义，如图４．１７所示。
ｐｕｂｌｉｃ ｉｎｔｅｒｆａｃｅ ＭａｉｎｔａｉｎＩｎｆｏ

ｓｔｒｉｎｇＡｄｄｌｎｆｏ（ｓｔｒｉｎｇ ＥｑｕｉｐｍｅｎｔＩＤ）； ，滕加设备基本信息

ｓｔｒｉｎｇ Ｄｅｌｅｔｅｌｎｆｏ（ｓｔｒｉｎｇ ＥｑｕｉｐｍｅｎｔＩＤ）； ／／删除设备基本信息

ｓｔｒｉｎｇ Ｍｏｄｉｆｙｌａｆｏ（ｓｔｒｉｕｇ ＥｑｕｉｐｍｅｎｔＩＤ）； ，／修改设备基本信息

ＩⅪ，ｅｌ ＩｓＥｘｉｓｔＩｎｆｏ（ｓｔｒｌｎｇ ＥｑｕｉｐｍｅｎｔｌＤ）； ，脸验信息是否已存在

ｓｔｒｉｎｇ Ｑｕｅｒｙｌｎｆｏ（ｓｔｒｉｎｇ ＥｑｕｉｐｍｅｎｔｌＤ）； ，，查询设备基本信息

国４．１７设备维护接口定义

维护信息接口则分别由查询信息、添加信息、修改信息、删除信息四个功能
接口实现。如图４．１８所示。
 第四章面向构件的分析与设计

————————…——
‘‘Ｉｎｔｅ衄ｅ＇＇
｝ＭａｉｎｔａｉｎＩｎｔｅｒｆａｃｅ；

一ｊ………１一《ｊ 一
Ｌ

／ ／ ｌ ／

——一 Ｐ。一——

Ｍｏｄｉｆｙｌｎｆｏｒｎｔｅｒｆａｃｅ ＤｅｌｅｔｅｌｎｆｏＩｎｔｅｒｆａｃｅ
ＲｅｑｕｉｒｅｌｎｆｏＩｎｔｅｒｆａｃｅ：一ＡｄｄｈｆｏＩｎｔｅｒｆａｃｅ。
三一：：：二二：。二二：ｌ＝：：二：二二：：：：二ｊ ＝二二二：Ｎ，。二＝一二二习Ｅ＝二：二ｊ二二二：一■二：■

图４．１８维护信息接口实现

其中，添加基本信息的操作实现如图４．１９所示：

ｐｕｂｌｉｃ ｉｎｔｅｒｆａｃｅ ＡｄｄＩｎｆｏ（Ｉｎｆｏ）ｔｈｒｏｗｓ ＥｑｕｉｐｍｅｎｔＥｘｃｅｐｔｉｏｎ

｛
Ｅ＿ＴｒａｎｓａｃｔｉｏｎＢｅｇｉｎ０； ，庳务开始
ｉｆ（Ｅ＿ＥｘｉｓｔｌｎｆｏｌＤ（ＩｎｆｏｌＤ））胴事在相同的设备ＩＤ，调用异常
ｔｈｒｏｗ ｒｔｕ－ｗ ＥｑｕｉｐｍｅｎｔＥｘｃｅｐｔｉｏｎ（”Ｔｈｉｓ ＩＤ ｃｕｒｒｅｎｔｌｙ ｅｘｉｓｔｓ！”）；

ｉｆ（Ｅ＿ＡｄｄＩｎｆｏ（］ｎｆｏ））
｛
Ｅ＿ＴｒａｎｓａｃｔｉｏｎＣｏｍｍｉｔＯ； 膊务提交
ｒｅｔｕｍ ｔｒｕｅ；

｝
ｅｌｓｅ

｛
Ｅ＿ＴｒａｎｓａｃｔｉｏｎＲｏｌｌｂａｃｋ０； ，腿回
ｒｅｔｕｒｎ ｆａｌｓｅ；

｝
｝

圈４．１９添加信息功能实现
 青岛火学硕士学位论文

同时，根据分析，建立了业务构件的构件规约表，如表４．１所示。

表４．１设备信息管理构件的构件规约

构件描述 设备信息管理 构件名称 ＥｑｕｉｐｍｅｎｔＡｄｍｉｎ

构件类型 业务构件 设计人 陈伟 设计日期 ２００７．５．１０

功能特性 实现对设备基本信息的管理。通过这个构件，设备管理员和设备

维护人员以及其他人员对设备基本信息的各种管理操作。

非功能特性 支持浏览器模式。查询响应时阀不超过５秒

部署要求 作为设备管理构件中的一个业务构件，部署在ＩＶＩＥＳ设备管理系统

中。

服务功能列表

名称 描述

ＥｑｕｉｐｍｅｎｔＱｕｅｒｙｌｎｐｕｌ 设备基本信息记录查询的条件输入

ＥｑｕｉｐｍｅｎｔＱｕｅｒｙＣｏｎｔｒｏｌ 设备基本信息记录查询的控制逻辑

１。

魄杵提快搓鼯 ？
接口名称 接口描述

ＳｅｔＣｌａｓｓｉ母 归属类别

Ｍａｉｎｔａｉｎｌｎｆｏ 维护设备基本信息

接口功能名称 功能描述

ＥｑｕｉｐｍｅｎｔＡｄｄ 添加设备基本信息

ＥｑｕｉｐｍｅｎｔＭｏｄｉｆｙ 修改设备基本信息

ＥｑｕｉｐｍｅｎｔＤｅｌｅｔｅ 删除设备基本信息

４．３．２动态模型

在分析了业务构件的各对象和对象闯的关系的静态结构后，下面要关注的是
在任何时刻对象及其关系改变的情况，这些情况可以用ＵＭＬ的动态模型进行形
象化描述ｌ删，由于ＵＭＬ中的各种动态视图表达的视角不同，对于设备信息管理
系统中的基本信息维护、查询等操作，可以借助ＵＭＬ中的时序图来描述。
时序图（Ｓｅｑｕｅｎｃｅ Ｄｉａｇｒａｍ）表示对象之间传递消息的时间顺序，阐明对象之
４６
 第四章面向构件的分析与设计

闻的交互过程以及在系统执行过程中的某一具体时刻将会发生什么事件。时序图
是一种强调时间顺序的交互图，其中对象沿横轴排列，消息沿纵轴排列，序列图
中的对象生命线是一条垂直的虚线它表示一个对象在一段时间内存在１６ｌＩ。
时序图着重描述设备基本信息维护和查询过程中多个对象消息传递的时间顺
序。即在对象间如何发送和接收消息。
以下是设备基本信息的查询和修改的时序图。

图４．２０设备基本信息查询时序圈

设备管理员（或者设备维护人员和高层管理人员，本例以设备管理员为例进行
查询时序图的说明）首先根据要查询的设备，输入特定的查询条件，再根据不同的
操作人员输入验证条件，通过提交查询请求，调用查询逻辑的程序，从数据库中
获得查询数据。再将所得到的符合条件的数据返回到显示界面上，完成设备信息
的查询。

４７
 青岛大学硕士学位论文

；监釜鳘璺县＿曾］’量差盏壹ｆｌ一凿 ～礁馥盘盈Ｉｊ］ｆ一五盔基盔岳＿］
一息显鞋—Ｊ
Ｌ盟牲。Ｊ
｝…．兰：提銮李询请毫…专－，
：１＝输入查询条年——一三；呸｝询请毫…０一
，
Ｈ— ３：调用＃询数据…。＞ｆ

ｊＩ
｛
ｆ
ｌ｛ｐ改净
｝ 忙５：修改专备信息
１』 够修堕绰熨

。：上览 ｆ一－一ｒ示
ｆ～…ｒ…］］Ｌ『】
｝

、．

图４．２１修改设备信息时序图

对设备信息的修改由设备管理员来完成，在修改具体设备信息前，需要首先
查询指定的设备，获得查询到的信息后，再通过修改信息逻辑处理程序来完成。

最后将修改后的数据存储到数据库中，完成对指定设备信息的修改。

４８
 第五章构件实现

第五章构件实现

５．１数据模型

完成了业务构件的分析与设计工作后，系统的架构已经基本确立，包括了各个
构件的接口规约等重要的部分。在实现阶段，业务构件需要调用服务构件提供的服
务，数据服务构件是其中重要的一部分。数据库系统是软件系统中的基础核心部分，
数据库的选择和设计直接关系到软件系统的安全和效率。本文依据￥９５设备对象模
型标准中设备类别和设备及它们的属性的定义，根据以上对系统的分析设计模型，
用ｓｑｌ Ｓｃｒｖｃｒ ２０００设计给出了ＭＥｇ设备管理系统的部分数据库表及之间的相互关
系。

衰５．１设备类别表（Ｅｑｕｉｐｍ盹ｎｔＣｌａｓｓ）

ｌ 列名 数据类型 描述 Ｉ
ＥＣＩＤ ｖａｆｃｈａｒ 特定设备类别的唯一标识 ｌ
ＥＣＤｅｓｃｒｉｐｔｉｏｎ ｖａｒｃｈａｒ 设备类别的附加信息 ｌ

表５．１所示设备类别表。一个设备类别就是为了调度和计划，将一些具有相同

特性的设备进行分组定义。ＥＣＩＤ代表的是设备类别的ＩＤ，而ＥＣＤｅｓｃｒｉｐｔｉｏｎ是对指
定类别的描述。例如：ｍ为ＡＯＯＩ，ＥＣＤｃｓｃｒｉｐｔｉｏｎ为反应堆单元．

表５．２设备类别属性表（ＥｑｕｉｐｍｅｎｔＣｌａｓｓＰｒｏｐｅｒｔｙ）

列名 数据类型 描述

ＥＣＰⅡ＇ ｖａｌ℃ｈａｆ 特定设备类别属性的唯一标识

ＥＣＰＤｅｓｃｒｉｐｔｉｏｎ ｖａｒｃｈａｒ 设备类别属性的附加信息

ＥＣⅥｄｌ坼 ｖａｘｃｈａｒ 值、值的集或特性范围

ＥＣ、Ｊ；ｌｌｕｃＵｎｉｔ ｖａｒｃｈａｒ 计量单位

表５．２为类别属性列表。每一个设备类别可能有零个或多个可识别的属性。设
备属性列表描述类别属性。例如：。反应堆单元”可能是。内层物料”．

衰５．３设备表（Ｅｑｕｉｐｍｅｎｔ）

Ｉ 列名 数据类墅 描述

ｌ Ｅ１１） ｖ盯ｃｈａｒ 特定设备的唯一标识

Ｉ ＥＤｃｓｃｒｉｐｔｉｏｎ ｖ盯ｃｈａｒ 设备的附加信息

 青岛大学硕士学位论文

在ＭＥｓ的结构模型中，设备可能是Ｓｉｔｅ、Ａｒｅａ、生产单位、生产线、工作单元、
处理单元或者单元中的定义。如：一个生产线可能有工作单元组成，设备就是“反
应堆单元１号”。表５．３设备表仅包括ＥＩＤ和ＥＤｅｓｃｒｉｐｔｉｏｎ。

表５．４设备类别属性表（ＥｑｕｉｐｍｅｎｔＰｒｏｐｅｒｔｙ）

列名 数据类型 描述

ＥＰｍ ｖａｒｃｈａｒ 特定设备属性的唯～标识

ＥＰＤｅｓｃｒｉｐｔｉｏｎ ｖａｒｃｈａｒ 设备属性的附加信息

Ｆ池ｌｕｅ ｖａｒｃｈａｒ 殖、值的集或特性范围

ＥＶｈｌｕｅＵｎｉｔ ｖａｒｃｈａｒ 计量单位

一个设备可能有零个或多个设备属性。这些属性指定了设备属性值，并关联到
设备类别属性。设备属性可能包括计量单位。一个设备分类属性可能是“体积”并
且它的值将是“５０００”，计量单位是“公升”，设备属性可能是“内层材料”并且他
的值是“玻璃”。表５．４列出了设备的属性列。

表５．５设备状态表（ＥｑｕｉｐｍｅｎｔＳｔａｔｍ）

列名 数据类型 描述

ＥＳⅢ ｖａｒｃｈａｇ 设备状态标识

Ｅｍ ｖａｔｃｈａｔ 所指定的相关设备标识

ＥＳＣｏｄｅ ｖａｒｃｈａｒ 状态代码

ＥＳＤｅｓｃｒｉｐｔｉｏｎ ｖａｒｃｌｍｒ 状态描述

表５．５设备状态表中定义了设备状态ｍ，所关联的设备Ｄ，及设备状态的指
定代码。ＥＳＤｅｓｃｒｉｐｔｉｏｎ则是对状态的描述。

表５．６设备维修记录表（ｈｌｕｉｐｍｅｎｔＭａｉｎｔｅｎａｎｃｅ）

列名 数据类型 描述

ＥＭＲＩＤ ＹⅡｃｂ∞ 设备维修记录标识

Ｅ卫Ｄ ｖａ曲ａｒ 特定维修的设备的唯一标识

ＥＭＲＤｅｓｃｒｉｐｔｉｏｎ ｖ缸Ｃｈ毓 维修描述

ＥＭＲＰｅｏｐｌｅ ｖａｒｃｂａｒ 维修人

ＥＭＲｌ铀ｅ Ｄａｔｅ 维修时间

表５．６维修记录表中则定义了维修记录的ｍ，所关联的设备Ⅲ，对维修的描
述以及维修人员和维修时间信息ａ

５０
 第五章构件实现

图５．１数据库表关系图

系统数据库表间的关系，如图５．１所示，设备类别和设备及与其各自的属性表
问的关联是以ＩＶＩＥＳ设备模型为基础进行设计关联，设备状态和维修记录表与设备
表相关联。主键显示了相互之间的关联关系。

５．２系统界面

业务构件的实现系统采用Ｂ／Ｓ结构，即Ｂｒｏｗｓｅｒ／Ｓｅｒｖｅｒ（浏览器／服务器）结构。
这种结构以ＷＥＢ为中心，采用ＴＣＰ／ＩＰ，Ｈ兀Ｐ传输协议，客户端通过浏览器（Ｂｒｏｗｓｅｒ）
访问Ｗｅｂ服务：Ｕ（ＷｅｂＳｅｒｖｅｒ）以及与ＷＥＢ相连的后台数据库（Ｄａｔａｂａｓｅ）。因此用户
工作界面是通过ＷＷＷ浏览器来实现，极少部分事务逻辑在前端（Ｂｒｏｗｓｅｒ）实现，
但是主要事务逻辑在服务器端（Ｓｅｒｖｅｒ）实现，形成所谓三层结构。Ｂ／Ｓ模式是当前世
界最先进的网络体系结构，代表了应用软件技术发展的必然趋势。
前端开发环境采用Ｖｉｓｕａｌ Ｓｔｕｄｉｏ．ＮＥＴ ２００３。Ｖｉｓｕａｌ Ｓｔｕｄｉｏ．ＮＥＴ是一个集成开发
平台，支持多种程序的开发语言。它不仅为用户提供标准的Ｗｅｂ程序开发控件（也
是组件），同时支持用户自创新控件及复合控件，而且还支持第三方控件。利用Ｖｉｓｕａｌ
Ｓｔｕｄｉｏ．ＮＥＴ开发的程序具有较强的移植性、安全性、高代码复用性，还可以为系统
开发提供完整的解决方案。数据库采用Ｓｑｌ Ｓｅｒｖｅｒ ２０００。以下是系统的部分界面，

主要以设备查询为例进行说明。

５１
童璺盔堂堡±堂堡丝苎

图５．２查诩设备信息界面

田５．３具体设备的信息界面
 第芤章构件实现

在获得使用权限后，操作人员可以先点击设备类别浏览和设备编号浏览获得具
体设备的编号，然后输入编号，提交给后台，得到需要查询的具体设备的详细信息。
图５．２是输入编号的界面。图５．３显示了具体设备的属性信息，对于授权的设备管
理员，在应用系统需要时，可以点击添加属性和修改属性来进行设备属性信息的添
加和修改。

圈５．４设备类别管理界面

设备管理员有权限对设备类别管理，对类别进行分类，编制设备类别分类表，・
增加、修改设备类别的属性值。如图５．４所示，通过运行管理系统中的设备类别管
理模块，对指定设备类别增加属性名称、值、及值类型．
 青岛大学硕士学位论文

图５．５修改设备信息界面

图５．５显示了修改设备基本信息时的界面。与查询不同，在此模块中，设备属
性的值对授权设备管理员是允许修改的。在确认需要改变设备信息后，系统提交给
后台程序将数据库中的原值替换，完成修改信息。
 第六章总结与展望

第六章总结与展望

基于构件的软件复用是目前软件研究中的一个重要课题，目前利用这种方法进
行ＭＥＳ领域的研究尚处于起步阶段。本文的主要工作是以ＵＭＬ的ＭＥＳ的构件抽
取方法为依据，以面向构件的方法对ＭＥＳ领域中的软件开发方法进行研究，并以

设备管理为例对构件的需求、分析、设计及实现的过程进行了详细描述，对业务构
件的规约和接口进行了详细设计。对￥９５中提出的对象模型进行了研究并从改进了
功能模型。本文的研究为ＭＥＳ领域软件构件化的开发方法提供了良好的参照，对
其他ＭＥＳ软件的开发具有一定的借鉴意义。
下一步有待进行的研究工作主要有：
ｌ、为进一步实现大粒度业务构件的复用，需要对领域工程进行深入的研究。
２、针对ＭＥＳ领域的其他功能，设计开发更多实用的可复用业务构件。
３、基于构件的开发和测试方法，与单纯的面向对象开发方法有所不同。在具
体开发过程中，还有很多值得研究的地方。
 青岛大学硕士学位论文

参考文献

［１］ＭＥＳＡ Ｉｎｔｅｒｎａｔｉｏｎａｌ．ＭＥＳ－ｅｘｐｌａｉｎｅｄ：Ａ ｈｉｇｈ ｌｅｖｅｌ ｖｉｓｉｏｎ［Ｒ］．ＭＥＳＡ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｗｈｉｔｅ

Ｐａｐｅｒ ６，１９９７．

［２］ＭＥＳＡ Ｉｎｔｅｒｎａｔｉｏｎａｌ．Ｔｈｅ Ｂｅｎｅｆｉｔｓ ｏｆ ＭＥＳ：Ａ Ｒｅｐｏｒｔ ｆｒｏｍ ｔｈｅ Ｆｉｅｌｄ ＥＲ］．ＭＥＳＡ

Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｗｈｉｔｅ Ｐａｐｅｒ １．１９９７．

［３］ＭＥＳＡ Ｉｎｔｅｒｎａｔｉｏｎａｌ．－匝Ｓ Ｆｕｎｃｔｉｏｎａｌｉｔｉｅｓ＆ＭＲＰ ｔｏ ＭＥＳ Ｄａｔａ Ｆｌｏｗ Ｐｏｓｓｉｂｉｌｉｔｉｅｓ［Ｒ］．

ＭＥＳＡ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｗｈｉｒｅ Ｐａｐｅｒ ２。１９９７．

［４】任守纲．基于构件的制造执行系统产品线关键技术研究［Ｄ］．南京：南京航空航天大学，２００５．

［５］赵刚，江平宇．网络化制造中资源优化配置的方法研究ＣＪ］．航空制造技术，２００３，（８）：６０－６４．

［６】齐勇，赵季中，侯迪．基于Ｗｅｂ的中间件系统集成框架［Ｊ］．计算机研究与发

展，２００１，３８（４）：４３０－４３７．

［７］Ｙｕ－Ｈｕｉ Ｔａｎ。Ｔｚｕｎｇ—Ｐｅｉ Ｈｏｎｇ，Ｓｈｅｎｇ－Ｉ Ｓｕｎ．Ａｎ ＸＭＬ ｉｍｐｌｅｍｅｎｔａｔｉｏｎ ｐｒｏｃｅｓｓ ｍｏｄｅｌ ｆｏｒ

ｅｎｔｅｒｐｒｉｓｅ ａｐｐｌｉｃａｔｉｏｎｓ［Ｊ］．Ｃｏｍｐｕｔｅｒｓ ｉｎ Ｉｎｄｕｓｔｒｙ。２００４，５５（２）：１８１—１９６．

［８】Ｏｂｊｅｃｔ Ｍａｎａｇｅｍｅｎｔ Ｇｒｏｕｐ．Ｍａｎｕｆａｃｔｕｒｉｎｇ Ｄｏｍａｉｎ Ｔａｓｋ Ｆｏｒｃｅ ＲＦＩ－３ Ｍａｎｕｆａｃｔｕｒｉｎｇ

Ｅｘｅｃｕｔｉｏｎｓ Ｓｙｓｔｅｍｓ［ＥＢ／ＯＬ］．ｈｔｔｐ：／／ｍ．∞ｇ．ｏｒｇ／ｄｏｃｓ／ｍｆｇ／９７一ｌｌ－０１．
【９］ＭＳＴＣ／ＪＯＰ，Ｓｐｅｃｉｆｉｃａｔｉｏｎｓ ｏｆ ｔｈｅ ｏｐｅｎｈ眍ｓ Ｆｒａｍｅｗｏｒｋ Ｖｅｒｓｉｏｎｌ．０（Ｄｒａｆｔ

ａｌｐｈａ２）（Ｓ］．２０００．

［１０］Ｊ．Ｓｉｅｂｅｒｇ，Ｒ．Ｗａｌｔｅｒ．＾ｓｃｈｅｄｕｌｉｎｇ ａｎｄ ｒｅｓｏｕｒｃｅ ｏｐｔｉｍｉｓｉｎｇ ＭＥｓ ｆｏｒ ｔｈｅ

ｓｅｍｉｃｏｎｄｕｃｔｏｒ ａｎｄ螂ｉｎｄｕｓｔｒｙ．＾ｄｖａｎｃｅｄ Ｓｅｍｉｃｏｎｄｕｃｔｏｒ Ｍａｎｕｆａｃｔｕｒｉｎｇ Ｃｏｎｆｅｒｅｎｃｅ

ａｎｄ Ｗｏｒｋｓｈｏｐ，２００３，３１（４）：１０１—１０５．

［１１］Ｂｙｏｕｎｇ Ｃｈｏｉ。Ｂｙｕｎｇ Ｋｉｍ．ＭＥＳ（ｍａｎｕｆａｃｔｕｒｉｎｇ ｅｘｅｃｕｔｉｏｎ ｓｙｓｔｅｍ）ａｒｃｈｉｔｅｃｔｕｒｅ ｆｏｒ ＦＭＳ

ｃｏｍｐａｔｉｂｌｅ ｔｏ ＥＲＰ（ｅｎｔｅｒｐｒｉｓｅ ｐｌａｎｎｉｎｇ ｓｙｓｔｅｍ）【Ｊ］．Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｊｏｕｒｎａｌ ｏｆ

Ｃｏｍｐｕｔｅｒ Ｉｎｔｅｇｒａｔｅｄ Ｍａｎｕｆａｃｔｕｒｉｎｇ，２００２，１５（３）：２７４—２８４．

［１２］也Ｄ．Ｒｉｃｈａｒｄｓ，ｆＬ－Ｌ Ｉ）ｕｄｅｎｈｕａｓｅｎ，Ｃ Ｍａｋａｔｓｏｒｉｓ，ｅｔｃ．Ｆｌｏｗ ｏｆ ｏｒｄｅｒｓ ｔｈｒｏｕｇｈ ａ

ｖｉｒｔｕａｌ ｅｎｔｅｒｐｒｉｓｅ ｔｈｅｉｒ ｐｒｏａｃｔｉｖｅ ｐｌａｎｎｉｎｇ ａｎｄ ｓｃｈｅｄｕｌｉｎｇ，ａｎｄ ｒｅａｃｔｉｖｅ

ｃｏｎｔｒｏｌ［Ｊ］．Ｃｏｍｐｕｔｅｒ＆Ｃｏｎｔｒｏｌ Ｅｎｇｉｎｅｅｒｉｎｇ Ｊｏｕｒｎａｌ，１９９７，（８）：１７３—１７９．

［１３］Ｓｈｅｎｇ－Ｌｕｅｎ Ｃｈｕｎｇ，ＭｕＤｅｒ Ｊｅｎｇ．Ｍａｎｕｆａｃｔｕｒｉｎｇ ｅｘｅｃｕｔｉｏｎ ｓｙｓｔｅｍ哪酷）ｆｏｒ

ｓｅｍｉｃｏｎｄｕｃｔｏｒ ｍａｎｕｆａｃｔｕｒｉｎｇ［Ａ］． Ｍａｎ ａｎｄ Ｃｙｂｅｒｎｅｔｉｃｓ［Ｃ］．ＩＥＥＥ Ｉｎｔｅｒｎａｔｉｏｎａｌ

Ｃｏｎｆｅｒｅｎｃｅ。２００２。４（６－９）：５．

［１４】Ｊ．Ｂｅｒｒｙ，Ｍ．Ａｐａｒｉｃｉｏ，Ｔ．Ｄｕｒｎｉａｋ，ｅｔｃ．ＮＩＩＩＰ—ＳＭＡＲＴ：ａｎ ｉｎｖｅｓｔｉｇａｔｉｏｎ ｏｆ

ｄｉｓｔｒｉｂｕｔｅｄ ｏｂｊｅｃｔ ａｐｐｒｏａｃｈｅｓ ｔｏ ｓｕｐｐｏｒｔ ＭＥＳ ｄｅｖｅｌｏｐｍｅｎｔ ａｎｄ ｄｅｐｌｏｙｍｅｎｔ ｉｎ ａ

ｖｉｒｔｕａｌ ｅｎｔｅｒｐｒｉｓｅ［Ａ］．Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ２ｎｄ ｉｎｔｅｒｎａｔｉｏｎａｌ ｅｎｔｅｒｐｒｉｓｅ ｄｉｓｔｒｉｂｕｔｅｄ

ｏｂｊｅｃｔ ｃｏｍｐｕｔｉｎｇ ｗｏｒｋｓｈｏｐ［ｅ１．１９９８：３６６—３７７．

５６
 参考文献

［１５３兄ＱＩＵ，ＩＬ ＩＱ＇ＳＫ，Ｑ ＸＵ．Ｅｘｔｅｎｄｅｄ ｓｔｒｕｃｔｕｒｅｄ ａｄａｐｔｉｖｅ ｓｕｐｅｒｖｉｓｏｒｙ ｃｏｎｔｒｏｌ ｍｏｄｅｌ

ｏｆ ｓｈｏｐ ｆｌｏｏｒ ｃｏｎｔｒｏｌｓ ｆｏｒ ａｎ ｅ－Ｍａｎｕｆａｃｔｕｒｉｎｇ ｓｙｓｔｅｍ［Ｊ］．Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｊｏｕｒｎａｌ ｏｆ

Ｐｒｏｄｕｃｔｉｏｎ Ｒｅｓｅａｒｃｈ。２００３，４１＜８）：１６０５—１６２０．

（１６］Ｍ．Ｈｏｒｉ，Ｔ．Ｋａｗａｍｕｒａ．Ａ．Ｏｋａｎｏ．ＯｐｅｎＭＥＳ：Ｓｃａｌａｂｌｅ Ｍａｎｕｆａｃｔｕｒｉｎｇ Ｅｘｅｃｕｔｉｏｎ

Ｆｒａｍｅｗｏｒｋ Ｂａｓｅｄ Ｄｉｓｔｒｉｂｕｔｅｄ Ｏｂｊｅｃｔ Ｃｏｍｐｕｔｉｎｇ［Ａ］．Ｈａｎ ａｎｄ Ｃｙｂｅｒｎｅｔｉｃｓ［Ｃ］．ＩＥＥＥ

Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｎｆｅｒｅｎｃｅ，１９９９（６）：３９８－４０３．

［１７］Ｃｈｉｎ－Ｙｉｎ Ｈｕａｎｇ．Ｄｉｓｔｒｉｂｕｔｅｄ ｍａｎｕｆａｃｔｕｒｉｎｇ ｅｘｅｃｕｔｉｏｎ ｓｙｓｔｅｍ：ａ ｗｏｒｋｆｌｏｗ

ｐｅｒｓｐｅｃｔｉｖｅ［Ｊ］．Ｊｏｕｒｎａｌ ｏｆ Ｉｎｔｅｌｌｉｇｅｎｔ Ｓｙｓｔｅｍ，２００２。１３（６）：４８５—４９７．

［１８】Ｆａｎ－Ｔｉｅｎ Ｃｈｅｎｇ，Ｅｒｉｃ Ｓｈｅｎ，Ｊｕｎ－Ｙａｎ Ｄｅｎｇ，ｅｔｃ．Ｄｅｖｅｌｏｐｍｅｎｔ ｏｆ ａ ｓｙｓｔｅｍ ｆｒａｍｅｗｏｒｋ

ｆｏｒ ｔｈｅ ｃｏｍｐｕｔｅｒ－ｉｎｔｅｇｒａｔｅｄ ｍａｎｕｆａｃｔｕｒｉｎｇ ｅｘｅｃｕｔｉｏｎ ｓｙｓｔｅｍ：Ａ ｄｉｓｔｒｉｂｕｔｅｄ

ｏｂｊｅｃｔ—ｏｒｉｅｎｔｅｄ ａｐｐｒｏａｃｈ［Ｊ］．Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｊｏｕｒｎａｌ ｏｆ Ｃｏｍｐｕｔｅｒ Ｉｎｔｅｇｒａｔｅｄ

Ｍａｎｕｆａｃｔｕｒｉｎｇ．１９９９，１２（５）：３８４－４０２．

［１９］Ｆａｎ—Ｔｉｅｎ Ｃｈｅｎｇ，Ｓｈａｎｇ－Ｌｕｎ Ｗｕ，Ｃｈｉｈ—Ｆｅｎｇ Ｃｈａｎｇ．Ｓｙｓｔｅｍａｔｉｃ ａｐｐｒｏａｃｈ ｆｏｒ ｄｅｖｅｌｏｐｉｎｇ

ｈｏｌｏｎｉｃ ｍａｎｕｆａｃｔｕｒｉｎｇ ｅｘｅｃｕｔｉｏｎ ｓｙｓｔｅｍ［Ａ］．Ｔｈｅ ２７ｔｈ Ａｎｎｕａｌ Ｃｏｎｆｅｒｅｎｃｅ Ｏｆ ｔｈｅ ＩＥＥＥ

Ｉｎｄｕｓｔｒｉａｌ Ｅｌｅｃｔｒｏｎｉｃｓ Ｓｏｃｉｅｔｙ［Ｃ】．２００１，ｌ（１）：２６１－２６６．

［２０］加三ｓＡ Ｉｎｔｅｒｎａｔｉｏｎａｌ． Ｃｏｎｔｒｏｌｓ Ｄｅｆｉｎｉｔｉｏｎ ＆ ＭＥＳ ｔｏ Ｃｏｎｔｒｏｌｓ Ｄａｔａ Ｐｌｏｗ

Ｐｏｓｓｉｂｉｌｉｔｉｅｓ［Ｒ３．ＭＥＳＡ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｗｈｉｔｅ Ｐａｐｅｒ ３，１９９５．

［２１３曹江辉．面向敏捷制造的制造执行系统关键技术研究［Ｄ】．南京：南京航空航天大

学。２００２．

［２２３于海滨，朱云龙．可集成的制造执行系统［Ｊ３．计算机集成制造系统，２０００，６（６）：卜６．
［２３］蔡宗琰，常志庆，王宁生，等．基于构件的可重构制造执行系统研究［Ｊ３．计算机应用研究，
２００４，２１（１２）：６８—６９，７２．
【２４］刘晓旅，蒙秋男，黄学文，等．基予软构件的柔性制造执行系统平台的研究［Ｊ］．计算机集成

制造系统，２００３．９（２）：１０１－１０６．

【２５】扬建军．以制造过程为管理核心的ＭＥＳ系统．先进制造模式下的制造执行系统

（８６３－５１１－９４３－００３）课题中期研究报告［Ｒ］．北京：北京航空航天大学制造系统研究所。２０００．

［２６】饶运清。刘世平。李淑霞，等．敏捷化车间制造执行系统研究［Ｊ］．中国机械工

程，２００２，１３（８）：６５４－６５６．

［２７］陈杰，孙宇，张世琪，等．面向过程的制造执行系统的研究［Ｊ３．高技术通讯，１９９９，（１２）：

３７—４０．

［２８］孙字，陈杰，蒋晓春，等．略论制造执行系统研究［Ｊ］．高技术通讯，１９９９，９（ｔＯ）：６０－６２．

［２９３ Ｃｏｒｍａ ｇｃＣｌｕｒｅ．软件复用标准指南［Ｍ］．王亚沙等译．北京：电子工业出版社。２００４．

【３０］ＮＡＴＯ．８ＡＴＯ ｓｔａｎｄａｒｄ ｆｏｒ ｄｅｖｅｌｏｐｉｎｇ ｒｅｕｓａｂｌｅ ｓｏｆｔｗａｒｅ ｃｏｍｐｏｎｅｎｔｓ．Ｙ０１．１ ｏｆ ３ ｖｏｌｕｍｅｓ，

ＮＡＴＯ ｃｏｎｔａｃｔ ｎｕｍｂｅｒ Ｃ０－５９５１一＾Ｄ礼１９９１．

 青岛大学硕士学位论文

［３１］ＮＡＴＯ．ＮＡＴＯ ｓｔａｎｄａｒｄ ｆｏｒ ｍａｎａｇｅｍｅｎｔ ｏｆ ａ ｒｅｕｓａｂｌｅ ｓｏｆｔｗａｒｅ ｃｏｍｐｏｎｅｎｔ ｌｉｂｒａｒｙ．Ｖ０１．２

ｏｆ ３ ｖｏｌｕｍｅｓ，Ｎ＾Ｔ０ ｃｏｎｔａｃｔ ｎｕｍｂｅｒ Ｃ０－５９５７一慨．１９９１．

［３２］ＮＡＴ（｝．ＮＡＴ（｝ｓｔａｎｄａｒｄ ｆｏｒ ｓｏｆｔｗａｒｅ ｒｅｕｓｅ ｐｒｏｃｅｄｕｒｅｓ．Ｖ０１．３ ｏｆ ３ ｖｏｌｕｍｅｓ，ＮＡＴＯ ｃｏｎｔａｃｔ
ｎｕｍｂｅｒ Ｃ０－５９５７一ＡＤＡ．１９９１．

［３３】王千祥，刘畅．分布式对象技术与软件复用［Ｊ］．计算机科学，１９９９，２６（５）：６１—６４．

［３４］Ｌｉｓａ Ｂｒｏｗｎｓｗｏｒｄ，Ｐａｕｌ Ｃｌｅｍｅｎｔｓ．Ｔｅｃｈｎｉｃａｌ Ｒｅｐｏｒｔ．Ｃ删／ＳＥＩ—９６一ＴＲ－０１６，Ｏｃｔｏｂｅｒ １９９６．

［３５］Ｓｈｏｌａｍ Ｇ＇Ｃｏｂｅｎ ｅｔｃ．Ｔｅｃｈｎｉｃａｌ Ｒｅｐｏｒｔ，０ｌＵ／ＳＥＩ－９Ｉ—ＴＲ一２８。ＥＳＤ－９Ｉ一１１ｃ一２８．Ｊｕｎｅ １９９２．

［３６］Ｓｈｏｌｕｍ Ｃｏｂｅｎ ｅｔｃ．Ｔｅｃｈｎｉｃａｌ Ｒｅｐｏｒｔ。Ｃ蛐／ＳＥＩ一９６－ＴＲ－０１８，Ｓｅｐｔｅｍｂｅｒ １９９６。

【３７】沈延森，姜梅，丁秋林．支持业务构成重组和信息系统重构的企业建模日】．小型微型计算机
系统，２００２，２３（４）：５０５—５０８．
［３８］通信技术发展现状与前景．ｈｔｔｐ：／／州．ｅｄｎｃｈｉｎａ．ｃｏｍ／ｂｌｏｇ／ｅｒｉｃ—ｓｕｎ／，２００６－８一１０．
［３９］杨芙清，梅宏，李克勤．软件复用与软件构件技术［Ｊ］．电子学报，１９９９，２７（２）：５１，６８—７５．

［４０】Ｃ．Ｓｚｙｐｅｒｓｋｉ．Ｃｏｍｐｏｎｅｎｔ Ｓｏｆｔｗａｒｅ—Ｂｅｙｏｎｄ Ｏｂｊｅｃｔ－Ｏｒｉｅｎｔｅｄ Ｐｒｏｇｒａｍｍｉｎｇ．Ａｄｄｉｓｏｎ

Ｗｅｓｌｅｙ Ｌｏｎｇｍａｎ．ｉｎｃ．，１９９８．

［４１］杨芙清．软件复用及其相关技术［Ｊ］，计算机科学，１９９９，２６（５）：１－４．
［４２］李延春，晏敏．软件构件技术的现状与未来［Ｊ）．计算机工程与应用，２００３，３９（３１）：８６—９３，９６
［４３］朱建江．基于软件构件的软件复用的研究［Ｄ］．南京：南京航空航天大学，２００１．
［４４】Ｊａｍｅｓ Ｒａｍｂａｕｇｈ．Ｉｖａｒ Ｊａｃｏｂｓｏｎ，Ｇｒａｄｙ Ｂｏｏｃｈ．ｕ虬参考手册（第二版）［Ｍ］．ＵＭＬ Ｃｈｉｎａ译．

北京：枫械工业出版社，２００５．
［４５］Ｇｒａｄｙ Ｂｏｏｃｈ。Ｊａｍｅｓ Ｒｕｍｂａｕｇｈ，Ｉｖａｒ Ｊａｃｏｂｓｏｎ．Ｔｈｅ Ｕｎｉｆｉｅｄ Ｍｏｄｅｌｉｎｇ Ｌａｎｇｕａｇｅ Ｕｓｅｒ

Ｇｕｉｄｅ［Ｍ］．Ａｄｄｉｓｏｎ－Ｗｅｓｌｅｙ Ｌｏｎｇｍａｎ，Ｉｎｃ，１９９８．

［４６］Ｒａｔｉｏｎａｌ Ｓｏｆｔｗａｒｅ Ｃｏｒｐｏｒａｔｉｏｎ．Ｕｎｉｆｉｅｄ Ｍｏｄｅｌｉｎｇ Ｌａｎｇｕａｇｅ ｖｅｒｓｉｏｎ ２．Ｏ［朗／ｏＬ］．

ｈｔｔｐ：／／，ｍｒ－１２Ｓ．ｉｂｍ．ｃｏｍ／ｄｅｖｅｌｏｐｅｒｗｏｒｋｓ／ｒａｔｉｏｎａｌ／ｌｉｂｒａｒｙ／ＯＳ／３２１＿ｕｍｌ／，２００５—１１．
Ｅ４７］吴建，郑潮，汪杰．ｕ札基础与Ｒ０ｓＥ建模案例［Ｍ］．北京：人民邮电出版杜，２００４．
［４８］Ｉｖａｒ Ｊａｃｏｂｓｏｍ Ｇｒａｄｙ Ｂｏｏｃｈ，Ｊａｍｅｓ Ｒｕｍｂａｕｇｈ．统一软件开发过程【ｌＩ］．周伯生，冯学民。攀

东平译．北京：机械工业出版社，２００２．
［４９］黄全周．软件过程与统一软件开发过程研究［Ｊ］．计算机工程与应用，２００４，４０（３１）：６６－６８．
［５０］Ｉｖａｒ Ｊａｃｏｂｓｏｎ．Ｏｂｊｅｃｔ－Ｏｒｉｅｎｔｅｄ Ｓｏｆｔｗａｒｅ Ｅｎｇｉｎｅｅｒｉｎｇ，Ａｎ ｕｓｅ ｃａｓｅ Ｄｒｉｖｅｎ

Ａｐｐｒｏａｃｈ［Ｍ］．Ｔｈｅ ＡｃＭ ｐｒｅｓｓ。＾Ｄｉｖｉｓｉｏｎ ｏｆ ｔｈｅ Ａｓｓｏｃｉａｔｉｏｎ ｆｏｒ Ｃｏｍｐｕｔｉｎｇ

Ｍａｃｈｉｎｅｒｙ，Ｉｎｃ，１９９２．

［５ｌ】柴永生，吴秀丽，孙树栋，等．设备管理信息系统及其关键技术研究［Ｊ】．计算机工程与应
用．２００４．４０（１２）：２１２—２１５．

［５２］石建玲，宋海生，李金良．基于Ｗｅｂ制造执行系统的设备管理系统研究［Ｊ］．现代制造工
程，２００３，（８）：１６—１９．

［ｓ３］黄柳青，王满红．构件中国一面向构件的方法与实践［Ｍ】．北京：清华大学出版杜，２００６．

５８
 参考文献

［５４］ｈｔｔｐ：／／ｍｍ－１２８．ｉｂｍ．ｃｏｍ／ｄｅｖｅｌｏｐｅｒｗｏｒｋｓ／ｃｎ／ｒａｔｉｏｎａｌ／

【５５］Ｈａｆｅｄｈ Ｍｉｌｉ，Ａｌｉ Ｍｉｌｉ Ｓｈｅｒｉｆ。Ｅｄｗａｒｄ Ａｄｄｙ．基于重用的软件工程［硅］．韩柯等译．北京：

电子工业出版社．２００４．

［５６］ＩＥＥＥ Ｒｅｃｏｍｍｅｎｄｅｄ Ｐｒａｃｔｉｃｅ ｆｏｒ Ａｒｃｈｉｔｅｃｔｕｒａｌ Ｄｅｓｃｒｉｐｔｉｏｎ，Ｄｒａｆｔ ３．０ ｏｆ ＩＥＥＥ Ｐ１４７１，

Ｍａｙ １９９８．

［５７］Ｅｎｔｅｒｐｒｉｓｅ－Ｃｏｎｔｒｏｌ Ｓｙｓｔｅｍ Ｉｎｔｅｇｒａｔｉｏｎ，Ｐａｒｔ ｌ：Ｍｏｄｅｌｓ ａｎｄ Ｔｅｒｍｉｎｏｌｏｇｙ．

ＡＮＳＩ／ＩＳＡ－９５．００．０１－２０００．

Ｃ５８］Ｅｎｔｅｒｐｒｉｓｅ－Ｃｏｎｔｒｏｌ Ｓｙｓｔｅｍ Ｉｎｔｅｇｒａｔｉｏｎ，Ｐａｒｔ ２：Ｏｂｊｅｃｔ Ｍｏｄｅｌ Ａｔｔｒｉｂｕｔｅｓ．

／ＩＮＳＩ／ＩＳ＾一９５．００．０２－２００１．

［５９３ Ｅｎｔｅｒｐｒｉｓｅ－Ｃｏｎｔｒｏｌ Ｓｙｓｔｅｍ Ｉｎｔｅｇｒａｔｉｏｎ，Ｐａｒｔ ３：Ａｃｔｉｖｉｔｙ Ｍｏｄｅｌｓ ｏｆ Ｍａｎｕｆａｃｔｕｒｉｎｇ

Ｏｐｅｒａｔｉｏｎｓ Ｍａｎａｇｅｍｅｎｔ．ＡＮＳＩ／ＩＳ＾一９５．ｏｏ．０３—２００５．

１ｅＯ］ｈｔｔｐ：／／ｗｗｗ．ｅｍｌ．ｏｒｇ．ｃｎ／ａｐｐＣａｓｅ／２００６１０２７２．ｈｔｍ

【６１］徐宝文，周毓明，卢红敏．Ｕ札与软件建模［Ｍ】．北京：清华大学出版社，２００６．
 青岛大学硕士学位论文

攻读学位期间的研究成果

［１］陈伟，于振伟，魏长江．基于ＧＰＲＳ的ＧＰＳ监控系统数据传输建模分析．山东理工
大学学报（自然科学版），２００６，（６）：５１—５４．

６０
 致谢

致谢

本文从选题、到课题的研究部是在导师魏长江教授全面、悉心的指导下完成的。
魏老师渊博的专业知识、严谨的治学态度、富有远见和启发性的建议和宝贵的经验
使我终生受益，并将激励学生在今后的学习、工作中锐意进取、不断前进。值此成
文之际，谨向导师表达我深深的敬意和衷心的感谢！
在课题的研究过程中，得到了多位同学的大力帮助，感谢隋韦韦，感谢谭薇，
还要感谢２００５级师弟胡阔见及实验室的其他同学在学习和生活中的帮助与支持。
感谢我的父母和家人对我的培养，对我的关怀、照顾与帮助。他们的理解和全
力的支持使我的论文得以顺利完成！
最后，在本文结束之际，向所有为我的论文提出宝贵意见的评阅老师们表示深
深地感谢和崇高的敬意．

作者：陈伟

二零零七年五月十二日

６１