OOAD,面向对象分析与设计

605940864

贡献于2012-02-26

字数:0 关键词:

1 << OOAD,面向对象分析与设计 >> 教材: 《UML和模式应用(原书第3版)》,Criag Larman,方梁译,机械工业出 版社,2006 参考书: [1] 《Applying UML and Patterns, An Introduction to Object-Oriented Analysis and Design and Unified Process》, Criag Larman, (第三 版,影印版),2006,中国电力出版社 [2] 《UML应用建模实践过程》,尤克滨,2003,机械工业出版社 2 软件工程 面向对象分析与设计 OOA/OOD 面向对象程序设计 OOP (Java/C++/C#) 理论(抽象) 实际(具体) 3 Bloom's Taxonomy of the Cognitive Domain SIX LEVELS Level-1: KNOWLEDGE Level-2: COMPREHENSION Level-3: APPLICATION Level-4: ANALYSIS Level-5: SYNTHESIS Level-6: EVALUATION 4 教学计划 10-16 上午 第一讲:概论,需求用例模型 (ch01~06) 10-16 下午 第二讲:对象分析 (ch09~13) 10-17 上午 第三讲:对象设计 (ch14~17) 10-17 下午 第四讲:对象设计模式(GRASP) (ch19~25) 10-30 上午 第五讲:对象设计模式(GoF) (ch26~31) 10-30 上午 第六讲:分布式报帐系统OOAD (补充案例) 10-31 上午 UML 建模工具的使用/复习 (上机) 10-31 下午 考试 5 上机作业 • 完成 ‛软件学院图书室管理系统‛ 的 OOAD • 3到5人为一组来完成,一人担任组长(自由组合) • 基本功能要求(单机系统) • 新书目录输入 • 图书查询 • 借阅图书 • 归还图书 • 电子版作业内容(一个 MS Word 文件) 1. 小组成员(姓名和学号)及分工 2. OOAD 的 JUDE 模型抓图及文字解说文件 • 用例图 • 用例 • 类图 • 顺序图 • 状态图 6 作业 • 以电子邮件的形式交作业 bobzc@163.com (或bobzc@sohu.com) 2. 请 2010/11/07 以前交,并写明姓名和学号 • 推荐的电子作业文件名格式 SX_10_OOAD_组长名字_手机号.zip 3. 每个收到的作业都会有一个电子邮件形式的确认 考核方法 1. 开卷考试(70%) 2. 笔头作业(30%) 7 第一章: 面向对象分析与设计(引论) 1.1 本书的主要内容 • UML 和对象思想 • UML 是用来绘制软件‘蓝图’的符号语言,是一种思考和交流的工具 • 更重要的是 ‚Thinking in Object” • OOAD 的原则和模式 • OOAD 的目标是设法生成一个高质量的软件‘蓝图’ • 设计中的典型问题经常有成熟的解决方案-模式(Pattern) • 设计中其它问题有设计的指导原则 • 职责驱动的设计(Resposibility-driven design) 8 • 以案例为红线,介绍 OOAD 中用到的概念和技术 • 超市收银机(POS)案例 • 掷骰子游戏案例 • 用例-Use Case • 软件需求模型 • 发现,记录,和交流软件需求的工具 • 软件过程-Software Process • Iterative Development Process,迭代式开发过程 • Unified Process,统一软件过程 • 敏捷建模 9 图 1.1 本书涵盖的主题和技能 Topics and Skills UML notation Requirements analysis Principles and guidelines Patterns Iterative development with an agile Unified Process OOA/D 10 1.2 最重要的学习目标 • 用OOAD开发出的软件系统是由一组相互合作的对象组成 • 很象现实生活中的团队合作 • 应该包含哪些成员? (OOA) • 各个成员的职责是什么? (OOD) • OOAD中最关键,最基本的技能是如何熟练的为软件组件分配职责 • 必不可少的一项活动,且对软件质量影响很大 • 比较难以掌握的一种技能 • GRASP 模式:关于对象设计和职责分配的九项基本原则 11 1.3 什么是分析和设计? • 分析强调的是对问题和需求的调查研究(What?) • 需求分析 - 对需求的调查研究 • 对象分析 - 对领域对象的调查研究 • 设计强调的是一个能满足需求的(概念上的)解决方案(How?) 1.4 什么是 OOAD? • OOA 强调的是在问题领域内去发现对象或概念 • 问题领域指的是需要开发的软件系统的背景领域 • 问题领域随着软件系统的不同而不同 • 问题领域涉及的都是已经存在的实体或概念 • OOD 强调的是如何定义软件对象及他们之间的协作方式来满足需求 • 软件对象大都是受领域对象的启发而得到的 • 在很多情况下软件对象和领域对象一一对应 • 但软件对象之间协作方式的定义却没有这么直观 12 图 1.2 面向对象强调对象的表示 Plane tailNumber public class Plane { private String tailNumber; public List getFlightHistory() {...} } domain concept visualization of domain concept representation in an object-oriented programming language 13 另外一个 OOAD 的例子 14 1.5 OOAD 举例: 掷骰子游戏(软件系统) • OOAD 过程的主要活动 –定义用例 (需求获取) –定义领域模型 (OOA, 对象分析) –定义交互图 (OOD, 对象设计) –定义设计类图 (OOD, 对象设计) 15 • 定义一个用例(简化的例子) • 用例(文字形式的) 用例名: 玩掷骰子游戏 参与者: 玩游戏者 用例描述: 玩游戏者一次掷两个骰子,如果两个骰子的面值相加为七则赢 • 用例图 16 • 定义领域模型 – 在做OOAD时, 我们先创建一个问题域的对象模型,然后在此对象模 型的基础上构建一个求解域的对象模型(软件蓝图) – 问题域的模型的创建是通过识别问题域中的相关概念,概念的属性 和相互关系,并将其用UML符号表示出来而完成的 17 定义交互图 • 利用交互图来探索领域模型中的对象应如何合作来实现软件系统的需求 • 交互图有两种形式(语义等价的) – 顺序图(Sequence Diagram) – 合作图(Collaboration Diagram) • 对象间的合作是通过一个对象向另一个对象发送消息(请求服务)来实现的 :DiceGame play() die1 : Die fv1 := getFaceValue() die2 : Die roll() roll() fv2 := getFaceValue() 18 敏捷式建模(以最简洁的方式快速捕捉灵感) 19 定义设计类图 • 在领域模型概念类的基础上定义设计类 • 设计类与软件实现(Java, C++)类相对应 2 Die faceValue : int getFaceValue() : int roll() DiceGame die1 : Die die2 : Die play() 1 20 1.6 什么是UML? • UML 是用来帮助构建软件系统一种可视化语言 • UML 是一种符号系统,主要用来为软件建模 – 发现 – 记录 – 交流 • UML 的地位和作用在许多时候被夸大了 • UML 不是一个软件方法(OO 是一种软件方法) • UML 不是一个软件过程(Unified Process 是一种软件过程) 21 第二章: 迭代,进化和敏捷 目标 1. 说明后续各章内容和顺序安排的动机 2. 定义迭代和敏捷过程 3. 定义统一过程中的基本概念 22 引论 • 现代软件的两个突出特点是复杂和多变 • 软件规模变得越来越大 • 从软件的构思开始至软件停止使用充满了变化 • 迭代开发是能很好地适应这两个特点的一种巧妙方法 • 主动迎接变更,不断反馈和调整 • 统一过程(UP)是综合了当前最佳实践经验的一种流行的迭代开发 方法 • 迭代的软件生命周期 • 风险驱动 23 瀑布生命周期的本质缺陷 • 是软件工程早期采用的一种生 命周期模型 – 早期 ‚手工作坊‛ 式软件开 发方式遭遇 ‚软件危机‛ – 借鉴其它工程行业(如建筑行 业)成功经验 – 采用确定需求,完成设计,再 予以实现的‚线性‛ 模型 • 瀑布生命周期没有考虑软件开 发的独特之处 – “多变” –“多变” 是软件开发的独特特 征 – 实际数据表明,项目规模越大, 变化的比例越大 0 5 10 15 20 25 30 35 40 10 100 1000 10000 Project Size in Function Points Requirements change 各种规模软件项目的变更百分比 24 通过迭代使系统向用户的真实需求收敛 Early iterations are farther from the "true path" of the system. Via feedback and adaptation, the system converges towards the most appropriate requirements and design. In late iterations, a significant change in requirements is rare, but can occur. Such late changes may give an organization a competitive business advantage. one iteration of design, implement, integrate, and test 25 • UP中一个最重要的思想: 迭代(方式的)开发 • 整个软件工程的开发活动被组织成一系列时间长度预先确定的小工程的开发活 动,每个小的过程称之为一个迭代 • 每个迭代有它自己的需求分析,设计,实现和测试活动 Requirements Design Implementation & Test & Integration & More Design Final Integration & System Test Requirements Design 3 weeks (for example) The system grows incrementally. Feedback from iteration N leads to refinement and adaptation of the requirements and design in iteration N+1. Iterations are fixed in length, or timeboxed. Time Implementation & Test & Integration & More Design Final Integration & System Test 26 迭代式和进化式的生命周期 Iteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration 5 20% 2% r e q u i r e m e n t s s o f t w a r e 30% 5% r e q u i r e m e n t s s o f t w a r e 50% 8% 90% 90% 20% 10% requirements workshops Imagine this will ultimately be a 20- iteration project. In evolutionary iterative development, the requirements evolve over a set of the early iterations, through a series of requirements workshops (for example). Perhaps after four iterations and workshops, 90% of the requirements are defined and refined. Nevertheless, only 10% of the software is built. 1 2 3 4 5 ... 20 week 1 MTW Th F week 2 MTW Th F week 3 MTW Th F kickoff meeting clarifying iteration goals with the team. 1 hour team agile modeling & design, UML whiteboard sketching. 5 hours start coding & testing a 3-week iteration de-scope iteration goals if too much work final check-in and code- freeze for the iteration baseline demo and 2-day requirements workshop next iteration planning meeting; 2 hours Most OOA/D and applying UML during this period Use-case modeling during the workshop 27 UP中面向进度的概念和术语 inc. elaboration construction transition iteration phase development cycle release A stable executable subset of the final product. The end of each iteration is a minor release. increment The difference (delta) between the releases of 2 subsequent iterations. final production release At this point, the system is released for production use. milestone An iteration end- point when some significant decision or evaluation occurs. 28 教材内容(OOAD)介绍的顺序是按照按照UP来安排的 Overview Inception Elaboration Iteration 1 Elaboration Iteration 2 Elaboration Iteration 3 Object-Oriented Analysis Object-Oriented Design Translating Designs to Code The Book Topics such as OO analysis and OO design are incrementally introduced in iteration 1, 2, and 3. Special Topics 29 第三章 案例研究 • 案例一: NextGen POS 系统软件系统开发 • POS – Point Of Sale (收银机) • 国外用于处理销售和付款的计算机化的系统 • POS 要与一些外部系统相连接 • 销售税收计算器 • 仓库管理系统 • 信用卡授权系统 • 需要支持日益增多的各种各样的终端和接口 • 手持终端 • Web 终端 • 是一个要服务各种各样具有不同商业处理要求的行业的通用的POS • 遵循迭代开发的策略,在多次迭代的过程中完成POS系统的需求获取, 面向对象的分析,设计,和实现 30 • 案例二: Monopoly 游戏系统 •“大富豪” 游戏 • 用于说明 OOAD 可以适用于背景广泛的领域 • OOAD 是一个通用的技术 • 案例三: 分布式报账系统 • 具有国内应用背景的例子 • 参考书中的例子 • 是一个贯通中外的作者写的案例 31 采用的(分层)体系结构和案例研究重点 User Interface Sale Payment Logging ... Database Access ... application logic layer other layers or components minor focus explore how to connect to other layers primary focus of case studies explore how to design objects secondary focus 32 • 需求的基本概念 • 用例建模(Use-Case Modeling) • 用例的种类和书写格式 • Actors,Goals和用例的发现 • 用例图 需求用例模型 33 • 定义:需求就是系统必须提供的能力和必须遵守的条件 – 能力 =》 功能 – 条件 =》 约束 • 需求获取中的挑战 – 如何发现需求 – 如何进行需求的交流 – 如何记录需求 – 如何管理需求 • 软件开发中的一个独特事实是:软件的需求总是在变化的 • 需求的有效管理称为软件开发的一个关键问题 – 希望在分析和设计之前发现所有的需求被证明是不现实的(“进化式需求”) – 需求的变化是需要管理的 • 保证需求是朝着用户的真实需要而变化的 • 保证需求最终是可实现的 第五章: 进化式需求 34 [Standish 94; Larman, 2002] 需求问题导致项目失败的统计数据 37% of the factors related to problems with requirements! 35 反映需求获取中存在问题的漫画 36 需求的类型 • 在UP中,需求是按照 FURPS+ 模型分类的 • FURPS+ 模型 – 功能性需求 (Functional) – 非功能性需求 • 可用性 (Usability) • 可靠性 (Reliability) • 性能 (Performance) •‘+’ 部分 – Implementation,Interface,Operations,Packaging,Legal • FURPS+ 模型可用作需求工作的 Check List(检查表) • 需求的记录 – 在UP中,需求主要是在用例模型(功能性需求)中记录的 – 非功能性需求是在补充说明文档中记录的 37 第六章: 用例 • 用例是需求获取的一个重要工具 – 需求的发现 – 需求的记录 – 需求的交流 • 用例在整个软件开发中占据重要的地位 6.1 示例 • 用例是描述系统使用者如何使用系统来达到目标的一组情节 • 例: 处理销售(用例):一个顾客携带采购的商品到达收费口。收银员使用 POS系统记录每件商品。系统给出商品的清单和累加值。顾客输入支付信 息,系统对信息进行验证和记录。系统给行库存信息。顾客从系统得到 收据。顾客携带商品离开。 38 Operation: enterItem(…) Post-conditions: -. . . Operation Contracts Sale date . . . Sales LineItem quantity 1..*1 . . . . . . Domain Model Use-Case Model Design Model: Register enterItem (itemID, quantity) : ProductCatalog spec = getProductSpec( itemID ) addLineItem( spec, quantity ) : Sale objects, attributes, associations Require- ments Business Modeling Design Sample UP Artifact Relationships : System enterItem (id, quantity) Use Case Text System Sequence Diagrams make NewSale() system events Cashier Process Sale : Cashier use case names system operations Use Case Diagram Vision Supplementary Specification Glossary scope, goals, actors, features terms, attributes, validation non-functional reqs, quality attributes requirements Process Sale 1. Customer arrives ... 2. Cashier makes new sale. 3. ... 用 例 在 O O A D 中 的 作 用 39 • 有关用例的一些背景情况 – 用例的概念最早是 Ivar Jacobson 在1986年提出来的 – 使用用例来记录需求目前已被软件界广泛接受 • 简单实用 • UML 的支持 • UP 中 ’用例驱动‘ 的概念 –《编写有效用例》,Alistair Cockburn,影印版,机械工业出版社,2002, 是一本非常优秀的参考书,简明,易懂,和实用 6.2 用例中的基本概念 • 参与者(Actor): 具有行为能力的事物,可以是人,系统或组织 • 场景(Scenario): 参与者和系统之间的一个特定的一系列交互 • 用例(Use Case): 描述参与者使用系统来达成目标的一组成功和失败的场景 40 • 用例(Use Case)和场景(Scenario)之间的关系 – 场景是用例的一个特例 – 用例包含了一组相关场景 用例举例 处理退货(Handle Returns) Main Success Scenario: A customer arrives at a checkout with items to return. The cashier uses the POS system to record each returned item… Alternate Scenarios: If they paid by credit, and the reimbursement transaction to their credit account is rejected, inform the customer and pay them with cash. If the item identifier is not found in the system, notify the cashier and suggest manual entry of the identifier code 41 Alternate Scenarios(continues): If the system detects failure to communicate with the external accounting system… (etc.) • 参与者和系统之间的交互可以有无数多种,其中那些交互构 成一个有效的用例? • 一个有效用例的两个显著特点 • 能给用户返回可观察到的价值 • 帮助用户达到他的一个目标 例:Login 是不是一个有效的用例? Login 可以观察到的价值是什么? 42 6.5 用例和功能性需求 • 用例是用来描述系统(功能性)需求的 • 用例主要是以文字方式记录下来的 • 用例图是系统用例,使用者,之间关系的图形表示 • 用例图是用例的抽象概括描述,仅有用例图是不够的 6.7 用例的类型和格式 • 用例的目的是记录系统作什么(What),而不是怎么做(How) • 用例记录交互的重点在业务过程而不在技术特点 • 黑箱用例把要开发的系统看成一个黑箱子,只描述系统的职责 例:’系统记录销售信息‘ (黑箱用例的描述方式) ’系统将销售信息写入数据库‘ (不是黑箱用例) ’系统为销售信息生成一条 SQL INSERT 语句‘ (更不是黑箱用例) 例:’收银员用扫描器来读入每件商品的信息‘ vs ’收银员使用POS系统记录每件商品‘ 43 • 常用的用例书写格式 – 简洁用例(brief,摘要形式) • 通常在编写用例的早期用来记录主要成功场景,多由一个文字段落组成 – 临时用例(casual) • 非正式的由多个文字段落组成,记录成功和失败的场景 – 详述用例(fully dressed) • 最正式,详细的格式 6.8 详细用例示例:处理销售(Process Sale) • 用例1:处理销售(见教材第35页) • 详细用例的格式由下述几个大的部分组成 – 绪言元素 – 项目相关人员和其兴趣的列表 – 前臵条件和后臵条件(成功保证) – 主要成功场景和步骤 – 扩展部分(其它可能的分支) – 特殊需求 – 技术和数据变更列表 44 6.9 用例格式的解释 绪言元素部分 • 主要参与者:调用系统服务来完成目标的主要参与者 • 项目相关人员及其兴趣列表(Stakeholders and Interest List): –‚The system operates a contract between stakeholders, with the use case detailing the behavioral parts of that contract… The use case, as the contract for behavior, capture all and only the behaviors related to satisfying the stakeholders’ interests [Cockbourn01]” 例: 收银员:希望能够准确,快速的输入,而且没有支付错误。 售货员:希望自动更新销售提成 • 前臵条件和后臵条件:规定了用例开始时和结束时应该为真的条件 例: – 前臵条件: 收银员必须已经被识别和授权 – 后臵条件: 存储了销售信息。准确计算了税金。更新了帐目和库存,记录了 提成,和生成了收据 45 主要成功场景和步骤(基本流程) • 能够满足项目 Stakeholders 利益的典型成功路径(Happy Path) 例:主要成功场景 1. 顾客携带购买的商品到达 POS 收费口 2. 收银员开始一次新的销售 3. 收银员输入商品标识 4. 。。。 收银员重复 3-4步,直到结束 5 。。。 扩展流程 • 扩展部分包括了除了’Happy Path’ 之外的所有其它可能的情况 • 扩展场景是从基本场景中分支出来的 • 一个扩展是由两部分组成:条件和处理 例1:扩展部分 3a 非法的标识 1 系统指示错误并拒绝输入 3b 有多个相同类别的商品,不需要跟踪每一个具体商品 1 收银员可以输入商品类别的表示和数量 46 • 在条件部分,应使用系统或参与者能够检测到的事务为条件 例2:5a 系统检测到与外部税金计算系统的通信故障 5b 外部税金计算系统不工作 例3:对在基本路径中多个步骤可能发生的扩展 3-6a 顾客要求收银员去掉一个已经输入的商品 1 收银员输入商品标识并删除该商品 2 系统显示更新后的累加值 3b 有多个相同类别的商品,不需要跟踪每一个具体商品 1 收银员可以输入商品类别的表示和数量 例4: 对在基本路径中任意一个步骤都可能发生的扩展(用 *a, *b, *c, …) *a 当系统崩溃时(可在任意时间发生) 为了支持系统恢复和正确地记帐,要保证所有交易敏感的状态和事件可以从场 景的任意一步中恢复出来 1 收银员重启系统,登录,要求恢复到上一个状态 2 系统重构上一个状态 47 • 用例的目标和范围 – 用例可在不同的抽象程度上写,可以包含不同范围的内容 – 在怎样的抽象程度写更好?一个用例的‘粒度’应怎样确定? 例: 下面那一个是有效的用例? a 谈判一个供货合同 b 处理退货 c 登录系统(Log In) 基本业务过程(EBP,Essential Business Process) • 定义:‚A task performed by one person in one place at one time, in reponse to a business event, which adds measurable business value and leaves the data in a consistent state“ • EBP 用例的特征 – 基本场景包含 5-10 个步骤 – 是一个几分钟或一小时内可以完成的对话 – 有可见或可度量的商业价值 – 完成时系统数据处于稳定和一致的状态 48 用例和目标 • EBP 用例是能够帮助参与者实现一个用户级目标的用例 • 在需求分析中,EBP用例是推荐的用例 • 发现 EBP 用例的方法 – 找出用户(使用系统)的目标 – 为每一个目标定义一个用例 – 用户的目标应在用例名中反映出来 EBP 原则应用举例 例: NextGen系统分析师在需求获取时与用户的对话 系统分析师: 你使用POS为了达到那些目标? 收银员: 一个是迅速登录,和用它来收款 系统分析师: 驱使你登录的目的是什么? 收银员: 向系统证明我的身份并获得授权使用(用户级目标) 系统分析师: 比这更高的目标呢? 收银员: 防止非法使用公司信息(企业级目标) • Login 并不适宜作为一个用例(从EBP角度),它并没有给企业增加可度量的 商业价值 49 • 找出主要参与者,目标和用例 – 发现用例的基本途径是 • 选择系统边界 • 识别主要参与者和目标 • 定义用例 参与者 目标 参与者 目标 收银员 处理销售 处理租赁 处理退货 。。。 系统管理员 添加用户 修改用户 删除用户 。。。 经理 启动 关机 。。。 销售活动分析系统 分析销售数据 。。。 。。。 。。。 。。。 。。。 50 主要参与者和用户目标和系统边界有关 Goal: Process sales Cashier Customer POS System Checkout Service Goal: Buy items Enterprise Selling Things Sales Tax Agency Goal: Collect taxes on sales Sales Activity System Goal: Analyze sales and performance data 51 参与者(Actor) • 参与者事具有行为能力的事务 – 人,系统,组织 • 三类参与者 – 主要参与者:通过使用系统实现自己目标 • 如,收银员 • 是发现用户目标和用例的一个起点 – 次要参与者:向系统提供服务 • 如,自动支付授权服务 • 明确外部接口和协议 – 后台参与者:不是前两钟参与者,但是用例的行为和其利益有关 • 如,政府的税务机关 • 用例图(Use Case Diagram) – 稻草人标识参与者 – 矩形表示(待开发)系统 – 用椭圆标识用例 – 连线标识使用或交流关系 52 用例图 Use Case Diagram NextGen POS Manage Users . . . Cashier System Administrator actor use case communicationsystem boundary Payment Authorization Service «actor» Tax Calculator «actor» Accounting System alternate notation for a computer system actor «actor» HR System Cash In «actor» Sales Activity System Manage Security Analyze Activity Customer Manager Process Sale Handle Returns 53 Influence of Artifacts On Each Other Design can be thought of as “Use Case Realization”

下载文档,方便阅读与编辑

文档的实际排版效果,会与网站的显示效果略有不同!!

需要 8 金币 [ 分享文档获得金币 ] 5 人已下载

下载文档

相关文档