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对用例的正式定义，对我们初学者可能有点难懂。

我们可以这样去理解，用例是参与者想要系统做的事情。

对于对用例的命名，我们可以给用例取一个简单、描述性的名称，一般为带有动作性的词。

用例在画图中用椭圆来表示，椭圆下面附上用例的名称。

系统边界系统边界是用来表示正在建模系统的边界。