软件工程幻灯片-ch4

1、2019/4/20,1,第二部分 建模,2019/4/20,2,模型,模型: 对问题的书面上的无歧义文字或图形的描述.简言之, 模型是对现实的简化. 通过模型, 人们可以了解所研究事物的本质. 最杰出的模型: 地图,2019/4/20,3,建模 建模: 对现实系统进行适当的过滤, 用适当的表现规则描述出简洁的模型. 建模是一种深入解决问题的方法. 建模的原则 (1). 选择建立什么样的模型对如何发现和解决问题具有重要的影响。正确的模型有助于提高开发者的洞察力。 (2). 每个模型可以有多种表达方式. 使用者的身份和使用的原因是评判模型好坏的关键。,2019/4/20,4,(3). 最好的模型总是能够切合实际. 模型是现实的简化，必须保证简化过程不会掩盖任何重要的细节。 (4). 孤立的模型是不完整的。,2019/4/20,5,软件建模的实现过程,软件建模的作用是把来源于现实世界的问题转化为计算机可以理解和实现的问题. 软件建模的实现过程是从需求入手, 用模型表达分析设计过程, 最终将模型映射成软件实现.,现实世界,计算机世界,映射,需求,模型,编码,2019/4/20,6,第四章 理解

2、需求,2019/4/20,7,最恐怖的噩梦： 一个客户走进你的办公室，坐下，正视着你，然后说：“我知道你认为我说的是什么，但你并不理解的是：我所说的并不是我想要的。”,2019/4/20,8,4.1 需求工程,构建一个软件系统最困难的部分是确定构建什么。其他部分工作不会像这部分工作一样，在出错之后会如此严重地影响随后实现的系统，并且以后修补竟会如此的困难。 Fred Brooks 一些常见的现象 需求工程（Requirement Engineering,RE）是指致力于不断理解需求的大量任务和技术。从软件过程的角度来看，需求工程是一个软件工程动作，开始于沟通活动并持续到建模活动。他必须适应于过程、项目、产品和人员工作的需要。,2019/4/20,9,需求工程为设计和构造奠定了坚实的基础。如果没有需求工程，那么实现的软件很有可能无法满足客户的需求。 需求工程过程通过执行七个不同的活动来实现：起始、导出、精化、协商、规格说明、确认和管理。,2019/4/20,10,起始 建立基本的理解，包括对问题、谁需要解决方案、所期望解决方案的性质、与项目利益相关者和开发人员之间达成初步交流合作的效果。

3、,2019/4/20,11,导出 询问客户、用户和其他人，系统或产品的目标是什么，想要实现什么，系统和产品如何满足业务的要求，最终系统或产品如何用于日常工作，这些问题是非常简单的。但是，实际上并非如此简单“这非常困难。 为什么导出需求这么困难？ 范围问题 理解问题 易变问题,2019/4/20,12,精化 精化是由一系列的用户场景建模和求精任务驱动的。这些用户场景描述了如何让最终用户和其他参与者与系统进行交互。解析每个用户场景以便提取分析类最终用户可见的业务域实体。应该定义每个分析类的属性，确定每个类所需要的服务，确定类之间的关联和协作关系，并完成各种补充图。 精化是件好事，但你必须知道何时可以停止精化。关键是能采用为设计监理一个坚实基础的方式说明问题。如果超出这个点就是在做设计。,2019/4/20,13,协商 需求工程师必须通过协商过程来调解冲突。应该让客户、用户和其他利益相关者对各自的需求排序，然后按优先级讨论冲突。使用迭代的方法给需求排序，评估每项需求对项目产生的成本和风险，表述内部冲突，删除、组合和（或）修改需求，以便参与各方均能达到一定的满意度。 在有效的协商中没有赢家也没

4、有输家，而是双赢。这是因为双方合作才是“交易”的坚实基础。,2019/4/20,14,规格说明 规格说明的形式和格式随着待开发软件的规模和复杂度的不同而变化。 一个规格说明可以是一份写好的文档、一套图形化的模型。一个形式化的数学模型、一组使用场景、一个原型或上述各项的任意组合。 例：湖南省轻工盐业集团人力资源系统需求分析说明书,2019/4/20,15,确认 在确认这一步将对需求工程的工作产品进行质量评估。需求确认要检查规格说明以保证：已无歧义的说明了所有的系统需求；已检测出不一致性、疏忽和错误并得到纠正；工作产品符合为过程、项目和产品建立的标准。 正式的技术评审时最主要的需求确认机制。确认需求的评审小组包括软件工程师、客户、用户和其他利益相关者，他们检查系统规格说明，查找内容或解释上的错误，以及可能需要进一步解释澄清的地方、丢失的信息、不一致性、冲突的需求或是不可实现的需求。 需求确认检查表,2019/4/20,16,需求管理,tortoise SVN,2019/4/20,17,4.2 建立根基,理想情况是：利益相关者和软件工程师在同一个小组工作。 现实情况：往往很难做到。 启动需求

5、工程所必需的步骤 1.确认利益相关者 2.识别多重观点 3.协同合作 4.首次提问,2019/4/20,18,4.2.1 确认利益相关者 利益相关者：直接或间接地从正在开发的系统中获益的人。 在开始阶段，需求工程师应该创建一个人员列表，列出哪些有助于诱导出需求的人员。最初的人员列表将随着接触的利益相关者人数的增多而增加，因为每个利益相关者都将被询问“你认为我还应该和谁交流”。,2019/4/20,19,4.2.2 识别多重观点 把三个利益相关者请进一个房间，然后问他们想要什么样的系统，你很有可能会得到四个或更多的不同观点 作者不详 需求工程师的工作就是把所有的利益相关者和提供的信息（包括不一致或是矛盾的需求）分类，分类的方法应该便于决策制定者为系统选择一个内部一致的需求集合。,2019/4/20,20,4.2.3 协同合作 需求工程师的工作是标识公共区域（即所有利益相关者都同意的需求）和矛盾区域或不一致区域（即某个利益相关者提出的需求和其他利益相关者的需求相矛盾）。很明显，后者更具有挑战性。 协作并不意味着必须由委员会定义需求。在很多情况下，利益相关者的协作是提供他们各自关于需求的观点

6、，而一个强有力的“项目领导者”（例如业务经理或高级技术员）可能要对删减哪些需求做出最终决策。,2019/4/20,21,4.2.4 首次提问 问问题的人是五分钟的傻瓜，而不问问题的人将永远是傻瓜。 中国谚语 什么问题有助于你获得对问题的初步认识？ 在需求导出时的提问应该是“与环境无关的”。第一组与环境无关的问题集中于客户和其他利益相关者、整体目标、收益。 下一组问题有助于软件开发组更好的理解问题，并允许客户表达其对解决方案的看法 最后一组问题关注与沟通活动本身的效率。,2019/4/20,22,4.3 导出需求,导出需求（又称为需求收集）是与问题求解、精化、谈判和规格说明等方面的元素结合在一起的。为了鼓励合作，一个包括利益相关者和开发人员的团队共同完成如下任务：确认问题，为解决方案的要素提供建议，商讨不同的方法并描述初步的需求解决方案。 1.协作收集需求 2.质量功能部署 3.用户场景 4.导出工作产品,2019/4/20,23,4.3.1 协作收集需求 主持一个协作需求收集会议的基本原则是什么？ 会议由软件工程师和其他的利益相关者共同举办和参与。 制定筹备和参与会议的规则。 建议拟定

7、一个会议议程，这个议程既要足够正式，使其涵盖所有的重点；但也不能太正式，以鼓励思想的自由交流。 由一个“调解人”（可以是客户、开发人员或其他人）控制会议。 采用“方案论证手段”（可以是工作表、活动挂图、不干胶贴纸或电子公告牌、聊天室或虚拟论坛）。 目的： 识别问题，提出解决方案的要素，协商不同的方法以及在有利于完成目标的氛围中确定一套解决需求问题的初步方案。,2019/4/20,24,4.3.2 质量功能部署（Quality Function Deployment，QFD） 一种将客户要求转为成软件技术需求的质量管理技术，目的是最大限度的让客户从软件工程过程中感到满意。为了达到这个目标，QFD强调理解“什么是对客户有价值的”，然后在整个工程活动中部署这些价值。QFD确认了三类需求： 正常需求：特定的系统功能 期望需求：人机交互的容易性，软件安装的简易性 令人兴奋的需求：多重触控技术的触摸屏,2019/4/20,25,4.3.3 用户场景 当收集需求时，系统功能和特性的整体愿景开始具体化。但是在软件团队弄清楚不同类型的最终用户如何使用这些功能和特性之前，很难转移到更技术化的软件工程活动。

8、为实现着一点，开发人员和用户可以创建一系列的场景（场景可以识别对将要构建系统的使用线索）。场景通常称为用例，它提供了将如何使用系统的描述。,2019/4/20,26,4.3.4 导出工作产品 什么样的信息是需求收集产生的？ 要求和可行性陈述 系统或产品范围的界限说明 参与需求导出的客户、用户和其他利益相关者的名单 系统技术环境的说明 需求列表（最好按照功能加以组织）以及每个需求适用的领域限制。 一系列使用场景，有助于深入了解系统或产品在不同运行环境下的使用。 任何能够更好的定义需求的原型 所有参与需求导出的人员需要评审以上的每一个工作产品。,2019/4/20,27,4.4 开发用例,从参与者的角度定义用例。参与者是人员（用户）胡设备在和软件交互时所扮演的较色。 参与者和最终用户并非一回事。典型的用户可能在使用系统时扮演了许多不同的较色，而参与者表示了一类外部实体，在用例中他们仅扮演一种较色。 主要参与者和次要参与者 开发用例,2019/4/20,28,4.5 构建需求模型,4.5.1 需求模型的元素 基于场景的元素 功能说明处理软件功能的描述 用例描述“参与者”和系统之间的交互作用

9、基于类的元素 由场景暗示 行为元素 状态图 面向数据流元素 数据流图,2019/4/20,29,一组用户场景，描述系统的线程使用 从“参与者”的点-视角来描述每一个场景人或设备以某种方式与软件交互 每一个场景回答以下问题： 谁是主要参与者、次要参与者？ 参与者的目标是什么？ 故事开始前有什么前提条件？ 参与者完成的主要工作或功能是什么？ 按照故事所描述的还可能需要考虑什么异常？ 参与者的交互中有什么可能的变化？ 参与者将获得、产生或改变哪些系统信息？ 参与者必须通知系统有关外部环境的改变吗？ 参与者希望从系统获取什么信息？,2019/4/20,30,30,用例图,房主,安装/接触系统,通过因特网访问系统,报警事件的响应,遇到错误条件,重新配置传感器以及相关的系统特性,传感器,系统管理员,2019/4/20,31,31,类图,从SafeHome 系统,传感器,2019/4/20,32,32,状态图,Reading Commands,System status = “ready” Display msg = “enter cmd” Display status = steady,Entry/subsystems ready Do: poll user input panel Do: read user input Do: interpret user input,State name,State variables,State activities,状态名,状态变量,状态活动,读指令,2019/4/20,33,33,分析模式,模式名称： 捕获模式本质的描述符。 目的： 描述该模式实现了或代表什么。 动机： 说明怎样用模式解决问题的一个场景。 影响环境： 对外部问题（影响）的描述，即能够影响如何使用模式，并当应用该模式时，影响即将被解决的外部问题。 解决方案：对如何应用模式来解决强调结构和行为问题的描述。 效果： 解决了发生在应用模式时和应用过程中存在权衡的问题。 设计： 通过使用已知的设计模式讨论如何实现该分析模式。 已知应用: 在实际系统中使用的例子。 相关模式：与命名模式有关的一个或更多分析模式，因为(1) 与命名模式共同使用；(2) 在结构上，与命名模式相似；(3)

《软件工程幻灯片-ch4》由会员F****n分享，可在线阅读，更多相关《软件工程幻灯片-ch4》请在金锄头文库上搜索。