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

第2章统一建模语言UML本章内容2.1UML概述2.2UML的关系2.3用例图2.4类图和对象图2.5交互作用图2.6活动图2.7用例驱动开发2.8RationalRose的安装与使用2.1UML概述建模的目的UML简介UML的术语和概念UML的组成2.1.1建模的目的建模的必要性对于多数程序员而言，在脑海里设想一个软件的实现与用代码来实现这个软件是没有距离的，怎么想，就怎么用代码来实现它。这种做法会产生下列问题：不利于交流。如果不建立模型，软件系统中的有些东西很难用文本的编程语言来表达清楚。如果程序员在修改代码时，没有将他脑海中的模型记录下来，这个信息可能会永远丢失，不便于软件维护。建模的重要性模型是对现实世界的简化，建模是为了更好地理解正在开发的系统。建模原理每一种模型可以在不同的精度级别上表示，最好的模型是与现实相联系的。单个模型是不充分的。对重要的系统应采用一组几乎独立的模型进行建模。面向对象建模从算法的角度建模（结构化）从面向对象的角度建模建模的目的2.1.2UML简介UML的发展UML不仅结合了Booch、OMT和OOSE方法，而且对其做了进一步的发展，统一了符号体系，并从其它的方法和软件工程实践中吸收了许多经过实际检验的概念和技术；UML是GradyBooch、JamesRumbaugh、IvarJacobson和许多其他人员集体智慧的结晶，并最终统一为大众所接受的标准建模语言。UML的特点UML是一种语言UML是一种可视化语言UML是一种可用于详细描述的语言UML是一种构造语言UML是一种文档化语言UML的功能为软件系统的产出建立可视化模型规约软件系统的产出构造软件系统的产出UML简介2.1.3UML的术语和概念系统和模型系统和子系统模型视图用例视图设计视图过程视图实现视图配置视图图系统和子系统包包是一个用来将模型单元分组的通用机制，可以将一个系统看作一个单一的、高级的包。可见性引入与输出类属关系PackageUML的术语和概念注释注释是附加在元素或元素集上，用来表示约束或注释的图形符号。UML的术语和概念协作协作是一组类、接口和其他元素的群体，它们共同工作，提供比各组成部分的功能总和更强的合作行为。UML的术语和概念对象对象(Object)代表了类的一个特定实例，具有身份(Identity)和属性值(AttributeValues)。为了与上下文中的其他对象相区别，每个对象都应该有一个名字。对象可以用3种方式命名：对象名、对象名和类名、或只用类名。objectobject:Class:ClassUML的术语和概念消息消息是对象间的通信，它传达了要执行动作的信息，它能触发事件。UML的术语和概念接口接口是用来规定类或组件服务的操作的集合。接口可以有名字，以与其他的接口相区分。实践中，接口名通常是从问题域的词汇表中抽取出的短名词或名词词组。和类一样，接口可以参与类属关系、关联关系和依赖关系。另外，接口还可以参与实现关系。UML的术语和概念接口的符号如图所示有3中表示方法。第一种是图标（Icon）形式，第二种是修饰（Decoration）形式，第三种是标签（Label）形式。对于后两种表示方法，还可以将属性、或操作、或两部分都隐藏起来objectobject:Class:ClassUML的术语和概念类型类型是类的构造型，用于描述对象的域。UML的术语和概念角色角色是一个参与特定语境的实体的行为。UML的术语和概念实例实例是抽象的具体表示，对它可使用一组操作，它有用来存储操作结果的状态。名称操作状态主动对象连接类范围的属性和操作暂时UML的术语和概念事件事件是对一个在时间和空间上占有一定位置的有意义的事情的规格说明。种类消息信号调用UML的术语和概念UML的扩充机制UML支持自身的扩充与调整，以便使其与一个特定的方法、组织或用户相一致，UML中包含3种主要的扩充组件：原型、标记值和约束。原型：能够说清领域中的词汇，且看起来仍像原有构造块的新事物。标记值：为UML事物增加新的特性。约束：增加新的语义或改变已存在的规则。UML的术语和概念状态机说明对象在生命期中响应事件所经历的状态序列，以及它们对事件的响应。状态：对象生命期中的一个条件或状况，在此期间，对象将满足某些条件，执行某些活动，或等待某些事件。初态：状态机或子状态的缺省开始位置；终态：状态机或外围状态的执行已经完成。转换：一个转换是两个状态之间的一种关系，表示对象将在第一个状态中执行一定的动作，并在某个特定事件发生而某个特定的条件满足时进入第二个状态。UML的术语和概念时间和空间时间标记：表示事件发生时刻的符号，由交互中的消息名形成的表达式。时间表达式：用来判断绝对或相对时间值的表达式。时间约束：关于绝对或相对时间值的语义陈述。位置：一个构件在一个节点上的位置。实时系统：是时间关键系统。事件可以在规则或不规则的时间发生；对一个事件的响应必须在可预料的绝对时间或者相对于事件本身的时间发生。UML的术语和概念UML的内容UML语义UML表示法UML的构成元素结构元素：模型的静态部分，描述概念或物理元素。包括类、接口、协作、用例、主动类、组件和节点。行为元素：模型的动态部分，描述跨越时间和空间的行为。包括交互和状态机。分组元素：模型的组织部分，如包。注释元素：模型的解释部分，用来描述、说明和标注模型的任何元素，如注解。2.1.4UML的组成关系关系说明元素之间的相互联系，即事物之间的联系，在面向对象建模中，有四种很重要的关系：依赖(Dependency)关系类属(Generalization)关系关联(Association)关系实现(Realization)关系UML的组成图图是由一组元素和关系组成的连通图，包括静态结构图和动态行为图类图对象图组件图配置图用例图UML的组成顺序图协作图状态图活动图2.2UML的关系依赖关系类属关系关联关系实现关系2.2.1依赖关系依赖关系描述了类之间的使用关系。如果一个模型元素发生变化会影响另一个模型元素（这种影响不必是可逆的），那么就说在这两个模型元素之间存在依赖关系。例如：有两个元素X、Y，如果修改元素X的定义会引起对元素Y的定义的修改，则称元素Y依赖于元素X。依赖关系依赖关系的UML符号表示是带箭头的虚线，指向被依赖的模型元素。依赖关系在类图中，依赖可以由许多原因引起，例如，一个类向另一个类发送消息（也即，一个类的操作调用另一个类的操作），或者一个类是另一个类的数据成员，或者一个类是另一个类的某个操作参数，那么就可以说这两个类之间存在着依赖关系。语义上，所有的关系（包括关联关系、类属关系、实现关系）都是各种各样的依赖关系，因为这3种关系具有很重要的语义，所以在UML中被分离出来成为独立的关系。2.2.2类属关系类之间的类属关系表示子类继承一个或多个父类的结构与行为。类属关系描述了类之间的“是一种”（is-a-kind-of)的关系,类属关系用来连接一般类与特殊类，用来描述父类与子类或父与子的关系，子类继承父类的特性，尤其是属性和操作。类属关系的UML符号表示是带空心箭头的实线，箭头指向父元素。一个类可以有零个到多个父类，没有父类且有一个或多个子类的类被称为根类或基类。没有子类的类被称为叶类。如果在继承关系中，每个类只能有一个父类，则是单继承。如果一个类有多于一个的父类存在，则被称为多继承。2.2.3关联关系关联关系是一种结构关系，规定了一种事物的对象可以与另一种事物的对象相连。例如，雇员为公司工作，一个公司有很多部门，就可以认为雇员和公司、公司和部门之间存在某种语义上的联系，在类图模型中，就可以在类Employee(雇员）和类Company(公司)、类Company(公司)和类Department(部门）之间建立关联关系。关联关系的UML符号表示是一条实线。关联关系可以应用于关联关系的四种基本修饰是：名称：描述关系的性质。角色：关联中靠近它一端的类对另外一端的类呈现的职责。阶元（Multiplicity)：说明一个关联的实例中有多少个相互连接的对象。聚合(Aggregation)：整体对象拥有部分对象。关联名通常是一个动词或动词词组，用来表示关联关系的类型或目的。所选择的关联名应该有助于理解该模型。关联关系中的相关术语和概念角色阶元导航聚合关系组合关系关联类可见性限定符接口说明符关联关系2.2.4实现关系实现关系是分类器之间的语义关系，一个分类器规定合同，另一个分类器保证实现这个合同。可以在两种情况下使用实现关系：实现被用在接口与实现它们的类或组件之间；实现被用在用例和实现该用例的协作之间。实现关系的UML符号表示是一条带有空心箭头的虚线。2.3用例图用例图概述用例图的构成用例图的应用2.3.1用例图概述参与者触发用例，并与用例进行信息交换。单个参与者可以和多个用例连接，一个用例也可以与多个参与者连接。对同一个用例而言，不同参与者有着不同活动：可以从用例获取值，也可以输出信息到用例中。在参与者和用例之间存在的关联关系通常被称为通信关联，因为它代表着参与者与用例之间的通信。用例图概述不带箭头的线段代表关联是双向导航（从参与者到用例，并从用例到参与者）；带箭头的线段代表关联是单向导航（从参与者到用例，或从用例到参与者），导航的方向表明了是参与者发起了和用例的通信还是用例发起了和参与者的通信。用例捕捉了系统的行为但没有规定怎样实现这些行为，这一点很重要，因为系统分析（规定行为）应该尽可能多地不被实现的细节（规定怎样执行行为）所影响。最终，用例需要被实现，在UML中用来实现用例的元素是协作（Collaboration)。协作是一起工作以实现用例行为的类和其他元素构成的群体，显式说明用例的实现。2.3.2用例图的构成参与者在UML中，参与者代表与系统交互的人、硬件、或另一个系统，是用例使用者与用例交互时所扮演的角色。参与者的UML符号表示是图示的“小人”，并可在符号下标出参与者名。参与者可以只向系统输入信息或只从系统接受信息，也可以既可以输入信息给系统，还可以接受系统的输出信息。参与者与参与者之间也可以存在类属关系。为了准确获取用例，首先需要识别系统的参与者，可以通过问题的答案来帮助发现系统的参与者。识别参与者须注意的问题：尽管参与者在用例图中是用类似人的图形来表示，但参与者并不一定必须是人。参与者代表角色。一个实体可以扮演多种角色（参与者），在确定实体的参与者身份时，应考虑其所扮演的角色，而不是实体的头衔或名称。角色不是对职位建模。用例图的构成用例用例描述了系统所执行的一组动作序列，系统执行该动作序列来为参与者产生一个可供观察的结果。用例的UML符号表示是椭圆，并可在符号下标出用例名。在实践中，用例的名字通常是用动词词组命名从问题域中发现的一些行为。用例表示了系统的功能，也就是系统提供给参与者的功能。系统的用例构成了系统的所有使用功能。用例图的构成用例图的构成构造一个好的用例应该遵循的原则：一个用例应该描述一个从头至尾的完整的功能，用例要与参与者交互。用例的获取是需求分析时首先要做的工作，大部分用例将在需求分析时产生，并且随着工作深入会发现更多的用例，这些都应及时添加到已有的用例集中。用例集中的每个用例都是一个潜在的需求。参与者的识别对识别用例很有用。面对一个大系统，可先列出参与者清单，再对每个参与者列出它的用例，问题就会容易很多。在识别出了参与者后，可以通过一些问题的答案来帮助发现系统的用例。用例图的构成对于每个用例，都可以用事件流来规定用例的行为。用例的事件流是对完成用例规定行为所需要的事件的描述。在描述用例的事件流时，既可以用非正式的结构化文本，也可以用正式的结构化文本，还可以用伪