信息服务模型基础结构中数据字典的设计与实现

缘分.exe

前言：
某共享系统涉及到多种异质、异构教育资源，研究其信息服务模型基础结构对于屏蔽资源差异，为用户提供统一服务具有重要的意义。数据字典是该信息服务模型基础结构中的重要组成部分，本文详细先容了该系统中数据字典基于J2EE平台的设计与开发，包括需求分析、总体设计、详细设计直到编码实现的全过程，整个系统采用UML进行分析和建模。
1 概述
1.1信息服务模式流程
信息服务模型基础结构在该共享系统中，位于底层数据库和上层各种应用（如统计分析、设备作业调度等等）之间，是整个共享系统的支撑层面。数据字典作为信息服务模型分系统的最底层，维护共享系统的数据组织模式（Data Schema），并直接与数据库进行交互。
在数据字典之上，分系统对资源信息数据进行封装，按照OGSA标准将各种资源封装成为以“服务”（Services）为基础的信息模型单元。这些“服务”统一以“接口”的形式为其上层的应用系统提供支撑。即该共享系统的所用应用通过调用信息服务模型分系统为其提供的接口与底层数据库完成交互，并获得共享资源提供的服务。
1.2. 数据字典在该信息服务模型中所处地位
l 通用数据元素字典，为不同的分系统开发者提供公共数据字典服务。
l 基于领域本体的资源属性字典，为全局信息服务模型及资源统一服务目录提供支撑。
2 共享系统中数据字典模块的设计与实现
2.1本模块任务与内容
该共享系统建立数据字典用来存储信息资源管理基础标准的全部内容，以支撑各个应用项目的开发，多个项目的互连，全系统的建设、运行、维护和数据信息的使用。
本共享系统建立数据字典主要基于三点：一为信息服务系统提供属性字典服务，而信息服务是本共享系统集成支撑平台的重要组成部分。二是对本系统数据库的一个完整的描述与总体的把握。三为所有模块开发者提供公用数据字典服务，促进数据共享，提高数据的使用效率。
本共享系统数据字典的用户可分为两类：一类为数据管理员，负责数据字典的创建与维护；另一类为上层应用，他们从数据字典中获取所需的数据与信息。
本模块两个任务：
2.1.1 数据字典体系结构的设计
数据字典体系结构的设计非常重要，关键要从系统的客观需要出发，分析各模块需要共享的公用数据和需要提供的接口，从而确定数据字典的类型。公用数据字典的设计必须参考国标来建立，属性字典的建立则需要研究专业领域的相关信息规范，结合本系统的实际情况来设计。信息模型字典体系主要包括五类字典：专家字典，通用数据字典，资源属性字典，表属性字典，索引信息字典。
2.1.2 基于数据字典的操作
基于信息模型数据字典的操作包括：创建字典，维护字典、浏览和查询、接口封装。
创建字典指设计字典的存储结构，即数据库表结构，然后录入数据。
维护字典指基于各类字典的增加、删除、修改操作。
数据字典创建好以后，还必须可以根据开发人员的要求进行一些操作，如增加一些特色属性，对自定义的属性的修改，或者删除不必要的属性或数据等等。因此大家的数据字典应该是动态的，可扩充的，在需求分析阶段建立，系统开发过程不断修改、充实、完善的。
对数据字典的维护往往是数据管理员应开发人员的要求来具体实施的，而数据字典一旦修改，数据管理员也应该及时将最新版本及时通知相关人员。
2.2 本模块的需求分析
2.2.1 第一阶段功能需求
由于本共享系统的开发历时比较长，数据字典体系结构也很丰富，所以从系统的客观需要出发，确定了第一阶段的功能需求，以后的开发中将继续完善整个字典体系结构的设计。

由于各个字典功能需求很相似，仅以专家字典为例先容具体的功能需求。本数据字典模块动态地维护一个专家库，包括以下功能：
u 增加专家：数据管理员可以增加专家。
u 删除专家：数据管理员可以删除专家。
u 修改角色：数据管理员可以对专家的信息进行修改。
u 浏览：数据管理员或上层应用可以浏览全部专家。
u 查询：数据管理员或上层应用可以根据专家所属专业或所属仪器设备类别进行单一或组合查询。
2.2.2 UML的USE CASE建模
USE CASE建模就是把上述的功能需求站在参与者的视角表达出来，通过应用用例建模来描述一个系统需要的准确的模型。
在UML中，USE CASE（用例）简单地显示了参与者和用例之间地静态关系，而不是动态关系。下面给出本应用程序在本阶段（功能需求分析）中的用例建模，将主要以USE CASE方式描述。

2.3 总体设计
2.3.1 数据库设计
一般说来，每一个属性Attribute不只对应于一个类别Class，且每一个类别会有多个属性，因此实体Class和Attribute是多对多的关系。每一个Expert必须是系统已经注册的一个用户，对应了唯一的一个用户号UserID,但每一个注册用户不一定是专家，因此实体User和Expert是继承的关系，而显然实体省和学校是一对多的关系。

2.3.2 用例描述
在本阶段，由于交互的对象是分析类，整个系统的职责也在分析类之间划分。同时，分析类也根据职责的不同分为边界类、控制类和实体类。
由于系统用例比较多，只选取其中最具代表性的一个用例维护属性字典来说明设计思路和实现方法。维护属性字典用例是由增加属性、修改属性信息、删除属性这三个用例来实现的，由于这三个用例的时序图很相似，只以修改属性信息来说明。
l 修改属性信息
用户从相应的类别中选择需要修改的属性，进行修改；系统提供给用户可选择属性和修改属性的界面，并完成该操作，即将修改结果写入数据库。可以很容易地反映出下面的操作序列：
u 用户从相应的类别中选择需要修改的属性
u 系统列出该属性的全部信息
u 用户输入修改信息
u 用户提交修改信息
u 完成修改，即将修改后的信息写入数据库。
在时序图中，系统被细化为若干的分析类，这些类就是在代码阶段构成真正的类的基础（包括JSP页面，JavaBean以及EJB组件）。基本上，这些类是按照功能的不同来划分的。
2.4 详细设计
截至到目前，从需求分析到概要设计，使用了UML语言对系统进行了建模。但是，还没有对J2EE组件（从JSP、JavaBean到EJB组件）进行详细的描述和设计。因此本阶段将：
l 对EJB组件进行详细设计，包括Session Bean和Entity Bean.
l 对前台组件进行详细设计，包括JSP页面、JavaBean的设计。
为此在设计的时候，并不像前面那样，纯粹从逻辑方面考虑，还参考了J2EE的架构特性，参考了一些成熟的设计模式，比如MVC结构。把UML和J2EE的特性最大限度的结合起来，是设计当中遇到的很大的难点。这里，将会分散在各个用例的建模中简单说明。
2.4.1 设计方案的理论依据以及方案讨论
MVC模型是由Xrox企业在80年代末期发表的一系列论文中首先提出来的。这种模型的基本原理是把应用程序的数据和商务逻辑，数据的外观呈现以及对数据的操作划分到不同的实体中去，这些实体成为模型、视图、控制器。使用这种模型可以使设计过程更加灵活，可以对商务规则和数据的物理表示进行修改而不触及任何用户界面的代码。
尽管这种方案最初是为了编写独立的GUI应用程序而开发出来的，然而它也可以很好的应用于J2EE的多层应用程序。用户将和控制器发生交互，告诉控制器他将要做哪些事情，控制器将以一种独立于客户端类型的方法把用户的请求转交给模型。
2.4.2 设计方案
EJB是一种服务器端组件体系结构，是一个基本的事务管理系统和一种与客户端类型无关的组件模型，它简化了用Java开发企业级的分布式组件应用程序的过程。通过EJB，大家能写出可扩展的、健壮的和安全的应用程序，而不用自己去写复杂的分布式组件框架。在一个多层结构的电子商务应用中，后台持久存储是由一个或多个数据库提供的。Web引擎使用HTML处理静态内容，使用Servlet和JSP处理动态表示逻辑，EJB提供Web层与数据库之间的业务逻辑。
EJB组件有两种类型，实体bean和会话Bean。在本应用程序中，选用了容器管理持久性（CMP）实体Bean，无状态会话Bean。用每个实体Bean来替换后面分析过的分析类中的实体类。会话bean主要用来处理商务逻辑，用它来替换控制类。把EJB纳入方案之后，MVC的角色就可以扩展到Web容器和EJB容器中的多个组件。在应用程序中，页面获得参数，并通过Javabean调用Session bean处理来自页面的请求。因此，Session bean是控制器，方案中，实体bean对应模型，JSP和Javabean对应视图。分析类中的Attri_Tbl和Class_Tbl分别转化为两个实体bean（Attri_Tbl和Class_Tbl），分别持有数据库相应表中某一相关元组的数据。设计中通常采用一个entity bean来映射一个数据库中的表。控制器由Session bean充当，负责对entity bean的调用。
3 结束语
数据字典作为信息服务模型基础结构的最底层，维护共享系统的数据组织模式（Data Schema），并直接与数据库进行交互。在数据字典之上，信息服务模型基础结构对资源信息数据进行封装，按照OGSA标准将各种资源封装成为以“服务”（Services）为基础的信息模型单元。这些“服务”统一以“接口”的形式为其上层的应用系统提供支撑，并获得共享资源提供的服务。