软件工程详解
信息来源：邪恶八进制信息安全团队（[url]www.eviloctal.com[/url]）
一.常用的分析工具：
测试工具：ATTOL UniTest、Ｃ++ Test、MTE、CodeTest;
覆盖率：ATTOL Coverage、PureCoverage、TrueCoverage;
内存检测：Boundschecker、PURIFY;
静态分析（结构）：Mccable、Logiscope、Hindsight;
静态分析（语法）：PC-lint、CodeCHK、CheckMate;
WEB压力测试：Web Express;
设计工具：UML、Rose、Visio、PowerDesigner;
编程工具：SourceInsight；
版本控制：VSS、Beyond Company
二.软件工程文档和方法：
(一)传统软件工程（瀑布模型）
1.问题定义
讨论要解决的问题，做一份书面报告即可。
2.可行性研究
研究问题的范围，探索这个问题是否值得去研究。
需要做的主要工作有：
a. 导出问题定义阶段的高层逻辑模型（通常用数据流图表示[1]），物理系统也可以用系统流程图表示），如有需要须初步定义一些数据字典[2]；
b. 并且做成本/效益分析。
3.需求分析
确定目标系统必须具备哪些功能。必须准确完整的提出系统逻辑模型。
需要做的主要工作有：
a. 划分出系统必须完成的所有功能；
这部分包含需要将功能用文字表达出来，可用层次方框图和Warnier图。在描述模型之间的关系时，可用ER模型来表示，再用范式来消除冗余。
b. 根据以上结果导出系统详细的逻辑模型可用数据流图、数据字典和主要处理算法描述（这个主要处理算法可用IPO图来画）
4.总体设计（概要设计）
划分出组成系统的物理元素――程序、文件、数据库、人工过程和文档等。设计软件的总体结构，确定系统中每个程序由哪些模块组成，以及这些模块相互间的关系。
需要做的主要工作有：
a. 功能分解；
这部分工作含结构设计（主要是模块的划分，可用层次图或结构图描述，可用数据流图来分析）和过程设计（每个模块的处理过程，可用IPO图）
b. 如有数据库，则需进行数据库设计和优化。（推荐使用PowerDesigner）
c. 制订测试计划
5.详细设计
将每个模块中的处理过程细化。
需要做的主要工作有：
a. 描述模块中处理过程；
可用程序流程图、盒图、PAD图、判定表、判定图，或者用伪代码来表示（可用Visio来作图）,可描述其中的复杂度。
6.编码与单元测试
编码（略）。
测试：黑盒测试――功能测试；白盒测试――结构测试；
单元测试即模块测试，在这个测试步骤中所发现的往往是编码和详细设计的错误。
需要做的主要工作有：
a.编写测试案例文档
7.综合测试
编写测试案例和文档
8.软件维护
(二) 面向对象的方法
1.概念和摘要
瀑布式生命周期的缺点表现在三个方面：<1> 后期的变化、迭代、改动困难 <2> 不支持重用 <3> 没有一个联系各个阶段的统一模型。
使用面向对象方法学开发软件时，工作重点应该放在生命周期中的分析阶段。通常需要建立三种形式的模型，分别时描述系统数据结构的对象模型，描述系统控制结构的动态模型和描述系统功能的功能模型，所以核心是建立对象模型――面向对象的建模（当前常用的建模语言是UML）。
在面向对象分析过程（OOA）中，构造出完全独立于实现的应用域模型（需求分析）；在面向对象设计过程(OOD)中，把求解域的结构逐渐加入到模型中（概要设计和详细设计）；在实现阶段，把应用域和求解域的结构都编成程序代码并进行严格的测试验证(编码测试)。测试一个OO系统是另一个需要进一步研究的课题。发布一个稳定的原型需要不同与以往控制结构化开发的产品的配置管理。
为改善面向对象开发的可管理性，玻姆(Boehm,1988)提出了一个结合了宏观和微观视角(macro & microview)的螺旋开发模型。宏观包括3个阶段：1分析---发现和识别对象；2 设计---发明和设计对象；3 实施---创建和实现对象。每个宏观阶段都包含一些微观迭代活动。
无论何种复杂程度的工程项目，设计都是从建模开始的，设计者通过创建模型和设计蓝图来描述系统的结构。(Rational Rose)
2.设计的三层结构
客户机/服务器体系结构的广泛使用预示了系统复杂化的发展趋势，为了解决这一问题，与之相应的三层结构方案(three-tiered)越来越得到了广泛的应用。
传统的两层结构不是“胖客户机”就是“胖服务器”，胖客户机结构将事务处理原则在用户端处理，胖服务器则将之与集成在数据库中，大量的数据流动为维护和编程带来了极大的困难，而且，其中包含的事务处理原则不能与其它应用共享。
三层结构方案是指由用户接口层、事务处理原则层和数据层的应用模型。与传统的两层结构相比，它有着更多的优点：
1).对应用结构任意一层做出修改时，只对其它层产生极小的影响。
2).固有的可塑性，三层既可共存于单机之中，也可根据需要相互分开。
3).公用代码数据库使事务处理规则在系统中共享。
3.采用面向对象技术设计系统的步骤
a. 描述系统需求；
b. 根据需求建立系统的静态模型，以构造系统的结构；
（――以上两步建立的模型都是静态的，包括用例图、类图（包括包）、对象图、组件图和配置图，是UML的静态建模机制。）
c. 描述系统的行为；
（――所建立的模型或者可以执行，或者表示执行时的时序状态或交互关系。它包括状态图、活动图、顺序图和合作图等4个图形，是UML的动态建模机制。）
需求分析阶段――可以用用例图来捕获用户需求。通过用例建模，描述对系统感兴趣的外部角色及其对系统（用例）的功能需求。
系统分析阶段（概要设计）――主要关心问题领域中的主要概念（如抽象、类和对象等）和机制，需要识别这些类一起它们相互间的关系，并用UML类图来描述。为实现用例、类之间的协作，可以用UML动态模型来描述。在此阶段，只对问题域的对象（现实世界的概念）建模，而不考虑定义软件系统中技术细节的类（如处理用户接口、数据库、通信和并行等问题的类）
系统设计阶段（详细设计）――为构造阶段提供更详细的规格说明。
4.Rose概述
Rose模型的四个视图是Use Case视图 、Logical视图、Component视图和Deployment视图。每个视图针对不同对象，具有不同用途。Use Case视图包括系统中的所有角色、案例和Use Case图，还包括一些Sequence图和Collaboration图。
Logical视图关注系统如何实现使用案例中提到的功能。它提供系统的详细图形，描述组件间如何关联。除其它内容之外，Logical视图还包括需要的特定类、Class图和State Transition 图。利用这些细节元素，开发人员可以构造系统的详细设计。
Component视图包括模型代码库、执行库和其它组件的信息。组件是代码的实际模块。Component视图的主要用户是负责控制代码和编译部署应用程序的人。有些组件是代码库，有些组件是运行组件，如执行文件或动态链接库（DLL）文件。
Collaboration图关注系统的部署，可能与系统的逻辑结构不同。整个小组都用Collaboration图了解系统部署，但用户是发布应用程序的人员。
Rose的九种图
用例图use case diagram，描述系统功能
类图class diagram，描述系统的静态结构
对象图object diagram，描述系统在某个时刻的静态结构
序列图sequence diagram，按时间顺序描述系统元素间的交互
协作图Collaboration diagram，按照时间和空间顺序描述系统元素间的交互和它们之间的关系
状态图state diagram，描述了系统元素的状态条件和响应
活动图activity diagram，描述了系统元素的活动
组件图component diagram，描述了实现系统的元素的组织
配置图deployment diagram，描述了环境元素的配置，并把实现系统的元素映射到配置上
根据它们在不同架构视图的应用，可以把9种图分成：
用户模型视图：用例图
结构模型视图：类图、对象图
行为模型视图：序列图、协作图、状态图、活动图（动态图）
实现模型视图：组件图
环境模型视图：配置图
UML建模过程笔记
首先，要区别视图和图的区别，视图是由很多图组成的，不同的视图可以用来描述同一系统的不同方面，从而更好的来描述系统。而图是由各种图片组成的，可用来组成视图
视图包含：用例视图(Use-case View)
逻辑视图(Logical View
组件视图(Component View)
并发视图(Concurrency View)
展开视图(Deployment View)等等。
图包含：用例图――1
类图
对象图
状态图（侧重对象状态的描述）――2
序列图（侧重于交互的时间顺序的描述）
协作图（侧重于涉及到的对象空间关系的描述）
活动图（侧重于交互动作的描述）――3
组件图
展开图
描述用例内容的一般是用例图和活动图（比较正式的结构）
UML中实现用例的基本思想是用协作来表示用例，而协作又被细化为若干个图（协作图、序列图、活动图），通过描述类、对象之间的关系来描述交互功能。
类图是构建其它图的基础，没有类图就没有状态图、协作图等其他图，也就无法表示系统的其它各个方面。类与类之间的关系有关联、通用化（继承）、依赖、精化。
关联：描述类与类之间的连接，即“彼此知道，相互通信”；
含：普通、递归、限定、或、有序、三元、聚合等七种
一.常用的分析工具：
测试工具：ATTOL UniTest、Ｃ++ Test、MTE、CodeTest;
覆盖率：ATTOL Coverage、PureCoverage、TrueCoverage;
内存检测：Boundschecker、PURIFY;
静态分析（结构）：Mccable、Logiscope、Hindsight;
静态分析（语法）：PC-lint、CodeCHK、CheckMate;
WEB压力测试：Web Express;
设计工具：UML、Rose、Visio、PowerDesigner;
编程工具：SourceInsight；
版本控制：VSS、Beyond Company
二.软件工程文档和方法：
(一)传统软件工程（瀑布模型）
1.问题定义
讨论要解决的问题，做一份书面报告即可。
2.可行性研究
研究问题的范围，探索这个问题是否值得去研究。
需要做的主要工作有：
a. 导出问题定义阶段的高层逻辑模型（通常用数据流图表示[1]），物理系统也可以用系统流程图表示），如有需要须初步定义一些数据字典[2]；
b. 并且做成本/效益分析。
3.需求分析
确定目标系统必须具备哪些功能。必须准确完整的提出系统逻辑模型。
需要做的主要工作有：
a. 划分出系统必须完成的所有功能；
这部分包含需要将功能用文字表达出来，可用层次方框图和Warnier图。在描述模型之间的关系时，可用ER模型来表示，再用范式来消除冗余。
b. 根据以上结果导出系统详细的逻辑模型可用数据流图、数据字典和主要处理算法描述（这个主要处理算法可用IPO图来画）
4.总体设计（概要设计）
划分出组成系统的物理元素――程序、文件、数据库、人工过程和文档等。设计软件的总体结构，确定系统中每个程序由哪些模块组成，以及这些模块相互间的关系。
需要做的主要工作有：
a. 功能分解；
这部分工作含结构设计（主要是模块的划分，可用层次图或结构图描述，可用数据流图来分析）和过程设计（每个模块的处理过程，可用IPO图）
b. 如有数据库，则需进行数据库设计和优化。（推荐使用PowerDesigner）
c. 制订测试计划
5.详细设计
将每个模块中的处理过程细化。
需要做的主要工作有：
a. 描述模块中处理过程；
可用程序流程图、盒图、PAD图、判定表、判定图，或者用伪代码来表示（可用Visio来作图）,可描述其中的复杂度。
6.编码与单元测试
编码（略）。
测试：黑盒测试――功能测试；白盒测试――结构测试；
单元测试即模块测试，在这个测试步骤中所发现的往往是编码和详细设计的错误。
需要做的主要工作有：
a.编写测试案例文档
7.综合测试
编写测试案例和文档
8.软件维护
(二) 面向对象的方法
1.概念和摘要
瀑布式生命周期的缺点表现在三个方面：<1> 后期的变化、迭代、改动困难 <2> 不支持重用 <3> 没有一个联系各个阶段的统一模型。
使用面向对象方法学开发软件时，工作重点应该放在生命周期中的分析阶段。通常需要建立三种形式的模型，分别时描述系统数据结构的对象模型，描述系统控制结构的动态模型和描述系统功能的功能模型，所以核心是建立对象模型――面向对象的建模（当前常用的建模语言是UML）。
在面向对象分析过程（OOA）中，构造出完全独立于实现的应用域模型（需求分析）；在面向对象设计过程(OOD)中，把求解域的结构逐渐加入到模型中（概要设计和详细设计）；在实现阶段，把应用域和求解域的结构都编成程序代码并进行严格的测试验证(编码测试)。测试一个OO系统是另一个需要进一步研究的课题。发布一个稳定的原型需要不同与以往控制结构化开发的产品的配置管理。
为改善面向对象开发的可管理性，玻姆(Boehm,1988)提出了一个结合了宏观和微观视角(macro & microview)的螺旋开发模型。宏观包括3个阶段：1分析---发现和识别对象；2 设计---发明和设计对象；3 实施---创建和实现对象。每个宏观阶段都包含一些微观迭代活动。
无论何种复杂程度的工程项目，设计都是从建模开始的，设计者通过创建模型和设计蓝图来描述系统的结构。(Rational Rose)
2.设计的三层结构
客户机/服务器体系结构的广泛使用预示了系统复杂化的发展趋势，为了解决这一问题，与之相应的三层结构方案(three-tiered)越来越得到了广泛的应用。
传统的两层结构不是“胖客户机”就是“胖服务器”，胖客户机结构将事务处理原则在用户端处理，胖服务器则将之与集成在数据库中，大量的数据流动为维护和编程带来了极大的困难，而且，其中包含的事务处理原则不能与其它应用共享。
三层结构方案是指由用户接口层、事务处理原则层和数据层的应用模型。与传统的两层结构相比，它有着更多的优点：
1).对应用结构任意一层做出修改时，只对其它层产生极小的影响。
2).固有的可塑性，三层既可共存于单机之中，也可根据需要相互分开。
3).公用代码数据库使事务处理规则在系统中共享。
3.采用面向对象技术设计系统的步骤
a. 描述系统需求；
b. 根据需求建立系统的静态模型，以构造系统的结构；
（――以上两步建立的模型都是静态的，包括用例图、类图（包括包）、对象图、组件图和配置图，是UML的静态建模机制。）
c. 描述系统的行为；
（――所建立的模型或者可以执行，或者表示执行时的时序状态或交互关系。它包括状态图、活动图、顺序图和合作图等4个图形，是UML的动态建模机制。）
需求分析阶段――可以用用例图来捕获用户需求。通过用例建模，描述对系统感兴趣的外部角色及其对系统（用例）的功能需求。
系统分析阶段（概要设计）――主要关心问题领域中的主要概念（如抽象、类和对象等）和机制，需要识别这些类一起它们相互间的关系，并用UML类图来描述。为实现用例、类之间的协作，可以用UML动态模型来描述。在此阶段，只对问题域的对象（现实世界的概念）建模，而不考虑定义软件系统中技术细节的类（如处理用户接口、数据库、通信和并行等问题的类）
系统设计阶段（详细设计）――为构造阶段提供更详细的规格说明。
4.Rose概述
Rose模型的四个视图是Use Case视图 、Logical视图、Component视图和Deployment视图。每个视图针对不同对象，具有不同用途。Use Case视图包括系统中的所有角色、案例和Use Case图，还包括一些Sequence图和Collaboration图。
Logical视图关注系统如何实现使用案例中提到的功能。它提供系统的详细图形，描述组件间如何关联。除其它内容之外，Logical视图还包括需要的特定类、Class图和State Transition 图。利用这些细节元素，开发人员可以构造系统的详细设计。
Component视图包括模型代码库、执行库和其它组件的信息。组件是代码的实际模块。Component视图的主要用户是负责控制代码和编译部署应用程序的人。有些组件是代码库，有些组件是运行组件，如执行文件或动态链接库（DLL）文件。
Collaboration图关注系统的部署，可能与系统的逻辑结构不同。整个小组都用Collaboration图了解系统部署，但用户是发布应用程序的人员。
Rose的九种图
用例图use case diagram，描述系统功能
类图class diagram，描述系统的静态结构
对象图object diagram，描述系统在某个时刻的静态结构
序列图sequence diagram，按时间顺序描述系统元素间的交互
协作图Collaboration diagram，按照时间和空间顺序描述系统元素间的交互和它们之间的关系
状态图state diagram，描述了系统元素的状态条件和响应
活动图activity diagram，描述了系统元素的活动
组件图component diagram，描述了实现系统的元素的组织
配置图deployment diagram，描述了环境元素的配置，并把实现系统的元素映射到配置上
根据它们在不同架构视图的应用，可以把9种图分成：
用户模型视图：用例图
结构模型视图：类图、对象图
行为模型视图：序列图、协作图、状态图、活动图（动态图）
实现模型视图：组件图
环境模型视图：配置图
UML建模过程笔记
首先，要区别视图和图的区别，视图是由很多图组成的，不同的视图可以用来描述同一系统的不同方面，从而更好的来描述系统。而图是由各种图片组成的，可用来组成视图
视图包含：用例视图(Use-case View)
逻辑视图(Logical View
组件视图(Component View)
并发视图(Concurrency View)
展开视图(Deployment View)等等。
图包含：用例图――1
类图
对象图
状态图（侧重对象状态的描述）――2
序列图（侧重于交互的时间顺序的描述）
协作图（侧重于涉及到的对象空间关系的描述）
活动图（侧重于交互动作的描述）――3
组件图
展开图
描述用例内容的一般是用例图和活动图（比较正式的结构）
UML中实现用例的基本思想是用协作来表示用例，而协作又被细化为若干个图（协作图、序列图、活动图），通过描述类、对象之间的关系来描述交互功能。
类图是构建其它图的基础，没有类图就没有状态图、协作图等其他图，也就无法表示系统的其它各个方面。类与类之间的关系有关联、通用化（继承）、依赖、精化。
关联：描述类与类之间的连接，即“彼此知道，相互通信”；
含：普通、递归、限定、或、有序、三元、聚合等七种