开题报告内容

最新推荐文章于 2022-10-24 11:25:49 发布

overmind

最新推荐文章于 2022-10-24 11:25:49 发布

阅读量3.6k

点赞数

分类专栏： my life 文章标签： uml 语言扩展出版 rtf 任务

本文链接：https://blog.csdn.net/overmind/article/details/65597

版权

my life 专栏收录该内容

25 篇文章 0 订阅

订阅专栏

北京理工大学研究生院

工程硕士学位论文（设计）开题报告

年级 03级

工程领域软件工程

姓名刘青

指导教师曹元大

企业指导教师

二○○四年七月七日

企业指导教师评阅意见：

签字：年月日

校指导教师评阅意见：

签字：年月日

工程硕士学位论文开题报告评审表

硕士生姓名			导师姓名		企业导师
学科、专业							第次开题
论文选题	题目名称
	性质（√）	基础理论研究（）；应用性研究（）
	类别（√）	企业项目（）；部（省）项目（）；国家项目（）；自拟项目（）。是否兵器类项目（）
评审组成员	姓名	职称		工作单位及职务		签字





评审意见	（含：选题意义；实验条件；技术方案可行性；研究计划合理性等）
成绩
评审组长签字：年月日

注：成绩以“合格”“不合格”记；评审组成员为高级职称人员。

Uml在

web application中的应用

UML的简介

UML : Unified Modeling Language(统一建模语言), 属于第三代面向对象开发的编制文档可开发的方法, 由Grady Booch, James Rumbaugh和Ivar Jacobson三位著名的方法学家提出, 已经成为业界标准. 需要注意的是, UML不是可视化的程序设计语言, 而是一种可视化的建模语言.其提出的目标是:
  1. 易用性. 可进行可视化建模.
  2. 无关性. UML与具体的实现无关, 与具体的过程无关, 可以用于任何语言任何开发过程
  3. 可扩展性. UML本身具有扩展机制.
  4. 复用性. UML强调在开发中对架构, 框架,模式和组件的重用

.UML架构
    UML由图和元模型组成, 其中, 图是语法, 而元模型是语义. UML语义定义在一个四层(也就是四个抽象级)建模概念框架中, 这四层分别是
  .元元模型(meta-meta model)层 : 组成UML最基本的元素"事务(Thing)", 代表要定义的所有事物
  .元模型(meta model)层 : 组成uml基本元素, 包括面向对象和面向组件的概念, 这一层的每个概念都是元元模型中"事物"概念的实例
  .模型(model)层 : 组成UML的模型, 这一层中的每个概念都是元模型中概念的一个实例, 这层的模型通常叫做类模型(class model)或类型模型(type model)
  .用户模型(user model)层 : 这层中的所有元素都是UML模型的例子, 这层的每个概念都是模型层的一个实例(通过分类), 也是元模型层的一个实例(通过版类化), 这层模型通常叫做对象模型(object model)或实例模型(instance model)

Uml的历史

　一个规范的标准化进程通常是一个冗长的过程。在UML 1.3的最终草案被批准之际，OMG UML修订任务组和OMG分析设计平台任务组联合主席Cris Kobryn于1999年10月在《COMMUNICATION OF THE ACM》上发表了本文，总结了UML的发展历程，并展望了其发展趋势。

　　在很短的时间内，UML已经成为软件工业中占支配地位的建模语言。目前它不仅是事实上的建模语言标准，也正在快速地成为法律上的标准。1997年，OMG采纳它作为标准建模语言。现在，OMG正在以ISO公共可用规范提交者的身份，申请将UML规范作为国际标准。

　　不过，一个规范的标准化进程通常是正式而漫长的，因为它要满足各种各样的技术规范和商业需求。从商业角度看，标准化的时间尺度通常与尽早使用最新技术的竞争需求是冲突的。从技术角度看，为了力求达成共识，则赞成这种"由委员会设计"的进程。

　　标准化之前的历史

　　早在1995年，Gray Booch和Janes Rumbaugh将他们的面向对象建模方法统一为Unified Method V0.8。一年之后Ivar Jacobson加入其中，共同将该方法统一为二义性较少的UML 0.9。同时，这三位杰出的方法学家被称为"三友(Three Amigos)"。

　　很快用户也认识到可对软件系统进行可视化、描述、构造和文档化的通用建模语言所带来的益处。他们充满激情地将这种语言的早期草案应用于不同的领域。受用户强烈需求的驱动，建模工具厂商也很快在它们的产品中加入了对UML的支持。

　　与此同时，UML成了实际上的工业标准。1996年，一个由建模专家组成的国际性队伍"UML伙伴组织"开始同"三友"一起工作，计划将UML提议作为OMG的标准建模语言。

　　1997年1月，伙伴组织向OMG提交了最初的提案UML 1.0。经过了九个月的紧张修订，于1997年9月提出了最终提案UML 1.1，这个提案在1997年11月被OMG正式采纳为对象建模标准。

　　有必要指出的是，由于比较仓促地通过了OMG的提交过程，尽管语言的基层结构和大部分上层结构是合理的，UML还是容忍了一些不尽如人意的负面因素：活动图的语义及表示法不完整；标准元素臃肿，其中有些元素是为了满足不同的、相互竞争的方法门派的需求而草率加入的，许多标准元素语义贫乏，而且命名和组织也不一致;结构混乱，所提交的规范并没有达到提交者预期的目标--用一种严格的元模型方法实现4层元模型结构，相反使用了一种实用但不精确的、松散的元模型方法，不利于UML同其他OMG规范的结合，比如与MOF（Meta Object Facility）的结合。

不过提交者们并没有因此推迟UML的标准化进程，而是在该语言的下一个修订版中解决了上述一些问题。

发展进程

OMG为修订标准而提供的基本机制是提案需求（RFP，Request for Proposals）和修订任务组（RTF，Revision Task Forces）。

其中RFP过程是OMG采纳新规范和改进已有规范的主要机制。任务组发布一个RFP，一个或多个提交团以规范草案作为初始提案响应该RFP，然后任务组对这些初始提案进行评估，并反馈给提交者，鼓励这些提交者与其竞争对手合作，从而形成最终提案。在任务组完成了对最终提案的评估后，就投票决定推荐众多提案中的哪一个。获得多数赞成票的提案就被送交组织委员会和主管该任务组的技术委员会去批准。

　　如果一个最终提案获得了所有的批准，它就成为被OMG采纳的技术。否则，任务组就有权重新发布一个修改过的RFP。

　　在一个规范被采纳后不久，将成立一个修订任务组，负责该规范的修订。1997年9月，OMG采纳UML 1.1规范之后不久，特许成立了第一个UML修订任务组，负责收集有关评论，并且提出修改建议。

　　该RTF提交的第一个主要产品是一个编辑版本UML 1.2，它改编了规范，使之与其他OMG规范更为一致。尽管这一版本纠正了印刷和语法错误，以及某些明显的逻辑上的不一致，但还是没有涉及对重要技术的改进。
该RTF的第二个主要的产品是其技术版本UML 1.3，它修正和改善了UML 1.1的遗留问题，并矫正了在此之后发现的许多小错误。该RTF一致推荐OMG批准其UML 1.3最终草案，并于1999年6月提交了一份最终报告。被推荐的规范随后被提交给组织委员会和平台技术委员会以获得批准。

　　演变的体系结构

　　UML是用元模型来描述的，元模型是4层元模型体系结构模式中的一层。此模式的其他层次分别是：元-元模型层、模型层和用户对象层。其中元模型层由元-元模型层导出，UML的元-元模型层在OMG MOF的元-元模型中定义，而UML元模型中的元类是MOF元-元类的实例。

　　元模型的体系结构模式已被证明可以用来定义复杂模型所要求的精确语义，这种复杂模型通常需要被可靠地保存、共享、操作以及在工具之间进行交换。它的特点如下：

　　● 它在每一层都递归地定义语义结构，从而使语义更精确、更正规。

　　● 它可用来定义重量级和轻量级扩展机制，如定义新的元类和构造型。

　　● 它在体系结构上将UML元模型与其他基于4层元模型体系结构的标准（比如MOF和用于模型交换的XMI Facility）统一起来。

　　在元模型层，UML元模型又被分解为三个逻辑子包：基础包、行为元素包和模型管理包。其中基础包由核心、扩展机制和数据类型三个子包构成，它是描述模型静态结构的语言底层结构，支持类图、对象图、构件图、部署图等结构图。行为元素包是描述模型动态行为的语言上层结构，支持不同的行为图，包括Use Case（用况）图、顺序图、协作图、状态图和活动图。模型管理包则定义了对模型元素进行分组和管理的语义，它描述了几种分组结构，包括包、模型和子系统。行为元素包和模型管理包都依赖于基础包。

　　UML 1.3的修订

　　UML 1.3是建模语言规范第一个成熟的发布。它纠正或调整了从UML 1.1中继承下来的遗留问题，并且修正了最终提交后的一年来所发现的大多数错误。从建模者的角度看，从UML 1.1到UML 1.3并没有很大变化，对语言的大部分改进是在底层对UML元模型语义的调整，只有很少量的变化是针对表示法的细枝末节的修改。底层结构上的变化对大多数用户来说是看不到的，但这使得UML在将来更容易实现和扩展。

　　● 解决UML 1.1的遗留问题

　　完善活动图的语义和表示法增加了状态的动态激发语义，定义了执行条件线程的语义和表示法，而且增加了对象流功能。为了做这些修订，还需要对活动图所依赖的状态机语义做以下修改:为同步并发的活动加入"同步状态"、精化信号的语义、为合并状态转换定义附加的伪状态。

　　清理关系的标准元素引入关系元类来组织各种类型的关系，并且把依赖构造型改造为依赖和流。此外，精练了泛化，不再需要以前的许多构造型（如继承、私有、子类、子类型等）。依赖和其他关系名称的一致性也有所改进。

　　体系结构的一致性通过加入物理元模型和XMI(XML metadata Interchange)DTD定义，提高了UML 1.3元模型的体系结构跟MOF和XMI Facility的一致性。从UML语义逻辑元模型导出的物理元模型包含了一些支持产生IDL和XMI DTD的修改（例如将关联类转化为类）。尽管这样做与严格的元模型方法相左，但它为未来UML的修订达到这一目标提供了桥梁。

　　● 其他变化

　　静态结构图放宽了限制，使类和接口之间可以关联，并且在类中可以声明信号。信号被定义为一个类元，可以操作。另外，还重新定义了模板和强类型的语义。

　　用况图用况之间的关系被重新定义为三种主要类型：泛化、包含和延伸。

　　交互图放宽了限制，使用户可以描述角色或实例。而且协作也可以泛化。

　　模型管理图改进了模型和子系统的语义和表示法，将它们从包中分离出来，并使之更容易使用。澄清了对包的访问和引入权限的区别。

　　尽管UML规范的核心是语法和语义定义，但它还包括模型交换、语言扩展以及约束等方面的定义。UML 1.3对这些相关规范都进行了错误纠正，并使之与核心语言的改进保持一致。

　　为UML 2.0确立路标

　　该RTF在最终报告中明确了因为超出其范围或时间不允许而不能做的各种改进。他们建议下一个RTF应特别注意扩展性和文档管理方面的问题。对目前的扩展机制，用户和工具开发商已经发现了一些重要问题，而涌入新UML外围的提案可能会加剧这些困难。在文档管理方面，物理元模型和XMI DTD规范的加入大幅度地增加了UML规范的长度，并使它变得笨拙难用（它现在已有800多页了）。下一次UML修订将会把物理建模规范拆分为单独的文档。

　　该RTF还进一步建议负责起草UML 2.0 RFP的工作组考虑以下问题：

　　体系结构使用严格的元模型方法定义一个与MOF元-元模型严格一致的物理元模型。给出改进的指导方针，以决定哪些部分应该定义在核心语言中，哪些部分应定义在UML的外围或标准模型库中。

　　扩展性提供同4层元模型体系结构一致的扩展机制。提高外围规范的严密程度，使其支持用户对语言定制能力不断增加的要求。

　　构件增强基于构件的软件开发的语义和表示法。

　　关系提供"精化"和"追踪"依赖关系的基本语义。在多个抽象层次上定义关联的语义。

　　状态图和活动图定义独立于状态图语义的活动图语义。在活动图和状态图中提供更随意的并发。详细说明状态机的泛化。

　　模型管理重新定义模型和子系统的表示法和语义，以增强对企业体系结构视图的支持。

　　总体机制定义一种模型版本管理的机制。详细说明图的互换机制。

　　体系结构的十字路口：是雕刻还是糊泥巴？

　　在UML 1.3最终报告中就体系结构问题强调指出：UML正在靠近OMG体系结构的十字路口。OMG希望通过对体系结构进行改进来完成技术上层结构规范（例如应用框架或商业构件），以补充用于进程间通信和分布式操作系统服务的CORBA底层结构。虽然CORBA IDL对描述分布式计算底层结构特别有效，它可以用来刻画与界面关联的操作，但却不能用来定义方法、用况、协作、状态机、工作流以及通常与实际商业构件相关的各种关系。

　　因为UML允许用户定义IDL所缺乏的语义，所以可以用UML来补充IDL。（用UML完全代替CORBA IDL对大多数OMG成员而言变化太剧烈。）然而在这种情况下，对那些想用关系和行为升级IDL结构化规范的人而言，UML将面临如下的挑战：

　　学习的曲折性 UML是一种通用的建模语言，允许全面的语义表达。但尽管其基本的语言部分很容易掌握，更深层次的内容却需要足够多的时间去学习。

　　语义臃肿作为一种通用的建模语言，UML的复杂性和庞大是不可避免的，但其中也包含了大量词义模糊、语义贫乏的标准元素。

　　轻量级的可扩展性 UML目前仅提供轻量级的扩展机制，如构造型、约束和标记。（相比之下元类是一种重量级的扩展机制。）这些机制将受到一些简单扩展的挑战，例如CORBA IDL接口的构造型，还将受到来自对扩展有更高需求的压力，诸如应用框架和分布式商业构件。

　　元模型癖好由于元模型现在被认为是管理复杂的分布式体系结构的强有力技术，许多建模者都渴望用这种新式的重磅大锤来解决本来用砸核桃的锤子（例如构造型）甚至钉大头针的锤子（例如标准模型库中的一个类）就足以解决的问题。

　　这些挑战要求OMG采用一种雕刻的方法（少即是多）而不是糊泥巴的方法来提炼和扩展UML的体系结构。尤其是OMG需要采取有效的三层结构来决定哪些语言扩展可以处理为对UML核心的修订，哪些可以处理为独立的外围，而哪些可以处理为标准模型库。如果这个三层结构运行正常的话，核心部分将保持或提高其完整性，同时允许自然的选择（借助OMG过程）来遴选最可行的外围和标准化的模型库。

Uml的现状与未来

　　UML是在多种面向对象建模方法的基础上发展起来的建模语言，主要用于软件密集型系统的建模。它的演化，可以按其性质划分为以下几个阶段：最初的阶段是专家的联合行动，由三位OO（面向对象）方法学家将他们各自的方法结合在一起，形成UML 0.9。第二阶段是公司的联合行动，由十几家公司组成的"UML伙伴组织"将各自的意见加入UML，形成UML 1.0和1.1，并作为向OMG申请成为建模语言规范的提案。第三阶段是在OMG控制下的修订与改进，OMG于1997年11月正式采纳UML 1.1作为建模语言规范，然后成立任务组进行不断的修订，并产生了UML 1.2、1.3和1.4版本，其中UML 1.3是较为重要的修订版。目前正处于UML的重大修订阶段，目标是推出UML 2.0，作为向ISO提交的标准提案。

　　在多种面向对象建模方法流派并存和相互竞争的局面中，UML树起了统一的旗帜，使不同厂商开发的系统模型能够基于共同的概念，使用相同的表示法，呈现彼此一致的模型风格。而且它从多种方法中吸收了大量有用（或者对一部分用户可能有用）的建模概念，使它的概念和表示法在规模上超过了以往任何一种方法，并且提供了允许用户对语言做进一步扩展的机制。

　　UML在语法和语义的定义方面也做了大量的工作。以往各种关于面向对象方法的著作通常是以比较简单的方式定义其建模概念，而以主要篇幅给出过程指导，论述如何运用这些概念来进行开发。UML则以一种建模语言的姿态出现，使用语言学中的一些技术来定义。尽管真正从语言学的角度看它还有许多缺陷，但它在这方面所做的努力却是以往的各种建模方法无法比拟的。

　　从UML的早期版本开始，便受到了计算机产业界的重视，OMG的采纳和大公司的支持把它推上了实际上的工业标准的地位，使它拥有越来越多的用户。它被广泛地用于应用领域和多种类型的系统建模，如管理信息系统、通信与控制系统、嵌入式实时系统、分布式系统、系统软件等。近几年还被运用于软件再工程、质量管理、过程管理、配置管理等方面。而且它的应用不仅仅限于计算机软件，还可用于非软件系统，例如硬件设计、业务处理流程、企业或事业单位的结构与行为建模。

　　不过UML在取得巨大成功的同时，也不断地受到批评。来自工业界的批评主要是，它过于庞大和复杂，用户很难全面、熟练地掌握它，大多数用户实际上只使用它一少部分的概念；它的许多概念含义不清，使用户感到困惑。来自学术界的批评则主要针对它在理论上的缺陷和错误，包括语言体系结构、语法、语义等方面的问题。

　　目前国内也有不少软件企业在学习并尝试使用UML。从总体上看，我国计算机界对UML的了解还相当初步，但是对它的崇拜程度却远远超过了西方发达国家。人们在学习和使用UML遇到和国外用户相同的疑难和困惑时，却不太敢怀疑UML有什么问题。所以国内几乎没有批评的声音，偶尔有一点，也会立即被捍卫的声音淹没，即使对UML一些最明显的缺点和错误也是如此。

　　相比之下，国际上对UML的讨论和评价则要客观得多。无论是Internet上的意见交流，或是每年一次的UML研讨会，还是学术期刊上发表的文章，都是既肯定其成绩，又指出其缺点和错误，并且以积极的态度提出建设性意见。在酝酿UML下一次的重大发布和筹划UML 2.0作为ISO标准提案的最近两年内，围绕UML的讨论更为活跃和热烈。

　　为了使我国计算机界对UML目前的状况有较为客观的了解，我们从大量的文献资料中选择了三篇最具权威性的文章，介绍给我国读者。从这组文章中，我们可以得到关于UML现状及未来发展的重要信息：

　　● UML已经取得重要成功，它已成为在软件工业中占支配地位的建模语言，并在许多领域的软件开发中得到应用。

　　● UML还存在许多问题，自它产生之日起就从未离开过批评：用户和教师抱怨它内容庞大、难学难教而且太过复杂;学者认为它缺少一个精练的核心和定义良好的外围，有些语义定义得不够精确而且带有二义性;建模实践者认为它缺少支持自己领域建模要求的机制;工具开发商则因为规范本身的不确定性而产生理解上的偏差，它们对UML的自行诠释有可能误导用户。

　　● UML的关键问题是过于庞大和复杂，以及在语言体系结构、语义等方面存在理论缺陷。产生这些问题的一个重要原因是，在形成规范的过程中不得不照顾多种方法流派的观点和多家公司的利益。

　　● 为了UML的下一次重大发布，UML 2.0修订的主持者正在广泛收集各方面的意见。各界都给予了很高的关注，提出的意见涉及UML的各个方面。其中一个关键问题是UML是否需要简化，以及如何使之更精练，最终大部分意见是提供一个精练的核心，而把不常用的内容放到定义良好的外围或扩展机制中。此外，UML 2.0还将对UML的底层结构、上层结构和对象约束语言（OCL）做重大改进。

　　原定UML 2.0在今年某个时间发布，但是在刚刚结束的本年度UML国际研讨会上，没有透露关于该版本最新进度的任何消息，看来它的面世要比预期的日程推后。

学位论文与我工作的联系

我目前的实习工作在国家电力商务网，主要负责web页面的生成。对于uml和web开发，自己有一些心得。UML、OO等，都是软件开发的先进武器。应用这些武器，可以使我们的程序条理更清楚，业务逻辑更加明确，程序更加模块化。使整个站点的健壮性更好，更加易于维护。

B/S是现在比较流行的结构，软件发展到今天，有个明显的趋势，那就是要逐渐告别单机版，要走向网络版。C/S模式中还是有一个，client端的存在，不可否认自己定义的客户端功能更加强大，但是client还是摆脱不了单机版的影子。随着internet的发展，html和浏览器大幅度的发展了起来，每一台机器上面都自然而然的安装了浏览器（browse），只要他想，随时都可以访问服务器，查看他所需要的内容。

随着网络的普及和深化，web不仅仅是一个只提供http服务的机器。各种各样的服务，如ftp、smtp等都一起发展壮大了起来。现在在http或其他协议的基础上，诞生了一种新的协议soap，他与wsdl等一起，建立了一个跨平台的、服务式的、基于远程调用的新型服务。

以后的web不是一个独立的web，而是一个基于网络上的你中有我，我中有你，相互关联、相互调用的web。一个彼此交融，信息实时、迅速交融的时代马上就要到来。

在软件开发过程中，前辈的一代代程序员积累了大量的文档和经验。其中体系结构，设计模式等等具体的方法在不同应用层次上给后来人提供了很好的应用。这里我们提到的uml,unified modeling language。在工程领域中是一种通用的规范，对于需求分析的建模有着特别重要的意义。

我现在开发的站点也是软件，我将主要研究uml在这方面应用时的特色。如对于web中特定的session、cookie，怎样使用uml把他们灵活的使用好。对于，javascript等前台的编程，以及后台数据库的编程，如何在uml中介定清楚。

在这一段时间里，我会在实践过程中，偏重于uml与建模，把学位论文完成好。