软件工程基于的需求分析方法.ppt

第四部分 软件工程的需求过程,软件工程,传统的需求分析方法-1面向对象的需求分析方法-2基于UML的需求分析方法-3需求工程与需求管理实现-4,第四部分 软件工程的需求过程,第三章 基于UML的需求分析方法UML概述-3.1需求获取与用例建模-3.2类与对象建模-3.3动态建模-3.4物理体系结构建模-3.5,第四部分 软件工程的需求过程,3.1 UML概述,UML统一OO方法大战的努力,1960年-70年代COBOL,FORTRAN,C结构化分析和设计技术1980年-1990年前Smalltalk,Ada,C+,Visual Basic早期面向对象生成（代码）方法1990年中晚期JavaUnified Process,UML概要,UML是一种语言：可视化详细描述的构造性的文档化的UML的价值是一个开发的标准支持完整的软件开发生命周期模型支持不同的应用领域是基于经验的和用户群体需要的被许多工具支持,什么是UML?,Unified Modeling Language（统一建模语言）是国际对象管理组织OMG制定的一个通用的、可视化建模语言标准用于描述（specify）、可视化（visualize）、构造（construct）和记载（document）软件密集型系统的各种工件UML提供了一系列建模元素、概念、关系以及规则，应用于软件开发活动详细内容，请学习统一软件开发过程（The Unified Software Development Process）（美）Ivar Jacobson、Grady Booch、James Rumbaugh著，周伯生、冯学民、樊东平译（机械工业出版社）,UML概念,UML Unified Modeling Language.组合了当前最好的面向对象软件建模方法UML三位主要贡献者1.OMT方法（对象、动态、功能模型，James Rumbaugh）2.The Booch method（5个步骤，Grady Booch）3.OOSE（User Case图，Ivar Jacobson）,James Rumbaugh,Grady Booch,Ivar Jacobson,UML概念,1994年，Booch和Rumbaugh在Rational开始了UML的工作，但是的目标是创建一个“统一方法”他们把Booch93和OMT2统一起来，与95年发布了UM0.8（Unified Method）1995年OOSE的创始人Jacobson加入到这个联盟中，开始把工作重点放到创建一种标准建模语言，UML Unified Modeling Language。他们以Booch方法、OMT方法、OOSE方法为基础，吸收了其他流派的长处，于96年6月、10月、97年1月、11月分别推出了UML0.9、0.91、1.0和1.1,创建UML,Booch 方法,OMT,UML概念,Method方法告诉使用者做什么、怎么做、什么时候做、为什么做（特定活动的目的），方法包括模型Modeling模型用来描述使用某种方法的结果，例如，通过不同角度的简化视图，描述对象系统的设计与实现结果，模型用建模语言来表达Language建模语言由记号（模型使用的符号）和一组规则（语法、语义等）组成,UML概念,UML是一种语言遵循特定的规则允许创建各种模型并不告诉设计者需要创建哪些模型并不提供开发过程UML是可视化语言UML是图形化语言图形便于交流（一幅图抵上千文字）UML是用于构造系统或理解系统的语言UML既支持正向工程，又支持反向工程UML是文档化语言将所建造的系统记录下来便于新程序员跟进开发产品新版本时很有用处,UML的概念,模型元素关系扩展的机制图表,UML构成：模型元素关系扩展的机制图表,模型元素,关系,图表,模型元素,结构元素类，接口，协作用例，主动类，构件节点行为元素交互,状态机组元素包,子系统其它元素注解,类、对象与接口,一个系统往往可以从不同的角度进行观察，一个角度构成了一个视图UML有九种图表，构成5种视图：1、用例图（use case diagram）2、类图（class diagram）3、对象图（object diagram）4、状态图（state diagram）5、时序图（sequence diagram）6、协作图（collaboration diagram)7、活动图（activity diagram）8、构件图（component diagram）9、部署图（deployment diagram）,UML的图表与视图,静态逻辑视图,动态逻辑视图,3-并发视图,1-用例视图,5-部署视图,2-逻辑视图,4-构件视图,模型,视图,和图表,活动图,模型是对一个系统从详细观察的角度的描述,模型,图表,图表是模型的视图表现给投资者看得详细的描述;提供了系统的局部详细描述；和别的视图保持语义一致；在UML中,有九种标准图表静态视图:用例图,类图,对象图,组件图,分布图动态视图:时序图,协作图,状态图,活动图,用例图,捕获用户能够看到的系统通过对”场景”的描述，定义系统的功能和性能，并获得用户和开发团队的共同认可提供清楚和无二义的用户与系统的交互描述,用例图,在开发过程的早期创建目的：详细说明系统的表达含义；捕获系统的需求；验证系统的体系结构；驱动实现和生成测试用例。由分析人员和领域专家开发,Use Case图,Use Case图形描述了一个系统应该执行的什么或应该有什么外部系统它描述了存在的actors（外部系统）、use case（该系统应该执行什么）以及它们的关系在Use Case视图中可以包含以下的图形Use Case图：包括：包、actors、use case和关系相互作用图（序列图或协同图）：包括：对象和消息符号表示：,Use Case图例,Use Case图例,UML用例图示例,类图,捕获系统的词汇表在开发过程中被创建和精确化目的系统中的名字和模型概念详细描述协作关系详细描述逻辑数据库表由分析人员、设计人员和代码实现人员开发,类图Class Diagram类图描绘系统的静态视图它描述了系统逻辑设计中存在的包、类以及它们之间的关系类图可以代表该系统中部分或全部的类结构,1购买 0.*属于,对象图,捕获实例和连接,对象图,捕获实例和连接在分析和设计阶段创建目的举例说明数据/对象结构详细描述瞬态图由分析人员、设计人员和代码实现人员开发,对象图Object Diagram,对象间关系,关联关系(Association)聚集关系(Aggregation)泛化关系(Generalization)依赖关系(Dependency)细化关系(Refinement),构件图,捕获实现的物理结构,构件图,捕获实现的物理结构作为体系结构规范的一部分实现目的组织源代码构造一个可执行的发布版本指定物理数据库由集成人员和程序人员创建,分布图,捕获系统硬件的拓扑结构,分布图,捕获系统硬件的拓扑结构作为系统结构规范的一部分被创建目的描述组件的分布标识系统性能瓶颈由集成人员、网络工程师和系统工程师开发,交互图,交互图描述了系统在逻辑设计中存在的对象及其间的关系它可以代表系统中对象的结构UML中包含两种交互图，它们对同一交互操作提供了不同的浏览视角时序图（顺序图）按时间顺序排列对象交互操作协作图围绕对象及其间的链接关系组织对象的交互操作,交互图,顺序图和协作图均被称为交互图（interaction diagram）。由一组对象、对象间的关系、对象间发送的消息组成一种动态视图，可以单独使用、也可以对用例中的特定控制流程建模。顺序图和协作图同构的：两种图之间可以相互转换，而没有任何信息损失。二者区别点在于：顺序图（sequence diagram）关注消息的时间顺序，有对象生命线、有控制焦点；协作图（collaboration diagram，在UML2.0中协作图被称为communication diagram，二者指的是同一类型的图）关注收发消息的对象的组织结构，有路径、有顺序号。,时序图,捕获系统的动态行为(面向时间的),时序图,捕获系统的动态行为(面向时间的)目的模型流程的控制举例说明典型的脚本,打印机就绪打印文件,时序图（Sequence Diagram）,打印机忙保存文件,打印文件,打印文件,计算机,打印服务器,打印队列,计算机,UML顺序图示例（某客户Joe取20美元的顺序图）,协作图,捕获系统的动态行为(面向消息的),协作图,捕获系统的动态行为(面向消息的)目的模型流程控制举例说明对象结构和控制的协调,协作图（Collaboration Diagram）,UML协作图示例（ATM系统中“客户插入卡”的协作图）,状态图,捕获系统动态行为(面向事件的),状态图,捕获系统动态行为(面向事件的)目的对象生命周期模型为起反作用的对象(用户接口、设备等）建模,状态图State Diagram状态图描述了：给定类的状态转换空间导致状态转换的事件导致状态改变的动作为类的重要动态行为建立状态转换图,状态图State Diagram,UML状态图示例电视机,世界上的万事万物在任何特定时刻总处于某一特定状态。一个电梯可以处于上升、下降、停止状态。一辆汽车可以处于前行、后退、停止状态。一台电视机可以处于开机、播放、待机或关机状态。,活动图,捕获动态行为（面向活动的）,活动图,捕获动态行为（面向活动的目的给商业工作流建模给操作建模,活动图Activity Diagram,Disk free,Disk full,显示磁盘满,显示在打印,删去显示信息,建立打印文件,Win.printAll(),printer.print(),活动图的符号集与状态图中使用的符号集类似。像状态图一样，活动图也从一个连接到初始活动的实心圆开始。活动是通过一个圆角矩形（活动的名称包含在其内）来表示的。活动可以通过转换线段连接到其他活动，或者连接到判断点，这些判断点连接到由判断点的条件所保护的不同活动。结束过程的活动连接到一个终止点（就像在状态图中一样）。作为一种选择，活动可以分组为泳道（swimlane），泳道用于表示实际执行活动的对象,UML活动图示例（ATM系统中“客户插入卡”的活动图）,体系结构和UML,组织：包,子系统,动态交互状态机,设计视图,实现视图,过程视图,组件,类,接口,协作,活动类,分布视图,用例,UML静态图,用例图（Use Case Diagram）类图(Class Diagram)对象图(Object Diagram)构件图(Component Diagram)部署图(Deployment Diagram),UML动态图,状态图（State Diagram）时序图（Sequence Diagram）协作图（Collaboration Diagram）活动图（Activity Diagram）,UML建模方法与视图,用例建模用例图类和对象（结构）建模：类图对象图行为（动态）建模用例图交互图（顺序图、协作图）活动图状态图物理体系结构建模构件图实施图,UML过程,UML过程主要包括：用例驱动（use-case-driven）以体系结构为中心（architecture-centric）反复（iterative）渐增式开发（incremental）,UML过程,1、用例驱动：用用例方法获取系统的功能需求，并以此驱动需求分析之后的所以阶段的开发在需求阶段，用例所包括的系统功能，需要用户的确认在设计和实现阶段，用例被实现在测试阶段，用例用于验证系统功能,需求,用例,用例影响开发的所有阶段用例视图影响其他视图,UML过程,2、以体系结构为中心项目开发的早期，除了需求以外，另一个最主要的工作就是确定系统的体系结构体系结构定义了系统的各部分、各部分的关系和交互、通信机制、如何增加和修改体系结构的规则体系结构决定了系统的功能和非功能部分非功能部分包括：性能、易理解性、易修改性、复用度在UML中，通过定义可以层次化的“包”，来实现把一个大系统划分成不同的小系统确定体系结构的基本方法是：分析、选择、原型化、评估和精细,UML过程,3、反复迭代用UML方法建模，可以反复多次，不需要一次完成通过反复，增加新信息、细化新的细节每次反复，应进行评估，评估的内容还应包括：代价、风险4、渐增式多次迭代，每次迭代增加新的用例和功能每次迭代，都是分析、设计、实现和测试的过程迭代的最大好处是分解了风险，不至于把失败的风险留到开发的最后才发现,3.2 需求获取与用例分析,需求开发过程的阶段任务,需求开发过程的重要里程碑,基于UML的需求获取,1、需求获取与业务建模,对于一个复杂的业务系统，我们可能涉及：公司组织、业务单位、部门和人员岗位、职责和功能、内部和外边网络、客户、业务信息流、行政和财务流等等为这个组织建立计算机系统，我们要回答：为什么要建立这个系统这个系统的定位在何处我们如何确定哪些功能是最适宜放在系统的特定节点上我们何时采用计算机处理而何时采用人工处理为适应计算机处理，我们需要改变现有工作流程吗回答这些问题的技术，就是业务建模,业务建模的目的：建模过程是开发者和用户之间为导出需求规约而进行的交互过程因此：理解现有业务组织的静态结构和动态运作方式确保客户、最终用户以及开发人员对业务组织有共同的理解系统的边界在那里？功能是什么？理解如何部署新的系统以提高生产力，以及现有的哪一个系统会受到新系统的影响系统的功能由用例来表示：用例用来：确定和描述系统的功能要求给出清晰和一致的系统做什么的描述为验证系统所需的系统测试提供基准提供从功能需求到系统实际类和操作的跟踪能力,传统方法：业务流程图存取款业务处理过程,在UML中的建模结构就是业务用例模型和业务对象模型领域模型将系统语境中的重要概念描述为领域对象，并建立这些领域对象之间的关系业务模型是领域模型的超集，包括：a.业务用例模型：说明系统所支持的业务过程b.业务对象模型：领域模型和业务用例实现业务用例模型是业务系统预期功能的描述模型，是系统开发任务和作为产品提交时的最根本的系统工作描述业务对象模型描述了实体和相互交互完成业务用例所需要的功能，是业务用例的实现下面，我们用示例介绍,利用UML概念进行业务建模,业务过程与业务用例,一个业务过程是根据组织目标而采用组织资源来获得预定义结果的一组逻辑相关的活动用一个业务用例代表一个业务过程业务用例包括：角色（与业务活动交互的人或系统）用例（角色与业务元素交互完成工作的事件序列）建立业务用例的过程：确定行为者确定用例,确定行为者,行为者：与系统交互的人或其他系统交互：发送、接收、交换信息行为者执行用例行为者是一个角色，而不是具体个人寻找行为者谁使用系统的功能谁需要系统提供信息谁维护、管理、控制系统系统完成功能还需要得到其他系统的支持还有哪些人对系统的结果感兴趣,业务用例 银行,确定用例,一个用例是被行为者感受到的一个完整的功能UML的定义：用例是给一个特定行为者的一个可观察的结果值的系统所完成的一系列动作这个动作除计算机内部完成的计算外，还包括与行为者的信息交互用例通过关联与行为者进行交互用例总是被行为者所启动，并回答一个可识别的结果类似于对象是类的实例，用例的实例是场景（scenario）。例如：“用户在ATM机上执行取款操作”用例的场景是：“张三在ATM机上取出300元人民币”寻找用例行为者需求系统提供哪些功能？行为者是否需要创建、读、写、修改、删除系统中的信息？行为者是否需要被系统提醒、启动系统的某个功能？系统能否帮助行为者做一些事情，来提高行为者的效率、便利,寻找用例,考虑人和饮料贩卖机的交互，包括购买饮料，首先，放置货物（饮料）等，下面考虑购买饮料。,l 用例描述了系统的行为，包括行为者和系统之间的交互以及系统与系统之间的交互。用例是系统提供的功能块。演示了人们如何使用系统。它来自于客户需求的分析。这个过程称为Use Case分析,是整个系统开发中非常关键的过程。,我们设计一个饮料贩卖机，从用户的角度来考察它的功能：问:“自动饮料贩卖机将为您做什么?”答:“我通过自动饮料贩卖机购买一听饮料.”饮料贩卖机的主要功能是使得用户可以购买饮料，我们为这种机器标记一个叫“买饮料”的use case.,UML中的 Use Case 表示,Buy Soda,Use Case,Actor,Communication,Customer,use case记录用户使用系统是从头到尾的一系列事件。用户普遍称为“活动者”，它可以是人或另一个系统。每一个 use case 包括“活动者”和一个表示 use case 的椭圆。,Use Case,活动者,活动者可以是人或另一个系统，它与当前的系统交互，向系统提供输入或从系统中获得输出。,Actor Name,Telephone System(电话系统）,使用电话卡,对方付款,Phone User(电话用户）,活动者的标志,谁对某一需求感兴趣？组织中哪一部分使用系统?谁从系统的使用中受益?谁向系统提供信息？谁将维护系统？系统使用外部资源吗?系统和已经存在的系统交互吗?,活动者的类型,实际的人，即用户，是最常用的角色，几乎每个系统都有。命名这些角色的时候，要按作用来命名，而不是按照位置命名。另外一个系统。例如航空订票系统可能需要与外部应用程序接口，验证信用卡以便购买。可能隐蔽的角色：时间。例如商业促销项目推出免费奖，每天下午三点，系统自动选择向随机客户提供免费奖品。,在饮料自动贩卖机中，除了买饮料的顾客，还有以下的活动者。,Buy Soda,Restock Soda,Collect Money,Customer,Supplier,Collector,每一种活动者具有自己的 use case,饮料贩卖机中的活动者,供应商向自动贩卖机添加饮料。收银员从自动贩卖机收钱。,理解用例,用例独立于实现。用例关注的是作用而不是如何实现这个作用。用例是系统的高级视图。用例的集合应让客户易于了解高层的整个系统。最后，用例关注系统外的用户。每个用例应表示用户与系统间的完整事务，为用户提供一定价值。用例应按业务术语命名，而不是按技术术语命名，应让客户一目了然。例如：用例不要命名为“客户与银行ATM的交互界面”，如果客户要买票,用例可以称为“客户购票”。,用例分析有助于:捕捉需求计划开发过程的循环往复。验证系统。需求分析从用例分析开始，它驱动整个开发过程。在用例中描述了所有的功能需求。,标记用例,活动者希望这个系统执行什么任务。活动者在系统中访问哪些信息(创建,存储,修修改,删除等)?外部的哪个变化将要被告知系统？系统的那个事件将要被告知活动者？系统将要怎样维护?,标记用例,用例的完整性 每个功能需求是否至少在一个用例中?如果需求不在用例中,则不会实现。是否考虑了每个操作者如何使用系统。每个操作员向系统提供了什么信息。每个操作员从系统接收了什么信息。是否考虑了维护问题，要有人启动和关闭系统。是否标示了系统要交互的所有外部系统。每个外部系统从系统接收什么信息和系统发送什么信息?,用例视图,一个 use case 视图包括 一个use case 集合，定义整个系统的功能。,Buy Soda,Restock Soda,Collect Money,Customer,Supplier,Collector,Soda Machine,Use Case 视图,系统 边界,用例的范围,2、从业务模型到系统模型,例：建立用例的系统模型,ATM取款机作为一个业务系统来取款的客户是一个角色用例是业务模型中业务的活动系统模型描述了业务中系统的工作（内部活动）角色是外部，用例是内部。取款的客户是角色，取款是用例。用例模型开始定义角色之间的关系（关联关系、包括关系、扩展关系、一般化关系等）。用例模型描述事件流，包括主事件流、其他事件流、前提条件、事后条件等等。这样，我们就建立了一张描述“活动”的Use Case图，通过这张图，我们就能够比较具体地描述“活动”，即让用户看到：谁与系统交互，有助于发现缺少的参与者知道系统的范围，有助于发现缺少的功能,业务用例描述：柜台取款,业务用例活动图：柜台取款注意：这里只有角色（客户）和用例（系统）对于系统内部的实现，我们还没有更多的涉及,从业务模型到系统模型-ATM,系统用例 ATM,系统用例-ATM取款,用例时序图-ATM取款系统开始区分ATM系统和银行主机系统,用例的层次,概要目标用例：需要多个用户目标会话来完成（日、周、月、年）用户目标用例：满足特定、迫切、有价值的用例目标（分钟、小时）子功能用例：为了完成用户的真实目标而提供的功能,用户目标层,“Can the actor go away happy after having done this?”通常1个人，1次性完成，2-20分钟,概要目标层,使用ATM用例：银行自动柜员机含有多个用户目标，可包含：存取款、查询、修改密码、打印凭单、提供跨地域、跨银行服务作用说明用户目标执行的背景说明相关目标的范围提供了下层用例的目录,用户目标层次,用例分析流程,定义系统范围和边界列出角色及其作用提取概要用例并调整得当着重对系统的用户目标层用例进行细化填写干系人责权利、前置后置条件编写基本流列出所有扩展条件，编写扩展处理步骤用活动图、状态图、交互图等描述重点用例9.分解、合并用例，调整用例关系模型（用例图）,需求获取关键是获得用户的确认,建立业务模型的工作主要包括：分析领域中的业务角色分析角色间的业务功能等关系分析业务组织架构分析业务规则分析业务实体分析业务事件分析以业务角色为主角的业务用例等；以业务用例为实例，与用户进行沟通：需求是否被清楚地陈述？存在错误的理解吗？需求的来源（人员、规章制度、文件）是否正确？需求的最终陈述是否得到用户最终责任人确认？,问题 用户不知道他们需求什么或不知道如何表达直到开发人员把用户所描述的东西给他们，用户才认为知道自己要什么分析人员认为自己比用户更了解用户的需求,解决方案将用户当作领域专家来认识和感激，尝试一下其他沟通和启发技术 尽早提供相互选择的启发技术：情节串联板、原型、角色换位等把分析人员放在用户的位置，试着换位一小时或一天,解决用户和开发人员综合症,介绍游戏规则,被动式介绍,主动式介绍,交互式介绍,需求诱导的方法（情节串联板）,原型开发,复杂程度与成本,需求获取过程需求管理的关注点,步骤：1、发现和分析问题 2、理解用户的需求 3、定义系统（用例模型）4、管理范围（项目管理）方法：采用业务建模和系统建模的方法进行问题分析 对与系统架构和系统行为有关的用例进行描述和定义目标：在问题定义上与用户达成共识理解问题背后的根本原因确定用户和项目干系人定义问题解空间的边界确定问题解决方案的约束和假设最终阶段完成标志：用户对系统目标的认可签字,需求获取过程产品基线管理的关注点,技术创新和突破,产品特点,客户：涉众和用例,分析人员和专家的意见,与公司其他产品的配套和一致性,与对手的竞争性产品差异和优势,开发团队的状况与产品的可持续性,系统平台与兼容性,公司目标与市场需求,一个真正伟大的产品,需求获取过程产品路线管理的关注点,图例：,正在发行,发布代码行,需求提取的最佳实践,明确构想和范围确立需求开发过程用户群分类选定产品代表建立用户核心队伍建立用例模型举办用例演示会,分析业务流程明确质量属性检查问题报告重用需求,用例常见错误,无系统目标或边界无角色定位用户界面细节过多目标层次太低目的与内容不一致含有设计内容过多的数据细节,“用例分析是当今消除需求不明确、不一致、不完整 的重要手段和关键技术”用例在需求获取阶段的好处：与传统的需求分析方法相比，用例书写简单、易于理解用例迫使开发人员从系统设计时，就从用户的角度考虑问题用例使用户参与需求过程，帮助他们理解所建设的系统，并提供了一种交流和记录的工具用例给出了需求的情景，从而使人们理解需求的原因以及系统是如何实现它的目标大多数情况下，用例是开发人员写的，因此，他是理解这个需求，也知道最终要对实现这个需求负责的,用例在系统开发的其他阶段的好处：用例在分析阶段，也是一个关键的工具，它帮助我们理解系统需求做什么以及系统可能如何去做用例在设计和实现过程中，也是一个关键的工具，它降低了因需求表达不确切和不一致，导致系统开发错误的风险用例可以直接延伸到测试过程，这有利于确保系统真正做了它应该做的事情用例也是用户文档的输入，可以从用例开始，很方便地组织用户文档的编写,用例在组织软件开发中的核心作用,用例驱动模型,到目前为止，我们完成了需求获取阶段的任务通过采用用例的方法，建立了业务模型，使用户理解并确认系统要做什么和不做什么,3、从业务用例到测试用例,V模型中的过程从左到右，描述了基本的开发过程和测试行为。V模型的价值在于它非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系。,测试与开发阶段的对应V模式,验收测试,在行业应用软件环境中，验收测试是项目过程非常重要的一环，也是项目经理非常关注的一项工作。验收测试与确认测试非常相似，所不同的是，确认测试是项目组或组织内部的测试，验收测试是用户主导、现场参与、现场环境下的测试。验收测试通常由项目组先提出测试大纲，定义测试目的、范围、方法、测试用例、预期结果、验收标准等。经用户同意批准，可能包括用户的修改、增加后，确定测试时间，开始进入验收测试。用户在完成按测试用例的测试后，在测试记录上逐条确认、签字，最后，在测试报告上签字，完成验收测试。一般地、验收测试报告是项目初验、终验的依据和主要验收形式。,系统验收与用例的关系,验收测试的用例，在需求获取完成后产生测试用例的依据是需求获取的业务用例。（1）从业务用例到实现用例（2）从业务用例到测试用例,根据用例的事件流分析，针对用例情景，产生验收测试用例。,从用例到测试用例,3.3 需求分析与类和对象建模,从现在开始，我们完成了“需求获取”阶段的任务，进入“需求分析”阶段需求获取阶段完成的标志，是获得用户签字确认的需求描述需求分析阶段任务完成的标志，是在经过需求分析、需求处理后，通过“需求评审”从现在开始，我们要用面向“实现”的眼光，来看待需求什么是面向实现？需求分析阶段的“面向实现”，是面向可交付成果什么是面向成果？我们先看一下需求评审的要求,需求开发过程的阶段任务,需求开发过程的重要里程碑,基于UML的需求分析,传统的需求分析阶段,需求分析阶段的任务和步骤复查系统规模和目标研究现有系统功能导出新系统模型重新定义问题导出和分析各种可选解决方案推荐行动方针草拟开发计划书写文档提交审查阶段成果交付物：需求定义文档（需求规格说明）,循环,需求分析需求获取与需求分析的区别,需求获取是面向用户、在较高的抽象级别上对系统特性的定义可以更多地关注系统的特性以及如何体现用户的需求，以便更好地理解系统的形状和形式可以对系统的完整性、一致性以及对环境的适应性进行评估在继续大量投入之前，可以利用这些信息决定可行性和管理系统的范围可以脱离对具体需求进行取舍和决策所带来的风险需求获取的目标是用户的认可，因此，阶段的验收标志是用户签字确认的需求描述,需求分析需求获取与需求分析的区别,需求分析是面向系统实现、严格对系统需求的定义定义系统的输入、输出、功能、属性以及系统环境的属性，决定系统的完整集合面向系统技术实现，讨论系统应该做什么，因此，应避免受项目进度、计划、预算、设计、测试等的影响需求和设计是迭代进行的，但需求将引导设计，也受设计方法的制约需求分析的验收标志是组织的需求评审,需求分析细化系统定义,在需求获取阶段，我们已经通过建立业务模型、系统模型，与用户共同确定了系统的特性：业务用例模型，可以映射出软件产品核心的需求，包括与业务功能对应的组织的特性，与业务流程对应的内外部关系特性等；系统用例模型，是在已经建立的业务模型的基础上，建立系统的模型。用例业务模型和系统模型的最典型表示形式软件产品本身可能还存在与业务无直接关系的另类需求（一般与硬件、软件环境相关），比如支持多种操作系统、对软件运行的远端监控要求、异常处理（如通讯连接中断等非业务异常）等等。另一方面，设计约束和限制，也是系统需求必须要考虑的内容通常这三部分需求构成软件需求的总集。,需求分析细化系统定义,在需求分析阶段，我们不可避免地要涉及到进行设计决策设计决策：硬件环境（运行在PC服务器上？还是小型机？）平台的选择（只支持Windows平台，是否也支持UNIX平台？）工具的限制（采用VB实现？）方法的约束（用XYZ类库实现数据库访问？）,需求分析是在需求获取、需求分析和设计决策之间反复迭代循环的过程,需求分析细化系统定义,软件需求是具体的：面向系统设计、编码面向测试因此，在需求获取的基础上，进一步细化系统需求、明确和细化系统定义，这就是需求分析阶段的任务在传统软件过程方法中，这二个阶段不是非常清晰和明确,需求分析细化用例,在需求获取过程中，我们建立了业务模型和系统模型，引入了角色和用例的概念角色与用例的区别：系统的角色是业务之外与业务交互的人或事例如：ATM取款机作为一个业务系统，来取款的客户就是一个角色用例是业务模型中，业务的活动在系统模型中，描述了业务中系统的工作（内部活动）。角色是外部，用例是内部。取款的客户是角色，取款是用例。用例模型开始定义角色之间的关系（关联关系：包括关系、扩展关系、一般化关系等）。用例模型描述事件流，包括主事件流、其他事件流、前提条件、事后条件等等。,需求分析细化用例,细化用例的主要步骤：审查主角细化描述定义和细化事件流程确定前置条件和后置条件确定特殊需求扩展用例,需求分析细化用例关系,为需求处理做准备在定义系统的用例规约之前，确定一份基本的术语词汇表，以统一项目开发中的用词。确定系统的用例，通常从寻找系统的主角开始。如果做了业务建模，则可以先从业务对象模型中的业务工人（Business Worker）着手。系统主要的主角确定后，可以根据为系统主角提供有价值的结果（Result of Value）这一准则（用例是为主角的活动最终提供一个有价值的结果的活动过程）来确定系统的用例。理清系统用例之间存在的密切关系，具有的内在结构，如泛化关系、包含关系、扩展关系等。有二种Interaction图，按时间顺序排列的是Sequence图，按对象关系排列的是Collaboration图。二种图从不同的角度，反映了案例中特定情形的流程。,需求分析的成果需求评审内容,CMM2对评审内容规定为：（1）确定不完整和遗漏的给定需求；（2）评审给定需求以确定他们是否：可行、适用于软件实现、说明清楚、适当、彼此一致、可测试。（3）有负责分析和分配系统需求的小组对确认可能有问题的给定需求进行评审并进行必要的修改。（4）相关小组协商由给定需求所得出的约定。在这里，我们最主要先关注（1）（2）二条第一条：需求分析阶段的需求规格说明必须与需求获取阶段经用户签字确认的用户需求描述一致第二条：需求规格说明还应具有一些特定的属性,良好的需求规格说明属性,具有良好的需求规格说明属性的需求文档，具有如下的属性：（1）不含糊性：如果每一个需求只有唯一的一种解释，那它是不含糊的；（2）完整性：如果需求包括了功能、性能、时间响应要求、限制、接口等属性，不存在没有界定的、以为是隐含或默认而实际存在认知差异的需求，是完整的；（3）可检验性：存在有限的、经济与技术都是可行的检验方法和程序，对需求的实现与否，进行检验，使得用户和组织通过该检验，确认需求被按照需求规格说明实现；（4）一致性：需求作为一种要求是一致的，不存在系统内相互冲突的需求要求；（5）可跟踪性：需求可追踪；（6）可使用性：可为产品的各阶段，特别是维护阶段，提供充分有用的信息。,所以，我们现在可以理解：需求分析，就是为了实现系统需求，并使最后交付成果与需求所要求的目标，不产生：含糊性、不完整性、不可检验性、不一致性、不可追踪性和不可用性，而进一步对需求进行描述和定义。需求分析继承需求获取阶段的成果需求分析面向下阶段系统概要设计需求分析采用自己的特定方法，达到相应的阶段要求需求获取阶段的目标是让用户签字采用的方法是尽量地让用户和开发团队都能理解并认同系统目标和范围界定的方法业务/系统模型、用例和USE CASE图需求分析阶段的目标是用计算机的（而不再是用户）眼光和语言，分解需求、定义需求。但是，这个眼光不是程序设计员的眼光，是系统分析师的眼光经过下一步需求处理后，达到需求规范要求分析的方法是一套“建模”技术,需求分析的成果：,用例驱动的分析,为了进一步描述系统，我们现在需要建立类和对象模型类和对象模型，描述了系统的静态结构有了系统的静态结构，我们才可以在静态结构的基础上，建立系统的行为（动态）模型在面向对象方法中，我们已经介绍了如何建立类和对象的模型UML的特点是一套统一描述方法和符号,用例驱动的分析实现,Booch method 的5个步骤（1）使用“寻找什么”标准来标识类和对象分析类（2）定义一般/特殊结构、定义整体/部分结构分析包（3）标识主题（子系统构件的表示）建立子系统（4）定义属性和实例联系（5）定义操作和消息联系,静态建模,动态建模,UML的三个来源和三个组成部分：OMT、5步骤、图形符号,从业务/系统模型到分析模型,分析类（逻辑结构）用例实现：将用例的实现（执行）表示为分析类（对象）之间的交互分析包（物理结构）以包（分块）的方式组织分析模型的组件强内聚、弱耦合完整性、正确性、一致性和易读性,类是信息和行为的包装 对象是类的特定实例 类图由系统中的类和它们之间的关系组成 例如：在C/S结构的系统中，我们把系统的信息放在数据库一方，行为放在应用程序一方。面向对象的特点之一就是将信息和影响信息的行为连接在一起，包装成类。类图和对象图：,（1）类/对象图静态分析,类,对象,对象图使用与类图相同的形式只是在对象名下加一个下划线对象名后可接以冒号和类名,分析模型由三个独立的模型构成：由用例和场景表示的功能模型；用类和对象表示的分析对象模型；由状态图和顺序图表示的动态模型。在需求获取阶段得到的用例模型就是功能模型。据此可导出分析对象模型和动态模型。需要注意，这些模型代表的是来自客户的概念，而非实际软件类或实际构件。如数据库、子系统、会话管理器、网络等，不应出现在分析模型中，因为这些概念仅与实现相关。分析中的类可以看作是高层抽象，在后续阶段将使用更多的细节实现。,在分析对象模型中有实体对象、边界对象和控制对象等三种类型。实体对象表示系统将跟踪的持久信息；边界对象表示参与者与系统之间的交互（接口）；控制对象负责用例的实现。可用UML提供的衍型机制，区分不同类型对象。,UML对类进行了分类，既所谓：B-C-E模型UML有三种基本的构造型：边界、实体和控制。边界类（Boundary Calsses）边界类位于系统与外界的交接处，包括所有窗体、报表、打印机和扫描仪等硬件的接口以及与其他系统的接口。要寻找和定义边界类，可以检查Use Case框图。每个角色/使用案例交互至少要有一个边界类。边界类使角色能与系统交互。例如，假设要迅速寻找模型中所有窗体，可以创建Form类型，将所有窗口指定为这个类型。要寻找模型中的所有窗体时，只要寻找Form类型的类即可。,UML类的三种基本构造型,控制类（Control Classes）控制类负责协调其他类的工作。每个使用案例通常都有一个控制类，控制使用案例中事件顺序。在Interaction框图中，控制类具有协调边界与实体有关消息的责任。还有处理共用功能的管理者，如资源竞争、分布式处理和错误处理等。实体类（Entity Classes）实体类保存要放进永久存储体的信息，在B-C-E模型中，通过实体类将数据库封装起来。例如：在JAVA中，实体类可以想象成负责处理JDBC的组件，而在EJB中，Entity Bean就是一个相当好的实体类的范例。增加类的类型 除了上述版型外，还可以向模型中增加自己的构造型。,类的三种基本构造型,ATM取款：用例的类提取,分析和设计：找到用例模型的类，寻找的方法是按照边界/控制/实体（BCE）模型然后“套”已经在类库中定义好的类。在实现中，真正需要自行创建的“类”并不多，甚