档案信息系统面向对象建模分析
随着计算机技术的飞速发展，其应用领域也在不断扩大。人们在越来越多的领域希望把更多、更难的问题交给计算机去解决。这使得计算机软件的规模和复杂性与日俱增，从而使软件技术不断地受到新的挑战。
软件系统的开发是一项工程，必须按工程学的方法组织软件的生产与管理，必须经过分析、设计、实现、测试、维护等一系列的软件生命周期阶段。这一认识促使了软件工程学的诞生。编程仍然是重要的，但是更具有决定意义的是系统建模。只有在分析和设计阶段建立了良好的系统模型，才有可能保证工程的正确实施。
软件工程的三个基石是：方法，工具与过程。本文采用统一开发过程（Rational Unified Process, RUP）方法，利用IBM公司的Rational Rose软件，并遵照UML2.0标准和Synergy过程模型对档案管理信息系统软件的开发过程进行面向对象建模分析。在介绍了面向对象方法及UML 表示法之后，以用例分析为基础，详细阐述了RUP 核心原则指导下的档案管理信息系统模型的建立过程。
RUP 的核心原则是：用例驱动、以构架为中心、迭代化的基于构件的开发过程。实践RUP 核心原则的前提是使用面向对象的方法与工具。面向对象的方法是一个体系，本文的侧重在于进行面向对象的分析与设计，并使用UML 语言在Rational Rose工具辅助下最终建立档案管理信息系统的设计模型。
关键词：面向对象；统一软件过程（RUP )；统一建模语言(UML)；档案管理信息系统
With the rapid development of computer technology, its applications are expanding. More and more people in the area that more and more difficult to resolve the issue to the computer. This makes computer software increasing size and complexity, so that software technologies are subject to the new challenges.
Software systems development is a project must be based on engineering methods of production and management software organization, must pass through analysis, design, realization, testing, maintenance, and a series of software life cycle stage. This awareness led to the birth of software engineering. Programming remains important, but more decisive was modeling system. Only in the analysis and design phase to establish a good system model, the project will make it possible to ensure correct implementation.
The three cornerstones of software engineering: methods, tools and processes. This article uses the Rational Unified Process methodology and IBM Corporation's Rational Rose software, and obeys the UML2.0 standard and the Synergy process model carries on the object-oriented modeling analysis to the records management information system software performance history. After the introduction of the object-oriented methods and UML said France, to use cases based on the analysis, detailed guidance of the core principles of the RUP archives management information system design modeling process.
The RUP core principles are: use cases driven, with the framework for the center, based on the computation of the components of the development process. RUP practice core principles are the use of object-oriented methods and tools. Object-oriented approach is a system， the focus here is the object-oriented analysis and design, and uses the UML language tool assistance finally to establish the records management information system in Rational under the Rose the design model.
Key words：Object-Oriented (OO)； Rational Unified Process (RUP)； Unified Modeling Language (UML)； Archives Management Information System
随着计算机技术的迅猛发展及信息化需求程度的日益加深, 管理信息系统的生产规模也日益增大,如何在合理的时间内,开发出高质量的软件是一个急需解决的问题。同时人们对软件的设计开发及维护管理也有了更高的要求,其中包括缩短软件开发周期,提高软件质量,保障软件的可持续发展等。这些难题都随着统一建模语言(UML) 的推出而逐渐得以解决。UML (Unified Modeling Language) 是一种标准的、用于面向对象和基于构件的软件系统建模语言,是一种用于对软件系统模型绘制可视化描述的工具。它的作用域不仅限于支持面向对象的分析与设计,还支持从需求分析开始的软件开发全过程,它有助于开发人员绘制出有利于交流的清晰的模型。基于UML 的这些特点,并将软件工程领域的新思想、新方法和新技术溶入其中,软件设计开发及维护的效率和质量将大大提高。
1946年，世界上第一台电子计算机在美国制成。20世纪50年代软件诞生。在计算机系统发展的初期，计算机通常只执行一个单一的、为特定目的所编写的程序，这使得早期计算机软件的通用性十分有限。从20世纪60年代中期到70年代中期，软件业进入了一个发展时期。这一时期的软件产品开始被广泛使用，但软件的开发方法仍然沿用早期的自由开发方式。随着软件的规模急剧膨胀，需求日趋复杂，软件维护的难度越来越大，开发成本以指数级的速度增长，失败的项目比比皆是，这就是“软件危机”。
“软件危机”的出现使得人们开始对软件开发的方法进行重新审视。1968年，北大西洋公约组织（North Atlantic Treaty Organization）的科技委员会召集了近50名杰出的程序员、计算机科学家，以及工业界人士在德国召开了一次讨论和制定摆脱“软件危机”为主题的国际学术会议，会上第一次提出了软件工程（Software Engineering）概念。从软件工程概念的提出至今已经近40年了，全世界有数百万的软件开发人员，软件在我们的生活中无处不在，但客观的说软件工程还处于摸索发展的阶段。
IEEE(Institute of Electrical and Electronics Engineers)计算机学会将“软件工程”定义为：“（1）应用系统化的、学科化的、定量的方法，来开发、运行和维护软件，即将工程应用到软件。（2）对（1）中各方法的研究”经典的软件工程思想将软件的生命周期分成五个阶段：需求分析阶段（Requirements Capture）、系统分析与设计阶段（System Analysis and Design）、系统实现阶段（Implementation）、测试阶段（Testing）和维护阶段（Maintenance）。
软件开发中包含了人和物的因素，存在着很大的不确定性。现代软件工程特别重视人与物的关系，即人和工具在不同层次上、不断循环发展的关系。基于面向对象的分析、设计方法的出现使得软件开发方法发生了翻天覆地的变化。随之而来的是面向对象建模语言（以UML为代表）、软件复用、基于组件的软件开发等新的方法和领域。
软件工程的三个核心要素是方法、工具和过程。只有这三个方面紧密配合才能设计出好的软件。相对于传统的线形的瀑布模型，统一软件过程是螺旋形的，是用例驱动的。首先获得并实现关键用例，由此建立系统的基本架构。再由此架构逐步实现其他用例，从而得到一个功能完善的系统。在统一软件工程中用例驱动、以架构为中心以及迭代的增量开发是同等重要的，缺一不可。
软件系统是为了服务于用户而出现的。因此，为了构造一个成功的系统，必须了解用户的需要是什么，并设法去满足这些需要。用例是用户与系统的交互的动作集合，能够向用户提供有价值的结果。它获取的是功能需求。所有的用例合在一起，构成用例模型，它描述了系统的全部功能，代替了传统的系统功能说明。然而，用例不仅是一种确定系统需求的工具，它还能驱动系统分析、设计、实现、测试的进行。即用例驱动整个的软件开发过程。基于用例模型，开发人员创建一系列的实现这些用例的分析、设计和实现模型，并审查每一个后续建立的模型与用例模型是否一致。测试人员测试系统以确定实现模型的构件正确实现了用例。因此，用例不仅启动了开发过程，而且使整个开发过程浑然一体。
用例驱动，表明开发过程是沿着一系列从用例得到的工作流（需求、分析、设计、实现、测试）前进的，用例被确定、分析、设计、实现，最后用例又成为测试的基础。在分析与设计期间，用例模型经由分析模型转化为设计模型。分析模型和设计模型都是由类和说明如何实现用例的用例实现集合组成的。分析模型是需求的详细的规格说明，将需求用例的事件流，用概念性的类之间的协作来重新转述，是一个概念模型。设计模型是实现的蓝图。
软件构架的作用与建筑物构架所起的作用类似。我们可以从结构、服务设施、供水、供电等各种不同的角度来审视一座建筑物。这使得施工人员在开始施工之前，就可以全面了解该建筑的全貌。与此类似，软件系统的构架也从不同的角度描述了即将构造的系统。
软件构架包含了系统中最重要的静态与动态特征。它受功能需求的影响，也受具体的构造环境与实施环境的影响。不但要支持实现功能的需求，也要支持实现非功能的需求。它刻画了系统的整体设计，去掉了细节部分，突出了系统的重要特征。每个产品都有功能与表现形式两个方面。功能与用例相对应，表现形式与构架相对应。用例在实现时必须适合于构架，构架又必须预留空间来实现新的用例。构架与用例，必须并行进化。
软件系统是个单一的实体，从不同的视角展示它有助于更好地理解系统的设计。系统的不同视角的展示就是视图，所有的视图合在一起展示了构架。软件的构架包括四个方面的内容：一是软件系统的组织；二是构成系统的结构元素及这些元素之间的接口，以及由元素间的协作所得到的各元素的行为；三是子系统，这些子系统由结构元素和行为元素组成；四是指导系统的组织的构架风格。构架可以表示为多种模型的视图：用例模型视图、分析模型视图、设计模型视图等。构架描述是所有系统模型的一个完整的系统的描述，只是它的内容比较少，只包含用来实现构架的重要用例中的设计元素。
迭代是一个细小的可管理的步骤。先是计划一小步，接着说明、设计、实现这一小步，最后集成、测试和运行这一小步。如果对这一小步感到满意，就进行下一步。在每步之间会得到反馈，以此来调整下一步的侧重点。然后开始另一步，接着再一步。当处理完计划中的所有步骤后，便开发出了可以发布的产品。
项目的早期迭代，侧重于增进对于需求、问题、风险和方案领域的了解。项目的后期迭代，侧重于产生产品的增量，以最终得到可对外发布的产品。开发一个商用软件可能会持续几个月或者一年以上，将整个大项目划分为几个袖珍项目是必须的。每个袖珍项目都是能够产生一个增量的迭代过程。迭代是指工作流中的步骤，增量是产品中增加的部分。应当按照计划好的步骤有选择地进行迭代，即受控地进行迭代。
面向对象实质是一种思维方法。软件工程学家Coad和Yourdon曾给出一个简单的定义：面向对象＝对象＋类＋继承＋通信。如果软件系统使用这四个概念设计并实现，则可认为这个软件系统是面向对象的。面向对象技术的基本观点可以概括为：（1）客观世界由对象组成。任何客观实体都是对象，复杂对象可由简单对象构成。（2）具有相同数据结构和操作的对象可以抽象为类，对象是类的实例。（3）类可以派生出子类，子类不仅可以继承父类的属性还可以有自己的特性。（4）对象之间的联系通过消息传递来维系。类的封装性使他具有外界不可见的数据，这些数据只能通过消息请求调用可见的方法访问。
面向对象方法的基本出发点就是尽可能地按照人类认识世界的方法和思维方式来分析和解决问题，使人们分析、设计一个系统的方法尽可能接近认识一个系统的方法。在20世纪80～90年代，面向对象的分析与设计（OOA&OOD）方法获得了长足的发展而且相关的研究也十分活跃，涌现了大量的方法学，据不完全统计，最多的时候高达50多种。其中最有代表性的当数Booch（Grady Booch）方法、OMT（Jim Rumbaugh）方法、OOSE（Ivar Jacobson）方法三种，而UML正是这三位大师联手共同打造而成的，现在已经成为了标准的建模语言。
模型是现实的简化．准确地讲，模型是能动的抽象认知的结果，包括认知活动的主体和认知活动的原则。主体决定了特定的视角，也就是简化复杂现实问题的动机．原则决定了特定的抽象层次，是指简化的水平。
对于同一个系统，基于不同的动机与水平，可以得出许多模型，有助于全方位，多角度地把握系统的本质．它既可以描述系统的静态结构，也可以描述系统的动态行为；既可以描述系统的宏观概貌，也可以描述系统的微观情境。模型是一组具有完整的语义的信息，有两个方面的内容：一是对现实的化简，表现为各种类型的图（diagram ）及其中的元素与关联；二是认知主体的视角和抽象层次，表现为不同类型的视图（view ）。
对于我们所面对的问题，模型是现实的简化。对于我们具体的解决方案，模型是简化的实现。建模的过程就是捕捉系统实质的过程。
软件开发中，建模的过程是不可缺少的，只是依据规模、详细程度与存在方式有所不同，这样才能做到有目的去做事，也才能降低风险和获得高回报。建立一个简单的系统，模型可有可无；建一个相对较复杂的系统，模型的必要性加大；建一个高度复杂的系统，则模型是不可缺少的。当我们所面临的问题的复杂度产生了大的飞跃之后，我们对付简单问题的处理方法，在新的环境中会失去原有的效果。
建模的意义随着系统复杂程序的增加而越发显著。开始，是借助模型更好地理解系统；到后来，则是反之，依赖于模型来理解系统。人脑对于复杂问题的理解能力是有限的，借助模型中的特定视角和抽象层次，我们可以有效地简化复杂问题。
UML的发展历史可分为五个不同的阶段：分离、统一、标准化、修订和产业化。
在分离期，即20世纪70年代中期到90年代中期，涌现了一批卓越的方法：Grady Booch的93方法（源于Booch，91），Jim Rumbaugh的对象建模技术2（OMT－2）方法（源于OMT－1）及Ivar Jacobson的面向对象软件工程方法（OOSE）。
在统一期，即20世纪90年代中期到1997年，三位方法学家结成盟友，致力于方法统一。1994年10月，Jim Rumbaugh通过Rational Software公司与Grady Booch联手共建统一方法。在1995年10月，发布了统一方法（Unified Method）的0.8版本。同年秋，Ivar Jacobson和他的Objectory公司加盟Rational Software公司。三位盟友于1996年6月发布了UML的0.9版本，同年10月发布0.91版本。同时恳请、接受和融入面向对象界的反馈意见。在1996年期间，各公司开始认识到UML的策略本质，OMG（Object Manage Group）的对象分析和设计任务组（Object Analysis and Design Task Force）颁布关于为支持面向对象分析和设计的工具建立标准的建议请求（Request for Proposal，RFP），旨在为面向对象的技术定义语义和原型标准。1997年1月，Rational Software公司组织UML合作者联盟，发布了UML的1.0版本，将其作为初始RFP响应提交给OMG。
标准化期始于1997年下半年，扩大的UML合作者联盟推出了一个更加透明的新版本－UML1.1版本，将其作为修订的RFP响应提交给OMG。1997年9月，订约通过成为正式标准。1997年11月17日，OMG采用该标准，将其列入OMG采用技术列表，并负责进一步发展UML。
UML1.1版本正式通过后，UML进入修订期。OMG设立修订任务组（RTF），广泛征求意见，对UML进行修改。先后推出1.2～1.x版本。又经过大型修订，建立了UML2.0版本。2.0重点强调可扩张性、语言体系结构、模型管理和行为语言语义，使UML的表示更友好，更精确。
在行业化期间，OMG通过国际标准化组织（International Organization for Standardization，ISO），推荐UML规范成为可公开获取规范（Publicly Available Specification，PAS）的国际标准。
图3_1
UML发展历程详细说明
3.4.2.1. 要素（things )
（1） 表述结构：用例（Usecase ) ，类（Class ) ，接口（Interface ）。
（2） 表述行为：交互（Interaction ) ，状态机( State Machine ）。
（3） 用于组织：包（package ）。
（4） 注解用：注释（notes ）。
3.4.2.2. 关系（Relationship )
（1） 关联关系（Association ) ：两个类的实例之间存在着连接。
（2） 依赖关系（Dependency ) ：依赖者使用被，依赖者。
（3） 泛化关系（Generalization ) ：特殊的是；一般的一种。
（4） 实现关系（Realization ) ：被实现者是要求的说明，实现者是解决方案。
3.4.2.3. 图（Diagrams )
1）静态图（Static Diagram ) :
（1） 用例图（Usecase Diagram ) ：展示用例，操作者，及其关系。
（2） 类图（Class Diagram ) ：展示类，接口，包，及其关系。
2）动态图（Active Diagram ) :
（1） 顺序图（Sequence Diagram ) ：按时序展示对象间的消息传递。
（2） 协作图（Collaboration Diagram ) ：展示对象间的组织结构。
（3） 状态图（StateChart Diagram )：对象所经历的状态，及对事件的响应。
（4） 活动图（Activity Diagram ) ：系统转移到另一个活动的可能路径和判断条件。
3.4.2.4. 语义扩展
UML对自身描述能力的三种扩展机制：构造型（Stereotype ) ，标注值（Tagged value ) ，约束（Constraint ）。语义扩展指的是基本要素的变形。
1）类的构造型（Stereotype )：<<Entity>>、<<Control>>、<<Boundary>>、<<Subsystem Proxy>>、 <<Role>>、<<Interface>>。
2）包的构造型：<<Subsystem>>、<<Layer>>。
3）用例的构造型：<<Usecase Realization>>、<<Mechanism>>。
建立模型可以帮助开发者更好的了解正在开发的系统，通过建模要实现下面的目标：
（1） 便于开发人员展现系统，逐步充实系统架构。
（2） 从需求到实例的成功转换。
（3） 适应实施环境的变化。
RUP是成功经验的集合，不是理论的推导，有非常强的实践性。我们建模的实践过程与RUP中“分析和设计”规程相容，是RUP在建模上的实例。
我们建模实践过程中的核心方法是RUP（Rational Unified Process）。RUP由四个主要部分组成：初始、细化、构造和交付。在初始阶段，要了解项目范围，并创建商业用例。在细化阶段，进行需求分析和风险分析，开发出基本的体系结构并且为构造阶段创建计划。在构造阶段，需要一系列的迭代，包括分析、设计、实现和测试等工作。在交付阶段，把已经开发出的项目完善成产品，包括Beta测试、性能调试和相关文档。
RUP中有9个核心工作流，分为6个核心过程工作流（Core Process Workflows）和3个支持工作流（Core Supporting Workflows）。
统一过程（UP）定义了下列六个核心过程工作流：
（1）业务模型工作流，通过业务模型获取相关知识以理解需要系统自动完成的业务。
（2）需求工作流，通过用例模型获取相关知识以理解自动完成业务的系统需求。
（3）分析设计工作流，通过分析/设计模型以分析需求，设计系统结构。
（4）实现工作流，基于实现模型实现系统。
（5）测试工作流，通过测试模型进行针对需求的系统测试。
（6）部署工作流，通过部署模型部署系统。
统一过程（UP）定义了下列三个支持工作流：
（1）配置变更管理工作流，用来管理系统和需求变更的配置。
（2）项目管理工作流，用来管理项目。
（3）环境配置工作流，用来配置项目的环境，包括所涉及到的过程和工具。
尽管6个核心过程工作流同传统的瀑布模型很相近，但在迭代阶段是完全不同的，这些工作流在生命周期中将不只一次的被访问。9个核心工作流在项目中将被轮流使用，但每一次迭代中都有不同的重点和强度。
图4_1
RUP的迭代开发流程
Rational Rose是由美国Rational公司开发的、面向对象的可视化建模工具。利用它可以建立用UML描述的软件系统模型。Rational Rose包括了统一建模语言（UML）、面向对象的软件工程（OOSE）及面向对象技术（OMT）。2002年，Rational公司被IBM公司收购，Rational成为IBM的第五大品牌。
4.2.2.1. Rational Rose的特点
Rational Rose在建模方面有以下特点：
（1） 保证模型和代码高度一致。Rose可以实现真正意义上的正向、逆向和双向工程。
（2） 支持多种语言包括：C＋＋、Visual C＋＋、Java、Smalltalk、Ada、Visual Basic和PowerBuilder，也能够为CORBA应用产生接口定义语言（IDL）和为数据库应用产生数据库描述语言（DDL）。
（3） 为团队开发提供强有力支持，提供采用SCM（软件配置管理）和不采用的两种团队开发模式。
（4） 支持模型的Internet发布。Rose的Internet Web Publisher能够创建一个基于Web的Rose模型的HTML版本。
（5） 生产使用简单且定制灵活的文档。Rose自身提供了直接产生模型文档的功能，但Rational文档生成工具SoDA提供的模型文档模板可方便的生成OOA和OOD的各种文档。
（6） 支持关系数据库的建模。Rose能为ANSI、SQL Server、Sybase、Watcom等支持标准DDL的数据库自动生成数据描述语言。
4.2.2.2. Rational Rose的运行环境
（1） 最低硬件配置环境：Pentium的PC兼容系统，600MHz PⅢ，512 RAM，400MB 磁盘空间。
（2） 版本要求：Windows NT 4.0、Service Pack 6a和SRP（Security Rollup Package）；Windows 2000 Professional；Windows XP Professional。
（3） 数据库环境：IBM DB2 Universal Database 5.X～7.X；IBM DB2 OS390 5.X&6.X；MS SQL Server 6.X/7.X和2000；Oracle 7.X～9.X；Sybase System 12。
（4） 显示要求：磁盘空间270MB，每增加一个模型，需增加1～3MB。
用例是面向目标的，它的作用相当于是一个系统要满足的交互容器。
活动者是系统外部的一个实体，它以某种方式参与用例的执行过程。活动者通过向系统输入或请求系统输入某些事情来触发系统的执行。
档案管理信息系统的活动者包括：档案管理员（Archivists），系统管理员（Admin），档案使用者（User），系统数据库（DB），共享打印机等。
我们只是对档案管理系统的核心部分建模，因此只选择了档案管理员（Archivists），系统管理员（Admin），档案使用者（User）三个活动者。
在模型中档案管理员（Archivists）和系统管理员（Admin）之间存在泛化关系。对于二者的关系我们可以用面向对象中父类与子类的概念做出更明确的解释，即系统管理员（Admin）是档案管理员（Archivists）的父类，而档案管理员（Archivists）则是系统管理员（Admin）的子类。这样系统管理员（Admin）将只是拥有管理用户的权限，而不能接触档案实体的管理，具体的工作只能由档案管理员（Archivists）来完成。
图5_1
活动者Admin和Archivists关系
表5_1
|
主语 |
动词 |
宾语 |
频率 |
到达方式 |
响应 |
|
Admin |
添加 |
User |
1/周 |
间歇性 |
系统添加用户 |
|
Admin |
删除 |
User |
1/周 |
间歇性 |
系统删除用户 |
|
Admin |
查询 |
User |
3/天 |
间歇性 |
生成相应用户信息列表 |
|
User |
查询 |
档案 |
5-10/天 |
间歇性 |
显示可公开档案信息列表 |
|
User |
借阅 |
档案 |
5-10/周 |
间歇性 |
档案管理员审核借阅申请 |
|
User |
归还 |
档案 |
5-10/周 |
间歇性 |
档案管理员接收档案 |
|
Archivists |
归还 |
档案 |
5-10/周 |
间歇性 |
修改档案文件状态 |
|
Archivists |
查询 |
档案 |
60/天 |
间歇性 |
显示档案信息列表 |
|
Archivists |
借阅 |
5-10/周 |
间歇性 |
审核用户的借阅申请 |
|
|
Archivists |
添加 |
卷宗 |
0－5/周 |
间歇性 |
系统新增卷宗 |
|
Archivists |
删除 |
卷宗 |
0－5/周 |
间歇性 |
系统删除卷宗 |
|
Archivists |
添加 |
文件 |
100/天 |
间歇性 |
相应卷宗添加文件 |
|
Archivists |
删除 |
文件 |
100/天 |
间歇性 |
相应卷宗删除文件 |
系统事件列表
依据表5_1 的活动者和活动者事件的分析，我们可以得到对应的系统用例模型。具体如图5_2 。
图5_2
系统用例模型
图5_3
系统初步体系结构模型
我们将系统中抽象出来的类分配在档案保管（Cartulary）、人员信息（People Information）和系统接口（Interface）三个包中进行管理。具体结构如图5_4 ：
图5_4
系统包结构
5.3.2.1. 档案保管（Cartulary）包
图5_5
Cartulary包类关系模型
5.3.2.2. 人员信息（People Information）包
图5_6
People information包类关系模型
5.3.2.3. 系统接口（Interface）包
图5_7
Interface包类关系模型
5.3.3.1. File类
图5_8
File类状态模型
5.3.3.2. Item类
图5_9
Item类状态模型
5.3.3.3. User类
图5_10
User类状态模型
这里将对档案管理员（Archivists），系统管理员（Admin），档案使用者（User）三个活动者所抽象形成的类的内部活动进行详细描述。
5.4.1.1. 档案管理员（Archivists）
5.4.1.1.1. 借阅活动
图5_11
Borrow活动模型
5.4.1.1.2. 案卷管理活动
图5_12
File活动模型
5.4.1.1.3. 文件管理活动
图5_13
Item活动模型
5.4.1.2. 系统管理员（Admin）
图5_14
Admin类活动模型
5.4.1.3. 档案使用者（User）
图5_15
User活动模型
5.4.2.1. 查询档案用例
5.4.2.1.1. 顺序图
图5_16
查询档案用例顺序模型
5.4.2.1.2. 协作图
图5_17
浙公网安备 33010602011771号