Software：

如果有想要内推字节跳动或者腾讯的小伙伴，欢迎加我的wx: dHR5czIwMTU=(base64)

（1）指令的集合，通过执行这些指令可以满足预期的特征、功能和性能需求；
（2）数据结构，使得程序可以合理利用信息
（3）软件描述信息，它以硬拷贝和虚拟形式存在，用来描述程序操作和使用

---

Software Engineering：

软件工程是：
（1）将系统化的、规范化、可量化的方法应用于软件的开发、运行和维护，即将工程化方法应用于软件。
（2）在（1）中所述方法的研究

What the difference between software and hardware/strong>
1.软件是设计开发的，而不是传统意义上生产制造的。
2.软件不会“磨损”
3.大多数软件根据实际的顾客需求定制的。

Why does software need Change or Evolved/strong>
软件必须适应新的计算环境或技术的需要。
必须增强软件来实现新的业务需求。
软件必须扩展到与其他更现代的系统或数据库进行互操作。
必须重新构建软件，使其在网络环境中可行。

**迭代过程流（iterative process flow）：**在执行下一个活动前重复执行之前一个或多个活动。

**并行过程流（parallel process flow）：**将一个或是多个活动与其他活动并行执行。

V模型（V-model）：
描述了质量保证动作同沟通、建模相关动作以及早期构建相关的动作之间的关系。
V模型强调软件开发的协作和速度，将软件实现和验证有机地结合起来，在保证较高的软件质量情况下缩短开发周期。
**优点：**适合工程量小、人力资源少并且开发过程中改动不大的项目
**缺点：**错误发现时间迟，产生的风险代价高

演化过程模型（Evolutionary Model）
演化模型是迭代的过程模型。
原型开发（prototyping ）：当需求很模糊的时候，原型开发可以帮助软件开发人员和利益相关者更好地理解究竟需要做什么。
优点：
开发者与用户充分交流，可以澄清模糊需求，需求定义比其他 模型好得多
开发过程与用户培训过程同步
为用户需求的改变提供了充分的余地
开发风险低，产品柔性好
开发费用低，时间短
系统易维护，对用户更友好

缺点：
1、 没有考虑软件的整体质量和长期的可维护性。
2、 大部分情况是不合适的操作算法被采用目的为了演示功能，不合适的开发工 具被采用仅仅为了它的方便，还有不合适的操作系统被选择等等。
3、 由于达不到质量要求产品可能被抛弃，而采用新的模型重新设计。
适用范围：
尽管原型可以用作独立的流程模型，但它更常用作一种可以在任何流模型的上下文中实现的技术。

协同模型（concurrent development model）
有时候又称为协同工程，它允许软件团队表述本章所描述的任何模型中的迭代和并发元素。
协同建模提供了项目当前状态的准确画面。
适用范围：所有类型的软件开发，协同模型通常更适合涉及不同工程团队的产品工程项目。

---

Agile Development

敏捷宣言（Agile development manifesto）：
个人和这些个人之间的交流胜过了开发过程和工具
可运行的软件胜过了宽泛的文档
客户合作胜过了合同谈判
对变更的良好响应胜过了按部就班地遵循计划

极限编程（Extreme Programming (XP)）
极限编程是敏捷软件开发使用最广泛的一个方法。

极限编程过程:
1.策划：
开始创造“用户故事”
敏捷团队评估每个故事并分配一个成本（开发周数）
故事被分组到一个可交付增量
承诺在交付日期进行
在第一次递增之后，“项目速度”用于帮助估计后续发行版本的发布日期和进度安排，确定是否对整个开发项目中的所有故事有过分承诺。
2.设计
遵循KIS（保持简洁）原则
鼓励使用CRC（类-责任-协作者）卡（见第8章）
对于困难的设计问题，建议创建“尖峰解决方案” – 一个设计原型
鼓励“重构”： 重构是以不改变代码外部行为而改进其内部结构的方式来修改软件系统的过程。
3.编码
在编码开始之前，建议对故事进行单元测试
鼓励“结队编程”
4.测试
所有的单元测试每天都执行
“验收测试”，由客户规定技术条件，并且着眼于客户可见的、可评审的系统级的特征和功能。

UML活动图在特定场景通过提供迭代流的图形表示来补充用例。
例：

基于类的建模

基于类建模表示了系统操作的对象、应用于对象间能有效控制的操作、这些对象间的关系以及已定义类之间的协作。
基于类的分析模型包括类和对象、属性、操作、类的职责协作者（CRC）模型、协作图和包。

识别分析类
外部实体（其他系统、设备、人员），产生或实验基于计算机系统的信息。
事物（报告、显示、字母、信号），问题信息域的一部分。
偶发事件或事件（所有权转移或完成机器人的一组移动动作），在系统操作环境内发生。
角色（经理，工程师，销售人员），由和系统交互的人员扮演
组织单元（部门，组，团队），和某个应用系统相关
场地（制作车间或码头），建立问题的环境和系统的整体功能
结构（传感器、交通工具、计算机），定义了对象的类或与对象相关的类。
例：

类-职责-协作者建模（CRC）
CRC模型实际上是表示类的标准索引卡片的集合。
顶部写类名，左侧列出类的职责，右侧部分列出了类的协作者。

顺序图：
表明事物引发从一个对象到另一个对象的转移。

设计概念

1.抽象（Abstraction）：
过程抽象是指具有明确和有限的指令序列（描述动作）
数据抽象是描述数据对象的冠名数据集合（描述动作怎么做）

2.体系结构（Architecture）：软件的整体结构和这种结构为系统提供概念完整方式。构件表示主要的系统元素及其交互。

3.模式（Patterns）：模式承载了已证实的解决方案的精髓。设计模式描述了在某个特定场景与可能影响模式应用和使用方法的“影响力”中解决某个特定的设计问题的设计结构。

4.关注点分离（Separation of concerns）：它表明任何复杂问题如果被分解为可以独立解决和优化的若干块，该复杂问题能够更容易的被处理。

5.模块化（Modularity）：模块化是关注点分离最常见的表现。模块化设计使得开发工作更易规划。

6.信息隐蔽（Hiding）：隐蔽意味着通过定义一系列独立的模块可以得到有效的模块化，独立模块互相之间只交流实现软件功能所必须的那些信息。隐蔽定义并加强了对模块内过程细节的访问约束和对模块所使用的任何局部数据结构的访问约束。

7.功能独立（Functional independence）：开发具有“专一”功能和低耦合性的模块即可实现功能独立。

8.求精（Refinement）：通过连续精化过程细节层次来实现程序的开发，通过逐步分解功能的宏观陈述直到形成程序设计语言的语句来进行层次开发。
抽象和精化是互补的概念。

9.方面（Aspects）：一个方面作为一个独立的模块进行实施，而不是作为“分割的”或者和许多构件“纠缠的”软件片段进行实施。设计体系结构应当支持定义一个方面，该方面即一个模块，该模块能够使该关注点经过它横切的所有其他关注点而得到实施。

10.重构（Refactoring）：重构是使用这样一种方式改变软件系统的过程：不改变代码的外部行为而是改进其内部结构。

11.面向对象的设计概念（OO design concepts）:
面向对象概念（类、对象、继承、消息和多态）

12.设计类（Design Class）：提供设计细节，使程序得以实施。

设计概念强调了：
（1）抽象的必要性，它提供了一种创造可重用软件构件的方法
（2）体系结构的重要性，它使得能够更好地理解系统整体结构
（3）基于模式的工程的有益性，它是一项用于已证明能力的软件的设计技术
（4）关注点分离和有效的模块化的价值，他们使得软件更容易理解、更容易测试以及更容易维护。
（5）信息隐藏的直接作用，当错误发生时，它能够减少负面影响的传播
（6）功能独立的影响，他是构造有效模块的标准
（7）求精作为一种设计方法的作用
（8）横切系统需求方面的考虑
（9）重构的应用，他是为了优化已导出的设计
（10）面向对象的类和与类相关特征的重要性

设计模型（design model）

数据设计元素：数据设计创建在高级抽象级上表示的数据模型和信息模型。
体系结构设计元素：体系结构设计元素通常描述为一组相互关联系统的子系统，且常常从需求模型中的分析包中派生出来。
接口设计元素：软件接口设计元素描述了信息如何流入和流出系统以及被定义为体系结构一部分的构件之间是如何通信的。
接口设计有3个重要的元素：
（1）用户界面
（2）和其他系统、设备、网络或其他信息生成者或使用者的外部接口
（3）各种设计构件之间的内部接口
构件级设计元素：软件的构件级设计完整地描述了每个软件构件的内部细节。构件级设计为所以局部数据对象定义数据结构，为所有在构件内发生的处理定义算法细节，并定义允许访问所有构件操作的接口。
**部署级设计元素：**部署级设计元素指明软件功能和子系统将如何在支持软件的物理计算环境内分布。

体系结构设计

程序或计算机系统的软件体系结构是指系统的一个或者多个结构，它包括软件构件、构件的外部可见属性以及它们之间的相互联系。
体系结构并非可运行的程序。
确切的说，它是一种表达,是能够：
（1）对设计在满足既定需求方面的有效性进行分析
（2）在设计变更相对容易的阶段，考虑体系结构可能的选择方案
（3）降低与软件构造相关的风险

体系结构重要的3个关键原因
1.软件体系结构的表示有助于对计算机系统开发感兴趣的各方展开交流。
2.体系结构突出了早期的设计决策，这些决策对随后所有的软件工程工作有深远影响，同时对系统作为一个可运行实体的最后成功有重要作用。
3.体系结构“构建了一个相对小的、易于理解的模型，该模型描述了系统如何构成以及其构件如何一起工作”

体系结构风格
1.以数据为中心的体系结构。
2.数据流体系结构。
3.调用和返回体系结构
4.面向对象体系结构
5.层次体系结构

体系结构环境图（ACD）
上级系统：这些系统把目标系统作为某些高层处理方案的一部分
下级系统：这些系统被目标系统使用，并为完成目标系统的功能提供必要的数据和处理
同级系统：这些系统在对等的基础上相互作用
参与者：通过产生和消耗必要处理所需的信息，实现与目标系统交互的实体（人，设备）

构件级设计

构件的概念：
1.构件是计算机软件中的一个模块化的构造块。
2.OMG定义构件：系统中模块化的、可部署的和可替换的部件，该部件封装了实现并暴露一组接口。
**面向对象的观点（Object-Oriented view）：**构件包括一组协作的类。
**传统观点（Traditional View）：**一个构件就是程序的一个功能要素，程序由处理逻辑及实现处理逻辑所需的每部数据结构以及能够保证构件被调用和实现数据传递的结构构成。

基本设计原则

**开闭原则（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的包或者内容时，就会发生这种耦合。
外部耦合：当一个构件和基础设施构件进行通信和协作时，就会发生这种耦合。

为什么要高内聚
　模块之间的关系越紧密,出错就越少!
　为什么要低耦合
　子程序间的关系越复杂,就会产生更多的意想不到的错误!会给以后的维护工作带来很多麻烦!
　 高内聚低耦合，是软件工程中的概念，是判断设计好坏的标准，主要是面向对象的设计，主要是看类的内聚性是否高，耦合度是否低。

用户界面设计

黄金准则

1.用户操纵控制
（1）以不强迫用户进入不必要的或不希望的动作的方式来定义交互模式
（2）允许用户交互被中断和撤销
（3）当技能级别增长时可以使交互流线化并允许定制交互
（4）使用用户与内部技术细节隔离开来
（5）设计应允许用户与出现在屏幕上的对象直接交互
2.减少用户的记忆负担
（1）减少对短期记忆的要求
（2）建立有意义的缺省
（3）定义直观的快捷方式
（4）以不断进展的方式揭晓信息
3.保持界面一致
（1）允许用户当前任务放入有意义的环境中
（2）在应用系统家族内保持一致性
（3）如果过去的交互模型已经建立起了用户期望，除非有迫不得已的理由，doze不要改变它。

可用性

可用性是指用户在使用高科技产品所提供的功能和特性时，对使用的容易程度和有效程度的定量测量。

用户界面的分析与设计

工程师建立用户模型。软件工程师创建设计模型。最终用户在脑海中对界面产生映像，称为用户的心理模型或系统感觉。系统的实现者创建实现模型。
**用户模型：**确定了系统最终用户的轮廓。
**设计模型：**用户界面的设计
**心理模型：**最终用户在脑海里对系统产生的印象。
**实现模型：**组合了计算机系统的外在表现，结合了所有用来描述系统语法和语言的支撑信息。

用户界面的分析和设计过程是迭代的，用户界面分析和设计过程开始于螺旋模型的内部，并且包括4个阶段：（1）界面分析及建模。（2）界面设计。（3）界面构造。（4）界面确认。

传统的测试策略

单元测试

单元测试侧重于软件设计的最小单元（软件构件或模块）的验证工作。
单元测试侧重于构件的内部处理逻辑和数据结构。
可以对多个构件并行执行。
测试模块的接口是为了保证被测试程序单元的信息能够正常地流入和流出；
检查局部数据结构以确保临时存储的数据在算法的整个执行过程中能维持其完善性。
执行控制结构中的所有独立路径（基本路径）以确保模块中的所有语句至少执行一次。
测试边界条件确保模块在到达边界值得极限或受限处理的情形下仍能正确执行。
最后要对所有的错误处理路径进行测试。

驱动模块：接收测试用例数据，将这些数据传递给被测模块，并输出结果。
桩：替换那些从属于被测模块的模块
当设计高内聚的构件时，就可以简化单元测试。当构件只强调一个功能时，测试用例数就会降低，且比较容易预见错误和发现错误。

集成测试

集成测试时构造软件体系结构的系统化技术，同时也是进行一些旨在发现与接口相关的错误的测试。
集成测试的目标是利用单元测试的构件建立设计中描述的程序结构。

**自顶向下集成：**自顶向下集成测试是一种构造软件体系结构的增量方法。
**深度优先：**深度优先集成是首先集成位于程序结构中主控路径上的所有控件。
**广度优先：**广度优先集成首先沿水平方向，将属于同一层的构件集成起来。
自顶向下集成过程：
1.主控模块作为测试驱动模块，用桩模块代替直接附属的下层模块；
2.根据所选的集成策略（深度优先/广度优先），每次用一个实际模块替换一个桩模块；
3.每集成一个模块都进行测试；
4.完成每个测试集之后，用实际模块替换另一个桩模块；
5.可以进行回归测试（即全部或部分地重复已做过的测试），以避免引入新错误。
回到第2步继续执行此过程，直到完成整个程序结构的构造。

**自底向上集成测试：**就是从原子模块（程序结构的最底层构件）开始进行构造和测试。
自底向上集成测试过程：
1.连接底层构件以构成完成特定子功能的簇。
2.编写驱动模块（测试的控制程序）以协调测试用例的输入和输出
3.测试簇
4.去掉驱动程序，沿着程序结构向上逐步连接簇

环复杂度（Cyclomatic Complexity ）计算方法：

来源：星星的小孩