软件的概念：
一个软件包含下面三个部分：
1、指令的集合，通过执行这些指令可以满足预期的特征、功能和性能需求；
2、数据结构，使得程序可以合理利用信息；
3、软件描述信息，它以硬拷贝和虚拟形式存在，用来描述程序操作和使用。
软件工程的概念：
1、将系统化的、规范化、可量化的方法应用于软件的开发、运行和维护，即将工程化方法应用于软件。
2、在1中所述方法的研究。
软件和硬件的区别：
1、软件是设计开发的，而不是传统意义上生产制造的。
2、软件不会“磨损” 。
3、大多数软件根据实际的顾客需求定制的。
支持软件工程的根基在于质量关注点（quality focus）， 是对软件的组织承诺，是支持软件工程的基石；
软件工程的基础是过程（process）层。软件过程将各个技术层次结合在一起，使得合理、及时地开发计算机软件成为可能；
软件工程方法（method）为构建软件提供技术上的解决方法。方法包括：沟通、需求分析、设计模型、编程、测试和技术支持。
软件过程：
软件过程是工作产品构建时所执行的一系列活动、动作和任务的集合。
Generic Framework Activity （通用框架活动）：
适用于所有软件项目，无论其规模和复杂程度如何。
1、沟通（Communication）：目的是理解利益相关者的项目目标，并收集需求以定义软件特性和功能。
2、策划（Planning）：定义和描述了软件工程工作，包括需要执行的技术任务、可能的风险、资源需求、工作产品和工作进度计划。
3、建模（Modeling）：利用模型哎更好地理解软件需求并完成符合这些需求的软件设计。
4、构建（Construction）：它包括编码和测试以发现编码中的错误。
5、部署（Deployment）：软件交付到用户，用户对其进行评测并给出反馈意见。
Umbrella Activities（普适性活动）：
普适性活动贯穿软件项目始终。
1、软件项目跟踪和控制：项目根据计划评估项目进度，并且采取必要的措施保证项目按进度计划进行。
2、风险管理：对可能影响项目成果或者产品质量的风险进行评估。
3、软件质量保证：确定和执行软件质量保证的活动
4、技术评估：评估软件工程产品、尽量在错误传播到下一个活动之前，发现并清除错误。
5、测量：定义和收集过程、项目和产品的度量，以帮助团队在发布软件的时候满足利益相关者要求。同时，测量还可以与其他框架活动和普适性活动配合使用。
6.软件配置管理：在整个软件工程中，管理变更所带来的影响。
7.可复用管理：定义产品复用的标准，并且建立构建复用机制。
8.工作产品的准备和生产：包括了生产产品所必需的活动。
软件的生命周期：
软件生命周期又称为软件生存周期或系统开发生命周期，是软件的产生直到报废的生命周期。
软件生存周期包括：
1、问题定义：弄清"用户需要计算机解决什么样的问题”，提出"系统目标和范围的说明“，提交用户审查和确认。
2、可行性分析：把待开发系统的目标以明确的语言描述出来，并从经济、技术、法律等多个方面进行可行性分析。
3、需求分析：弄清用户对软件系统的全部需求，编写需求规格说明书和初步的用户手册，提交评审。
4、开发阶段：设计、实现（完成源程序的编码）、测试
5、维护：改正性维护（由于开发测试的不彻底、不完全），适应性维护（适应环境变化），完善性维护（使用过程中提出的一些建设性意见），预防性维护（改善软件系统的可维护性和可靠性）。
软件过程：
指软件生命周期所涉及的一系列相关过程，是指一套关于项目的阶段、状态、方法、技术和开发、维护软件的人员以及相关Artifacts（计划、文档、模型、编码、测试、手册等）组成。包含基本过程类、支持过程类、组织过程类。
1、基本过程类包括获取过程、供应过程、开发过程、运作过程、维护过程和管理过程。
2、支持过程类包括文档过程、配置管理过程、质量保证过程、验证过程、确认过程、联合评审过程、审计过程以及问题解决过程。
3、组织过程类包括基础设施过程、改进过程、培训过程。
软件过程模型：
过程模型总共分为三大类：
1、惯例过程模型：
瀑布模型(又叫作生命周期模型)；
增量过程模型: 包括增量模型、RAD模型；
演化过程模型: 包括原型开发模型、螺旋模型、协同开发模型；
专用过程模型: 包括基于构件的开发模型、形式化方法模型、面向方面的软件开发模型。
2、面向对象模型：
喷泉模型；
可重用部件组装模型。
3、敏捷过程模型：
XP模型；
自适应软件开发；
动态系统开发；
Scrum模型；
Crystal模型；
特征驱动开发；
敏捷建模。
常见软件工程模型：
瀑布模型：
将软件生命周期中的各个活动规定为线性连接的模型，包括需求分析、设计、编码、测试、运行与维护，由前至后、相互衔接的固定顺序，如同瀑布流水逐级下落。
瀑布模型是以文档作为驱动、适合于软件需求很明确的软件项目的模型。
V模型：
瀑布模型的一个变体，提供了一种验证确认活动应用于早期软件工程工作中的方法。
瀑布模型的优点：
容易理解，管理成本低；
强调开发的阶段性早期计划及需求调查和产品测试。
瀑布模型的缺点：
客户必须能够完整、正确和清晰地表达他们的需要；
开始2个或3个阶段，很难评估真正的进度；
项目结束时，出现大量的集成和测试工作；
需求或设计中的错误往往只有到了项目后期才能够被发现，对于项目风险的控制能力较弱，从而导致项目常常延期完成，开发费用超出预算。
增量模型：
融合了瀑布模型的基本成分和原型实现的迭代特征，它假设可以将需求分段为一系列增量产品，每一增量可以分别开发。
使用增量模型，第1个增量往往是核心的产品。客户对每个增量的使用和评估都作为下一个增量发布的新特征和功能，这个过程在每一个增量发布后不断重复，直到产生了最终的完善产品。增量模型强调每一个增量均发布一个可操作的产品。
增量模型的优点：
容易理解，管理成本低；
强调开发的阶段性早期计划及需求调查和产品测试；
第一个可交付版本所需要的成本和时间很少；
开发由增量表示的小系统所承担的风险不大；减少用户需求的变更；
运行增量投资，即在项目开始时，可以仅对一个或两个增量投资。
增量模型的缺点：
如果没有对用户的变更需求进行规划，那么产生的初始增量可能会造成后来增量的不稳定；
如果需求不想早期思考的那样稳定和完整，那么一些增量就可能需要重新开发，重新发布；
管理发生的成本、进度和配置的复杂性可能会超出组织的能力。
演化模型：
是迭代的过程，软件开发人员能逐步开发出更完整的软件版本，适用于软件需求缺乏准确认识的情况，典型的演化模型有原型模型和螺旋模型。
1、演化模型之原型模型：
是预期系统的一个可执行版本，反映了系统性的一个选定的子集，一个原型不必满足目标软件的所有约束，目的是能快速、低成本地构建原型。
原型模型开始于沟通，其目的是定义软件的总体目标，标识需求，然后快速制定原型开发的计划，确定原型的目标和范围，采用快速射击的方式对其进行建模，并构建原型。
根据原型的目的，可分为三种：
探索型原型：
目的是弄清目标的要求，确定所希望的特性，并探讨多种方案的可行性。
实验型原型：
目的是验证方案或算法的合理性，是在大规模开发和实现前，用于考查方案是否合适、规格说明是否可靠等。
演化型原型：
目的是将原型作为目标系统的一部分，通过对原型的多次改进，逐步将原型演化成最终的目标系统。
2、演化型模型之螺旋模型：
将瀑布模型与演化模型结合起来，加入了两种模型均忽略的风险分析，弥补了这两种模型的不足。
螺旋模型将开发过程分为几个螺旋周期，每个螺旋周期大致和瀑布模型相符合：
制定计划：确定软件的目标，选定实施方案，明确项目开发的限制条件。
风险分析：分析所需的方案，识别风险，消除风险。
实施工程：实施软件开发，验证阶段性产品。
用户评估：评价开发工作，提出修正建议，建立下一个周期的开发计划。
螺旋模型强调风险分析，使得开发人员和用户对每个演化层出现的风险有所了解，从而做出应有的反应。因此，该模型特别适用于庞大、复杂并且具有高风险的系统。
螺旋模型和瀑布模型比较：
螺旋模型支持用户需求动态变化，为用户参与软件开发的所有关键决策提供了方便，有助于提高软件的适应能力，并且为项目管理人员及时调整管理决策提供了便利，从而降低了软件开发的风险。在使用螺旋模型进行软件开发时，需要开发人员具有相当丰富的风险评估经验和专门知识。另外，过多的迭代次数会增加开发成本，延迟提交时间。
协同模型：
有时候又称为协同工程，它允许软件团队表述本章所描述的任何模型中的迭代和并发元素。 协同建模提供了项目当前状态的准确画面。 适合所有类型的软件开发，协同模型通常更适合涉及不同工程团队的产品工程项目。
统一过程模型：
统一过程模型是一种“用例驱动、以体系结构为核心、迭代及增量”的软件 过程框架，由 UML 方法和工具支持。
它是一种增量模型，定义了五个阶段：
起始阶段，包括用户沟通和计划活动，强调定义和细化用例；
细化阶段，包括用户沟通和建模活动，重点是创建分析和设计模型；
构件阶段，细化模型设计，并将设计模型转化为软件构件实现；
转化阶段，将软件从开发人员传递给最终用户，并由用户完成 beta 测试和验收测试；
生产阶段，持续地监控软件的运行，并提供技术支持。
统一过程模型的优点：
任何功能开发后就进入测试过程，及早进行验证；
早期风险识别，采取预防措施。
统一过程模型的缺点：
需求必须在开始之前完全弄清楚，否则有可能在架构上出现错误；
必须有严格的过程管理，以免使过程退化为原始的试→错→改模式；
如果不加控制的让用户过早接触没有测试完全，版本不稳定的产品可能对用 户和开发团队都带来负面的影响。
喷泉模型：
一种以用户需求为动力，以对象作为驱动的模型，适合于面向对象的开发方法。它克服了瀑布模型不支持软件重用和多项开发活动集成的局限性，喷泉模型使开发过程具有迭代性和无间隙性。
喷泉模型的优点：
提高软件项目的开发效率，节省开发时间。
喷泉模型的缺点：
开发阶段是重叠的，开发过程中需要大量的开发人员，不利于项目的管理。需要严格的管理文档，使得审核的难度加大。
基于构件的开发模型：
利用预先包装的构件来构造应用系统，基于构件的开发模型具有许多螺旋模型的特点，它本质上是演化模型，需要以迭代的方式构建模型。分为领域工程和应用系统工程两部分。
领域工程的目的是构建领域模型、领域基准体系结构和可复用构件库。 应用系统工程的目的是使用可复用构件组装应用系统。
形式化方法模型：
建立在严格数学基础上的一种软件开发方法，主要活动是生成计算机软件形式化的数字规格说明。用严格的数学语言和语义描述功能规约和设计规约，通过数学的分析和推导，易于发现需求的歧义性、不完整性和不一致性，易于对分析模型、设计模型和程序进行验证。
结构化分析的概念：
是一种软件开发方法，一般利用图形表达用户需求，强调开发方法的结构合理性以及开发软件的结构合理性。
结构是指系统内各个组成要素之间的相互联系、相互作用的框架。结构化开发提出了一组提高软件结构合理性的准则，如分解与抽象、模块独立性、信息隐蔽等。针对软件生存周期各个不同的阶段，它有结构化分析和结构化程序设计等方法。
结构化分析方法给出一组帮助系统分析人员产生功能规约的原理与技术。它一般利用图形表达用户需求，使用的手段主要有数据流图、数据字典、结构化语言、判定表以及判定树等。
结构化分析的步骤如下：
分析当前的情况，做出反映当前物理模型的DFD；
推导出等价的逻辑模型的DFD；
设计新的逻辑系统，生成数据字典和基元描述；
建立人机接口，提出可供选择的目标系统物理模型的DFD；
确定各种方案的成本和风险等级，据此对各种方案进行分析；
选择一种方案；
建立完整的需求规约。
敏捷宣言（Agile development manifesto）：
个人和这些个人之间的交流胜过了开发过程和工具
可运行的软件胜过了宽泛的文档
客户合作胜过了合同谈判
对变更的良好响应胜过了按部就班地遵循计划
极限编程：
极限编程是敏捷软件开发使用最广泛的一个方法。极限指的是把好的开发实践运用到极致。广泛运用于需求模糊且经常变动的场合。极限编程面对变化和不确定性更加快速敏捷，能快速持续迭代渐增。
极限编程的特点：
1、客户作为开发团队的成员。客户与开发紧密配合，客户负责确定需求，回答问题，验收。
2、短交付周期。两周一次迭代，交互目标系统可工作的版本，不断演示迭代生成的系统获得反馈意见。
3、结对编程，测试驱动开发。先有好的测试方案然后再编程，所有的测试工作完成了才算工作完成。
4、集成所有。程序代码归所有人所有，任何人都有修改代码的权利，全体成员对所有代码负责。
5、持续集成。多次集成系统，随着需求的变更，不断回归测试。
6、可持续开发速度，能维持长期稳定的速度，开放的工作空间，全体成员在开放场所工作，随时自由交流讨论。
7、及时调整计划。计划是灵活和循序渐进的。
8、重构。代码重构是在不影响系统行为的前提下，重新调整和优化系统的内部结构，降低复杂性，消除冗余，增加灵活性，提高性能。不要过分依赖重构，前期重设计。
设计概念：
抽象（Abstraction）：
过程抽象是指具有明确和有限的指令序列（描述动作）
数据抽象是描述数据对象的冠名数据集合（描述动作怎么做）
体系结构（Architecture）：
软件的整体结构和这种结构为系统提供概念完整方式。构件表示主要的系统元素及其交互。
模式（Patterns）：
模式承载了已证实的解决方案的精髓。设计模式描述了在某个特定场景与可能影响模式应用和使用方法的“影响力”中解决某个特定的设计问题的设计结构。
关注点分离（Separation of concerns）：
它表明任何复杂问题如果被分解为可以独立解决和优化的若干块，该复杂问题能够更容易的被处理。
模块化（Modularity）：
模块化是关注点分离最常见的表现。模块化设计使得开发工作更易规划。
信息隐蔽（Hiding）：
隐蔽意味着通过定义一系列独立的模块可以得到有效的模块化，独立模块互相之间只交流实现软件功能所必须的那些信息。隐蔽定义并加强了对模块内过程细节的访问约束和对模块所使用的任何局部数据结构的访问约束。
功能独立（Functional independence）：
开发具有“专一”功能和低耦合性的模块即可实现功能独立。
求精（Refinement）：
通过连续精化过程细节层次来实现程序的开发，通过逐步分解功能的宏观陈述直到形成程序设计语言的语句来进行层次开发。
抽象和精化是互补的概念。
方面（Aspects）：
一个方面作为一个独立的模块进行实施，而不是作为“分割的”或者和许多构件“纠缠的”软件片段进行实施。设计体系结构应当支持定义一个方面，该方面即一个模块，该模块能够使该关注点经过它横切的所有其他关注点而得到实施。
重构（Refactoring）：
重构是使用这样一种方式改变软件系统的过程：不改变代码的外部行为而是改进其内部结构。
对象：
对象(Object)是系统中用来描述客观事物的一个实体,它是构成系统的一个基本单位,由一组属性和对这组属性进行操作的一组服务组成。
类：
类(Class)是具有相同属性和服务的一组对象的集合,它为属于该类的全部对象提供了统一的抽象描述,其内部包括属性和服务两个主要部分。
封装：
封装(Encapsulation)是把对象的属性和服务结合成一个独立的系统单位,并尽可能隐藏对象的内部细节。
继承：
继承(Inheritance)是指子类可以自动拥有父类的全部属性和服务。
消息：
消息(Message)是对象发出的服务请求,一般包含提供服务的对象标识、服务标识、输入信息和应答信息等信息。
多态性：
多态性(Polymorphism)是指在父类中定义的属性或服务被子类继承后,可以具有不同的数据类型或表现出不同的行为。
主动对象：
主动对象(Active Object)是一组属性和一组服务的封装体,其中至少有一个服务不需要接收消息就能主动执行(称为主动服务)。
面向对象分析：
面向对象的分析(OOA)就是运用面向对象的方法进行需求分析,其主要任务是分析和理解问题域,找出描述问题域和系统责任所需的类及对象,分析它们的内部构成和外部关系,建立OOA模型。
面向对象设计：
面向对象的设计(OOD)就是根据已建立的分析模型,运用面向对象技术进行系统软件设计。它将OOA 模型直接变成OOD模型,并且补充与一些实现有关的部分,如人机界面、数据存储、任务管理等。
面向对象编程：
面向对象的编程(OOP)就是用一种面向对象的编程语言将OOD模型中的各个成分编写成程序。
面向对象测试：
面向对象的测试(OOT)是指对于运用OO技术开发的软件,在测试过程中继续运用OO技术进行以对象概念为中心的软件测试。
黑盒测试：
黑盒测试也称功能测试或数据驱动测试,它是在已知产品所应具有功能的情况下,通过测试来检测每个功能是否都能正常使用。
白盒测试：
白盒测试也称结构测试或逻辑驱动测试,它是知道产品内部工作过程,可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行,按照程序内部的结构测试程序,检验程序中的每条通路是否都有能按预定要求正确工作,而不顾它的功能。
基本设计原则：
开闭原则（Open-Closed Principle ，OCP）：模块应该对外延具有开放性，对修改具有封闭性。
依赖倒置原则（Dependency Inversion Principle ，DIP）：依赖于抽象，而非具体实现。
Liskov替换原则（Liskov Substitution Principle (LSP)）：子类可以替换他们的基类。
接口分离原则（The Interface Segregation Principle (ISP)）：多个客户专用接口比一个通用接口好
发布复用等价性原则（The Release Reuse Equivalency Principle，REP）：复用的粒度就是发布的粒度
共同封装原则（The Common Closure Principle (CCP)）：一同变更的类应该合在一起
共同复用原则（The Common Reuse Principle (CRP））：不能一起复用的类不能被分到一组
内聚性（Cohesion）：
内聚性意味着构件或者类只封装那些相互关联密切，以及与构件或类自身有亲密关系的属性和操作。
功能内聚：主要通过操作来体现，当一个模块只完成某一组特定操作并返回结果时，就称此模块是功能内聚的。
分层内聚：高层能够访问低层的服务，但低层不能访问高层的服务。
通信内聚：访问相同数据的所有操作被定义在同一个类中。（数据的查询，访问，存储）
耦合性（Coupling）：
耦合是类之间彼此联系程度的一种定性度量。 随着类（构件）相互依赖越来越多，类之间的耦合程度亦会增加。
内容耦合：暗中修改其他构件的内部数据，这违反了信息隐蔽原则
公用耦合：当大量的构件都要使用同一个全局变量时发生这种耦合
控制耦合：当操作A调用操作B，并向B传递控制标记时，就会发生这种耦合。
标记耦合：当类B被声明为类A某一操作中的一个参数类型时，就会发生这种耦合。
数据耦合：当操作需要传递长串的数据参数时，就会发生这种耦合。
例程调用耦合：当一个操作调用另一个操作时，就会发生这种耦合。
类型使用耦合：当构件A使用了在构件B中定义的一个数据类型时，就会发生这种耦合。
包含或者导入耦合：当构件A引入或者包含一个构件B的包或者内容时，就会发生这种耦合。
外部耦合：当一个构件和基础设施构件进行通信和协作时，就会发生这种耦合。
为什么要高内聚?
模块之间的关系越紧密,出错就越少!
为什么要低耦合?
子程序间的关系越复杂,就会产生更多的意想不到的错误!会给以后的维护工作带来很多麻烦!
高内聚低耦合，是软件工程中的概念，是判断设计好坏的标准，主要是面向对象的设计，主要是看类的内聚性是否高，耦合度是否低。