软考高项-第五章 信息系统工程考点集锦

5.1软件工程

5.1.1架构设计

考点1.软件架构设计的一个核心问题是能否达到架构级的软件复用。

考点2.软件架构分为:

名称	说明
数据流风格	包括批处理序列和管道/过滤器两种风格
调用/返回风格	包括主程序/子程序、数据抽象和面向对象，以及层次结构
独立构件风格	包括进程通信和事件驱动的系统
虚拟机风格	包括解释器和基于规则的系统
仓库风格	包括数据库系统、黑板系统和超文本系统

考点3.在架构评估过程中，评估人员所关注的是系统的质量属性。

考点4.从目前已有的软件架构评估技术来看，可以归纳为三类主要的评估方式，分别是基于调查问卷（或检查表）的方式、基于场景的方式和基于度量的方式。这三种评估方式中，基于场景的评估方式最为常用。

5.1.2需求分析

考点5.需求是多层次的，包括业务需求、用户需求和系统需求。

（1）业务需求。是指反映企业或客户对系统高层次的目标要求，通常来自项目投资人、购买产品的客户、客户单位的管理人员、市场营销部门或产品策划部门等。

（2）用户需求。用户需求描述的是用户的具体目标，或用户要求系统必须能完成的任务。也就是说，用户需求描述了用户能使用系统来做些什么。

（3）系统需求。系统需求是从系统的角度来说明软件的需求。

考点6.质量功能部署（QFD）是一种将用户要求转化成软件需求的技术，其目的是最大限度地提升软件工程过程中用户的满意度。QFD将软件需求分为三类，分别是常规需求、期望需求和意外需求。

（1）常规需求。用户认为系统应该做到的功能或性能，实现越多用户会越满意。

（2）期望需求。用户想当然认为系统应具备的功能或性能。如果期望需求没有得到实现，会让用户感到不满意。

（3）意外需求。意外需求也称为兴奋需求，是用户要求范围外的功能或性能（但通常是软件开发人员很乐意赋予系统的技术特性），实现这些需求用户会更高兴，但不实现也不影响其购买的决策。

考点7.需求过程：主要包括需求获取、需求分析、需求规格说明书编制、需求验证与确认等。

（1）需求获取:需求获取只有与用户的有效合作才能成功。常见的需求获取方法包括用户访谈、问卷调查、采样、情节串联板、联合需求计划等。

（2）需求分析：需求分析对已经获取到的需求进行提炼、分析和审查，以确保所有的项目干系人都明白其含义并找出其中的错误、遗漏或其他不足的地方。

使用结构化分析（SA）方法进行需求分析，其建立的模型的核心是数据字典。围绕这个核心，有三个层次的模型，分别是数据模型、功能模型和行为模型（也称为状态模型）。一般使用实体关系图（E-R图）表示数据模型，用数据流图（DFD）表示功能模型，用状态转换图（STD）表示行为模型。E-R图主要描述实体、属性，以及实体之间的关系；DFD从数据传递和加工的角度，利用图形符号通过逐层细分描述系统内各个部件的功能和数据在它们之间传递的情况，来说明系统所完成的功能；STD通过描述系统的状态和引起系统状态转换的事件，来表示系统的行为，指出作为特定事件的结果将执行哪些动作（例如，处理数据等）。

（3）需求规格说明书编制：软件需求规格说明书（SRS）是需求开发活动的产物，编制该文档的目的是使项目干系人与开发团队对系统的初始规定有一个共同的理解，使之成为整个开发工作的基础。

（4）需求验证与确认：一般通过需求评审和需求测试工作来对需求进行验证。需求评审就是对SRS进行技术评审，SRS的评审可以发现那些二义性的或不确定性的需求，为项目干系人提供在需求问题上达成共识的方法。

考点8.统一建模语言（UML）是一种定义良好、易于表达、功能强大且普遍适用的建模语言。从总体上来看，UML的结构包括构造块、规则和公共机制三个部分。

考点9.UML中的事物也称为建模元素，包括结构事物、行为事物（也称动作事物）、分组事物和注释事物（也注解事物）。这些事物是UML模型中最基本的OO构造块。

考点10.UML中的关系，主要有四种关系，分别为