1、软 件 工 程第一章 软件工程概述第一章 软件工程概述 了解软件工程历史 软件的概念与特点 软件的分类 软件的发展和软件危机 软件工程的目标和原则 认识软件开发过程模型 软件过程 软件过程模型了解软件工程历史 软件定义 软件是计算机系统中与硬件相互依存的另一部分，它是包括程序，数据及其相关文档的完整集合。程序是按事先设计的功能和性能要求执行的指令序列。数据是使程序能正常操纵信息的数据结构。文档是与程序开发，维护和使用有关的图文材料。软件的特点（1）软件是一种逻辑实体，它具有抽象性。软件成本集中在开发上，对软件的质量控制必须从软件的开发着手。软件在运行和使用过程中没有磨损、老化问题。软件一旦研制
2、成功，其生产过程就变成复制过程，会出现软件产品版权保护问题。软件存在升级和移植的问题，所产生的维护成本通常比开发成本要高许多。4 软件的特点（2）大多数软件仍然是定制的。软件本身是复杂的。软件涉及因素多。由于软件研制工作需要投入大量、复杂、高强度的脑力劳动，导致了软件成本昂贵。5 软件的分类 按软件的功能进行划分 系统软件 支撑软件 应用软件6按软件规模进行划分7分类分类参加人员参加人员开发期限开发期限程序规模程序规模/源程序行数源程序行数特征特征微型微型114周周500以下以下不必有严格的设计和测试文档不必有严格的设计和测试文档小型小型1216月月1k2k通常没有与其他程序的接口通常没有与其
3、他程序的接口中型中型3512年年5k50k需要有严格的文档和设计规范需要有严格的文档和设计规范大型大型52023年年50k100k需要按照软件工程方法进行管理需要按照软件工程方法进行管理超大型超大型 100100045年年1M(=1000k)必须按照软件工程开发，有严格的质量必须按照软件工程开发，有严格的质量管理措施管理措施巨型巨型20005000510年年1M10M同上同上表表1-1 软件规模的分类软件规模的分类 按软件工作方式划分 实时处理软件 分时软件 交互式软件 批处理软件 按软件服务对象的范围划分 项目软件 产品软件 按使用的频度进行划分 按软件失效的影响进行划分8 软件的发展 程序
4、设计阶段 50至60年代 程序系统阶段 60至70年代 软件工程阶段 70年代以后 软件发展阶段最根本的变化 人们改变了对软件的看法 软件的需求是软件发展的动力 软件工作的范围从考虑程序的编写扩展到设计整个软件生存期 目前：社会信息化、软件产业化的阶段过渡软件危机 软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。即包含两方面的问题：如何开发软件、如何维护软件。具体表现 软件开发成本估计不准，开发成本超出预算 开发进度不能保证，交付时间一再拖延 开发出来的产品不符合用户的需求 软件产品质量无法保证 软件的可维护程度低 软件开发生产率的发展跟不上硬件的发展速度和人们需求的增长 产
5、生原因 根本原因软件开发过程不成熟 忽视软件开发前期的调研和分析工作 没有统一的、规范的方法论指导 文档资料不齐全，忽视人与人的交流 忽视测试阶段的工作 忽视软件的维护 消除软件危机的途径 软件工程的定义 软件工程是用工程、科学和数学的原则与方法研制、维护计算机软件的有关技术和管理方法。软件工程三要素：过程、方法和工具 软件开发过程为建造高质量的软件所需完成的任务框架 软件工程方法为软件开发提供了“如何做”的技术 软件工具为软件工程方法提供了自动的或半自动的软件支撑环境 软件工程项目的基本目标 组织实施软件工程项目，从技术上和管理上采取了多项措施以后，最终希望得到项目的成功。所谓成功指的是达到
6、以下几个主要的目标付出较低的开发成本；达到要求的软件功能；取得较好的软件性能；开发的软件易于移植；需要较低的维护费用。软件工程的基本原理 用分阶段生命周期计划严格管理 坚持进行阶段评审 实行严格的产品控制 采用现代程序设计技术 结果应能清楚地审查 开发小组的人员应该少而精 承认不断改进软件工程实践的必要性认识软件开发过程模型 软件过程 通过定义若干框架活动来建立公共过程框架，每一个任务集合都由软件工程工作任务、项目里程碑、软件工程产品（交付物）和质量保证点组成，通过多个任务集合来保证框架活动可被修改，以适应不同软件项目特征和项目组的需要。软件过程模型软件开发（过程）模型是跨越整个生存期的系统开
7、发、运作和维护所实施的全部过程、活动和任 软件开发过程定义了 方法使用的顺序 要求交付的文档资料 为保证质量和适应变化所需要的管理 软件开发各个阶段完成的里程碑 常用的模型介绍 瀑布模型 原型（演化）模型 螺旋模型 喷泉模型 构件组装模型 统一过程模型RUP瀑布模型 瀑布模型（生存周期模型）就是传统的生命周期方法学（既自顶向下结构化开发模型方法）。优点：奠定了软件工程方法的基础；流水依赖；便于分工协作；推迟现实；文档易修改；有复审质量保证。缺点：用户需求明确困难；用户见面晚；纠错慢；难于克服系统分析员不懂专业领域的知识，用户不懂计算机的困难，成功率低。适合于系统要求明确的小系统。软件生存期的瀑
8、布模型软件生存期的瀑布模型 问题定义可行性研究需求分析概要设计详细设计编码测试运行维护评价返回计划维护阶段开发阶段定义阶段定义做什么的问题结构设计如何做的体系结构修改设计需求说明书设计说明书源程序清单测试报告维护报告原型模型（rapid prototype model）原型模型（rapid prototype model）是为了确定需求而提出的实际模型。打破传统的自顶向下结构化开发模型方法，在计划和需求分析后，把系统主要功能接口做为设计依据，快速开发出软件样机，及时征求用户意见，正确确定系统需求，然后再进一步准确地进行系统设计与实现。优点：与用户见面快；开发成功率高，适合于需求不确定的大系统。
9、缺点：周期长，开发成本高。原型模型原型模型 螺旋模型螺旋模型沿着螺线旋转（一个螺旋式周期），在四个象限上分别表达四个方面的活动，即：制定计划确定软件目标，选定实施方案，弄清项目开发的限制，选定完成目标的策略风险分析分析所选方案，考虑如何识别和消除风险，风险角度分析该策略实施工程实施软件开发，启动一个开发阶段 客户评估评价前一步开发工作，提出修正建议，计划下一轮的工作 特点 瀑布模型+快速原型+风险分析 迭代过程喷泉模型 喷泉模型对软件复用和生存期中多项开发活动的集成提供了支持，主要支持面向对象的开发方法。喷泉一词本身体现了迭代和无间隙特性。系统某个部分常常重复工作多次，相关功能在每次迭代中随之
10、加入演进的系统。所谓无间隙是指在开发活动，即分析、设计和编码之间不存在明显的边界。喷泉模型示意图并发模型 并发过程模型定义了一系列事件，对于每一个软件活动，这些事件触发了从一个状态到另一个状态的变迁。2728基于构件的开发模型 特点：形式化软件开发方法（形式化需求规格说明、变换技术）、程序自动生成技术、确保正确喷泉模型 喷泉模型是一种以用户需求为动力，以对象为驱动的模型，主要用于描述面向对象的软件开发过程。总结软 件 工 程第二章 软件项目管理第二章 软件项目管理 了解软件项目管理的内容 软件项目产品的特点 软件项目管理的内容 对项目进行计划 IT项目估算、计划和进度管理 组织管理任务1 了解
11、软件项目管理的内容 软件管理的目标就是保证软件项目的成功，就是保证在规定的时间内、预算计划内开发出令用户满意的软件产品。软件开发的所有成员都紧紧围绕这一个目标进行工作。那么，针对上一章选取的软件项目进行项目管理，应该包含哪些具体的内容呢？351.软件项目产品的特点 软件项目管理的任务 根据项目合同书的要求，制定项目计划和工程进度安排、监督和检查项目实施过程、保证工程满足要求的质量标准、分析确定并排除风险、在规定的期限和预算成本内完成项目。软件项目产品的特点 抽象性 缺陷检测的困难性 高度的复杂性 缺乏统一规则372.软件项目管理的内容 什么是软件项目管理 软件项目管理是为了使软件项目能够按照预
12、定的成本、进度、质量顺利完成，而对成本、人员、进度、质量、风险等进行分析和管理的活动。软件项目管理的对象是软件工程项目，它所涉及的范围覆盖了整个软件工程过程。38 项目管理的主要要素 范围，也称工作范围。指为了实现项目目标必须完成的所有工作。一般通过定义交付成果和交付成果的标准来定义工作范围。时间，也称为项目进度。与项目时间相关的因素用进度计划来描述，进度计划不仅说明了完成项目工作范围内所有工作需要的时间，也规定了每个活动的具体开始日期和完成日期。成本，也称为项目费用。指完成项目所需要的所有款项的费用，包括人力成本、原材料、设备租金、分包费用和咨询费用等。质量。指项目满足明确或隐含需求的程度，
13、与绩效和满意度密切相关。一般通过定义工作范围中的交付物标准来明确定义，这些标准包括各种特性及这些特性需要满足的要求。39 项目管理的过程 启动软件项目 制订项目计划 评审项目计划 编写管理文档40 项目管理的内容 项目的范围管理 时间管理 成本管理 质量管理 人员的组织管理 沟通管理 风险管理 采购管理和集成管理41任务2 对项目进行计划 一个软件项目如果要进入到系统实施阶段，需要做的准备工作可能包括如何对项目进行阶段性的划分，在每个阶段中的工作重点和任务是什么，完成本阶段工作和任务的人力、资源需求，时间期限，阶段工作和任务的成果形式等等，这些都是在项目启动时需要进行考虑的内容。那么，针对于我
14、们目前的项目，应该如何组织管理这些任务呢？421.IT项目估算、计划和进度管理 影响IT项目进度的因素 低估IT项目实现的条件 项目参与者的失误 不可预见事件的发生 项目状态信息收集的情况 计划变更调整的及时性43 IT项目进度控制 识别偏差 分析偏差原因 确定对既发偏差的态度 关注进度正偏差 调整项目进度计划442.组织管理 人员是软件机构中最重要的资产，他们代表着智力资本。合理地调配人员是成功完成软件项目的切实保证。因此软件项目管理的关键是人员管理。项目管理者必须利用其团队成员，用可能最有效的方式解决技术和非技术上的问题。软件机构要尊重员工，管理者要激励员工。软件项目成功的关键是能够将高素
15、质的软件开发人员合理地组织起来，使他们有效地分工协作，共同完成开发工作。项目组的组织原则 软件开发小组的规模不宜太大，人数不能太多，一般3-5人左右为宜。切忌在开发过程中增加人员，这将使人员之间的联系增多，造成通信成本的增加而导致效率降低。项目组的组织方式 民主制程序员组 主程序员组 现代程序员组 民主程序员组 小组成员完全平等，享有充分民主，通过协商做出决策。小组成员之间的通讯是平行的，如果小组有n个成员，则可能的通讯信道为 条。民主制程序员组通常采用非正式的组织方式，虽然名义上有一个组长，但其与组内其它成员完成同样的任务。由小组全体成员讨论协商决定应该完成的工作，并依据各成员能力和经验分配
16、适当的任务。n(n-1)/2 优点：组员对发现程序错误持积极的态度，这种态度有助于更快地发现错误，从而导致高质量的代码；组员享有充分民主，小组有高度凝聚力，组内学习气氛浓厚，有利于攻克技术难关。缺点 在组内多数成员技术水平不高或缺乏经验情况下采用该组织方式，将会因为没有明确的权威指导项目进展，小组成员间缺乏必要的协调，而导致项目失败。应用 适合于研制周期长、难度大的项目。日本大多数软件开发公司都采用这种形式。主程序员组 主程序员组使用经验丰富、技术好、能力强的程序员作为主程序员。同时，利用人和计算机在事务性工作方面给主程序员提供充分支持，而且保证所有通讯都通过一两个人进行。后备程序员 后备程序
17、员也应该技术熟练而且富于经验，他协助主程序员工作并且在必要时(主程序员生病、出差或跳槽)接替主程序员的工作。所以后备程序员必须和主程序一样优秀，一样深入了解项目。主程序员 主程序员既是成功的管理人员，又是经验丰富、技术好、能力强的高级程序员，负责体系结构设计和关键部分的详细设计，并且负责指导其他程序员完成详细设计和编码工作 编程秘书 编程秘书负责完成与项目有关的全部事务性工作，如，维护项目资料库和项目文档，编译、连接、执行源程序和测试用例。虽然主程序员组有很多优点，但是，我们还应看到这种组织方式固有的不切实际的地方：主程序员既是高级程序员又是优秀管理者，但现实中这种人才很难见到。后备程序员更难
18、找。人们希望后备程序员像主程序员一样优秀，但他们必须坐在“替补席”上，拿着较低的工资等待接替主程序员。编程秘书也很难找。专业的软件技术人员一般都厌烦日常的事务性工作。现代程序员组 特点 将“主程序员组”中的主程序员的职则划为两个人来承担：一个技术负责人，负责小组的技术活动 一个行政负责人，负责所有的非技术的决策活动现代程序员组 大型项目的技术管理组织结构包含分散决策的组织方式 优点 将管理和行政分开，有助于调动组员的积极性 行政组长和技术组长分工明确 避免了“主程序员组”中，全才主程序员难找的问题 缺点 有时行政组长和技术组长的管理权限界限不明 选择软件工程小组结构时应考虑的7个因素 待解决问
19、题的困难程度 要开发程序的规模 小组成员在一起工作的时间 问题能够被模块化的程度 对待开发的系统的质量和可靠性的要求 交付日期的严格程度 项目要求的社交(通信)程度通过对一些知名企业的调研，在整个软件项目活动的五个阶段大致涵盖了通过对一些知名企业的调研，在整个软件项目活动的五个阶段大致涵盖了1414个职位个职位 ；项目经理、需求分析师、系统分析师、系统架构设计师、软件架构设计师、网络架构设计师、数据库设计师、软件界面设计师、软件工程师、编码程序员、网络工程师、软件测试工程师、质量保障工程师及产品发布工程师；实现阶段实现阶段构成阶段构成阶段立项阶段立项阶段需求分析阶段需求分析阶段需求分析师项目经
20、理系统架构设计师软件架构设计师数据库设计师软件界面设计师网络架构设计师系统分析师软件开发工程师编码程序员网络工程师软件测试工程师质量保障工程师产品发布工程师结束阶段结束阶段项目经理软件企业的职位概况 IT组织管理 软件开发组织机构设置 组织机构的职责分工 软件开发项目组的角色60 总结小结 理解 项目组的组织方式及其特点 掌握 项目计划的内容62软 件 工 程第三章 需求工程（1）任务1 获取用户想法 需求概述 需求获取64任务1 获取用户想法 我们现在有一个来自于某高校系内资料室的图书管理的需求。这个资料室是一个新建的图书资料室。由于一般的图书管理系统是针对具有一定规模的图书馆设计的，所以用
21、在目前规模较小的图书资料室上有些大材小用，并且也大大超出了成本的预算。因此用户一方面希望能够有一套图书管理系统帮助图书管理员完成日常上的图书借阅管理的工作，同时又能满足小型资料室规模不大的需求。所以，该资料室希望能够根据其自身的特点制定一套合理、有效、规范和实用的图书管理系统，完成对图书资料集中统一的管理。65 我们希望通过对用户需求做进一步的了解，明确用户当前遇到的具体问题和希望达成的目标，这些信息的掌握将为后续软件开发指明方向。但是，我们到底需要获得哪方面的信息，有什么样的具体措施和方法能够帮助我们捋顺思路，更有目的性地获取这些信息呢？661.需求概述 什么是需求？用户解决问题或达到目标所
22、需要的条件或权能。系统或系统部件要满足合同、标准、规范或其他正式规定文档所要具有的条件或权能。反映上面两条的文档说明。需求工程 指系统分析人员通过细致的调研分析，准确地理解用户的需求，将不规范的需求陈述转化为完整的需求定义，再将需求定义写成需求规约的过程。需求工程包含需求开发和需求工程管理两部分。（1）需求类型 功能需求 功能需求描述系统所应提供的功能和服务，包括系统应该提供的服务、对输入如何响应及特定条件下系统行为的描述。非功能需求 作为功能需求的补充，非功能需求是指那些不直接与系统的具体功能相关的一类需求，但它们与系统的总体特性相关，如可靠性、响应时间、存储空间等。68非功能性需求的类型
23、领域需求 领域需求的来源不是系统的用户，而是系统应用的领域，反映了该领域的特点。它们主要反映了应用领域的基本问题，如果这些需求得不到满足，系统的正常运转就不可能。领域需求可能是功能需求，也可能是非功能需求，其确定所需的领域知识。它经常采用一种应用领域中的专门语言来描述。业务需求 反映组织机构或客户对软件高层次的目标要求，这项需求是用户高层领导机构决定的，它确定了系统的目标规模和范围。用户需求 用户使用该软件要完成的任务 系统需求 容易被忽视的要求通常是为了保证整个系统能够正常运行的辅助功能,用户一般不会意识到。软件需求各组成部分之间的关系（2）需求开发目标 建立分析模型 分析模型是描述软件需求
24、的一种模型，由于各个用户往往会从不同的角度阐述他们对原始问题的理解和对目标软件的需求，因此，有必要为原始问题及其目标软件系统建立模型。这种模型一方面用于精确地记录用户对原始问题和目标软件的描述；另一方面，它也将帮助分析人员发现用户需求中的不一致性，排除不合理的部分，挖掘潜在的用户需求。这种模型往往包含问题及其环境所涉及的信息流、处理功能、用户界面、行为模型及设计约束等，它是形成需求说明，进行软件设计、实现的基础。构建正式的需求文档73 需求开发 活动 可行性研究 需求导出和分析 需求描述 需求有效性验证 需求管理 活动 需求变更控制 版本控制 需求跟踪 需求状态跟踪文档文档用户需求说明书用户需
25、求说明书产品产品(系统系统)需求规格需求规格说明书说明书文档文档需求评审报告需求评审报告需求跟踪报告需求跟踪报告需求变更控制报告需求变更控制报告（3）需求开发过程需求开发过程模型75需求开发与需求管理流程图 需求规格说明书与其它开发活动之间的关系需求规格说明书软件设计验收测试项目计划产品发布用户培训签订合同需求评审需求获取需求分析需求规格说明书需求审查需求工程 需求规格说明书对系统开发过程中其它活动的影响 项目的开发成本、进度、资源使用量等都是以需求规格说明书为依据 项目经理根据它制定开发计划 设计人员根据它进行系统设计 测试人员根据它编写测试计划。设计测试用例 产品发布人员根据它编写产品介绍
26、和客户文档 培训人员根据它编写培训教程2.需求获取 需求获取（requirements elicitation）也称为需求收集（requirements capture），它是与发现目标系统应该提供的需求相关的活动的统称。对起初一系列需求的提炼和扩展的过程就称为需求分析（requirements analysis）。（1）需求获取的方法 需求获取的步骤 需求获取的方法 建立联合分析小组 由用户、系统分析员和领域专家构成的需求收集方法 搜集现有文档、报表等。这是最常用的方法，但必须依靠企业负责人和系统最终用户的帮助，才能获得所需文件；座谈会。由开发组组织用户和相关部门的经理、IT技术人员以及高层
27、管理人员参加，目的是集中精力、缩短时间、提高搜集信息的效率和准确度；访谈。对各级管理人员和工作人员要自上而下地进行访问，有针对性地对细节做专门访问。其优点是能够得到更多的信息，缺点是耗费时间；调查问卷。涉及调查表，对一些共性的问题进行较大范围的调查，但效果不一定好，观察工作环境，参加业务实践；原型法。由于用户对系统需求的含义不甚了解，因此由系统开发人员为用户提供可以借鉴的模型系统，引导用户提出更加合理的需求。82（2）分析人员与用户的合作关系 了解用户 用户是一种泛称，它可细分为“客户”、“最终用户”、“间接用户”(或称为关系人)客户：掏钱买软件的用户 最终用户：最终操作软件的用户 间接用户：
28、既不掏钱买软件，也不使用软件，但它可能对软件产品产生很大影响。分清用户的重要性 项目需求工程实施中客户与分析人员、开发人员交流时的合法要求（权利）。要求分析人员使用符合客户语言习惯的表达 要求分析人员了解客户的业务及目标。要求分析人员编写软件需求规约。要求得到需求工作结果的解释说明。要求开发人员尊重客户的意见。要求开发人员对需求及产品实施提供建议，拿出主意。描述产品易使用的特性。调整需求，允许重用已有的软件构件。获得满足客户功能和质量要求的系统。软件需求获取过程中客户有下列义务。给分析人员讲解自己的业务。抽出时间清楚地说明宽完善需求。准确而详细地说明需求。及时地做出决定。尊重开发人员的需求可行
29、性及成本评估。划分需求优先级别。评审需求文档和原型。需求出现变更要马上联系。应遵照开发组织处理需求变更的过程。尊重开发人员采用的需求工程过程。软 件 工 程第三章 需求工程（2）任务2 构建功能模型 需求分析 结构化分析法 功能建模 任务3 构建数据模型 任务4 构建行为模型87任务2 构建功能模型 我们在任务1中对图书管理系统作了初步的了解和设想，但是仍然有很多细节信息没有完全描述出来。一般情况下我们会通过语言描述来记录用户在执行业务过程中的一些规则和对数据的要求，但是这样会存在很大的问题。一方面语言描述非常的繁多，不容易理解；另一方面，语言本身也容易存在二义性，容易造成理解上的偏差。那么，
30、是否存在什么更好的方式来记录用户的业务使用细节，同时也可以帮助我们捋清用户的业务思路，清晰地记录下用户的相关数据信息？881.需求分析 “软件危机”，在本质上是需求危机，而需求危机实际上是交流危机。为了消除“软件危机”，就需要在软件工程师和最终用户之间架起一座桥梁以便于沟通，并使得最终用户也参与项目的开发。（1）软件需求分析 问题识别 评价和综合 建模 规约 评审 需求阶段文档的区别 内容 用户需求。是用自然语言加图表的形式给出的关于系统需要提供哪些服务，以及系统操作受到哪些约束的声明。软件需求规约(需求规格说明书)。详细地给出系统将要提供的服务以及系统所受到的约束。软件需求规约文档有时也称为
31、功能描述，应该非常精确，它可能成为系统买方和软件开发者之间合同的主要内容 读者对象2 结构化分析方法 结构化分析是一种建立模型的活动，通过数据、功能和行为模型来描述必须被建立的要素。逻辑模型 分析模型的要素 数据流图(DFD)描述数据在系统中如何被传送或变换，以及描述如何对数据流进行变换的功能（子功能）；实体关系图(ERD)描述数据对象及数据对象之间的关系；状态迁移图(STD)描述系统对外部事件如何响应，如何动作。数据字典(DD)就是用来定义数据流图中的各个成分的具体含义的，它以一种准确的、无二义性的说明方式为系统的分析、设计及维护提供了有关元素的一致的定义和详细的描述。它和数据流图共同构成了
32、系统的逻辑模型，是需求规格说明书的主要组成部分。3 功能建模和数据流图（DFD）功能建模 用抽象模型的概念，按照软件内部数据传递、变换的关系，自顶向下逐层分解，直到找到满足功能要求的所有可实现的软件为止。使用数据流图来表达系统内数据的运动情况，而数据流的变换则用结构化英语、判定表与判定树来描述。数据流图中的主要图形元素 数据源点或终点(外部实体)数据加工(数据处理、数据变换、转换)数据存储文件 数据流或或或 例子-描述银行取款过程的数据流图储户清单数据2.1验证有效性储户信息2.3取款处理2.4打印清单利息清单取款信息有效取款信息2.5计算清单取款处理信息2.2合法性验证合法取款信息 数据流与
33、数据加工之间的关系 数据流图的层次结构 为了表达数据处理过程的数据加工情况，需要采用层次结构的数据流图。按照系统的层次结构进行逐步分解，并以分层的数据流图反映这种结构关系，能清楚地表达和容易理解整个系统。在多层数据流图中，顶层流图仅包含一个加工，它代表被开发系统。它的输入流是该系统的输入数据，输出流是系统所输出数据。底层流图是指其加工不需再做分解的数据流图，它处在最底层。中间层流图则表示对其上层父图的细化。它的每一加工可能继续细化，形成子图。数据流图的画法 基本原则：自外向内，自顶向下，逐层细化，完善求精。步骤：先找系统的数据源点与终点。找出外部实现的输出数据流和输入数据流。在图的边上画出系统
34、的外部实体。从外部实体的输入数据流（系统的源点）出发，按照系统的逻辑需要，逐步画出一系列逻辑加工，直到找出外部实体所需要的输出数据流（既系统的汇点），形成数据流的封闭。进行检查和修改。再逐个加工处理过程，画出所需要的子图。结构化分析方法功能建模举例 某企业销售管理系统 数据流图绘制步骤 首先确定系统的输入和输出(系统的边界)根据销售管理业务，画出顶层数据流图，以反映最主要业务处理流程(封闭)103这个数据流图只是一个高层的系统逻辑模型，它反映了目这个数据流图只是一个高层的系统逻辑模型，它反映了目标系统要实现的功能标系统要实现的功能 经过分析，销售管理业务处理的主要功能应当有处理订单、供货处理、
35、进货单处理、缺货统计和销售统计五大项。主要数据流输入的源点和输出终点是顾客、仓库、经理和采购部门。然后从输入端开始，根据企业销售工作流程，画出数据流流经的各加工框，逐步画到输出端，得到第一层数据流图（从左到右）练习1 请采用DFD描绘一个简单的大学课程选课系统的关联图。其中教务处提供有关课程的信息，学生申请选课后得到课程时间表，教师在学生选课完成后得到班级列表。练习2假设一家工厂的采购部每天需要一张订货报表，报表按零件编号排序，表中列出所有需要再次订货的零件。对于每个需要再次订货的零件应该列出下述数据：零件编号、零件名称、订货数量、目前价格、主要供应者和次要供应者。零件入库或出库称为事物，通过
36、放在仓库中的CRT终端把事物报告给订货系统。当某种零件的库存数量少于库存量临界值时就应该再次订货。数据流程图的注意点 DFD上所有图形符号只限于前述四种基本元素 DFD主图必须包括前述四种基本元素，缺一不可 DFD的主图上的数据流必须封闭在外部实体之间 每个加工至少有一个输入数据流和一个输出数据流 在数据流图中，需按层给加工框编号。编号表明该加工所处层次及上下层的亲子关系 规定任何一个数据流子图必须与它上一层的一个加工对应，两者的输入数据流和输出数据流必须一致。此即父图与子图的平衡 可以在数据流图中加入物质流，帮助用户理解 图上每个元素都必须有名字，编号 数据流图中不可夹带控制流 初画时可以忽
37、略琐碎细节，以集中精力于主要数据流 一个处理逻辑，在下一层分解时不宜超过7个处理逻辑任务3 构建数据模型 我们构建了功能模型之后会发现在功能模型中使用到了很多的数据，尤其出现了需要持久化保存的数据存储。那么在实际业务运转过程中，这些数据之间有什么约束关系吗？如果约束存在，我们的系统在运转过程中就必须要遵守这些约束。然而，我们该如何表示这些数据之间的约束，描述这种关系呢？111数据建模 数据模型包括三种互相关联的信息：数据对象，描述对象的属性，描述对象间相互连接的关系。数据对象：是需被目标系统所理解的复合信息的表示。它具有若干不同特征或属性的信息。数据对象可以是外部实体,事物,角色,行为或事件,
38、组织单位,地点或结构。数据对象只封装了数据，没有包含作用于这些数据上的操作。属性：定义了数据对象的特征。它可用来：为数据对象的实例命名；描述这个实例；建立对另一个数据对象的另一个实例的引用；主码：为了唯一地标识数据对象的某一个实例，定义数据对象中的一个属性或几个属性为主码(key)，书写为_id。例如在“学生”数据对象中用“学号”做关键码，它可唯一地标识一个“学生”数据对象中的实例。关系：各个数据对象的实例之间的关联。如一个学生“张鹏”选修两门课程“软件工程”与“计算机网络”，学生与课程的实例通过“选修”关联起来。实例的关联有三种：一对一(1:1)；一对多(1:m)；多对多(n:m)。这种实例
39、的关联称为“基数”。基数表明了“重复性”。如 1 位教师带学生班的 30 位同学，就是 1:m 的关系。实例关联有是“可选”还是“必须”之分。也有 1 位教师带 0 位同学的情形 用“O”表示关系是可选的，用“”表示关系必须出现 1 次。这表明了关系的“参与性”。管带管带 例子 某管理信息系统具有以下实体、属性及语义描述：每名教师教授若干课程，每门课程可以由若干教师来教授，每个班级有若干学生，每名学生可以学习若干门课程，每门课程可以有若干学生学习，每名学生学完一门课程后得到一个成绩。描述教师的属性有：员工号，姓名，性别，住址。描述课程的属性有：课程号，课程名，学分。描述学生的属性有：学号，姓名
40、，性别，出生日期。描述班级的属性有：班号，人数。教师课程教授学习学生成绩mnnm班级有员工号姓名性别课程号课程名学分住址学号姓名性别出生日期班号人数n1ER图 练习 学校由若干个系组成，每个系有若干名教师和学生，老师或者学生只能属于某一个特定院系；每个教师可以担任若干门课程，并参加多项科研项目；教师的工资由其职称决定，每位老师都拥有自己的工作证；每门课程可以由若干老师任教；每个学生可以同时选修多门课程。请设计教学管理的E-R模型，并根据自己的理解标示实体、联系及其属性。任务4 构建行为模型 在我们进行需求获取，分析整理用户的功能需求的过程中，我们会发现不但要捋顺业务流程，还有很多业务规则需要我
41、们特别关注。这些业务规则往往特定于某个业务对象，针对这个业务对象所发生的变化将导致相应的业务规则及业务运行方式发生改变。此时我们需要通过模型的建立来记录这种变化。那么，在结构化分析模型中，哪种模型可以用来记录行为的变迁呢？118行为建模和状态迁移图 行为建模给出需求分析方法的所有操作原则，但只有结构化分析方法的扩充版本才提供这种建模的符号。状态迁移图 描述系统的状态如何相应外部的信号进行推移的一种图形表示 圆圈“”表示可得到的系统状态 箭头“”表示从一种状态向另一种状态的迁移（写上导致迁移的信号或事件的名称）例子 没人打电话时电话处于闲置状态；有人拿起听筒则进入拨号音状态，到达这个状态后，电话
42、的行为是响起拨号音；这时如果拿起听筒的人改变主意不想打了，他把听筒放下（挂断），电话重又回到闲置状态；如果拿起听筒很长时间不拨号（超时），则进入超时状态；如果此人想打电话，开始拨数字，此时出现拨号音，电话处在拨号状态；当拨完电话号码之后，是有效的电话号码则电话试图接通对方，处在试接通状态；如果电话号码无效，则播放提示信息；如果拨号的时间过长（超时），则进入超时状态，响起蜂鸣音。闲置拨号音do:响拨号音拨号接通中do:试接通振铃do:振铃通话断线超时do:响蜂鸣音存储的信息do:播放信息忙音do:响忙音挂断电话超时拿起听筒数字超时无效号码有效号码已接通受话人回话受话人挂断电话信息播完占线挂断电话
43、数字 该状态转换图表达了银行领域中如下业务知识：储蓄账户有正常、挂失、冻结、销户等4种状态；有效的储蓄账户始于开户交易，开户交易成功后储蓄账户处于正常状态；开户交易的业务规则是：开户金额10元人民币；用户可以凭身份证要求对自己的储蓄账户进行挂失和解挂交易；银行可以根据授权（例如司法授权）对储蓄账户进行冻结和解冻；处于正常状态的储蓄账户可以进行存款、取款交易；处于正常状态的储蓄账户经销户交易后变成销户状态。练习任务5 构建数据字典 我们无论是在数据流图中还是在E-R图中都使用到了数据。这些数据项是否也会存在着使用上的约束和要求呢？我们软件系统在使用的时候有什么需要注意的地方吗？这些信息如果搞不清
44、楚，恐怕会对使用我们系统的用户产生不好的影响。那么，是否也存在着某种方法来描述和整理这些信息呢？125数据词典 1.数据词典与数据流图配合，能清楚地表达数据处理的要求 2.词条描述对于在数据流图中每一个被命名的图形元素，均加以定义，其内容有:名字，别名或编号，分类，描述，定义，位置，其它等 数据流词条描述 数据流名：说明：简要介绍作用即它产生的原因和结果 数据流来源：来自何方 数据流去向：去向何处 数据流组成：数据结构 数据量流通量：数据量，流通量 数据元素词条描述 数据元素名：类型：数字(离散值，连续值)，文字(编码类型）长度：取值范围：相关的数据元素及数据结构：数据文件词条描述 数据文件名
45、：简述：存放的是什么数据 输入数据：输出数据：数据文件组成：数据结构 存储方式：顺序，直接，关键码 存取频率：加工逻辑词条描述 加工名：加工编号：反映该加工的层次 简要描述：加工逻辑及功能简述 输入数据流：输出数据流：加工逻辑：简述加工程序，加工顺序 源点及汇(终)点词条描述 名称：外部实体名 简要描述：什么外部实体 有关数据流：数目：数据结构的描述 符 号 含 义 举 例 被定义为 与 x=ab.,.或.|.或 x=a,b，x=a|b .或 m.n 重复 x=a，x=3a8 (.)可选 x=(a)“.”基本数据元素 x=“a”.连结符 x=1.9对存折格式的数据字典的定义格式为：对存折格式的
46、数据字典的定义格式为：存折存折=户名户名+所号所号+帐号帐号+开户日期开户日期+性质性质+印密印密+1+1存取行存取行5050户名户名=2=2字母字母2424所号所号=“001”“999”=“001”“999”注：储蓄所编码规定三位数字注：储蓄所编码规定三位数字帐号帐号=“00000001”“99999999”=“00000001”“99999999”注：帐号是由注：帐号是由8 8位数字组成位数字组成开户日期开户日期=年年+月月+日日性质性质=“1”“6”=“1”“6”注：注：“1”1”表示普通储户表示普通储户 “5”5”表示工资户等表示工资户等印密印密=“0”=“0”注：注：印密在存折上不显
47、示印密在存折上不显示存取行存取行=日期日期+（摘要）（摘要）+支出支出+存入存入+余额余额+操作操作+复核复核日期日期=年年+月月+日日年年=“00”“99”=“00”“99”月月=“01”“12”=“01”“12”日日=“01”“31”=“01”“31”摘要摘要=1=1字母字母4 4 注：表明是存注：表明是存？是取？还是换？是取？还是换？支出支出=“=“金额金额”注：金额规定不能超过注：金额规定不能超过9999999.999999999.99金额金额=“0000000.01”“9999999.99”=“0000000.01”“9999999.99”操作操作=“00001”“99999”=“0
48、0001”“99999”小结 了解 需求获取原则和方法需求文档包含的内容及注意事项 理解 结构化分析方法的步骤 掌握 需求分类及需求工程的主要活动需求分析的任务和原则运用结构化分析方法建立系统模型，包括实体-关系图（ERD）、数据流图（DFD）、状态迁移图，数据字典。软 件 工 程第四章 软件设计（1）任务1 构建软件体系结构 软件设计概述 体系结构风格 结构化设计方法134任务1 构建软件体系结构 在第三章中我们针对图书管理系统进行了功能模型的构建，理清了图书管理系统的业务规则和功能性需求，那么，我们是否已经准备好将功能转换成对应的代码了呢？我们知道，一个完整的应用程序，如果采用结构化语言进
49、行编写，其主要的组成构件是函数，现在的问题是我们是否可以借助于得到的功能模型为合理设定函数模块提供帮助。1351 软件设计概述 软件设计的目的 设计是一个建模活动，它使用分析阶段得出的信息（即需求模型）并把这些信息转换为叫做解决方案的模型。所以设计阶段的目标是定义、组织和构造将作为结构蓝图的最终解决方案系统的各个组成部分。136 抽象 逐步求精 模块化 信息隐藏 控制层次 软件的体系结构软件设计的原理抽象“抽象”的心理学观念使人能够集中于某个一般性级别上的问题，而不去考虑无关的底层细节，这种解决问题的方式也应用于软件领域。抽象的思维方式应用软件开发领域，软件过程中的每一个步骤都是软件解决方案抽
50、象级别上的求精。抽象的类型 过程抽象 是对特定和有限的功能命名的序列。例如：查询子系统，实现查询功能；进一步抽象层次降低，查询子系统分为：按书名查询，按作者查询，按出版社查询等；按书名查询过程步骤，输入关键字，进行查询，显示结果。数据抽象 是数据命名的集合。例如：查询“书”，进一步详细定义其属性：书名、作者、出版社、出版日期、ISBN等；书名，进一步定义为长度50个字符的字符串。控制抽象 是程序控制机制内部细节的设计。例如：在操作系统中用以协调某些活动的同步信号。逐步求精 逐步求精是由Niklaus Wirth最初提出的一种自顶向下设计策略，系统是通过过程细节的连续的精化层次开发的，层次结构通
