信息系统开发技术概述(1)

信息系统开发技术概述同济大学经济与管理学院徐德华博士Email:[e-mail]主要内容1.统一建模语言UML2．COM+组件技术3.CORBA4.EJB与J2EE5..NET平台1.统一建模语言UML1.1UML产生背景面向对象建模语言出现于70年代中期。从1989年到1994年，其数量从不到十种增加到了五十多种。90年代中，一批新方法出现了，其中最引人注目的是Booch1993、OOSE和OMT-2等。Booch是面向对象方法最早的倡导者之一，Booch1993比较适合于系统的设计和构造。Rumbaugh等人提出了面向对象的建模技术（OMT）方法，用对象模型、动态模型、功能模型和用例模型，共同完成对整个系统的建模，所定义的概念和符号可用于软件开发的分析、设计和实现的全过程，软件开发人员不必在开发过程的不同阶段进行概念和符号的转换。OMT-2特别适用于分析和描述以数据为中心的信息系统。Jacobson于1994年提出了OOSE方法，其最大特点是面向用例(Use-Case)，并在用例的描述中引入了外部角色的概念。OOSE比较适合支持商业工程和需求分析。统一建模语言（UnifiedModelingLanguage，UML）不仅统一了Booch、Rumbaugh和Jacobson的表示方法，而且对其作了进一步的发展，并最终统一为大众所接受的标准建模语言。“统一建模语言（UML）是一种用于软件系统制品规约的、可视化的构造及建档语言，也可用于业务建模以及其它非软件系统。”UML是一种通用的可视化建模语言，用于对软件进行描述、可视化处理、构造和建立软件系统的文档。UML适用于各种软件开发方法、软件生命周期的各个阶段、各种应用领域以及各种开发工具UML能够描述系统的静态结构和动态行为：静态结构定义了系统中重要对象的属性和操作以及这些对象之间的相互关系；动态行为定义了对象的时间特性和对象为完成目标任务而相互进行通信的机制。UML不是一种程序设计语言，但我们可以用代码生成器将UML模型转换为多种程序设计语言代码，或使用反向生成器工具将程序源代码转换为UML模型。1.2UML语言概述1.2.1UML语言的特征不是一种可视化的程序设计语言，而是一种可视化的建模语言；是一种建模语言规格说明，是面向对象分析与设计的一种标准表示；不是过程，也不是方法，但允许任何一种过程和方法使用它。1.2.2UML语言的目标易于使用，表达能力强，进行可视化建模；与具体的实现无关，可应用于任何语言平台和工具平台；与具体的过程无关，可应用于任何软件开发过程；简单并且可扩展，具有扩展和专有化机制；强调在软件开发中，对架构、框架、模式和组件的重用；与最好的软件工程实践经验集成；可升级，具有广阔的适用性和可用性；有利于面向对象工具的市场增长。1.2.3UML组成由视图view，图diagram，模型元素modelelement和通用机制generalmechanism等几个部分组成。视图是表达系统的某一方面特征的UML建模元素的子集，由多个图构成，是系统的抽象表示；图是模型元素集的图形表示；模型元素代表面向对象中的类、对象、消息和关系等概念，是构成图的最基本的常用概念。通用机制用于表示其它信息，比如注释、模型元素的语义等。。1.3UML语义UML语义描述基于UML的精确元模型（MetaModel）定义。元模型为UML的所有元素在语法和语义上提供了简单、一致、通用的定义性说明，使开发者能在语义上取得一致，消除了因人而异的最佳表达方法所造成的影响。此外UML还支持对元模型的扩展定义。1.4UML表示法UML表示法定义UML符号的表示法，为开发者或开发工具使用这些图形符号和文本语法为系统建模提供了标准。这些图形符号和文字所表达的是应用级的模型，在语义上它是UML元模型的实例。统一建模语言UML的重要内容可以由五类图（共9种图形）来定义。1.4.1用例图（UseCasediagram）用例视图是被称为参与者的外部用户所能观察到的系统功能的模型图。用例是外部可见的一个系统功能单元，这些功能由系统单元所提供，并通过一系列系统单元与一个或多个参与者之间交换的消息所表达。用例也可以有不同的层次。用例可以用其他更简单的用例进行说明。在交互视图中，用例作为交互图中的一次协作来实现。1.4.2静态图（Staticdiagram）静态图对应用领域中的概念以及与系统实现有关的内部概念建模，包括类图、对象图和包图。类图描述系统中类的静态结构。对象图是类图的实例，几乎使用与类图完全相同的标识。他们的不同点在于对象图显示类的多个对象实例，而不是实际的类。包图由包或类组成，表示包与包之间的关系。包是操作模型内容、存取控制和配置控制的基本单元。1.4.3行为图（Behaviordiagram）行为图包括状态图和活动图，描述系统的动态模型和组成对象间的交互关系。状态图描述类的对象所有可能的状态以及事件发生时状态的转移条件。状态图可用于描述用户接口、设备控制器和其他具有反馈的子系统。活动图描述满足用例要求所要进行的活动以及活动间的约束关系，有利于识别并行活动。活动图有助于理解系统高层活动的执行行为，而不涉及建立协作图所必须的消息传送细节。1.4.4交互图（Interactivediagram）交互图描述了执行系统功能的各个角色之间相互传递消息的顺序关系，包括顺序图和合作图。顺序图显示对象之间的动态合作关系，它强调对象之间传送消息的时间顺序，同时显示对象之间的交互关系。顺序图可以用来进行一个场景说明，即一个事务的历史过程。协作图描述对象间的协作关系，协作图跟顺序图相似，显示对象间的动态合作关系，但它们的侧重点不同。1.4.5实现图（Implementationdiagram）实现图包括构件图和配置图，显示系统实现时的一些特性，包括源代码的静态结构和运行时刻的实现结构。构件图描述代码部件的物理结构及各部件之间的依赖关系，有助于分析和理解部件之间的相互影响程度。配置图定义系统硬件的物理拓扑结构以及在此结构上执行的软件。它可以显示计算结点的拓扑结构和通信路径、结点上运行的软件构件、软件构件包含的逻辑单元(对象、类)等。1.5UML的应用领域UML的目标是以面向对象图的方式来描述任何类型的系统，具有很宽的应用领域。其中最常用的是建立软件系统的模型，但它同样可以用于描述非软件领域的系统，如机械系统、企业机构或业务过程，以及处理复杂数据的信息系统、具有实时要求的工业系统或工业过程等。总之，UML是一个通用的标准建模语言，可以对任何具有静态结构和动态行为的系统进行建模。此外，UML适用于系统开发过程中从需求规格描述到系统完成后测试的不同阶段。2．COM+组件技术所谓组件，其实就是一种可部署软件的代码包，其中包括某些可执行模块。组件单独开发并作为软件单元使用，它具有明确的接口，软件就是通过这些接口调用组件所能提供的服务，多种组件可以联合起来构成更大型的组件乃至直接建立整个系统。实现组件并不一定需要采用面向对象语言。支持组件的技术包括COM+、CORBA和EJB等。2.1COM的产生Microsoft出品了COM（ComponentObjectModel），COM仅仅只是一个规范。不管组件用什么语言写成，只要符合这个COM规范，就能被用任何一种语言写成的客户程序调用。Microsoft推出Windows98和Windows2000后，整个操作系统的核心都围绕着COM来建立。我们可以把Windows系统看作是一系列的COM接口，在需要是可以调用这些接口。COM服务程序有三种形式：第一种是驻留在本地机器上以DLL形式提供，该服务程序被调用时，嵌入到调用程序的线程中运行，是最常用的形式；第二种是驻留在本地机器上以EXE形式提供，该服务程序被调用时将占用独立的线程运行；第三种驻留在远端机器上以EXE形式提供，服务程序通过网络被调用，它在远端机器上运行，结果通过网络返回调用者。COM的缺点就是大家常常提到的“DLL地狱”。这个问题在一个DLL要被一个新版本的DLL所取代时引发。开发者不得不通过关闭所有的客户应用程序的方法来达到清除所用对这个组件的引用的目的。有时所有的方法都还起不了作用，那你只好重新启动服务器后才能替换掉老的DLL。2.2DCOM即DistributedCOM，与COM的不同点：COM有两种存在形式（DLL、EXE），但DCOM必须是可执行程序，因为DCOM不可能在客户程序的内存空间运行，所以不能是动态连接库。COM（DLL形式）可以不用RPC通信，而DCOM必须使用RPC远程调用。COM（DLL形式）与客户共同存在于同一内存空间，调用速度快。COM（DLL形式）的安全性不高，客户程序可以造成服务COM发生错误，DCOM安全性高。COM程序配置简单，DCOM配置较复杂。2.3COM+的产生为了让企业级的应用程序能使用上COM，它必需要有以下的特定的能力。验证能力对象池（ObjectPooling）事务处理支持分布式架构为了使开发者不必去为他们的组件添加这些能力，微软公司出品了DCOM和MTS（MicrosoftTransactionServer，微软事务服务器）。MTS允许相关的作业单元被当作一个事务来对待，这意味着如果所有的作业单元被成功地完成，整个事务就被当作成功地完成，反之如果有一个单元未成功完成，整个事务将被重新轮回。在客户请求对象和释放对象后，MTS仍保存着这个对象，所以当另一个客户请求同一个组件的时候，MTS就将保存着的对象交给它。通过这种方式，MTS减少了在服务器源实例化的次数。MTS针对企业应用和Web应用的特点，在COM/DCOM的基础上又添加了许多功能和特性，包括事务特性、安全模型、管理和配置等，MTS使COM成为一个完整的组件体系结构。COM+并不是COM的新版本，我们可以把它理解为COM的新发展，COM+的底层结构仍然以COM为基础。可以认为COM+是COM、DCOM和MTS的集成。但更重要的一点是，COM+倡导了一种新的概念，它把COM组件软件提升到应用层而不再是底层的软件结构，它通过操作系统的各种支持，使组件对象模型建立在应用层上，把所有组件的底层细节留给操作系统，因此，COM+与操作系统的结合更加紧密。2.4COM+基本结构COM+不再局限于COM的组件技术，它更加注重于分布式网络应用的设计和实现，已经成为Microsoft系统平台策略和软件发展策略的一部分。2.4.1WindowsDNA策略WindowsDNA（DistributedinterNetApplicationArchitecture）是Microsoft多年积累下来的技术精华集合起来而形成一个完整的、多层结构的企业应用总体方案，它使Windows真正成为企业应用平台。(a)三层结构技术组成模型(b)WindowsDNA结构2.4.2COM+基本结构从COM的发展角度来看，COM最初作为桌面操作系统平台上的组件技术，主要为OLE服务。但是随着WindowsNT与DCOM的发布，COM通过底层的远程支持使组件技术延伸到了分布式应用领域，充分体现了COM的扩展能力以及组件结构模型的优势。MTS为COM增添了许多新的内容，弥补了COM和DCOM的一些不足，它注重于服务器一端的组件管理和配置环境。COM+进一步把COM、DCOM和MTS统一起来，形成真正适合于企业应用的组件技术。COM+组成结构图COM+不仅继承了COM、DCOM和MTS的许多特性，同时也新增了一些服务，比如负载平衡、内存数据库、事件模型、队列服务等。COM和MTS把组件的所有配置信息都保存在Windows的系统注册表中，然而，COM+把大多数的组件信息保存在一个新的数据库中，称为COM+目录(COM+Catalog)。COM+目录把COM和MTS的注册模型统一起来，并提供了一个专门针对组件的管理环境。2.5COM+新增系统服务介绍COM+的系统服务充分体现了COM+的特征，通过这些系统服