我选择,我喜欢! -- .Net学堂

UML是一种建模语言而不是方法,这是因为UML中没有过程的概念,而过程正是方法的一个重要组成部分。UML本身独立于过程,这意味着用户在使用UML进行建模时,可以选用任何适合的过程。过程的选用与软件开发过程的不同因素有关,诸如所开发软件的种类(如实时系统、信息系统和桌面产品)、开发组织的规模(如单人开发、小组开发和团队开发)等。用户将根据不同的需要选用不同的过程。然而,使用UML建模仍然有着大致统一的过程框架,该框架包含了UML建模过程中的共同要素,同时又为用户选用与其所开发的工程相适合的建模技术提供了很大的自由度。

1. UML建模过程高层视图

图2是UML建模过程的一个高层视图。这是一个迭代递增的开发过程。使用此方法,不是在项目结束时一次性提交软件,而是分块逐次开发和提交。构造阶段由多次迭代组成,每一次迭代都包含编码、测试和集成,所得产品应满足项目需求的某一子集,或提交给用户,或纯粹是内部提交。每次迭代都包含了软件生命周期的所有阶段。同时,每次迭代都要增加一些新的功能,解决一些新的问题。

因此,首先要做的工作是:选择一些功能点,然后完成这些功能;之后再选择别的功能点,如此循环往复。前两个阶段是初始( Inception)和细化 ( Elaboration) 阶段。在初始阶段,需要考虑项目的效益,并确定项目的范围。这一阶段需要与项目出资方进行讨论。在细化阶段,需要收集更为详细的需求,进行高层分析和设计,并为构造阶段制定计划。运用这种迭代开发过程时,还有一些工作(如β测试、性能调试和用户培训等)要放到最后的移交阶段(Transition)中进行。

事实上,涉及实际建模工作的微过程存在于上述的每次迭代中。迭代式开发是项目成功的重要保证。

2. UML实际建模过程

每次迭代都分为以下几个阶段:
分析阶段　建模的目的是捕捉系统的功能需求,分析、提取所开发系统的"客观世界"领域的类以及描述它们的合作概貌。
设计阶段　建模的目的是通过考虑实现环境,将分析阶段的模型扩展和转化为可行的技术实现方案。
实现阶段　具体工作就是进行编码,同时对已构造的模型作相应的修正。
配置阶段　通过模型描述所开发系统的软硬件配置情况。
测试阶段　使用前几个阶段所构造的模型来指导和协助测试工作。

在系统开发的不同阶段,使用UML为系统建模,可以通过建立不同的模型,从不同的视角,以不同的详略程度对系统进行描述。下面以一个商业管理信息系统的开发过程为例,具体介绍UML建模的实际过程:
(1) 需求
最初版本商业MIS的正文需求规格说明应当由代表系统最终用户的人员提供,内容包括系统基本功能需求和对计算机系统的要求。大致描述如下:
· 它是一个商业支持系统;
· 采购员采购所需的商品;
· 保管员将采购的商品登记入库;
· 调拨员将库存商品调拨到相应的销售部门;
· 销售部门销售商品;
· 统计部门核算商场经营状况;
· 系统能运行于通用的技术环境(如Unix、Windows等)中,具有
良好的图形用户界面
· 系统容易维护,便于功能扩充 。
由于基于UML的系统开发采取增量和迭代方式,商业MIS的初始版本仅需要完成系统的最基本功能(基本业务),而其他功能的实现(如商品移管、电子订货、电子支付、网络销售等)则在以后的版本中完成。

(2) 分析
分析的任务是找出系统的所有需求并加以描述,同时建立模型,以定义系统中的关键领域类,应由系统用户和开发人员合作完成。这一阶段不要拘泥于设计细节和技术方案。

需求分析
分析的第一步是定义用例,以描述所开发系统的外部功能需求。用例分析包括阅读和分析需求说明,此时需要与系统的潜在用户进行讨论。用例模型的主要构件是用例、角色和系统边界。用例用于描述每个功能需求,系统边界用于界定系统功能范围,而角色用于描述与系统功能有关的外部实体,它可以是用户,也可以是外部系统。
在本实例中,通过分析,先确认商业MIS中的角色有销售人员、库存人员、采购人员、辅助人员和分析人员。在此基础上,确认用例。商业MIS的用例有订货采购、库存管理、商品销售、统计分析、系统维护(包括增加商品、取消商品、制作标签、价格变更、取消或更新标签)。如图3所示。

除了用用例图描述系统需求外,还可以用文字(或活动图)对每个用例进行需求说明,更具体地描述该用例与角色的交互。例如我们可以描述订货采购用例的需求说明如下:
· 如果是新商品:
a. 新商品登记;
b. 采购进货;
c. 登记入库 。
· 如果商品库存不足:
a. 采购进货;
b. 登记入库。
订货采购需求可以用活动图来描述,如图4所示。由于用例的需求说明直接影响到后续设计阶段对类的操作的定位,因此,用例的需求说明应当尽量全面、准确。

值得说明的是,绝大多数用例可以在系统需求分析阶段确定,但随着系统的进展,可能会发现更多的用例,甚至会发现前面定义的用例存在不够确切或错误的地方,需要重新修改。因此,在整个系统开发过程中,都应当时刻关注用例。

特定领域分析
分析阶段的另一项工作是特定领域分析,以列出系统中的特定领域类。我们可以通过阅读规格说明、用例以及寻找系统处理的"概念"来进行特定领域分析,也可以通过用户和领域专家的讨论,以识别出要处理的所有关键类及它们的相互关系。这里的特定领域是指具体的商业领域,而不是整个系统领域。
在本实例中,可以确定商业MIS中的特定领域类为商品、保质商品、非保质商品、物品、销售、订货、库存、厂商,并使用类图来描述系统领域类及其关系。
需要强调的是,这一阶段对特定领域类的描述具有一定的素描性质,也就是说特定领域类的操作和属性不一定与最终实现时的定义一致。因为此时还没有涉及到系统功能的具体实现,不可能准确、完整地定义它们。有一些操作需要在设计阶段细化时才能确定。
此外,为了描述领域类的动态行为,可以使用UML中的任何一种动态图(如顺序图、活动图、合作图、状态图)。本阶段的各动态图都具有素描性质,主要是为了协助对领域类及其相互关系的分析,为下一阶段的具体设计打下基础。
UML建模是很灵活的过程,使用者不必面面俱到地画出各种图。对于每一幅图,只有在必要时(比如能帮助分析、设计、指导编码、加深理解、促进交流等)才需要画出,这样的图对建模才有意义,否则会浪费精力而事倍功半
(3) 设计
设计阶段的任务是通过综合考虑所有的技术限制,以扩展和细化分析阶段的模型。设计的目的是指明一种易转化成代码的工作方案,是对分析工作的细化,即进一步细化分析阶段所提取的类(包括其操作和属性),并且增加新类以处理诸如数据库、用户接口、通信、设备等技术领域的问题。
设计阶段可以分为两个部分:结构设计是高层设计,其任务是定义包(子系统),包括包间的依赖性和主要通信机制。我们希望得到尽可能简单和清晰的结构,各部分之间的依赖尽可能的少,并尽可能的减少双向的依赖关系。
第二部分是详细设计,细化包的内容,使编程人员得到所有类的一个足够清晰的描述。同时使用UML中的动态模型,描述特定情况下这些类的实例之间的行为。
· 结构设计
一个设计良好的系统结构是系统可扩充和可变更的基础。包实际上是一些类的集合。类图中包括有助于用户从技术逻辑中分离出应用逻辑(领域类),从而减少它们之间的依赖性。这就是软件结构设计强调的模块间的高聚合、低偶合的原则。在商业MIS中,存在以下包(或子系统):
用户接口包:用户接口类允许用户访问系统数据和加入新数据。在商业对象中,用户接口包跟商业对象包合作,调用商业对象的操作,实施数据的检索和插入。
商业对象包:包括来自分析阶段的特定领域类。在设计阶段,详细设计这些类,以完整定义他们的操作,支持对数据库的存取。所以,所有商业对象类必须继承数据库包中的类。
数据库包:为商业对象包中的类提供服务,便于永久存储。
实用包:包含系统其他包要使用的服务。它们之间的内在关系如图1所示。

· 详细设计
详细设计的目的是通过创建新的类图、状态图和动态图,描述新的技术类,并扩展和细化分析阶段"素描"的商业对象类。这些图在分析阶段也曾用过,不过在详细设计阶段,它们是从技术层次上对系统进行更详尽的描述。如分析阶段的用例描述用来验证它们是否在设计阶段都得到处理,而顺序图用来展示系统中每个用例在技术上如何实现,等等。
数据库包:MIS的实现必须有永久存储对象即数据库的支持,因此系统中必须增加数据库层,提供这种服务。目前,市面上有许多商用数据库,有的是真正的面向对象数据库如工程数据库,有的是传统的关系数据库。由于我们只讨论设计方法,不涉及具体的环境,因此,可以抽象一个永久存储类来实现对数据库的通用操作,如存储、更新、删除、查询等。永久类类似于MFC中的基类。
商业对象包:设计阶段的商业对象包即是分析阶段的领域类,需要从实现角度对这些类进行细化,包括如何实现他们之间的关联和行为。所有这些对象类必须从数据库包的永久类中继承而来。分析阶段描述的类的操作,在设计模型中可能被分解成几个操作或者改变名称。因为分析是构造每个类的框架,而设计是对系统的详细说明,因此设计模型中所有类的操作必须定义符号和返回值。图2是经过细化后的商业类图(局部)

在设计阶段,也可细化分析阶段的状态图,更详细的显示状态的变换细节(如图3)。使用状态图可以揭示单个对象在整个系统中的变化细节,对了解和实现关键类有较大的帮助。
此外,还可以使用其他图在实现层上从不同侧面对分析阶段建立的模型进行细化。
用户接口包:用户接口包在其他包的"顶层"。在系统中,它为用户提供信息和支持。由于所有与用户的交互都是通过用户接口实现的,因此UML的动态模型非常适合对GUI包的描述。图4用顺序图描述系统增加新商品用例的动态模型。另一种表示顺序的图是合作图(如图5)。

建立用户接口是设计阶段的一项特殊活动。在商业MIS中,用户接口可以分为功能(系统中的主功能窗口,如采购、库存、销售、统计分析等)、信息(显示系统信息的窗口以及(维护系统的窗口)等三部分。
目前,由于可视化技术的迅速发展,用户界面的设计相对比较简单。一般情况下,应用系统的用户界面由带有菜单条和相应图形的主窗口组成。
(4) 实现
构造或实现阶段是对类进行编程的过程。可以选择某种面向对象对象编程语言(如Java)作为实现系统的软件环境。Java很容易实现从逻辑视图到代码部件的映射,因为类到Java代码文件之间是一一映射关系。图6是设计模型的部件图,显示逻辑视图到部件视图的一个简单映射。逻辑视图中的包也映射到相应的部件视图中。

在实现阶段中,可以选取下列图的说明来辅助编程:
· 类的规格说明:每个类的规格说明详细显示了必要的属性和操作。
· 类图:显示类的静态结构和类之间的关系。
· 状态图:显示类的对象可能的状态、所需处理的转移以及触发这些转移的操作。
· 包含某个类的对象的动态图(顺序图、合作图、活动图):显示该类的某个方法的实现或别的对象是如何使用该类的对象的。
· 用例图和规格说明:显示系统需求和结果。
编码期间也可能会发现设计模型的缺陷。这时需要开发者修改设计模型。修改设计模型时一定要保持设计模型与编码的一致性,以便将来易于维护。
(5) 测试和配置
完成系统编码后,需要对系统进行测试,它通常包括:单元测试、集成测试、系统测试和验收测试。在单元测试中使用类图和类的规格说明,对单独的类或一组类进行测试;在集成测试中,使用组件图和合作图,对各组件的合作情况进行测试;在系统测试中,使用用例图,以检验所开发的系统是否满足例图所描述的需求。
系统的配置是实际的交付系统,包括文档和组成模型等。对商业MIS而言,它是一个典型的客户/服务器系统。可以用配置图显示系统的物理结构,如图7所示。从表面上看,配置图能显示系统设备之间的关系以及显示节点跟可执行软件单元的对应关系。然而一旦某个节点内部的对象或可执行部件过多(超过5个),就很难完全用配置图清楚描述这种关系。

(6) 小结

本文所举的商业MIS系统的UML建模过程可以用图8来描述。其中首先要把握的是如何使用用例技术正确描述系统需求。UML中的类图描述的是系统中类的静态关系,对象图有助于对复杂类的理解。在系统开发过程中,类图可应用于分析、设计和实现阶段。类的包化有助于进行系统结构设计。商业MIS的包分为用户接口包、商业对象包、数据库包,他们之间的关系是前者依赖后者。

UML的动态模型包括状态图、顺序图、合作图以及活动图。在商业MIS中,顺序图对描述商业对象的交互非常有用,是商业MIS分析、设计和实现阶段最重要的支持手段之一。

总之,UML提供的九种视图从不同应用层次和不同角度为系统从系统分析、设计直到实现的提供有力支持。在不同的阶段建立不同的模型,建模的目的也各不相同。

UML为用户建模提供了强大的支持,并提供了很大的自由度。用户在遵循增量迭代开发的原则下,完全可以根据自己所开发系统的特点,在每次迭代的微过程(分析、设计、实现、测试和配置)中,灵活的选用UML所提供的各种图。
我们认为,未来的软件开发范式将具有以下三个特点:首先,软件开发自动化的程度将越来越高;其次,在所开发的软件中隐藏的差错将越来越少;第三,在新型软件工程环境的支持下,将有能力开发出自适应的软件系统。标准建模语言UML及其集成化支持环境,将为走向这个新范式铺平道路(全文完)。

Trackback: http://tb.donews.net/TrackBack.aspx?PostId=165914