高级软件工程笔记

软件系统
支撑软件（Support Software）：软件系统的中间层，支撑各种软件的开发、运行与维护的软件。
系统软件（System Software System Software）：最靠近计算机硬件的 最靠近计算机硬件的一层软件 —— 控制和协调计算机及外部设备、支持应用软件开发与运行的软件。
支撑软件（Support Software）：软件系统的中间层，支撑各种软件的开发、运行与维护的软件。


软件工程（Software Engineering Software Engineering）：研究或应用工程化方法来设计、创造、构建和维护有效、实用和高质量软件的一门学科。

软件危机:对软件开发工作量和成本估计不准；软件开发进度难以控制；软件产品质量与可靠性差强人意

软件工程技术主要发展趋势
软件需求工程 （Requirement Engineering）—— 基于知识的软件需求分析、需求分析自动化
中间件（Middleware Middleware）技术—— 中间件平台、企业服务总线ESB、网络构件、基于中间件的软件集成技术
软件质量保障 —— 软件质量评测与度量、软件可靠性技术、软件 程过 改进模
软件领域化 —— 领域软件工程（ Domain Engineering）、行业应用软件、企业应用软件

程序的本质是组合、抽象与构造
构造的基本手段是迭代和递归。递归是一种表达相似性对象及动作的重复性无限性构造的重要思想

程序:由基本动作指令构造的，若干指令的一个组合或一个执行序列，用以实现复杂动作
指令：控制基本动作执行的命令

计算系统 = 基本动作 + 指令 + 程序执行机构

递归是表达相似性对象及动作的无限性重复性构造的方法
定义：递归是一种关于抽象的表达方法---用递归定义无限的相似事物
构造：递归是一种算法或程序的构造技术---自身调用自身，高阶调用低阶，构造无限的计算步骤
递归执行：递归是一种典型的计算/执行过程---由后向前代入，直至代入到递归基础，再由递归基础向后计算直至计算出最终结果，即由前向后计算

程序应该正确、有效、易理解、简单、自然、可拓展、可伸缩
程序设计语言是：人与计算机通信的最基本工具。语法+语义+语用

结构化程序设计原则
简单结构，尽量使用语言提供的基本控制结构，即顺序结构、选择结构和重复（循环）结构
组合嵌套，复杂结构应该用基本控制结构组合或嵌套实现
一致性，语言中没有的控制结构，可用一段等价的程序段模拟，但要求该程序段在整个系统中应前后一致
块机制，将程序组织成容易识别的块，每块只有一个入口和一个出口
严格控制GOTO语句

自顶向下，先考虑总体，后考虑细节；先考虑全局目标，后考虑局部目标
逐步细化，对于复杂问题，进行分解为子目标。
模块化，再将子目标分解为小目标，予以结构化实现

程序设计风格—重用性要求
可重复使用的、功能相对独立的算法或接口。应该考虑封装成公共的控件或类
相对固定和独立的程序实现方式和过程，应考虑做成程序模板，增强对程序实现方式的复用


程序的效率：程序的执行速度及程序所需占用的存储空间
效率的影响因素
算法，源程序的效率与详细设计阶段确定的算法的效率直接有关
存储器，大中型计算机系统,存储限制不是主要问题。在微型计算机系统，存储容量对软件设计和编码的制约很大
输入/输出

面向对象程序设计

含义，面向对象程序设计是以建立模型体现出来的抽象思维过程和面向对象的方法。
方法，选择程序设计语言、类的实现、方法的实现、用户接口的实现等
主要概念，对象、类、数据抽象、继承、动态绑定、数据封装、多态性、消息传递。

编码策略
自顶向下，从模块的最高层次逐步向下编码
复合模式，自顶向下与自底向上相结合，可以先总体界面、交互，到基础模块
自底向上，从类继承的底层开始向上编码
线程模式，线程：执行关键功能的最小模块集合先线程，级关键构建，后其他模块


算法是软件的灵魂
算法是一个有穷规则的集合，它用规则规定了解决某一特定类型问题的运算序列，或者规定了任务执行或问题求解的一系列步骤。

计算学科算法的基本特征
有穷性：一个算法在执行有穷步规则之后必须结束
确定性：算法的每一个步骤必须要确切地定义，不得有歧义性。
输入：算法有零个或多个的输入
输出：算法有一个或多个的输出/结果，即与输入有某个特定关系的量。
能行性：算法中有待执行的运算和操作必须是相当基本的(可以由机器自动完成)，并能在有限时间内完成

问题求解第一步--数学建模
TSP问题(Traveling Salesman Problem，旅行商问题)
有若干城市，任何两个城市之间的距离都是确定的，现要求一旅行商从某城市出发必须经过每一城市且只能在每个城市逗留一次，最后回到原出发城市，问如何事先确定好一条最短的路线使其旅行的费用最少。
TSP是最有代表性的组合优化问题之一，在半导体制造(线路规划)、物流运输(路径规划)等行业有着广泛的应用
第二步，算法策略设计
遍历算法
贪心算法，每次在选择下一个城市的时候，只考虑当前情况，保证迄今为止经过的路径总距离最短
第三步，算法思想的精确表达
算法的数据结构设计---问题或算法相关的数据之间的逻辑关系及存储关系的设计
    数据结构是数据的逻辑结构、存储结构及其操作的总称，它提供了问题求解/算法的数据操纵机制
算法的控制结构设计---算法的计算规则或计算步骤设计
    顺序结构，分支结构，循环结构


软件过程
软件生命周期，软件产品或软件系统从设计、投入使用到被淘汰的全过程
软件过程是在工作产品构建过程中，所需完成的工作活动、动作和任务的集合
    活动主要实现宽泛的目标，与应用领域、项目大小、结果复杂性或者实施软件工程的重要程度没有直接关系
    动作包含了主要工作产品生产过程中的一系列任务
    任务关注小而明确的目标，能够产生实际产品。
软件过程模型：是软件开发全部过程、活动和任务的结构框架。它能直观表达软件开发全过程，明确规定要完成的主要活动、任务和开发策略。
软件过程评估：能力成熟度模型CMM

传统软件过程模型
瀑布模型
实际（带反馈）的瀑布模型
瀑布模型的缺点
    增加工作量：各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量
    早期错误发现晚：早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果
    开发风险大：由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险
    不适应需求变化：不能反映实际的开发方式，软件开发需要迭代；无法适应需求不明确和需求的变化
瀑布模型适用于系统需求明确且稳定、技术成熟、工程管理较严格的场合，如军工、航天、医疗

V模型（V-model）：瀑布模型的变种

原型模型（Prototype model）
原型（prototype）一个部分开发的产品，使客户和开发人员能够对计划开发的系统的相关方面进行检查。
优点：减少需求不明确带来的风险
适用场合：客户定义一个总体目标集，但他们并不清楚系统的具体输入输出。

增量模型（Incremental model）
增量：满足用户需求的一个子集，能够完成一定功能、小而可用的软件
增量模型是一种非整体开发的模型，是一种进化式的开发过程
增量模型从部分需求出发，先建立一个不完整的系统，通过测试运行这个系统取得经验和反馈，进一步使系统扩充和完善
如此反复进行，直至软件人员和用户对所设计的软件系统满意为止
增量模型结合了原型模型的基本要素和迭代的特征，采用了基于时间的线性序
列，每个线性序列都会输出该软件的一个“增量“
每个增量的开发可用瀑布或快速原型模型
适用于软件开发中需求可能发生变化、具有较大风险、或者希望尽早进入市场的项目

螺旋模型：开发过程分成若干次迭代，每次迭代代表开发的一个阶段，对应模型中一条环线
优点
螺旋模型强调原型的可扩充性和可修改性，原型的进化贯穿整个软件生存周期，这将有助于目标软件的适应能力，支持用户需求的动态变化
原型可看作可执行的需求规格说明，易于为用户和开发人员共同理解，还可作为继续开发的基础，并为用户参与所有关键决策提供了方便
螺旋模型为项目管理人员及时调整管理决策提供了方便，进而可降低开发风险
适用于需求不明确或者需求可能发生变化的大型复杂的软件系统。

喷泉模型（Fountain model）
喷泉模型是一种以用户需求为动力，以对象为驱动的模型，主要用于描述面向对象的软件开发过程
软件开发早期定义对象，整个开发过程充实和扩充对象


现代软件过程模型
基于构件的开发模型，Component-based development
软件复用思想。
适用于系统之间有共性的情况

统一过程模型Rational Unified Process
基于面向对象方法学，使用统一建模语言UML（Unified Modeling Language）

敏捷开发过程
快速响应变化和不确定性
测试驱动开发可能导致通过测试但非用户期望；重构而不降低质量困难
适用于需求模糊且经常改变的场合，适合商业竞争环境下的项目。


如何选择软件过程模型
1.前期需求明确的情况下，尽量采用瀑布模型
2.用户无系统使用经验，需求分析人员技能不足的情况下，尽量借助原型模型
3.不确定因素很多，很多东西无法提前计划的情况下，尽量采用增量模型或螺旋模型
4.需求不稳定的情况下，尽量采用增量模型
5.资金和成本无法一次到位的情况下，可采用增量模型
6.对于完成多个独立功能开发的情况，可在需求分析阶段就进行功能并行，每个功能内部都尽量遵循瀑布模型
7.全新系统的开发必须在总体设计完成后再开始增量或并行
8.编码人员经验较少的情况下，尽量不要采用敏捷或迭代模型
9.增量、迭代和原型可以综合使用，但每一次增量或迭代都必须有明确的交付和出口原则



需求分析的概念
确定系统必须具有的功能和性能。
需求获取
需求分析：对应用问题及环境的理解和分析，为问题涉及的信息、功能及系统行为建立模型。将用户需求精确化、完全化，最终形成下一步的需求规格说明书。
软件需求规格说明书（SRS）------软件系统的需求规格说明，是对待开发系统的行为的完整描述。它包含了功能性需求和非功能性需求。

需求验证的工作
对需求文档需执行以下类型的检查：
（1）有效性检查
检查不同用户使用不同功能的有效性。
（2）一致性检查
在文档中，需求之间不应该冲突。
（3）完备性检查
需求文档应该包括所有用户想要的功能和约束。
（4）现实性检查
检查保证能利用现有技术实现需求

需求验证技术
（1）需求评审
（2）利用原型检验系统是否符合用户的真正需要
（3）对每个需求编写概念性的测试用例。
（4）编写用户手册。用浅显易懂的语言描述用户可见的功能。
（5）自动的一致性分析。可用CASE工具检验需求模型的一致性

需求分析的任务
建立分析模型：准确地定义未来系统的目标，确定为了满足用户的需求系统必须做什么
编写需求说明:用《需求规格说明书》规范的形式准确地表达用户的需求。

需求分析模型
面向过程分析模型:其基本思想是用系统工程的思想和工程化的方法，根据用户至上的原则，自始自终按照结构化、模块化，自顶向下地对系统进行分析与设计
面向对象分析模型由5个层次（主题层、对象类层、结构层、属性层和服务层）和5个活动（标识对象类、标识结构、定义主题、定义属性和定义服务）组成。


面向过程分析模型——结构化分析方法
面向数据流进行需求分析的方法
结构化分析方法适合于数据处理类型软件的需求分析
具体来说，结构化分析方法就是用抽象模型的概念，按照软件内部数据传递、变换的关系，自顶向下逐层分解，直到找到满足功能要求的所有可实现的软件为止

数据流图的层次结构
在多层数据流图中，顶层流图仅包含一个加工，它代表被开发系统。它的输入流是该系统的输入数据，输出流是系统所输出数据
中间层流图则表示对其上层父图的细化。它的每一加工可能继续细化，形成子图
底层流图是指其加工不需再做分解的数据流图，它处在最底层

加工表示对数据进行的操作, 如“处理选课单” 、“产生发票”等
外部实体（数据源点/终点）位于系统之外的信息提供者或使用者,称为外部实体。即存在于系统之外的人员或组织。如“学务科”等
数据流表示数据和数据流向, 由一组固定成分的数据组成 如“选课单”由“学号、姓名、课程编号、课程名”等成分组成,数据流可从加工流向加工，也可在加工与数据存储或外部项之间流动；两个加工之间可有多股数据流
数据存储表示需要保存的数据流向, 如“ 学生档案”、“课程设置”等


检查数据流图的原则
1）数据流图上所有图形符号只限于前述四种基本图形元素
2）数据流图的主图必须包括前述四种基本元素，缺一不可
3）数据流图的主图上的数据流必须封闭在外部实体之间
4）每个加工至少有一个输入数据流和一个输出数据流
5）在数据流图中，需按层给加工框编号。编号表明该加工所处层次及上下层的亲子关系
6）规定任何一个数据流子图必须与它上一层的一个加工对应，两者的输入数据流和输出数据流必须一致。此即父图与子图的平衡
7）图上每个元素都必须有名字
8）数据流图中不可夹带控制流
9）初画时可以忽略琐碎的细节，以集中精力于主要数据流


功能建模——编写数据字典，写出系统需求规格说明书，提交审查，并编写测试验收计划、编写初步的用户手册概要。


面向对象的软件开发模型
数据模型（对象模型）:描述系统数据结构的对象模型;
行为模型（动态模型）描述系统控制结构
功能模型:描述系统功能
一个典型的软件系统使用数据结构（对象模型），执行操作（动态模型），并且完成数据值的变化（功能模型）

软件评估
组织分析：掌握目标单位的组成构成
业务分析：以客户为中心，进行业务描述，遵循由粗到细的建模步骤，以岗位为最基本的构成单位，以岗位职责为最基本活动元素，建模业务流程，无须考虑流程中可能出现的异常情况和错误，可以在业务流程中反映相关的数据处理和变换
可行性分析：可行性的目的不是要解决问题，而是确定问题是否值得去解决，用最小的代价在尽可能短的时间内确定问题是否能够解决



总体设计——又称为概要设计或初步设计。
总体设计的任务是进行系统设计和结构设计。
系统设计划分出组成系统的物理元素——程序、文件、数据库、人工过程和文档等等，但是每个物理元素仍然处于黑盒子级，这些黑盒子里的具体内容将在详细设计阶段完成。
结构设计就是要确定系统中每个程序是由哪些模块组成的，以及这些模块相互间的关系

人类在认识复杂现象的过程中使用的最强有力的思维工具是抽象。
1）抽象：就是抽出事物的本质特性而暂时丌考虑它们的细节。
处理复杂系统的惟一有效的方法是用层次的方式构造和分析它。
一个复杂的动态系统首先可以用一些高级的抽象概念构造和理解，这些高级概念又可以用一些较低级的概念构造和理解，如此下去，直至最低层次的具体元素以某种方式对应于程序的一组成分
2）可行性分析：把需要解决问题抽象为一个解，探索是否有可行的解决方法。

需求分析：把需要解决的解抽象成功能；
总体设计：把系统抽象为结构；
详细设计：把结构抽象为每个模块的处理过程；
编码阶段：把处理过程抽象为机器能够执行的程序，
当源程序写出来以后，也就达到了抽象的最低层


信息隐藏原理
设计和确定模块，使得一个模块内包含的信息(过程和数据)对于不需要这些信息的模块来说，是不能访问的。
局部化
把一些关系密切的软件元素物理地放得彼此靠近。局部化有助于实现信息隐藏。

模块独立性：每个模块完成一个相对独立的特定子功能，并且和其它模块之间的关系(或接口)很简单。
模块独立的概念是：模块化、抽象、信息隐藏和局部化概念的直接结果。

数据耦合当一个模块调用另一模块时，被调用模块的输入、输出都是简单的数据
特征耦合：当一个模块调用另一个模块时传递了整个数据结构,而被调用的模块只需要其中的一部分数据元素。
控制耦合：一模块向下属模块传递的信息，控制了被调用模块的内部逻辑。
外部耦合：一组模块均不同一外部环境关联，并受到约束时，它们之间便存在外部耦合。
公共耦合：一组模块引用同一个公共数据区。
内容耦合：如果两个模块中的一个模块直接引用了另一个模块的内容,则它们之间是内容耦合

内聚：衡量一个模块内部各个元素彼此结合的紧密程度。
偶然内聚：如果一个模块完成一组任务，这些任务彼此间即使有关系，关系也是很松散的，就叫做偶然内聚。
逻辑内聚：如果一个模块完成的任务在逻辑上属于相同或相似的一类，则称为逻辑内聚。
时间内聚：如果一个模块包含的任务必须在同一段时间内执行，就叫时间内聚
过程内聚：如果一个模块内的处理元素是相关的，而且必须以特定次序执行，则称为过程内聚。
通信内聚：如果模块中所有元素都使用同一个输入数据和(或)产生同一个输出数据，则称为通信内聚
顺序内聚：如果一个模块内的处理元素和同一个功能密切相关，而且这些处理必须顺序执行(通常一个处理元素的输出数据作为下一个处理元素的输入数据)，则称为顺序内聚。
功能内聚：如果模块内所有处理元素属于一个整体，完成一个单一的功能，则称为功能内聚。功能内聚是最高程度的内聚




好的设计应该具有如下三个特点
设计必须实现在分析模型中包含的所有明确要求，必须满足客户所期望的所有隐含要求；
设计必须对编码人员、测试人员及后续的维护人员是可读可理解的；
设计应提供该软件的完整视图，从实现的角度解决数据、功能及行为等各领域方面的问题


设计相关概念：
抽象
体系结构，软件的整体结构和这种结构为系统提供概念上完整性的方式
设计模式，在给定上下文环境中一类共同问题的共同解决方案
模块化，软件被划分为命名和功能相对独立的多个组件（通常称为模块），通过这些组件的集成来满足问题的需求
信息隐藏，模块应该具有彼此相互隐藏的特性，即：模块定义和设计时应当保证模块内的信息（过程和数据）不可以被不需要这些信息的其他模块访问
功能独立，每个模块只负责需求中特定的子功能，并且从程序结构的其他部分看，该模块具有简单的接口
精化，逐步求精的过程
重构，不改变组件功能和行为条件下，简化组件设计（或代码）的一种重组技术

四类设计技术
数据设计（有时也被称为数据架构）构建高层抽象（客户/用户的数据视图）的数据模型、信息模型体系结构设计
部署设计，部署环境包含整个解决方案的逻辑架构和服务质量（QoS）需求
接口设计（含界面设计）：允许用户操作控制（用户为中心），减少用户记忆负担，保持界面一致
组件设计：面向过程的组件设计-函数与模块的设计，面向对象的组件设计-类与操作的设计


变换分析
事务分析
混合结构分析：我们通常利用以变换分析为主、事务分析为辅的方式进行软件结构设计


面向对象设计活动之一：架构设计
第1步：构造系统的物理模型
第2步：设计子系统
第3步：非功能需求设计


软件测试策略
单元测试、系统测试、验收测试
黑盒（等价类、边界值）、白盒、条件覆盖、语句覆盖、


软件项目管理的定义
是为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对人员（People）、产品（Product）、过程（Process）和项目(Project)进行分析和管理的活动。
4P要素：人员、产品、过程、项目

软件逆向工程Software Reverse Engineering
是分析目标系统，识别系统的构件及其交互关系，并且通过高层抽象或其他形式来展现目标系统的过程
对逆向工程而言，抽象的层次、完备性、工具与分析人员协同工作的程度、过程的方向性等因素是需要考虑的