UML方法范文
UML方法范文（精选9篇）
UML方法 第1篇
制造业是经济建设和国防建设的基础, 也是社会发展的原动力。产品信息建模是21世纪制造业的一项关键支撑技术, 合理的产品模型对产品开发和企业生存具有重要的意义。产品模型是产品全生命周期管理的底层支撑, 国内外对企业产品信息建模方面的研究已经开展多年, 取得相当多的研究成果。比较著名的研究成果有CIM-OSA方法、ARIS体系结构、IDEF方法、GRAI/GIM方法与PERA方法等, 另外工作流建模技术、面向对象建模方法也取得了不少研究成果[1]。
UML是一种通用的可视化建模语言。它是在Booch, OMT和OOSE三大面向对象方法学基础上, 吸取了其他面向对象开发方法和近30年软件工程的经验和成果, 抽象出的模型语言[2]。UML的目标是以面向对象图的方式来描述任何类型的系统, 具有很广的应用领域。其中, 最常用的是建立软件系统的模型, 但它同样可以用于描述非软件领域的系统[3]。目前, UML已在企事业、金融、交通、电讯、国防、医学、科研、网络等领域得到实际应用。
传统的建模方法, 描述系统和语义约束能力差, 基于UML的产品模型可以解决全生命周期产品定义、过程和资源的一致性问题, 同时提供了多种视图来满足不同角度创建系统的需要。现以UML建模语言为基础, 依据UML四层元元模型结构结合元模型理论、面向对象的建模方法和广义产品建模方法寻求一种能为企业建立支持产品全生命周期, 具有多角度, 多视图, 界面友好, 便于理解、并且有严格语义约束, 数据完整一致, 少冗余的产品信息模型的建模方法。
1 基于UML的产品三层结构模型
元模型就是关于模型的模型, 是关于如何建立模型、模型的语义或模型之间如何集成和互操作等信息的描述。元模型由于比模型的抽象程度高, 因此能够较好地解决模型集成中地问题。元模型是用来解决模型层难以解决的问题, 同样在元模型层难以解决的问题可以通过元元模型来解决[4]。
软件工程中, 为统一定义各种建模语言及模型间的转换关系, OMG试图提出各建模语言 (元模型) 的公共抽象 (元元模型) 来统一建模语言的表达, 继而可以统一各模型之间转换规则的表达, 于是在1999年提出了MOF规范, 此规范借用UML的图示方法, 基于面向对象思想的概念定义元建模元素。现在OMG给出的各项规范中, UML, CMW和CORBA IDL等均已采用基于MOF的定义[5]。
根据软件行业中UML和MOF定义的四层元元模型结构和相互关系如图1所示[6], 定义产品模型中三层元元模型结构和相互关系如图2所示。
基于对UML四层元模型结构中MOF层和UML层的分析, 结合机械类产品所要表达的内容, 给出以下定义:
1) 产品元元类:位于产品元元模型层中不再细分, 具有自我解释定义的类。
2) 产品元类:位于产品元模型层中类, 是产品元元类的实例。
3) 产品元元模型:模型中除了被解释的元素以外, 必须全部由产品元元类构成。
4) 产品元模型:产品元元模型的实例, 由产品元类或产品元类和产品元元类构成。
建立产品元元模型层目的是为了解决产品模型层无法解决的问题如产品元模型层语义含糊、模型集成和信息共享等。产品元元模型层的类型系统比产品模型层的类型系统更细致地划分了模型的类型系统中的各种概念、关系、约束等, 并且还包含关于产品元模型的控制和指导等信息的概括和抽象, 将产品元元模型的这些概念实例化就可以对某个具体元模型的建模进行监控。
产品元模型层中的产品元类是产品元元类的综合实例, 是在产品全生命周期建模中的主要元素, 产品元类在UML建模环境语义约束下按照相互间的关系进行一定形式的交换构成了产品的元模型。产品元模型加直观体现出面向对象的思想, 同时语法规则和语义约束在UML建模工具环境下得到了严格的约束。用于元模型层建模的产品元类的定义是在产品元元层来完成的。通过这种层级约束, 确保了产品建模中模型逻辑一致性和数据完整性。
2 产品元元层和产品元层
利用UML的扩展机制结合广义建模理论建立如图3所示的产品元元模型基本组成结构[7]。给出以下几种类的定义:
1) 信息类:基于广义产品模型下的不同层次, 不同类型信息的抽象定义。
2) 过程信息类:信息类中关于对产品生命过程方面描述类的抽象定义。
3) 结构信息类:信息类中关于对产品结构方面描述类的抽象定义。
4) 关系类:用于定义广义产品模型环境中“点”与“点”之间的关联信息, 即产品生命周期过程中各类关联属性的抽象定义。
5) 结构关系类:关系类中关于对产品结构关系方面描述类的抽象定义。
6) 过程关系类:关系类中关于对产品过程关系方面描述类的抽象定义。
产品元元类由信息类和关系类构成;信息类由结构信息类和过程信息类构成;关系类由结构关系类和过程关系类构成。产品元类依赖产品元元类来描述。
结构信息要满足表达、评价和管理的需要。因此结构信息包括表达性结构信息、评价性结构信息和管理性结构信息。
过程是不同状态之间活动的集合, 活动则以一系列的步骤或行为以及行为所引起的对象状态的改变为特征。可以认为活动以前面的活动所产生的产品数据 (或状态信息) 为输入, 经过决策, 并采用一定的行为或步骤, 对输入的产品相关信息进行操作, 形成新的产品状态或产品数据。过程作为活动的记录, 其内容应该能够体现活动的特征。
关系信息体现了在装配层次上对产品结构的描述, 是产品功能特征的体现, 因为机械产品的功能主要通过构成产品的零、部件之间静态或动态的配合关系来实现, 这类信息的获得主要在产品的概念设计和结构设计阶段。按照广义产品建模方法结构关系根据性质不同分为三类, 分别是功能关系、定位关系和运动关系。
过程是由一个和若干个活动 (过程单元) 构成的。这些活动之间存在关系, 或表现为一种时间性的关系, 或表现为一种逻辑性的关系。
产品元元类库是产品元元类的集合, 按照所述方法, 建立产品元元类库如图4所示。
以其中结构关系元元类包为例展开抽象产品结构关系元元类如图5所示。
根据产品全生命周期建模需要, 定义产品元类由产品基本元类、产品需求元类、产品设计元类、产品制造元类、产品销售元类和产品服务元类构成, 如图6所示。
建立产品元类库如图7所示。
以其中产品服务元类包为例展开抽象产品结构关系元元类如图8所示。
3 产品生命周期建模
参照PTC公司对产品全生命周期阶段的划分, 将产品生命周期划分为需求分析、设计、制造、销售和服务五个阶段[8,9]。
1) 产品需求分析阶段:在这一阶段企业通过调查和分析市场和客户需求, 确定产品的基本功能, 性能, 使用环境和其他约束, 实现产品信息从客户角度向设计者角度的转换。
2) 产品设计阶段:产品设计阶段一般要分为三个阶段, 概念设计, 详细设计和工艺设计。在这三个阶段中, 产品设计所需的信息是不同的。随着设计的深入进行, 产品所包含的信息越来越丰富。概念设计阶段完成产品的功能定义和原理设计, 提供原理设计方案;详细设计阶段细化原理方案, 提供原理的具体实现结构, 得到产品的技术方案;工艺设计阶段则是对产品制造工艺流程的设计, 是产品设计阶段向制造阶段的过渡。
3) 产品制造阶段:产品制造阶段包括生产准备、供应、加工、外协, 装配等过程, 是产品在物理上形成的阶段。在该阶段, 相关人员对各种计划进行分解, 优化调度配制所需的制造资源, 进行加工装配等活动。
4) 产品销售阶段:产品销售阶段的主要活动包括, 市场推广、产品发布、销售战略制定以及客户管理、定单管理等。PLM系统负责企业与分销商、客户以及供应商之间的信息协调和管理, 保证定单、生产、库存和销售等环节的畅通和一致性。
5) 产品服务阶段:产品服务阶段是从物理产品形成到产品报废为止的时间跨度。在这个阶段企业服务人员对产品进行测试, 交付用户使用。典型的服务包括产品安装、使用培训、故障诊断和维护等。
对应产品生命周期的划分, 产品生命周期各阶段模型对应企业人员职责的活动图泳道模型如图9所示。
产品全生命周期建模目的是建立面向产品全生命周期的统一的、具有可扩充性的能表达完整信息的产品模型, 该产品模型能随着产品开发进程自动扩张, 并从设计模型自动映射为不同目的的模型, 如可制造性评价模型、成本估算模型、可装配性模型、可维护性模型等, 同时产品模型应能全面表达和评价与产品全生命周期相关的性能指标[10]。
产品全生命周期模型用例模型如图10所示。产品整个周期包含了客户和外部企业在内的多范围用例。随着先进制造技术的发展, 企业间信息交流的日益频繁, 产品生产已走出单一企业, 向着联盟方向发展。
以产品制造阶段为例, 建立产品制造阶段元模型如图11所示。产品制造活动在产品设计模型的基础上, 根据产品的加工和装配关系, 改变产品的设计BOM, 参照工艺BOM, 经过演化映射形成制造BOM。零件可以划分为由其他企业加工的外协件和本企业加工的自制件。对于外协件, 制造企业需要到市场中进行采购。零件的加工需要按照工艺路线和规则进行, 所以零件类依赖于工艺类。部件类是一组相互聚合的零件组合。机械产品的功能和设计者的意图体现于零件的具体几何结构, 特别是零件间的相互连接和装配关系, 这就要求制造企业重视产品的装配工艺。各种制造和装配工艺不仅规定了工艺操作方法, 也提出了产品制造过程中的资源要求。部件需要按照装配工艺进行装配操作, 在部件类与工艺之间存在依赖关系。同时, 加工工艺、装配工艺和生产计划依赖于企业资源。
4 采用UML对模型映射关系建模
以产品BOM为例说明采用UML对模型关系建模的方法。
BOM的含义是物料项清单 (bill of material) 即构成一个物料项的所有子物料项的列表。在产品的全生命周期中, 存在着各种面向企业不同部门、具有不同用途的BOM文件, 不同的部门为了各自的目的设计、生成、管理和使用BOM。在产品的全生命周期中, BOM视图种类和相互间关系如图12所示[11]。
下面, 以设计BOM到工艺BOM的演化映射为例来说明采用UML对模型映射关系建模的方法。一般来说, 由于工艺的变动而导致其映射信息不同的原因主要可以归结为[11]:
1) 继承部件映射规则Fi ( ) 。
在产品P中, 如果设计BOM中某一部件为继承部件, 则在工艺BOM中该部件完全继承其在设计BOM中定义的装配关系。图13中的e部件。
2) 虚设部件映射规则Fv ( ) 。
如果在工艺中将设计BOM中某部件定义为虚设部件, 则在工艺BOM中应该将该部件在设计BOM中的下属所有零部件按设计BOM中表述的数量关系移动到虚设部件的父件中去。如图13中的c部件。
3) 中间部件映射规则Fm ( ) 。
如果某部件是中间部件, 则应该根据工艺BOM中的中间部件相关信息和设计BOM的中间部件的父子件的相关信息, 在制造BOM中添加中间部件的装配关系信息。如图13中的f部件。
4) 外协部件映射规则Fc ( ) 。
在制造BOM中只描述外协部件本身, 而不描述外协部件的下级零部件物料信息。因此, 所有的外协部件处于BOM树的叶节点上, 外协部件在制造BOM中可以视为一个零件来处理, 正如在设计BOM/制造BOM的形式化描述中不描述处于叶结点的零件一样, 外协部件应设成空元素。如图13中的d部件。
自然属性映射符合继承部件映射规则, 所以从EBOM到PPBOM的演化映射模型如图14所示。
5 产品层建模
产品层的建模即是对产品元层模型的实例化, 现以平口钳为例, 对元模型的应用进行详细讨论, 验证基于UML的产品建模方法的准确性和有效性。
平口钳, 作为一种夹具, 在生产工作中得到广泛使用。Pro/E中产品的3D模型如图15所示。
平口钳的产品层结构模型如图16所示。平口钳产品由平口钳固定部件和平口钳活动部件两个部件以及1个到多个平口钳文档组成。其中平口钳固定部件由下列零件组成:1个固定钳身、1个平口钳垫圈、1根丝杠、1个垫圈、2个螺母、1块钳口板和2个螺钉。平口钳活动部件包括下列零件:1个平口钳螺钉、1个平口钳螺母、1块活动钳口、2个螺钉和1块钳口板。
平口钳的产品层关系模型如图17所示。平口钳固定部件和平口钳活动部件是靠丝杠和平口钳螺母之间的丝杠螺母连接关系装配的, 固定钳身和丝杠关系是轴孔连接, 钳口板和固定钳身以及钳口板和活动钳口的关系是螺钉连接, 活动钳口和平口钳螺钉为轴孔连接, 活动钳口和平口钳螺母是平面配合, 平口钳螺钉和平口钳螺母是螺栓连接, 平口钳螺钉和活动钳口是轴孔连接关系。产品层模型是这两种模型的叠加。
应用前面所建立的BOM映射元模型来建立平口钳产品的设计BOM向工艺BOM的映射模型如图18所示。
6 结论
文中所做研究工作目的是为了寻求更加有效建立支持产品全生命周期模型的方法。通过以上工作, 建立了基于UML的产品信息模型。UML严格的语法规则和语义约束为产品定义、制造、服务等过程和资源提供了一个联结, 解决了全生命周期产品定义、过程和资源的一致性和数据冗余问题。同时产品全生命周期建模是一项多角色参于多角度需求的复杂工程, 基于UML的产品建模方法提供了多种视图来满足不同角色和角度创建系统的需要, 支持产品静态、动态和工作流建模。该工作扩展了以往对产品建模方法的研究, 为进一步对产品信息的管理奠定了基础。
摘要：为有效保证产品全生命周期产品定义、过程和资源的一致性, 同时满足系统多角度创建系统的需要, 提出基于UML的产品建模方法。通过定义“产品元元模型层”、“产品元模型层”和“产品模型层”三层产品模型结构及其内容和相互关系, 实现了产品建模定义、约束统一性, 实际应用表明基于UML的产品建模方法的有效性和可行性。
关键词：产品元元模型,产品元模型,产品模型
参考文献
[1]杨云涛, 王润孝, 等.企业建模方法及ARIS建模过程应用研究[J].组合机床与自动化加工技术, 2007 (3) :86-88.
[2]Joseph Schmuller.李虎, 赵龙刚译.UML基础、案例与应用[M].3版.北京:人民邮电出版社, 2006:4-5.
[3]徐宝文, 周毓明, 卢红敏.UML与软件建模[M].北京:清华大学出版社, 2006:6-7.
[4]肖田元.虚拟制造[M].北京:清华大学出版社, 2004.65.
[5]Object Management Group (OMG) .Meta Object Facility (MOF) Core Specifica-tion.Version2.0:5P (http://www.omg.org/docs/formal/06-01-01.pdf, accessed in October 2007) .
[6]Joseph Schmuller.UML基础、案例与应用[M].3版.李虎, 赵龙刚, 译.北京:人民邮电出版社, 2006.156.
[7]王涛.广义产品建模方法的研究[D].北京:清华大学博士学位论文.2004:23-88.
[8]黄双喜, 范玉顺.产品生命周期管理研究综述[J].计算机集成制造系统CIMS.2004, 10 (1) :1-9.
[9]舒启林, 王成恩.产品全生命周期中面向客户服务的产品模型[J].中国机械工程.2005, 16 (15) :1358-1362.
[10]沈建新, 周儒荣.产品全生命周期管理系统框架及关键技术研究[J].南京航空航天大学学报.2003, 35 (5) :565-571.
基于UML的系统分析与设计 第2篇
关键词：UML；系统分析；语言
中图分类号：TP311.52 文献标识码：A 文章编号：1674-7712 （2014） 18-0000-01
随着社会信息化程度的逐渐加快，软件的需求量变得越来越大，结构也变得越来越复杂，这无形中增加了软件开发的难度系数和复杂性。UML作为一种面向对象的建模方法，融入了软件工程领域的新方法、新技术、新思想，在软件不同的开发周期使用同一组概念和表示方法，并且在同一个模型中可以混合使用，具有功能强大、容易表达、适用度较高等优势。
一、统一建模语言
UML的简介。统一建模语言是OMG（Object Management Group）组织于1997年发布的。它是一种面向可视的、对象的且被广泛使用的建模工具。UML语言由元模型和图构成，图代表的是UML的语法，定义各种UML元素、框图、符号及使用方法。元模型是UML的语义，可以给出图的含义，所以UML是通过元模型描述的以图形表示方法为基础的一种建模语言。UML的特点如下：
（1）UML仅仅是一种标准的建模语言，它完全独立于开发过程；（2）UML是单一通用的建模语言；（3）UML擅长分布式、并行的系统的建模；（4）UML有许多新的概念，如扩展机制、模式等。
常见的UML模型图一般包括静态的用例图、动态的状态图和活动图的行为图。用例图包含类图、包图、对象图；状态图和行为图包含顺序图、协作图的交互图形以及构件图、配置图的实现图等5类10种模型。
二、UML在系统开发中的建模
（一）RUP
RUP（Rational Unified Process）是Rational軟件公司创造的一种面向对象且基于网络的软件工程方法。因为UML仅仅是一种建模语言而不是建模方法，本身独立于过程，因此在实际的开发中通常会将RUP和UML联系在一起，建立软件系统可视化模型，帮助人们提供管理软件复杂性的能力。RUP告诉我们如何通过可视化对软件系统建模，使建模变的直观、清晰，降低软件开发的风险系数，从而能更好的适应用户需求的经常性变动，控制整个系统的开发过程，维护系统完整性。
RUP软件生命周期在时间上一般可分为开始、细化、构建和移交4个阶段。开始阶段是为了系统建立案例，通过确定参与者、项目边界、用例及参与者与用例的关系这四个步骤确定用例图。此阶段主要完成用例图。细化阶段的目标是分析问题领域，在开始阶段的基础上，收集更详细的系统需求，建立健全的体系结构基础，制定项目计划，除去已知的高风险元素。此阶段主要包括计划，分析和结构设计。细化阶段需要完成初期评估，审查用例质量和风险调查。类图反应的是对象之间的抽象关系，如幻化、关联和聚合等，建立类图是细化阶段最重要的工作。生成类的三个步骤：（1）识别类；（2）确定类的属性和操作；（3）确定类之间的关系。
细化阶段完成的图主要有包图、类图、活动图、对象图、顺序图、状态图和协作图。在构建阶段中，所有剩余的构件和应用程序功能被开发并集成为产品，所有的功能被详细测试。构建阶段后期，需要配置系统运行的软硬件环境，这其中硬件环境可用配置图来表示。移交阶段是将设计完成的软件产品交给用户，接受用户的测试，提交用户手册，进行用户培训等，确保软件对最终用户是可用的。移交阶段可能是跨越了几次迭代，软件需求规范及用UML表示的用例图、类图、组件图和配置图要及时更新，保证软件和模型同步。
（二）面向对象的UML的建模
面向对象的UML建模过程主要包含了解需求、分析、设计、实现、测试和配置。首先进行业务流程建模，主要是为了评估系统、理解需求及系统将要解决的问题。其次需求分析，主要是用例模型的定义，采集和评价系统的需求。在这个过程中需要了解各角色间的关系以便进行系统设计及实现时减少盲目性，这一过程要注意对象和类的定义以及领域分析。然后进行的是系统分析与设计，设计分为框架设计和详细设计。系统分析与设计的结果是产生一个对象模型，即设计模式。最后进行的是实现，可运用Rational Rose或其他软件提供的平台分析前面所设计的图，再转化为自己熟悉的高级语言，这样可以看到UML把图转换成系统的程序设计结构的框架，并且系统扩张时仅需更改前两步的设计图，改变程序的框架，从而彻底改变传统设计所带来的复杂性和潜在的危险性。在系统测试的时候也可运用UML将系统划分为多个单元，将每个单元作为一个整块，分别对它们进行测试，再将测试结果返回到设计实现中进行分析。可以看出在整个系统设计的全过程，运用UML减少了系统设计的复杂性与盲目性，提高了设计效率。
三、结束语
UML作为一种面向对象的标准化的统一建模语言在系统开发中是非常重要的，特别是对于联系复杂，结构庞大的系统来说，利用基于UML的可视化建模软件工具，按照RUP的要求方便的管理项目需求、使基于组件的框架、验证软件质量、控制版本更新，从而实现整个软件系统的面向对象分析、设计与迭代。
参考文献：
[1]Booch G，Rumbaugh J，Jacobson I.UML用户指南（第2版）[M].北京：人民邮电出版社，2006.
[2]刘芳.UML语言及实际中建模的应用[D].山东科技大学，2003.
[3]成茜.ERP人力资源管理系统在企业中的应用[J].企业导报，2013（07）：215-216.
教学管理系统UML用例建模方法 第3篇
一、用例 (Use Case) 概念
用例 (Use Case) 的概念是Jacobson在1992年首先提出的。此后在Firesmith和Booch等几种软件开发方法中对于确切地描述用户需求中的功能需求;帮助发现系统中应设立哪些对象;核实每种功能需求是否有相应的对象予以满足等, 都起到了很好的促进作用, 因此受到人们的重视和好评。
二、系统需求分析
需求分析是系统开发中的一个重要步骤, 是整个系统开发的基础。需求分析的结果将直接影响到整个软件工程的成功与失败。如果需求定义错误 (如需求不完全、不合乎逻辑、不贴切或使人易于发生误解) , 那么不论以后的工作质量如何, 都必然导致系统开发的失败。大量实践证明, 信息系统产生的许多错误都是由于需求定义不准确或错误导致的。而且, 如果在需求定义阶段发生错误, 修改这些错误的代价是非常高的。因此, 信息系统开发中需求分析是系统成功的关键一步, 必须引起足够的重视。只有在正确的需求分析基础之上, 才能顺利完成系统的设计与实现工作。
三、用例 (Use Case) 建模
教学管理系统功能设计利用UML方法完成, 通过用例图描述了系统的主要功能及其使用的对象。
创建用例模型的工作包括:确定活动者和用例、描述用例、定义用例间的关系、最后确认模型。用例模型由用例图组成, 用例图展示了活动者、用例以及它们之间的关系。在创建用例模型时, 用户与开发者之间的积极合作和交流是十分重要的, 用户的参与使模型能够反映出用户所希望的细节, 并以用户的语言和术语来描述用例等。
USE CASE图可以按下列步骤建立:
1. 定义活动者。
活动者 (Actor) 是用户作用于系统的一个角色 (Role) 。活动者有自己的目标, 并且通过与系统的交互达到目标。
2. 定义USE CASE。
USE CASE本身是用户或其他系统与正在设计的系统的一个交互, 每一个USE CASE都是一个活动者与系统在交互中执行的有关事物序列。应当根据系统的需求找出全部的USE CASE, 并从活动者的角度给出事件流。当USE CASE执行时, 系统应提供给活动者服务。
3. 绘制USE CASE图。
USE CASE图是系统的外部行为视图。在确定了活动者和USE CASE的基础上绘制USE CASE图, 可以更清楚地了解系统的行为。绘制USE CASE图应先从顶层抽象开始, 然后逐步分解、精细化USE CASE图, 直到能清晰地表达问题、满足系统分析与建立模型的需要为止。基于前面的分析过程, 在此绘制了系统顶层用例图, 如图1所示。
四、结束语
UML课程教学方法的探索与实践 第4篇
UML作为一种面向对象的建模语言, 已经成为面向对象软件系统分析设计的必备工具。越来越多的软件设计开发人员使用UML, 很多高校也开设了UML课程。然而, 笔者在教学过程中发现学生在学习了UML的各种符号、图形等基础知识后, 真正涉及到一个完整真实的案例时, 却茫然的无从下手, 导致课程学习难以与软件开发过程有效的结合起来。因此如何有效改进课程的教学效果是许多教师都在思考的问题, 下面结合自身的教学经验, 从案例教学、团队合作、交流讨论三个方面进行了探讨。
2、案例教学
案例教学是指对于工学结合的课程, 教师使用案例进行教学。其中案例是由教师课前, 根据一定的教学目的, 精心编写的或挑选的、与实践相关的、具有代表性的典型案例, 在课堂上组织学生进行分析和讨论, 然后由教师对其进行归纳总结等教学程序来实现教学目标的一种教学方式[1]。选择的案例难易程度要适中, 应与课程大纲相一致, 确保不会脱离课程教学的基本要求, 并且能覆盖课程主要教学内容。结合教学目标与培养方案, 选取贴近学生学习生活的“学生信息管理系统”作为贯穿UML课程的教学案例, 可以调动学生学习的积极性和主动性, 使他们能够积极主动地参与到整个教学活动过程中。
在实际教学中, 以“学生信息管理系统”作为教学案例来组织整个教学过程。UML作为一种可视化的建模语言, 其主要表现形式就是将模型进行图形化表示。针对UML每一种图的讲授均通过图的基本概念, 图的组成, 图的创建概述, 图的创建示例这四个方面进行。而具体到每一种图的创建时, 都是围绕“学生信息管理系统”来展开的, 始终基于该需求层层推进, 从系统分析、设计到实现, 从用例视图、静态视图到动态视图。基于案例教学, 使生硬的理论概念活了起来, 使学生在整个课程学习中思路变得清晰起来, 对系统的理解变得自然而通透。
3、团队合作
在案例教学的基础上进一步开拓学生的思维, 提高他们分析问题和解决问题的能力, 实施了团队合作。团队合作指的是一群有能力, 有信念的人在特定的团队中, 为了一个共同的目标相互支持合作奋斗的过程。团队合作的目的在于发展学生运用与课程相关的知识, 充分的与团队中的其他成员交流, 通力合作共同解决问题的能力。
在课程基础章节学习完毕后进行了UML课程设计, 将学生分成多个4~6人的小组团队, 使教学的基本单位由个体的学生扩展为分组的学习团队, 团队中的每位成员都赋予了各自的角色;要求各个团队自选一个不同的题目, 将前面介绍的UML各种图形以及模型元素综合起来, 以书面报告的形式形成一个具体的系统建模, 并用ROSE画出该系统的用例图、类图、时序图、协作图、状态图、活动图、组件图和部署图, 以完整体验使用UML对面向对象的系统进行分析、设计的全过程。将团队合作引入到实际教学中, 教师主要提出具体任务和要求, 并对如何完成这一任务作一些启发性的提问和方法上的阐述, 充分调动学生的好奇心, 有效地激发了他们的学习兴趣、创造力以及协作精神。最关键的是使学生在面临一个新的任务时不再茫然, 他们知道从哪里入手, 从哪些方面展开, 积极参与到知识、问题和任务的讨论中。经过一段时间的探索与磨合后, 同学们都认识到个人的能力和思维是有限的, 应该多借助团队的力量, 学习别人的优点和长处, 学会站在不同的角度看待问题。同学们也都体会到自主探索的乐趣, 团队合作的成就感, 并能针对出现的问题提出相应的解决方案。一改以往教师主讲, 学生被动听课的状态, 真正实施了以学生为主体, 教师为主导的教学模式, 大大提高了UML课程的教学效果。
4、交流讨论
每个团队最终以书面报告的形式展示任务的完成情况, 并将主要信息做成演示文稿。在课堂上由教师组织每个团队在规定的时间内由组长讲述, 相关成员补充, 其它团队进行挑错评议, 引导学生推进讨论, 集思广益, 开拓思路, 各抒己见, 让他们从不同的角度看待系统, 讨论问题。以学生讨论为主, 教师点评为辅, 尽可能针对一些大家都存在的共性问题展开讨论, 让学生在思路上得到进一步拓展和启发。通过讨论, 一方面可以使学生学习彼此的优点, 看其它同学是如何完成任务的, 在方法上和自己有什么不同且优于自己的地方;另一方面大家共同找不足, 发现存在的问题, 通过交流一起探讨改进意见和解决方法。
在这一阶段, 教师的任务并不是使学生接受特定的解决方法, 而是倾听学生的意见并教他们如何自己去判断问题、分析问题。教师的主要作用是提出疑问, 引起争论, 鼓励分析, 推进讨论。教师要帮助学生学会评价自己及他人的见解, 为学生提供讨论的方向与机会, 处理学生在讨论中的各种情绪反应等[2]。
最后由教师结合学过的理论知识针对出现的问题进行归纳总结。通过学生的交流讨论教师进行查漏补缺, 讲解一些共同的难点问题, 并给出相应实例, 进一步加深学生对所学知识的理解和综合运用, 有效提高了UML课程的教学质量, 取得了良好的教学效果。
5、结束语
在实际UML教学中, 笔者在基础章节采用案例教学, 在整个课程后期通过团队合作完成课程设计, 最后组织学生交流讨论, 针对出现的问题进行归纳总结, 收到了良好的教学效果。这些都来源于实际教学工作中的一些经验性的总结, 希望对该课程的开展起到一定的借鉴作用。
参考文献
[1]毛伟芳.案例教学在职教中的运用[J].保山师专学报, 2004, 22 (6) :77.
基于UML的测试用例生成方法研究 第5篇
UML所具有的特性决定了它不仅适合于对面向对象软件进行分析与设计的建模,同时它也可以作为测试的依据。目前,UML仍处于不断发展与完善之中,基于UML的测试用例生成技术还处于起步阶段,需要对其进行深入研究。
1 研究工作背景
软件测试可以通过两种方法实现:基于代码的测试与基于规格说明的测试。前一种方法是通过代码导出测试用例;后一种方法是通过规格说明导出测试用例。基于UML模型的软件测试是一种新兴的软件测试方法,属于基于规格说明测试的一个分支。UML由于其定义良好、易于表达、功能强大,融入了软件工程领域的新思想、新方法和新技术,现已应用于从需求分析开始的面向对象软件开发的全过程,因此UML自然成为了测试用例生成的有效信息来源。国内外多所大学和研究所都在进行这方面的研究,可以看出,基于UML的测试将成为软件测试的发展趋势和主流。
基于UML的测试用例生成方法需要借鉴许多传统的测试用例生成方法,所以有必要先对一些传统的测试用例生成方法作一些介绍:
(1) 判定表法 判定表是分析和表达多种逻辑条件下执行不同操作情况的工具。通过填写条件桩、动作桩、条件项、动作项和简化项建立判定表,然后生成测试用例。目前很多测试方法都是以转换为判定表为目标,因为判定表这种结构能够保障我们考虑了所有可能的条件组合。如果使用判定表标识测试用例,那么判定表的这种完备性能够保证一种完备的测试。但是使用判定表法其前提条件是测试系统的规格说明能以判定表形式给出,或者很容易转换为判定表,这就限制了其使用的范围,而且其生成的测试用例组合的数字往往过于庞大。
(2) 场景法 现在的软件设计几乎都是由事件触发来控制流程的,而同一事件不同的触发顺序形成事件流,不同的事件流便形成了不同的场景。这种软件设计的思想也被引入到软件测试中,测试用例都是依据场景来生成的,这有利于测试用例覆盖系统所有可能的执行流程,同时使测试用例更容易理解和执行。但是场景法其基本流和备选流通常是基于文字说明的,很抽象、很难理解,而且该方法中没有给出如何从基本流和备选流中确定用例场景以及考虑事件流程出现环路如何处理的问题。
2 基于UML测试用例生成的方法
与判定表法、场景法等传统的测试用例生成方法所基于的规格说明相比,UML中的模型更为形象,更适合对系统进行描述。不过各种传统的测试用例生成方法已十分规范严格,也各有其自身的优点。所以基于UML的测试用例生成方法应充分利用各种传统的测试用例生成方法的优点。在前期的研究中,研究者多单独基于一种UML模型来生成测试用例,很少综合运用多个UML模型中的测试信息。本文将介绍一种方法,该方法基于UML用例图、活动图,并与传统测试用例生成方法很好地结合起来生成测试用例。
本文所介绍的基于UML的测试用例生成方法是属于系统测试阶段的测试用例生成方法,针对系统中的软件这一部分进行测试,其主要步骤如图1所示。
2.1 创建用例依赖序列
首先,我们依据UML用例图创建用例依赖序列。这一步骤的需求信息是UML用例图,输出信息是角色相关的用例依赖序列。这一步骤的目的是使测试能覆盖系统所有可能的执行流程,以此来覆盖系统所有的模块和功能。具体步骤如下:
(1) 系统中每个角色相关的用例都需要确定它们相互之间的顺序依赖关系,我们使用活动图规范和形象地描述这种依赖关系,在这种依赖关系活动图中,活动点表示用例,而有向边表示用例之间的顺序依赖关系。这种依赖关系依据用例执行的时间顺序关系,也就是说有向边开始的用例执行时间在结束用例之前,但开始用例执行后结束用例也可不执行。此外,为了表示用例执行的并行性,需要通过同步开始点和同步结束点来表示;
(2) 将用例依赖关系活动图转换为有向图,转换过程中,需要把同步开始点和同步结束点变成常规的边;
(3) 深度优先搜索有向图得到所有系统执行流程。在深度优先搜索有向图时,需要考虑循环流程的问题,对于循环的流程必须加以限制(通常按照系统特定需求加以限制)从而使流程数目变成有限。
2.2 对每条流程用活动图进行描述
在得到系统所有的执行流程后,我们对每条流程用活动图进行描述。这一步骤的需求信息是上一步骤生成的系统所有的执行流程,输出信息是系统执行流程的活动图。这一步骤我们使用UML活动图来描述流程的原因是:基于活动图比起基于文字说明可更加形象、清晰地生成测试场景。
2.3 建立测试场景
在得到系统所有执行流程的活动图后,我们由活动图生成测试场景。这一步骤的需求信息是上一步骤生成的系统执行流程的活动图,输出信息是测试场景。这一步骤的目的是把系统分为多个场景来描述,然后我们可逐一把测试针对某一场景来进行,这就利用到了场景法中的优点,使测试用例更容易理解和执行。具体步骤如下:
(1) 由上面生成的流程活动图当中获取流程基本流和备选流。在活动图中,基本流即是从上到下直线下来的活动,而备选流则是循环的返回或者跳过基本流的活动;
(2) 基本流和每个备选流可以各自对应一个场景,这些是最基本最简单的测试场景;
(3) 组合备选流以建立测试场景。想对所有的备选流组合建立场景是不现实的,假设有7条备选流,那么将有27=128备选流组合,需要建立128个场景,显然,描述这些所有的场景是不现实的。因此,我们应该选择若干合理的备选流组合。选择备选流组合建立场景的原则是,两个备选流在活动图上相隔很近,相互影响,相关性较强,则这两个备选流可组合建立测试场景;
(4) 对于循环的备选流,特别是无限循环备选流,产生的场景将是无限多个。对此我们将采取一种有效的方法对其进行处理,即假设程序执行了循环备选流两次,程序就已经执行了整个循环实例。
2.4 生成测试用例
在得到所有的测试场景后,我们对每个测试场景借鉴判定表生成测试用例。这一步骤的需求信息是上一步骤生成的测试场景,输出信息是最终的测试用例。这一步骤我们借鉴了判定表法的目的是保证测试用例的完备性。具体步骤如下:
(1) 从场景的每个步骤中找出变量。我们可利用系统需求分析阶段,UML建模过程中形成的数据字典和对象约束语言OCL(object constraint language)来找出每个步骤的输入变量;
(2) 数据字典和OCL中有对这些变量取值的详细约束,我们可根据边界值法和等价类划分法的有关思想对这些变量的约束条件进行划分,最后形成对每个变量的显著不同的测试选项;
(3) 组合不同的测试选项生成测试用例。不同的测试场景所需的测试选项也有所不同,应该选取不会使测试场景发生转换的测试选项来进行组合。具体的测试选项组合过程是,创建第一个测试用例时,可以选择组合任意测试选项。创建第二个测试用例时,从选项中选出在第一个测试用例中没有使用过的测试选项,并进行组合。然后继续添加测试用例直到所有的测试选项都被覆盖到为止;
(4) 用真实的数据值分别替换测试用例中的每个变量的选项就可生成最终的测试用例。
3 基于UML测试用例生成的实例
下面我们将结合一个实例来验证该基于UML测试用例生成方法的可行性。该实例为公司薪资系统,其用例图如图2所示。
对于薪资管理系统中的财务角色,其用例依赖关系活动图如图3所示。
图3的活动图转换为有向图后如图4所示。其中S表示同步开始点,E表示同步结束点,A表示添加职员用例,D表示删除职员用例,Q表示查询职员用例,M表示修改职员基本信息用例,C表示计算职员本月工资用例。
在此我们限制循环次数最多为2次。搜索有向图4的全部可能流程,用树的方式表示出来,如图5所示。
在此我们选取有向树图5的流程SADE,在参照添加用户、删除用户用例的活动图的基础上,我们可通过如图6所示的活动图对该流程进行描述。
我们把图6的基本流和备选流以表1的形式描述。
由表1我们可得到场景M(main,基本流)、B1、B2、B3、B4、B5、B6、B7,由表1的备选流组合可建立以下几个场景:B1B2、B3B4、B5B6B7,因表1的B1、B2、B3、B4、B5、B6、B7都是循环备选流,所以我们应增加场景B1B1、B2B2、B3B3、B4B4、B5B5、B6B6、B7B7。
我们对表1所表示的基本流和备选流可建立如表2的测试场景。
在此我们选取场景1来进行下面的步骤,对于表2的测试场景1,我们可用表3描述场景1中变量的不同测试选项。
背景为灰色的测试选项为场景1中所需要的测试选项,得到测试选项后,对于表2的测试场景1我们可建立如表4的测试用例矩阵。
对于表4的测试用例矩阵中的测试用例1,可以通过变量赋值生成表5。
表5就是最终生成的测试用例,然后我们就可以基于表5进行测试了。
4 基于UML测试用例生成的实例结果分析
结合实例,我们可总结该基于UML测试用例生成方法相对于其它的测试用例生成方法,有以下优点:
(1) 系统许多错误与系统的执行流程有关,测试要按照某一个流程执行才能发现这些错误。实例中如图5所示的有向树覆盖了系统所有可能的执行流程,有利于测试用例覆盖这些错误;
(2) 图6的流程活动图是由用例活动图按顺序组合生成的,由于这些用例活动图在需求分析阶段已建立好,可直接复用,这就简化了测试过程,节约了测试成本。同样的,表3的测试选项信息也是由已建立好的数据字典和OCL中导出的。测试信息可由分析设计模型中直接导出,这也是基于UML测试的最大优势;
(3) 场景法中没有给出如何从基本流和备选流中确定用例场景以及考虑事件流程出现环路如何处理的问题,该方法改进了场景法这一问题,生成了如表2所示的测试场景;
(4) 我们在得到测试场景后再使用判定表,这就使判定表的规格说明集中于一个场景范围,同一场景范围的规格说明很容易转换为判定表,而且同一个场景范围的测试用例的动作结果都是一致的,这就简化了测试用例组合的复杂度和数目。这样我们就解决了判定表法使用范围的限制和测试用例组合数字过于庞大这两个问题。
5 结 论
由于面向对象软件系统的规格说明多数使用UML模型表达,而且UML模型中包含了大量可以用于软件测试的信息,因此基于UML的软件测试将是以后基于模型软件测试研究的重点。由上述实例可看出,本文介绍的基于UML的测试用例生成方法充分运用了UML模型在测试用例生成方法方面的信息和能力,节约了测试成本,使得测试用例生成方法过程更加规范、简洁,同时该方法结合并改进了场景法和判定表法的优点,使整个测试过程更加易于理解和执行,并且保证了测试的完备性。
本文提出的基于UML模型的测试用例生成方法还存在如下缺点,需要在下一步工作中对其进行改进:
(1) 首先使用该方法的测试人员需要具备一定的理论基础,如等价类划分法、边界值法、场景法、判定表法的知识,还要掌握相关使用方法,这就导致该方法自动化程度和通用程度不高,而且使用该方法还需要一定的前期投入,如软件用例功能的划分、流程活动图的构造等。在下一步工作中我们需要对该方法的形式化过程进行改良,使其测试过程更加规范、易行;
(2) 该方法对测试失效辨识能力不强,仅仅根据UML模型中的内容来建立预期测试结果,以后应该多借鉴其它测试方法在失效辨识方面取得的成果,提高该方法失效辨识能力。
摘要：基于模型的软件测试是由软件需求分析模型与设计模型中生成一套测试用例的技术。随着基于UML模型的软件开发与RUP(Rational Unified Process)开发过程的广泛应用,基于UML模型的软件测试逐渐成为基于模型软件测试的主要研究方向。结合UML模型中的测试信息,结合并改进了传统的测试用例生成方法,如场景法、判定表法等,提出了一套较合理的基于UML的测试用例生成方法,使得基于UML的测试用例生成方法的流程更加规范,更加易于生成满足很高覆盖要求的测试用例,并运用实例对其进行了验证。
关键词：场景法,判定表法表,基于UML的测试用例生成
参考文献
[1]RON Patton.Software testing[M].China Machine Press,2006.
[2]徐宏喆,陈建明,张昊翔,等.UML自动化测试技术[M].西安交通大学出版社,2006.
[3]莫斯里.软件测试自动化[M].邓波,等译.机械工业出版社,2003,10.
[4]谢棠棠,张为群.一种基于UML模型的系统测试方法[J].西南师范大学学报:自然科学版,2005,30(2):259 -263.
[5]JAMES Rumbaugh,等.UML参考手册[M].姚淑珍,等译.机械工业出版社.
[6]蔡敏,徐慧慧,黄炳强.UML基础与Rose建模教程[M].人民邮电出版社,2006.
[7]云倩,李臻,陈萱.软件质量工程师手册[M].中国标准出版社,2005.
[8]李正海.软件质量保证技术[M].上海交通大学出版社,2006.
UML方法 第6篇
在系统需求分析过程中, 分析建模是很重要的阶段, 主要使用一种符合需求分析原则的符号体系来建立一组模型, 包括创建描述信息内容和信息流模型, 划分系统, 建立各个系统的功能模型和行为模型, 描述关键要素。常规分析建模可细分为结构化分析和面向对象分析两种方法, 其中结构化分析方法可能产生解释错误、信息含糊等问题, 因此目前大多采用面向对象分析方法进行分析建模。
1 UML 的建模流程
1.1 UML 的符号系统
UML的建模语言以图形为主进行系统分析, 实现可视化建模。常用的图形有:用例图、静态图、行为图和交互图[1]。
1.2 UML 的建模流程
1.2.1 利用用例模型建立系统功能模型
在需求分析初期, UML将用户需要就系统单次交互过程中所实施的一组行为的相关动作序列提出一个用例, 并汇总各类用例行程一个集合, 建立用例模型, 以此确定待开发系统功能, 具体包括用户与各用例之间关系、用例与用例之间包含扩展关系等等。客户描述用例的过程, 就是明确系统功能的过程。
1.2.2 利用静态模型建立系统功能模型
UML静态模型主要描述系统内部静态结构可视图, 以用例模型为基础, 确定用例内部及相互之间依赖、关联和聚合等关系及整体功能范围对其提出的约束和限定, 最后在粗略的静态系统模型框架内逐步细化各功能需求。
1.2.3 利用动态模型机制建立系统行为模型
UML动态模型主要用于描述对象间作用关系和信息交换关系。其中状态图主要描述控制信息即外部事件导致系统将采取怎样的动作方式, 描述各种系统行为模式以及各行为状态之间的变迁方式;序列图主要描述系统对象间交互动态关系, 可显示对象间信息发送顺序和对象间交互关系两方面内容[2]。
2 基于 UML 的网络安全体系建模分析方法
网络安全系统是基于安全管理和安全技术的集攻击、防范、检测、控制、管理和评估于一体的系统工程[3]。目前安全体系设计的主要问题是结构框架比较抽象, 歧义问题较多, 因此统一建模语言UML是适用于网络安全体系建模的较好选择。
2.1 安全目标建模
安全目标ST可从业务功能、业务范围和业务流程等入手建模, 定义ST是二元组ST=
业务功能BF表示网络可以实现特定目的的能力, 适合用用例图进行刻画。
BF为四元组BF=
业务范围BS表示业务功能所达到的广度, 适合用类图进行刻画。
BS为二元组BS=
业务流程BP表示业务执行过程, 适合用活动图进行刻画。
BP为九元组BP=
2.2 安全边界建模
安全边界SB可从物理联通边界和安全措施边界入手建模, 定义SB是二元组SB=
连通边界LNB表示网络资产要素及要素间在物理逻辑连通方面的关系。LNB=
安全措施SMB表示网络中各类技术、管理措施的限定边界。SMB=
2.3 安全体系要素建模
安全体系要素可从安全机制和安全威胁两方面入手建模。
安全机制STR可定义为七元组STR=
安全威胁ST是可定义为五元组ST=
3 结束语
基于网络安全系统设计的发展现状, UML成为网络安全系统设计中的首选建模模式。在具体的网络安全系统设计中, 可从安全目标、安全边界和安全体系要素三个方面入手建模, 以充分发挥UML的可视化、直观性等优势。
参考文献
[1]布宁, 刘玉岭, 连一峰, 黄亮.一种基于UML的网络安全体系建模分析方法[J].计算机研究与发展, 2014, 07:1578-1593.
[2]杜芸.网络安全体系及其构建研究[J].软件导刊, 2013, 05:137-139.
[3]王亚东.浅析网络安全体系设计与建设的研究[J].科技风, 2012, 18:49.
UML方法 第7篇
开发软件系统的工作首先便是获取系统需求并进行需求分析, 需求分析是软件开发生命周期的第一个阶段, 它贯穿于整个开发生命周期, 是软件系统开发中的关键问题。但至今需求分析仍是软件系统开发中最复杂、最困难的过程之一。表现在1.需求获取困难。软件需求获取中缺乏领域知识的问题常常是模糊的、不精确的, 而需求获取及分析偏向创造性思维活动, 其过程让第三者难以理解;2.需求分析不完整。是软件开发失败的主要原因之一;3.需求建模较复杂。在软件需求中混杂着各种各样的需求, 功能性需求与非功能性需求错综复杂的联系, 以及当前对非功能需求分析建模技术的缺乏都大大增加了需求建模的复杂性。如何有效地分析客户需求并映射到系统设计开发过程, 实现系统需求的跟踪管理和控制, 是软件系统开发中的重要课题。
针对需求分析中存在的困难, 提出了一种基于U M L的Q F D需求定量分析方法, 把U M L用例建模应用到软件需求分析中, 用作为需求获取和分析过程可视化, 以及建立可视化模型的工具, 利用QFD客观地使需求项目层次化, 可视化和充分化, 从而降低需求建模的复杂性。同时给出一个需求分析框架, 使该方法具有较强的可操作性。
二、U M L需求建模
UML (Unified Modeling Language) 是一种通用的可视化建模语言, 它支持从需求分析开始的软件系统开发的全过程。在软件系统需求分析中可通过用例图对系统的需求进行分析建模。UML作为一种强大的图形化建模语言, 是理想的需求描述和建模分析工具, 对大规模的、复杂的、不断变化的用户需求有着很强的控制力。
用例 (USE CASE) 是系统执行的一系列动作, 通过这些动作能获得对参与者 (Actor, 包括客户、用户和开发人员等) 有价值的结果。
1. 用例与需求的关系。
用例体现参与者需要系统完成何种操作, 强调实现用户的真正目标, 以一种简单而有效的方式表达系统的行为, 更体现系统对用户的价值, 把需求书写者的注意力从程序员关心的系统功能列表, 回到用户需求上。
需求分为业务需求、用户需求、软件需求三个层次, 如图1所示。需求工程应该从上向下, 从宏观到微观, 且循环迭代补充完整。
在UML中, 软件需求定义为“系统所需的特性、属性或行为”。软件需求就是系统必须遵循的条件和所具备功能的陈述, 它们都是可以观察的外部系统行为规范, 它表明了用户或者另一系统要求调用系统必须完成的工作, 因此这些需求必须是详细且明确的, 同时软件的需求又可以明确地指导系统的实现和测试工作。
用例图关注的是系统功能高层次的形状, 而不关注系统的具体实现方法, 它着重从用户的角度描述系统功能, 适用于系统的需求分析阶段, 是系统的核心, 驱动着其他模型的开发。
系统所有的参与者和所有用例组成用例模型, 用例模型帮助参与者在如何使用系统方面达成共识, 参与者在与用例进行交互时使用系统。一张用例图描述部分用例模型, 显示带有关联关系的用例和参与者的集合。用例建模得到的功能需求明确规定了参与者执行的特定任务, 使用户能清晰看到系统提供的有价值操作, 有效地降低待开发系统的复杂度, 帮助人们理解复杂的问题。
2. 使用用例进行需求分析。
在软件需求分析过程中, 需求一般可以分为两类:功能需求和非功能需求。功能需求是系统必须能够实现的系统行为, 而不需要在条件中加入物理约束, 它指定了系统的输入和输出行为;非功能性需求指定了了系统必须具有的其他性质, 描述的是系统的特征或者系统的环境特征。
在使用UML进行需求建模时, 通过用例图从用户目标和系统交互功能两方面来分析。在软件系统开发的过程中, 客户先给了项目组《用户需求书》, 其中描述了业务需求和用户需求, 主要内容是用户希望的系统功能, 然后由需求小组进行需求获取和需求分析。用例将软件需求放在环境中, 将功能性需求放入实际操作的用户环境中, 当系统与用户或其他系统交互时, 可以描述系统的行为。
(1) 用例的提取。通过《用户需求书》, 对领域内的相关词法进行分析, 将用户和客户的需要作为需求, 筛选出有效的备选需求, 将功能性需求表示为用例模型中的用例, 其他的需求放到一个单独的列表中, 以待在质量功能展开时进行分析, 同时对用例图中的用例进行语义描述。
(2) 建立需求用例模型。用例模型是所有用于描述指定系统的用例、参与者和用例参与者关联关系的组合。在UML中用例模型是这样定义的:用例模型可用于描述系统的功能性需求或者用例的其他分类。在软件开发过程中, 使用模型对现实进行简化、概括, 从而可以加强对真实构建系统的理解。
通过用例描述发现用例之间的关系, 在用例图中描述出来建立用例模型, 对用例之间的关系进行可视化的描述, 使用户和领域专家能够更好地对系统的需求分析及其建模结果进行审评, 及早发现需求的不足, 减少系统开发的风险。
3. 质量功能展开需求分析。
通过UML可视化地表达系统需求的发现与描述, 克服了系统需求分析中纯文字性说明的不足之处, 体现了直观、规范、易交流等优点, 这是需求表达的一种有效手段。在需求分析阶段, 还有一个关键的工作在于怎样尽力降低初始阶段的开发费用, 加快初始阶段的开发进度。但在系统分析人员缺少相关的领域知识, 不熟悉其业务流程的情况下, 提取需求、精确描述需求之间关系、对于需求用例的优先级控制、性能性需求和技术特性需求等问题难以解决。
质量功能展开QFD (Quality Function Deployment) 模型也是针对软件系统开发周期各阶段而建立的模型, 特别是可对需求和技术特性进行定量需求分析。在系统需求分析中, Q F D以用户的需求为输入, 采用关系矩阵的方法对用户需求加以描述、迭代展开, 将用户需求与技术特性、用户需求的重要性与竞争性联系起来, 并把用户的需求转化为技术特性、构件接口和体系框架, 从而提高系统需求获取质量和需求分析质量, 为从需求到设计的映射打下了好的基础。
质量屋HOQ (House of Quality) 的概念是由美国学者J.R.Hauser和Don Clausing在1988年提出的。质量屋是由一个输入到个输出的转换过程, 它提供了一种将用户需求转化成为技术特性, 并配置到建造过程中去的结构方法。QFD采用HOQ建立用户需求和功能特性之间的相互联系, 针对需求抽取困难的问题, 把QFD应用到系统需求管理中, 质量屋矩阵可用作需求获取和分析过程可视化, 及构造可视化模型的工具。质量屋的基本结构如图2所示。
一个完整的质量屋包括6个部分: (1) 用户需求及重要度:确定了什么才是用户最需要的; (2) 技术特性:在需求分析时, 由系统项目组根据用户需求来提取出满足这些需求的技术特性; (3) 关系矩阵:描述了用户需求和技术特性之间的关系程度; (4) 竞争分析:站在用户的角度, 对本软件系统在满足用户需求方面进行评估, 以确定本系统的竞争优势和劣势以寻找突破性的改进方向和领域; (5) 技术评估:技术评估包括技术特性的权重、竞争性评估和设计质量; (6) 关联矩阵:表示出了各技术特性之间相互支持或阻碍的关系。
经过反复的质量功能展开, H O Q阵逐渐被整理成层次化结构形式, 而软件需求和数据项目也被同时并列地层次化。H O Q矩阵的层次与需求项目的层次相对应, 反映了需求的一次水平、二次水平、三次水平等层次关系, 并通过技术评估检验需求是否满足要求。
4. 基于UML的QFD软件系统需求定量分析过程。
基于已建立的初始用例模型, 由于领域业务、需求变化的因素可能导致需求分析的演化, 即在现有需求分析的基础上进行下一遍的需求分析及建模。基于不同领域知识互补的必要性, 以演化的观点来考虑系统的需求分析, 项目经理应与参与者共同分析。不同类型的参与者在需求分析建模过程中, 从不同的层次、不同的角度分析系统的需求, 并通过UML表示出需求。如, 需求分析人员主要考虑系统范围的设定;构架设计师必需处理关键和重大的风险, 确认那些制定构架计划所需要的用例。经过QFD展开分析定量确定用例的优先级, 对于本阶段的目标是无关紧要的用例, 只投入少量的精力, 同时检验分析的需求是否足够地满足用户的需求。
需求分析及建模需要经过多次反复才能完成, 系统需求分析包括提炼、分析和仔细审查已收集到的需求, 以确保所有的风险承担者都明白其含义并找出其中的错误、遗漏或其他不足的地方。基于UML的QFD软件系统需求定量分析过程包括以下的循环过程:
(1) 对领域内的相关词法进行分析, 筛选出有效的备选需求;
(2) 将功能性需求表示为用例;
(3) 建立需求用例模型;
(4) 列出用例模型中的功能需求和用户的性能需求;
(5) 对每一个需求尽可能量化应该做的工作;
(6) 列出用户需求与技术特性之间的关系;
(7) 对需求的重要性进行排序, 并给出评分;
(8) 需求评审, 对技术特性相对重要度较低的需求重复上述过程进行修正。
基于UML的QFD软件系统需求定量分析模型如图3所示。
用例作为新的需求分析技术, 但若项目组对用例的划分、用例的描述、用例与用例之间的关系把握不好, 仍会造成项目的失败。所以在实际工作中, 建立用例模型后, 为了保证获取正确的需求, 应采用关系矩阵的方法加以描述、迭代展开, 从而提高需求分析的质量, 保证对用例的一致理解, 最终获取需求的成功。
本文提出的基于UML的QFD需求定量分析方法已用于通用多媒体播放器的界面设计、超市管理系统的需求分析及中小企业ERP实施规划中, 收到了很好的效果。
摘要：在对软件系统进行UML需求分析的基础上, 以质量功能展开中的质量屋系列矩阵为主线, 提出了一种基于UML的QFD需求定量分析方法, 对需求的优先级和技术特性需求的重要度进行定量分析, 其有效性在实践中得到了验证。
关键词：UML,QFD,需求分析
参考文献
[1]熊伟新藤久和渡边喜道:软件需求定量分析及其映射的模糊层次分析法[J].软件学报.Vol.16, No.3, 2005, 16 (3) 427～433
[2]黄雨田聂丽琴段富何华军:用例需求分析技术的应用[J].太原理工大学学报.Vol.36, No.2, 2005 (3) 24～27
[3]闫健恩王翠华林建秋王俊义:用例建模在软件需求分析中的应用[J].内蒙古大学学报 (自然科学版) Vol.38No.5, 2007 (9) 578～581
[4]刘渝妍赵卿陈媛:基于UML的老年人口生活质量指标体系框架模型设计[J].重庆工学院学报.2005 (10) :20～25
[5]王敏:基于UML的快速原型方法的研究和实现-推理快速生成法IFBM[J].华东师范大学硕士论文2005 (10)
[6]刘渝妍杨永发:基于SQFD的软件需求分析技术[J].计算机应用研究增刊2007
[7]邵家骏:质量功能展开[M].北京:机械工业出版社.2004
[8]刘渝妍:基于质量屋的人机界面设计[J].昆明大学学报, 2006 (4)
UML方法 第8篇
关键词 UML 信息系统 分析 设计
中图分类号：TP3 文献标识码：A
0前言
现今，各行各业在发展过程中，需要处理的信息逐渐增多，由此推动了计算机信息管理系统的应用，利用计算机信息管理系统有很多的好处，最大的好处就是便于管理信息，提高了工作的效率及信息保护的安全性。图书馆包含大量的书籍资料，而且会有许多的用户来频繁的借书、还书，这使得图书馆需管理的信息大量增加。尽管大部分的图书馆都采用了计算机信息管理系统，但是仍然处于初始阶段，未真正的发挥信息系统的作用，因此，有了基于UML的信息系统分析与设计。
1UML的组成及建模机制
UML的组成：UML是一种建模语言，需要面向对象来进行，在软件系统中应用UML，可以帮助用户对对象进行描述和建模，而且从软件开发开始，直到软件系统最终的测试，都可以利用UML来进行描述。UML主要由四大部分组成，分别为：视图，非图形，由多个图构成，在一个系统中分为不同的抽象层，而视图就是某层对系统的抽象表示；图，是由各种图形来构成的；模型元素，是指图中使用的概念；通用机制，是指所提供出来的其他信息。
UML的建模机制：在UML的建模机制中，主要包括两种，一种是静态建模机制，另一种是动态建模机制。静态建模机制是UML的基础，包括六项内容，分别为用例图、类图、对象图、包、构件图、部署图。在信息系统中包含多个对象，各个对象之间需要进行交互，交互的方法为互相之间传递消息，在动态建模机制中，包含四种动态图：顺序图、状态图、协作图、活动图，在这四种动态图中，消息是一种通信表示方式，实现对象之间的交互。
2基于UML的图书馆信息管理系统的分析与设计
（1）总体功能需求
随着社会的发展，要求图书馆要实现现代化及自动化。据调查显示，现在已经有600多个图书馆实现了互联网联机目录，另外，网络中还拥有虚拟图书馆，这是由非盈利组织和商业公司建立起来的，主要目的是给用户提供更为广泛的信息。现今，图书馆的业务范围正在扩展，而且用户的工作特点也在不断地发生变化，因此在充分了解这两方面内容的基础上，在图书馆信息管理系统中建立了四大结构：读者服务区、图书馆工作区、行政管理区、图书馆简介。
（2）系统的用例视图
这一阶段为分析阶段，在这一阶段中，以用户的需求为主，建立起用例视图。实际上，用例视图就是从用户的角度出发，建立起用户需求的系统功能模型图。建立用例视图包括两方面的工作：第一，确定系统用户，在图书馆系统中，系统用户包括注册及非注册阅借阅者、图书馆及系统管理员、外部信息源、电子及纸质书刊、行政主管，而不同的用户还可以细分出更多的子类别；第二，确定和说明用例，图书馆系统要拥有不同的功能，根据功能划分，系统可划分为读者服务、流通、采访、编目、维护子系统几大部分。
（3）系统静态视图
静态视图是一种基础视图。在系统需求确定之后，就需要依据需求来识别系统对象，并进行分类。类确定之后，就需要了解各类之间的关系，并根据关系建立起类图。对系统中的类进行划分，可分为3个包：GUI包、Library包、DB包。不同的包由不同的类组成，GUI包由界面类组成，实体类组成了Library包，而与数据库相关的类则组成了DB包。
（4）系统动态视图
系统会随着时间的变化而变化，动态视图主要是描述变化行为，在描述时以静态视图为基础。首先，要建立交互作用图，在图书馆信息管理系统中，包含着大量的时序图，比如系统管理员添加书籍时序图、系统管理员删除书目时序图等，在时序图中，都需要进行交互作用；其次，建立协作图，协作图表示的是对象之间在时间及空间上的交互，与时序图所描述的内容基本相同；第三，建立状态图，在系统中，需要建立状态图的类有两种，书籍及借阅者账户；第四，建立活动图，活动图主要是确定以何种顺序来完成一项操作。
（5）系统的配置与实现
在图书馆信息系统中，包含两个组件图：业务对象组件图、用户界面组件图。在信息系统的设计中，要明确系统中软件及硬件的配置情况，而为了进行合理的配置，就需要建立相应配置图。
在对图书馆信息管理系统进行分析与设计时，充分的应用了UML建模语言，从系统的分析到系统的实现，UML利用描述手段将其科学的联系在一起。
3结论
UML作为一种标准的建模语言，对于以面向对象技术来描述的系统来说，无论是何种类型的系统，都可以适用，而且在一个系统的不用开发阶段，都可以使用UML建模语言。应用UML建模语言对信息系统进行分析与设计，可以更好地实现信息管理，保证信息管理的有效性及有序性。本文以图书馆信息管理系统为例，简单的讲述了利用UML进行分析与设计的过程。
参考文献
[1] 林奕君.基于UML的图书馆管理信息系统的分析与设计[J].科技情报开发与经济，2014（14）：27-28.
[2] 陈洪雷.基于UML的仓库管理信息系统的分析与设计[J].商场现代化，2012（01）：251.
[3] 吕冠艳，李奋华.基于UML的信息系统需求分析模型[J].微型机与应用，2010（20）：142-143.
初识UML 第9篇
设计UML的主要目的是描述面向对象的系统。随着软件产业的规模越来越大及对软件通用性的要求越来越强, 软件开发复杂性、难度系数也越来越大, 随之出现了许多能简化开发复杂度、清晰开发思路的的方法统一建模语言。UML是由Grady Booch、James Rumbaugh与Ivar Jacobson发起, 在Booch方法、OOSE方法、OMT方法的基础上形成的一个建模语言, 并于1997年9月发布的UML1.1。UML的诞生和发展对于整个软件开发流程的改善起了相当关键的作用。
UML对软件开发最大的贡献是在设计与建模上, 此前设计与建模比较纷乱, 众说纷纭, 结果造成很多开发者在建模的过程中不知道到底要遵循哪种方式, 相对地也会减缓软件开发的速度。UML带来的最大好处就是大家愿意在建模上发挥自己的能力, 把软件开发从原来的写程序发展到可以有很规范的结构和建模的方式, 这是软件应该要发展的方向, 也是UML意义最大的体现。
二、UML的概述及目标
UML是一种能够描述问题、描述解决方案、起沟通作用的语言。作为一种建模语言, UML的定义包括语义和语法两部分。UML的语义描述基于UML提供的精确元模型的定义 (元模型为UML的所有元素在语法和语义上提供了简单、一致和通用的定义性说明, 并且UML还支持对元模型的扩展定义) , UML的语义用自然语言描述, 同时在语义上, 模型是元模型的实例;UML的语法定义了UML的概念、元素、符号表示法及用法, 为开发者或开发工具使用这些图形符号和文本语法提供了系统建模标准。
UML是一种可视化的建模语言, 对其各种建模元素可进行详细说明, 并能生成所建模型的文档。使用UML时, 要从不同的角度观察系统, 为此定义了一个概念“视图”。视图是对系统模型在某方面的投影, 它注重于系统的某个方面, 每个视图是图的协作, 由视图可以定义模型, 模型在语义上是闭合的, 它从特定的角度、在一定抽象层次上描述目标系统。可以把视图组织成模型, 开发人员可从各视角观察并使用模型。
UML定义了5大类共9种视图: (一) 用例图; (二) 静态图, 包括类图、对象图和包图; (三) 行为图; (四) 交互图, 它描述对象间的交互关系, 系动态视图; (五) 实现图, 包括构件图和配置图。
UML成功的关键在于它能够反映软件开发者各种真实的需要。如果标准制定得太严格或太松散以至于根本不能用于真正的技术, 那么就会导致标准的失败。因此建立了以下目标:
(一) 为建模者提供现成可用的、富表达力的、可视化的建模语言, 以开发和交换有意义的模型。
(二) 提供可扩展性和特殊化机制以延续核心概念。
(三) 支持独立于编程语言和开发过程的规范。
(四) 为理解建模语言提供正好司的基础。
(五) 推动对象工具市场的成长。
(六) 支持更高级的开发概念。
三、简述UML建模过程及建模支持工具
在软件开发建模过程中可根据实际需要, 组合使用这些视图的一部分或所有视图。作为一个完整的建模语言, UML支持系统开发的不同阶段, 从需求描述、系统分析、系统设计直至最后的系统测试及维护。在需求分析阶段, UML通过用例模型来捕获用户需求, 通过用例图, UML描述跟系统相关的角色及他们对系统的功能要求 (用例) ;分析阶段主要关心问题域的概念和实体, 并得到与问题域直接相关的类和对象以及它们之间的关系;在系统设计阶段, 用户需要定义一些与技术相关的类, 如用户接口、数据库、通讯和并行等问题;在编码阶段, 开发人员应用一种语将设计得到的类转换成实际的代码, 同时需把UML支持的概念合适转化到特定的实现语言中;在系统测试阶段, 测试人员根据应用UML开发过程中产生的文档和各类图 (用例图、类图、构件图、合作图等等) 进行测试验证。
当然好方法一定要有好的工具支持才能取得好的效果, 由于UML本身是一个以图形化图符为主的建模方法, 因此在图形绘制及模型管理上会随着软件规模的扩大而变得困难。这时UML支持工具就显得更为重要, 工具的作用不仅在于它可以帮助人们方便地实现图示模型的绘制, 实现模型的更改, 更重要的是工具使得人们可以全面地对模型进行整个开发过程的管理。目前最常用的UML支持工具为Rational公司开发出来的Rose工具, 它全面支持UML中的各个模型, 同时还可从正向或逆向两个方向支持用户进行系统开发, 功能非常强大。
四、UML结合软件开发流程的体会
软件开发一般可分为瀑布式与反复式开发流程。瀑布式开发需要在开发初期进行详细的需求分析与设计, 在整个项目开发过程中, 总体需求基本保持不变。反复式开发一般首先建立一个系统最小模型, 然后根据需求, 逐渐实现系统其他部分。现实世界的需求, 很难在项目初期完全确定, 是随着时间的推延不断变化的, 这也要求我们采用这种迭代式的开发方法。目前最流行的敏捷软件开发, 正是基于这个原因, 采用反复迭代的方式进行软件的开发。在项目开发阶段, 应把UML当作草稿, 在实现系统的过程中, 随着需求的变化, UML草图不断变化, 便于开发人员沟通交流与代码编写。在测试完成总结阶段, UML用作蓝图, 通过代码, 生成系统总体结构图, 这种图只要求粗略介绍系统, 不追求细节, 主要用于二次开发及维护人员对代码的了解。在软件技术发展的驱动下, 软件建模技术也会随之不断发展。未来UML技术必然会表现出它的局限性, 从而出现能够满足新需求的软件建模语言。
五、UML的发展趋势
UML从最初0.8版本到现今2.0版本, 功能正日趋完善。虽然目前由于UML较专业化, 使用难度还较大, 不过随着UML的不断发展, 相信不久的将来将会被越来越多的人应用。甚至有人预测当可执行UML技术成熟以后, 很多编程语言的生存都可能受到挑战, 可执行UML将取代一大批的编程语言。今后, 你只需画下类图, 然后指定对象之间的交互, 最后再选择运行平台, 建模环境就会帮你生成可执行文件了。Rational的XDE这个工具中, 我们已经可以看到可执行UML的雏形了, 你只需在建模环境中创建系统模型, 工具就会立刻帮助你生成可执行代码。
摘要：近年来UML在世界范围, 已经逐渐成为面向对象技术领域占主导地位的标准建模语言。本文对UML产生的背景及其基本概念进行阐述, 并谈了UML结合软件开发流程的体会, 最后对UML的发展趋势进行预测。
关键词：UML,统一建模语言,视图
参考文献
[1]冀振燕.UML系统分析设计与应用案例[M].北京:人民邮电出版社, 2003.06.
[2]美Kurt Bittner, Lan Spence著;姜昊, 许青松译.用例建模-USE CASE MODELING[M].北京:清华大学出版社, 2003.8.
UML方法范文
声明：除非特别标注，否则均为本站原创文章，转载时请以链接形式注明文章出处。如若本站内容侵犯了原著者的合法权益，可联系本站删除。
