1 / 80

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

面向对象的需求分析 余阳 教授 中山大学软件学院. 1. OOA 与 UML 2. 瀑布模型与 OOA 建模 3. RUP 与 OOA 建模 4. 系统愿景 5. 业务建模 6. 系统建模 7. 非功能性需求的定义 8. 案例分析. 0. OOA 与 UML. OOA 的核心是利用面向对象的概念和方法建造需求模型。包含:图形 语言机制 + 面向对象方法学 历史: 60 年代中 Simula 67 ; 80 年代初 Smalltalk ; 80 年代中后期成为软件开发方法。 90 年代中后期, UML( 统一建模语言 )

kipling
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

More Related