需求工程---需求分类：
质量功能部署（QFD）是一种将客户要求转化成软件技术需求的技术。QFD的目的是最大限度地让客户从软件工程过程中感到满意。为了这个目标，QFD确认了三类需求：
- 常规需求
- 期望需求：那些隐含在产品或系统中的，可能由于非常基础以至于用户没有显式说明的需求。
- 意外需求
需求工程---需求工程概述
需求开发可分为：情况获取、分析、编写规格说明呵呵评审四个阶段。这些项包括软件类产品中需求收集、评价、编写文档等所有活动。需求开发活动包括以下几个方面：
- 确定产品所期望的用户类别
- 获取每个用户类的需求
- 了解实际用户任务和目标以及这些任务所支持的业务需求
- 分析源于用户的信息以区别用户任务需求，功能需求、业务规则、指令属性、建议解决方法和附件信息
- 将系统级的需求分为几个子系统，并将需求中的一部分分配给软件组件
- 了解相关质量属性的重要性
- 商讨实施优先级的划分
- 将所收集的用户需求编写成文档和模型
需求分析---需求分类：
软甲需求包括三个不同的层次：业务需求、用户需求和功能需求。
- 业务需求反应了组织机构或客户对系统、产品高层次的目的要求，他们在项目视图与范围文档中予以说明。
- 用户需求描述了用户使用产品必须要完成的任务，这在用例文档或方案脚本说明中予以说明。
- 功能需求定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。
解析：“用户能有效地纠正文档中的拼写错误”是业务的需求，因为产品的包装盒封面上可能会标明这是个满足需求的拼写检查器；
“找出文档中的拼写错误并通过一个提供的替换项列表来供选择替换拼错的词”。是用户的需求；
“该拼写检查器还有许多功能需求，如找到并高亮提示错词的操作”是功能的需求。
需求工程---UML
UML利用5个系统视图描述系统的组织结构，包括系统分解的组成部分，以及他们的关联性、交互机制和指导原则等提供系统设计的信息。
- 用例视图是最基本的需求分析模型。
- 逻辑视图表示了涉及模型中在架构方面具有重要的意义的部分，即类、子系统、包和用例实现的子集。
- 进程视图是可执行线程和进程作为活动类的建模。
- 实现视图对组成基于系统的物理代码的文件建模。
- 部署视图把组件部署到一组物理节点上，表示软件到硬件的映射和分布结构
需求工程---需求分析
系统分析阶段的基本任务是系统分析是在充分了解用户需求的基础上，把双方对待建系统的理解表达为系统需求规格说明书。
需求模式---UML
命令模式（Command）是一种对象的行为型模式，类似于传统程序设计方法中的回调机制，它将一个请求封装为一个对象，从而使的可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤销的操作。命令模式对命令的封装，将发出命令的责任和执行命令的责任分割开，委派给不同的对象，以实现发送者和接收者完全解耦，提供更大的灵活性和可扩展性。
Command模式的结构如下图所示
其中：
类Command声明执行操作的接口；
ConcreteCommand将一个接收者对象绑定与一个动作，并调用接收者相应的操作，以实现execute方法
类Client创建一个ConcreteCommand对象并设定它的接收者；
类invoke要求Command执行这个请求；
类Receiver知道如何实施与执行一个请求相关的操作，任何类都可能作为一个接收着。
在“点菜”这个实例中，订单是厨师（Cook）与action（按订单加工）之间的绑定，厨师接受订单并对其进行负责。所以在该实例中，与Command类对应的类时“Order”，与Receiver对应的类时“Cook”
需求工程---需求分类：
系统性能评价基础知识：应用系统运行了一段时间后，通常会出现一些性能问题，需要考虑对系统性能进行调整。如果在系统开发设计和开发阶段没有充分考虑好某些方面的性能（例如：并发用户数量大大增加影响了性能）；如果系统运行环境发生了变化（例如网络环境的改变或企业规模的扩大）都可能使系统的性能大大下降；经过一段时间的运行，积累了不少运行状况的数据，分析得知了系统性能的瓶颈所在，这些因素都是对系统性能进行调整的原因。
用户的功能性需求发生变化时常需要对系统进行完善性维护，而不是调整系统的性能。
UML中的事务也称为建模元素，包括结构事务（structural things）、行为事务\动作事务（behavior things）、分组事务（grouping things）和注释事务（annotational things）这些事务是UML模型中最基本的OO构造块。
- 结构事务：结构事务在模型中属于静态的部分，代表概念上或物理上的元素。UML有七种结构事务，分别是类、接口、协作、用户、活动类、构件和节点。
- 类是描述具有相同属性、方法、关系和语义的对象的集合，一个类实现一个或多个接口；
- 接口是指类或构件提供特定服务的一组操作的集合，接口描述了类或构件的对外的可见的动作；
- 协作定义了交互的操作，是一些角色和其他事物一起工作，提供一些合作的动作，这些动作比事物的总和要大；
- 用户是描述一系列的动作，产生有价值的结果。在模型中用例通常用来组织行为事物。
- 用例是通过协作来实现的；
- 活动类的对象有一个或多个进程或线程。活动类和类很相似，只是它的对象代表的事物的行为和其他事物是同时存在的；
- 构件是物理上或可替换的系统部分，它实现了一个接口集合；
- 节点是一个物理元素，它在运行时存在，代表一个可计算的资源，通常占用一些内存和具有处理能力。
- 一个构件的集合一般来说位于一个节点，但是可能从一个节点转到另一个节点；
行为事物：行为事物是UML模型中的动态部分，代表时间和空间上的动作。UML有两种主要的行为事物。
- 第一种是交互（内部活动）：交互是由一组对象之间在特定上下文中，为达到特定目的而进行的一系列消息交换而组成的动作。交互中组成动作的对象每个操作都要详细列出，包括消息，动作次序（消息产生的动作）、连接（对象之间的连接）；
- 第二种是状态机：状态机由一系列对象的状态组成的
分组事物：分组事务是UML模型中组织的部分，可以把他们看成是盒子，模型可以在其中进行分解。UNL只有一种分组事务，称为包。包是一种将有组织的元素分组的机制。与构件不同的是，包存粹是一种概念上的事物，只存在与开发阶段，而构件可以存在与系统的运行阶段。
注释事物：注释事物是UML模型的注释部分；
需求工程---需求分析：
业务流程图这一建模工具的理解和掌握：
业务流程图（TFD）是业务流程调查结果的图形化表示，它反映现有系统各部门的业务处理过程及其之间的分工与联系，以及连接各部门信息流的传递和流动关系，体现现有系统的边界、环境、输入、输出和数据存储等内容。
需求工程---UML
依赖（dependency）依赖是两个事物之间的语义关系，其中一个事物发生变化会影响到另一个事物的语义。
从UML事物关系的本质上看，包含关系和扩展关系都属于依赖关系。对包含关系而言，抽象用例中的事件流是一定插入到基本用例中去的，并且插入点只有一个。
扩展用例的事件流往往可以抽象为基本用例的备选事件流，在扩展关系中，可以根据一定的条件来决定是否将扩展用例的事件流插入到基本用例的事件流中，并且插入点可以有多个。在实际应用中，很少使用泛化关系，子用例的特殊行为都可以作为父用例中的备选事件流而存在。
进程视图是以可执行线程和进程作为活动类的建模，它描述了并发与同步结构。UML中的活动图可以用于表达进程视图
操作系统---段页式存储
在高级语言程序中，对存储数据的位置进行抽象，采用的虚拟地址。在程序运行时再进行地址变换，分为内部地址变换与外部地址变换。虚拟存储系统按照地址映像方式把虚拟地址转换为主存物理地址称为内部地址变换。如果要访问的指令或数据已经在主存中，则命中，直接访问即可，否则就发生了页面失效，此时再进行外部地址变换，即将虚拟地址变换为辅存物理地址。
系统设计---处理流程设计
基于BPR的信息系统规划一定要突破以现行职能式管理模式的局限，从供应商、企业、客户的价值链出发，确定企业信息化的长远目标，选择核心业务流程为实施的突破口，在业务流程创新以及规范化的基础上，进行信息系统规划。基于BPR的信息系统规划的主要步骤如下：
- 战略规划：主要是明确企业的战略目标，认清企业的发展方向，了解企业运营模式；进行业务流程的调查，确定成功实施企业战略的成功因素，并在此基础上定义业务流程，制订信息系统战略规划，使得信息系统目标与企业目标保持一致，为业务流程实施提供战略指导。
- 流程规划：业务流程规划是数据规划与功能规划的基础，主要任务是选择核心业务流程，并进行流程分析识别出关键业务流程，以及需要改进的业务流程，画出改进后的业务流程图。
- 数据规划：在业务流程规划的基础上识别由流程所产生、控制和使用的数据，并对数据进行相应的分类；首先定义数据类，然后进行数据的规划，按时间长短可以将数据分为历史数据、年报数据、季度数据、月度数据、日报数据等；按数据是否共享可以分为共享数据和内部专用数据；按数据的用途可分为系统数据u、基础数据和综合数据等；
- 功能规划：在对数据类和业务流程了解的基础上，才能建立数据类与过程的CU矩阵，对他们的关系进行综合，并通过CU矩阵识别子系统，进一步进行系统总体逻辑结构的规划，即功能规划，识别功能的模块。
- 实施规划：本阶段包括两个活动，分别是确定系统开发顺序和制订项目开发计划。在企业目前有限的资源状况下，需要确定各个信息系统开发的优先次序，保证那些最关键的信息系统能优先开发。同时，要制订各个信息系统开发的计划，保证信息系统战略能有序实施。
系统设计---设计模式
- 适配器模式（Adapter）：适配器模式将一个接口转换成客户希望的另一个接口，从而使接口不兼容的那些类可以一起工作。适配器模式既可以作为类结构型模式，也可以作为对象结构型模式。在适配器模式中，通过使用一个具体类将适配者适配到目标接口中；在对象适配器模式中，一个适配器可以将多个不同的是适配者适配到同一个目标；
- 装饰模式（Decorator）：装饰模式是一种对象结构型模式，可动态给一个对象增加一些额外的职责，就增加对象功能来说，装饰模式比生成子类实现更加的灵活。通过装饰模式，可以在不影响其他对象的情况下，以动态、透明的方式给单个对象增加职责；当需要动态给一个对象增加功能，这些功能可以再动态地被撤销时可以使用装饰模式；当不能采用生成子类的方法进行扩充时也可使用装饰模式。
- 代理模式（Proxy）：代理模式是一种对象结构型模型，可为某个对象提供一个代理，并由代理对象控制对原对象的引用。代理模式能够协调调用者和被调用者，能够在一定程度上降低系统的耦合度，其缺点是请求的处理速度会变慢，并且实现代理模式需要额外的工作。
系统设计---设计模式
解析“为了节省内存空间，要求不能将具有相同属性（例如：类型、扩展名、、图标相同）的相同文件看作不同的对象”这句话的意思是：有相同属性的相同文件，即使存在不同的目录下，应作为一个对象。即创建了一个对象要在多处共享使用，所以使用享元模式
系统设计---设计模式
- 从图中找出模式的关键字，如果找到，是这种模式的概率较高（70%）。有很多的模式，其UML图是完全一样的，只是用在不同的场景，有不同用意而已，此时不标明是那种模式，根本就无法进行判断。
- 需要从选项进行横向对比，所以我们需要分析选项中每一种模式的主要特征是什么？在本题中图中已经出现visitor，而与此同时访问者模式中的标准函数accept的身影，所以visitor的概率最高。
-
- stragegy模式：策略模式，主要是方便策略的选择与改变；
- Observer模式：主要是建立观察关系，一旦被观察者有变化快速通知观察者联动处理
- State模式：主要关注状态的变迁，这些与图中的表达不符合
