统一建模语言：第3讲 用例图

统一建模语言班级：B110407-08、B110412-13上课地点：教3－202上课时间：星期二，下午第6、7节星期四，上午第1、2节总学时：48学时。其中：40学时讲课，8学时上机（实验）授课知识点讲课Priestley实验第1讲统一建模语言概述2Ch1、Ch2

第2讲软件开发过程3Ch2、Ch3

第3讲用例图4Ch4第4讲类图和对象图4Ch4、Ch8实验1第5讲活动图4第6讲交互图4Ch5、Ch9实验2第7讲状态机图6Ch6、Ch10实验3第8讲物理图3Ch7、Ch11第9讲模型管理图2总学时：56学时。其中：48学时讲课，8学时上机（实验）授课教材讲课大纲/Plan上机第10讲对象约束语言2Ch12第11讲统一建模语言应用6Ch4~Ch7、Ch13、Ch14实验4

复习课合计48408第3讲:用例图3.0

实验课题：餐馆系统（业务）需求描述第3讲:用例图3.0

实验课题：餐馆系统（业务）需求描述：术语第3讲:用例图3.0

实验课题：餐馆系统（业务）需求描述：业务流程晚间3次餐点简餐17:30~19:30正餐19:45~21:45夜点10:00~11:30预约记录餐桌号、联系人姓名、电话、进餐人数其他允许预约跨时段允许取消预约允许调整预约（时间段、人数变化→餐桌改变）允许不预约，直接进店就餐第3讲:用例图3.0

实验课题：餐馆系统用户期待的系统实现——对计算机化系统的需求功能需求系统实现与手写预约单显示同样信息格式大致相同，员工快速接受记录新的预约修改、删除、查询预约性能需求操作灵活即时更新提高工作效率第3讲:用例图3.0

实验课题：餐馆系统系统开发迭代和增量的开发考虑基本需求，首先实现系统的核心功能，代替现有的手工预约单营业时记录预约顾客到达时更新预约在后期的迭代增量开发中，添加额外的功能第3讲:用例图3.0

实验课题：餐馆系统系统开发：模型驱动的开发（MDD）业务建模：领域模型系统分析：分析模型系统设计：设计模型系统实现：实现模型第3讲:用例图3.0

实验课题：餐馆系统业务建模：用例建模领域模型用例建模：参与者、用例、用例图描述用例组织用例模型完成用例模型领域建模术语表第3讲:用例图3.0

示例课题：EasyLibrary图书馆管理系统1.基本数据维护功能添加或删除读者帐户，修改并且维护读者的基本信息，包括读者的名字、所属院系、学号、读者编号、读者类型、有效期和借阅图书的数量上限等。第3讲:用例图3.0

示例课题：EasyLibrary图书馆管理系统1.基本数据维护功能添加或删除图书信息，更新并且维护它们的信息，包括图书的名称、作者、出版时间、出版社名称、ISBN、类别和预留信息等。第3讲:用例图3.0

示例课题：EasyLibrary图书馆管理系统1.基本数据维护功能第3讲:用例图3.0

示例课题：EasyLibrary图书馆管理系统2.基本业务功能实现读者借书、还书和续接业务如果图书已经借出，要进行预留副本操作。每次用户还书时，还要检验是否是在规定期限内归还。如未按期归还，要收取读者相应罚款。第3讲:用例图3.0

示例课题：EasyLibrary图书馆管理系统2.基本业务功能在进行完上述操作后，要实时更新数据库中的各项记录，这个功能是整个图书馆管理系统的核心。第3讲:用例图3.0

示例课题：EasyLibrary图书馆管理系统2.基本业务功能第3讲:用例图3.0

示例课题：EasyLibrary图书馆管理系统3.数据库管理功能读者信息和图书的信息要实现集中存放，所有数据都要实现统一管理每本图书的借出和归还都要进行详细的登记，以便能够对各个分馆的运作有一个综合、全面的了解，并根据实际情况补充书源不足的部分。第3讲:用例图3.0

示例课题：EasyLibrary图书馆管理系统3.数据库管理功能第3讲:用例图3.0

示例课题：EasyLibrary图书馆管理系统4.信息查询功能根据关键字搜索图书，获得该图书的副本数量、当前状态和图书的其他信息。读者通过验证后，可以查看自己所借图书的清单，借还日期的信息，副本预留信息等。第3讲:用例图3.0

示例课题：EasyLibrary图书馆管理系统4.信息查询功能第3讲:用例图3.0

示例课题：EasyLibrary图书馆管理系统4.身份认证功能数据维护操作只能由系统管理员进行，只有图书馆的工作人员才拥有这样的权限。需要安全管理系统对用户的身份进行验证。第3讲:用例图3.0

示例课题：EasyLibrary图书馆管理系统5.与外部系统交互功能在读者缴纳罚款时，可以采用校园网转账的方式进行支付。第3讲:用例图3.0用例建模1.对语境建模（1）识别系统外部的参与者。（2）将类似的参与者组织成泛化/特殊化的结构层次。（3）必要时为每个参与者提供一个构造型。（4）将参与者放入用例图，说明参与者与用例之间路径。2.对需求建模（1）识别系统外部参与者来建立系统的语境。（2）考虑每一个参与者期望的行为或需要系统提供的行为。（3）把公共的行为命名为用例。（4）分解公共行为，放入新的用例中以供其他的用例使用（5）在用例图中对用例、参与者和它们之间关系进行建模。第3讲:用例图3.0用例建模用例图

用例图是从用户的角度来描述系统所实现的功能，它标明了用例的参与者，同时确定了参与者和用例之间的关联关系。在软件的需求分析阶段，往往采用用例图来建立系统需求模型。第3讲:用例图3.0用例建模用例图

软件需求分析需要开发人员和用户共同完成，经过双方讨论确定第3讲:用例图3.0用例建模用例图三种主要建模元素用例（UseCase）参与者（Actor）依赖、类属和关联关系用例图可选元素注释和约束包系统边界框第3讲:用例图3.0用例建模用例图元素之间的关系（relationship）关联（association）包含（include）扩展（extend）泛化（generalization）第3讲:用例图3.1参与者也称角色、活动者是为了完成某个任务，与系统进行交互的外部实体是相对系统而言，外部实体所扮演的角色参与者表示符号：分类按性质分用户角色硬件设备，如IC卡门禁系统的IC卡读写器时钟，定时触发的时钟其它系统，如ATM柜员机系统和银行后台系统按重要性分，主要参与者和次要参与者第3讲:用例图3.1参与者具有某一种特定功能的角色，参与者是虚拟的概念，它可以是人，也可以是外部系统或设备等。参与用例的执行过程通过向系统输入或请求系统输入某些事件来触发系统的执行由参与用例时所担当的角色来表示每个参与者可以参与一个或多个用例参与者不是系统的一部分，它们处于系统的外部。

第3讲:用例图3.1参与者如何识别参与者？谁向系统提供信息？谁从系统获取信息？谁操作系统？谁维护系统？系统使用了哪些外部资源？系统是否和已经存在的系统交互？第3讲:用例图3.1参与者参与者间的关系在用例图中，使用泛化关系来描述多个参与者之间的公共行为。参与者间的泛化关系第3讲:用例图3.2用例对系统、子系统或类与参与者交互动作序列的说明用例的执行给参与者带来可见的价值是对一组场景（脚本，scenarios)共同行为特征的抽象场景是用例的一次完整、具体的执行过程；是在系统中按照某个顺序执行一系列相关动作，实现某种功能的操作集合多个用例组成系统，参与者以某种场景与系统交互，请求系统执行用例，以获得可见的价值用例与场景的关系，如同类与对象的关系用例表示符号：第3讲:用例图3.2用例用例是对系统行为的动态描述，可增进设计人员、开发人员与用户的沟通，理解正确的需求可以划分系统与外部实体的界限，是系统设计的起点，是类、对象、操作的来源，而通过逻辑视图的设计，可以获得软件的静态结构。

第3讲:用例图3.2用例场景与用例场景：附表用例符号用例描述第3讲:用例图3.2用例：事件流事件流场景中系统行为的一个特定动作序列描述参与者执行用例时，发生的所有可能交互脚本与用例的关系就象实例与类的关系，脚本是用例的一个实例。对一个用例的完整说明，包括：基本事件流(basiccourseofevents)：描述交互时的正常场景扩展事件流，即可选的或例外的事件流(alternativeandexceptionalcoursesofevents)：正常场景之外的情况第3讲:用例图3.2用例用例分析是对系统功能的分解如何确定用例的粒度？如何确定用例的粒度？粒度可大可小，一般一个系统宜控制在20个用例左右用例是系统级、抽象的描述，不是细化的（做什么）复杂的系统可以划分成若干子系统处理。如何确定用例？参与者希望系统执行什么任务？参与者在系统中访问的哪些信息（增删改查）需要将外界的哪些信息提供给系统？需要将系统的哪个事件告诉参与者？如何维护系统？第3讲:用例图3.2用例：关系1.参与者与用例之间的关联（association）关系参与者到用例的单向箭头只表示谁启动用例，不考虑信息的双向流动每个用例都由角色启动，除了包含和扩展用例第3讲:用例图3.2用例：关系2.用例之间的泛化（generalization）关系原因：如果系统中的一个或几个用例是某个一般用例的特殊化时，就需要使用用例的泛化关系。图示：用例中的泛化关系用带空心箭头的实线来表示，箭头的方向指向父用例说明：子用例表示父用例的特殊形式，子用例从父用例继承行为和属性，还可以添加自己的行为，或覆盖、改变所继承的行为。第3讲:用例图3.2用例：关系3.用例之间的包含（include）关系原因：（1）如果两个以上用例有大量一致功能，可将这个功能分解到另一个用例中，其他用例可和这个用例建立包含关系。（2）一个用例功能太多，可用包含关系建模两个小用例。第3讲:用例图3.2用例：关系3.用例之间的包含（include）关系包含关系把几个用例的公共步骤分离成一个单独的被包含用例。通常，把包含用例称为客户用例，被包含用例称作提供者用例。第3讲:用例图3.2用例：关系3.用例之间的包含（include）关系图示：带构造型《include》的虚线箭头由基本用例指向被包含用例两个以上的用例有共同功能，可分解到单独用例，形成包含依赖执行基本用例时，每次都必须调用被包含用例，被包含用例也可单独执行。注：一个用例功能过多需分解成小用例，构成包含依赖。第3讲:用例图3.2用例：关系4.用例之间的扩展（extend）关系

扩展关系是把新行为插入到已有用例的方法基础用例（被扩展用例）提供了一组扩展点，在这些新的扩展点中可以添加新的行为扩展用例提供了一组插入片段，这些片段能够被插入到基础用例的扩展点上第3讲:用例图3.2用例：关系4.用例之间的扩展（extend）关系基础用例（被扩展用例）不必知道扩展用例的任何细节，它仅为其提供扩展点。基础用例即使没有扩展用例也是完整的，这点与包含关系有所不同。第3讲:用例图3.2用例：关系4.用例之间的扩展（extend）关系图示：带构造型《extend》的虚线箭头由被扩展用例指向基本用例一个用例（在某些扩展点上）扩展另一个用例的功能，构成新用例扩展用例依赖于被基本用例，不是单独执行完整的独立用例注扩展用例没有参与者指向，仅仅是个部分片段，不能单独执行，在执行其他用例时，扩展到此用例执行父用例一定会执行包含用例，但执行父用例不一定执行扩展用例第3讲:用例图3.2用例：用例描述作用用例描述的是一个系统做什么（what）的信息，并不说明怎么做（how），怎么做是设计模型的事方式表格形式：附表格模版纯文本格式步骤先进行用例概述，搭建一个框架再进行用例详述，将事件流进行 细化，是否细化或细化到什么程 度由项目的迭代计划来决定第3讲:用例图3.2用例：用例描述第3讲:用例图3.3用例图系统功能模型图，显示系统与外部参与者交互作用图中呈现参与者、用例，以及它们之间的关系对系统、子系统或类的行为进行可视化建模描述用户的功能需求，强调谁在使用系统、系统可以完成哪些功能使用户能够理解如何使用图中元素使开发者能够实现图中元素注用例分析技术是一种公认有效的用户需求获取、分析和描述技术第3讲:用例图3.3用例图建模步骤1）确定系统边界，找出外部参与者和外部系统2）确定每一个参与者所希望的系统行为，命名为用例3）把公共的系统行为分解为新用例，供其他用例使用4）把一些变更的行为分解为扩展用例5）编制用例的脚本（用例描述）6）绘制用例图7）把特殊情况的用例画成单独的子用例图8）验证、评审第3讲:用例图3.3用例图：示例分析（一）餐馆系统1.分析用例分析员与系统用户协商一个用例表示用户使用系统完成一次任务用例的初始清单新增预约信息 ：AddBooking取消预约信息 ：DeleteBooking查询预约信息 ：QueryBooking修改预约信息 ：UpdateBooking记录顾客到来 ：RecordArrival餐桌调换 ：TableTransfer第3讲:用例图3.3用例图：示例分析（一）餐馆系统2.分析参与者个人用户可在不同时期但当一个或多个角色顾客不是系统用户，因此不作为一个参与者参与者的初始清单负责记录预约和取消预约 ：Receptionist顾客到达时，负责分配餐桌和调换餐桌：HeadWaiter第3讲:用例图3.3用例图：示例分析（一）餐馆系统3.初始用例图活动者和用例之间的“关联”关系第3讲:用例图3.3用例图：示例分析（一）餐馆系统4.描述用例

用例“AddBooking”

基本事件流：

1)

接待员(Receptionist)向系统输入要预约的日期

2)

系统显示该日期的预约信息

3)

检查是否有合适的餐桌可以使用，有合适的餐桌，则录入预约信息（餐桌号、顾客姓名、电话号码、预约时间、人数）

4)

系统显示录入的预约信息

5)

结束预约

可选事件流：

1)

接待员(Receptionist)向系统输入要预约的日期

2)

系统显示该日期的预约信息

3)

检查是否有合适的餐桌可以使用，没有合适的餐桌

4)

结束预约

例外事件流：

1)

接待员(Receptionist)向系统输入要预约的日期

2)

系统显示该日期的预约信息

3)

检查是否有合适的餐桌可以使用，有合适的餐桌，但录入人数时，发现餐桌太小容纳不下顾客人数

4)

询问是否继续预约，回答“否”直接结束预约；回答“是”保存预约信息并附有警告标志后，结束预约

用例描述：

1)

用例名称：AddBooking

2)

用例编号：

3)

参与者：Receptionist

4)

事件流：

第3讲:用例图3.3用例图：示例分析（一）餐馆系统4.描述用例

用例“DeleteBooking”第3讲:用例图3.3用例图：示例分析（一）餐馆系统4.描述用例

用例“UpdateBooking”第3讲:用例图3.3用例图：示例分析（一）餐馆系统4.描述用例用例“QueryBooking”第3讲:用例图3.3用例图：示例分析（一）餐馆系统4.描述用例用例“RecordArrival”第3讲:用例图3.3用例图：示例分析（一）餐馆系统4.描述用例

用例“TableTransfer”第3讲:用例图3.3用例图：示例分析（一）餐馆系统5.系统原型设计第3讲:用例图3.3用例图：示例分析（一）餐馆系统6.组织、优化用例模型参与者之间的“泛化”关系用例之间的“依赖”关系“扩展”依赖关系<<extend>>考虑“顾客不预约直接来餐馆就餐”的情况，添加用例“RecordWalk-in”，与“RecordArrival”之间是扩展依赖用例“RecordArrival”与“TableTransfer”之间是扩展依赖“包含”依赖关系<<include>>用例“AddBooking”、“DeleteBooking”、“UpdateBooking”与“QueryBooking”之间是包含依赖用例“RecordWalk-in”与“AddBooking”之间是包含依赖用例“RecordArrival”、“TableTransfer”与“UpdateBooking”之间是包含依赖第3讲:用例图3.3用例图：示例分析（一）餐馆系统6.组织、优化用例模型

完整用例模型第3讲:用例图3.3用例图：示例分析（二）EasyLibrary由于EasyLibrary的需求比较复杂，我们把系统的用例划分为4个功能，它们是：（1）SystemService：包含系统提供给读者的服务（2）SystemAdministration：包括和图书馆