《UML完整例子.ppt》由会员分享，可在线阅读，更多相关《UML完整例子.ppt（38页珍藏版）》请在三一文库上搜索。
1、UML完整例子,书籍管理系统分析与设计,1.需求描述,小王是一个爱书之人，家里各类书籍已过千册，而平时又时常有朋友外借，因此需要一个个人图书管理系统。 该系统应该能够将书籍的基本信息按计算机类、非计算机类分别建档，实现按书名、作者、类别、出版社等关键字的组合查询功能。,需求描述,在使用该系统录入新书籍时系统会自动按规则生成书号，可以修改信息，但一经创建就不允许删除。 该系统还应该能够对书籍的外借情况进行记录，可对外借情况列表打印。 另外，还希望能够对书籍的购买金额、册数按特定时间周期进行统计,2.类图的设计 - （1）发现类,小王是一个爱书之人，家里各类书籍已过千册，而平时又时常有朋友外借，因
2、此需要一个个人图书管理系统。 该系统应该能够将书籍的基本信息按计算机类、非计算机类分别建档，实现按书名、作者、类别、出版社等关键字的组合查询功能。,发现类,在使用该系统录入新书籍时系统会自动按规则生成书号，可以修改信息，但一经创建就不允许删除。 该系统还应该能够对书籍的外借情况进行记录，可对外借情况列表打印。 另外，还希望能够对书籍的购买金额、册数按特定时间周期进行统计,（2）筛选备选类,“小王”、“人”、“家里”很明显是系统外的概念，无须对其建模； 而“个人图书管理系统”、“系统”指的就是将要开发的系统，即系统本身，也无须对其进行建模； 很明显“书籍”是一个很重要的类，而“书名”、“作者”、
3、“类别”、“出版社”、“书号”则都是用来描述书籍的基本信息的，因此应该作为“书籍”类的属性处理，而“规则”是指书号的生成规则，而书号则是书籍的一个属性，因此“规则”可以作为编写“书籍”类构造函数的指南。,筛选备选类,“基本信息”则是书名、作者、类别等描述书籍的基本信息统称，“关键字”则是代表其中之一，因此无需对其建模； “功能”、“新书籍”、“信息”、“记录”都是在描述需求时使用到的一些相关词语，并不是问题域的本质，因此先可以将其淘汰掉； “计算机类”、“非计算机类”是该系统中图书的两大分类，因此应该对其建模，并改名为“计算机类书籍”和“非计算机类书籍”，以减少歧义；、,筛选备选类,“外借情况
4、”则是用来表示一次借阅行为，应该成为一个候选类，多个外借情况将组成“外借情况列表”，而外借情况中一个很重要的角色是“朋友”借阅主体。 虽然到本系统中并不需要建立“朋友”的资料库，但考虑到可能会需要列出某个朋友的借阅情况，因此还是将其列为候选类。为了能够更好地表述，将“外借情况”改名为“借阅记录”，而将“外借情况列表”改名为“借阅记录列表”；,筛选备选类,“购买金额”、“册数”都是统计的结果，都是一个数字，因此不用将其建模，而“特定时限”则是统计的范围，也无需将其建模；不过从这里的分析中，我们可以发现，在该需求描述中隐藏着一个关键类书籍列表，也就是执行统计的主体。,（3） 得到候选类,在使用“名
5、词动词法”寻找类的时候，很多团队会在此耗费大量的时间，特别是对于中大型项目，这样很容易迷失方向。其实在此主要的目的是对问题领域建立概要的了解，无需太过咬文嚼字,（4）关联分析，建模，多重性分析，再建模,（5） 职责分析,书籍类：从需求描述中，可找到书名、类别、作者、出版社；同时从统计的需要中，可得知“定价”也是一个关键的成员变量。 书籍列表类：书籍列表就是全部的藏书列表，其主要的成员方法是新增、修改、查询（按关键字查询）、统计（按特定时限统计册数与金额）。 借阅记录类：借阅人（朋友）、借阅时间。 借阅记录列表类：主要职责就是添加记录（借出）、删除记录（归还）以及打印借阅记录,类图,（6） 限定
6、与修改,导航性分析：Book与BookList之间、BorrowRecord和BorrowList之间是组合关系均无需添加方向描述，而Book与BorrowRecord之间则是双方关联，也无需添加约束： Book对象创建后就不能够被删除只能被修改，因此在Book类边上加上用自由文本写的约束 ； 一本书要么属于计算机类，要么属于非计算机类，因此在ItBook和OtherBook间加了 “Xor”约束限定符： 一本书只有一册，因此只能够被借一次，因此对于一本Book而言只能有一个RecordId与其对应,限定分析,3.绘制用例图,用例图的绘制流程,（1）记录需求特性表,（2）识别参与者,已有的上下
7、文关系图（表示系统范围）及其他相关模型：它们描述了系统与外部系统的边界，从这些图中可以寻找出与系统有交互关系的外部实体。 项目相关人员分析：对项目的相关人员进行分析，就能够决定出哪些人将会与系统进行交互。 书面的规格说明和其它项目文档（如会谈备忘录等）,识别参与者,需求研讨会和联合应用开发会议的记录：这些会议的参与者通常是很重要的，因为他们在组织中所代表的角色就是可能与系统发生交互的参与者。 当前过程和系统的培训指南及用户手册：这些东西中经常会有潜在参与者。,（3）合并需求获得用例,（4）用例图,（5）细化用例描述搭框架,1.用例名称：新增书籍信息（UC01） 2.简要说明：录入新购书籍信息，
8、并自动存储建档。 3.事件流： 3.1 基本事件流 3.2 扩展事件流 4.非功能需求 5.前置条件：用户进入图书管理系统。 6.后置条件：完成新书信息的存储建档。 7.扩展点：无 8.优先级：最高（满意度 5，不满意度5）,（6）细化用例描述填血肉,3.事件流： 3.1 基本事件流 1）图书管理员向系统发出“新增书籍信息”请求； 2）系统要求图书管理员选择要新增的书籍是计算机类还 是非计算机类； 3）图书管理员做出选择后，显示相应界面，让图书管理员输入信息，并自动根据书号规则生成书号； 4）图书管理员输入书籍的相关信息，包括：书名、作者、 出版社、ISBN号、开本、页数、定价、是否有CDRO
9、M； 5）系统确认输入的信息中书名未有重名； 6）系统将所输入的信息存储建档。,细化用例描述填血肉,3.2 扩展事件流 5a）如果输入的书名有重名现象，则显示出重名的书籍，并要求图书管理选择修改书名或取消输入； 5a1）图书管理员选择取消输入，则结束用例，不做存储建档工作； 5a2）图书管理员选择修改书名后，转到5） 4.非功能需求：无特殊要求 ,（7）编写要点,使用简单的语法：主语明确，语义易于理解； 明确写出“谁控制球”：也就是在事件流描述中，让读者直观地了解是参与者在控制还是系统在控制； 从俯视的角度来编写：指出参与者的动作，以及系统的响应，也就是从第三者观察的角度； 显示过程向前推移：
10、也就是第一步都有前进的感（例如，用户按下tab键作为一个事件就是不合适的）；,编写要点,显示参与者的意图而非动作（如果只描述了动作，人们不能够很容易地直接从事件流描述中理解用例）； 包括“合理的活动集”（带数据的请求、系统确认、更改内部、返回结果）； 用“确认”而非“检查是否”，例如“系统确认所输入的信息中书名未有重名”； 可选择地提及时间限制； 采用“用户让系统A与系统B交互”的习惯用语； 采用“循环执行步骤x到y，直到条件满足”的习惯用语。,4.绘制交互图,首先根据自己的喜好和实际的表现需要来选择顺序图或通信图。 不过由于它们在语义上是等价的，因此可以绘制出一种，再通过建模工具来自动转换成
11、另一种图 。,（1）准备工作,分析模型中的交互图彻重于分析类的职责分配和交互流程，而设计模型中的交互图则彻重于设计类的引入和实际方法的调用与流程控制 先确定参与交互的对象、对象之间的关系（通信图），然后确定对象间的消息交互流程（用同步调用、异步消息、返回消息表示），并利用交互片断（顺序图）或迭代标记及监护条件来表示循环和分支结构,（2）鲁棒分析,Robustness分析不是UML模型的一部分，它是一个强大的草图工具，是介于分析和设计之间的一种有效工具 在Robustness分析中，将应用边界类、控制类和实体类 从一个用例中抽取三类对象的方法：,鲁棒分析从事件流开始,鲁棒分析寻找边界对象,图书管
12、理员向系统发出“新增书籍信息”请求主窗口、“新增书籍信息”按钮 系统要求图书管理员选择要新增的书籍是计算机类还是非计算机类书籍类别列表框。 图书管理员做出选择后，显示相应界面，让图书管理员输入信息，并自动根据书号规则生成书号“新书信息录入”窗口及辅助的“提交”按钮,鲁棒分析寻找控制对象和实体对象,根据事件流中的步骤5，以及扩展路径的描述，就可以在原图上增加相应的控制对象，得到更进一步的分析图,鲁棒分析寻找控制对象和实体对象,新添两个逻辑：一是基本事件流中的步骤2、3要求根据用户选择的类别，自动获得书号；二是当书名重复性检查没有通过（有重名），则应返回要求其重输,（3）构建交互模型,（4）转换成通信图,组件图,