面向对象软件开发过程初始阶段实用全套PPT

Click to edit Master title style,Click to edit Master text styles,Second level,Third level,Fourth level,Fifth level,*,*,北京邮电大学计算机学院通信软件工程中心,标题区,一级,二级,三级,四级,五级,*,标题区,一级,二级,三级,四级,五级,标题区,一级,二级,三级,四级,五级,*,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,面向对象软件开发过程初始(ch sh)阶段,第一页，共29页。,提纲(tgng),7b.1 POS案例,7b.2 初始阶段的主要(zhyo)工作,7b.3 需求类型,7b.4 用例模型：写出实际语境中的需求,7b.5 识别其他需求,7b.6 从初始阶段到细化阶段,第二页，共29页。,2,7b.1 POS案例(n l),POS系统：记录(jl)销售信息，处理支付过程，常用于零售店。,系统包括：,硬件：计算机，条码扫描器,软件：,与其他系统连接：第三方税金计算器和库存控制系统,系统要求：,相对容错：库存系统故障不影响销售和付款，即：如果远程服务（库存系统）暂时中断，系统必须能够获取销售信息和处理现金付款，不至于营业瘫痪。,多客户终端：瘦客户Web终端、PC、触摸屏、无线PDA,易于客户化，如不同用户在开始一个新的销售或增加新商品时要求执行一些额外的业务逻辑，系统应该灵活支持。,第三页，共29页。,3,7b.2 初始阶段的主要(zhyo)工作,初始阶段应该考虑以下问题：,项目的构想怎么样？商业案例是什么？,可行性如何？,购买还是开发？,粗略估计(gj)一下成本，估计(gj)收益。,项目是否停止或继续进行？,主要目标：,只进行一定的研究，得到未来新系统的可行性以及实现系统总体目标的合理判断，并确定是否值得继续深入研究系统即可。（深入的研究是细化阶段的工作）,概括为：,预见项目的范围、构想和商业案例；,项目相关人员是否就项目的构想达成基本的一致，项目是否值得继续进行认真的研究。,第四页，共29页。,4,7b.2 初始阶段的主要(zhyo)工作,初始阶段的时间比较短暂，只要建立起初始的一般构想，并确定项目是否可行(kxng)，是否值得细化研究就行。,工件,注解,构想和商业案例,描述高层的目标和约束、商业案例，并提供一个执行摘要,用例模型,描述功能需求和相关的非功能需求,(10%),补充规范,描述其他需求,术语表,关键的领域术语,风险列表和风险管理计划,描述业务、技术、资源和进度上的风险，以及如何减轻这些风险或该如何应对。,原型和概念验证,阐明构想，验证技术问题,迭代计划,描述在第一次细化迭代中该做什么？,阶段计划和软件开发计划,对细化阶段的持续时间和工作量进行低精度的猜测。开发涉及的工具、人员、培训和其他资源。,开发案例,描述为本项目定制的统一过程的步骤和工件。在统一过程中，总需求为项目定制一些步骤或工件。,第五页，共29页。,5,7b.3 需求(xqi)类型,需求就是系统必须提供的能力和必须遵从的条件。,需求管理更推崇用“一种条理化的方法来寻找、记录、组织和跟踪系统不断变化的需求”。,需求类型：FURPS,Function（功能）：特性、能力、安全性,Usability（可用性）：人性化因素、帮助和文档；,Reliability（可靠性）：故障周期、可恢复性、可预测性；,Performance（性能）：响应时间、吞吐量、准确性、有效性、资源利用率；,Supportability（可支持性）：适应性、可维护性、国际化、可配置性。,：一些辅助性和次要的因素。,Implementation（实现）：资源限制、语言和工具、硬件等；,Interface（接口(ji ku)）：与外部系统接口(ji ku)所加得约束；,Operations（操作）：系统操作环境中的管理,Package（包装）,Legal（授权）：许可证或其他方式。,第六页，共29页。,6,4 用例模型：写出实际(shj)语境中的需求,5 识别其他(qt)需求,谁从该系统获取信息，谁提供信息给系统？,定义了项目相关人员对待开发(kif)产品的见解，根据项目相关人员的主要需要和系统特性来规定。,如果开发队伍不能在规定时期内完成，可以将需求推延到未来的任务计划列表中。,编写构想和补充规范的第一个版本。,细化阶段的一些关键思想和最佳实践：,主要成功场景：（基本流程、典型流程）,描述业务、技术、资源和进度上的风险，以及如何减轻这些风险或该如何应对。,4 用例模型：写出实际语境中的需求,4 用例模型(mxng)：写出实际语境中的需求,描述为本项目定制的统一过程的步骤和工件。,高层候选架构和组件建议,特性是系统能做的事情。,分析销售数据和销售表现,7b.4 用例模型：写出实际语境(y jn)中的需求,系统需求：为了满足客户(k h)使用系统的目的。,用例：就是描述客户(k h)如何使用系统来达到目的的一组情节。以此来发现和记录系统的功能性需求。,用例描述功能性需求的思想是由Ivar Jacobson在1986年提出来的，表达的主要思想是：在需求分析中专注于考虑系统怎么才能增加价值和实现目标。,在面向用户目标的语境中考虑系统的功能和特性，这是用例的分析关键。,用例模型是文本文档，UML中的用例图只是给出了角色和用例的名称和关系。,第七页，共29页。,7,7b.4 用例模型：写出实际(shj)语境中的需求,黑箱用例Black-box use cases推荐使用,将系统描述为具有某种职责,描述系统必须做什么（功能需求），而非如何(rh)做（设计），即：将系统看成一个黑箱，观察系统的外部行为：,如：,系统记录销售信息,系统将销售写入数据库,系统为销售生成INSERT SQL语句,第八页，共29页。,8,7b.4 用例模型：写出实际(shj)语境中的需求,用例建模的基本过程：,1.选择系统边界：,POS作为一个系统，包含软件、POS机、输入终端等，收银员、支付授权、税金计算等不包括在系统之内。,2.识别主要角色：,主要角色：在使用系统服务的过程中满足自己的用户目标的那些参与者。找出用户目标,次要角色：为系统提供服务的那些参与者。说明外部接口和协议,后台角色：对用例的行为感兴趣(xngq)。保证找到并满足所有必要的兴趣(xngq)。,3.识别主要角色的目标,一般来讲：第2和第3步是同时进行的。,第九页，共29页。,9,7b.4 用例模型：写出实际(shj)语境中的需求,谁或什么使用该系统？,交互中，它们扮演什么角色？,谁安装系统？,谁启动和关闭系统？,谁维护系统？,与该系统交互的是其他什么系统？,谁从该系统获取信息，谁提供信息给系统？,有什么事情发生在固定(gdng)时间？,角色(ju s)：_,角色(ju s)职责：_,_,角色(ju s)识别问题：,_,_,_,角色描述模板,第十页，共29页。,10,7b.4 用例模型(mxng)：写出实际语境中的需求,谁来启动和停止系统？,谁来进行用户管理和安全管理？,是否存在一个监控进程，其在系统错误的时候能够(nnggu)重启系统？,系统升级怎样处理？主动升级还是被动升级？,谁来管理系统？,由于系统对时间事件进行响应，“时间”是否也是一个角色？,谁来评估系统的活动或性能？,谁来评估日志(rzh)？日志(rzh)是否能够远程获取？,上述问题能够帮助我们找出容易遗漏的角色和目标,第十一页，共29页。,11,7b.4 用例模型(mxng)：写出实际语境中的需求,收银员：,处理销售、处理租赁、处理返回、入款(r kun)、出款,经理：,启动、关机,系统管理员：,添加用户、修改用户、删除用户、安全管理、系统表管理,销售活动分析系统：,分析销售数据和销售表现,第十二页，共29页。,12,7b.4 用例模型：写出实际(shj)语境中的需求,4.定义用例：,一般来讲，要为每个用户目标(mbio)定义一个基本业务过程（EBP）级别的用例。,EBP：由一个人在某个时间某个地点执行的一项任务，这项任务是对某一业务事件的反应，而且能够增加可以度量的业务价值，并且能够保持数据状态的一致。,用例分析时，应该专注于EBP级别的用例。如：“验证身份”不是EBP级别的用例，是更低级别的用例，但是，由于它是很多EBP用例的前提或者一部分，所以可以单独写成用例。但是不要定义过多低级别上的用例，它们只是EBP中的一个步骤。,具体步骤？,用户(yngh)目标,企业目标,第十三页，共29页。,13,7b.4 用例模型：写出实际语境(y jn)中的需求,用例的表达,简洁用例：简明扼要，通常(tngchng)用在主要场景。,场景：是角色和系统之间的一系列特定的活动和交互，是用例的实例。,临时用例：非正式的段落格式。,详述用例,详述用例的格式,主要参与者：,项目相关人员及其兴趣：把用例作为项目相关人员与系统之间的行为契约，从而界定系统必须做什么。,前置条件：用例执行前的条件。,后置条件：用例执行成功后的保证。,第十四页，共29页。,14,7b.4 用例模型：写出实际语境(y jn)中的需求,主要成功场景：（基本流程、典型流程）,场景一般记录三种步骤：,角色与系统之间的交互；,验证动作（通常由系统完成）,系统完成状态改变（如：记录什么、修改什么）,扩展：（替代流程）,扩展由两部分组成：条件和处理。,以系统或角色能够检测到的某事物作为条件。,特殊需求：,与用例相关的非功能性需求,质量属性：性能、可靠性、易用性,设计约束,技术与数据的变化列表：,描述技术上的设计约束，特别是有关I/O的技术。,发生频率(pnl),待解决的问题,第十五页，共29页。,15,7b.4 用例模型：写出实际语境(y jn)中的需求,用例：处理销售,主要参与者：收银员,项目相关人员及其兴趣：,前置条件：收银员必须已经被识别和授权,后置条件：存储销售信息、准确计算税金、更新账目和库存信息、记录提成、生成收据、记录支付授权服务的许可。,主要成功场景：,1.顾客携带商品到达POS机收费口,2.收银员开始一次新的销售,3.收银员输入商品标识,4.系统记录单件商品，并显示该商品的描述、价格、累加值。价格可以(ky)根据一套定价规则来计算。收银员重复34步，直到商品输入结束。,5.系统显示总值并计算税金。,6.收银员请顾客付款。,7.顾客支付，系统处理支付。,8.系统记录完整的销售信息，并将销售和付款信息发送到外部的记帐系统和库存系统。,9.系统打印收据,10.顾客带着商品和收据离开。,第十六页，共29页。,16,7b.4 用例模型(mxng)：写出实际语境中的需求,用例图,1.用例图要简单(jindn)；,2.用例的主要工作,不是画图，而是,写出文本。,收银员,支付授权服务,处理销售,处理退货,收款,分析活动,第十七页，共29页。,17,7b.5 识别其他(qt)需求,用例模型只是描述了系统的功能性需求，其他需求放在下列工件中描述：,补充规范：未在用例中描述的FURPS+需求。,术语表：术语及其定义，还可以用作数据字典。,构想（vision）：概述项目的远景。构想用简洁的语言表达项目总体想法，包括：项目为什么被提出？有哪些问题？有哪些项目相关人员？他们需要什么？以及提出了哪些解决方案等。,定义了项目相关人员对待开发(kif)产品的见解，根据项目相关人员的主要需要和系统特性来规定。,第十八页，共29页。,18,7b.5 识别其他(qt)需求,补充规范,修订,简介,功能性,跨越许多用例的一般(ybn)功能,日志和错误处理,可插入的业务规则,安全性,可用性,人性因素,可靠性,可恢复性：外部服务发生错误的时候，尽量采用本地方法来解决，以使交易能够完成。,性能,第十九页，共29页。,19,7b.5 识别(shbi)其他需求,可支持性,适应性,可配置(pizh)性,实现约束,采购的组件,免费的开放源码的组件,接口,值得注意的硬件及其接口,软件接口,领域（业务）规则：规定