基于UML的面向对象的软件系统分析.doc

哈尔滨师范大学
课程论文

课程名称：软件系统分析设计
任课教师：依波
题  目：基于UML的面向对象的软件系统分 析、设计与开发技术   
姓  名：朱润华
学  号：2012040732
学  院：计算机科学与信息学院
系  别：计算机科学与技术系
成  绩：

基于UML的面向对象的软件系统分析、设计与开发技术
朱润华
摘 要：本文对基于UML的面向对象的软件系统分析、设计与开发技术进行了研究，指出了基于迭代方法的RUP与传统的基于瀑布法的软件开发过程相比具有合理性和优越性，剖析了这些先进技术的思想内涵。此外，文中还详细介绍了基于问题说明和用例分析的软件系分析方法，以及UML中多种模型图的使用方法和适用范围。
关键词：UML 面向对象 RUP 问题说明

一、 引言

上个世纪90年代以来的快速、持续、无法预测的竞争环境的变化给企业的生存、发展提出了新的挑战竞争环境的变换太快而我们企业调整、适应的速度跟不上，主要表现在:技术更新的速度跟不上、管理模式的调整跟不上、生产方式的更新硬不上、信息系统的支持跟不上、新型人才的培训跟不上敏捷化成为企业生存发展的基本条件企业实现敏捷化的最主要的决定性因素是:敏捷化的员工和敏捷化的信息系统其中信息系统的敏捷化主要表现为:快速地进行自我调整和重构化适应竞争环境变化的需要;能支持软件系统的快速重用并通过重构组成新的应用系统“面向重构、重用的敏捷化信息系统分析、设计和开发”成为社会发展的迫切需要。
目前在信息系统分析与建模领域主要的方法有:IDEF方法、OMT方法和UML方法UML代表统一建模语言(Uni-fled modeling Language)，是由Booch Rumbaugh和Jacobson共同努力设计完成的，它融合了三种主要的面向对象技术Booch OMT和00SE中的精华1997年11月，UML的1. 1版被OMG(Object Management Group)批准为标准，成为基于面向对象技术的标准建模语言。
UML是一种用可视化方法对软件系统进行描述、实施和说明的标准语言。UML强调通过图示化的方法，通过不断交互和逐步逼近来捕捉、描述用户的真正需求它能支持用不同
实现技术进行的软件开发全过程。

二、生命周期迭代法的RUP

对UML的应用离不开软件工程中的一系列新方法和理论，包括生命周斯迭代法和著名的RUP(Rational Unified Proces)软件系统的开发可以分为初始阶段(Inceptio)细化阶段(Elaboratio)构造阶段(Construction)和移交阶段(Transitio)与传统的“瀑布法”不同的生命周期迭代法已经成为当前软件开发的主要方法。

1、生命周期迭代法
这种方法的主要特征是:
(1)连续渐进的集成不是从头到尾一次成型，也不是在系统交付以前才匆匆完成。
(2)频繁的可执行系统的发瓶一部分是内部更新，一部分正式提交使用。
(3)通过可验证的进步来迎接风险的挑战进步是通过产品的可测试原型系统的进步来衡量，而不是仅仅从文本和工程估计上来判断。
生命周期迭代法是有计划的、有序的和结果可预测的。它是以降低风险为目标来驱动迭代的，在整个过程中都有使用者和客户的参加。生命周斯迭代法带来了巨大的优越性:
(1)不断的版本发布成为一个团队日常工作的真正的驱动力。
(2)可以将发现问题、制定方案和解决过程集成到下一次迭代中完成而不是中断正在进行的开发过程。
(3)可以更好的安排产品开发的辅助过程(测试者、编码者、软件工具、配置管理、质量保证等等)，以实现并行开发的目标。
生命周期迭代法中的每一个个别循环的生命周期采用的是小型瀑布法，如图1所示:

图1 个别循环的生命期——小型瀑布法

我们可以从功能、性能、能力范围、评测质量几个方面根据迭代计划过程确定的目标评价迭代的结果，还要考虑到本次迭代以后外部环境的变换(例如需求的变换、用户的变换和
竞争者情况的变换等，来确定需要在下一次迭代中返工的问题。
一般来讲，对于一个18个月的项目计划3- 6次迭代是比较合适的。第一次迭代一般是最难的，而且团队在迭代开始前往往对困难预计不足，因此不应该对第一次迭代提出过高
的功能要求迭代的结果、最近的风计、可撞的资源(包括代码和浏试数据)视化的建模软件来捕获系统和组件的结构的行九使用可视化的图形来进行系统建模，允许隐藏系统的细节，并且保持设计和实施之间的一致性UML是成功的可视化建模的基础。

2、RUP
UML是一种建模语言而不是一种方法，因为UML并不包含对过程的定义1998年正式颁布的RUP是UML设计者们共同定义的一个软件开发的公共过程框架RUP是一个使用生命周期迭代法的软件开发过程它提供了在一个开发团队内分配任务和职责的一套严格的方法它的目标是在可预测的进度和预算内完成高质量软件的生产，满足用户的需要。
与传统的软件开发中编写大量的文档不同的是，RUP强调建立并且维护“模型”“模型”就是对开发中的软件系统的语义丰富的表示，用可视化的工具软件来建立RUP是有效的使用UML的向导，它吸取了许多现代软件开发中最好的实践经验，并且把它们组织成一种能够适用于各种工程和组织的形式这些最好的实践经验包括:
(1)迭代的进行软件开发对于当今复杂的软件系统，已经不可能按照传统的方法(首先定义整个问题，设计整个解决方案，编写整个软件，最后测试)进行顺序的开发我们需要一种迭代的方法，通过连续的精炼来不断的增进对问题的理解，从而在多次迭代的基础上渐进的得到一个有效的解决方案，RUP使用迭代的方法，把传统的“大瀑布”改成多个“小瀑布”，通过把高风险的项目分散到生命周期的每一个阶段，可以显著的降低整个工程的风险。
(2)管理需求RUP描述了怎样提取、组织、并文档化需求的功能和约束;跟踪和文档化中间方案和决策;并且容易的捕获和交流业务需求。
(3使用基于组件的架构RUP支持基于组件的软件开发组件是执行一个特定功能的模块或者子系统，可以方便的集成进一个定义良好的体系框架中，从而实现软件系统的重构和重用。
(4)可视化的建模软件RUP向我们展示了怎样利用可视化的建模软件来捕获系统和组件的结构的行丸使用可视化的图形来进行系统建模，允许隐藏系统的细节，并且保持设计和实施之间的一致比UML是成功的可视化建模的基础。
(5)验证软件质量不足的应用性和可靠性是抑制软件应用的重要因氟因此应该基于可靠性、功能性、应用性和系统性的要求来评论软件的质量在RUP中，质量评价内置到了全部开发活动中，与全部参加者有关，并且使用客观量度和标准。
(6)控制软件的变更由于软件系统的变更往往是不可避免的，管理软件变更的能力就十分重要应该确保每个变更都是可以接受的，并且能够跟踪RU P描述了怎样控制、跟踪和监视软件的变更，来确保成功的迭代开发三基于问题说明的系统分析和设计。
问题说明是基于UML的面向对象的系统开发的第一步，它主要说明系统应该做什么而不是怎么做问题说明可以由用户提供，但在多数情况下，它是由开发者通过和客户的协商共同定义吮这里和用户协商的含义在于如何正确把握系统的功能需求。
问题说明可以作为开发者最初确定对象类候选对象的参考，从问题说明中提取对象类的主要步骤是:
(1)抽取问题说明中的名词和名词短语，作为可能的对象类
(2)利用领域知识来补充遗漏的对象类
(3)通过观察用例图来补充遗漏的对象类
(4)剔除所有不必要和不正确的候选类
(5)准备数据辞典
在确定了对象类以后，还可以进一步从问题说明中提取对象之间的联系:
(1)抽取问题说明中的动词和动词短语，作为可能的对象类之间的联系。
(2)利用领域知识来补充遗漏的对象之间的联系。
(3)通过观察用例图来补充遗漏的对象类之间的联系。
(4)剔除所有不必要和不正确的候选联系。
(5)更新类设讯
再进一步，可以从问题说明中确定对象类和联系类的属性:
(1)抽取问题说明中的名词+所有格补语，作为可能的对象类和联系类的属
(2)利用领域知识来补充遗漏的对象类和联系类的属
(3)通过观察用例图来补充遗漏的对象类和联系类的属
(4)剔除所有不必要和不正确的候选属
(5)更新类设讯

四、 UML的基本模型图

UML是一种用可视化方法对软件系统开发的全过程提供支持的标准建模语言，它提供了下列的5类，共10种基本模型图:
(1)用例图;
(2)静态图，包括类图、对象图和包图;
(3)交互图，包括状态图和活动图;
(4)行为图，包括状态图和活动图;
(5)实现图，包括构件图和配置图。
概括的讲，UML可以用于:
(1)利用活动者和用例来描述系统的边界和它的主要功能；
(2)通过各种交互图形来描述用例的实现；
(3)用类图来描述系统的静态结构和特征；
(4)用状态转换图来描述对象的动态特征；
(5)通过部件图和实施图来描述系统的物理特征和体系结构；
(6)通过自定义类型，扩展系统功能。

1、用例图
系统分析和设计的第一步也是最关键的一步，是用户需求的捕捉，引入用例的概念并用来开发需求，是面向对象技术进入第二代的标志用例分析是从用户角度来描述业务过程的方法用例图描述系统外部的执行者(Actor)与系统提供的用例(Use Case)之间的某种联系。通过系统分析，确定大致的设计目标:
(1)执行者:系统的外部用户，可以是人或者其它的应和系统。
(2)用例:执行者对系统的应用方式;通过他/它(执行者)与系统的交互过程描述(Scenarios)来详细说明用户的真实需求用例是类，所有类的描述都可以应用于用例，类的泛化(generalization)特性在用例中被具体化或扩展为应用(uses)和扩充(extends)用例图着重于从系统外部执行者的角度来描述系统需要提供哪些功能，并且指明了这些功能的执行者是谁。用例图是指由参与者（Actor）、用例（Use Case）以及它们之间的关系构成的用于描述系统功能的静态视图。用例图（User Case）是被称为参与者的外部用户所能观察到的系统功能的模型图，呈现了一些参与者和一些用例，以及它们之间的关系，主要用于对系统、子系统或类的功能行为进行建模。用例图 use case diagram 类别静态视图组成主角、用例以及它们之间的关系。参与者（Actor）、用例（Use Case）、系统边界、箭头组成，用画图的方法来完成。参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。因此参与者可以是人，可以是事物，也可以是时间或其他系统等等。还有一点要注意的是，参与者不是指人或事物本身，而是表示人或事物当时所扮演的角色。比如小明是图书馆的管理员，他参与图书馆管理系统的交互，这时他既可以作为管理员这个角色参与管理，也可以作为借书者向图书馆借书，在这里小明扮演了两个角色，是两个不同的参与者。参与者在画图中用简笔人物画来表示，人物下面附上参与者的名称。
用例是对包括变量在内的一组动作序列的描述，系统执行这些动作，并产生传递特定参与者的价值的可观察结果。这是UML对用例的正式定义，对我们初学者可能有点难懂。我们可以这样去理解，用例是参与者想要系统做的事情。对于对用例的命名，我们可以给用例取一个简单、描述性的名称，一般为带有动作性的词。用例在画图中用椭圆来表示，椭圆下面附上用例的名称。
系统边界。系统边界是用来表示正在建模系统的边界。边界内表示系统的组成部分，边界外表示系统外部。系统边界在画图中用方框来表示，同时附上系统的名称，参与者画在边界的外面，用例画在边界里面。因为系统边界的作用有时候不是很明显，所以我个人理解，在画图时可省略。
箭头用来表示参与者和系统通过相互发送信号或消息进行交互的关联关系。箭头尾部用来表示启动交互的一方，箭头头部用来表示被启动的一方，其中用例总是要由参与者来启动。
主要的作用有三个：（1）获取需求；（2）指导测试；（3）还可在整个过程中的其它工作流起到指导作用。元素之间的关系用例图中包含的元素除了系统边界、角色和用例，另外就是关系。关系包括用例之间的关系，角色之间的关系，用例和角色之间的关系。角色之间的关系。由于角色实质上也是类，所以它拥有与类相同的关系描述，即角色之间存在泛化关系，泛化关系的含义是把某些角色的共同行为提取出来表示为通用的行为。
用例的行为包含了另一个用例的行为。基本用例描述在多个用例中都有的公共行为。包含关系本质上是比较特殊的依赖关系。它比一般的依赖关系多了一些语义。在包含关系中箭头的方向是从基本用例到包含用例。在UML1.1中用例之间是使用和扩展这两种关系，这两种关系都是泛化关系的版型。在UML1.3以后的版本中用例之间是包含和扩展这两种关系。
泛化关系：代表一般与特殊的关系。它的意思和面向对象程序设计中的继承的概念是类似的。不同的是继承使用在实施阶段，泛化使用在分析、设计阶段。在泛化关系中子用例继承了父用例的行为和含义，子用例也可以增加新的行为和含义或者覆盖父用例中的行为和含义。
扩展关系的基本含义和泛化关系类似，但在扩展关系中，对于扩展用例有更多的规则限制，基本用例必须声明扩展点，而扩展用例只能在扩展点上增加新的行为和含义。与包含关系一样，扩展关系也是依赖关系的版型。在扩展关系中，箭头的方向是从扩展用例到基本用例，这与包含关系是不同的。
用例的泛化、包含、扩展关系的比较。一般来说可以使用“is a”和“has a”来判断使用那种关系。泛化和扩展关系表示用例之间是“is a”关系，包含关系表示用例之间是“has a”关系。扩展与泛化相比多了扩展点，扩展用例只能在基本用例的扩展点上进行扩展。在扩展关系中基本用例是独立存在。在包含关系中在执行基本用例的时候一定会执行包含用例。如果需要重复处理两个或多个用例时可以考虑使用包含关系，实现一个基本用例对另一个的引用。当处理正常行为的变形是偶尔描述时可以考虑只用泛化关系。当描述正常行为的变形希望采用更多的控制方式时，可以
在基本用例中设置扩展点，使用扩展关系。扩展关系比较难理解，如果把扩展关系看作是带有更多规则限制的泛化关系，可以帮助理解。通常先获得基本用例，针对这个用例中的每一个行为提问：该步骤会出什么差错？该步骤有不同的情况工作怎样以不同的方式进行等，把所有的变化情况都标识为扩展。通常基本用例很容易构造，而扩展用例需要反复分析、验证。当我们发现已经存在的两个用例间具有某种相似性时，可以把相似的部分从两个用例中抽象出来单独作为一个用例，该用例被这两个用例同时使用，这个抽象出的用例和另外两个用例形成包含关系。图2所示的是一个订货系统的用例图。

图2 一个订货系统的用例图

2、类图
类图技术是面向对象方法的核心技术类图是系统逻辑视图的表示方法它用来描述对象的特性以及不同对象之间的关系。UML通过类图来描述下列基本元素:
(1)不同的类以及它们的属性(attribute)和行为特性(behavior)工
(2)不同类之间的关联(association聚合(aggregate相关(dependence)和继承(inheritance)关系。
(3)类的实例数量特性(multiplicity)和遍历方向(navigation indicators)
(4)角色名(role names)
类是具有相同结构、相同特性、相同关系和相同语义的对象的集瓷类可以通过分析问题说明、考察交互图(包括事件顺序图和对象合作图)中的对象，总结抽象出来类用一个分成三部分的矩形来表示，这三部分分别是:类名称、属性和方法UML规定了三种类之间的关系:关联、聚合和相羌此外，父类与子类之间还存在继承关系。类图(Class diagram)是显示了模型的静态结构，特别是模型中存在的类、类的内部结构以及它们与其他类的关系等。类图不显示暂时性信息。
类图(Class diagram)由许多（静态）说明性的模型元素（例如类、包和它们之间的关系，这些元素和它们的内容互相连接）组成。类图可以组织在（并且属于）包中，仅显示特定包中的相关内容。类图(Class diagram)是最常用的UML图，显示出类、接口以及它们之间的静态结构和关系；它用于描述系统的结构化设计。类图(Class diagram)最基本的元素是类或者接口。
一般包含3个组成部分。第一个是类名；第二个是属性（attributes）；第三个是该类提供的方法（ 类的性质可以放在第四部分；如果类中含有内部类，则会出现第五个组成部分）。类名部分是不能省略的，其他组成部分可以省略。
类名书写规范：正体字说明类是可被实例化的，斜体字说明类为抽象类。属性和方法书写规范：修饰符 [描述信息] 属性、方法名称 [参数] [：返回类型|类型]，属性和方法之前可附加的可见性修饰符：加号（+）表示public；减号（-）表示private；#号表示protected；省略这些修饰符表示具有package（包）级别的可见性。如果属性或方法具有下划线，则说明它是静态的。描述信息使用 << 开头和使用 >> 结尾。类的性质是由一个属性、一个赋值方法和一个取值方法组成。书写方式和方法类似。图3显示的是一个订货系统的“订单”类的类图。

图3 一个订货系统的“订单”类的类图。

3、交互图
交互图主要用来描述对象之间的动态合作关系以及合作过程中的行为次息它常常用来描述一个用例的行为，显示该用例中所涉及的对象和这些对象之间的消息传递情况。
交互图主要有两种形式，即顺序图和合作图。顺序图按照时序来显示对象之间的交互作用，但是并不能够清楚的显示对象之间的关系。一张合作图描述了一个合作，这个合作是由
一个特定环境中的对象集合以及这些对象之间的消息交互共同组成故与顺序图不同，合作图显示了对象之间的关系，但是不把时间当作一个独立的维。交互图是描述对象之间的关系以及对象之间的信息传递的图。种类序列图和协作图，对象沿横轴排列消息，沿纵轴按时间顺序排列。序列图和协作图称为交互图。其中，序列图用来描述对象之间消息发送的先后次序，阐明对象之间的交互过程以及在系统执行过程中的某一具体时刻 将会发生什么事件。序列图是一种强调时间顺序的交互图，其中对象沿横轴排列，消息沿纵轴按时间顺序排列。序列图中的对象生命线是一条垂直的虚线，他表示一个对象在一段时间内存在。顺序图是一个二维图形。以时间顺序显示参与者向系统发起的事件及 对象间交互的图 顺序图不表示对象间的关联(associations)关系。
顺序图中的一些主要元素：
– Object (包括actor实例)
– Lifeline (生命线)
– Focus of control(控制焦点)和activation(激活期)
– Message
协作图也是一种交互图，它强调收发消息的对象的组织结构。协作图和序列图是同样的，它们可以相互转换。在多数情况下，协作图主要用来对单调的、顺序的控制流建模，但它也可以用来对包括迭代和分支在内的复杂控制流进行建模。n协作图:包含一组对象和链(link)，协作图中的组成元素Object(包括actor实例，多对象，主动对象)Message Link(链)。两种图间可以互相转换。图4、图5分别是创建一条订单记录的顺序和合作图。

图4 创建一条订单记录顺序图

图5创建一条订单记录合作图

4、行为图
行为图包括状态图和活动图两种，用于刻画对象的动态特性。
对于大多数开发人员而言，状态图是一个十分熟悉的工具一般来讲，状态图描述了一个特定对象的所有可能状态以及由于各种事件的发生而引起的状态之间的转概大多数面向对象技术都使用状态图来描述一个对象在其生命周期中的行为。图6所示的是一个订单对象的状态图。

图6 一个订单对象的状态图

从顺序关系上看，活动图与常用的程序流程图非常相似它描述了需要做的活动以及执行这些活动的顺序。活动图主要用于描述工作流和并行过程的行为，对企事业过程中业务活动的建模非常重要。
比较起来，状态图适合于描述跨越多个用例的单个对象的行为:交互图适合于描述单个用例中的多个对象的行为;活动图适合于展现多个对象和多个用例的活动的总次序。

5、实现图
构件图和配置图是UML中定义的两种实现图，可以显示系统实现时的一些特性构件图显示代码本身的逻辑结构，主要用于显示系统中各个功能部件之间的依赖关系和调用关系。在面临越来越多的分布式系统时，配置图是我们更好的设计和描述系统中的软构件和硬件的配置情况的有力工具下面的图。UML的实现图用来描述系统实现方面的信息，它从系统的层次描述硬件的组成和布局，软件系统的划分和功能实现。实现图包含构件图和部署图。构件图显示一组构件之间的组织和依赖关系，并秒速其中的构造细节。部署图用来描述系统硬件的物理结构及在此结构上执行的软件。     
 构件图从软件架构的角度来描述系统的主要功能，比如系统分成几个子系统，每个子系统包含哪些类，包等和它们之间的关系等。使用构件图可以清楚的看出系统的结构和功能。
构件是系统中遵从一组接口且提供其实现的物理的，可替换的部分。构件能够完成独立功能，它是软件系统的组成部分。在功能划分的软件系统中，软件被分成一个个的模块。随着面向对象技术的引用，软件系统被分成若干个子系统，构件。每个构件能够实现一定的功能，为其他构件提供使用接口，方便软件的复用。
配置构件：包含操作系统，java虚拟机以及数据库管理系统等，这是形成可执行文件的基础。
工作产品构件：这是由模型，源代码和配置文件等组成由UML图，java类和jar文件，EJB中的实体，xml配置文件，动态链接库以及数据库表等。
执行构件：在运行时创建的构件，是最终运行系统中通过这些构件来产生结果。
部署图描述了系统运行时的硬件节点以及在这些节点上运行的软件构件的静态视图。部署图显示了系统中的硬件，安装在硬件上的软件以及用于连接异构机器的中间件。节点是运行时各种硬件资源的通用名称。节点可以用来表示各种资源的类型以及包含对象和构件的实例。处理器是指能够执行软件，具有计算能力的节点。例如：服务器，工作站等。设备是指没有计算能力的节点。通常情况下是通过接口为外部提供服务的节点，如打印机，显示器或扫描仪等。图7所示的是一个订货系统的构件图。

图7 一个订货系统的构件图

五、 结语

在这个瞬息万变的时代，在合理的时间内开发和管理高质量的应用程序变得越来越困难统一建模语言UML的出现为信息系统建模与设计的供了有力工具利用基于UML的可视化的建模软件工具，我们可以按照RUP的要求方便的管理项目需求、使用基于组件的框架、验证软件质量，控制版本更新，从而实现整个软件系统的面向对象的分析、设计与迭代开发这一技术的深入普及与应用必将对我国软件产业的发展产生非常积极的推动作用。

参考文献
[1] 倍杰、杨明福，“使用Rational Rose实现对基于Web的应用的00设计”，微型电脑应2001
[2] 调安宁，“用面向对象的方法设计动态web' ,微型电脑应用，2001年，第17卷，第9期
[3] 鲁博、柴跃廷，“关于统一建模语言一一UML”，计算机工程与科学，2000年，第22卷
[4] 误跃、罗吴蔓，“统一建模语言RML分层抽象建模机制”，电子科技大学学报，2001年
[5] 浏军、王宁生，“基于UML的迭代式软件开发过程”，计算机工程与应用，2001年
[6] 刘超、张莉，《可视化面向对象建模技术》,北京航空航天大学出版社，2001年7月