《软件工程导论(第6版)》笔记

最新推荐文章于 2024-09-28 15:18:19 发布

猴勒

最新推荐文章于 2024-09-28 15:18:19 发布

阅读量707

点赞数 13

分类专栏：本科课程文章标签：软件工程需求分析设计规范软件维护笔记

本文链接：https://blog.csdn.net/holeer/article/details/142603727

版权

本科课程同时被 2 个专栏收录

13 篇文章 5 订阅

订阅专栏

读书笔记

7 篇文章 0 订阅

订阅专栏

说明：《软件工程导论(第6版)》是浙江科技大学软件工程本科专业课程《软件工程概论》使用的教材。

第2章可行性研究

2.5 数据字典

数据字典是关于数据的信息的集合，也就是对数据流图中包含的所有元素的定义的集合。
任何字典最主要的用途都是供人查阅对不了解的条目的解释，数据字典的作用也正是在软件分析和设计的过程中给人提供关于数据的描述信息。
数据流图和数据字典共同构成系统的逻辑模型。

2.5.1 数据字典的内容

典型的情况是，在数据字典中记录数据元素的下列信息：一般信息（名字，别名，描述等），定义（数据类型，长度，结构等）……

2.5.2 定义数据的方法

数据字典中的定义就是对数据自顶向下的分解。当分解到不需要进一步定义，每个和工程有关的人也都清楚其含义的元素时，这种分解过程就完成了。

由数据元素组成数据的方式只有四种基本类型：顺序、选择、重复、可选。

虽然可以使用自然语言描述由数据元素组成数据的关系，但是为了更加清晰简洁，建议采用下列符号：
=意思是等价于（或定义为）；
+意思是和（即，连接两个分量）
[ ]意思是或，通常用|隔开供选择的分量；
{ }意思是重复，通常用下限和上限进一步注释；
( )意思是可选。

第3章需求分析

3.1 需求分析的任务

3.1.1 确定对系统的综合要求

虽然功能需求是对软件系统的一项基本需求，但却并不是唯一的需求。通常对软件系统有下述几方面的综合要求。

功能需求：这方面的需求指定系统必须提供的服务。
性能需求：性能需求指定系统必须满足的定时约束或容量约束，通常包括速度（响应时间）、信息量速率、主存容量、磁盘容量、安全性等方面的需求。
可靠性和可用性需求：可靠性需求定量地指定系统的可靠性。可用性与可靠性密切相关，它量化了用户可以使用系统的程度。
出错处理需求：这类需求说明系统对环境错误应该怎样响应。
接口需求
约束：设计约束或实现约束描述在设计或实现应用系统时应遵守的限制条件。提出这类需求，只是说明用户或环境强加给项目的限制条件。常见的约束有：精度；工具和语言约束；设计约束；应该使用的标准；应该使用的硬件平台。
逆向需求：逆向需求说明软件系统不应该做什么。
将来可能提出的要求：应该明确地列出那些虽然不属于当前系统开发范畴，但是据分析将来很可能会提出来的要求。这样做的目的是，在设计过程中对系统将来可能的扩充和修改预做准备，以便一旦确实需要时能比较容易地进行这种扩充和修改。

3.6 状态转换图

状态转换图通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为。

3.6.1 状态

状态是任何可以被观察到的系统行为模式。

在状态图中定义的状态主要有：初态（即初始状态）、终态（即最终状态）和中间状态。在一张状态图中只能有一个初态，而终态则可以有0至多个。

状态图既可以表示系统循环运行过程，也可以表示系统单程生命期。当描绘循环运行过程时，通常并不关心循环是怎样启动的。当描绘单程生命期时，需要标明初始状态和最终状态。

3.6.2 事件

事件是在某个特定时刻发生的事情，它是对引起系统做动作或（和）从一个状态转换到另一个状态的外界事件的抽象。例如，内部时钟表明某个规定的时间段已经过去，用户移动或单击鼠标等都是事件。简而言之，事件就是引起系统做动作或（和）转换状态的控制信息。

3.6.3 符号

在状态图中，初态用实心圆表示，终态用一对同心圆（内圆为实心圆）表示。
中间状态用圆角矩形表示。

状态图中两个状态之间带箭头的连线称为状态转换，箭头指明了转换方向。状态变迁通常是由事件触发的，在这种情况下应在表示状态转换的箭头线上标出触发转换的事件表达式；如果在箭头线上未标明事件，则表示在源状态的内部活动执行完之后自动触发转换。

事件表达式的语法如下：事件说明[守卫条件]/动作表达式
其中，事件说明的语法为：事件名（参数表）。
守卫条件是一个布尔表达式。
动作表达式是一个过程表达式，当状态转换开始时执行该表达式。

3.7 其他图形工具

3.7.1 层次方框图

层次方框图用树形结构的一系列多层次的矩形框描绘数据的层次结构。树形结构的顶层是一个单独的矩形框，它代表完整的数据结构，下面的各层矩形框代表这个数据的子集，最底层的各个框代表组成这个数据的实际数据元素（不能再分割的元素）。

第5章总体设计

5.4 描绘软件结构的图形工具

5.4.1 层次图和HIPO图

层次图用来描绘软件的层次结构。虽然层次图的形式和第3.7节中介绍的描绘数据结构的层次方框图相同，但是表现的内容却完全不同。层次图中的一个矩形框代表一个模块，方框间的连线表示调用关系而不像层次方框图那样表示组成关系。

层次图很适于在自顶向下设计软件的过程中使用。

5.2.5 模块独立

耦合

耦合是对一个软件结构内不同模块之间互连程度的度量。耦合强弱取决于模块间接口的复杂程度，进入或访问一个模块的点，以及通过接口的数据。

如果两个模块中的每一个都能独立地工作而不需要另一个模块的存在，那么它们彼此完全独立，这意味着模块间无任何连接，耦合程度最低。但是，在一个软件系统中不可能所有模块之间都没有任何连接。

如果两个模块彼此间通过参数交换信息，而且交换的信息仅仅是数据，那么这种耦合称为数据耦合。如果传递的信息中有控制信息（尽管有时这种控制信息以数据的形式出现），则这种耦合称为控制耦合。

数据耦合是低耦合。 系统中至少必须存在这种耦合，因为只有当某些模块的输出数据作为另一些模块的输入数据时，系统才能完成有价值的功能。一般说来，一个系统内可以只包含数据耦合。控制耦合是中等程度的耦合，它增加了系统的复杂程度。控制耦合往往是多余的，在把模块适当分解之后通常可以用数据耦合代替它。

如果被调用的模块需要使用作为参数传递进来的数据结构中的所有元素，那么，把整个数据结构作为参数传递就是完全正确的。但是，当把整个数据结构作为参数传递而被调用的模块只需要使用其中一部分数据元素时，就出现了特征耦合。在这种情况下，被调用的模块可以使用的数据多于它确实需要的数据，这将导致对数据的访问失去控制，从而给计算机犯罪提供了机会。

当两个或多个模块通过一个公共数据环境相互作用时，它们之间的耦合称为公共环境耦合。公共环境可以是全程变量、共享的通信区、内存的公共覆盖区，任何存储介质上的文件、物理设备等。

公共环境耦合的复杂程度随耦合的模块个数而变化，当耦合的模块个数增加时复杂程度显著增加。如果只有两个模块有公共环境，那么这种耦合有下面两种可能。（1）一个模块往公共环境送数据，另一个模块从公共环境取数据。这是数据耦合的一种形式，是比较松散的耦合。（2）两个模块都既往公共环境送数据又从里面取数据，这种耦合比较紧密，介于数据耦合和控制耦合之间。

如果两个模块共享的数据很多，都通过参数传递可能很不方便，这时可以利用公共环境耦合。

最高程度的耦合是内容耦合。 如果出现下列情况之一，两个模块间就发生了内容耦合：一个模块访问另一个模块的内部数据；一个模块不通过正常人口而转到另一个模块的内部；两个模块有一部分程序代码重叠（只可能出现在汇编程序中）；一个模块有多个入口（这意味着一个模块有几种功能）。应该坚决避免使用内容耦合。

第8章软件维护

8.2 软件维护的特点

8.2.1 结构化维护与非结构化维护差别巨大

结构化维护
如果有一个完整的软件配置存在，那么维护工作从评价设计文档开始，确定软件重要的结构特点、性能特点以及接口特点；估量要求的改动将带来的影响，并且计划实施途径。然后首先修改设计并且对所做的修改进行仔细复查。接下来编写相应的源程序代码；使用在测试说明书中包含的信息进行回归测试；最后，把修改后的软件再次交付使用。