第一篇：软件工程之用例模型总结

软件工程之用例模型总结

一、用例模型1.用例概念用例：使用系统时发现的功能性需求，不应过于复杂，简单的来说就是你希望系统能够有什么功能，能够增加系统的价值。

用例模型包括用例描述和用例图，我们主要把中心放在用例描述上。

用例模型包含参与者和场景，场景包括成功场景和失败场景。因此用例模型中有多个场景；每个场景是一个用例。用例必须注重为用户提供可观察的返回值，就是系统触发了一个用例之后能够给用户带来什么。

一般用例都是黑盒用例，即不考虑如何实现。2.Use Case Description每个用例都有一个描述。怎样确定用例？(1)确定一个功能；

(2)写一个用例；(1)主要参与者：调用系统服务完成目标的人。(2)次要参与者：为系统提供服务的人。

(3)写出每个项目相关人员的理想需求，从中分析功能。(4)PreCondition:执行到这个用例之前必须为真的情况，比如必须已成功登录或通过验证。

(5)PostCondition:成功执行完此用例后的情况，比如登录用例的后置条件是成功登录（不考虑其他失败情况）。(6)main flow：将最理想的步骤列出。一般main flow步骤如下：

(1)参与者发生动作。

(2)系统验证。

(3)返回结果。

(7)extension flow：扩展步骤,通常格式为：(1)系统检测到**有问题;在main flow中的第一步扩展，则用1a,1b,1c;3.如何确保正确的用例

EBP原则:一般用例都需要遵守这个规则，即确定主要用例。用例中的主要用例是一些重复做但是有意义的事，比如收银员收钱，重复多次是有意义的，因为钱收得多了；但是像登录系统，这种做100次却没有意义的用例，不能被称为主要用例；

(1)EBP（基本业务过程）原则的用例写入；

(2)如果要写编辑A，删除A，添加A，可以合并成“管理A”； 4.用例图

每个用例描述都是一个用例，左边是主要参与者（希望系统为他提供服务）和次要参与者（提供给系统服务的人）；

在次要参与者中不能有数据库，因为在用户角度看是不知道系统有数据库的；

关系：

(1)泛化关系，在参与者和用例中都能泛化。(2)包含关系：

表示A包含B；比如A是管理数据，B可以是添加数据、删除数据等；

(3)扩展关系：表示D被C扩展，D包含新的功能，比如D是查询数据，C可以是打印数据，即用户可以查询但不打印数据，打印数据只是一个扩展功能。用例描述模板 [html] view plain copy

用例模型根据系统边界的确定，描述了系统的输入和输出，确定了系统外部的参与者，通过用例描述了系统的主要功能，描述了外部参与者与系统的交互，将系统作为一个黑盒，从用户角度描绘出系统需要提供的功能;

Use Case：用例名称

Actor：参与者

Precondition：前置条件，即执行这个用例一定要满足的条件

Postcondition：后置条件，如果成功执行，则一定会变成的状态

Main flow：

1.用户开始一次会话

2.用户输入信息

3.系统验证并反馈

4.用户重复2，3步

Extensions：

3a：数据无效

1.系统提示出错

第二篇：软件工程生命周期模型的学习总结

综述

软件过程定义了软件开发中采用的方法。软件工程是集成计算机软件开发的过程、方法和工具的学科。

软件工程的一般视图：定义阶段（做什么）、开发阶段（如何做）、支持阶段（变化）。线性顺序模型

有时被称为“传统生存周期或瀑布模型”。

活动包括：系统/信息工程和建模、软件需求分析、设计、代码生成、测试、支持 为什么线性模型有时候不能奏效？

建议：虽然线性模型经常被嘲笑为“旧式的”，但是，在需求被很好理解的情况下，它仍然是一种合理的方法。缺点：

1、实际的项目大部分情况难以按照该模型给出的顺序进行，而且这种模型的迭代是间接的，这很容易由微小的变化而造成大的混乱。

2、经常情况下客户难以表达真正的需求，而这种模型却要求如此，这种模型是不欢迎具有二义性问题存在的。

3、客户要等到开发周期的晚期才能看到程序运行的测试版本，而在这时发现大的错误时，可能引起客户的惊慌，而后果也可能是灾难性的。

4、采用这种线性模型，会经常在过程的开始和结束时碰到等待其他成员完成其所依赖的任务才能进行下去，有可能花在等待的时间比开发的时间要长。我们称之为“堵赛状态”。

优点：

1、它提供了一个摸板，这个摸板使得分析、设计、编码、测试和支持的方法可以在该摸板下有一个共同的指导。

2、虽然有不少缺陷但比在软件开发中随意的状态要好得多。

瀑布模型将软件开发活动分为需求分析、设计、编码、测试等几个阶段，这几个阶段是对工程活动的划分，瀑布模型没有再涉及其它方面的活动，因此瀑布模型关注于工程活动。

关于选取开发模型

有时开发模型的选取不是很容易判断的，这里面有时不单是需求及开发的问题，对于开发商有开发周期、开发费用的问题，对于用户同样有内部计划、公司发展计划等因素进行影响。

一般来说对于应用开发―――为客户开发软件，客户在开发及测试完毕软件后就要实际开始使用，那么就使用瀑布模型。

当然在需求明确的情况下自然也要使用瀑布模型

对于自主开发及客户需求不明并有较长的设计时间―――可以用演化模型。

而螺旋模型适于适合于大型软件开发，吸收了“演化”概念，不过有时也用于用户需求不明的情况下。当然还有其他开发模型，没有在本文讨论。名词定义：

瀑布模型：规定了各项软件工程活动。包括：制定开发计划、进行需求分析和说明、软件设计、程序编码、测试及维护。

特点：自上而下，相互衔接的固定次序，如瀑布流水、逐级下落。

演化模型：第一次只是试验开发，其目标只在于探索可行性，弄清软件需求;第二次则在此基础上获得较为满意的软件产品，通常把一次得到的试验性产品称“原型”。特点：减少由于软件需求不明确而给开发带来的风险。

螺旋模型：将瀑布模型及演化螺旋模型结合起来，并且加入被两种模型都忽略了的风险分析，弥补了两者的不足。

瀑布模型的特点：

① 瀑布模型为软件的开发和维护提供了一种有效有管理模式，对保证软件产品的质量有重要的作用；

② 可根据这一模式制定出开发计划，进行成本预算，组织开发力量，以项目的阶段评审和文档控制为手段，有效地对整个开发过程进行指导； ③ 在一定程度上消除非结构化软件、降低软件的复杂度、促进软件开发工程化方面起到显著作用；

④ 瀑布模型缺乏灵活性、无法通过开发活动来澄清本来不够确切的需求，这将导致直到软件开发完成时发现所开发的软件并非是用户所需求的。原型实现模型

原型实现范型定义： 需求收集 快速设计

原型实现模型是迭代的，是帮助客户或开发者理解需求的，总体上讲，并不是交付一个最终产品系统。其流程从听取客户意见开始、随后是建造/修改原型、客户测试运行原型、然后回头往复循环直到客户对原型满意为止。由于这种模型可以让客户快速的感受到实际的系统（虽然这个系统不带有任何质量的保证），所以客户和开发者都比较喜欢这种过程模型（对于那些仅仅用来演示软件功能的公司而言或从来不考虑软件质量和不害怕长期维护的公司而言）。缺点：

1、没有考虑软件的整体质量和长期的可维护性。

2、大部分情况是不合适的操作算法被采用目的为了演示功能，不合适的开发工具被采用仅仅为了它的方便，还有不合适的操作系统被选择等等。

3、由于达不到质量要求产品可能被抛弃，而采用新的模型重新设计。

优点：

1、如果客户和开发者达成一致协议：原型被建造仅为了定义需求，之后就被抛弃或者部分抛弃，那么这种模型很合适了。

2、迷惑客户抢占市场，这是一个首选的模型。

原型实现仍然是软件工程的一个有效范型。关键是定义开始时的游戏规则，即客户和开发者达成一致：原型被建造仅是为了定义需求，之后就被抛弃了（或至少部分被抛弃），实际的软件在充分考虑了质量和可维护性之后才被开发。

建议：当你的客户有一个合理的续签，但对细节没有任务线索时，先开发一个原型。

原型模型则主要是为了解决需求获取的难题而创建原型用于需求的获取和确认，再将需求转化为软件系统，其主要内容集中在软件开发本身，因此原型模型也关注于工程活动。RAD模型

快速应用开发（Rapid Application Development、RAD）是一个增量型的软件开发过程模型，强调极短的开发周期。是线性顺序模型的一个“高速”变种，通过使用基于构件的建造发放赢得了快速开发。如果需求理解的好而且约束了项目的范围，利用这种模型可以很快的创建出功能完善的“信息系统”。其流程从业务建模开始，随后是数据建模、过程建模、应用生成、测试及反复。RAD过程强调的是复用，复用已有的或开发可复用的构件。实际上RAD采用第四代技术。基于构件的软件工程（不理解）适用范围：

如果需求理解得很并且约束了项目范围。主要适用于信息系统应用，包括以下阶段：业务建模、数据建模、过程建模、应用生成、测试及反复。

业务建模工作流程与其他工作流程的关系如下：

业务模型是需求工作流程的一种重要输入，用来了解对系统的需求。

业务实体是分析设计工作流程的一种输入，用来确定设计模型中的实体类。

缺点：

1、只能用于信息系统。

2、对于较大的项目需要足够的人力资源去建造足够的RAD组。

3、开发者和客户必须在很短的时间完成一系列的需求分析，任何一方配合不当都会导致RAD项目失败。

4、这种模型对模块化要求比较高，如果有哪一功能不能被模块化，那么建造RAD所需要的构件就会有问题。

5、技术风险很高的情况下不适合这种模型。

优点：

1、开发速度快，质量有保证。

2、对信息系统特别有效。演化软件过程模型

演化模型是迭代的。它的特征是：使软件工程师渐进地开发逐步完善的软件版本。

5.1 增量模型

增量模型融合了线性顺序模型的基本成分（重复的应用）和原型实现的迭代特征。增量模型采用随着日程时间的进展而交错的线性序列。每一个线性序列产生软件的一个可发布的“增量”。当使用增量模型时，第一个增量往往是核心的产品，也就是说第一个增量实现了基本的需求，但很多补充的特征还没有发布。客户对每一个增量的使用和评估，都做为下一个增量发布的新特征和功能。这个过程在每一个增量发布后不断从复，直到产生了最终的完善产品。增量模型强调每一个增量均发布一个可操作的产品。

缺点：

1、至始至终开发者和客户纠缠在一起，直到完全版本出来。

优点：

1、人员分配灵活，刚开始不用投入大量人力资源，当核心产品很受欢迎时，可增加人力实现下一个增量。

2、当配备的人员不能在设定的期限内完成产品时，它提供了一种先推出核心产品的途径，这样就可以先发布部分功能给客户，对客户起到镇静剂的作用。

3、具有一定的市场。

增量模型将瀑布模型的顺序化和多次迭代相结合，每个增量开发都是一次瀑布模型的过程，强调每一个增量均发布一个可运行版本，以满足客户和市场的需要。增量模型主要考虑当需要快速推出可运行的版本，而该版本不需要完整的功能时，在工程活动上的解决方案，因此增量模型也关注于工程活动。

5.2 螺旋模型

这是一个演化软件过程模型，它将原型实现的迭代特征和线性顺序模型中控制的和系统化的方面结合起来。使得软件的增量版本的快速开发成为可能。在螺旋模型中，软件开发是一系列的增量发布。在每一个迭代中，被开发系统的更加完善的版本逐步产生。螺旋模型被划分为若干框架活动，也称为任务区域。典型地，有3到6个任务区域：

1、客户交流：建立开发者和客户之间有效通信所需要的任务。

2、计划：定义资源、进度、及其它相关项目信息所需要的任务。

3、风险分析：评估技术的及管理的风险所需要的任务。

4、工程：建立应用的一个或多个表示说需要的任务。

5、构造及发布：构造、测试、安装和提供用户支持所需要的任务。

6、客户评估：基于对在工程阶段产生的或在安装阶段实现的软件表示的评估，获得客户反馈所需要的任务。

这是一个相对较新的模型，它的功效还需要经历若干年的使用方能确定下来。

缺点：

1、需要相当的风险分析评估的专门技术，且成功依赖于这种技术。

2、很明显一个大的没有被发现的风险问题，将会导致问题的发生，可能导致演化的方法失去控制。

3、这种模型相对比较新，应用不广泛，其功效需要进一步的验证。

优点：

1、对于大型系统及软件的开发，这种模型是一个很好的方法。开发者和客户能够较好地对待和理解每一个演化级别上的风险。

螺旋模型的主要贡献在于明确提出迭代概念和风险的问题，并指出在项目定义、需求、设计等阶段均存在风险，需要重点考虑，并通过多次迭代的原型主动诱发风险。风险管理不属于工程活动的范围，但我们仍然认为螺旋模型的主要内容是工程方面的：因为对于非工程活动，螺旋模型仅考虑了风险问题，而风险管理仅是非工程活动的一个小部分，不足以依此推断螺旋模型主要关注于非工程活动。

5.3 WINWIN螺旋模型

螺旋模型提出了强调客户交流的一个框架活动。该活动的目标是从客户处诱导项目需求。在理想情况下，开发者简单地询问客户需要什么,而客户提供足够的细节进行下去。不幸的是这种情形很少发生。在现实中，客户和开发者进入一个谈判过程，客户被要求在成本和应市之间的约束下平衡功能、性能、和其它产品或系统特征。最好的谈判追求“双赢”结果，也就是说通过谈判客户获得大部份系统的功能，而开发者则获得现实的和可达到的预算和时限。对客户的交流定义了下面的活动：

1、系统或子系统的关键“风险承担者”的标识。

2、风险承担者的“赢条件”的确定。

3、风险承担者的赢条件谈判，以将它们协调为一组满足各方考虑的双赢条件。

缺点：

1、需要额外的谈判技巧。

优点：

1、客户和开发者达到一种平衡。

5.4 并发开发模型

这种模型关注于多个任务的并发执行，表示为一系列的主要技术活动、任务及它们的相关状态。并发过程模型是由客户要求、管理决策、评审结果驱动的。该模型不是将软件工程活动限定为一个顺序的事件序列，而是定义了一个活动网络。网络上的每一个活动均可于其它活动同时发生。这种模型可以提供一个项目的当前状态的准确视图。

缺点：暂时无

优点：

1、可用于所有类型的软件开发，而对于客户/服务器结构更加有效。

2、可以随时查阅到开发的状态。基于构件的开发模型

面向对象的技术为软件工程的基于构件的过程模型提供了技术框架。面向对象模型强调了类的创建、类的封装了的数据、操纵该数据的算法。一般来讲经过合适的设计和实现，面向对象的类可以在不同的应用及基于计算机的系统的体系结构中复用。基于构件的开发模型融合了螺旋模型的许多特征，它本质上是演化形的，要求软件创建的迭代方法。然而基于构件的开发模型是利用预先包装好的软件构件（有时成为类）来构造应用。

开发活动从候选类的标识开始，这一步是通过检查将被应用系统操纵的数据及用于实现该操纵的算法来完成的。相关的数据和算法被封装成一个类。

缺点：

1、过分依赖于构件，构件库的质量影响着产品质量。

优点：

1、构件可复用。提高了开发效率。

2、采用了面向对象的技术。形式化方法模型

形式化方法模型包含了一组活动，他们导致了计算机软件的数学规约。形式化方法使得软件工程师们能够通过应用一个严格的数学符号体系来规约、开发、和验证基于计算机的系统。这种方法的一个变种，称为净室软件工程，已经被一些组织所采用。在开发中使用形式化方法时，它们提供了一种机制，能够消除使用其它软件过程模型难以克服的很多问题。二义性、不完整性、不一致性能被更容易地发现和纠正，而不是通过专门的评审，是通过对应用的数学分析。形式化方法提供了可以产生无缺陷软件的承诺。

缺点：

1、开发费用昂贵（对开发人员需要多方面的培训），而且需要的时间较长。

2、不能将这种模型作为对客户通信的机制，因为客户对这些数学语言一无所知。

3、目前还不流行。

优点：

1、形式化规约可直接作为程序验证的基础，可以尽早的发现和纠正错误（包括那些其它情况下不能发现的错误）。

2、开发出来的软件具有很高的安全性和健壮性，特别适合安全部门或者软件错误会造成经济损失的开发者。

3、具有开发无缺陷软件的承诺。第四代技术

一系列的软件工具的使用，是第四代技术的特点。这些工具有一个共同的特点：能够使软件工程师们在较高级别上规约软件的某些特征，然后根据开发者的规约自动生成源代码。我们知道，软件在越高的级别上被规约，就越能被快速的建造出程序。软件工程的4GT模型集中于规约软件的能力：使用特殊的语言形式或一种采用客户可以理解的术语描述待解决问题的图形符号体系。和其它模型一样，4GT也是从需求收集这一步开始的，要将一个4GT实现变成最终产品，开发者还必须进行彻底的测试、开发有意义的文档，并且同样要完成其它模型中同样要求的所有集成活动。总而言之，4GT已经成为软件工程的一个重要方法。特别是和基于构件的开发模型结合起来时，4GT模型可能成为当前软件开发的主流模型！

缺点：

1、用工具生成的源代码可能是“低效”的。

2、生成的大型软件的可维护性目前还令人怀疑。

3、在某些情况下可能需要更多的时间。

优点：

1、缩短了软件开发时间，提高了建造软件的效率。

2、对很多不同的应用领域提供了一种可行性途径和解决方案 9 过程技术 产品和过程 11 附录

第三篇：软件工程题例

【例1】某装配厂有一个存放零件的仓库，仓库中现有的各种零件的数量及每种零件的库存量临界值等数据记录在库存清单主文件中。当仓库中零件数量有变化时，应该及时修改库存清单主文件；如果哪种零件的库存量少于它的库存量临界值，则应该报告给采购部门以便订货，规定每天向采购部门送一次订货报告。

该装配厂使用一台小型计算机处理更新库存清单主文件和产生订货报告的任务。零件库存量的每一次变化称为一个事务，由放在仓库中的CRT终端输入到计算机中；系统中的库存清单程序对事务进行处理，更新存储在磁盘上的库存清单主文件，并且把必要的订货信息写在磁带上。最后，每天由报告生成程序读一次磁带，并且打印出订货报告。下图所示的系统流程图描绘了上述系统的概貌。

事务库存清单主文件库存清单程序订货信息报告生成程序订货报告

例1 【例2】利用Visio绘制如下图所示的数据流图。

D1库存信息库存清单1.11.21.32仓库管理员事务接收事务事务更新库存库存信息处理订货清单订货报表产生报表采购员订货信息D2订货信息订货信息

例2 【例3】车辆购置业务流程

总工程师1.2总经理批复基础设施购置申请单（公司所有）二级公司1.31.1二级公司基础设施购置申请单基础设施购置申请单（公司所有）基础设施购置申请单（融资挂靠）审批购车技术机务部1.4生产经营处车辆调拨通知单二级公司各类单据发票下调拨单并插入设备台帐客货经营处财务处车辆购置登记表汽车履历及规格记录二级公司 例3 试完成飞机订票系统的业务流程图，系统描述如下： 为了方便旅客，某航空公司拟开发一个机票预定系统。旅行社把预定机票的旅客信息（姓名、性别、工作单位、身份证号码、旅行时间、旅行目的地等）输入该系统，系统为旅客安排航班，旅客在飞机起飞前一天凭取票通知和账单交款取票，系统核对无误即印出机票给顾客。

P1.3 P1.1 订票信息P1.2 订票信息打印取票输入旅客查询机票通知及账基本信息信息单订单通知及账单旅客订票信息旅客机票机票预订系统取票通知及账单旅客已付款证明D1 机票信息系统机票D1 航班信息表航班信息要求的机票信息P1.5 取票取票证明P1.4 得到已付款证明付款旅客旅客符合要求的机票P2 符合旅客要求的余票订票信息D2 订票信息表例4

第四篇：软件工程总结

第一章软件与软件工程的概念

软件的概念：软件是计算机系统中与硬件相互依存的另一部分，软件包括程序，数据，及其相关文档的完整集合。程序是按事先设计的功能和性能要求执行的指令序列。数据是使程序能够正确地处理信息的数据结构。文档是与程序开发，维护和使用有关的图文资料。

程序的最小单位是函数及子程序，程序与数据是分离的，在面向对象程序设计时代，程序的最小单位是类，在类中封装了相关的数据及指令代码。

软件的特性，判断正误：1.软件是无形的、不可见的逻辑实体，因此，软件是无法描述的。（错）

2、软件的开发特性是指软件需要大量手工劳动，难以自动化生产。（对）

3、有缺陷的软件就是废品。（错）

4、软件的生产指的是软件的复制。（错）

5、由于软件的开发充满人的个性特点，因此管理并不决定软件开发的成败（错）。

6、软件的开发环境往往就是软件的运行环境，或者与其兼容。（对）

7、合格的软件产品不需要维护，软件需要维护说明其质量不合格。（错）

8、软件可以不断改进，因此软件不需要废弃。（错）

软件的分类：1，系统软件：能与计算机硬件紧密配合在一起，使计算机系统各个部件，相关的软件和数据协调，高效的工作的软件。2，应用软件，是在系统软件的支持下，在特定区域内开发，为特定目的服务的一类软件。3，支撑软件，也叫工具软件，是协助用户开发软件的工具性软件。4，可复用软件，最初实现的典型的可复用软件是各种标准函数库，通常是由计算机厂商提供的系统软件的一部分。

IEEE给出的定义：软件工程是开发，运行，维护和修复软件的系统方法。软件的定义：计算机程序，方法，规则，相关的文档资料一集在计算机上运行时所必需的数据。

软件危机的典型表现

1、成本太高，预算不准

2、超过预计时间

3、软件质量标准不明确

4、生产率低

5、缺乏文档资料，难以维护。原因：1，缺乏软件开发的经验和有关软件开发数据的积累，使得开发工作的计划很难制定。2.软件人员与用户的交流存在障碍，除了知识背景的差异，缺少合适的交流方法及需求描述工具。3，软件开发过程不规范，缺少方法和规范的指导。4，随着软件规模的增大，其复杂性往往会呈指数级升高。5，缺少有效的软件评测手段，提交用户的软件质量差。

软件危机发生的主要原因有：

1、遇到了无法解决的高难度技术问题（不是）

2、无法招聘到足够的编程高手（不是）

3、软件人员与用户互相不理解（是）

4、计划和管理不科学、落实不力（是）

5、软件质量标准不明确（是）

软件的质量特性包括（选择）问题1：

1、功能性

2、可靠性

3、使用性

4、经济性（不包括）

软件的质量特性包括（选择）问题2：

1、效率

2、可维护性

3、可移植性

4、经济性（不包括）

软件工程的目标是运用先进的软件开发技术和管理方法来提高软件的质量和生产率，也就是要以较短的周期，较低的成本生产出高质量的软件产品，并最终实现软件的工业化生产。软件生存期：软件的孕育，诞生，成长，成熟，衰亡的生存过程。软件生存期由软件定义，软件开发和运行维护三个时期组成，每个时期又可划分为若干个阶段。

2、软件定义时期的任务主要任务是解决“做什么”的问题，确定工程的总目标和可行性；实现工程目标的策略及系统功能；估计需要的资源和成本；制订工程进度表。通常又分为3个阶段：问题定义，可行性研究，需求分析。

3、软件开发时期的任务和包含阶段主要任务是解决“如何做”的问题，设计和实现定义的软件。由概要设计、详细设计、编码和测试4个阶段组成。

4、软件运行维护时期的主要任务是使软件持久地满足用户的需要，通常有4类维护活动：改正性维护；适应性维护；完善性维护；预防性维护。开发过程中的典型文档：软件需求规格说明书。项目计划。软件测试计划。软件设计说明书。用户手册。软件工程各个阶段的基本任务

1、问题定义与可行性研究：解决什么问题？能否解决问题？是否值得做？”

2、需求分析：做什么

3、软件设计：如何实现

4、程序编码和单元测试：实现设计

5、集成和系统测试：组装连接测试、功能验证测试

6、软件运行和维护：修改 第二章软件工程方法与工具

软件工具：是指能支持软件生存周期中某一阶段（如系统定义，需求分析，设计，编码，测试，维护等）的需要而使用的软件工具。

需求分析工具

1、结构化图形工具箱。通过数据流程图DFD进行功能分析。包括DFD图形工具，实体-关系图(E-R)图形工具，Jackson图形工具，Warnier图形工具，Visio综合工具，2、面向对象工具，Rational Rose，PowerDesigner，Visio 设计工具（1)概要设计工具：设计目标软件的体系结构、控制结构和数据结构。软件的体系结构通常用模块结构图来描述。模块的数据结构通常用实体-关系图来描述。Visio。Rational Rose 详细设计工具。设计模块的算法和内部实现细节。详细设计描述方法有输入-处理-输出(IPO)图。问题分析图(PAD)。盒图(NS图)。流程图(FC)。程序设计语言(PDL)。结构化语言。判定表。判定树

第三章软件需求获取与结构化分析方法 需求获取的主要任务是与用户沟通，了解系统或产品的目标是什么，客户或用户想要实现什么，系统和产品如何满足业务的要求，最终系统或产品如何用于日常工作。获取并理解用户的需求是软件工程师所面对的最困难的任务之一。

需求分析的困难体现：系统的目标或范围问题；需求不准确性问题；需求的易变问题

需求获取的任务：发现和分析问题，并分析问题的原因，结果关系。与用户进行各种方式的交流，并使用调查研究方法收集信息。按照三个成分即数据，过程和接口观察问题的不同侧面。将获取的需求文档化，形式有用例，决策表，决策树等。需求获取的原则：深入浅出，以流程为主线。

获取具体的需求的途径1，与用户交流。2，现有产品或竞争产品的描述文档。3，系统需求规格说明。4，当前系统的问题报告和改进要求。5，市场调查和用户问卷调查。6，观察用户如何工作。

关于需求获取问题的认识辨析：

1、没有与用户交流就不可能获取系统需求。（不能获取准确、全面的系统需求）

2、没有经过与用户交流而获取的需求都是不真实的需求。（一些需求从用户以外的途径获取）

3、系统开发必须独立完成，参考类似系统及技术文档属于抄袭行为，应予避免。（系统开发包含研究行为，应了解对手产品，取长补短）

4、系统开发包含改进当前系统的缺陷和不足。（对）

5、需求调查时，用户所说的需求未必是真实、准确的需求，因此需求分析需要依赖用户，但是不能过分迷信用户。（对，需求描述是困难的）

6、观察用户如何工作也是一种需求调查行为。（对）

软件需求分析阶段的任务：需求获取，需求分析，需求定义，需求验证。完整性，正确性，合理性，可行性，充分性。

结构化分析方法：是一种建模技术。核心是数据字典。

功能模型用数据流图（DFD)来描述使用实体—关系图（ER图）建立数据模型。使用状态转换图（简称状态图）建立系统行为模型。数据字典。加工规格说明。需求建模的依据是需求描述

数据建模，ER图，需要认真看。

第四章结构化设计方法

结构化设计方法是在模块化，自顶向下逐步细化及结构化程序设计技术基础上发展起来的，结构化设计方法可分为两类：一类是根据系统的数据流进行设计，称为面向数据流的设计，或称过程驱动设计，另一类是根据系统的数据结构进行设计，称为面向数据结构的设计，或称数据驱动的设计。

软件的体系结构设计，模块化设计都是分而治之策略的具体表现。模块化是将整体软件划分为独立命名且可独立访问的模块，不同的模块通常具有不用的功能或指责，每个模块可独立开发，测试，最后组装成完整的软件。模块是构成软件的基本构件。模块并不是越小越好，当模块数目增加时，每个模块的规模将减小，开发单个模块的成本确实减少了，但是随着模块数目增加，模块之间关系的复杂程度也会增加，设计模块间接口所需要的工作量也将增加。

模块的独立性是指软件系统中每个模块只涉及软件要求的具体的子功能，而与软件系统中其他模块的接口是简单的，若一个模块只具有单一的功能且与其他模块没有太多的联系，那么称此模块有独立性。

自顶向下，逐步细化：抽象是指忽视一个主题中与当前目标无关的方面，以便更充分地注意与当前目标有关的方面，当我们进行软件设计时，设计开始时应尽量提高软件的抽象层次，按抽象级别从高到低进行软件设计，将软件的体系结构按自顶向下方式，对各个层次的过程细节和数据细节逐层细化，直到用程序设计语言的语句能够实现为止，从而最后确定整个系统的体系结构，这就是自顶向下逐步细化过程。

复用是指同一事物不做修改或稍加修改就可以多次重复使用，将服用的思想用于软件开发，称为软件复用。1是尽量使用已有的构件。2是如果确实需要创建新的构件，则在设计时应该考虑将来的可重复使用性。软件设计的阶段与任务：从工程管理的角度，可以将软件设计分为概要设计阶段和详细设计阶段。从技术的角度，传统的结构化方法将软件设计划分为体系结构设计、数据设计、接口设计和过程设计4部分；概要设计包括体系结构设计、数据设计、接口设计。详细设计即过程设计，对结构表示进行细化，得到软件详细的数据结构和算法。

软件设计各项设计工作的依据：体系结构设计，定义软件模块及其之间的关系，依赖于数据流图。数据设计，依赖于ER图。接口设计，依赖于顶层数据流图。过程设计：依赖于加工规格说明、状态图

基于数据流方法的设计过程：1.复查并精化数据流图。2.确定数据流图中数据流的类型，典型的数据流类型有变换型数据流和事务型数据流。3.导出初始的软件结构图。4.逐级分解。5.精化软件结构。6.导出接口描述和全局数据结构。

软件模块结构的改进方法：1，模块功能的完善化。2，消除重复功能，改善软件结构。3，模块的作用范围应在控制范围之内。4，尽可能减少高扇出结构，随着深度增大扇入。5，避免或减少使用病态连接。6，模块的大小要适中。接口设计的依据是数据流图中的自动化系统边界。

自顶向下，逐步细化的设计过程主要包括两个方面：一是将复杂问题的解法分析和细化成由若干个模块组成的层次结构，二是将每个模块的功能逐步分解细化为一系列的处理。第五章编码

编码容易出现的风格不足

1、变量或函数名字缺乏具体含义

2、变量或函数名字与其用途不符

3、变量或函数未加上必要的注释

4、函数未说明其功能、参数的意义

5、引用的符号未加以解释和说明

6、对循环等重要的程序语句未注释

7、对用到的重要库函数没有解释说明

8、对结构体等复杂数据结构的组成成分没有解释说明

9、缺乏必要的提示语句 第六章软件测试方法

软件测试是在软件投入生产性运行之前，对软件需求分析，设计规格说明和编码的最终复审，是软件质量控制的关键步骤。软件测试是为了发现错误而执行程序的过程。

第五篇：软件工程总结

一、软件工程概述

1．软件特点

软件：计算机程序（人们为了实现特定的功能而编制的一组指令集），软件文档，以及计算机程序运行时所需要的数据。

软件是计算机系统中的逻辑成分，具有无形性，可复用性。

2．软件分类（1）按功能划分：系统软件、支撑软件、应用软件。（2）按工作方式划分：实时处理软件、分时处理软件、交互式软件、批处理软件。（3）按规模划分：微型软件、小型软件、中型软件、大型软件。（4）按服务对象划分：通用软件、定制软件。3．软件发展阶段（1）程序设计时代（20世纪50年代）。（2）程序系统时代（20世纪60年代）。（3）软件工程时代（20世纪70年代起）。4．软件危机

（1）危机现象：软件开发成本与进度估计不准确，软件产品与用户要求不一致，软件产品质量可靠性差，软件文档不完整不一致，软件产品可维护性差，软件生产率低。

（2）危机原因：科学的工程化思想组织和指导，完善的质量保证体系，软件文档的不重视，软件的不可见性，系统规模庞大，生产工程化程度低，对用户需求关心不 够，对维护不够重视，开发工具自动化程度低。5．软件工程

软件工程：运用现代科学技术知识来设计并构造计算机程序及为开发、运行和维护这些程序所必须的相关文件资料。软件工程是一门关于软件开发与维护的工程学科，它涉及软件生产的各个方面，能够为经济、高效地开发高质量的软件产品提供最有效的支持。

软件工程的目标：控制成本，满足需求，提高质量，提高可靠性，是产品易于维护，移植，升级和使用，控制开发周期。

（1）工程方法：结构化方法、JSD方法、面向对象方法。（2）软件工具：具有自动化特征的软件开发集成支撑环境。（3）工程过程：在软件工具支持下的一系列工程活动，基本活动是软件定义、软件开发、软件验证、软件维护。（4）工程管理：项目规划，项目资源调配，软件产品控制。（5）工程原则：分阶段生命周期计划，阶段评审制度，严格的产品控制，采用先进的技术，成果能清楚地审查，开发队伍精练，不断改进工程实践。（6）工程目标：开发成本较低，软件功能能满足用户需求，软件性能较好，软件可靠性高，软件易于使用、维护与移植，能按时完成开发任务并及时交付使用。（7）工程文化：包括工程价值、工程思想和工程行为三个方面的内容。

二、软件工程过程模型 1．软件生命周期 如同任何事物都有一个发生、发展、成熟直至衰亡的全过程一样，软件系统或软件产品也有一个定义、开发、运行维护直至被淘汰这样的全过程，我们把软件将要经历的这个全过程称为软件的生命周期。它包含：软件定义、软件开发、软件运行维护三个时期，并可以细分为可行性研究、项目计划、需求分析、概要设计、详细设计、编码实现与单元测试、系统 2 集成测试、系统确认验证、系统运行与维护等几个阶段。

软件定义期 软件定义是软件项目的早期阶段，主要由软件系统分析人员和用户合作，针对有待开发的软件系统进行分析、规划和规格描述，确定软件是什么，为今后的软件开发做准备。这个时期往往需要分阶段地进行以下几项工作。1．软件任务立项 软件项目往往开始于任务立项，并需要以“软件任务立项报告”的形式针对项目的名称、性质、目标、意义和规模等作出回答，以此获得对准备着手开发的软件系统的最高层描述。2．项目可行性分析 在软件任务立项报告被批准以后，接着需要进行项目可行性分析。可行性分析是针对准备进行的软件项目进行的可行性风险评估。因此，需要对准备开发的软件系统提出高层模型，并根据高层模型的特征，从技术可行性、经济可行性和操作可行性这三个方面，以“可行性研究报告”的形式，对项目作出是否值得往下进行的回答，由此决定项 目是否继续进行下去。3．制定项目计划 在确定项目可以进行以后，接着需要针对项目的开展，从人员、组织、进度、资金、设备等多个方面进行合理的规划，并以“项目开发计划书”的形式提交书面报告。4．软件需求分析 软件需求分析是软件规格描述的具体化与细节化，是软件定义时期需要达到的目标。需求分析要求以用户需求为基本依据，从功能、性能、数据、操作等多个方面，对软件系统给出完整、准确、具体的描述，用于确定软件规格。其结果将以“软件需求规格说明书”的形式提交。在软件项目进行过程中，需求分析是从软件定义到软件开发的最关键步骤，其结论不仅是今后软件开发的基本依据，同时也是今后用户对软件产品进行验收的基本依据。软件开发期 在对软件规格完成定义以后，接着可以按照“软件需求规格说明书”的要求对软件实施开发，并由此制作出软件产品。这个时期需要分阶段地完成以下几项工作。1．软件概要设计 概要设计是针对软件系统的结构设计，用于从总体上对软件的构造、接口、全局数据结构和数据环境等给出设计说明，并以“概要设计说明书”的形式提交书面报告，其结果将成为详细设计与系统集成的基本依据。模块是概要设计时构造软件的基本元素，因此，概要设计中软件也就主要体现在模块的构成与模块接口这两个方面上。结构化设计中的函数、过程，面向对象设计中的类、对象，它们都是模块。概要设计时并不需要说明模块的内部细节，但是需要进行全部的有关它们构造的定义，包括功能特征、数据特征和接口等。在进行概要设计时，模块的独立性是一个有关质量的重要技术性指标，可以使用模块的内聚、耦合这两个定性参数对模块独立性进行度量。2．软件详细设计 设计工作的第二步是详细设计，它以概要设计为依据，用于确定软件结构中每个模块的内部细节，为编写程序提供最直接的依据。详细设计需要从实现每个模块功能的程序算法和模块内部的局部数据结构等细节内容 3 上给出设计说明，并以“详细设计说明书”的形式提交书面报告。3．编码和单元测试 编码是对软件的实现，一般由程序员完成，并以获得源程序基本模块为目标。编码必须按照“详细设计说明书”的要求逐个模块地实现。在基于软件工程的软件开发过程中，编码往往只是一项语言转译工作，即把详细设计中的算法描述语言转译成某种适当的高级程序设计语言或汇编语言。为了方便程序调试，针对基本模块的单元测试也往往和编码结合在一起进行。单元测试也以“详细设计说明书”为依据，用于检验每个基本模块在功能、算法与数据结构上是否符合设计要求。4．系统集成测试 所谓系统集成也就是根据概要设计中的软件结构，把经过测试的模块，按照某种选定的集成策略，例如渐增集成策略，将系统组装起来。在组装过程中，需要对整个系统进行集成测试，以确保系统在技术上符合设计要求，在应用上满足需求规格要求。5．系统确认验证 在完成对系统的集成之后，接着还要对系统进行确认验证。系统确认验证需要以用户为主体，以需求规格说明书中对软件的定义为依据，由此对软件的各项规格进行逐项地确认，以确保已经完成的软件系统与需求规格的一致性。为了方便用户在系统确认期间能够积极参入，也为了系统在以后的运行过程中能够被用户正确使用，这个时期往往还需要以一定的方式对用户进行必要的培训。在完成对软件的验收之后，软件系统可以交付用户使用，并需要以“项目开发总结报告”的书面形式对项目进行总结。

软件运行与维护期 软件系统的运行是一个比较长久的过程，跟软件开发机构有关的主要任务是对系统进行经常性的有效维护。软件的维护过程，也就是修正软件错误，完善软件功能，由此使软件不断进化升级的过程，以使系统更加持久地满足用户的需要。因此，对软件的维护也可以看成为对软件的再一次开发。在这个时期，对软件的维护主要涉及三个方面的任务，即改正性维护、适应性维护和完善性维护。2．瀑布模型 瀑布模型诞生于20世纪70年代，是最经典的并获得最广泛应用的软件过程模型。瀑布模型中的“瀑布”是对这个模型的形象表达，即山顶倾泻下来的水，自顶向下、逐层细化。（1）特点：线性化模型、阶段具有里程碑特征、基于文档的驱动、阶段评审机制。（2）作用：为软件项目按规程管理提供了便利，为其他过程模型的推出提供了一个良好的 拓展平台。（3）局限性：主要适合于需求明确且无大的需求变更的软件开发，但不适合分析初期需求 模糊的项目。3．原型模型（1）快速原型方法：是原型模型在软件分析、设计阶段的应用，用来解决用户对软件系统在需求上的模糊认识，或用来试探某种设计是否能够获得预期结果。（2）原型进化模型：针对有待开发的软件系统，先开发一个原型给用户使用，然后根据用 户的使用意见，对原型不断修改，使它逐步接近，并最终到达开发目标。