北京哪家医院白癜风最好 https://myyk.familydoctor.com.cn/2831/

软件工程学概论

.软件危机

软件成本日益增长，开发进度难以控制，软件质量差，软件维护困难。

软件危机的原因

技术原因：软件规模越来越大；软件复杂度越来越高

管理原因：软件开发缺乏正确的理论指导，过分依靠个人技巧和创造性：对用户需求没有完整准确的认识，就匆忙着手编写程序

消除软件危机的途径

技术和方法，软件工具，组织管理

软件工程基本原理

用分阶段的生命周期计划严格管理

坚持进行阶段评审

实行严格的产品控制

采用现代程序设计技术

结果应能清楚地审查

开发小组的人员应该少而精

承认不断改进软件工程实践的必要性

.2软件开发

软件的生命周期

软件定义软件开发软件维护

问题定义可行性研究需求分析概要设计详细设计编码和单元测试综合测试软件维护

然而软件的需求是模糊的，变化的，结构化模型滞后反应

软件开发过程

瀑布模型：“文档驱动”，静态

快速原型：快速简历核心功能、螺旋模型：阶段风险评估

喷泉模型：迭代

软件开发新过程

敏捷软件开发(极限编程—XP)：快速适应需求变化，灵活的人员组织，面向业务持续改进

个体和交互胜过过程和工具

可以工作的软件胜过面面俱到的文档

客户合作胜过合同谈判

响应变化胜过遵循计划

统一软件开发过程

软件开发方法

结构化方法

面向对象方法

Jackson系统开发方法

模块化方法

软件复用

可行性分析

2.可行性研究

确定问题是否值得去解决

分析可能的解法，判定系统规模和目标是否能够实现，效益是否可观

技术可行性，经济~，操作~，法律~

2.2可行性研究过程

复查系统规模和目标

研究目前正在使用的系统

完成现有系统的基本功能分析

解决现有系统的问题

绘制高层系统数据流图

掌握与其他系统的接口

导出新系统的高层逻辑模型

以数据流图和数据字典为基础进一步复查

导出方案

技术可行性，排除不现实的系统

操作可行性，排除用户不能接受的方案

经济可行性，排除利润低的方案

制定进度表

2.3系统流程图

系统流程图描绘组成系统的主要物理元素以及信息在这些元素流动和处理的情况。

2.数据流图（DFD）

信息的流动：信息流不能为动词，实体到实体的信息流动，处理要有输入输出，处理名不能为名词

2.5数据字典

数据字典是关于数据的信息的集合，即对设计图中包含的元素的定义。

一般构成：

一般信息（名字、别名、描述等）

定义（数据类型、长度、结构等）

使用特点（值的范围、使用频率、使用方式等）

控制信息（来源、用户、使用程序、访问权等）

分组信息（父结构、从属结构、物理位置等）

开发数据库第一步就是定义数据字典。

需求分析

为了开发出真正满足用户需求的软件产品，首先必须知道用户的需求。获取（当前的情况和需要解决的问题），进行分析，编写规格说明，然后进行需求验证(一份付出，十份收获)，反复求精，多次细化。

多与用户进行沟通或者调查，获得尽可能明确的用户需求。

3.需求分析的任务

系统的数据要求

任何软件系统本质上都是信息处理系统

建立数据模型（E-R图）

数据字典

Warnier图

系统的逻辑模型

数据流图、E-R图、状态转换图、数据字典、算法描述

结构化分析实质是一种创建模型的活动。通过需求分析而建立的模型必须达到下述的三个基本目标。

描述用户的需求。

为软件设计工作奠定基础。

定义一组需求，一旦开发出软件产品之后，就可以用这组需求为标准来验收该产品。

3.2实体-联系（E-R）图

数据模型包含三种相互关联的信息：数据对象、描述数据对象属性及数据对象彼此间相互连接的关系。

软件：PowerDesigner

3.3规格说明方式

总体设计

概要设计的主要任务是分析软件规格说明，对软件进行功能分解，划分模块，设计出模块结构。

.设计原理

模块化

面向对象范型中的对象是模块，对象内的方法也是模块。模块是构成程序的基本构件。

每个模块完成一个子功能，把这些模块集成起来构成一个整体，可以完成指定的功能满足用户的需求。

模块化优点：结构清晰，容易阅读和理解，容易测试和调试，有助于提高软件的可靠性，可修改性，便于组织和管理。

抽象——求精

信息隐藏和局部化

一个模块内包含的信息(过程和数据)对于不需要这些信息的模块来说，是不能访问的。

模块独立：度量标准内聚和耦合

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

内聚：标志一个模块内各个元素彼此结合的紧密程度，它是信息隐蔽和局部化概念的自然扩展。应尽可能高内聚。

.2启发规则

改进软件结构提高模块独立性

模块规模应该适中

深度、宽度、扇出和扇入都应适当

模块的作用域应该在控制域之内

力争降低模块接口的复杂程度

设计单入口单出口的模块

模块功能应该可以预测

描述软件结构方法：层次图

.3面向数据流的设计方法

面向数据流的设计方法把信息流映射成软件结构，信息流的类型决定了映射的方法。

信息流：变换流，事务流

·（变换流和事务流）

面向数据流方法的设计过程：

应该在设计的早期阶段尽量对软件结构进行精化。可以导出不同的软件结构，然后对它们进行评价和比较，力求得到“最好”的结果。

.小结

软件工程方法学采用结构化设计技术完成设计工作。

软件设计在软件工程过程中处于技术核心地位，是软件开发过程中决定软件产品质量的关键阶段。

软件设计必须依据对软件产品的需求来进行，结构化设计把结构化分析的结果作为基本输入信息。

由数据模型、功能模型和行为模型描述的软件需求被传送给软件设计者，以便他们采用适当的设计方法完成数据设计、体系结构设计、接口设计和过程设计。

为了获得高质量的软件设计结果，应该遵循模块化、抽象、逐步求精、信息隐藏和模块独立等基本设计原理，特别是其中的模块独立原理，对软件体系结构设计和接口设计具有非常重要、十分具体的指导作用。

总结众多软件工程师在开发软件的长期实践中所积累的丰富经验，形成了一些启发规则，这些启发规则虽然不像上述基本原理那样普遍适用，但在许多场合仍然能给软件设计者以有益的启示，有助于设计出有效模块化的软件。

通常，使用层次图或结构图表示软件结构，这些图形工具具有形象直观、容易理解的优点，应该学会用这类图形描绘软件结构。

面向数据流的设计方法是设计软件体系结构的一种系统化的方法，它定义了一些映射规则，可以把数据流图变换成软件的初步结构。

得出软件的初步结构之后，必须根据好设计的标准，同基本设计原理和启发规则为指南，对所得到的软件结构进行仔细优化，才能设计出令人满意的软件体系结构。

详细设计

5.结构程序设计

如果一个程序的代码块仅仅通过顺序、选择和循环这三种控制结构进行连接，并且每个代码块只有一个入口和一个出口，则称这个程序是结构化的。

5.2人机界面设计

用户界面设计是一个迭代的过程，也就是说，通常先创建设计模型，再用原型实现这个设计模型，并由用户试用和评估，然后根据用户的意见进行修改。

5.2.一般交互

保持一致性。为人机界面中的菜单选择、命令输入、数据显示以及众多的其他功能，使用一致的格式。

提供有意义的反馈。向用户提供视觉的和听觉的反馈，以保证在用户和界面之间建立双向通信。

在执行有较大破坏性的动作之前要求用户确认。如果用户要删除一个文件，或覆盖一些重要信息，或请求终止一个程序运行，应该给出确认提示。

允许取消绝大多数操作。UNDO或REVERSE功能使众多终端用户避免了大量时间浪费。每个交互式应用系统都应该能方便地取消已完成的操作。

减少在两次操作之间必须记忆的信息量。不应该期望用户能记住一大串数字或名字，以便在下一步操作中使用它们。应该尽量减少记忆量。

提高对话、移动和思考的效率。应该尽量减少击键次数，设计屏幕布局时应该考虑尽量减少鼠标移动的距离，应该尽量避免出现用户问：“这是什么意思”的情况。

允许犯错误。系统应该保护自己不受致命错误的破坏。

按功能对动作分类，并据此设计屏幕布局。下拉菜单的一个主要优点就是能按动作类型组织命令。实际上，设计者应该尽力提高命令和动作组织的“内聚性”。

提供对工作内容敏感的帮助设施。

用简单动词或动词短语作为命令名。过长的命令名难于识别和记忆，也会占据过多的菜单空间。

5.2.2信息显示

只显示与当前工作内容有关的信息。用户在获得有关系统的特定功能的信息时，不必看到与之无关的数据、菜单和图形。

不要用数据淹没用户，应该用便于用户迅速地吸取信息的方式来表示数据。例如，可以用图形或图表来取代巨大的表格。

使用一致的标记、标准的缩写和可预知的颜色。显示的含义应该非常明确，用户不必参照其他信息源就能理解。

允许用户保持可视化的语境。如果对图形显示进行缩放，原始的图像应该一直显示着(以缩小的形式放在显示屏的一角)，以使用户知道当前观察的图像部分在原图中所处的相对位置。

产生有意义的出错信息。

使用大小写、缩进和文本分组以帮助理解。人机界面显示的信息大部分是文字，文字的布局和形式对用户从中吸取信息的难易程度有很大影响。

使用“模拟”可视化显示方式表示信息，以使信息更容易被用户吸取。

高效率地使用显示屏。当使用多窗口时，应该有足够的空间使得每个窗口至少都能显示出一部分。此外，屏幕大小应该选得和应用系统的类型相配套(这实际上是一个系统工程问题)。

5.2.3数据输入

尽量减少用户的输入动作。最重要的是减少击键次数，这可以用下列方法实现：用鼠标从预定义的一组输入中选一个；用“滑动标尺”在给定的值域中指定输入值；利用宏把一次击键转变成更复杂的输入数据集合。

保持信息显示和数据输入之间的一致性。显示的视觉特征(例如，文字大小、颜色和位置)应该与输入域一致。

允许用户自定义输入。专家级的用户可能希望定义自己专用的命令或略去某些类型的警告信息和动作确认，人机界面应该允许用户这样做。

交互应该是灵活的，并且可调整成用户最喜欢的输入方式。用户类型与喜欢的输入方式有关，秘书可能非常喜欢键盘输入，而经理可能更喜欢使用鼠标之类的点击设备。

使在当前动作语境中不适用的命令不起作用。这可使用户不去做那些肯定会导致错误的动作。

让用户控制交互流。用户应该能够跳过不必要的动作，改变所需做的动作的顺序(在应用环境允许的前提下)，以及在不退出程序的情况下从错误状态中恢复正常。

对所有输入动作都提供帮助。

消除冗余的输入。除非可能发生误解，否则不要要求用户指定工程输入的单位；不要要求用户在整钱数后面键入00；尽可能提供缺省值；绝对不要要求用户提供程序可以自动获得或计算出来的信息。

5.3过程设计的工具

程序流程图

盒图（N-S图）

PAD图

判定树

面向对象的分析设计实例：银行ATM业务分析设计

面向对象分析，就是抽取和整理用户需求并建立问题域精确模型的过程。在概念上面向对象分析大体上按照下列顺序进行：寻找类与对象，识别结构，识别主题，定义属性，建立动态模型，建立功能模型，定义服务。分析不可能严格地按照预定顺序进行，大型、复杂系统的模型需要反复构造多遍才能建成。通常，先构造出模型的子集，然后再逐渐扩充，直到完全、充分地理解了整个问题，才能最终把模型建立起来。

实例：银行ATM业务分析设计

需求陈述：

某银行拟开发一个自动取款机系统，它是一个由自动取款机、中央计算机、分行计算机及柜员终端组成的网络系统。

ATM和中央计算机由总行投资购买。总行拥有多台ATM，分别设在全市各主要街道上。分行负责提供分行计算机和柜员终端。柜员终端设在分行营业厅及分行下属的各个储蓄所内。该系统的软件开发成本由各个分行分摊。

银行柜员使用柜员终端处理储户提交的储蓄事务。储户可以用现金或支票向自己拥有的某个账户内存款或开新账户。储户也可以从自己的账户中取款。一个储户可能拥有多个账户。柜员负责把储户提交的存款或取款事务输进柜员终端，接收储户交来的现金或支票，或付给储户现金。

柜员终端与相应的分行计算机通信，分行计算机具体处理某个账户的事务并且维护账户。

拥有银行账户的储户有权申请领取现金兑换卡。使用现金兑换卡可以通过ATM访问自己的账户。目前仅限于用现金兑换卡在ATM上提取现金(即取款)，或查询有关自己账户的信息(例如，某个指定账户上的余额)。将来可能还要求使用ATM办理转账、存款等事务。

所谓现金兑换卡就是一张特制的磁卡，上面有分行代码和卡号。分行代码唯一标识总行下属的一个分行，卡号确定了这张卡可以访问哪些账户。通常，一张卡可以访问储户的若干个账户，但是不一定能访问这个储户的全部账户。每张现金兑换卡仅属于一个储户所有，但是，同一张卡可能有多个副本，因此，必须考虑同时在若干台ATM上使用同样的现金兑换卡的可能性。也就是说，系统应该能够处理并发的访问。

当用户把现金兑换卡插入ATM之后，ATM就与用户交互，以获取有关这次事务的信息，并与中央计算机交换关于事务的信息。首先，ATM要求用户输入密码，接下来ATM把从这张卡上读到的信息以及用户输入的密码传给中央计算机，请求中央计算机核对这些信息并处理这次事务。中央计算机根据卡上的分行代码确定这次事务与分行的对应关系，并且委托相应的分行计算机验证用户密码。如果用户输入的密码是正确的，ATM就要求用户选择事务类型(取款、查询等)。当用户选择取款时，ATM请求用户输入取款额。最后，ATM从现金出口吐出现金，并且打印出账单交给用户。

建立对象模型：

确定需求中的类与对象和操作，并筛选掉不正确和不必要的。

方法：将需求陈述中的名词作为候选对象，动词作为候选服务（操作），并提取需求陈述中隐含的类。之后筛除掉冗余、无关、笼统、属性、操作、实现等不正确和不必要的类。

初步筛选，剩下下列类：ATM、中央计算机、分行计算机、柜员终端、总行、分行、柜员、储户、账户、事务和现金兑换卡。

类确定后，确定类之间的关联。经初步分析得出的关联只能作为候选的关联需经过进一步筛选，以去掉不正确的或不必要的关联：已删去的类之间的关联、与问题无关的或应在实现阶段考虑的关联、瞬时事件、依赖关系、三元关联、派生关联。

ATM系统原始类图

划分主题

在开发大型、复杂系统的过程中，为了降低复杂程度，习惯于把系统再进一步划分成几个不同的主题，也就是在概念上把系统包含的内容分解成若干个范畴。

确定属性

应该仅考虑与具体应用直接相关的属性，不要考虑那些超出所要解决的问题范围的属性。

在分析过程中应该首先找出最重要的属性，以后再逐渐把其余属性增添进去。认真考察经初步分析而确定下来的那些属性，从中删掉不正确的或不必要的属性：误把对象当作属性、把链属性误作为属性、把限定误当成属性、误把内部状态当成了属性、过于细化、存在不一致的属性。

反复修改

仅仅经过一次建模过程很难得到完全正确的对象模型。软件开发过程是一个多次反复修改、逐步完善的过程。在建模的任何一个步骤中，如果发现了模型的缺陷，都必须返回到前期阶段进行修改。

最终ATM对象模型