《{流程管理流程再造}UML实用技术介绍,用例类图时序图开发流程V11》由会员分享，可在线阅读，更多相关《{流程管理流程再造}UML实用技术介绍,用例类图时序图开发流程V11（79页珍藏版）》请在金锄头文库上搜索。
1、Uml实用技术,Unified Modeling Language,我们动手做做练习,UML帮助我们做需求,简单了解UML,UML在设计阶段如何发挥作用,主题,我们动手做做练习,UML帮助我们做需求,简单了解UML,UML在设计阶段如何发挥作用,主题,软件开发过程详解,目前的现实是什么？业务建模 在这个现实下，开发系统是为了达到什么目标？愿景 为了达到目标，系统应对外提供什么样的功能和性能？需求 为了提供这些功能，系统内部应该有什么样的核心业务机制？分析 为了满足性能，系统的核心机制如何在选定的架构上实现？设计,找 到 问 题,解 决 问 题,UML三个主要作用,使用可视化建模来获取并表现商业
2、逻辑和对象,使用可视化建模来分析和设计计算机应用程序,理由一：UML是客户、系统分析员和程序员之间的“桥梁”,用例图 活动图 状态图,时序图 对象图 部署图 ,UML三个主要作用,理由二：UML从客户的角度将复杂的系统整理清楚,UML三个主要作用,software,可移植,技术交互,性能,全面,容量,稳定性,错误处理,容错性,功能需求,成本,兼容性,理由三：UML能使越来越复杂的软件 系统架构更加合理和健壮,系统模型可由“4+1”视图展现,逻辑视图,场景视图,系统功能,分析设计结构,系统并发工作情况,实现视图,实现模块和代码间的关系,部署视图,系统物理拓扑架构,进程视图,4+1视图模型，从5个
3、不同的视角包括包括逻辑试图、进程视图、物理视图、开发视图、场景视图来描述软件体系结构。每一个视图只关心系统的一个侧面，5个试图结合在一起才能反映系统的软件体系结构的全部内容,系统模型可由“4+1”视图展现,系统模型可由“4+1”视图展现,上升到组件概念,系统模型可由“4+1”视图展现,现在公司里不再考虑功能能不能实现，而在于PK性能，可扩展性等非功能性。,系统模型可由“4+1”视图展现,系统模型可由“4+1”视图展现,模型可由9个图来展现,模型,墨绿色表示动态图 粉红色表示静态图 （可把用例图单列出来）,用例图，类图，时序图经常用,UML9种图,UML9种图,UML9种图,用例图：业务建模、需
4、求、测试 类图：业务建模、分析、设计 对象图：业务建模、分析、设计 组件图：设计 部署图：设计 顺序图：业务建模、分析、设计 协作图：业务建模、分析、设计 状态图：需求、分析、设计 活动图：业务建模、设计,结构,行为,敏捷建模原则：需要时再添加,可互换,可互换,主要步骤,我们动手做做练习,UML帮助我们做需求,简单了解UML,UML在设计阶段如何发挥作用,主题,UML之用例图,需求分析中我们如何整理和抽象我们从用户那得到的业务描述。 用流程图描述业务流程、用用例图表达用户业务工作,识别执行者,执行者要点： 系统外必须和它交互 系统边界直接与系统交互 有意义的交互属于目标系统的责任 任何事物人、
5、外系统、外部因素、时间,识别执行者,抽象出执行者的思路： 谁使用了系统的主要功能？ 谁改变了系统的主要数据？ 谁从系统获取信息？ 谁需要系统的支持以完成日常工作任务？ 谁负责维护、管理并保持系统正常运行？ 系统需要应付（处理）哪些硬件设备？ 系统需要和哪些外部系统交互？ 谁（或什么）对系统运行产生的结果感兴趣？ 有没有自动发生的事件？,识别执行者,责任类似或重叠抽象出执行者,UML之执行者,Actor之间也有继承关系。且注意图形表示。,识别用例,用例的基本定义： 用例实例是在系统中执行的一系列动作，这些动作将生成特定执行者可见的价值结果。一个用例定义一组用例实例。 Ivar Jacobson（
6、RUP）,通俗地讲：执行者通过系统达到某个有用目标,步骤,路径,目标,识别用例,设计用例要注意以下要点： 价值结果有意义的目标 系统执行价值结果由系统生成 执行者可见业务语言，用户观点 注意：抽象一组用例实例时控制好用例的粒度,识别用例,有意义的目标：,识别用例,用户观点而非系统观点：,用户观点,系统观点,识别用例,用例命名：执行者视角,动词 （+宾语）,状语,定语,如：批量修改登录记录编号,识别用例,执行者使用这个系统达到什么目标？,语法测试：【执行者】使用系统来【用例】,用例命名：慎用弱动词、弱名词,30,弱动词：进行、使用、复制、加载、重复,弱名词：数据、报表、表格、表单、系统,会掩盖真
7、正的业务,识别用例,识别用例,讨论：几个登录？,或,注意角色的划分和公共用例的定义,要不把用户抽象成三种，或者把登录抽象成三种。,识别用例,用例的粒度：四轮马车,任何业务归根到底都可以看作CURD，但光CURD能为Actor提供价值吗？ CRUD是Create（创建）、Read（读取）、Update（更新）和Delete（删除）缩写,警惕CURD泛滥！,一般要避免全部使用，要抽象，公用的，其它的不要，但默认有。,识别用例,用例的粒度：在四轮马车之前尽量细致,另注：多个用例会操作同一项数据，即对一个数据项操作用例未必是同一个用例,识别用例,讨论：登录怎么处理？（确定用例之间的关系）,用例有先后或
8、前提关系时不要简单认为是简单的包含或者是扩展关系,更进一步的精度,用例图可以作用例文档的总图，进一步的精度：有层次的文档，文档中每一句话都有其价值,通过关系整理用例,用例的关系,扩展：分离扩展路径,包含：提取公共步骤，便于复用,泛化：同一业务目的的不同技术实现,大多数为包含关系,通过关系整理用例,通过关系整理用例,包含关系的误用,通过关系整理用例,通过关系整理用例,通过关系整理用例,用例间不存在“角色与用例”的关系！,通过关系整理用例,书写用例文档,用例的内容,用例编号：用例名 执行者 前置条件 后置条件 涉众利益 基本路径 1XXXX 2XXXX 3XXXX 扩展 2a.XXXX 2a1.X
9、XXX 字段列表 业务规则 非功能需求 设计约束 待解决问题,书写用例文档,涉众利益,利益的冲突,银行的,用户的,法律的,谁的？,书写用例文档,涉众利益,谁关心这个系统, 会涉及到他的什么利益? 对于同一件事情, 不同的人看的视角可能各不相同, 而不同的视角则是基于不同的利益 。 探索系统的需求, 就是探索不同的涉众之间的利益的最佳平衡点 。 涉众的位置不同, 利益会有所不同, 开发人员要从最前排的涉众(老大)的利益为出发点, 否则会影响需求必须明确, 涉众的利益是不会轻易改变的, 稳定的利益关系,书写用例文档,路径交互步骤的描述,只写“可观测的” 使用主动语句 句子必须以执行者或系统作为主语
10、 每一句都要朝目标迈进 分支和循环 不要涉及界面细节,书写用例文档,字段列表,+ 数据序列 可选项 * 多个 | | | 可能取值 A=B 把B的结构赋给A,可以用自然语言，也可以用表达式,书写用例文档,字段列表,注册信息=公司名+联系人+电话+联系地址* 联系地址=州+城市+街道+邮编 保存信息=注册信息+注册时间 客房状态=空闲|已预定|占用|维修中,书写用例文档,可用性,系统应易于使用 第一次使用时30分钟内能学会添加员工（任务时间） 5次击键能完成客人入住服务，不需要使用鼠标（操作次数） 80%的用户认为系统易学，并且使用效率高（用户调查） 系统界面应如XX附件所示的屏幕图像（小心）,
11、可用性需求的表达,？,书写用例的书面格式,其他简单视图,活动图 之 流程图,其他简单视图,活动图 之 泳道图,泳道用于对于多个用户一起完成一个过程，非常有用。,其他简单视图,状态图,我们动手做做练习,UML帮助我们做需求,简单了解UML,UML在设计阶段如何发挥作用,主题,系统详细设计主要目的,详细设计的目的是在具体编写代码前，在代码结构层面上的一次设计，构层面的意思是只要表达出代码的主要属性和方法命名就可以，不必编写方法体代码。 将系统架构实现的功能所涉及到的代码结构都设计出来，这样的做法能够帮助开发人员明确开发思路，且能够较为清楚的了解系统全局结构，作出相应的调整，避免代码开发过程中再去调
12、整代码结构造成的开发资源的浪费。 另一个主要的目的是，将系统的代码结构清晰、直观的描述成文，便于其他开发人员、维护人员对系统的扩展与维护。,Uml语言类图基本画法,1.类设计简单的讲，就是创建一个类然后定义类中的属性和方法。 2.类间关系的设计，包括两个层次包关系设计及类关系设计，两个层次间可以认为是总与分的关系。具体的做法，根据各类间的应用或调用的方式不同明确其之间的关系，类间关系一般分成关联、依赖、累计关系。 3.关系确定规则见以下实例（包关系与类关系基本一致包关系有包中类关系决定）,类中常见的继承表达1,继承通过指向超类的一条闭合的，单箭头的实线表示,类中常见的继承表达2,一个使用树形记
13、号的继承实例,类中常见的接口与实现表达,Professor类和Student类实现Person接口的类图实例,类中常见的关联关系表达,两个类间的双向关联,一个类知道另一个类的属性和方法，前者具有取得后的方法，则形成了单向关联，反之亦然。,类中常见的关联关系表达,两个类间的单向关联,单向关联关系，前者能向后者发送消息取得他的属性,类中常见的关联关系表达,描述两个或多个类的结构性关系。 一个完整的关联定义包含三部分，分别是类之间的关联直线和两个关联端点 主要特性：角色，多重性，导航性 角色：当一个类处于关联的某一端时，该类就在这个关系中扮演了一个特定的角色；角色是关联中靠近它的一端的类对另外一端的
14、类呈现的职责。,类中常见的关联关系表达,多重性：关联角色的多重性是说明一个关联的实例中有多少个相互连接的对象。 导航性：给定两个类的关联，从一个类的对象能够导航到另一个类的对象，导航可以是双向的。,类中常见的关联关系表达,类中常见的依赖关系表达方式,依赖关系中flight中没有customer属性，因此要用其他方法查找coustomer。如果customer是全局的（包含静态方法），则flight知道他的存在。如果coustomer作为参数传递到flight的方法中，则flight能够引用到它，最后，如果customer事例化为flight方法中的本地变量，则flight就引用到了它的存在，在
15、依赖关系中，必须采用三种方法之一,类中常见的关联关系表达,类中常见的聚合关系和组合关系,类中常见的聚合关系和组合关系,聚合：指的是整体与部分的关系。通常在定义一个整体类后，再去分析这个整体类的组成结构。从而找出一些组成类，该整体类和组成类之间就形成了聚合关系。例如一个航母编队包括海空母舰、驱护舰艇、舰载飞机及核动力攻击潜艇等。需求描述中“包含”、“组成”、“分为部分”等词常意味着聚合关系。组合：也表示类之间整体和部分的关系，但是组合关系中部分和整体具有统一的生存期。一旦整体对象不存在，部分对象也将不存在。部分对象与整体对象之间具有共生死的关系。聚合和组合的区别在于：聚合关系是“has-a”关系
16、，组合关系是“contains-a”关系；聚合关系表示整体与部分的关系比较弱，而组合比较强；聚合关系中代表部分事物的对象与代表聚合事物的对象的生存期无关，一旦删除了聚合对象不一定就删除了代表部分事物的对象。组合中一旦删除了组合对象，同时也就删除了代表部分事物的对象。,类中常见的聚合关系和组合关系,我们用浅显的例子来说明聚合和组合的区别。“国破家亡”，国灭了，家自然也没有了，“国”和“家”显然也是组合关系。而相反的，计算机和它的外设之间就是聚合关系，因为它们之间的关系相对松散，计算机没了，外设还可以独立存在，还可以接在别的计算机上。在聚合关系中，部分可以独立于聚合而存在，部分的所有权也可以由几个聚合来共享，比如打印机就可以在办公室内被广大同事共用关联和聚合的区别主要在语义上，关联的两个对象之间一般是平等的，例如你是我的朋友，聚合则一般不是平等的，例如一个公司包含了很多员工，其实现上是差不多的。聚合和组合的区别则在语义和实现上都有差
