第2章电子商务应用系统与开发.pptx

第2章统一建模语言UML本章内容2.1 UML概述 2.2 UML的关系 2.3 用例图2.4 类图和对象图2.5 交互作用图2.6 活动图2.7 用例驱动开发2.8 Rational Rose的安装与使用2.1 UML概述 建模的目的 UML简介 UML的术语和概念 UML的组成 2.1.1 建模的目的 p 建模的必要性 对于多数程序员而言，在脑海里设想一个软件的实现与用代码来实现这个软件是没有距离的，怎么想，就怎么用代码来实现它这种做法会产生下列问题：n不利于交流n如果不建立模型，软件系统中的有些东西很难用文本的编程语言来表达清楚n如果程序员在修改代码时，没有将他脑海中的模型记录下来，这个信息可能会永远丢失，不便于软件维护p 建模的重要性n模型是对现实世界的简化，建模是为了更好地理解正在开发的系统p 建模原理n每一种模型可以在不同的精度级别上表示，最好的模型是与现实相联系的单个模型是不充分的对重要的系统应采用一组几乎独立的模型进行建模p 面向对象建模n从算法的角度建模（结构化）n从面向对象的角度建模建模的目的 2.1.2 UML简介 p UML的发发展nUML不仅结合了Booch、OMT和OOSE方法，而且对其做了进一步的发展，统一了符号体系，并从其它的方法和软件工程实践中吸收了许多经过实际检验的概念和技术；nUML是Grady Booch、James Rumbaugh、Ivar Jacobson和许多其他人员集体智慧的结晶，并最终统一为大众所接受的标准建模语言。

p UML的特点nUML是一种语言nUML是一种可视化语言nUML是一种可用于详细描述的语言nUML是一种构造语言nUML是一种文档化语言p UML的功能n为软件系统的产出建立可视化模型n规约软件系统的产出n构造软件系统的产出UML简介 2.1.3 UML的术语和概念 p 系统和模型n系统和子系统n模型n视图l用例视图l设计视图l过程视图l实现视图l配置视图n图系统和子系统p 包 包是一个用来将模型单元分组的通用机制，可以将一个系统看作一个单一的、高级的包n可见性n引入与输出n类属关系UML的术语和概念 p 注释释n注释是附加在元素或元素集上，用来表示约束或注释的图形符号 UML的术语和概念 p 协协作n协作是一组类、接口和其他元素的群体，它们共同工作，提供比各组成部分的功能总和更强的合作行为UML的术语和概念 p 对象n对象(Object)代表了类的一个特定实例，具有身份(Identity)和属性值(Attribute Values)n为了与上下文中的其他对象相区别，每个对象都应该有一个名字对象可以用3种方式命名：对象名、对象名和类名、或只用类名UML的术语和概念 p 消息n消息是对象间的通信，它传达了要执行动作的信息，它能触发事件。

UML的术语和概念 p 接口n接口是用来规定类或组件服务的操作的集合n接口可以有名字，以与其他的接口相区分实践中，接口名通常是从问题域的词汇表中抽取出的短名词或名词词组n和类一样，接口可以参与类属关系、关联关系和依赖关系另外，接口还可以参与实现关系UML的术语和概念 n接口的符号如图所示有3中表示方法第一种是图标（Icon）形式，第二种是修饰（Decoration）形式，第三种是标签（Label）形式对于后两种表示方法，还可以将属性、或操作、或两部分都隐藏起来UML的术语和概念 p 类型n类型是类的构造型，用于描述对象的域UML的术语和概念 p 角色n角色是一个参与特定语境的实体的行为UML的术语和概念 p 实例n实例是抽象的具体表示，对它可使用一组操作，它有用来存储操作结果的状态l名称l操作l状态l主动对象l连接l类范围的属性和操作l暂时UML的术语和概念 p 事件n事件是对一个在时间和空间上占有一定位置的有意义的事情的规格说明l种类 l消息信号l调用UML的术语和概念 p UML的扩充机制nUML支持自身的扩充与调整，以便使其与一个特定的方法、组织或用户相一致，UML中包含3种主要的扩充组件：原型、标记值和约束。

l原型：能够说清领域中的词汇，且看起来仍像原有构造块的新事物l标记值：为UML事物增加新的特性l约束：增加新的语义或改变已存在的规则UML的术语和概念 p 状态机n说明对象在生命期中响应事件所经历的状态序列，以及它们对事件的响应l状态：对象生命期中的一个条件或状况，在此期间，对象将满足某些条件，执行某些活动，或等待某些事件l初态：状态机或子状态的缺省开始位置；l终态：状态机或外围状态的执行已经完成l转换：一个转换是两个状态之间的一种关系，表示对象将在第一个状态中执行一定的动作，并在某个特定事件发生而某个特定的条件满足时进入第二个状态UML的术语和概念 p 时间和空间n时间标记：表示事件发生时刻的符号，由交互中的消息名形成的表达式n时间表达式：用来判断绝对或相对时间值的表达式n时间约束：关于绝对或相对时间值的语义陈述n位置：一个构件在一个节点上的位置n实时系统：是时间关键系统事件可以在规则或不规则的时间发生；对一个事件的响应必须在可预料的绝对时间或者相对于事件本身的时间发生UML的术语和概念 p UML的内容nUML语义nUML表示法p UML的构成n元素l结构元素：模型的静态部分，描述概念或物理元素。

包括类、接口、协作、用例、主动类、组件和节点l行为元素：模型的动态部分，描述跨越时间和空间的行为包括交互和状态机l分组元素：模型的组织部分，如包l注释元素：模型的解释部分，用来描述、说明和标注模型的任何元素，如注解2.1.4 UML的组成 n关系 关系说明元素之间的相互联系，即事物之间的联系，在面向对象建模中，有四种很重要的关系：l依赖(Dependency)关系l类属(Generalization)关系l关联(Association)关系l实现(Realization)关系UML的组成 n图 图是由一组元素和关系组成的连通图，包括静态结构图和动态行为图l类图l对象图l组件图l配置图l用例图UML的组成 l顺序图l协作图l状态图l活动图2.2 UML的关系 依赖关系 类属关系 关联关系 实现关系 2.2.1 依赖关系p 依赖关系描述了类之间的使用关系p 如果一个模型元素发生变化会影响另一个模型元素（这种影响不必是可逆的），那么就说在这两个模型元素之间存在依赖关系p 例如：有两个元素X、Y，如果修改元素X的定义会引起对元素Y的定义的修改，则称元素Y依赖于元素X依赖关系p 依赖关系的UML符号表示是带箭头的虚线，指向被依赖的模型元素。

依赖关系p在类图中，依赖可以由许多原因引起，例如，一个类向另一个类发送消息（也即，一个类的操作调用另一个类的操作），或者一个类是另一个类的数据成员，或者一个类是另一个类的某个操作参数，那么就可以说这两个类之间存在着依赖关系p语义上，所有的关系（包括关联关系、类属关系、实现关系）都是各种各样的依赖关系，因为这3种关系具有很重要的语义，所以在UML中被分离出来成为独立的关系2.2.2 类属关系p 类之间的类属关系表示子类继承一个或多个父类的结构与行为类属关系描述了类之间的“是一种”（is-a-kind-of)的关系,类属关系用来连接一般类与特殊类，用来描述父类与子类或父与子的关系，子类继承父类的特性，尤其是属性和操作p 类属关系的UML符号表示是带空心箭头的实线，箭头指向父元素 一个类可以有零个到多个父类，没有父类且有一个 或多个子类的类被称为根类或基类 没有子类的类被称为叶类 如果在继承关系中，每个类只能有一个父类，则是单继承 如果一个类有多于一个的父类存在，则被称为多继承 2.2.3 关联关系p关联关系是一种结构关系，规定了一种事物的对象可以与另一种事物的对象相连p例如，雇员为公司工作，一个公司有很多部门，就可以认为雇员和公司、公司和部门之间存在某种语义上的联系，在类图模型中，就可以在类Employee(雇员）和类Company(公司)、类Company(公司)和类Department(部门）之间建立关联关系。

p关联关系的UML符号表示是一条实线关联关系p 可以应用于关联关系的四种基本修饰是：n名称：描述关系的性质n角色：关联中靠近它一端的类对另外一端的类呈现的职责n阶元（Multiplicity)：说明一个关联的实例中有多少个相互连接的对象n聚合(Aggregation)：整体对象拥有部分对象关联名通常是一个动词或动词词组，用来表示关联关系的类型或目的所选择的关联名应该有助于理解该模型p 关联关系中的相关术语和概念n角色n阶元n导航n聚合关系n组合关系n关联类n可见性n限定符n接口说明符关联关系2.2.4 实现关系p 实现关系是分类器之间的语义关系，一个分类器规定合同，另一个分类器保证实现这个合同p 可以在两种情况下使用实现关系：n实现被用在接口与实现它们的类或组件之间；n实现被用在用例和实现该用例的协作之间p 实现关系的UML符号表示是一条带有空心箭头的虚线2.3 用例图 用例图概述 用例图的构成 用例图的应用 2.3.1 用例图概述p 参与者触发用例，并与用例进行信息交换单个参与者可以和多个用例连接，一个用例也可以与多个参与者连接p 对同一个用例而言，不同参与者有着不同活动：可以从用例获取值，也可以输出信息到用例中。

p 在参与者和用例之间存在的关联关系通常被称为通信关联，因为它代表着参与者与用例之间的通信用例图概述p不带箭头的线段代表关联是双向导航（从参与者到用例，并从用例到参与者）；带箭头的线段代表关联是单向导航（从参与者到用例，或从用例到参与者），导航的方向表明了是参与者发起了和用例的通信还是用例发起了和参与者的通信p用例捕捉了系统的行为但没有规定怎样实现这些行为，这一点很重要，因为系统分析（规定行为）应该尽可能多地不被实现的细节（规定怎样执行行为）所影响p最终，用例需要被实现，在UML中用来实现用例的元素是协作（Collaboration) 协作是一起工作以实现用例行为的类和其他元素构成的群体，显式说明用例的实现2.3.2 用例图的构成p 参与者n在UML中，参与者代表与系统交互的人、硬件、或另一个系统，是用例使用者与用例交互时所扮演的角色参与者的UML符号表示是图示的“小人”，并可在符号下标出参与者名参与者可以只向系统输入信息或只从系统接受信息，也可以既可以输入信息给系统，还可以接受系统的输出信息参与者与参与者之间也可以存在类属关系n为了准确获取用例，首先需要识别系统的参与者，可以通过问题的答案来帮助发现系统的参与者。

n识别参与者须注意的问题：l尽管参与者在用例图中是用类似人的图形来表示，但参与者并不一定必须是人l参与者代表角色l一个实体可以扮演多种角色（参与者），在确定实体的参与者身份时，应考虑其所扮演的角色，而不是实体的头衔或名称l角色不是对职位建模用例图的构成p 用例n用例描述了系统所执行的一组动作序列，系统执行该动作序列来为参与者产生一个可供观察的结果n用例的UML符号表示是椭圆，并可在符号下标出用例名n在实践中，用例的名字通常是用动词词组命名从问题域中发现的一些行为n用例表示了系统的功能，也就是系统提供给参与者的功能系统的用例构成了系统的所有使用功能用例图的构成用例图的构成n构造一个好的用例应该遵循的原则：l一个用例应该描述一个从头至尾的完整的功能，用例要与参与者交互n用例的获取是需求分析时首先要做的工作，大部分用例将在需求分析时产生，并且随着工作深入会发现更多的用例，这些都应及时添加到已有的用例集中用例集中的每个用例都是一个潜在的需求n参与者的识别对识别用例很有用面对一个大系统，可先列出参与者清单，再对每个参与者列出它的用例，问题就会容易很多n在识别出了参与者后，可以通过一些问题的答案来帮助发现系统的用例。

用例图的构成n对于每个用例，都可以用事件流来规定用例的行为用例的事件流。