3面向对象需求理解new.ppt
- 文档编号:1381136
- 上传时间:2022-10-21
- 格式:PPT
- 页数:91
- 大小:2.29MB
3面向对象需求理解new.ppt
《3面向对象需求理解new.ppt》由会员分享,可在线阅读,更多相关《3面向对象需求理解new.ppt(91页珍藏版)》请在冰豆网上搜索。
信息系统分析与设计,基于UML的系统开发,需求理解,案例分析,3,UML的理解,UML,UnifiedModelingLanguage面向对象的统一建模语言,建模工具之一,实质:
沟通方法,正如英语一样成为世界各地人解决沟通的问题。
还有MicrsoftVisio等,基于UML的系统开发,4,基于UML的系统开发,5,为什么需求分析要用UML-沟通工具,UML的用例模型体现了参与者和系统的交互行为,UML的概念模型体现了问题域实体之间的关系。
基于UML的系统开发,UML是一种建模语言,是一种标准的表示方法,适用于系统开发的全过程,它的应用贯穿于从需求分析到系统建成后测试的各个阶段。
1需求分析:
可以用用例来捕获用户的需求。
通过用例建模,可以描述对系统感兴趣的外部角色及其对系统的功能要求(用例)。
2分析:
分析阶段主要关心问题域中的基本概念(例如,抽象、类和对象等)和机制,需要识别这些类以及它们相互间的关系,在这个阶段只为问题域的类建模,而不定义软件系统的解决方案细节(例如,处理用户接口、数据库、通信和并行性等问题的类)。
基于UML的系统开发,3设计:
把分析阶段的结果扩展成技术解决方案,加入新的类来定义软件系统的技术方案细节。
设计阶段用和分析阶段类似的方式使用UML。
4构造(编码):
这个阶段的任务是把来自设计阶段的类转换成某种面向对象程序设计语言的代码。
5测试:
对系统的测试通常分为单元测试、集成测试、系统测试和验收测试等几个不同的步骤。
UML模型可作为测试阶段的依据,不同测试小组使用不同的UML图作为他们工作的依据:
单元测试使用类图和类规格说明;集成测试使用构件图和协作图;系统测试使用用例图来验证系统的行为;验收测试由用户进行,用与系统测试类似的方法,验证系统是否满足在分析阶段确定的所有需求。
总之,统一建模语言UML适用于以面向对象方法来描述任何类型的系统,而且适用于系统开发的全过程,从需求规格描述直到系统建成后的测试和维护阶段。
基于UML的系统开发,为什么需求分析要用UML-传统需求表述方式,采用功能分解方式描绘整个系统的组成,功能分解了功能模块。
缺少参与者与系统的交互行为。
设计和需求容易混淆,其中包含了一部分设计。
造成不知细到什么程度?
系统功能之间关联要用其它文档描述,分割了系统功能所在应用环境。
基于UML的系统开发,CourseArchitecture,信息系统分析与设计,主流方法,传统的方法:
结构化开发方法,系统规划,系统分析,系统设计,系统运行与维护,系统实施,面对对象,开发方法,Web系统开发,3.UML基础-概述九个UML图,用例图(业务建模、需求、测试)类图(业务建模、分析、设计)对象图(业务建模、分析、设计)构件图(设计)部署图(设计)顺序图(业务建模、分析、设计)协作图(业务建模、分析、设计)状态图(需求,分析,设计)活动图(业务建模、设计),结构,行为,基于UML的系统开发,认识问题,分析问题,解决问题,最终用户(提出问题),开发团队(解决问题),以用户的身份站在用户的角度认识问题获取需求用例建模技术,以开发者的身份站在用户的角度分析问题分析需求用例分析技术,以开发者的身份站在开发团队的角度分析问题解决需求面向对象设计,理解需求,需求建造“正确”的系统,需求:
系统必须满足的条件或具备的能力软件质量准则“FURPS”功能性(Functionality)可用性(Usability)可靠性(Reliability)性能(Performance)可支持性(Supportability),非功能性需求,需求理解,需求难在何处?
1.问题空间理解2.人与人之间的沟通3.需求的不断变化,需求:
饮料问题我要一瓶饮料差不多,但我要无糖饮料很好,不过我要绿茶的啊,没有大瓶的,大瓶的无糖绿茶饮料,难捕获,易变!
需求理解,需求:
如此脆弱,客户/用户的要求/想法/期望,软件设计,软件产品,分析和设计,编码和测试,验收,没价值的软件需求,补文档,需求理解,需求:
也需要开发,客户/用户的要求/想法/期望,软件设计,软件产品,开发,编码和测试,验收,有价值的软件需求,分析和设计,需求理解,需求(requirement)与需求的活动,需求分析的任务:
准确地定义未来系统的目标,确定为了满足用户的需求系统必须做什么;用需求规格说明书规范的形式准确地表达用户的需求。
需求分析阶段研究的对象是软件项目的用户要求:
必须全面理解用户的各项要求.要准确地表达被接受的用户要求。
只有经过确切描述的软件需求才能成为软件设计的基础。
通常软件开发项目是要实现目标系统的物理模型。
作为目标系统的参考,需求分析的任务就是借助于当前系统的逻辑模型导出目标系统的逻辑模型,解决目标系统的“做什么”的问题。
其实现步骤如图所示。
参考当前系统建立目标系统模型,参考当前系统建立目标系统模型,业务需求:
反映了组织机构或客户对系统、产品高层次的目标要求;用户需求:
描述了用户使用系统必须要完成的任务;功能和非功能需求:
定义了开发人员必须实现的软件功能;环境、约束的需求接口的需求,需求就是要获得系统提供的所有服务,是“做什么”。
软件需求包括五个层次:
软件需求的层次,销售点终端系统基本功能:
1.记录在线(当前的)销售卖出的商品。
2.计算当前的销售总额,包括税和优惠折算。
3.从条形码中获得被购买的商品信息。
4.当一次销售被提交给系统后,应减少库存量。
5.记录完整的销售信息。
6.出纳员通过输入号或密码登入系统。
7.提供一个持久化存储机制。
8.提供过程间和系统间通讯机制。
9.显示记录下来的商品说明、商品价格。
需求是对一个产品的需要或要求的描述,处理支付的功能:
1.处理现金支付,记录实付款额,计算应还款额。
2.处理信用卡支付。
3.处理支票支付。
属性,响应时间:
显示商品说明和商品价格不超过5秒钟。
界面形式:
基于表的窗口和对话框,键盘导航。
容错处理:
即使电源或设备发生故障,也必须在24小时内将授权的信用卡支付记录到应收款系统中去。
操作系统平台:
MicrosoftWindowsXP。
需求是对一个产品的需要或要求的描述,21,需求获取:
明确收集信息的类型;找到收集信息的相关者;分析用户系统的工作流;召开联合会议。
分析问题:
绘制关联图;创建开发原型;分析可行性;确定需求优先级;建立分析模型;编写数据字典。
编写需求规格说明书,需求验证,需求管理,需求阶段的五个活动,用例的概念在1986年由IvarJacobson正式提出之后被广泛接受,迅速发展,已成为OO、UML、RUP的标准规范和方法。
用例方法的思想:
从用户的角度来看,他们并不想了解系统的内部结构和设计,他们所关心的是系统所能提供的服务,也就是被开发出来的系统将是如何被使用的。
系统透视,系统外部并与该系统发生交互的人或其他系统,系统基本事件流,用例分析技术,22,获取好的需求,需求收集包括五个关键步骤找到可以帮助你理解这个系统的人倾听这些相关人员的描述,并从他们的角度来理解系统利用一个容易理解的模型来描述用户希望如何使用这个系统以及为他们提供的什么价值详细地描述系统和客户以及系统和外部系统之间的交互重构(refactor)这个详细描述以保证它是可读且易懂,需求理解,开发过程的高层步骤,需求理解,设计,实施,制定计划定义需求创建原型,进行系统构建,最终实现系统并投入使用,分析,构造,基于UML的系统开发过程,需求理解,定义计划草案时间进度表、资源计划、预算等初步调查报告目标、选择、业务需求等需求规格说明定义需求,对需求进行陈述术语记录在术语表中建立概念等说明,约束和规则等实现原型对问题、风险因素和需求的辅助理解用例对领域过程的文字叙述用例图展示所有用例与用例之间的关系概念模型草案初步的概念模型,建立用例和说明有关的词汇,基于UML的系统开发过程,需求理解面向对象系统开发的首要步骤是进行项目需求调研,了解系统所属单位的业务流程,以及系统涉及到的各类人员。
通过分析,确定系统边界,识别出系统中的所有用例和角色;分析系统中各角色和用例间的联系,再使用UML建模工具画出系统的用例图。
这个过程具体包括:
了解业务过程,形成描述业务过程的活动图;进行领域分析,了解客户领域中的主要实体,构造高层类图;识别协作系统,建立初步的部署图;发现系统需求,通过联合应用开发计划,细化类图。
会议的工作产品是包图。
包代表了一个系统功能的高层领域;将结果提交给客户。
得到客户认可后继续。
基于UML的系统开发过程,系统分析的任务:
是找出系统中所有需求并加以描述,同时建立特定域模型。
建立域模型有助于开发人员考察用例,从中抽取出类,并描述类之间的关系。
整个过程如下:
理解系统用法,进行高层用例分析。
工作产品是用例图,涵盖了用例与参与者和用例之间的包含、扩展关系。
充实用例,分析每个用例中的步骤序列。
工作产品是对每个用例步骤的用例描述。
细化类图,在类图中加入关联名、抽象类、多重性、泛化和聚集。
工作产品是一个细化的类图。
分析对象状态变化。
进一步细化模型,展示对象状态的变化。
工作产品是状态图。
定义对象之间的交互。
工作产品是顺序图和协作图。
分析系统与其他协作系统的集成。
包括通信类型、网络体系结构等。
工作产品是详细的系统部署图和数据类型。
基于UML的系统开发过程,系统设计阶段:
是进一步细化分析阶段的模型。
涉及到的任务包括:
开发和细化对象图,根据类图产生必要的对象图,检查每个操作并开发对应操作的活动图去充实对象图。
工作产品是对象图和活动图。
开发构件图。
可视化地描绘出构件与构件之间的关系。
工作产品是构件图。
制定部署计划。
编制系统的部署以及系统和其他协作系统集成的计划,表明每个节点中驻留哪些构件。
工作产品是部署图。
设计和开发用户界面原型,包括与用户进行JAD会议。
用户界面应该考虑到完成所有用例。
分析员和用户共同开发用户界面原型(按钮、检查框、下拉列表、菜单等)。
工作产品是屏幕界面原型。
类的包化有助于进行系统结构设计。
包分为用户接口包、商业对象包、数据库包,他们之间的关系是前者依赖后者。
设计测试。
用例是进行测试设计的依据,目的是开发的软件能够实现用例所描述的事情。
工作产品是测试脚本。
编制文档。
文档编制人员和开发人员共同编制文档,制定每个文档的高层结构。
工作产品是文档结构。
基于UML的系统开发过程,系统实现阶段的主要工作包括:
编制代码。
程序员根据掌握的类图、对象图、活动图和构件图,编写实现系统的代码。
工作产品是编制出的代码。
测试代码:
测试专家运行测试脚本,评价代码是否完成了预期的工作。
工作产品是测试结果。
构建用户界面和用户界面到代码的连接与测试。
GUI专家构建用户界面并将界面连接到代码,进一步测试确保用户界面工作正确。
工作产品是带有用户界面的功能系统。
完成文档。
开发阶段,文档专家与程序员并行工作,确保文档及时完成和交付。
工作产品是文档。
编制备份和恢复计划。
由系统工程师编制计划,防止系统崩溃。
工作产品是备份和恢复计划。
在硬件上安装最终系统。
系统工程师在开发人员协助下,将开发好的系统部署到合适的计算机上运行。
工作产品是完全部署好的计算机系统。
测试安装后的系统。
开发组对安装好的系统测试。
包括功能测试、备份和恢复机制是否能够起作用等。
系统试运行,基于UML的系统开发过程,基于UML的系统开发过程,理解需求总体问题陈述客户目标系统功能系统属性,理解需求,总体问题陈述创建用于商品零售的销售点终端系统客户ObjectStore公司,一个跨国的对象零售商。
目标:
为顾客快速结账。
进行快速准确的销售统计分析。
仓储控制自动化,理解需求,销售点终端系统,系统功能(SystemFunction)
(1)基本功能R1.1记录当前的销售R1.2计算当前的销售总额,包括税和优惠折算R1.3从条形码中获得被购买的商品信息R1.4当一次销售提交给系统后,削减库存量R1.5记录完整的销售信息R1.6出纳员必须输入ID和口令才能进入系统R1.7提供持久化存储R1.8提供过程间和系统间的通讯机制R1.9显示记录下来的商品说明、商品价格
(2)处理支付功能R2.1
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 面向 对象 需求 理解 new