T
taozhiyu
Unregistered / Unconfirmed
GUEST, unregistred user!
前五期所述主要内容如下:
一、标准建模语言uml概述
二、标准建模语言uml的静态建模机制
三、标准建模语言uml的动态建模机制
四、标准建模语言uml的支持环境
1. 过程工程的基本要点
2. uml柔性软件开发过程及其支持环境
(接上期)
3. uml集成化支持环境
uml集成化支持环境是在需求牵引下支持建造柔性信息系统的系统开发环境,其组成应包
括uml可视化建模系统、模拟系统、代码生成系统、逆向变换系统、质量控制系统及其支
持软件等。这些环境均应基于uml的语法规则和语义定义,如图1所示。由此可知,这个支持环
境是一个能支持系统建模、系统模拟和系统生成的"闭环式开发"的集成化支持环境。
(1) uml可视化建模系统的框架
uml可视化建模系统支持从系统需求、系统分析到系统设计的整个建模过程,提供um l图形
的编辑和美化工具,保证得到语法正确、语义完整的uml图形模型,并提供包括文档管理和图
形打印等辅助支持。
支持环境的建模机制
由于uml不仅支持对系统的对象建模,还支持对需求和系统体系结构的建模,不仅支持建立系
统的静态模型,还支持描述系统的动态模型,因此,模型建造系统应支持以下模型的创建和
编辑:
需求模型 包括静态模型和动态模型。静态模型即功能模型,在uml中通过用例图描述系统
功能和各功能的潜在用户及它们之间的关系。动态模型通过活动图支持对业务过程或事务
处理过程的描述。
系统对象模型 包括静态模型和动态模型。通过包图、类图和对象图定义系统对象及对象
间的静态关系;通过顺序图、合作图和状态图描述对象间的交互关系、对象的生命周期以及
生命周期中对象可能存在的状态和状态间的转换约束。
系统体系结构模型 通过组件图和配置图支持软件体系结构和硬件体系结构以及通信机制的
定义。同时,还应进一步支持软硬件系统之间的合作关系的可视化表示。
建模系统的检测机制
uml语法正确性检测机制 为保证所得到的uml图形模型符合其语法定义,应提供语法正确性
检测机制。一个较好的方法是提供语法制导的uml可视化建模工具,在模型的建造过程中提供
动态的语法制导和语法检测功能。这样,既可方便用户学习和使用,也可保证所建造的模型
在语法结构上的正确性。
uml模型的一致性检查机制 由于uml支持从需求分析到系统设计整个建模过程,并且支持用
户从不同的角度描述系统,而大型软件项目各模型间的协作和约束关系错综复杂,显然不应
由用户独自承担对它们的管理和维护工作。作为建模支持系统,应提供模型间的一致性检查
机制。
首先,该机制应根据以上对基于uml软件开发模型的讨论,在软件开发阶段时间轴上确定引入
模型的时间;其次,明确同一种模型的细化分层机制,以及怎样用其他模型描述主模型的细节
;第三,在软件开发阶段时间轴上,一个模型存在自顶向下分解的层次结构,在各时间阶段产
生的层次结构中,各种uml模型相互约束、协作又产生复杂的网状关系,需要建立不同阶段、
不同功能的同一种模型与不同种模型约束和协作的数学模型;最后,在该数学模型的基础上
,研究将约束和协作关系有机地加入软件开发各个阶段的模型一致性检查机制。此外,由于
允许从不同的角度描述同一模型,如交互图包括顺序图和合作图,这两者之间允许存在冗余
信息,因此,不仅应保证两者间信息的一致性,还可考虑支持模型间的一致性转换。
uml模型的完备性检查机制 完备性检查机制须在uml语义定义的基础上,首先定义uml图形
模型的完备性准则,以保证uml图形模型的完备性。uml图形模型的完备性可分三个层次来
考虑,即:各个图形的完备性;各个子模型的完备性,也就是相关图形的组合完备性;系统模型
的整体完备性。区分这三种完备性的意义在于:在不同阶段可以进行语义完备性和语义正
确性检查。
文档生成和管理工具 文档生成工具是指文档自动生成机制。作为一个建模支持系统,应支
持包括需求描述、面向对象分析和设计、系统体系结构等文档资料的自动生成。文档管理
工具是指文档资料的版本管理等辅助管理工作。
(2) uml模拟系统
系统模拟机制支持对uml模型的功能模拟和性能模拟,它包括以下三个部分:
动态模型的模拟 主要包括对活动模型、交互模型(顺序图和合作图)以及状态图的模拟。
根据预先定义的语义,模拟各个模型对系统在时间特性上的描述是否真实地反映了客观现
实和用户需求,并应提供相应的跟踪调试机制。
系统功能(需求)和用户界面的模拟 借助于代码自动生成工具和用户界面自动生成工具的
支持,产生系统原型,并尽早提供给用户,以确保建模的有效性。
系统性能的模拟 作为一个良好的建模和开发支持工具,以支持对系统体系结构的建模,即
在不同系统配置和功能分配的情况下,对系统性能进行模拟,以便得到优化的系统设计方案
和合理的系统配置。
(3) uml代码生成系统
uml集成化支持环境应能支持可视化对象和行为的代码生成。uml代码生成系统也称之
为uml支持环境的正向变换系统。众所周知,软件开发的最终目的是产生可执行代码。在
大多数软件开发环境中,建模和编码过程缺少有机的统一,这是有其历史原因的。其中最
重要的原因是缺少功能强大、简单清楚、标准统一的建模语言。uml的出现以及被omg接受
为标准,为消除这个障碍提供了一个很好的起点。
在uml语言的代码生成机制方面,国际上一些大公司做了有益的研究和开发工作,比较有代表
性的是rational公司和advanced software technologies inc.。但这些研究和实现大多
限于uml静态模型中的类图,其他有关模型代码自动生成机制的研究资料则非常罕见。
我们认为,代码自动生成机制应根据uml语言多种模型动态协作、关系复杂的特点,首先界
定uml的语义和面向对象编程语言(首先是java)的语义,研究专用语义机制描述面向对象模
型和语言中动态与静态机制,建立两者的语义模型。然后,再在该语义模型下建立两者的
映射模型,并研究代码自动生成实现技术和独立于uml语言本身的编程语言的特殊机制。
代码自动生成机制在研究与实现时,还应考虑后面逆向转换机制的需求。
(4) uml软件质量控制
软件系统的质量往往是大型、复杂系统成败的关键。软件系统质量难以保证的主要原因首
先是软件系统固有的复杂性。但人们往往对这一点尚未有足够的认识,而把软件系统的复
杂程度看得过低。另外一个原因是由于软件系统及其管理工作固有的不可见性。采用定量
软件工程有利于改善可见性,但是还不可能做到完全透明。因此,在当代软件技术水平的前
提下,建造软件质量控制环境势在必行。学术界与工业界对软件质量工程的看法主要划分
为两个流派,一个叫"产品足够优质"(good-enough),另一个叫"无差错软件"( error-free)。
在建造软件质量控制环境时,除了应建造通用软件过程管理环境(包括软件项目管理、软件配
置管理和软件质量管理)、软件过程支持环境(以支持软件开发单位成熟度模型cmm、个体
软件过程psp和支持群组软件过程tsp的实现)外,还应包含相互联系但可分别独立使用的三
个子环境:
集成化软件测试环境 这个环境应包括软件需求覆盖测试工具、源程序覆盖测试工具、软
件回归测试工具、软件测试管理工具和内存负载检测工具等。
集成化软件质量度量环境 度量有关软件质量的原始数据,并据此来计算iso软件度量标准
中所需要的管理度量元。
软件产品质量综合评测系统 从上述诸方面因素对软件产品的质量进行综合考虑,把所得
到的数据进行加权综合。只有满足整体要求的软件才被认为是一个合格的软件产品。
(5) uml逆向变换系统
当用户对生成的代码进行修改后,逆向转换机制将用户的修改转换到模型上。否则,将造成
模型和代码间的不一致性,使系统的扩充、增删和维护难以进行。
我们认为,如果一个支持环境既有正向变换机制,又有逆向变换机制,就能保持模型和代码的
一致性。动态模型的逆向转换机制是研究难点,一般可由建模、析取和抽象三个步骤组成
。我们将在正向转换的基础上,建立起模型到代码的映射关系,尝试建立一套约束机制,实
现自动的或人工导引的逆向转换机制。目前,国际上对这方面的研究尚不成熟。
五、标准建模语言uml的应用实例
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建模是很灵活的过程,使用者不必面面俱到地画出各种图。对于每一幅图,只有在必要
时(比如能帮助分析、设计、指导编码、加深理解、促进交流等)才需要画出,这样的图对
建模才有意义,否则会浪费精力而事倍功半。(未完待续)
一、标准建模语言uml概述
二、标准建模语言uml的静态建模机制
三、标准建模语言uml的动态建模机制
四、标准建模语言uml的支持环境
1. 过程工程的基本要点
2. uml柔性软件开发过程及其支持环境
(接上期)
3. uml集成化支持环境
uml集成化支持环境是在需求牵引下支持建造柔性信息系统的系统开发环境,其组成应包
括uml可视化建模系统、模拟系统、代码生成系统、逆向变换系统、质量控制系统及其支
持软件等。这些环境均应基于uml的语法规则和语义定义,如图1所示。由此可知,这个支持环
境是一个能支持系统建模、系统模拟和系统生成的"闭环式开发"的集成化支持环境。
(1) uml可视化建模系统的框架
uml可视化建模系统支持从系统需求、系统分析到系统设计的整个建模过程,提供um l图形
的编辑和美化工具,保证得到语法正确、语义完整的uml图形模型,并提供包括文档管理和图
形打印等辅助支持。
支持环境的建模机制
由于uml不仅支持对系统的对象建模,还支持对需求和系统体系结构的建模,不仅支持建立系
统的静态模型,还支持描述系统的动态模型,因此,模型建造系统应支持以下模型的创建和
编辑:
需求模型 包括静态模型和动态模型。静态模型即功能模型,在uml中通过用例图描述系统
功能和各功能的潜在用户及它们之间的关系。动态模型通过活动图支持对业务过程或事务
处理过程的描述。
系统对象模型 包括静态模型和动态模型。通过包图、类图和对象图定义系统对象及对象
间的静态关系;通过顺序图、合作图和状态图描述对象间的交互关系、对象的生命周期以及
生命周期中对象可能存在的状态和状态间的转换约束。
系统体系结构模型 通过组件图和配置图支持软件体系结构和硬件体系结构以及通信机制的
定义。同时,还应进一步支持软硬件系统之间的合作关系的可视化表示。
建模系统的检测机制
uml语法正确性检测机制 为保证所得到的uml图形模型符合其语法定义,应提供语法正确性
检测机制。一个较好的方法是提供语法制导的uml可视化建模工具,在模型的建造过程中提供
动态的语法制导和语法检测功能。这样,既可方便用户学习和使用,也可保证所建造的模型
在语法结构上的正确性。
uml模型的一致性检查机制 由于uml支持从需求分析到系统设计整个建模过程,并且支持用
户从不同的角度描述系统,而大型软件项目各模型间的协作和约束关系错综复杂,显然不应
由用户独自承担对它们的管理和维护工作。作为建模支持系统,应提供模型间的一致性检查
机制。
首先,该机制应根据以上对基于uml软件开发模型的讨论,在软件开发阶段时间轴上确定引入
模型的时间;其次,明确同一种模型的细化分层机制,以及怎样用其他模型描述主模型的细节
;第三,在软件开发阶段时间轴上,一个模型存在自顶向下分解的层次结构,在各时间阶段产
生的层次结构中,各种uml模型相互约束、协作又产生复杂的网状关系,需要建立不同阶段、
不同功能的同一种模型与不同种模型约束和协作的数学模型;最后,在该数学模型的基础上
,研究将约束和协作关系有机地加入软件开发各个阶段的模型一致性检查机制。此外,由于
允许从不同的角度描述同一模型,如交互图包括顺序图和合作图,这两者之间允许存在冗余
信息,因此,不仅应保证两者间信息的一致性,还可考虑支持模型间的一致性转换。
uml模型的完备性检查机制 完备性检查机制须在uml语义定义的基础上,首先定义uml图形
模型的完备性准则,以保证uml图形模型的完备性。uml图形模型的完备性可分三个层次来
考虑,即:各个图形的完备性;各个子模型的完备性,也就是相关图形的组合完备性;系统模型
的整体完备性。区分这三种完备性的意义在于:在不同阶段可以进行语义完备性和语义正
确性检查。
文档生成和管理工具 文档生成工具是指文档自动生成机制。作为一个建模支持系统,应支
持包括需求描述、面向对象分析和设计、系统体系结构等文档资料的自动生成。文档管理
工具是指文档资料的版本管理等辅助管理工作。
(2) uml模拟系统
系统模拟机制支持对uml模型的功能模拟和性能模拟,它包括以下三个部分:
动态模型的模拟 主要包括对活动模型、交互模型(顺序图和合作图)以及状态图的模拟。
根据预先定义的语义,模拟各个模型对系统在时间特性上的描述是否真实地反映了客观现
实和用户需求,并应提供相应的跟踪调试机制。
系统功能(需求)和用户界面的模拟 借助于代码自动生成工具和用户界面自动生成工具的
支持,产生系统原型,并尽早提供给用户,以确保建模的有效性。
系统性能的模拟 作为一个良好的建模和开发支持工具,以支持对系统体系结构的建模,即
在不同系统配置和功能分配的情况下,对系统性能进行模拟,以便得到优化的系统设计方案
和合理的系统配置。
(3) uml代码生成系统
uml集成化支持环境应能支持可视化对象和行为的代码生成。uml代码生成系统也称之
为uml支持环境的正向变换系统。众所周知,软件开发的最终目的是产生可执行代码。在
大多数软件开发环境中,建模和编码过程缺少有机的统一,这是有其历史原因的。其中最
重要的原因是缺少功能强大、简单清楚、标准统一的建模语言。uml的出现以及被omg接受
为标准,为消除这个障碍提供了一个很好的起点。
在uml语言的代码生成机制方面,国际上一些大公司做了有益的研究和开发工作,比较有代表
性的是rational公司和advanced software technologies inc.。但这些研究和实现大多
限于uml静态模型中的类图,其他有关模型代码自动生成机制的研究资料则非常罕见。
我们认为,代码自动生成机制应根据uml语言多种模型动态协作、关系复杂的特点,首先界
定uml的语义和面向对象编程语言(首先是java)的语义,研究专用语义机制描述面向对象模
型和语言中动态与静态机制,建立两者的语义模型。然后,再在该语义模型下建立两者的
映射模型,并研究代码自动生成实现技术和独立于uml语言本身的编程语言的特殊机制。
代码自动生成机制在研究与实现时,还应考虑后面逆向转换机制的需求。
(4) uml软件质量控制
软件系统的质量往往是大型、复杂系统成败的关键。软件系统质量难以保证的主要原因首
先是软件系统固有的复杂性。但人们往往对这一点尚未有足够的认识,而把软件系统的复
杂程度看得过低。另外一个原因是由于软件系统及其管理工作固有的不可见性。采用定量
软件工程有利于改善可见性,但是还不可能做到完全透明。因此,在当代软件技术水平的前
提下,建造软件质量控制环境势在必行。学术界与工业界对软件质量工程的看法主要划分
为两个流派,一个叫"产品足够优质"(good-enough),另一个叫"无差错软件"( error-free)。
在建造软件质量控制环境时,除了应建造通用软件过程管理环境(包括软件项目管理、软件配
置管理和软件质量管理)、软件过程支持环境(以支持软件开发单位成熟度模型cmm、个体
软件过程psp和支持群组软件过程tsp的实现)外,还应包含相互联系但可分别独立使用的三
个子环境:
集成化软件测试环境 这个环境应包括软件需求覆盖测试工具、源程序覆盖测试工具、软
件回归测试工具、软件测试管理工具和内存负载检测工具等。
集成化软件质量度量环境 度量有关软件质量的原始数据,并据此来计算iso软件度量标准
中所需要的管理度量元。
软件产品质量综合评测系统 从上述诸方面因素对软件产品的质量进行综合考虑,把所得
到的数据进行加权综合。只有满足整体要求的软件才被认为是一个合格的软件产品。
(5) uml逆向变换系统
当用户对生成的代码进行修改后,逆向转换机制将用户的修改转换到模型上。否则,将造成
模型和代码间的不一致性,使系统的扩充、增删和维护难以进行。
我们认为,如果一个支持环境既有正向变换机制,又有逆向变换机制,就能保持模型和代码的
一致性。动态模型的逆向转换机制是研究难点,一般可由建模、析取和抽象三个步骤组成
。我们将在正向转换的基础上,建立起模型到代码的映射关系,尝试建立一套约束机制,实
现自动的或人工导引的逆向转换机制。目前,国际上对这方面的研究尚不成熟。
五、标准建模语言uml的应用实例
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建模是很灵活的过程,使用者不必面面俱到地画出各种图。对于每一幅图,只有在必要
时(比如能帮助分析、设计、指导编码、加深理解、促进交流等)才需要画出,这样的图对
建模才有意义,否则会浪费精力而事倍功半。(未完待续)
]