Download presentation
Presentation is loading. Please wait.
1
面向对象的需求分析 余阳 教授 中山大学软件学院
面向对象的需求分析 余阳 教授 中山大学软件学院 1. OOA与UML 2. 瀑布模型与OOA建模 3. RUP与OOA建模 4. 系统愿景 5. 业务建模 6. 系统建模 7. 非功能性需求的定义 8. 案例分析
2
0. OOA与UML OOA的核心是利用面向对象的概念和方法建造需求模型。包含：图形语言机制+面向对象方法学 历史：
60年代中Simula 67； 80年代初Smalltalk；80年代中后期成为软件开发方法。 90年代中后期，UML(统一建模语言) OO方法把程序看作是相互协调而又彼此独立的对象的集合。 OO方法强调软件开发过程中面向客观世界中的事物，采用人类认识世界的普遍的思维方法。
3
1. OOA与UML——OO的概念 对象：是现实世界中个体或事物的抽象表示，是其属性和相关操作的封装。
类：某些对象共同特征（属性和操作）的表示。 继承：是现实世界中遗传关系的直接模型，它表示类间的内在联系以及对属性和操作的共享。 聚集：现实世界中部分-整体关系的模拟。 消息：对象与外部世界相互关联的唯一途径。 关联、依赖、多态……
4
1. OOA与UML——UML简介 用于对软件密集型系统的制品进行可视化、祥述、构造和文档化的图形语言，是一种描绘系统蓝图的标准方法。
综合了Grady Booch的Booch方法、Jackson的 OOSE和Rumbaugh的OMT方法，1994年底开始，1998年发布了UML 1.3版。 UML是一种语言，提供了用于交流的词汇表和词汇表中组合词汇的规则。特别着重于对系统进行概念上物理上的可视化描述。主要完成的工作：可视化、祥述、构造、文档化。 使用UML描述系统，可直接得到需求、体系结构、项目计划和源代码等文档。
5
1. OOA与UML——UML的语言机制 图形化的表示机制，十多种视图，分4类： 用例图：用户角度：功能、执行者 静态图：系统静态结构
类图：概念及关系 对象图：某种状态或时间段内，系统中活跃的对象及其关系 包图：描述系统的分解结构 行为图：系统的动态行为 交互图：描述对象间的消息传递 顺序图：强调对象间消息发送的时序 合作图：强调对象间的动态协作关系 状态图：对象的动态行为。状态-事件-状态迁移-响应动作 活动图：描述系统为完成某功能而执行的操作序列 实现图：描述系统的组成和分布状况 构件图：组成部件及其关系 部署图：物理体系结构及与软件单元的对应关系
6
1. OOA与UML——UML语言机制(用例图)
例：
7
1. OOA与UML——UML语言机制(类图)
8
1. OOA与UML——UML语言机制(顺序图)
9
1. OOA与UML——UML语言机制(协作图)
10
1. OOA与UML——UML语言机制(状态图)
11
2.瀑布模型与OOA建模 瀑布模型的OOA过程 用例图 用例 系统用例模型 系统愿景 领域专家 SSD或泳道图 用例图 用例BSD
业务用例模型 领域(概念)模型 操作契约 分析师 系统非功能性需求 系统顶层架构
12
3. RUP与OOA建模——过程与目标 迭代渐进式，四个阶段：
初启：确定目标、范围、粗略估价、决策。识别并简略描述用例、精化10%的用例。几天或一周。 细化：初步需求分析、初步高层设计、部分详细设计、部分原型构造。主要需求通过用例及用例图描述（详细描述90%）和部分用例的产品级实现（20%）；标识重要的风险，并能够精确估算实现每一用例的完成时间。2-6次迭代。 构造：通过迭代完成对所有用例的软件实现。 迭代计划及其原则：业务价值大、风险高、能反映系统架构的用例优先 迭代过程：针对用例的分析、设计、编码、测试、集成 移交
13
3. RUP与OOA建模——敏捷RUP的OOA
14
3. RUP与OOA建模——RUP阶段与任务
15
谁被《财富》杂志评为“20世纪最伟大企业家”？
4. 系统愿景——愿景（Vision） 谁被《财富》杂志评为“20世纪最伟大企业家”？ 让每个家庭都拥有一辆汽车！ 让每个桌面都有一台计算机！
16
4. 系统愿景——概念 系统愿景：客户开发该系统的目的
客户(Customer) vs. 用户(User) vs. 涉众(Stakeholder) 系统愿景决定了系统的需求！ 如果仅允许一份文档、模型或工件来支撑项目，我会选择愿景文档。 －－Philippe Kruchten
17
4. 系统愿景——规则1 规则1：愿景必须来自客户的老大——最有权力的观众、你的衣食父母，他是否高兴很重要！
18
4. 系统愿景——规则1 接触不到“老大”？
19
4. 系统愿景——规则1 愿景不是功能，老大往往不会从功能角度考虑。
20
4. 系统愿景——规则2 规则2：必须指出度量指标
21
4. 系统愿景——规则2 不同维度度量指标之间的排序
22
4. 系统愿景——规则3 规则3：愿景必须恰如其分，换一个项目就不合适
23
4. 系统愿景——规则4 规则4：单独列出涉众高阶目标及利益 谁关心这个系统？会涉及到他的什么利益？
24
4. 系统愿景——规则4 同一件事情，不同的利益视角
25
4. 系统愿景——规则4 开发人员花在前排涉众身上的时间往往不够！ 排序是否正确直接影响需求。 台上演什么戏？由台下各种人角逐而定。
探索系统的需求，就是探索涉众利益之间的最佳平衡点。 越是一线用户，往往排位越低，没有用户的系统，也一样有涉众。
26
4. 系统愿景——其它规则 规则5：保持简捷，最好不超过10条。
27
5. 业务建模 系统“需求”不断变化的根源——来路不正！ 把视角从系统转向组织 网站系统 != 网站组织
没有把系统放在组织中来看，导致得到的系统不符合组织需要 把视角从系统转向组织 系统如何给组织带来好处？讲一个好卖的故事！ 网站系统 != 网站组织
28
5. 业务建模——选定业务组织 愿景波及的需要改进的组织 绝大多数工作流不相干－－太大 很多要改进的地方未涉及－－太小 和老大的职权范围有关
29
5. 业务建模——选定业务组织 从外部看：价值的集合——业务用例图 从内部看：系统的集合——业务序列图
30
5. 业务建模——业务用例图 业务执行者：在组织之外和组织交互的人群或组织 业务工人：在组织的一部分
31
5. 业务建模——业务用例图 业务工人vs. 业务实体（Business Entity）
待开发系统——组织中的一个新的业务实体，以取代现有业务工人或业务实体的一些责任
32
5. 业务建模——业务用例图 组织为业务执行者提供哪些价值？ 注意：业务建模的研究对象是组织！
对外的价值（业务用例）基本不会变化，但内部的实现每次会变化一部分。
33
5. 业务建模——业务用例图 业务流程就是业务用例的实现 组织里发生的一切都是为业务执行者提供价值
34
5. 业务建模——业务用例描述 文字 活动图 序列图 活动图往往只表现动作，序列图强迫思考背后目的，更清晰。
35
5. 业务建模——业务用例描述 消息的名字——代表责任和目的
36
5. 业务建模——业务用例描述 消息的方向——责任委托，不是数据流动
37
5. 业务建模——业务用例描述 不要围着待开发系统编造业务流程
38
5. 业务建模——业务用例描述 只画领域相关的系统
39
5. 业务建模——业务用例描述 把时间看作特殊的业务实体。时间 != 定时器
40
5. 业务建模——业务用例描述 最小单位是人或独立智能系统
41
5. 业务建模——业务改进 原业务用例的业务流程
42
5. 业务建模——业务改进 用新的软件改进原来的业务流程
43
5. 业务建模——业务改进 改进点：改善信息流转
44
5. 业务建模——业务改进 改进点：封装复杂业务逻辑
45
5. 业务建模——业务改进 访问和操作业务对象
46
5. 业务建模——业务改进 改进点，结合愿景，针对每个活动思考： 涉及到信息的流动吗（物流能变成信息流吗）？
包含的业务逻辑能封装到系统里吗？ 涉及到什么业务对象？需要系统管理起来吗？
47
5. 业务建模——抽取系统用例
48
6. 系统建模 系统建模的研究对象是要开发的系统
系统用例：从外部用户的角度看，一个用例是执行者与软件系统间的一次典型的交互作用。从系统内部看：一个用例代表系统执行的一系列动作，且动作结果被外部执行者察觉。 执行者通过系统用例达到某个目标，对解决某个业务问题有价值。 系统执行者：在系统外，与系统作有意义交互的系统
49
6. 系统建模——系统执行者 系统执行者与重要无关
50
6. 系统建模——系统执行者 有意义的交互
51
6. 系统建模——系统执行者 主执行者、辅执行者
52
6. 系统建模——系统用例 用例是“能卖”的价值 期望和承诺、买和卖的平衡点
53
6. 系统建模——系统用例 用例多大？——期望、契约、承诺例多大－－期望、契约、承诺
54
6. 系统建模——系统用例 业务序列图帮助理清责任 智能批假——请假变成了人事系统的用例
55
6. 系统建模——系统用例 命名：动宾结构 慎用弱动词弱名词－－会掩盖真正的业务 命名：不存在“子系统”的用例
弱动词: 进行、使用、复制、加载、生成… 弱名词: 数据、报表、表格、表单、系统… 命名：不存在“子系统”的用例
56
6. 系统建模——系统用例 用例不存在“粒度问题” 最常犯“粒度”错误：把步骤当作用例
57
6. 系统建模——系统用例 四轮马车！ 用有色眼镜看，所有业务最终都会成为CRUD 多问：为什么要CRUD？仅CRUD能为执行者提供价值吗？
58
6. 系统建模——系统用例 业务用例vs. 系统用例 一个业务用例，多个系统用例
59
6. 系统建模——系统用例 业务用例vs. 系统用例 多个业务用例，一个系统用例
60
6. 系统建模——系统用例 用例模版： 基本路径：客户最想看到、最关心的路径。 把基本路径单独分离，凸现用例的核心价值。不要忘记初衷！
用例名 执行者 前置条件 后置条件 涉众利益 基本路径 1…..×××× 2……×××× 3…..×××× 扩展 2a.××××： 2a1….××××× 字段列表 业务规则 非功能需求 设计约束 基本路径：客户最想看到、最关心的路径。 把基本路径单独分离，凸现用例的核心价值。不要忘记初衷！
61
6. 系统建模——系统用例 涉众利益
62
6. 系统建模——系统用例图 执行者与用例间的关系：触发执行/信息交换 用例图中的边 用例之间的关系 执行者-〉用例：表示触发执行/信息交换
用例-〉执行者：用例生成的信息传递给执行者 用例之间的关系 使用(include)关系 扩展关系(extend) 继承关系
63
6. 系统建模——系统用例图 多个用例会操作同一项数据
64
6. 系统建模——系统用例图
65
6. 系统建模——系统用例图
66
6. 系统建模——系统用例图 “高层”用例：错误根源——偷换了研究对象
67
6. 系统建模——建立领域概念模型 机制：类图 UML类图 领域概念模型的建立 UML的类包含：类的名称、属性列表、方法列表。图元：
类之间的关系：继承与泛化、聚集（普通、构成，）、关联关系(稳定性)、依赖关系(临时性) 关联是依赖的强化、聚合是关联的强化、构成是聚合的强化 领域概念模型的建立 标示关键的概念，来源：? 标示概念间的关系 类名 属性名称：类型=初值 操作名称 操作名称(参数表)：返回值类型
68
6. 系统建模——建立领域概念模型(例子)
69
Enteritem(UPC, quantity)
6. 系统建模——SSD SSD：系统顺序图System Sequence Diagram Cashier :System 将系统看做黑盒子 重复直到货物为空 Buy-Item-version 1 Enteritem(UPC, quantity) endSale() makePayment(amount) Actor 系统事件触发了系统操作
70
6. 系统建模——操作契约 操作: 操作名和参数 交叉引用: 此操作发生时所在的系统用例
前置条件:在此任务执行前，对系统或领域模型中对象状态的重要假定。 后置条件: 此操作完成后，领域模型中对象的状态
71
6. 系统建模——操作契约（例） 契约 CO2: enterItem
操作: enterItem(itemID: ItemID, quantity: integer) 交叉引用: Use Cases: Process Sale 前置条件:正在进行销售. 后置条件: 创建了SalesLineItem的一个实例sli.（创建实例） sli 与当前的Sale对象关联 (形成关联). sli.quantity赋值为quantity (修改属性). 基于itemID的匹配，将Sli关联到ProductDescription(形成关联)。
72
6. 系统建模——建立顶层架构(包图) 建立顶层架构的机制：包图 UML包图 包：UML对类进行分组的一种机制 包之间的关系：依赖、构成
连接器：表示包之间的信息传递、事件发送和软件调用关系等，且有单向和双向（无向）之分
73
6. 系统建模——建立顶层架构(模式) 软件顶层架构设计，几种主要架构模式： 流程处理模式 客户/服务器模式 模型-视图-控制器(MVC)
分层模型。
74
6. 系统建模——建立顶层架构(原则) 建立顶层架构过程中要考虑的问题： 架构中包的数量 架构中包的耦合度 软件元素的稳定性
软件元素的必然性 作为软件系统运行环境的物理网络拓扑 软件元素的安全、保密级别 开发团队的技术专长
75
7.非功能性需求的定义 量化描述
76
7.非功能性需求的定义——可用性
77
7.非功能性需求的定义——可靠性 系统应能防范磁盘故障（安全） （对照）系统应采用冗余磁盘阵列
系统应保证收到的数据和发送的数据一致（完整） MTBF（Mean Time Between Failures） MTTR（Mean Time To Repair）
78
7.非功能性需求的定义——性能 系统应在0.5秒之内拍摄超速车的照片（速度） 系统应允许1000个用户同时使用（容量）
在标准工作负荷下，系统的CPU占用率应少于50%（能力）
79
7.非功能性需求的定义——可支持性 95%的紧急错误应能在30工作时内修复 在修复故障时，未修复的相关缺陷平均数应小于0.5
在两年内，以每功能点××的价格升级系统 升级新版本时，应保存所有系统设置和个人设置
80
8. 案例分析 中大软件人才培训中心（简称：中大软培）要开发一个和以下业务相关的计算机系统：
广州市政府为大力发展软件产业，常年委托中大软培举办与软件开发相关的技术培训。参加对象为广州市软件行业的软件开发人员，技术讲座由业界或高校知名专家主讲。市政府向中大软培下达培训任务后，培训主管根据任务需要决定请哪一位专家，并拟定培训计划，交给教务人员执行。教务人员根据培训主管提供的专家资料（职务、擅长领域、 、电话等）更新自己的专家资料Excel文件，然后通过各种方式联系专家，与专家商议培训的时间和主题。确定后，教务人员就要尽快制作好培训网页，在中大软培网站上发布。中大软培还拥有一个邮件列表系统，教务人员也可制作好培训宣传邮件群发。开发人员会在讲座网站上下载报名表WORD文档，填好后 给教务人员，教务人员会把报名表剪贴合并到一个WORD文件中，然后给开发人员回信通知已接受报名，并告知培训相关事项。 培训前一天，教务人员逐个 提醒报名的开发人员准时参加讲座，如果留了手机，还需要短信提醒学员。讲培训当天，学员到达培训地点后，首先要到现场找教务人员签到。教务员查对名单，发放资料。如果来人名单上没有，教务员判断培训教室是否有空位，若有，则现场办理报名（填表或给名片），若无座位，拒绝该人参加。
Similar presentations
