软件工程初体验

目录

一：软件危机来了

二：这个软件可行吗？

三：描述软件需求

四：高内聚与低耦合

五：用例图

六：单元测试

---

一：软件危机来了

1：软件维护困难

2：软件工期拖延、成本超支

3：软件的质量难以保证

二：这个软件可行吗？

可行性研究的基本概念

软件项目的可行性研究是项目前期工作中最重要的内容，它是在项目投资决策前对软件工程研发进行全面的技术经济分析论证的科学方法和工作阶段。

可行性研究的基本内容

1.技术可行性分析：主要考虑项目使用技术的成熟度，技术选择的制约条件等能否满足当前项目开发的技术要求。

2.经济可行性分析：主要是把系统开发和运行的所需要的成本与得到的效益进行比较，进行成本/效益分析。

3.社会因素可行性分析：主要研究法律等制约项目研发的条件。

4.风险分析：主要考虑平台项目在实施过程中可能需要的各种风险因素，以及每种因素可能出现的概率和出险后造成的影响程度。

三：描述软件需求

具体来说，可以将系统的需求分为功能需求和非功能需求两大类，具体可以分为如下8种类型：

功能需求：这方面的需求指定系统必须提供的服务。通过需求分析应该划分出系统必须完成的所有功能。例如：如果旅客预定机票过程中没有指定座位偏好，机票预订系统就应当随机为它分配。

非功能需求：非功能需求描述了系统必须展现的属性或特性和必须要遵守的约束，包括系统在性能、可靠性和可用性、接口、约束等方面的特征。

1. 性能需求：性能需求指定系统必须满足的定时约束或容量约束，通常包括速度(响应时间)、信息量速率、主存容量、磁盘容量、安全性等方面的需求。例如：机票预定系统所支持的用户在线人数至少为50000。
2. 可靠性和可行性需求：可靠性需求定量地指定系统的可靠性。可用性与可靠性密切相关，它量化了用户可以使用系统的程度。例如：机票预定系统在一个月内发生故障的次数低于三次，体现了系统的可靠性需求。在任何时刻系统中的服务器或备份服务器至少有一个是可用的，体现了系统的可用性需求。
3. 出错性需求：这类需求说明系统对环境错误应该怎样响应。例如，如果它接收到从另一个系统发来的违反协议格式的消息，应该做什么?注意，上述这类错误并不是由该应用系统本身造成的。例如：系统中若某个节点因负载过高停止运行时需要有一定的错误处理机制如启动备份节点来保证系统的正常运行。
4. 接口需求：接口需求描述应用系统与它的环境通信的格式。常见的接口需求有：用户接口需求；硬件接口需求；软件接口需求；通信接口需求。例如，系统应该提供第三方登录接口，客户端必须通过post请求的方式来向服务端系统请求数据。
5. 约束：设计约束或实现约束描述在设计或实现应用系统时应遵守的限制条件。例如，系统应该满足跨平台的特性，应用所使用的所有文本数据将以XML格式的文件进行存储等。
6. 逆向需求：逆向需求说明软件系统不应该做什么。理论上有无限多个逆向需求，我们应该仅选取能澄清真实需求且可消除可能发生的误解的那些逆向需求。例如：一个用户账号不允许多个设备同时登录。
7. 将来可能提出的需求：应该明确地列出那些虽然不属于当前系统开发范畴，但是据分析将来很可能会提出来的要求。这样做的目的是，在设计过程中对系统将来可能的扩充和修改预做准备，以便一旦确实需要时能比较容易地进行这种扩充和修改。例如：系统要尽可能地考虑向后兼容性，为下代版本更新留出预留空间。

四：高内聚与低耦合

耦合定义：不同模块之间相互依赖程度的度量

1：内容耦合：内容耦合指一个模块直接修改或操作另一个模块的数据，或者一个模块直接转到另一个模块的内部，或者一个模块有多个入口。

 上述代码中，订单模块调用了商品模块并且修改了商品的单价，这是不允许的。应该将单价变量的修饰符修改为private。

2：控制耦合：控制耦合指一个模块向另一模块传递一个控制信号，接收信号的模块将依据该信号值进行必要的活动。这种耦合的实质是在单一接口上选择多功能模块中的某项功能。因此，对所控制模块的任何修改，都会影响控制模块。（模块之间传递的不是数据信息，而是控制信息例如标志、开关量等，一个模块控制了另一个模块的功能。）例如：网上商城系统中用户会分为普通用户和会员用户。模块A获取用户类型（普通用户、会员用户）传递给模块B，模块B根据不同类型的用户提供不同的服务。

3：数据耦合：模块间通过参数(不是控制参数、公共数据结构或外部变量)来传递基本类型的数据，称为数据耦合。由于限制了只通过参数表传递数据，按数据耦合开发的程序界面简单、安全可靠。因此，数据耦合是松散的耦合，模块之间的独立性比较强。在软件程序结构中至少必须有这类耦合。

内聚定义：一个模块之内各成分之间相互依赖程度的度量

1：顺序内聚：若一个模块中的各个部分都与同一个功能密切相关，并且必须按照先后顺序执行（通常前一个部分的输出数据就是后一个部分的输入数据），则称该模块的内聚为顺序内聚。

2：功能内聚：功能内聚指模块各个成分结合在一起，完成一个特定的功能。功能性模块具有内聚性最强、与其他模块联系少的特点。

五：用例图

用例图的基本概念

人们习惯使用一种交互的方式来描述系统的场景，借以“捕获”用户的需求，这就是用例的概念。通过用例的交互场景就可以更明确地捕获到用户的需求，再借助 UML 中的用例图，可以对这种活动进行文档化。用例图是从软件需求分析到最终实现的第一步，他显示了系统的用户提供的功能以及用户希望提供的功能，有利于用户和软件开发人员之间的沟通。

用例图的组成

参与者：参与者是指存在于系统外部并直接与系统交互的人、系统、子系统或类的外部实体的抽象。

用例：位于系统内部，用例是系统提供给参与者的功能。

 六：单元测试

单元测试的定义

单元测试（Unit testing）是对最小的软件设计单元（模块或源程序单元）的验证工作。

单元测试的目的

保证每个模块作为一个单元能正确运行。

单元测试的重点

1.模块接口

首先应该对通过模块接口的数据流进行测试，如果数据不能正确地进出，所有其他测试都是不切实际的。在对模块接口进行测试时主要检查下述几个方面：参数的数目、次序、属性或单位系统与变元是否一致；是否修改了只作输入用的变元；全局变量的定义和用法在各个模块中是否一致。

2.局部数据结构

对于模块来说，局部数据结构是常见的错误来源。应该仔细设计测试方案，以便发现局部数据说明、初始化、默认值等方面的错误。

3.重要的执行通路

由于通常不可能进行穷尽测试，因此，在单元测试期间选择最有代表性、最可能发现错误的执行通路进行测试就是十分关键的。应该设计测试方案用来发现由于错误的计算、不正确的比较或不适当的控制流而造成的错误。

4.出错处理通路

好的设计应该能预见出现错误的条件，并且设置适当的处理错误的通路，以便在真的出现错误时执行相应的出错处理通路或干净地结束处理。不仅应该在程序中包含出错处理通路，而且应该认真测试这种通路。当评价出错处理通路时，应该着重测试下述一些可能发生的错误：
(1) 对错误的描述是难以理解的；
(2) 记下的错误与实际遇到的错误不同；
(3) 在对错误进行处理之前，错误条件已经引起系统干预；
(4) 对错误的处理不正确；
(5) 描述错误的信息不足以帮助确定造成错误的位置。

5. 边界条件

边界测试是单元测试中最后的也可能是最重要的任务。
软件常常在它的边界上失效。
例如，处理n元数组的第n个元素时，或做到i次循环中的第i次重复时，往往会发生错误。使用刚好小于、刚好等于和刚好大于最大值或最小值的数据结构、控制量和数据值的测试方案，非常可能发现软件中的错误。

单元测试的不足

单元测试不能捕获程序中的每一个错误。根据定义，单元测试只测试单元自身的功能。因此它不捕获集成错误、性能问题或其它任何系统范围的问题。