软件工程就是为了经济地获得可靠的且能在实际机器上有效地运行的软件，而建立和使用完善的工程原理。
软件工程的目标是经济地开发出高质量的软件
软件生命周期由软件定义、软件开发、运行维护3个时期组成，每个时期又进一步划分成若干个阶段。
软件定义时期的任务是：
这个时期的工作通常又称为系统分析，由系统分析员负责完成。软件定义时期通常进一步划分成3个阶段：
开发时期具体设计和实现在前一个时期定义的软件，它通常由下述4个阶段组成：
其中前两个阶段又称为系统设计，后两个阶段又称为系统实现。
维护时期的主要任务是使软件持久地满足用户的需要。
通常对维护时期不再进一步划分阶段，但是每一次维护活动本质上都是一次压缩和简化了的定义和开发过程。
这个特点有两重含义：①必须等前一阶段的工作完成之后，才能开始后一阶段的工作；②前一阶段的输出文档就是后一阶段的输入文档。因此，只有前一阶段的输出文档正确，后一阶段的工作才能获得正确的结果。
软件工程的基本目标是优质、高产。为了保证所开发的软件的质量，在瀑布模型的每个阶段都应坚持两个重要做法：（1）每个阶段都必须完成规定的文档，没有交出合格的文档就是没有完成该阶段的任务。（2）每个阶段结束前都要对所完成的文档进行评审，以便尽早发现问题，改正错误。
使用原型及其他方法来尽量降低风险。
由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，因此不利于项目的管理。此外这种模型要求严格管理文档，使得审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况。
？？？what'sthis？？？
这个阶段要回答的关键问题是：“对于上一个阶段所确定的问题有行得通的解决办法吗”
确定问题是否值得去解决
(1)名字应代表整个数据流(或数据存储)的内容，而不是仅仅反映它的某些成分。(2)不要使用空洞的、缺乏具体含义的名字(如“数据”、“信息”、“输入”之类)。(3)如果在为某个数据流(或数据存储)起名字时遇到了困难，则很可能是因为对数据流图分解不恰当造成的，应该试试重新分解，看是否能克服这个困难。
这个阶段的任务是准确地确定“为了解决这个问题，目标系统必须做什么”，主要是确定目标系统必须具备哪些功能。
综合上述两项分析的结果可以导出系统的详细的逻辑模型，通常用数据流图、实体-联系图、状态转换图、数据字典和主要的处理算法描述这个逻辑模型。
根据在分析过程中获得的对系统的更深入更具体的了解，可以比较准确地估计系统的成本和进度，修正以前制定的开发计划。
需求分析是软件生存周期中计划阶段的最后一个步骤
DFD（分层数据流图）：概念
分层：面对复杂的系统时，一个比较好的方法是分层次地描绘这个系统。首先用一张高层次的系统流程图描绘系统总体概貌，表明系统的关键功能。然后分别把每个关键功能扩展到适当的详细程度，画在单独的一页纸上。
数据字典（DD）加工说明：结构化语言、判定表、判定树
概念性数据模型是一种面向问题的数据模型，是按照用户的观点对数据建立的模型。它描述了从用户角度看到的数据，它反映了用户的现实环境，而且与在软件系统中的实现方法无关。
属性定义了数据对象的性质。必须把一个或多个属性定义为“标识符”应该根据对所要解决的问题的理解，来确定特定数据对象的一组合适的属性。
联系可分为以下3种类型：(1)一对一联系(1∶1)(2)一对多联系(1∶N)(3)多对多联系(N:N)
状态转换图(简称为状态图)通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为。状态图还指明了作为特定事件的结果系统将做哪些动作(例如，处理数据)。状态图提供了行为建模机制，可以满足第3条分析准则的要求。
事件是在某个特定时刻发生的事情，它是对引起系统做动作或(和)从一个状态转换到另一个状态的外界事件的抽象。
(1)必须有形式化的语法(或表)，因此可以用计算机自动处理使用这种语法说明的内容；(2)使用这个软件工具能够导出详细的文档；(3)必须提供分析(测试)规格说明书的不一致性和冗余性的手段，并且应该能够产生一组报告指明对完整性分析的结果；(4)使用这个软件工具之后，应该能够改进通信状况。
可以站在全局高度上，花较少成本，从较抽象的层次上分析对比多种可能的系统实现方案和软件结构，从中选出最佳方案和最合理的软件结构，从而用较低成本开发出较高质量的软件系统。
总体设计过程通常由两个主要阶段组成：
典型的总体设计过程包括下述9个步骤：
耦合是对一个软件结构内不同模块之间互连程度的度量。耦合强弱取决于模块间接口的复杂程度，进入或访问一个模块的点，以及通过接口的数据。
内聚标志一个模块内各个元素彼此结合的紧密程度，它是信息隐藏和局部化概念的自然扩展。简单地说，理想内聚的模块只做一件事情。设计时应该力求做到高内聚，通常中等程度的内聚也是可以采用的，而且效果和高内聚相差不多；但是，低内聚很坏，不要使用。
结构化设计方法是基于模块化、自顶向下细化、结构化程序设计等程序设计技术基础发展起来的。
将软件设计成由相对独立且具有单一功能的模块组成的结构，分为概要设计和详细设计两个阶段。
详细设计阶段的任务就是把解法具体化，也就是回答下面这个关键问题：“应该怎样具体地实现这个系统呢”
详细设计阶段的根本目标是确定应该怎样具体地实现所要求的系统，也就是说，经过这个阶段的设计工作，应该得出对目标系统的精确描述，从而在编码阶段可以把这个描述直接翻译成用某种程序设计语言书写的程序。
详细设计阶段的任务还不是具体地编写程序，而是要设计出程序的“蓝图”，以后程序员将根据这个蓝图写出实际的程序代码。因此，详细设计的结果基本上决定了最终的程序代码的质量。考虑程序代码的质量时必须注意，程序的“读者”有两个，那就是计算机和人。
程序流程图、NS图（方块图）、HIPO图、PAD图（问题分析图）
程序流程图又称为程序框图，它是历史最悠久、使用最广泛的描述过程设计的方法，然而它也是用得最混乱的一种方法。
出于要有一种不允许违背结构程序设计精神的图形工具的考虑，Nassi和Shneiderman提出了盒图，又称为N-S图。
PAD是问题分析图(problemanalysisdiagram)的英文缩写，自1973年由日本日立公司发明以后，已得到一定程度的推广。它用二维树形结构的图来表示程序的控制流，将这种图翻译成程序代码比较容易。
PAD图是面向高级程序设计语言的，为FORTRAN，COBOL和PASCAL等每种常用的高级程序设计语言都提供了一整套相应的图形符号。由于每种控制语句都有一个图形符号与之对应，显然将PAD图转换成与之对应的高级语言程序比较容易。
过程设计语言（PDL）也称为伪码，这是一个笼统的名称，现在有许多种不同的过程设计语言在使用。它是用正文形式表示数据和处理过程的设计工具。PDL具有严格的关键字外部语法，用于定义控制结构和数据结构；另一方面，PDL表示实际操作和条件的内部语法通常又是灵活自由的，可以适应各种工程项目的需要。因此，一般说来，PDL是一种“混杂”语言，它使用一种语言的词汇，同时却使用另一种语言(某种结构化的程序设计语言)的语法。
不如图形工具形象直观，描述复杂的条件组合与动作间的对应关系时，不如判定表清晰简单。
PROCEDUREspellcheckISBEGINsplitdocumentintosinglewordsloadupwordsindictionarydisplaywordswhicharenotindictionarycreateanewdictionaryENDspellcheck详细设计说明书详细设计产生的主要文件是详细设计说明书，它为编写源代码提供了必要的说明
这个阶段的关键任务是写出正确的容易理解、容易维护的程序模块。程序员应该根据目标系统的性质和实际环境，选取一种适当的高级程序设计语言(必要时用汇编语言)，把详细设计的结果翻译成用选定的语言书写的程序，并且仔细测试编写出的每一个模块。
结构化程序设计（structuredprogramming）是进行以模块功能和处理过程设计为主的详细设计的基本原则。结构化程序设计是过程式程序设计的一个子集，它对写入的程序使用逻辑结构，使得理解和修改更有效更容易。
源程序代码的逻辑简明清晰、易读易懂是好程序的一个重要标准，为了做到这一点，应该遵循下述规则。
程序清单的布局对于程序的可读性也有很大影响，应该利用适当的阶梯形式使程序的层次结构清晰明显。编写源程序文件通常要考虑的问题包括
程序的清晰性是最重要的目标
在设计和编写程序时应该考虑下述有关输入输出风格的规则：
这个阶段的关键任务是通过各种类型的测试(及相应的调试)使软件达到预定的要求。
G.Myers给出了关于测试的一些规则，这些规则也可以看作是测试的目标或定义。
在设计得好的软件系统中，每个模块完成一个清晰定义的子功能，而且这个子功能和同级其他模块的功能之间没有相互依赖关系。因此，有可能把每个模块作为一个单独的实体来测试，而且通常比较容易设计检验模块正确性的测试方案。模块测试的目的是保证每个模块作为一个单元能正确运行，所以模块测试通常又称为单元测试。在这个测试步骤中所发现的往往是编码和详细设计的错误。
子系统测试是把经过单元测试的模块放在一起形成一个子系统来测试。模块相互间的协调和通信是这个测试过程中的主要问题，因此，这个步骤着重测试模块的接口。
系统测试是把经过测试的子系统装配成一个完整的系统来测试。在这个过程中不仅应该发现设计和编码的错误，还应该验证系统确实能提供需求说明书中指定的功能，而且系统的动态特性也符合预定要求。在这个测试步骤中发现的往往是软件设计中的错误，也可能发现需求说明中的错误。不论是子系统测试还是系统测试，都兼有检测和组装两重含义，通常称为集成测试。
验收测试把软件系统作为单一的实体进行测试，测试内容与系统测试基本类似，但是它是在用户积极参与下进行的，而且可能主要使用实际数据(系统将来要处理的信息)进行测试。验收测试的目的是验证系统确实能够满足用户的需要，在这个测试步骤中发现的往往是系统需求说明书中的错误。验收测试也称为确认测试。
白盒测试法与黑盒测试法相反，它的前提是可以把程序看成装在一个透明的白盒子里，测试者完全知道程序的结构和处理算法。这种方法按照程序内部的逻辑测试程序，检测程序中的主要执行通路是否都能按预定要求正确工作。白盒测试又称为结构测试。设计测试方案是测试阶段的关键技术问题。测试方案包括具体的测试目的（例如，预定要测试的具体功能），应该输入的测试数据和预期的结果。通常又把测试数据和预期的输出结果称为测试用例。其中最困难的问题是设计测试用的输入数据。不同的测试数据发现程序错误的能力差别很大，为了提高测试效率降低测试成本，应该选用高效的测试数据。因为不可能进行穷尽的测试，选用少量“最有效的”测试数据，做到尽可能完备的测试就更重要了。
有选择地执行程序中某些最有代表性的通路是对穷尽测试的惟一可行的替代办法。所谓逻辑覆盖是对一系列测试过程的总称，这组测试过程逐渐进行越来越完整的通路测试。测试数据执行(或叫覆盖)程序逻辑的程度可以划分成哪些不同的等级呢从覆盖源程序语句的详尽程度分析。
语句覆盖：就是指设计若干个测试用例，使得用这些测试用例执行测试之后使得每一条可执行语句至少被执行一遍。对于前面的例子，L1包含了所有的可执行语句，所以根据L1来设计测试用例就可以达到100%语句覆盖。用例如下：
{input(A,B,x);output(A,B,x)}={(2,0,4),(2,0,3)}不足if(A>1)and(B=0) x=x/A;if（A=2)or(X>1) x=x+1;判定覆盖又称为分支覆盖：设计若干个测试用例，执行测试，使得被测单元中的每个判定的取值TRUE和FALSE分支至少经历一次。对于判定(A>1)and(B=0)和(A=2)or(X>0)分别测试其true,false分支。可以选择L1,L2组合或者L3,L4组合。对于L1,L2组合，L1:{(2,0,4)，(2,0,3)}L2:{(1,1,1),(1,1,1)};对于L3,L4组合，L1:{(2,1,1)，(2,1,2)}L2:{(3,0,3),(3,1,1)};
设计若干个用例，执行测试，每个语句至少执行一次，并且使得程序中每个判定的每个条件的可能取值至少执行一次。
if(A>1)and(B=0) x=x/A;if（A=2)or(X>0) x=x+1;条件包括：
使用判定-条件覆盖来弥补这个不足。
判定-条件覆盖就是设计足够的测试用例,使得判定中每个条件的所有可能取值至少执行一次，同时每个判定的所有可能判定结果至少执行一次。
路径覆盖就是设计足够的测试用例，覆盖程序中所有可能的路径。
图论中点覆盖的概念定义如下：如果连通图G的子图G′是连通的，而且包含G的所有结点，则称G′是G的点覆盖。由于流图的每个结点与一条或多条语句相对应，显然，点覆盖标准和语句覆盖标准是相同的。
图论中边覆盖的定义是：如果连通图G的子图G″是连通的，而且包含G的所有边，则称G″是G的边覆盖。为了满足边覆盖的测试标准，要求选取足够多测试数据，使得程序执行路径至少经过流图中每条边一次。通常边覆盖和判定覆盖是一致的。
黑盒测试法把程序看作一个黑盒子，完全不考虑程序的内部结构和处理过程。也就是说，黑盒测试是在程序接口进行的测试，它只检查程序功能是否能按照规格说明书的规定正常使用，程序是否能适当地接收输入数据并产生正确的输出信息，程序运行过程中能否保持外部信息的完整性。黑盒测试又称为功能测试。黑盒测试着重测试软件功能。黑盒测试并不能取代白盒测试，它是与白盒测试互补的测试方法，它很可能发现白盒测试不易发现的其他类型的错误。黑盒测试力图发现下述类型的错误：①功能不正确或遗漏了功能；②界面错误；③数据结构错误或外部数据库访问错误；④性能错误；⑤初始化和终止错误。白盒测试在测试过程的早期阶段进行，而黑盒测试主要用于测试过程的后期。
等价划分是一种黑盒测试技术，这种技术把程序的输入域划分成若干个数据类，据此导出测试用例。一个理想的测试用例能独自发现一类错误。穷尽的黑盒测试通常是不现实的。因此，只能选取少量最有代表性的输入数据作为测试数据，以期用较小的代价暴露出较多的程序错误。等价划分法力图设计出能发现若干类程序错误的测试用例，从而减少必须设计的测试用例的数目。
经验表明，处理边界情况时程序最容易发生错误。边界值分析是一种测试用例设计技术，它是等价划分的补充。
不同类型不同特点的程序通常又有一些特殊的容易出错的情况。有时分别使用每组测试数据时程序都能正常工作，这些输入数据的组合却可能检测出程序的错误。一般说来，即使是一个比较小的程序，可能的输入组合数也往往十分巨大，因此必须依靠测试人员的经验和直觉，从各种可能的测试方案中选出一些最可能引起程序出错的方案。对于程序中可能存在哪类错误的推测，是挑选测试方案时的一个重要因素。
维护阶段是软件生命周期的最后一个阶段，其基本任务是保证软件在一个相当长的时期能够正常运行。软件工程的目的是要提高软件的可维护性，减少软件维护所需要的工作量，降低软件系统的总成本。
如果有一个完整的软件配置存在：
这是在软件开发的早期应用软件工程方法学的结果。虽然有了软件的完整配置并不能保证维护中没有问题，但是确实能减少精力的浪费并且能提高维护的总体质量。
如果软件配置的惟一成分是程序代码：
这种维护方式是没有使用良好定义的方法学开发出来的软件的必然结果。
维护阶段的关键任务是，通过各种必要的维护活动使系统持久地满足用户的需要。通常有4类维护活动：
可以把软件的可维护性定性地定义为：维护人员理解、改正、改动或改进这个软件的难易程度。提高可维护性是支配软件工程方法学所有步骤的关键目标。
维护要求表是一个外部产生的文件，它是计划维护活动的基础。软件组织内部应该制定出一个软件修改报告，它给出下述信息：
面向对象的方法学可以用下列方程来概括：
OO=objects +classes +inheritance +communicationwithmessagesOO基本概念：对象、类、封装、继承、多态、消息对象在应用领域中有意义的、与所要解决的问题有关系的任何事物都可以作为对象，它既可以是具体的物理实体的抽象，也可以是人为的概念，或者是任何有明确边界和意义的东西。
对象由
封装在一起构成的统一体。
分类是人类认识客观世界的基本方法。在面向对象的软件技术中，“类”就是对具有相同数据和相同操作的一组相似对象的定义，也就是说，类是对具有相同属性和行为的一个或多个对象的描述。
实例就是由某个特定的类所描述的一个具体的对象。
在面向对象的程序中，把数据和实现操作的代码集中起来放在对象内部。一个对象好像是一个不透明的黑盒子，表示对象状态的数据和实现操作的代码与局部数据，都被封装在黑盒子里面，从外面是看不见的，更不能从外面直接访问或修改这些数据和代码。使用一个对象的时候，只需知道它向外界提供的接口形式，无须知道它的数据结构细节和实现操作的算法。
假设B继承自A，那么Aa=newB()，那么假设A和B中都有m()方法，a.m()调用的是B中的m()方法
消息就是要求某个对象执行在定义它的那个类中所定义的某个操作的规格说明。通常，一个消息由下述3部分组成：
方法就是对象所能执行的操作，也就是类中所定义的服务。方法描述了对象执行操作的算法，响应消息的方法。
属性就是类中所定义的数据，它是对客观世界实体所具有的性质的抽象。类的每个实例都有自己特有的属性值。
两种重载
不论采用哪种方法开发软件，分析的过程都是提取系统需求的过程分析工作主要包括3项内容：
高层设计模型：Client/ServerMVC类的设计（复用类）任务（应该是这个？）在面向对象系统中，你将发现类和通信对象的重复出现的模式。这些模式解决特定的设计问题，并使得面向对象设计更灵活、优美和最终可复用。他们通过将新的设计基于以前的经验之上而帮助设计者复用成功的设计，熟悉这样模式的设计者可以立即应用他们到设计问题中，而不需要重新去发现他们。
面向对象技术中的“类”，是比较理想的可重用软构件，不妨称之为类构件
(1)模块独立性强(2)具有高度可塑性(3)接口清晰、简明、可靠
(1)实例重用
使用适当的构造函数，按照需要创建类的实例还可以用几个简单的对象作为类的成员创建出一个更复杂的类
(2)继承重用
关键是设计一个合理的、具有一定深度的类构件继承层次结构
(3)多态重用
使对象的对外接口更加一般化(基类与派生类的许多对外接口是相同的)系统运行时，根据接收消息的对象类型，由多态性机制启动正确的方法，去响应一个一般化的消息
问题未在分析过程中被发现，传播到设计阶段产生的问题
OO测试在策略上和传统系统的测试类似，但是，战术技巧上存在不同。因为OO分析和设计模型在结构上类似于最终OO程序的内容，“测试”从对这些模型的评审开始。一旦代码生成，OO测试开始“小规模”类测试。一系列测试被设计以检查类操作并检查当某类和其他类协作时是否有错误发生。类被集成以形成子系统，用于完全地测试协作类。最后，user-case被用于发现在软件确认级的错误。
你必须在将程序交付给客户之前执行程序以试图消除所有错误，从而使客户将不会经历由于质量差所带来的挫折。为了发现最大可能数量的错误，测试必须被系统化地进行，必须用严格的技术来设计测试案例。
UML模型图（5类，10种）：
从本质上将，一个用例是用户与计算机之间为达到某个目的的一次典型交互作用：
用例图描述系统外部的执行者与系统的用例之间的某种联系。
用例图着重于从系统外部执行者的角度来描述系统需要提供哪些功能，并且指明了这些功能的执行者是谁；用例图在UML方法中占有十分重要的地位，人们甚至称UML是一种用例图驱动的开发方法。
在面向对象的建模技术中，类、对象和它们之间的关系是最基本的建模元素。对于一个想要描述的系统，其类模型、对象模型以及它们之间的关系揭示了系统的结构。类图描述了系统中的类及其相互之间的各种关系，其本质反映了系统中包含的各种对象的类型以及对象间的各种静态关系（关联，子类型）。
类图描述类及类与类之间的静态关系。类图是一种静态模型，它是创建其他UML图的基础。
可见性属性名：类型名=初值{性质串}属性的可见性（即可访问性）：
注意，没有默认的可见性。
可见性操作名（参数表）：返回值类型{性质串}操作可见性的定义方法与属性相同。参数表是用逗号分隔的形式参数的序列。描述一个参数的语法如下：
对象图是类图的一种变形。除了在对象名下面要加下划线以外，对象图中所使用的符号与类图基本相同。对象图是类图的一种实例化。一张对象图表示的是与其对应的类图的一个具体实例，即系统在某一时期或者某一特定时刻可能存在的具体对象实例以及它们相互之间的具体关系。对象图并不象类图那样具有重要的地位，但是利用它可以帮助我们通过具体的实例分析，更具体直观地了解复杂系统类图的丰富内涵。对象图还常常被用作合作图的一部分，用以展示一组对象实例之间的动态协作关系。
聚集也称为聚合，是关联的特例。聚集表示类与类之间的关系是整体与部分的关系。在陈述需求时使用的“包含”、“组成”、“分为……部分”等字句，往往意味着存在聚集关系。除了一般聚集之外，还有两种特殊的聚集关系，分别是共享聚集和组合聚集。
UML中的泛化关系就是通常所说的继承关系，它是通用元素和具体元素之间的一种分类关系。具体元素完全拥有通用元素的信息，并且还可以附加一些其他信息。在UML中，用一端为空心三角形的连线表示泛化关系，三角形的顶角紧挨着通用元素。注意，泛化针对类型而不针对实例实际上，泛化关系指出在类与类之间存在“一般-特殊”关系。泛化可进一步划分成普通泛化和受限泛化。
可以给泛化关系附加约束条件，以进一步说明该泛化关系的使用方法或扩充方法，这样的泛化关系称为受限泛化。预定义的约束有4种：多重、不相交、完全和不完全。这些约束都是语义约束。
依赖关系描述两个模型元素（类、用例等）之间的语义连接关系：其中一个模型元素是独立的，另一个模型元素不是独立的，它依赖于独立的模型元素，如果独立的模型元素改变了，将影响依赖于它的模型元素。
软件与明确地和隐含地定义的需求相一致的程度
当软件在指定条件下使用时，软件产品提供满足明确和隐含要求的功能的能力。
软件产品维持规定的性能级别的能力。
产品被理解、学习、使用和吸引用户的能力。
相对于所用资源的数量，软件产品可提供适当性能的能力。
可被修改的能力。修改可能包括纠正、改进或软件对环境、需求和功能规格说明变化的适应。
从一种环境转移到另一种环境的能力。
美国卡内基梅隆大学软件工程研究所在美国国防部资助下于20世纪80年代末建立的能力成熟度模型（capabilitymaturitymodel，CMM)，是用于评价软件机构的软件过程能力成熟度的模型。
最初，建立此模型的目的主要是，为大型软件项目的招投标活动提供一种全面而客观的评审依据，发展到后来，此模型又同时被应用于许多软件机构内部的过程改进活动中。
能力成熟度模型的基本思想是，由于问题是由我们管理软件过程的方法不当引起的，所以新软件技术的运用并不会自动提高软件的生产率和质量。
初始级-无序过程
可重复级
已定义级
可管理级
优化级
1、一次性
2、独特性
3、目标的明确性
4、组织的临时性和开放性
5、后果的不可挽回性
项目具有较大的不确定性，它的过程是渐进的，潜伏着各种风险。它不像有些事情可以试做，或失败了可以重来，即项目具有不可逆转性。