面向对象的需求分析 余阳 教授 中山大学软件学院

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. 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. 系统建模——系统执行者 • 有意义的交互