第6章-面向对象需求分析

面向对象需求分析8.1需求工程•软件需求工程是一门分析并记录软件需求的学科，把软件需求分解成一些主要的子系统和任务，通过一系列分析、设计、比较研究、原型开发过程把这些系统需求转换成软件需求描述和一系列性能参数。•实施五个独立的管理过程：需求获取，需求分析，需求规格编写，需求验证，需求变更管理等。8.1.1需求类别软件系统的需求可分为•功能需求•非功能需求•领域需求•系统数据需求•功能需求：描述系统功能、输入输出、异常处理。•非功能需求：对系统提供的功能或服务给出约束，包括反应时间，可靠性，存储控件，可移植性，与其它软硬件系统接口，安全规章，隐私权保护，I/O设备能力，用户界面数据表示等。•一个功能需求没有满足，可能降低系统能力；而一个非功能需求没有满足，可能导致整个系统无法使用。•领域需求：来自对系统应用领域的需求，通常表现为某个特定的功能需求，某个特定的非功能需求，或对已存在需求的约束。•这些需求对领域专家是显而易见的，所以在需求陈述中不详细列出，而系统开发人员对此不了解，导致需求不确定。8.1.2需求获取需求获取的基本方法和技术包括•会谈•使用调查表•场景分析•建立原型会谈：包括正式会谈和非正式会谈•一般先进行非正式会谈，提出一些可自由回答的问题鼓励会谈人员表达自己的想法。询问客户对目前系统为什么不满意，了解问题的性质、需要解决的方案，所需的人数和能力，客户的目标和收益。•正式会谈提出实现准备好的议题，需要准备一份会谈概要的书面材料，最好每人一份，一遍陈述及发现忽略的项目。•对大型系统，通常有不同类型的用户，可形成多种视点，这时需要进行面向多视点的需求分析。使用调查表•当需要对上百人进行个人意见调查时，这种方法十分有效。经过仔细考虑的书面回答可能比口头回答要准确。在非正式会谈基础上制定的调查表效果更好。•客户使用的各种表格反映了他们工作流程中各个环节的重点，是获得信息的重要手段。场景分析•把人与系统进行交互的场景描述出来，易于理解和评论，再以形式化方式表示出来，称为场景分析或情景分析。•情景开始于一个框架，在导出过程中，细节被逐步增加，直到产生一个完整的描述。•一个场景描述通常包括如下内容：场景开始前系统状态描述一个关于标准事件流的描述一个关于哪会出错，以及如何处理错误的描述有关可能在同一时间进行的活动的信息场景完成后系统状态描述需求获取的过程：1)列举候选需求2)理解系统语境3)捕获功能性需求4)捕获非功能性需求8.1.3需求分析•需求分析的过程即需求建模过程，是为最终用户所看到的系统建立一个概念模型，是对需求的抽象描述，并尽可能多地捕获现实世界的语义。8.1.4需求验证•在设计之前验证需求的正确性及其质量，能大大减少项目的后期返工现象。•需求验证的任务是保证需求符合完整性、正确性、灵活性、必要性、无二义性、一致性、可跟踪性及可验证性这些良好特征。•最后双方签字。8.1.5需求变更管理•需求变更管理活动需要完成下面几个任务：确定变更控制过程建立变更控制管理委员会进行变更影响分析跟踪变更影响的产品建立基准和控制版本维护变更历史记录跟踪每项需求的状态衡量需求的稳定性8.2面向对象方法基础•对于结构化分析与设计和面向对象的分析与设计来说，信息系统开发的生命周期是相同的，都要经过规划、分析、设计和实施，所不同的是建立的模型和采用的建模技术。•结构化分析与设计注重对过程进行建模，面向对象的分析与设计则强调对事物和它们的交互建模。8.2.1迭代开发过程•根据系统功能自己而不是软件开发活动将项目分解为多个迭代周期，每个迭代周期完成需求定义、分析、设计、实现等活动，生产出经过测试和集成的、可执行的系统子集。在反复迭代过程中可以获取应用反馈并在下一次迭代周期中精化、增强系统功能。•目前有影响力的迭代过程模型是统一过程模型和敏捷开发过程。Rational统一过程模型•RUP不是一个简单具体的过程，而是一个通用的过程框架，适合于不同类型的软件系统、不同的应用领域、不同类型的组织、不同功能级别和项目规模。•RUP的突出特点有：用例驱动，以架构为核心，迭代和增量。•RUP可以用二维坐标来描述。•横轴通过时间组织，是过程展开的生命周期特征，体现开发过程的动态结构，用来描述它的术语主要包括周期(Cycle)、阶段(Phase)、迭代(Iteration)和里程碑(Milestone)；•纵轴以内容来组织为自然的逻辑活动，体现开发过程的静态结构，用来描述它的术语主要包括活动(Activity)、产物(Artifact)、工作者(Worker)和工作流(Workflow敏捷开发过程•敏捷开发过程是一系列轻量过程模型的总称，致力于在无过程和繁琐过程中达到平衡，使以不多的步骤获得较满意的结果，典型的为极限编程（eXtremeProgramming），主要做法如下：•客户作为团队成员•使用用户素材•短期交付•结对编程，集体所有权•测试驱动开发，持续集成•设计简单，注重重构8.2.2UML•UnifiedModelingLanguage（统一建模语言）是对象管理组织（OMG）制定的一个通用的、可视化的建模语言标准。UML的历史BoochmethodOMTUnifiedMethod0.8OOPSLA´95OOSEOthermethodsUML0.9Web-June´96UML1.0UMLpartnerspublicfeedback1989-1994期间，OO方法从不足10种增加到50多种2004FinalsubmissiontoOMG,Nov‘97FirstsubmissiontoOMG,Jan´97UML1.1OMGAcceptance,Nov1997Fall1998UML1.3UML2.0UML的创始人•UML是由世界著名的面向对象技术专家G.Booch、J.Rumbaugh和I.Jacobson发起，在Booch方法、OMT方法和OOSE方法的基础上，广泛征求意见，集众家之长，几经修改而完成的。–Booch方法：Booch方法包含“微开发过程”和“宏开发过程”。–Rumbaugh方法：对象模型化技术(OMT)用于分析、系统设计和对象级设计。分析活动建立三个模型：对象模型，动态模型和功能模型。–Jacobson方法：也称为OOSE(面向对象软件工程)，特别强调使用实例。BoochRumbaughJacobsonUML的特点•统一了面向对象方法的表示•表示能力强大，可用于各种软件系统建模，以及其它系统建模，如商业系统•与开发过程无关•允许扩展•本身不涉及特定语言的语法及规则，但可对应到各种OOP语言框架UML和OOA、OOD•UML既不是方法论，也不是一种开发过程，而是面向对象系统分析与设计的建模语言，是一种语言工具。•OOA&OOD是方法论，该方法论的实践过程中需要使用UML的图符，使用时还必须遵循一定的原则及步骤。UML结构UMLStructure构造块buildingblocks公共机制commonmechanisms构架architecture基本UML建模元素、关系和图达到特定目标的公共UML方法系统架构的UML视图UML1.X结构UML构造块公共机制架构物件关系图规格说明修饰公共分类扩展机制用例视图逻辑视图进程视图实现视图部署视图结构物件行为物件分组物件注解物件关联依赖泛化实现类图顺序图对象图协作图构件图状态图部署图活动图用例图构造块buildingblocks物件things关系relationships图diagrams建模元素本身把物件联系在一起，关系说明两个或多个物件时如何语义相关的UML模型的视图，它们展现物件的集合，“讲述关于软件系统的故事”，是我们可视化系统将做什么（分析级图）或者系统如何做（设计级图）的方法物件things结构物件行为物件分组物件注解物件UML模型中的名词，如类、接口、协作、用例、活动类、构件、节点UML模型的动词，如交互、状态机包，它用于把语义上相关的建模元素分组为内聚的单元注解，它附加到模型以捕获特殊信息，同黄色便笺很相像关系relationships关联association依赖dependency泛化generalization实现realization描述对象之间的一组链接对象的改变引起依赖对象的语义改变一类元素是另一类元素的特化，泛化是相反一般的元素类元之间的关系，一个类元说明一份契约，另一个类元保证实现该契约图diagrams类图classdiagrams对象图objectdiagrams构件图componentdiagrams部署图deploymentdiagrams用例图usecasediagrams顺序图sequence`diagrams协作图collaborationdiagrams状态图statechartdiagrams活动图activitydiagrams静态模型(系统结构)动态模型(系统行为)公共机制公共机制commonmechanisms规格说明specifications修饰adornments公共分类commondivisions扩展机制extensibilitymechanisms规格说明•UML模型至少具有两种维度：–图形维度：允许使用图和图标可视化模型–文本维度：由各种建模元素的规格说明所组成•规格说明–模型元素的特征和语义的文本描述—模型的“肉”–形成了承载模型的语义背板（semanticbackplane），赋予模型意义，各种图仅仅是该背板的视图或者可视化投影–deathbydiagram—由于图形而死亡修饰•修饰：图中建模元素上暴露的信息项以表现某个要点–任何UML图仅是模型的视图，因此，只有在修饰增强了图的整体清晰性和可读性或者突出模型的某些重要特征时，你才应该表示那些修饰Window+size:Area#visibility:Boolean-xptr:XWindow+create:void+hide:void-attachXWindow:voidWindow公共分类•公共分类描述认识世界的特殊方法–类元（Classifier）和实例•类元：一类事物的抽象概念；如bankaccount–参与者、类、类元角色、构件、数据类型、接口、节点、信号、子系统、用例•实例：一类事物的特定实例；如mybankaccount–接口（interface）和实现•接口：说明事物行为的契约（做什么）•实现：事物是如何工作的特殊细节（如何做）扩展机制•约束：允许对模型元素添加新的规则•构造型：基于已有的建模元素引入新的建模元素•标记值：允许为模型元素添加新的特性，是带有相关值的关键字剧目name:String《数据库》TicketDB计划制定{author=FrankMartin,due=Dec.31,1999}{namesforoneseasonmustbeunique}约束版型TicketDB版型图标标记值架构•架构（Architecture）–构架是一个系统的组织结构，包括系统分解成的各个部分、它们的连接性、交互机制和通知系统设计的向导规则–IEEE：在其环境中系统的高级概念4+1视图-1ProcessViewDeploymentViewLogicalViewUse-CaseViewImplementationViewEnd-userFunctionalityProgrammersSoftwaremanagementPerformanceScalabilityThroughputSystemintegratorsSystemtopologyDelivery,installationcommunicationSystemengineeringAnalysts/DesignersStructure4+1视图-2•UseCaseView–End-user:Functionality–这些视图由用例视图所统一，它描述项目干系人（stakeholder）的需求；所有其他视图都是从用例视图派生而来，该视图把系统的基本需求捕获为用例并提供构造其他视图的基础。•LogicalView–