UML建模期末复习

概念理解：

面向对象方法的本质:

OO方法是指把软件组织成一系列离散的、合并了数据结构和行为的对象。

面向对象软件开发方法描述和理解问题域的基本思想是，对问题域进行自然分割，以更接近人类思维的方式建立问题域模型，从而使生产出的软件尽可能直接地描述现实世界，具有更好的可维护性，能适应用户需求的变化。

“面向对象”(Object Oriented,简称OO)是一种以事物为中心的编程思想。

面向对象的方法主要是把事物给对象化,对象包括属性与行为.当程序规模不是很大时,面向过程的方法还会体现出一种优势,因为程序的流程很清楚,按着模块与函数的方法可以很好的组织.

“面向过程”是一种以过程为中心的编程思想。

就是分析出解决问题所需要的步骤，然后用函数把这些步骤一步一步实现，使用的时候一个一个依次调用就可以了。

面向过程其实是最为实际的一种思考方式,就是算面向对象的方法也是含有面向过程的思想.可以说面向过程是一种基础的方法.它考虑的是实际的实现.一般的面向过程是从上往下步步求精.所以面向过程最重要的是模块化的思想方法.

面向对象与面向过程有什么不同？

对象和类的概念理解和二者的关系:

(1)类

具有相同或相似性质的对象的抽象就是类。因此，对象的抽象是类，类的具体化就是对象，也可以说类的实例是对象。

类具有属性，它是对象的状态的抽象，用数据结构来描述类的属性。

类具有操作，它是对象的行为的抽象，用操作名和实现该操作的方法来描述。

(2)类的结构

在客观世界中有若干类，这些类之间有一定的结构关系。通常有两种主要的结构关系，即一般--具体结构关系，整体--部分结构关系。

①一般——具体结构称为分类结构，也可以说是“或”关系，或者是“is a”关系。

②整体——部分结构称为组装结构，它们之间的关系是一种“与”关系，或者是“has a”关系。

(3)对象

对象是人们要进行研究的任何事物，从最简单的整数到复杂的飞机等均可看作对象，它不仅能表示具体的事物，还能表示抽象的规则、计划或事件。

(4)对象的状态和行为

对象具有状态，一个对象用数据值来描述它的状态。

对象还有操作，用于改变对象的状态，对象及其操作就是对象的行为。

对象实现了数据和操作的结合，使数据和操作封装于对象的统一体中

//现实中先有对象后有类.

//计算机中先有类后有对象.

一对象:现实世界中<*某个具体事务*>叫对象.

对象的组成部分:

⑴特征:用来识别一个对象,在计算机中叫属性.

⑵行为:体现一个对象功能的,计算机中叫方法

二类:将<*一组有共同点*>的对象,其共同点抽象出来就是类.

⑴构造函数:与类同名,没返回值,实例化同时调用,用于初始化,只能调用一次

⑵一个类中至少有2个构造函数,不带参数的为默认构造函数,带有用于初始化的构造函数.

⑶函数重载:函数同名不同参数以参数个数和参数类型为标准

对象分析方法:

1.一切都是对象；

2.对象都是独立的；

3.对象都具有原子性；

4.对象都是可抽象的；

5.对象都有层次性。

对抽象层次的理解:

抽象是从众多的事物中抽取出共同的、本质性的特征，而舍弃其非本质的特征。

共同特征是指那些能把一类事物与他类事物区分开来的特征，这些具有区分作用的特征又称本质特征。因此抽取事物的共同特征就是抽取事物的本质特征，舍弃非本质的特征。所以抽象的过程也是一个裁剪的过程，将不同的、非本质性的特征全部裁剪掉了。

所谓的共同特征，是相对的，是指从某一个侧面看是共同的。比如，对于汽车和大米，从买卖的角度看都是商品，都有价格，这是他们的共同的特征，而从其他方面来比较时，他们则是不同的。所以在抽象时，同与不同，决定于从什么角度上来抽象。抽象的角度取决于分析问题的目的。

抽象的主要目的:

抽象化主要是为了使复杂度降低，以得到领域中较简单的概念，好让人们能够控制其过程或以综观的角度来了解许多特定的事态。

抽象是把事物的个别特征去掉，取其共同点，去代表或说明同一类的事物。语言符号能在许多不同的抽象层次上活动，正是它的长处。抽象层次原理认为语言符号的抽象层次与传播效果成反比关系。同一个题目，可以在低的较具体的层次上和儿童讲，也可经在高的比较抽象的层次上和大学生谈，所不同的只是程度深浅，抽象的词可以包含一大堆具体的东西。在这个抽象的阶梯上爬得越高，次一级的事物的特征就消失在高一级的总体的意文中。以抽象层次高的语句，去简明地表达更多的具体意义，但层次越高，理解便也越难，引起误会的机会也大；若在低的具体的层次上进行，懂得的人会多，但必须用上一大堆词句。

1.抽象层次是面向对象方法中极其重要且非常难以把握的技巧；

2.要想建立好模型，就需学会站在不同的抽象层次考虑问题。

3.抽象层次越高，被屏蔽（或者说封装）的信息也就越多，信息量越少也就越容易理解和处理。

统一过程一般抽象层次:

什么时候选择什么样的层次以及总共抽象多少层？------用例粒度

抽象层次与边界的选择总是相生相伴------边界

用例、参与者、边界:

参与者：

定义：actor是在系统之外与系统交互的某人或某事物。

发现参与者：参与者的一个重要来源是涉众，从涉众中找出那些直接对系统发出动作，或直接从系统中接收反馈的涉众。

参与者一定是直接并且主动地向系统发出动作并获得反馈的，否则就不是参与者。

练习：

●情况一：机票购买者通过登陆网站购买机票，那么参与者就是：

参与者=机票购买者

●情况二：假如机票购买者通过呼叫中心，由人工坐席操作订票

系统购买机票，那么谁是机票预订系统真正的参与者？

参与者=人工坐席

这时机票购买者是哪个系统的参与者？

呼叫中心

●情况三：假如机票购买者通过呼叫中心的自动语音预订机票而不是通过人工坐席，那么谁成为了机

票预订中心的参与者？

参与者=呼叫中心

如图，这是一个参与者非人类的例子。

●情况四：如果扩大系统边界，让呼叫中心成为机票预订系统的一个子系统，并且假设机票购买者将

可以自主选择是通过人工坐席、自动语音还是登陆网站预定机票，那么谁是机票预订系统的参与者？

参与者=机票购买者

而人工坐席则变成什么角色？

业务工人

用例

基本概念：官方文档对用例是这样定义的：用例定义了一组用例实例，其中每个实例都是系统所执行的一系列操作，这些操作生成特定主角可以观测的值。

一个完整的用例定义由参与者、前置条件、场景、后置条件构成。如图所示：

●用例的特征：

?用例是相对独立的。

?用例的执行结果对参与者来说是可观测的和有意义的。

?这件事必须由一个参与者发起。不存在没有参与者的用例，用例不应该自动启动。

?用例必然是以动宾短语形式出现的。

?一个用例就是一个需求单元、分析单元、设计单元、开发单元、测试单元。下图展示了用例如何驱动软件开发活动。

●用例的粒度：

?用例粒度的选择没有标准的规则。一般来说，在项目的不同阶段使用不同的粒度。

?在业务建模阶段，用例的粒度以每个用例能够说明一件完整的事情为宜，即一个用例可以描述一项完整的业务流程。这将有助于明确需求范围。

?在用例分析阶段，即概念建模阶段，用例的粒度以每个用例能描述一个完整的事件流为宜。可理解为一个用例描述一项完整业务中的一个步骤。需要采用面向对象的方法，归纳和抽象出业务用例中的关键概念模型并为之建模。

?在系统建模阶段，用例视角是针对计算机的，因此用例的粒度以一个用例能够描述操作者与计算机的一次完整交互为宜。。

?前述的粒度划分方法并非标准，只是适合于大多数情况。用例粒度的划分依据最标准的方法是：该用例是否完成了参与者的某个完整目的为依据。

练习题目：

（1）某人去图书馆，查询了图书书目，出示了借阅证，图书管理员查询了该人以前的借阅记录以确保没有未归还的书，最后借到了书。从这段话中你能得出多少用例？

（2）一个人去邮局办事，寄信，同时购买了信封。

?一个大系统和一个很小的系统用例粒度会有较大差别。

?不论粒度如何选择，必须把握的原则是在同一个需求阶段，所有用例的粒度应该是同一个量级的。

?用例粒度的大小不是从用例包含的步骤的多少来判断的，粒度与边界有关。

●用例的获得：发现用例的前提条件是发现参与者。获取用例的准备工作：

?参与者是位于系统边界之外的；

?参与者对系统有着明确的期望和明确的回报要求；

?参与者的期望和回报要求在系统边界之内。

●用例的获得：可以通过以下问题引导业务代表：

?您对系统有什么期望？

?您打算在这个系统里做些什么事情？

?您做这件事的目的是什么？

?您做完这件事情有一个什么样的结果？

●在此过程中需要确保：

?一个明确的有效的目标才是一个用例的来源。

?一个真实的目标应当完备地表达主角的期望。

?一个有效的目标应当在系统边界内，由主角发动，并具有明确的后果。

各种关联关系

类图

建模公式:

静态模型

交互模型

状态图

状态图(Statechart Diagram)是描述一个实体基于事件反应的动态行为，显示了该实体如何根据当前所处的状态对不同的时间做出反应的。通常我们创建一个UML状态图是为了以下的研究目的：研究类、角色、子系统、或组件的复杂行为。状态图用于显示状态机（它指定对象所在的状态序列）、使对象达到这些状态的事件和条件、以及达到这些状态时所发生的操作。

状态是对象执行某项活动或等待某个事件时的条件。对象可能会在有限的时间长度内保持某一状态。

顺序图

顺序图是将交互关系表示为一个二维图。纵向是时间轴，时间沿竖线向下延伸。横向轴代表了在协作中各独立对象的类元角色。类元角色用生命线表示。当对象存在时，角色用一条虚线表示，当对象的过程处于激活状态时，生命线是一个双道线。

消息用从一个对象的生命线到另一个对象生命线的箭头表示。箭头以时间顺序在图中从上到下排列。

用例图

用例图就是由主角、用例以及它们之间的关系构成的图。该图说明了用例模型中的关系。

用例图由参与者参与者（Actor）、用例（Use Case）、系统边界、箭头组成，用画图的方法来完成。

参与者

参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。因此参与者可以是人，可以是事物，也可以是时间或其他系统等等。还有一点要注意的是，参与者不是指人或事物本身，而是表示人或事物当时所扮演的角色。比如小明是图书馆的管理员，他参与图书馆管理系统的交互，这时他既可以作为管理员这个角色参与管理，也可以作为借书者向图书馆借书，在这里小明扮演了两个角色，是两个不同的参与者。参与者在画图中用简笔人物画来表示，人物下面附上参与者的名称。

用例

用例是对包括变量在内的一组动作序列的描述，系统执行这些动作，并产生传递特定参与者的价值的可观察结果。这是UML对用例的正式定义，对我们初学者可能有点难懂。我们可以这样去理解，用例是参与者想要系统做的事情。对于对用例的命名，我们可以给用例取一个简单、描述性的名称，一般为带有动作性的词。用例在画图中用椭圆来表示，椭圆下面附上用例的名称。

系统边界

系统边界是用来表示正在建模系统的边界。边界内表示系统的组成部分，边界外表示系统外部。系统边界在画图中方框来表示，同时附上系统的名称，参与者画在边界的外面，用例画在边界里面。因为系统边界的作用有时候不是很明显，所以我个人理解，在画图时可省略。

箭头

箭头用来表示参与者和系统通过相互发送信号或消息进行交互的关联关系。箭头尾部用来表示启动交互的一方，箭头头部用来表示被启动的一方，其中用例总是要由参与者来启动。

元素之间的关系

用例图中包含的元素除了系统边界、角色和用例，另外就是关系。关系包括用例之间的关系，角色之间的关系，用例和角色之间的关系。

角色之间的关系

由于角色实质上也是类，所以它拥有与类相同的关系描述，即角色之间存在泛化关系，泛化关系的含义是把某些角色的共同行为提取出来表示为通用的行为。

用例之间的关系：

包含关系：

本用例的行为包含了另一个用例的行为。基本用例描述在多个用例中都有的公共行为。包含关系本质上是比较特殊的依赖关系。它比一般的依赖关系多了一些语义。在包含关系中箭头的方向是从基本用例到包含用例。在UML1.1中用例之间是使用和扩展这两种关系，这两种关系都是泛化关系的版型。在UML1.3以后的版本中用例之间是包含和扩展这两种关系。

泛化关系：

代表一般于特殊的关系。它的意思和面向对象程序设计中的继承的概念是类似的。不同的是继承使用在实施阶段，泛化使用在分析、设计阶段。在泛化关系中子用例继承了父用例的行为和含义，子用例也可以增加新的行为和含义或者覆盖父用例中的行为和含义。

扩展关系:

基本含义和泛化关系类似，但在扩展关系中，对于扩展用例有更多的规则限制，基本用例必须声明扩展点，而扩展用例只能在扩展点上增加新的行为和含义。与包含关系一样，扩展关系也是依赖关系的版型。在扩展关系中，箭头的方向是从扩展用例到基本用例，这与包含关系是不同的。

用例的泛化、包含、扩展关系的比较。

一般来说可以使用“is a”和“has a”来判断使用那种关系。范化和扩展关系表示用例之间是“is a”关系，包含关系表示用例之间是“has a”关系。扩展与范化相比多了扩展点，扩展用例只能在基本用例的

扩展点上进行扩展。在扩展关系中基本用例是独立存在。在包含关系中在执行基本用例的时候一定会执行包含用例。如果需要重复处理两个或多个用例时可以考虑使用包含关系，实现一个基本用例对另一个的引用。当处理正常行为的变形是偶尔描述时可以考虑只用泛化关系。当描述正常行为的变形希望采用更多的控制方式时，可以在基本用例中设置扩展点，使用扩展关系。扩展关系比较难理解，如果把扩展关系看作是带有更多规则限制的泛化关系，可以帮助理解。通常先获得基本用例，针对这个用例中的每一个行为提问：该步骤会出什么差错？该步骤有不同的情况吗？该步骤的工作怎样以不同的方式进行等，把所有的变化情况都标识为扩展。通常基本用例很容易构造，而扩展用例需要反复分析、验证。当我们发现已经存在的两个用例间具有某种相似性时，可以把相似的部分从两个用例中抽象出来单独作为一个用例，该用例被这两个用例同时使用，这个抽象出的用例和另外两个用例形成包含关系。

活动图

活动图（activity diagram，动态图）是阐明了业务用例实现的工作流程。业务用例工作流程说明了业务为向所服务的业务主角提供其所需的价值而必须完成的工作。业务用例由一系列活动组成，它们共同为业务主角生成某些工件。工作流程通常包括一个基本工作流程和一个或多个备选工作流程。工作流程的结构使用活动图来进行说明。

RUP与UML的关系：

RUP是一个非常完整而庞大的软件方法

RUP提供了软件开发生命周期的结构，明确定义了主要里程碑和决策关系。

RUP产品包括过程配置和过程视图，以指导系统分析员、开发人员、测试人员、项目经理、配置经理、数据分析员和其他团队成员共同开发软件。

RUP的总体架构

RUP与UML的关系------创作精美的文章

UML 语言

RUP 文法

UML 五线谱

RUP 音乐理论

RUP与UML的关系------判断对错:

RUP是指导UML的方法中最著名、应用最广的一个，两者是不可分开的；

RUP与UML是软件方法与建模语言的完美结合；

RUP是因为UML才诞生的；

RUP归纳和整理了很多在实践中总结出来的软件工程的最佳实践；

RUP使用UML作为软件分析设计语言；

不采用RUP的方法也可以使用UML。

RUP的特点及其应用:

庞大、全面、复杂；

追求稳定；

更适合于做长期战略规划的软件产品；

集成了很多过程类的最佳实践，包括：用例驱动、构件化；

RUP集成了技术和管理方面的内容，涉及了软件工程的方方面面，学习RUP将提升自身软件能力。