软件生命周期

1. 可行性研究与计划
2. 需求分析
3. 概要设计
4. 详细设计
5. 实现
6. 集成测试
7. 确认测试
8. 使用和维护

瀑布模型（面向文档的软件开发模型）

1. 需求分析
2. 总体设计
3. 详细设计
4. 编码与调试
5. 集成测试与系统测试

螺旋模型

1. 需求分析
2. 风险分析
3. 工程实现
4. 评审

构件组装模型

1. 设计构件组装
2. 建立构件库
3. 建立应用软件
4. 测试与发布

统一过程RUP

RUP显著特征:用例驱动的、架构为中心、迭代和增量。

1. 初始（界定系统范围，明确系统目的，业务建模和需求）
2. 细化（抽象软件逻辑模型，设计软件架构，分析设计）
3. 构建（完成系统构建，实施和测试）
4. 交付（重构、修改、测试和部署）

基于架构的软件设计ABSD

ABSD（基于架构的软件开发）架构驱动的：商业、质量、功能需求。
ABSD描述软件架构：视角、视图；
ABSD描述需求：用例，质量场景；
ABSD三个基础：功能分解、通过选择架构风格来实现质量和业务需求、软件模板的使用。

基于架构的软件开发模型ABSDM

1. 架构需求
2. 架构设计
3. 架构文档化
4. 架构复审
5. 架构实现
6. 架构演化

可行性研究的内容

1. 经济可行性
2. 技术可行性
3. 法律可行性
4. 执行可行性
5. 方案的选择

需求分析的实现步骤

1. 获取当前系统的物理模型
2. 抽象出当前系统的逻辑模型
3. 建立目标系统的逻辑模型

软件需求

第一种分类：

1. 功能需求
2. 非功能需求
3. 设计约束

第二种分类：

1. 业务需求
2. 用户需求
3. 系统需求

需求工程

1. 需求开发：需求捕获、需求分析、编写规格说明书和需求验证
2. 需求管理：需求基线、处理需求变更和需求跟踪

类

1. 实体类：映射需求中的每个实体
2. 控制类：控制用例工作的类，例如，用例“身份验证”
3. 边界类：系统与外界的交接处，包括所有窗体、报表、打印机和扫描仪等硬件的接口，用于系统接口与系统外部进行交互

UML架构（4+1视图）

1. 逻辑视图：以问题域的语汇组成的类和对象集合。
2. 进程视图：可执行线程和进程作为活动类的建模，它是逻辑视图的一次执行实例。
3. 实现视图：对组成基于系统的物理代码的文件和组件进行建模。
4. 部署视图：把组件物理地部署到一组物理的、可计算的节点上。
5. 用例视图：最基本的需求分析模型。

用户界面设计原则

1. 置用户于控制之下
2. 减少用户的记忆负担
3. 保持界面一致

面向对象分析模型

1. 顶层架构图
2. 用例与用例图
3. 领域概念模型

软件架构定义

为软件系统提供了一个结构、行为和属性的高级抽象，由构成系统的元素的描述、这些元素的相互作用、指导元素集成的模式及这些模式的约束组成
软件架构的重要性

1. 项目关系人之间交流的平台
2. 早期设计决策
3. 在较高层面上实现软件复用
4. 架构对开发的指导与规范意义不容忽略

架构的模型（4+1视图模型）

1. 逻辑视图：主要支持系统的功能需求，即系统提供给最终用户的服务
2. 开发视图：也称为模块视图，主要侧重于软件模块的组织和管理
3. 进程视图：侧重于系统的运行特性，主要关注一些非功能性的需求，例如系统的性能和可用性。
4. 物理视图：主要考虑如何把软件映射到硬件上，它通常要考虑到解决系统拓扑结构、系统安装、通信等问题。
5. 场景：可以看作是那些重要系统活动的抽象，它使四个视图有机地联系起来，从某种意义上说，场景是最重要的需求抽象。

软件质量属性

1. 功能性：适合性、准确性、互操作性、依从性、安全性；
2. 可靠性：成熟性、容错性、易恢复性；
3. 易用性：易理解性、易学性、易操作性；
4. 效率：时间特性、资源特性；
5. 可维护性：易分析性、易改变性、稳定性、易测试性；
6. 可移植性：适应性、易安装性、遵循性、易替换性；

软件架构风格定义

软件架构风格是描述某一特定应用领域中系统组织方式的惯用模式。架构风格定义了一个系统家族，即一个架构定义一个词汇表和一组约束。词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的。架构风格反映了领域中众多系统所共有的结构和语义特性，指导如何将各个模块和子系统有效地组织成一个完整的系统。
软件架构风格分类
1. 数据流风格
批处理风格：每个处理步骤是一个单独的程序；每一步必须在前一步结束后才能开始；数据必须是完整的，以整体的方式传递。
管道过滤器风格：每个构件都有一组输入和输出，构件读输入的数据流，经过内部处理，然后产生输出数据流。
2. 调用/返回风格
主程序/子程序风格：程序体系结构是较简单的结构，其组件是主程序和子程序，连接件是调用返回机制。
面向对象风格：面向对象体系结构风格的组件是类和对象。连接件是对象之间通过功能与函数调用实现交互。对象是通过函数和过程的调用-返回机制来交互的，而类是
通过定义对象，再采用调用-返回机制进行交互。
层次风格：层次系统组织成一个层次结构，每一层为上层服务，并作为下层客户。
3. 独立构件风格
进程通信风格：通过进程间通信独立组建的风格。
事件驱动系统风格：事件驱动架构风格。构件不直接调用一个过程，而是触发或广播一个或多个事件。系统中其他构件中的过程在一个或多个事件中注册，当一个事件
被触发，系统自动调用在这个事件中注册的所有过程。一个事件的触发就导致了另一个模块中过程的调用。
4. 虚拟机风格
解释器风格：一个解释器通常包括完成解释工作的解释引擎，一个包含将被解释的代码的存储区，一个记录解释引擎当前工作状态的数据结构，以及一个记录源代码被
解释执行的进度的数据结构。将高抽象层次的程序翻译为低抽象层次所能理解的指令，以消除程序语言与硬件之间存在的差异。
基于规则的系统风格：基于规则的系统包括规则集、规则解释器、规则/数据选择器及工作内存。
5. 仓库风格
数据库系统风格：数据库架构是库风格最常见的形式。构件主要有两大类，一个是中央共享数据源，保存当前系统的数据状态；另一个是多个独立处理元素，处理元素
对数据元素进行操作。
黑板系统风格：黑板架构包括知识源、黑板和控制3个部分。知识源包括若干独立计算的不同单元，提供解决问题的知识，知识源响应黑板上的变化，也只修改黑板。黑
板是一个全局数据库，包含解域的全部状态，是知识源互相作用的唯一媒介。
超文本系统风格：早期的静态网页是比较典型的超文本系统。

软件架构评估的方法

1. 基于调查问卷或检查表的方式
2. 基于场景的方式：架构权衡分析法（ATAM）和软件架构分析方法（SAAM）
3. 基于度量的方式

特定领域的软件架构DSSA 的活动阶段

1. 领域分析：主要目标是获得领域模型。
2. 领域设计：这个阶段的目标是获得 DSSA。
3. 领域实现：主要目标是依据领域模型和 DSSA 开发与组织可复用信息。

设计模式

1. 创建型设计模式
抽象工厂(Abstract Factory）：在不指定具体类的情况下，为创建一系列相关或相互依赖的对象提供了一个接口。生产多种产品。比如：键盘+鼠标。
构建器模式（Builder）：构建器模式将复杂对象和构建与其表示相分离，这样相同的构造过程可以创建不同的对象。例如肯德基的汉堡、薯条、可乐、炸鸡等是不变的，而套餐组合是经常变化的。
工厂方法模式（Factory Method）：工厂方法模式定义了创建对象的接口，它允许子类决定实例化哪一个类。生产1类产品，比如惠普鼠标+联想鼠标。
原型模式（Prototype）：原型模式允许对象在不了解要创建对象的确切类以及如何创建等细节的情况下创建自定义对象。例如A a2 = new A（a1）,a1是A类的一个对象。
单例模式（Singleton）：单例模式确保一个类只有一个实例，并且提供了对该类的全局访问入口，它可以确保使用这个类实例的所有对象使用相同的实例。 getInstance()。
2. 结构型设计模式
适配器模式（Adapter）：适配器模式可以充当两个类之间的媒介，它可以转换一个类的接口，这样就可以被另外一个类使用，这使得具有不兼容接口的类能够协同使用。 电源适配器，220v转5v。
桥接模式（Bridge）：桥接模式可以将一个复杂的组件分成两个独立的但又相关的继承层次结构：功能性的抽象和内部实现。咖啡大杯、中杯、小杯；加糖、加奶、加咖啡。
组合模式（Composite）：组合模式允许创建树型层次结构来改变复杂性，同时允许结构中的每一个元素操作同一个接口。目录+文件。
装饰器模式（Decorator）：装饰器模式可以在不修改对象外观和功能的情况下添加或者删除对象的功能。肉夹馍，以夹馍为主，以材料(鸡蛋、火腿、里脊)装饰肉夹馍。 咖啡+糖+加奶
外观模式（门面模式 Facade）：门面模式为子系统中的一组接口提供了一个统一的接口（允许在不删除系统中的所有可用选项的前提下为用户提供一个简化的界面）。股票（子系统）+基金（接口）。
享元模式（Flyweight）：享元模式可以通过共享对象减少系统中低等级的、详细的对象数目。数据库连接池、缓冲池等。
代理模式（Proxy）：代理模式为控制对初始对象的访问提供了一个代理对象。明星+经纪人(代理)。
3. 行为型设计模式
责任链模式（Chain of Responsibility）：责任链模式可以在系统中创建一个链，这样消息可以在首先接收到它的级别处被处理，或者可以定位到可以处理它的对象。请假2天内，转到直属上次，超过3天，转到上司的上司。
命令模式（Command）：命令模式在对象中封装了请求，这样就可以保存命令，将该命令传递给方法以及像任何其他对象一样返回该命令。1个 APP控制多个厂家的多种产品，厂家将各种产品的控制功能封装成命令。
解释器模式（Interpreter）：解释器模式可以解释定义其语法表示的语言，还提供了用表示来解释语言中的语句的解释器。编译器、运算表达式计算、正则表达式解析。
迭代器模式（Iterator）：迭代器模式为集合中的有序访问提供了一致的方法，而该集合是独立于基础集合，并与之相分离的。游标，迭代器，foreach。
中介者模式（仲裁者模式 Mediater）：通过引入一个能够管理对象间消息分布的对象，简化了系统中对象间的通信。 qq消息，服务器（中介者）转发。
备忘录模式（Memento）：备忘录模式可以保持对象状态的“快照”（snapshot），这样对象可以在不向外界公开其内容的情况下返回到它的最初状态。游戏存档、虚拟机快照。
观察者模式（Observer）：观察者模式为组件向相关接收方广播消息提供了灵活的方法。该模式定义了对象间一到多的依赖关系，这样当对象改变状态时，将自动通知并更新它所有的依赖对象。Listener，明星（主题）发微博，粉丝（观察者）都收到了。
状态模式（State）：状态模式允许对象在内部状态变化时，变更其行为，并且修改其类。人睡觉，上班，休息都是状态，case（xxx）。
策略模式（Strategy）：策略模式定义了一组能够用来表示可能行为集合的类。这些行为可以在应用程序中使用，来修改应用程序功能。商场现在正在搞活动，有打折的、有满减的、有返利的等，说到底都是一些算法，这些算法本身只是一种策略。
模板方法模式（Template Method）：模板方法模式提供了在不重写方法的前提下允许子类重载部分方法的方法。在操作中定义算法的框架，将一些步骤由子类实现。该模式可以在不修改算法结构的情况下，让子类重新定义算法的特定步骤。老师出的试卷（模板）都是一样的。
访问者模式（Visitor）：访问者模式提供了一种方便的、可维护的方法来表示在对象结构元素上要进行的操作。该模式允许在不改变操作元素的类的前提下定义一个新操作。通俗易懂设计模式解析——访问者模式
家里来了客人，客人就是访问者，他可以做一些事情，但是又不能做全部的事情。

软件测试阶段

1. 单元测试
2. 集成测试
3. 系统测试

基准测试程序

1. 真实程序：所有程序全部测评，准确性最高。
2. 核心程序：真实程序中具有代表性的代码。
3. 小型基准程序：代码行数比较少，通常是测试算法。
4. 合成基准程序：人为合成基准程序，准确性最低

其评测准确程度依次递减

负载均衡算法

1. 随机法
2. 轮询法
3. 最小连接法

软件设计方法

1. 模型驱动设计
2. 结构化设计
3. 信息工程
4. 原型设计
5. 面向对象设计
6. 快速应用开发

EJB

EJB——EnterpriceJavaBeans：是一个用于分布式业务应用的标准服务端组件模型。
EJB定义了三种企业Bean：

1. 会话Bean(SessionBean)：用于实现业务逻辑，比如用户注册、信息记录、数据操作等。
2. 实体Bean(Entity Bean)：代表真实物体的数据。
3. 消息驱动Bean(MessageDriven Bean)：用来专门处理基于消息请求的组件。

SOA设计原则

1. 明确定义的接口
2. 自包含和模块化
3. 粗粒度
4. 松耦合
5. 互操作性、兼容和策略声明

Web服务协议堆栈

1. UDDI（统一描述、发现和集成）：Web服务的发布、查找、定位，是一种目录；
2. WSDL（web服务描述语言）：如何使用程序调用web服务；
3. SOAP（简单对象访问协议）：Web服务系统中发送和接收数据，使用xml存储数据；
4. BPEL（Web服务业务流程执行语言）多个web服务组合到一个复杂业务（应用）中。

REST设计概念和准则

1. 网络上的所有事物都被抽象为资源。
2. 每个资源对应一个唯一的资源标识。
3. 通过通用的连接件接口对资源进行操作。
4. 对资源的各种操作不会改变资源标识。
5. 所有的操作都是无状态的

需求变更流程

1. 问题分析和变更描述
2. 变更分析和成本计算
3. 变更实现

企业应用集成

技术上综合考虑:

1. 界面集成
2. 平台集成
3. 数据集成
4. 应用集成
5. 过程集成

集成的深度来划分：

1. 应用集成
2. 业务过程集成
3. 数据集成

商业智能

商业智能系统主要包括数据预处理、建立数据仓库、数据分析及数据展现 4 个主要阶段。 数据预处理是整合企业原始数据的第一步，它包括数据的抽取、转换和装载三个过程。建立数据仓库则是处理海量数据的基础。数据分析是体现系统智能的关键， 一般采用联机分析处理和数据挖掘两大技术。

信息系统

数据环境：

1. 数据文件
2. 应用数据库
3. 主题数据库
4. 信息检索系统

应用层次

1. 战略级
2. 战术级
3. 操作级
4. 事务级

数据库三大范式

1、第一范式(1NF)；2、第二范式(2NF)；3、第三范式(3NF)。
第一范式(1NF)的要求是属性不可分割，，
第二范式(2NF)的要求是满足第一范式，且不存在部分依赖；
第三范式(3NF)的要求是满足第二范式，且不存在传递依赖。