面向对象分析和设计课件

1、高级软件工程陈宁江2007.101面向对象方法概述面向对象的分析和设计方法基于UML的面向对象分析与设计2什么是面向对象（ Object Oriented ，OO）？面向对象是一种风范（Paradigm），是一种观察和分析问题的方法论（Methodology）从本质上来说，面向对象方法是确定动作的主体在先（先确定系统中的对象），执行动作在后（再确定在这些对象上可能实施的操作）传统的面向过程的程序设计，最关心的是过程 面向对象技术：是一种软件系统设计的工程技术，将“对象”作为软件系统的基本组成单元，将数据及其上作用的操作一起封装，以标准的接口规范对外提供服务 3面向对象技术的基本观点 客观世界是

2、由对象组成的从动态观点看，对对象施加的操作就是该对象的行为具有相同数据和相同操作的对象可以归并为一个类，对象是类的一个实例对象之间通过消息传递相互联系类具有封装性类可以派生出子类，子类继承父类的全部特性，又可以有自己的新特性4面向对象技术的发展历史初始阶段（ 60年代末80年代中期）挪威，Simula语言：引入了类的概念和继承机制Xerox，Smalltalk语言发展阶段（ 80年代中期到90年代）面向对象编程语言的繁荣： C+、Object Pascal、Java等成熟阶段（90年代中期以后）面向对象分析和设计方法的发展与规范： Booch方法、Rumbaugh的OMT方法、Coad/You

3、rdon方法、 Jacobson的OOSE方法 等形成一整套面向对象软件工程体系5面向对象方法的优点 按照人类的自然思维方式建立软件系统模型，有利于理解和交流在整个开发过程中采用统一的概念和模型表示，使开发活动之间平滑过渡 对象所具有的封装性和信息隐蔽等特性，容易实现软件复用易于维护，体系结构易于理解、扩充和修改6面向对象的基本概念对象（Object）由一组属性和在这些属性数据上的容许操作对组成类（Class）封装（Encapsulation）继承（Inheritance）多态性（Polymorphism）消息（Message）7面向对象的基本概念 1. 对象（object） 对象是指一组属性

4、以及这组属性上的专用操作的封装体 属性（attribute）通常是一些数据，有时它也可以是另一个对象。每个对象都有它自己的属性值，表示该对象的状态。对象中的属性只能通过该对象所提供的操作来存取或修改。 操作（operation）（也称方法）规定了对象的行为，表示对象所能提供的服务。 一个对象通常由对象名、属性和操作三部分组成。 82. 类（class） 类是一组具有相同属性和相同操作的对象的集合。一个类中的每个对象都是这个类的一个实例（instance）。 类是创建对象的模板，从同一个类实例化的每个对象都具有相同的结构和行为。轿 车型号：字符串颜色：字符串牌照号：字符串张经理的轿车型号=桑塔纳

5、颜色=红色牌照号=沪AN2037类实例对象9 封装（encapsulation）：一种信息隐蔽技术，用户只能看见对象封装界面上的信息，对象的内部实现对用户是隐蔽的。 封装的目的：使对象的使用者和生产者分离，使对象的定义和实现分开。 继承（inheritance）： 继承是类间的基本关系，它是基于层次关系的不同类共享数据和操作的一种机制。 父类中定义了其所有子类的公共属性和操作，在子类中除了定义自己特有的属性和操作外，可以继承其父类（或祖先类）的属性和操作，还可以对父类（或祖先类）中的操作重新定义其实现方法。 10 矩形长宽对角线计算面积计算对角线 多边形顶点数顶点坐标计算面积旋转交通工具飞行器

6、汽 车 船轿 车货 车 一般-特殊关系继承的例子 11 如果一个子类只有唯一一个父类，这个继承称为单一继承。 如果一个子类有一个以上的父类，这种继承称为多重继承。 水上交通工具 陆上交通工具 水陆两栖交通工具多重继承12 多态性（polymorphism） 指同一个操作作用于不同的对象上可以有不同的解释，并产生不同的执行结果。 例如“画”操作，作用在“矩形”对象上，则在屏幕上画一个矩形，作用在“圆”对象上，则在屏幕上画一个圆。 相同操作的消息发送给不同的对象时，每个对象将根据自己所属类中定义的这个操作去执行，从而产生不同的结果。 13if 条件 then p := t ; else p :=

7、r ;area := p.getarea ;getArea abstractpolygonareahexagongetArearectanglegetArealengthwidthtrianglegetAreaVar p : polygon ;Var t : triangle := triangle.new ;Var r : rectangle := rectangle.new ; 14面向对象的软件工程面向对象的分析（OOA）：分析和理解问题域，找出类及对象，分析它们的内部构成和外部关系面向对象的设计（OOD）：运用面向对象技术进行软件设计面向对象的编程（OOP）：用面向对象的编程语言将设计

8、模型转换成程序面向对象的测试（OOT）：运用OO技术进行以对象概念为中心的软件测试，以类作为基本测试单位面向对象的维护（OOM）15喷泉模型 迭代和无间隙特征迭代：各开发活动常常重复工作多次，相关的功能在每次迭代中随之加入演进的系统无间隙：开发活动之间不存在明显的边界16 面向对象分析一般步骤如下：获取客户对系统的需求：包括标识场景（scenario）和用例（use case），建造需求模型用基本的需求为指南，选择类和对象（包括属性和操作）定义类的结构和层次建造对象-关系模型建造对象-行为模型利用用例/场景来复审分析模型 17 面向对象设计系统设计子系统划分选择实现数据管理、界面支持和任务管理

9、的设计策略为系统设计合适的控制机制复审并考虑权衡对象设计在过程级别设计每个操作的实现细节定义内部类为类属性设计内部数据结构消息设计 使用对象间的协作和对象-关系模型，设计消息模型复审 复审设计模型并在需要时迭代18代表性的OO分析与设计方法Booch方法Rumbaugh的对象模型化技术(OMT)Coad和Yourdon方法Jacobson的OOSE(面向对象软件工程)19面向对象的建模语言UML统一建模语言（Unified Modeling Language，UML）：一种直观化、明确化、构建和文档化软件系统产物的可视化建模语言 20UML是什么？UML是Booch 、OOSE和OMT方法的结

10、合，同时吸收了其他方法的思想UML是一种语言UML是一种可视化的建模语言UML是一种可用于详细描述的语言UML是一种构造语言UML是一种文档化语言21UML的主要组成视图（View）：用于构造系统模型图（Diagram）：用于描述视图模型元素：用于表示图的一组符号22UML中的视图（View）用例视图（Use Case View）：描述系统应该具有的功能集设计视图（Design View）：描述系统功能的内部设计和协作情况，包括静态结构和动态行为进程视图（Process View）：描述系统的并发工作状况，包含并发与同步的线程和进程实现视图（Implementation View）：描述系统的

11、实现模块（组件或者文件）及其之间的关系部署视图（Deployment View）：描述系统的物理架构和硬件拓扑结构的节点23UML中的图（Diagram）系统功能：用例图静态结构：类图；对象图动态行为：状态图；时序图；协作图；活动图物理架构：组件图；分布图 24视图与图主题域视图 （view）图（diagram）结构化静态视图类图（class）设计视图内部结构（internal structure）协作图（collaboration）构件图（component）用例视图用例图（use case）动态的状态机视图状态机图（state machine）活动视图活动图（activity）交互视图顺序

12、图（sequence）通信图（communication）物理的部署视图部署图（deployment）模型管理模型管理视图包图（package）25模型元素 模型元素指模型中的实体以及实体间相互连接的关系 部分模型元素注解类属性操作对象：类属性操作状态用例 结点供应接口包依赖关联泛化主动类属性操作请求接口构件实现26UML2.0与1.4的比较对UML1.4进行了一些扩充。用更为受限的通信图代替了协作图。 增加了交互综述图、定时图、协议状态图、组成结构图等新图。27简单的UML例子例子描述：在Web浏览器中，编写JAVA程序Hello，World！ import java.awt.Graphic

13、s;class HelloWorld extends java.applet.Applet public void paint (Graphics g) g.drawString(Hello, World！, 10,10);28HelloWorld的UML图HelloWorld类HelloWorld及其相关类HelloWorld的继承层次29HelloWorld的UML图（续）HelloWorld包Paint的顺序图HelloWorld构件30基于UML的分析、设计和实现 描述需求：使用用例来确定用户需求和系统必须为用户提供的服务静态建模：根据需求建立系统的静态模型动态建模：描述系统的动态行为

14、31一、 用例模型和用例图32现代需求实践实践名称描述用例(Use case)描绘一个系统外在可见的需求情况，是代表系统中各个项目相关人员之间就系统的行为所达成的契约用户故事(user story)由客户参与编写，说明他们需要系统为他们做什么，一般用客户的术语编写，其长度约为三句话左右共性：站在用户的角度看待系统、定义系统 ；使用用户能够看懂的语言来表述 33需求获取采用场景和用例的技术，是需求获取过程中弥补多个具有不同背景的执行者团队之间代沟的有力工具场景：表达了用户和系统之间的一系列交互，描述了一个系统实例用例：是对一类场景所进行的抽象场景和用例两者一般均用自然语言描述，这一形式对用户而言

15、是易于理解的34用例用例(use case)是Ivar Jacobson发明的. 其它的中文译名有: 用况、用案等.定义1: 用例是对一个活动者(actor)使用系统的一项功能时所进行的交互过程的一个文字描述序列.定义2: 用例是系统、子系统或类和外部参与者交互的动作序列的说明, 包括可选的动作序列和会出现异常的动作序列.用例是代表系统中各个项目相关人员之间就系统的行为所达成的契约.35 1）分析员首先标识使用该系统的不同的执行者（执行者，actor），这些执行者代表使用该系统的不同的角色。 每个执行者可以叙述他如何使用系统，或者说他需要系统提供什么功能 2）执行者提出的每一个使用场景都是系统

16、的一个用例的实例，一个用例描述了系统的一种用法（或一个功能），所有执行者提出的所有用例构成系统的完整的需求 注：执行者与用户是不同的两个概念，一个用户可以扮演几个角色（执行者）；一个执行者可以是用户，也可以是其他系统（应用程序或设备）采用用例收集客户需求36需求获取的活动（1）标识执行者（2）标识场景（3）标识用例（4）求精用例（5）标识用例之间的关系（6）标识非功能需求（7）绘制用例图，编写详细的用例描述37用例图用例图包含的模型元素执行者(actor)：与系统进行交互的外部实体。可以是人或者其它系统用例：描述系统提供的功能（从外部视点角度）模型元素之间的关系执行者之间：继承关系执行者与用例

17、之间：关联关系用例之间：继承、扩展和包含关系38执行者 是指与系统交互的人或其他系统，它代表外部实体。使用用例并且与系统交互的任何人或物都是执行者。执行者代表一种角色，而不是某个具体的人或物。在用例图中用直线连接执行者和用例，表示两者之间交换信息。39执行者的种类系统用户与所建造的系统交互的其他系统一些可以运行的进程 硬件设备时钟执行者是为了完成一个事件而与系统交互的实体，是用户相对系统而言所演的角色。执行者不仅可以由人承担，还可以是事物40执行者的例子1）其它软件系统：当系统需要与其它系统交互时，如ATM柜员机系统中，银行后台系统就是一个执行者；2）硬件设备：如果系统需要与硬件设备交互时，如

18、在开发IC卡门禁系统时，IC卡读写器就是一个执行者；3）时钟：当系统需要定时触发时，时钟就是执行者41执行者间的关系在用例图中，使用泛化关系来描述多个执行者之间的公共行为。 执行者间的泛化关系示例：执行者实际上是一个类, 因此它们之间可以存在一定的关系42如何标识 执行者需要注意： 大多数执行者在系统开发之前就已经存在执行者是在系统边界之外的，即它们是来自外部的；任何要使用未来系统的外部软件系统就是一个执行者。 可通过如下问题的提出获取和确认执行者： 系统完成工作后，哪一个用户组受益？谁将使用系统的主要功能？谁需要借助系统的支持来完成日常工作？次要功能由哪一个用户组完成？谁来维护和管理系统与该

19、系统进行交互的外部硬件和软件系统是谁？哪些人或系统对本系统产生的结果（值）感兴趣？43例子：学生注册课程系统某大学准备开发一个学生课程注册系统：学生使用该系统查询新学期将开设的课程和讲课教师情况，选择自己要学习的课程进行登记注册，并可以查询成绩单教师使用该系统查询新学期将开设的课程和选课学生情况，并可以登记成绩单注册管理员使用该系统进行注册管理，包括维护教师信息、学生信息和课程信息等在每个学期的开始，学生获得该学期的课程目录表，课程目录表列出每门课程的所有信息，诸如基本信息、教师、开课系和选课条件等新学期开始前两周为选课注册时间，在此期间学生可以选课注册，并且允许改变或取消注册申请，开学两周后

20、注册管理员负责关闭课程注册。每个学生可以选择不超过4门课程，同时指定2门侯选课程以备主选课程未选上。每门课程最多不能超过10人，最少不能低于3人，低于3人选课的课程将被取消。一旦学生的注册过程完毕，注册系统将有关信息提交收费系统以便学生付费。如果在实际注册过程中名额已满，系统将通知学生在提交课程表之前予以更改在学期结束时，学生可以存取系统查看电子成绩单。由于学生成绩属于敏感信息，系统必须提供必要的安全措施以防非法存取 44发现执行者问题： 谁使用系统的功能？ 谁需要借助系统完成日常工作？ 谁来维护和管理系统，以保证系统正常工作？ 系统控制的硬件设备有哪些？ 系统需要与其他哪些系统交互？ 谁对系

21、统产生的结果感兴趣？45用例 用例：是能够被执行者感受到的、系统将完成的一系列动作，是一个完整功能这些动作除了完成系统内部的计算工作外，还包括与执行者通信。用例通过关联与执行者连接关联指出一个用例与哪些执行者交互46用例的特征用例代表某些用户可见的功能，以实现一个具体的用户目标用例总是被执行者启动的，执行者必须直接或间接地指示系统去执行用例，用例向执行者提供可识别的输出通过关注谁启动了某一个用例，可标识出前面未注意到的新执行者用例必须是完整的，描述了一系列从初始情况出发的相关交互用例是一个类，它代表一类功能而不是使用该功能的某个具体实例。用例的实例称为“场景”47用例图举例48用例的命名从执行

22、者的角度出发进行命名（如使用“登录”而不用“身份验证”）使用动宾结构或主谓结构命名.尽量使用行业术语（如用“报销”，而不用“交钱”）例: 字处理程序中, “置正文为黑体”和”创建索引”都可以是用例.例: 在一个银行业务系统中可能有如右的用例浏览账户余额列出交易内容划拨资金49学生注册课程系统中的用例 50如何标识 用例 执行者需要系统提供哪些功能？ 执行者自身需要做什么？ 执行者是否需要读取、创建、删除、修改或存储系统中的某类信息？ 系统中发生的事件需要通知执行者吗？ 执行者需要通知系统某些事情吗？ 从功能观点看，这些事件能做什么？执行者的日常工作是否因为系统的新功能而被简化或提高了效率？系统

23、需要哪些输入输出？输入来自何处？输出到哪里去？当前使用的系统（可能是人工系统）存在的主要问题是什么？ 51注意事项（1）开发者使用系统的用户手册、过程手册、公司标准、用户日志和计划表，以及与用户和客户交谈的记录等来回答问题。开发者应该使用应用领域中的词汇而非自己专业领域的词汇写出场景。当开发者更加深入地了解了应用领域且决定了要采用的可能技术后，可采用迭代和增量方式求精场景。在标识执行者和标识场景期间，开发者要做的最重要工作是理解这些应用领域。52注意事项（2）不要将所有的需求都以用例的形式表示出来.用例只描述系统功能性方面的需求, 它只量全部需求的一部分.本质上用例分析是功能分解技术, 但目前

24、是OO开发的第一步.用例是与实现无关的关于系统功能的描述.53标识用例图中的关系关系说明记号关联执行者与他所参与的一个用例之间的通信路径。表示了用例执行期间的信息流扩展扩展的用例到基本用例的一种关系，它指出扩展的用例所定义的行为如何插入到基本用例所定义的行为中包含指出包含用例定义的行为被包含在基本用例所定义的行为中继承一个一般用例与一个更特殊的用例之间的关系，特殊用例可继承一般用例的特征 extendinclude54关联关系表示参与者用例之间进行通信。 不同的参与者可以访问相同的用例。 55包含关系客户用例可以简单地包含提供者用例具有的行为，并把它所包含的用例行为作为自身行为的一部分。 56

25、包含关系在对系统进行分析时，通常会发现有些功能在不同的环境下都可以被使用。在编写代码时，我们希望编写可重用的构件，这些构件包括诸如可以从其他代码中调用或参考的类库、子过程以及函数。包含关系是指一个用例(客户用例)的行为包含了另一个用例(提供者用例)的行为.客户用例可以简单地包含提供者用例具有的行为，并把它所包含的用例行为作为自身行为的一部分。57注意: 箭头方向为客户用例到提供者用例.包含关系的例子58a.如果有多个用例，并且这些用例包含大量类似的行为，应该考虑将这些类似的行为通过包含关系包含到用例中，将这个功能分解到另一个用例中b.对两个或多个互相独立的用例建模时做了重复的工作，可以通过包含

26、关系包含这些重复的工作c.如果某个行为可能会引入冗余，或者，当行为发生变化时可能导致不一致性，这时，应该对这种行为进行孤立建模并将它包含到用例中 使用包含关系的情况59扩展关系当某个新用例在原来的用例基础上增加了新的步骤序列，则原用例被称作基用例，这种关系被称为扩展关系。扩展用例被定义为基础用例的增量扩展。基础用例提供扩展点以添加新的行为。扩展用例提供插入片段以插入到基础用例的扩展点上。 60a.两个用例相似但不完全相同时b.当要对多个额外情况逐一建模时，可以使用扩展关系，用一个独立的用例替代每个额外的情况c.如果用例涵盖了所有的情况变化，则该用例将会变得十分复杂，应该考虑使用扩展关系 常见的

27、扩展关系61基本用例(扩展关系中)扩展用例(扩展关系中)基本用例(包含关系中)包含用例(包含关系中)网上购物的部分用例扩展关系例子62泛化关系父用例也可以被特别列举为一个或多个子用例。 子用例表示父用例的特殊形式。 子用例从父用例处继承行为和属性，还可以添加行为或覆盖、改变继承的行为。63泛化关系的例子64用例图举例65“扩展”与“包含”的区别(1/2)两种关系都意味着从几个用例中抽取那些公共的行为并放入一个单独的用例中，而这个用例被其他用例包含或扩展两种关系的目的不同：通常在描述一般行为的变化时采用扩展关系在两个或多个用例中出现重复描述又想避免这种重复时，可以采用包含关系根本区别：在包含关系

28、中，源用例没有目的用例就不能工作，而被包含用例可以独立存在；在扩展关系中，源用例即使没有目的用例也能工作得很好，而目的用例通常只能作为扩展的用例而存在。泛化和扩展表示用例之间的 “is a”, 包含关系表示用例之间的“has a”.66“扩展”与“包含”的区别（2/2）67扩展关系中，基用例可以单独存在，但在一定的条件下，它的行为可以被另一个用例的行为延伸。扩展只能发生在基用例的序列中某个特定的点上，这个点叫扩展点扩展关系的基本含义与泛化关系类似, 但对扩展用例有更多限制, 即基本用例必须声明若干”扩展点”, 扩展用例只能在扩展点上增加行为和含义.扩展关系与泛化关系68用例图的绘制流程69记录

29、需求特性表编号说明FEAT01新增书籍信息 FEAT02修改已有的书籍信息 FEAT03书籍信息按计算机类、非计算机类分别建档 FEAT04录入新书时能够自动按规则生成书号FEAT05计算机类与非计算机类书籍采用不同的书号规则FEAT06录入新书时如果重名将自动提示FEAT07按书名、作者、类别、出版社等关键字组合查询书籍FEAT08列出所有书籍信息FEAT09记录外借情况FEAT10外借状态能够自动反应在书籍信息中FEAT11按人、按书查询外借情况FEAT12列出所有的外借情况FEAT13按特定时间段统计购买金额、册数FEAT14所有查询、列表、统计功能应可以单独对计算机类或非计算机类进行7

30、0合并需求获得用例特性用例FEAT01.新增书籍信息FEAT03.书籍信息按计算机类、非计算机类分别建档FEAT04.录入新书时能够自动按规则生成书号FEAT05.计算机类与非计算机类书籍采用不同的书号规则FEAT06.录入新书时如果重名将自动提示UC01.新增书籍信息FEAT02.修改已有的书籍信息UC02.修改书籍信息FEAT07.按书名、作者、类别、出版社等关键字组合查询书籍FEAT08.列出所有书籍信息FEAT14.所有查询、列表、统计功能应可以单独对计算机类或非计算机类进行UC03.查询书籍信息FEAT09.记录外借情况FEAT10.外借状态能够自动反应在书籍信息中UC04.登记外借

31、信息FEAT11.按人、按书查询外借情况FEAT12.列出所有的外借情况FEAT14.所有查询、列表、统计功能应可以单独对计算机类或非计算机类进行UC05.查询外借信息FEAT13.按特定时间段统计购买金额、册数FEAT14.所有查询、列表、统计功能应可以单独对计算机类或非计算机类进行UC06.统计金额和册数71用例分析的基本步骤找出系统外部的参与者和外部系统, 确定系统边界和范围确定每一个参与者所期望的系统行为把这些系统行为命名为用例使用泛化、包含、扩展等关系处理系统行为的公共或变更部分编制每一个用例的脚本绘制用例图区分主要事件流和异常事件流, 如果需要, 可以把异常事件流处理为单独的用例细

32、化用例图, 解决用例间重复与冲突的问题.72用例的描述（1/2）用例描述是指对一个用例的功能进行的文字描述, 是参与者与系统交互动作序列的说明.用例描述才是用例的主要部分, 是后续的交互图分析和类图分析必不可少的部分.用例采用自然语言描述参与者与系统的交互行为,要易于理解. 其读者是开发人员、用户、项目经理、测试人员等.73用例的描述（2/2）用例的目标用例是怎么启动的参与者与用例之间的消息如何传送用例中除了主路径外, 其它路径是什么用例结束后系统的状态其它需要描述的内容用例描述一般包括的内容：描述用例时的原则是尽可能写得“充分”, 而不是形式化、完整或漂亮.74用例图的描述执行者的简要描述

33、客户：向公司订购商品的人 客户代表：公司处理客户请求的雇员 库存系统：记录公司库存的软件用例的简要描述 订购货物：客户创建一个新的请求商品的订单，并为那些商品付费 取消订单：客户取消一个已经存在的订单75 用例的详细描述 用例通常用正文来描述，也可用活动图来描述 。 用例的正文描述应包括以下内容：用例的目的：用例的最终目的是什么？它试图达到什么？用例是如何启动的：哪个执行者在什么情况下启动用例的执行？执行者和用例之间的事件流：用例与执行者之间交换什么消息或事件来通知对方改变或恢复信息？描述系统与执行者之间的主事件流是什么？以及系统中哪些实体被使用或修改？用例中可供选择的流：用例中的活动可根据条

34、件或异常（exception）有选择地执行。如何结束用例：描述何时可认为用例已结束。76事件流是用例完成需求行为的事件描述事件流的目的是：建立用例中逻辑流程的文档，详细描述系统用户的工作和系统本身的工作，既包括正常状态下系统完成需求行为的事件，也包括在其他状态下不能完成需求行为的事件用例的事件流77用例的描述模板用例名称参与的执行者目标：简要描述用例的最终任务和结果前置条件：此用例开始执行的前提条件事件流：是从执行者的角度看，列出用例的各个步骤。包括基本流程和可选流程用例是怎样启动的；角色和用例之间的信息处理过程用例在不同的条件下，可以选择执行的多种方案特殊需求后置条件：此用例执行结束的条件和

35、结果78描述用例的例子79事件流可分为两部分：基本路径 基本路径是运转正常时的路径，是一系列没有分支和选择的简单陈述句可选路径 可选路径是指不同于基本路径而允许不同的事件序列的路径。 对于明显有可能随时发生的事情来说，可选路径非常有效。事件流的路径80如订购货物用例的基本路径：事件流：基本路径1. 当客户选择订购货物时，用例开始2. 客户输入他的姓名和地址3. 当客户输入产品代码时a. 系统给出产品描述和价格b. 系统往客户订单中添加该物品的价格 循环结束4. 客户输入信用卡支付信息5. 客户选择提交6. 系统检验输入的信息，把该订单作为未完成的交易保存，同时向记账系统转发支付信息7. 当支付

36、确认后，订单就被标记上已经确认，同时返回给客户一个订单ID，用例结束81 如果在订购货物用例中，客户可以在提交订单前随时取消订单，其可选路径如下：可选路径：在选择提交前任何时候，客户都可以选择cancel。这次订购没有被保存，用例结束。在基本路径第6步，如果有任何不正确的信息，系统提示客户去修改这些信息。在基本路径第7步，如果支付没有被确认，系统将提示客户改正支付信息或者取消。如果客户选择修改信息，就回到基本路径第4步；如果选择取消，用例结束。82用例写作简单指南 用例应该使用动词短语命名。用例名字应该说明用户要努力完成什么。 使用名词短语对执行者进行命名。 系统的边界是清晰的。由执行者完成的

37、步骤和由系统完成的步骤是可以进行区分的。事件流中的用例步骤表达成主动语态,这将直接说明是谁完成了这一步骤。前后步骤之间的因果关系是清晰的。异常情况应该另外描述。用例描述不涉及系统的用户接口。从长度上讲，一个用例不能太长。否则，可使用包含关系和扩展关系分解成较小的用例。83描述用例时易出现的错误只描述系统的行为, 没有描述参与者的行为只描述参与者的行为, 没有描述系统的行为在用例描述中就设定了对用户界面的设计的要求描述过于冗长84Use case: Withdraw cashActor: customer主事件流：储户插入ATM卡,并输入密码储户按“取款”按钮,并输入取款数目储户取走现金/ATM

38、卡/收据储户离开Use case: Withdraw cashActor: customer主事件流：ATM系统获得ATM卡和密码设置交易类型为“取款”ATM系统获得取款金额输出现金、收据和ATM卡系统复位用例的描述例子（1/2）ATM系统“取款”用例的两个错误描述：只描述了actor的行为只描述了System的行为85用例的描述例子（2/2）Use case: Withdraw cashActor: customer主事件流：储户通过读卡机插入ATM卡ATM系统从卡上读取银行ID、账号、加密密码, 并通过主银行系统验证银行ID和账号储户输入密码, ATM系统根据加密密码对输入密码进行验证储户

39、按 “取款”按钮, 并输入取款数目, 该数目应该为$5的倍数ATM系统通知主银行系统, 传递账号和金额, 并接收返回的确认信息和账户余额ATM系统输出现金、ATM卡和收据ATM系统记录交易到日志文件ATM系统“取款”用例的正确描述：86用例建模实例实现一个简化的银行储蓄账户管理系统，该系统是在银行的柜台上对客户办理活期储蓄业务。系统的需求陈述如下：一个客户可以在多个银行中开设账户，一个客户也可在同一银行中开设多个不同的账户。客户可以通过银行职员进行开户、存款、取款、转账、注销账户等活动。其中转账指客户将自己的某个账户上的钱款转入同一银行的不同账户（称为银行内转账）或转入不同银行的账户（称为银行

40、间转账）。系统管理员负责系统的账户管理及业务报表的生成。87识别执行者客户：到银行办理储蓄业务的人，负责输入密码银行职员（客户代理）：银行工作人员，代表客户进行储蓄业务的操作银行职员（管理人员）：银行工作人员，根据客户的储蓄业务更新账户管理员：银行计算机的管理人员，负责账户的管理和业务报表的生成88识别用例从系统的需求陈述可知：银行职员（客户代理）需要系统提供开户、存款、取款、转账、注销账户等功能，这些功能都包含了校验密码的功能。系统管理员需要系统提供账户管理和报表生成功能。银行职员（管理人员）则参与了账户管理中的更新账户的功能。转账功能可分为银行内转账和银行间转账，它们可设计成继承了基本转账

41、用例89银行储蓄账户管理系统包含包含包含银行职员（用户代理）账户管理银行间转账开户取款银行内转账注销存款校验密码转账报表生成其它银行账户管理系统客户系统管理员银行职员（管理人员）90开户用例描述用例名称：开户参与的执行者：银行职员（客户代理），客户前置条件：一个合法的银行职员（客户代理）已登录到该系统事件流：1.当选择开户功能时用例开始2.输入客户信息（姓名、地址、身份证号等）3.从账户管理系统获取新的账号4.请客户输入密码5.请客户再次输入密码6.如果两次密码不一致则回到第4步，否则继续7.在账户库中添加新账户8.打印存折，用例结束后置条件：在账户库中增加了一个新账户，得到一张新存折 91用

42、例名称：取款参与的执行者：银行职员（客户代理）前置条件：一个合法的银行职员（客户代理）已登录到该系统事件流：基本路径：1.当选择取款功能时用例开始2.当输入客户信息（姓名、账号等）后 a）如果客户信息与账户不一致，显示错误信息，可以重新输入或结束用例 b）如果该账户被冻结，显示冻结信息并结束用例3.输入并校验密码4.输入取款金额，如果该账户的余款小于取款金额，显示错误信息，要求重新输入5.打印取款单，交客户签字6.建立取款事件记录，更新账户信息7. 打印存折，用例结束可选路径：1.在第5步客户签字之前的任何时刻，客户可以取消本次取款，用例结束2.第3步校验密码时，如发现密码不一致，则重新输入密

43、码，或用例结束后置条件：如果取款成功，客户账户中的余额被更新（减少），否则余额不变。92描述取款用例的活动图客户不确认客户确认余额取款额未冻结不一致一致选择重新输入选择结束冻结余额取款额打印取款单输入客户信息显示错误信息建立取款记录更新账户信息打印存折显示错误信息输入取款金额输入并校验密码显示冻结信息93用例模型的用处客户：详细说明系统应有的功能和使用方法开发人员：理解系统的需求，作为后续工作的基础测试人员：验证系统实现是否与用例模型说明的功能一致文档人员：为编写用户手册提供参考94例子：学生注册课程系统某大学准备开发一个学生课程注册系统：学生使用该系统查询新学期将开设的课程和讲课教师情况，选

44、择自己要学习的课程进行登记注册，并可以查询成绩单教师使用该系统查询新学期将开设的课程和选课学生情况，并可以登记成绩单注册管理员使用该系统进行注册管理，包括维护教师信息、学生信息和课程信息等在每个学期的开始，学生获得该学期的课程目录表，课程目录表列出每门课程的所有信息，诸如基本信息、教师、开课系和选课条件等新学期开始前两周为选课注册时间，在此期间学生可以选课注册，并且允许改变或取消注册申请，开学两周后注册管理员负责关闭课程注册。每个学生可以选择不超过4门课程，同时指定2门侯选课程以备主选课程未选上。每门课程最多不能超过10人，最少不能低于3人，低于3人选课的课程将被取消。一旦学生的注册过程完毕，

45、注册系统将有关信息提交收费系统以便学生付费。如果在实际注册过程中名额已满，系统将通知学生在提交课程表之前予以更改在学期结束时，学生可以存取系统查看电子成绩单。由于学生成绩属于敏感信息，系统必须提供必要的安全措施以防非法存取 95（1）发现角色角色是与系统交互的人或事问题： 谁使用系统的功能？ 谁需要借助系统完成日常工作？ 谁来维护和管理系统，以保证系统正常工作？ 系统控制的硬件设备有哪些？ 系统需要与其他哪些系统交互？ 谁对系统产生的结果感兴趣？96（2）发现用例 97（3）描述用例 基本内容：目标：简要描述用例的最终任务和结果事件流：包括基本流程和可选流程 用例是怎样启动的；角色和用例之间的

46、信息处理过程用例在不同的条件下，可以选择执行的多种方案用例在什么情况下才能被视作完成，完成时结果应传给角色 特殊需求前提条件：此用例开始执行的前提条件后置条件：此用例执行结束后，结果应传给什么角色 98描述用例的例子99常见问题分析（1）(1) 用例的粒度问题 对于一个目标系统进行用例分析后得到的用例数目有多少比较合适?100常见问题分析（2）(2) 用例的分解/合并 系统中相似的功能, 是合并为一个用例还是分解为几个用例?方法1一个用例/三个脚本方法2 三个用例101常见问题分析（3）(3) 三层结构如何采用用例表示? (4) 下面哪个用例图正确? 102实例分析：语音邮箱系统目标：构建一个

47、语音邮箱系统问题描述： 语音邮箱系统中,可以为每个系统用户(邮箱主人)分配一个语音邮箱号码. 进行留言时, 拨打语音邮箱系统的主号码, 在听到提示音”请输入邮箱号”后,输入要语音邮箱号,听到主人设定的问候语后,进行留言然后挂断电话. 邮箱主人拨打语音邮箱系统的主号码,在听到提示音”请输入邮箱号”后,输入要语音邮箱号,听到主人设定的问候语后, 输入密码+#进行邮箱管理. 此时系统提供三种服务:1.接收信息; 2.更改问候语; 3.更改密码.其中接收留言包括收听新留言、存储留言、删除留言等。103实例分析：语音邮箱系统1. 找出actor和外部系统,确定系统边界.参与者：呼叫者、邮箱用户2. 主要

48、功能分析(参与者期望的系统行为等)(1). 呼叫者保留信息(留言).(2). 邮箱用户管理信息: 收听/存储/删除.(3). 邮箱用户更改问候语.(4). 邮箱用户更改密码.104实例分析：语音邮箱系统3. 初步找到的用例呼叫者：保留信息邮箱主人：接收信息、更改问候语、更改密码4. 进一步寻找用例邮箱主人：登录邮箱呼叫者、邮箱主人：拨打邮箱号码5. 分析用例之间的关系本例较为简单,只使用“包含关系”即可.105实例分析：语音邮箱系统6. 绘制初步用例图106二、 类图和对象图107分析活动：从用例导出对象 包括： 标识对象将用例映射成对象（使用顺序图）建模对象之间的交互标识对象之间的关系标识对

49、象的属性和行为分析模型评审108标识对象通常陈述中的名词或名词短语是可能的潜在对象，它们以不同的形式展示出来。一些标识对象的准则： 在用例中出现可重复的名词（例如，事件）如果是系统必须跟踪的现实世界中的实体（例如，工作人员，资源），他们生产或消费计算机系统所使用的信息如果是系统必须跟踪的现实世界中的活动、发生的事情或事件（例如，危机处理计划）如果是用例，应产生一个对应的对象如果是数据源和数据汇（例如，打印机），应认真分析角色（如：管理者、工程师、销售员），他们由与系统交互的人扮演组织单位（如：部门、小组、小队），他们与一个应用有关；场所（如：制造场所、装载码头），它们建立问题和系统所有功能的环

50、境与用户进行交互的人工制品（例如，工作站）应引起注意 总是出现在应用域中的术语要特别引起注意109标识对象（续）Abbott提出的启发式准则：将语言成分（名词、进行时、be动词和副词）映射成模型的成分（对象、操作、继承关系和类）语言成分 模型构件实例 专有名词实例人员乙 普通名词类现场工作人员 Doing动词操作创建、提交、选择 Being动词继承是一种, 是其中的一个 Having动词聚集有, 由组成, 包括 情态动词约束必须是形容词属性事件描述 110交叉用例检查参与对象的启发式规则： 哪一个用例创建了这一对象？哪一个执行者可以访问这一信息？哪一个用例可以修改和撤销这一对象？哪一个执行者可

51、以启动这些对象？这一对象是必须的吗？111三对象模型：实体、边界和控制在分析对象模型中，包括了实体对象、边界对象和控制对象三种类型。实体对象：表示系统将跟踪的持久信息。边界对象：表示执行者与系统之间的接口和交互。控制对象：负责用例实现。为了区分不同类型的对象，可以使用UML提供的版类机制描述之，如： ， ， 112实体对象用例中的连续名词（如事件）系统需要跟踪的现实世界中的实体（如现出工作人员，调度者等）系统需要跟踪的现实世界中的活动（如紧急情况操作预案）数据源或数据汇（如打印机）113边界对象 边界对象：表示了系统与执行者之间的接口。边界对象从执行者处收集信息，将之转换成一种可用于实体对象和

52、控制对象的表示形式。 边界对象在一个很粗略的层面上对用户界面进行建模。该模型不描述用户界面可视方面的细节，如像“菜单项”或“滚动条”之类的边界对象就显得太细了。114边界对象（续）一些准则：用户需要的初始用例的用户界面用户需要键入系统的数据表格标识通知和系统用于对用户进行响应的消息注：不要使用边界对象对接口的可视方面进行建模，而应该使用用户原型建模可视用户界面为了描述界面，总是使用最终用户的术语115控制对象 控制对象：负责协调边界对象和实体对象。在现实世界中，控制对象通常没有具体的对应物。通常，控制对象通常在一个实体开始时创建，并在该实体退出时终止。从边界对象处收集信息，并将这些信息分配给实

53、体。116为类和对象命名时的准则使用标准术语。使用具有确切含义的名词。必要时使用名词短语。名字应该是富于描述性的、简洁的而且无二义性的。 117类图 描述系统的结构,用于表示系统中的类以及类与类之间的关系是创建其它图的基础类的描述主要包括：类的属性和操作118类图(续)描述类、接口、协作及它们之间关系的图。显示系统中各个类的静态结构。 119接口 在没有给出对象的实现和状态的情况下对对象行为的描述 包含操作但不包含属性没有对外界可见的关联。 一个类可以实现一个或多个接口接口类：120标识关联 一个关联表示了两个或者多个类之间的关系。标识关联的好处：通过构造对象之间的清晰关系，澄清分析模型使得开

54、发者去发现相关联的边界用例关联的属性关联的名字：选择性的，无需全局唯一关联的角色：标识了每一个类的功能关联的重数：标识了可能的对象实例数目通过检查指示状态的动词或动词词组可以标识出关联121类图中的关联聚集组合关联泛化依赖细化（实现）122类间关联关联分为：普通关联，限定关联，关联类。普通关联：最常见的关联关系，只要类与类之间存在连接关系就可以用普通关联表示普通关联的图示符号是连接两个类之间的直线。关联一般是双向的在一个方向上为关联起一个名字，在另一个方向上为关联起另一个名字，如果关联清晰的话，也可不起名字。为避免混淆，在名字前面（或后面）加一个指示关联方向的黑三角。123有首都国家城市工作于

55、公 司员 工雇佣关联通常是双向的124关联的重数在表示关联的直线两端可以写上重数（multiplicity），重数表示该类有多少个对象与对方的一个对象相连接。重数的表示方法通常有： 0.1： 表示0到1个对象；0.*或*： 表示0到多个对象；1+或1.*：表示1到多个对象；1.15： 表示1到15个对象；3：表示3个对象。如果图中未明确标出关联的重数，则默认重数是1。 125关联的角色在任何关联中，都会涉及到关联对象所扮演的角色（即起的作用），显式标明角色名有助于理解类图 如果没有显式标出角色名，则意味着用类名同时作为角色名 126关联的例子（1）工作于公 司员 工雇佣* 1工作于公 司员 工

56、雇佣* * * 雇佣 *工作于工人1.*老板0.1管理公 司员 工127一个类的对象在不同的关联中扮演不同的角色保险公司人保险合同保险单0.11表示为表达0.*1有涉及婚姻丈夫妻子0.*1.*涉及有保险客户关联的例子（2）128限定关联限定关联：通常用在一对多或多对多的关联关系中，可以把模型中的重数从一对多变成一对一，或将多对多简化成多对一 在类图中把限定词放在关联关系末端的一个小方框内 129关联类为了说明关联的性质，还可以增加一些附加信息引入关联类来记录这些信息关联中的每个连接与关联类的一个对象相联系。关联类通过一条虚线与关联连接。 130导航性（navigability）和链接（link

57、） 选课 学生课程（a） 选课 学生课程（c） 选课 学生课程（b）描述一个对象通过链进行导航访问另一个对象。如果说明一个对象知道另一个对象在哪里，可以加上箭头使用导航性可以降低类间的耦合度。 (可导航的链接在OO语言中常表示为“指针”)包括：单向关联和双向关联。131导航性符号 明确的含义隐含的含义未指明双向可导航右边可导航左边未指明只有右边可导航只有右边可导航只有右边可导航右边未指明左边不可导航只有右边可导航双向可导航双向可导航双向不可导航双向不可导航132聚集 聚集是关联的特例。聚集所表示的类之间的关系是整体与部分的关系。在需求陈述中， “包含”、“组成”、“分为部分”等字句，这往往意味

58、着存在聚集关系聚合（Aggregation）：处于部分方的对象可同时参与多个处于整体方对象的构成组合(composition)：如果部分类完全隶属于整体类，部分的存在依赖于整体。一旦整体类不存在了，则部分类也会随之消失，或失去存在价值133134泛化(generalization) 泛化关系（继承）：通用元素和具体元素之间的一种分类关系。具体元素完全拥有通用元素的信息，并且还可以附加一些其他信息。 135显示计算面积四边形泛化和继承显示六边形显示三角形多边形显示边数顶角座标长宽矩形计算面积136抽象类没有具体对象的类称为抽象（Abstract）类。抽象类通常作为父类，用于描述其他类（子类）的公

59、共属性和行为137依赖依赖关系：描述两个模型元素（类、用例等）之间的语义连接关系：其中一个模型元素是独立的，另一个模型元素不是独立的，它依赖于独立的模型元素，如果独立的模型元素改变了，将影响依赖于它的模型元素。被依赖元素的变化会要求或指示依赖元素的改变例如，友元依赖关系，该关系使得B类的操作可以使用A类中私有的或保护的成员。 138 依赖关系用一个虚线箭头表示，箭头上可附加含关键字的版型，关键字用来指明依赖的种类。 UML 2.0中的依赖种类：access（访问） bind（绑定）call（调用）create（创建）instantiate（实例化）realize（实现）send（发送） tra

60、ce（追踪）use（使用）依赖关系的表示Scheduling Engine依赖关系Box Officeuse139细化（实现）当对不同抽象层次上的同一个事物进行描述时，这些层次描述之间具有细化关系。细化用来协调不同阶段模型之间的关系，常常用于跟踪模型的演变假设两个模型元素A和B描述同一个事物，它们分属不同的抽象层，如果B在A的基础上进行了更详细的描述，则称B 细化了A（或者B实现了A） 140细化关系interfacechoiceBlocksetDefault（choice:Choice）getChoice（）:ChoiceRadioButtonArraysetDefault（choice:B