《软件工程考点》由会员分享，可在线阅读，更多相关《软件工程考点（9页珍藏版）》请在金锄头文库上搜索。
1、软件是程序和所使程序正确运行所需的相关文档和配置信息。 软件有可能是针对某一特定用户开发的，也有可能是面向一般市场开发的。软件系统包括：独立程序、配置文件（设置程序）、系统文档（描述系统结构）、用户文档 （如何使用系统）、Web站点（告知用户下载最新产品信息）【分类】通用软件产品：为一系列不同用户开发的，在市场上公开销售的如PC软件Excel或者Word。 定制软件产品（客户软件产品）：受特定的客户委托，由软件承包商专门为这类客户开发。 新软件可以通过开发新的项目程序、配置通用软件系统或重用现有的软件来创建。 软件工程是一门工程学科，涉及软件生产的各个方面。软件工程师既能恰当地应用理论、方法和
2、工具，又能有选择地利用它们，即使在没有可用的 理论和方法的情况下，也力求找出解决问题的方法。计算机科学研究的是构成计算机和软件系统基础的有关理论和方法，而软件工程则是研究软 件制作中的实际问题。计算机科学仍不能作为软件工程的坚实的基础。系统工程研究由软件起主导作用、有关复杂系统的开发和进化的各个方面，包括软硬件开发， 过程设计等。软件工程是系统工程中的关于开发软件基础设施，控制，应用和系统数据库 的部分。系统工程师参与了系统描述，体系设计，集成和部署。软件过程是指制作软件产品的一组活动及其结果。 软件过程的基本活动有：软件描述-客户和工程师定义所要生产的软件以及对其操作的一些约束软件开发-软件
3、得以设计和编程实现软件有效性验证-软件经过检查以保证它就是客户所需要的软件进化-软件随不同的客户和变化的市场需求而修改。 软件过程模型：是从一特定角度提出的软件过程的简化描述。 几种软件过程模型：工作流模型（描述软件过程中各种活动的序列及其输入输出和相互依赖型）数据流或活动模型（把软件过程描述成一组活动，每个活动都完成一定的数据转换）、 角色励作模型（谁描述了参与软件过程的人员的不同角色和各自负责的活动） 软件开发模型：瀑布模型（包含软件过程各个活动并将其描述成独立的过程阶段）进化式开发（软件描述、开发和有效性验证活动交替进行的开发方法） 基于组件的软件工程（假定系统的各个组件已经存在，并把组
4、件集成到新 系统中，而非从头开始）瀑布模型过程：需求分析和定义；系统和软件设计；实现和单元测试；集成和系统测试；运行和维护 瀑布模型主要缺点是难以适应过程中进行的变化。上一个阶段完成，下一个阶段才能启动。适用性：将项目分成不同阶段，使人们难以应付不断变化的客户需求；因此，当需 求十分明确，且在软件开发中只做有限修改时才适合使用该模型；然而很少有业务系统有稳 定的需求；所以瀑布模型主要是用于大型系统工程项目，且软件项目是大型工程项目的一部 分时尤为适用。进化式开发包括：探索式开发：其目标是与客户一起工作，共同探索系统需求，直到最后交付系统，这类 开发是从需求较清楚的一部分开始，根据用户的建议逐渐
5、向系统中添加功能。抛弃式原型：目标是理解用户需求，然后再给出系统的一个较好的需求定义。 存在问题：过程不可见；系统结构通常较差；需要专业技能（如快速原型语言等）。 适用性：小型或中型的交互系统；大型系统的某部分（如用户接口）；生命周期短的系统基于组件的软件工程基于可复用的系统，这些系统是现成的组件或者是商业现成产品系统COTS 过程：组件分析（给出需求描述，然后搜寻能满足需求的组件）需求修改（根据得到的组件信息来分析需求，然后修改需求以反映可得到的组件）使用复用的系统设计（开发设计系统框架或重复使用一个已存在的框架）开发和集成（组件不能买到时需自己开发，再集成自己开发的或现成的组件形成整体）
6、基于组件的软工特点：减少了需要开发的软件数量，降低了风险和成本，使软件可以快速交 付。然而需求妥协不可避免，可能导致系统不符合用户真正需求；对系统进化的控制也不起 作用。随着组件标准的出台，这种方法得到越来越广泛的使用。需求被视为对系统应提供的服务或对系统的约束的一个高层抽象描述，被定义为对系统功能 的详细的、用数学方法的形式化描述。需求可以作为一个合同竞标的基础，也可以作为合同自身的基础，这两种文件描述都被称为 需求文档。需求类型：用户需求：是用自然语言加图表的形式，给出的关于系统需要提供哪些服务以及 系统操作受到哪些约束的声明。系统需求：详细精确地给出系统的服务和约束。系统需求文档也称为功
7、能描述。 软件系统分为功能需求、非功能需求和领域需求。功能需求对系统应提供的服务、如何对输入做出反应及系统在特定条件下的行为的描述。 非功能需求对系统提供的服务或功能给出的约束。时间约束、开发过程的约束、标准等。 领域需求来自系统的应用领域的需求，反应该领域的特点。【功能需求】描述系统所预期提供的功能或服务，取决于开发的软件类型、软件未来的用户 以及开发的系统类型。软件需求分析的三个层次是：业务需求反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范 围文档中予以说明。用户需求文档描述了用户使用产品必须要完成的任务。功能需求定义了开发人员必须实现的软件功能，使得用户能完成他们的
8、任务，从而满足 了业务需求。图书馆系统图书借阅管理子系统中，业务需求：完成校园图书的借阅，为大学的学生和 教职员工提供图书借阅的服务。用户需求有三类用户：读者（本科学生、硕士生、老师）：查询图书信息、进行借阅。图书管理员：读者信息的管理、图书信息的管理、借阅活动的操作。 系统管理员：图书管理员信息的管理、数据库的维护、日志维护和系统安全维护。 系统功能需求具有全面（用户所需的所有服务都应该给出描述）、一致性（在对系统功能需 求进行描述时，不能前后矛盾）。【非功能需求】定义了系统的属性和约束，指那些不直接与系统具体功能相关的一类需求。 与系统总体特性相关（如可靠性、反应时间和存储空间），定义了系
9、统的约束（如I/O设备 的能力、系统界面中数据的表示）。非功能需求不只与软件系统本身有关，还与系统开发过 程有关。非功能需求分类：产品需求（叙述产品行为的需求，包括系统运行速度和内存消耗等性能需求）机构需求（过程标准、实现要求、交付需求）外部需求（所有系统外部因素和开发过程）领域需求一般包括专用性很强的领域术语或是涉及领域概念。是一个新的特有的功能需求、 对已存在功能需求的约束或是需要实现的一个特别计算。领域需求问题：不易理解性、含蓄性【用户需求】是从用户角度来描述系统功能和非功能需求，以便让用户能看懂。用自然语言、 图表和直观的图形来定义，以便让用户理解。【系统需求】比用户需求相比，系统需求
10、是对系统功能、服务和约束更详细的描述。它们被 用来作为系统设计的技术，可以作为有关系统实现合同的一部分。几种需求表达形式的比较：用自然语言描述（二义性、随意性太大、缺乏模块化）结构化语言描述（所有的需求都要以一种标准的方式进行书写，对使用的词汇进行了限制） 标准格式的描述（实体或功能、输入及来源、输出及输出趋向、其他被引用的实体等的描述） 表格描述（用来补充自然语言，在有多个可能情形时尤其有用）计算的表格描述图形模型（当需知状态是如何改变或需要描述一个动作序列时，图形模型是最为有用的工具） 序列图（显示了在与一个系统进行用户交互的过程中，事件所发生的顺序。自上而下地读一 个序列图，可以从中看出
11、动作所发生的顺序）ATM机中提取现金的序列：验卡；处理请求；完成交易。体系结构设计的产品是一个体系结构设计文档内容包括：静态结构模型：给出子系统或组件，将其作为一个个独立的单元来开发动态过程模型：给出系统在运行时的过程组成。它可能不同于静态模型接口模型：定义每个子系统从它们的公共接口能得到的服务关系模型：给出如子系统间的数据流这样的模型分布模型：给出子系统在多台计算机上是如何分布的体系结构设计的步骤：1.系统概述入AA2.设计约束AAA3.设计策略AAA4.系统总体结 构入入5.子系统N的结构与功能AA6.开发环境的配置AAA7.运行环境的配置AA8.测试 环境的配置AA9.其他系统组成反映的
12、是系统组织所采用的基本策略。时间上分为概要和详细。系统组成类型三个：共享数据容器类型（全部共享数据放在一个中央数据库中，所有子系统都能从中存取数据, 每个子系统与其他子系统间数据交互通过消息传递来实现）优点：它是共享大量数据的一个高效方法;子系统不必关心数据是如何集中进行的这些活动， 如、例如备份、信息安全性等；共享模型能通过容器模式而看得见。缺点：子系统一定要与容器数据模型一致，不可避免地，每个专用的工具之间要做出妥协； 数据进化变得很困难和昂贵；容器模型迫使所有的子系统使用相同的策略；很难将容器有效 的分配到多台机器上。共享服务和服务器类型（一组给其他子系统提供服务的单击服务器；一组向服务
13、器请求服 务的客户机；一个连接客户机和服务器的网络）优点：数据的分布式最直接的；可以更有效地使用网络系统，从而降低了对硬件的要求；很 容易就添加一台新的服务器或更新现有的服务器。缺点：没有共享数据模型，子系统以不同的方式组织它们的数据。数据交换效率就可能很低; 每个服务器上出现冗余数据管理；没有中央寄存器的名字和服务，这可能很难找出哪个服务 器和哪些服务可用。抽象机或分层类型（把系统组织成一系列层次，每一层提供一组服务，）分层的方法支持系统的增量式开发。当一层的接口改变的时候，只有毗邻的层受影响。 然而，用这种方法构成系统可能是困难的。快速软件开发特性：1.描述、设计和实现过程是并发的。没有详
14、细的系统描述，设计文档得到了最少化。 2系统通过一系列增量开发出来。最终用户和其他系统信息持有者都参与了每个增量 的定义和评估。3系统用户界面通常是采用交互开发系统开发的增量式开发的优点：客户服务的加速移交：系统的每个增量可以移交高优先级的功能给用户。客户的参与：系统用户必须参与到增量开发过程中来，他们的参与不仅仅意味着系统更容 易达到他们的需求，它是也意味着系统的最终用户对系统承担了义务。增量式开发的缺点：管理问题：很难评价系统的进程，很难发现问题，因为增量式开发无法有效地产生大量的 系统文档。合同问题：一般的合同可能包括一个系统描述；没有系统描述，人们就不得不用不同形式 的合同。有效性证明
15、问题：没有一个描述，系统正在被证明的是什么呢？维护问题：连续的变更将使得任何软件系统的结构变坏，导致软件改变的代价更高，从而 也演变成新的需求。增量式开发的目标是向最终用户移交一个可用的系统。原型构造开始于用户需求，这些需求 被理解得最好。抛弃式原型构造的目标是验证或者导出系统需求。原型构造开始于那些不好理解的需求。 敏捷方法特点：关注代码而不是设计；以软件开发的迭代方法为基础；迅速完成和移交可用软件给用户，客 户提出新的变化了的需求，有软件开发人员在下一个循环中实现。敏捷方法很可能最适合于开发小型或中等规模的业务系统和个人计算机产品。敏捷（极限）方法的问题：很难将兴趣保持在参与到开发的客户身上。团队成员个人可能从性格上不太适应激烈的投入，这是敏捷方法的典型特征。对变更做出优先级排序可能是极困难的，尤其是对那些有很多参与者的系统。维护简洁性需要额外的工作。随着其他迭代方法的发展，合同可能也是极限方法的一个问题。极限编程可能是最为人所熟知也是流行最广的一种敏捷方法。极限编程采用“极限”方法到迭代开发中。新的软件版本每天之中构造好几次；移交给用户的增量大约是每两周一次；所有测试必须执行于每次构造中，且只当所有测试成功执行后软件的新版本才是可接受的。XP （极限编程）和敏捷方法的原则：增量式开发是通过系统的小的频繁开发的版本来支持的；客户的参与是通过全时雇佣到开发团队的方式；人（
