1、UML实用技术,V1.0,软件开发过程详解,目前的现实是什么？业务建模 在这个现实下，开发系统是为了达到什么目标？愿景 为了达到目标，系统应对外提供什么样的功能和性能？需求为了提供这些功能，系统内部应该有什么样的核心业务机制？分析 为了满足性能，系统的核心机制如何在选定的架构上实现？设计,找 到 问 题,解 决 问 题,UML三个主要作用（1）,使用可视化建模来获取并表现商业逻辑和对象,使用可视化建模来分析和设计计算机应用程序,理由一：UML是客户、系统分析员和程序员之间的“桥梁”,用例图 活动图 状态图,时序图 对象图 部署图 ,UML三个主要作用（2）,理由二：UML从客户的角度将复杂的系
2、统整理清楚,UML三个主要作用（3）,software,可移植,技术交互,性能,全面,容量,稳定性,错误处理,容错性,功能需求,成本,兼容性,理由三：UML能使越来越复杂的软件 系统架构更加合理和健壮,系统模型可由“4+1”视图展现,模型可由9个图来展现,模型,墨绿色表示动态图 粉红色表示静态图 （可把用例图单列出来）,UML9种图,用例图：业务建模、需求、测试 类图：业务建模、分析、设计 对象图：业务建模、分析、设计 组件图：设计 部署图：设计顺序图：业务建模、分析、设计 协作图：业务建模、分析、设计 状态图：需求、分析、设计 活动图：业务建模、设计,结构,行为,敏捷建模原则：需要时再添加,
3、可互换,可互换,主要步骤,识别执行者,执行者（Actor）在系统之外，透过系统边界与系统进行有意义交互的任何事物。,识别执行者,执行者要点： 系统外必须和它交互 系统边界直接与系统交互 有意义的交互属于目标系统的责任 任何事物人、外系统、外部因素、时间,识别执行者,思路： 谁使用了系统的主要功能？ 谁改变了系统的主要数据？ 谁从系统获取信息？ 谁需要系统的支持以完成日常工作任务？ 谁负责维护、管理并保持系统正常运行？ 系统需要应付（处理）哪些硬件设备？ 系统需要和哪些外部系统交互？ 谁（或什么）对系统运行产生的结果感兴趣？ 有没有自动发生的事件？,识别执行者,责任类似或重叠抽象出执行者,识别用
4、例,用例的基本定义：用例实例是在系统中执行的一系列动作，这些动作将生成特定执行者可见的价值结果。一个用例定义一组用例实例。Ivar Jacobson（RUP）,通俗地讲：执行者通过系统达到某个目标,步骤,目标,路径,识别用例,用例要点： 价值结果有意义的目标 系统执行价值结果由系统生成 执行者可见业务语言，用户观点 一组用例实例用例的粒度,识别用例,有意义的目标：,识别用例,用户观点而非系统观点：,用户观点,系统观点,识别用例,用例命名：执行者视角,动词（+宾语）,状语,定语,识别用例,用例的粒度（3）：四轮马车,任何业务归根到底都可以看作CURD，但光CURD能为Actor提供价值吗？ CR
5、UD是Create（创建）、Read（读取）、Update（更新）和Delete（删除）缩写,警惕CURD泛滥！,识别用例,用例的粒度（3）：四轮马车误区,多个用例会操作同一项数据,识别用例,用例的粒度（6）：灵活处理CURD,也可以把包含复杂交互的路径独立出去形成用例,识别用例,执行者使用这个系统达到什么目标？,语法测试：【执行者】使用系统来【用例】,识别用例,讨论（1）：登录怎么处理？,识别用例,讨论（2）：几个登录？,或,用例文档：更进一步的精度,用例图可以作用例文档的总图进一步的精度：有层次的文档文档中每一句话都有其价值,书写用例文档,用例的内容,用例编号：用例名 执行者 前置条件 后
6、置条件 涉众利益 基本路径 1XXXX 2XXXX 3XXXX 扩展 2a.XXXX 2a1.XXXX 字段列表 业务规则 非功能需求 设计约束 待解决问题,书写用例文档,涉众利益,利益的冲突,银行的,用户的,法律的,谁的？,书写用例文档,路径交互步骤的描述,只写“可观测的” 使用主动语句 句子必须以执行者或系统作为主语 每一句都要朝目标迈进 分支和循环 不要涉及界面细节,书写用例文档,字段列表,+ 数据序列 可选项 * 多个 | | | 可能取值 A=B 把B的结构赋给A,可以用自然语言，也可以用表达式,书写用例文档,字段列表,注册信息=公司名+联系人+电话+联系地址* 联系地址=州+城市+
7、街道+邮编 保存信息=注册信息+注册时间 客房状态=空闲|已预定|占用|维修中,用表达式,书写用例文档,可用性,系统应易于使用第一次使用时30分钟内能学会添加员工（任务时间） 5次击键能完成客人入住服务，不需要使用鼠标（操作次数） 80%的用户认为系统易学，并且使用效率高（用户调查）系统界面应如XX附件所示的屏幕图像（小心）,可用性需求的表达,？,通过关系整理用例,用例的关系,扩展：分离扩展路径,包含：提取公共步骤，便于复用,泛化：同一业务目的的不同技术实现,通过关系整理用例,包含关系的误用,通过关系整理用例,除此之外，不能有别的关系！,类图解说,识别类及其属性审查,属性是否描述类对象的特征属
8、性是否存在冗余是否有复杂结构的属性是否有1对多的属性属性是否对类的所有对象都有意义,识别类及其属性审查,属性是否描述类对象的特征,类的属性什么的什么 什么的什么的什么 什么的什么的什么的什么,识别类及其属性审查,属性是否存在冗余,常见冗余如：出生年月年龄,识别类及其属性审查,是否有复杂结构的属性,识别类及其属性审查,复杂结构属性的处理,1:1可以在原类中展开 1:N独立出去形成关联,识别类及其属性审查,复杂结构属性的处理,识别类及其属性审查,是否有1对多的属性,识别类及其属性审查,属性是否对类的所有对象都有意义,识别类之间的泛化,识别思路,A的对象总是B的对象，B的对象也总是A的对象 A的对象
9、总是B的对象，B的对象有时是A的对象（*） A的对象从来不是B的对象，B的对象也从来不是A的对象 A和B之间有一些共同的属性（*）,识别类之间的关联,关联的几种表现形式,思考：与用例关联种类的区别？,识别类之间的关联,聚合 vs. 组合,组合/部分容器/内容集合/成员,识别类之间的关联,关联的几种表现形式,识别类之间的关联,绘制关联关系,识别类之间的关联,要点（2）：自反关联,识别类之间的关联,关联类,关联本身可以有自己的属性和操作关联类,或,识别类之间的关联,警惕“数据库”习惯,关联类也要有业务意义,识别类之间的关联,警惕“数据库”习惯,不是拥有“外键”，而是拥有“对象”,三种版型的类,在分
10、析阶段 边界类：用例的每个执行者映射一个边界类 责任：输入、输出、过滤控制类（可选）：一个用例映射一个控制类 责任：控制事件流，负责为实体类分配责任实体类：一个用例有多个实体类参与，一个实体类可以参与多个用例 责任：业务行为的主要承载体,顺序图解说,顺序图和类图的映射,顺序图绘制要点（Rose）（1）,顺序图绘制要点（Rose）（4）,顺序图绘制要点（Rose）（5）,责任分配原则,原则1：专家（Expert）原则原则2：老板（Boss）原则原则3：可视（Visibility）原则,结束语,软件质量是设计出来的，而不是测试出来的！设计思想是比开发语言更重要的东西！现在还有不少程序员在使用Java语言来进行结构化编程，使用Rose进行面向功能的分析！Rose不仅仅是OO的设计工具，更重要的是通过用例、类图和顺序图三者来实现OO的思考！我们呢,
