A002-181-2171-陈超
目录
一、需求分析认识
1.1 需求分析的定义
1.2 需求分析的目标和原则
1.3 需求分析的内容
1.3.1 业务需求
1.3.2 用户需求
1.3.3 功能需求
1.3.4 非功能性的需求
1.3.5 需求分析报告
1.4 需求分析的过程
1.5 需求分析的方法
1.5.1 功能分解方法
1.5.2 结构化分析方法
1.5.3 信息建模方法
1.5.4 面向对象的分析方法
面向对象的分析方法的关键是识别问题域内的对象，分析它们之间的关系，并建立三类模型，即对象模型、动态模型和功能模型。面向对象主要考虑类或对象、结构与连接、继承和封装、消息通信，只表示面向对象的分析中几项最重要特征。类的对象是对问题域中事物的完整映射，包括事物的数据特征(即属性)和行为特征(即服务)。
1.6 需求分析的特点
二、图类关键字
2.1 活动图（activity graph）认知说明：
2.2 类图(class diagram)的认知说明：
2.3 协作图(collaboration diagram)认知说明：
2.4 组件图(component diagram)的认知说明：
2.5 部署图(deployment diagram)认知说明：
2.6 对象图(object diagram)认知说明：
2.7 序列图(sequence diagram)认知说明
2.8 状态图(statechart diagram)认知说明：
2.9 用例图(use case diagram）认知说明：
2.10 上下文图(Context Diagram)认知说明：
2.11 数据流图(Dataflow Diagram)认知说明：
2.12 状态转换图(State Transition Diagram)认知说明：
2.13 实体关系图(entity-relationship-diagram)认知说明：
2.14 交互图(Interaction Diagram)认知说明：
2.15 状态机图(State Machine Diagram)认知说明：
三、模型关键词
3.1 上下文模型(Context model)认知说明：
3.2 类模型(Class model)认知说明：
3.3 模型精化（model elaboration）认知说明：
3.4 模型元素（model element）认知说明：
3.5 定义模型[MOF]认知说明：
3.6 实体关系模型(Entity-Relationship Model)认知说明：
3.7 原始类型(Primitive Type)认知说明：
3.8 需求模型(Requirements model)认知说明：
3.9 规格模型(Specification Model)认知说明：
3.10 静态模型(Static Model)认知说明：
3.11 动态模型(Dynamic Models)认知说明：
3.12 结构模型(Structural Model)认知说明：
3.13 模型元素（model element）认知说明：
3.14 元模型(MetaModel)认知说明：
3.15 元元模型(Meta-Meta Model)认知说明：
3.16 平台独立模型(Platform independent model)认知说明：
3.17 平台特定模型(Platform specific model)认知说明：
四、需求关键词
4.1 需求分析(Requirements analysis)认知说明：
4.2 需求基准(Requirement Baseline)认知说明：
4.3 需求获取(Requirement elicitation)认知说明：
4.4 需求管理(Requirements Management)认知说明：
4.5 需求确认(Requirements validation)认知说明：
4.6 软件需求规范说明(Software requirements specification)认知说明：
4.7 需求抽取技术(Requirements elicitation technique)认知说明：
4.8 涉众(Stakeholder)认知说明：
4.9 功能需求(Functional Requirement)认知说明：
4.10 非功能需求(Non-Functional Requirement)认知说明：
4.11 需求工程程序(Requirement engineering processes)认知说明：
五、第四类关键词
5.1 行为特征（behavioral feature）认知说明：
5.2 约束（constraint）认知说明：
5.3 控制焦点（focus of control）认知说明：
5.4 防卫条件（guard condition）认知说明：
5.5 二元联想(binary association)认知说明：
5.6 一般化(generalization)认知说明:
5.7 包容层次结构(containment hierarchy) 认知说明：
5.8 复合状态(composite state) 认知说明：
5.9 动态分类(dynamic classification) 认知说明：
5.10 应用程序域(Application Domain) 认知说明：
5.11 基线(baseline) 认知说明：
5.12 上下文边界(context boundary) 认知说明：
5.13 关联类(Association Class)认知说明：
5.14 二元联想(binary association)认知说明：
5.15 布尔表达式(Boolean Expression)认知说明：
六、第五类关键词
6.1 决策表(decision table)认知说明：
6.2 容错(Fault Tolerance)认知说明：
6.3 可维护性(Maintainability)认知说明：
6.4 统一建模语言(Unified Modeling Language)认知说明：
6.5 伪稳态(Pseudosteady State)认知说明：
6.6 可靠性弱点度量(Reliability)认知说明：
6.7 结构化分析(structured analysis)认知说明：
6.8 动作顺序(Action Sequence)认知说明：
6.9 接口规格(Interface specification)认知说明：
6.10 MVC(Model-View-Controller)认知说明：
6.11 单继承(Single Inheritance)认知说明：
6.12 体系结构(Architecture)认知说明：
6.13 基数(Cardinality)认知说明：
6.14 组合聚集(Composite aggregation)认知说明：
6.15 具体类(Concrete Class)认知说明：
七、第六类关键词
6.1 抽象类(Abstract Class)认知说明：
6.2 衍生元素(Derived Elements)认知说明：
6.3 流程开发(development process)认知说明：
6.4 刻板印象(stereotype)认知说明：
6.5 结构特征(Structural Feature)认知说明：
6.6 面向对象设计(Object-oriented design)认知说明：
6.7 开源程序代码(Open-source code)认知说明：
6.8 域名(Domain Name)认知说明：
6.9 动态分类(Dynamic Classification)认知说明：
6.10 形式参数(Formal Parameter)认知说明：
6.11 实际参数(actual parameter)认知说明：
6.12 警卫条件(Guard Condition)认知说明：
6.13 继承(Inheritance)认知说明：
6.14 内部过渡(Internal Transition)认知说明：
6.15 数据库服务器(Database server)认知说明：
八、第七类关键词
8.1 元对象(MetaObject)认知说明：
8.2 分层架构(Layered Architecture)认知说明：
8.3 设计模式(Design patterns)认知说明：
8.4 多类别分类(Multiclass Classification)认知说明：
8.5 多重继承(Multiple Inheritance)认知说明：
8.6 n元联想(N-Ary Association)认知说明：
8.7 外显性质(Emergent properties)认知说明：
8.8 对象流状态(object flow state)认知说明：
8.9 对象生命线形状(Object Lifeline shape)认知说明：
8.10 持久化对象(Persistent Object)认知说明：
8.11 事务处理(Transaction processing)认知说明：
九、建议
9.1 了解什么是产品需求
9.2 了解需求对象
9.3 获取需求，识别问题
9.4 对需求进行分类
9.5 需求价值评判
9.6 提升需求分析能力
十、总结
一、需求分析认识
1.1 需求分析的定义
需求分析也称为软件需求分析、系统需求分析或需求分析工程等，是开发人员经过深入细致的调研和分析，准确理解用户和项目的功能、性能、可靠性等具体要求，将用户非形式的需求表述转化为完整的需求定义，从而确定系统必须做什么的过程。
1.2 需求分析的目标和原则
目标：需求分析是软件计划阶段的重要活动，也是软件生存周期中的一个重要环节，该阶段是分析系统在功能上需要“实现什么”，而不是考虑如何去“实现”。需求分析的目标是把用户对待开发软件提出的“要求”或“需要”进行分析与整理，确认后形成描述完整、清晰与规范的文档，确定软件需要实现哪些功能，完成哪些工作。此外，软件的一些非功能性需求(如软件性能、可靠性、响应时间、可扩展性等)，软件设计的约束条件，运行时与其他软件的关系等也是软件需求分析的目标。
原则：(1)侧重表达理解问题的数据域和功能域。对新系统程序处理的数据，其数据域包括数据流、数据内容和数据结构。而功能域则反映它们关系的控制处理信息。
(2)需求问题应分解细化，建立问题层次结构。可将复杂问题按具体功能、性能等分解并逐层细化、逐一分析。
(3)建立分析模型。模型包括各种图表，是对研究对象特征的一种重要表达形式。通过逻辑视图可给出目标功能和信息处理间关系，而非实现细节。由系统运行及处理环境确定物理视图，通过它确定处理功能和数据结构的实际表现形式。
1.3 需求分析的内容
1.3.1 业务需求
反映了组织机构或客户对系统、产品高层次的目标要求，通常在项目定义与范围文档中予以说明。
1.3.2 用户需求
描述了用户使用产品必须要完成的任务，这在使用实例或方案脚本中予以说明。
1.3.3 功能需求
定义了开发人员必须实现的软件功能，使用户利用系统能够完成他们的任务，从而满足了业务需求。
1.3.4 非功能性的需求
描述了系统展现给用户的行为和执行的操作等，它包括产品必须遵从的标准、规范和约束，操作界面的具体细节和构造上的限bai。
1.3.5 需求分析报告
报告所说明的功能需求充分描述了软件系统所应具有的外部行为。“需求分析报告”在开发、测试、质量保证、项目管理以及相关项目功能中起着重要作用。
1.4 需求分析的过程
1、首先调查组织bai机构情况，包括了解该组织的部门组成情况，各部门的职能等，为分析信息流程作准备。
2、然后调查各部门的业务活动情况，包括了解各个部门输入和使用什么数据，如何加工处理这些数据，输出什么信息，输出到什么部门，输出结果的格式是什么。
3、协助用户明确对新系统的各种要求，包括信息要求、处理要求、完全性与完整性要求。
4、确定新系统的边界，确定哪些功能由计算机完成或将来准备让计算机完成，哪些活动由人工完成。由计算机完成的功能就是新系统应该实现的功能。
5、分析系统功能
6、分析系统数据
7、编写分析报告
1.5 需求分析的方法
目前，软件需求的分析与设计方法较多，一些大同小异，而有的则基本思路相差很大。从开发过程及特点出发，软件开发一般采用软件生存周期的开发方法，有时采用开发原型以帮助了解用户需求。在软件分析与设计时，自上而下由全局出发全面规划分析，然后逐步设计实现。
从系统分析出发，可将需求分析方法大致分为功能分解方法、结构化分析方法、信息建模法和面向对象的分析方法。
1.5.1 功能分解方法
将新系统作为多功能模块的组合。各功能义可分解为若干子功能及接口，子功能再继续分解。便可得到系统的雏形，即功能分解——功能、子功能、功能接口。
1.5.2 结构化分析方法
结构化分析方法是一种从问题空间到某种表示的映射方法，是结构化方法中重要且被普遍接受的表示系统，由数据流图和数据词典构成并表示。此分析法又称为数据流法。其基本策略是跟踪数据流，即研究问题域中数据流动方式及在各个环节上所进行的处理，从而发现数据流和加工。结构化分析可定义为数据流、数据处理或加工、数据存储、端点、处理说明和数据字典。
1.5.3 信息建模方法
它从数据角度对现实世界建立模型。大型软件较复杂；很难直接对其分析和设计，常借助模型。模型是开发中常用工具，系统包括数据处理、事务管理和决策支持。实质上，也可看成由一系列有序模型构成，其有序模型通常为功能模型、信息模型、数据模型、控制模型和决策模型。有序是指这些模型是分别在系统的不同开发阶段及开发层次一同建立的。建立系统常用的基本工具是E—R图。经过改进后称为信息建模法，后来又发展为语义数据建模方法，并引入了许多面向对象的特点。
信息建模可定义为实体或对象、属性、关系、父类型/子类型和关联对象。此方法的核心概念是实体和关系，基本工具是E-R图，其基本要素由实体、属性和联系构成。该方法的基本策略是从现实中找出实体，然后再用属性进行描述。
1.5.4 面向对象的分析方法
面向对象的分析方法的关键是识别问题域内的对象，分析它们之间的关系，并建立三类模型，即对象模型、动态模型和功能模型。面向对象主要考虑类或对象、结构与连接、继承和封装、消息通信，只表示面向对象的分析中几项最重要特征。类的对象是对问题域中事物的完整映射，包括事物的数据特征(即属性)和行为特征(即服务)。
1.6 需求分析的特点
需求分析的特点及难点，主要体现在以下几个方面。
(1)确定问题难。主要原因：一是应用领域的复杂性及业务变化，难以具体确定；二是用户需求所涉及的多因素引起的，比如运行环境和系统功能、性能、可靠性和接口等。
(2)需求时常变化。软件的需求在整个软件生存周期，常会随着时间和业务而有所变化。有的用户需求经常变化，一些企业可能正处在体制改革与企业重组的变动期和成长期，其企业需求不成熟、不稳定和不规范，致使需求具有动态性。
(3)交流难以达到共识。需求分析涉及的人事物及相关因素多，与用户、业务专家、需求工程师和项目管理员等进行交流时，不同的背景知识、角色和角度等，使交流共识较难。
(4)获取的需求难以达到完备与一致。由于不同人员对系统的要求认识不尽相同，所以对问题的表述不够准确，各方面的需求还可能存在着矛盾。难以消除矛盾，形成完备和一致的定义。
(5)需求难以进行深入的分析与完善。需求理解对不全面准确的分析，客户环境和业务流程的改变。市场趋势的变化等。也会随着分析、设计和实现而不断深入完善，可能在最后重新修订软件需求。分析人员应认识到需求变化的必然性，并采取措施减少需求变更对软件的影响。对必要的变更需求要经过认真评审、跟踪和比较分析后才能实施。
二、图类关键字
2.1 活动图（activity graph）认知说明：
•活动图和交互图是UML中对系统动态方面建模的两种主要形式
•交互图强调的是对象到对象的控制流，而活动图则强调的是从活动到活动的控制流
•活动图是一种表述过程基理、业务过程以及工作流的技术。它可以用来对业务过程、工作流建模，也可以对用例实现甚至是程序实现来建模
•UML 2.0而言，去除了“活动图是状态图的一种特例”这一规定
活动图案例分析：
购物活动图
1、 泳道分为：会员泳道和系统泳道。会员选择商品并加入购物车，系统完成订单生成及其支付完毕。
2、 开始节点：会员添加商品到购物车，点击【订单确认】，开始交于系统处理订单流程
3、 结束节点：商品发送完毕和付款成功，订单处理流程结束
4、 活动状态：产生订单、Check Credit Cart核对信用卡、Check Stock 核对库存量、Deliver Goods 发送商品、Process Credit Cart付款
5、 分叉与汇合：【产生订单】为检查库存量和会员支付金额是否足够，如果不足，取消订单，如过库存量和支付金额足够，发送商品和付款，最后汇合为订单完成。
小组房屋出租系统活动图分析：下面是我们房屋出租系统的登录活动图，由用户进行登录来实现对房屋出租系统的操作。活动图是UML用于对系统的动态行为建模的另一种常用工具，它描述活动的顺序，展现从一个活动到另一个活动的控制流。活动图在本质上是一种流程图。活动图着重表现从一个活动到另一个活动的控制流，是内部处理驱动的流程。首先在这个登录功能模块中，开始时是输入账号和密码，假如密码错误，那么就会退出系统，否则如果密码正确，那么就可以进行房屋出租系统，之后便可以进行查询等操作的实现。
2.2 类图(class diagram)的认知说明：
类图(Class diagram)是显示了模型的静态结构，特别是模型中存在的类、类的内部结构以及它们与其他类的关系等。类图不显示暂时性的信息。类图是面向对象建模的主要组成部分。它既用于应用程序的系统分类的一般概念建模，也用于详细建模，将模型转换成编程代码。类图也可用于数据建模。
小组房屋出租系统类图分析：类图用来描述系统的结构。类是用来指定一组对象共有的结构和行为的抽象。从上述分析我们可以找出八个类登录、房屋、合同、租金、管理、查询统计维护。这八个类之间有着一定的关联。首先以登录类为前提登录后就可以进行房屋、合同、租金的查询、管理统计和维护操作。而各种操作是对房屋、合同和租金进行的。合同的变化可能引起租金的变化每个合同又对应一个房屋。房屋与合同之间是一一对应关系，合同与租金之间也是对应关系。
2.3 协作图(collaboration diagram)认知说明：
协作图是动态图的另一种表现形式，它强调参加交互的各对象结构的信息。协作图是一种类图，它包含类元角色和关联角色，而不仅仅是类元和关联。协作图强调参加交互的各对象的组织。
示例简介 : 汽车租赁流程;
-- 涉及到的对象 : Customer (客户), Order (订单), Worker (工人), Record (记录), Car (汽车);
-- 流程简介 : 客户写好订单,工人核对订单,核对后订单存在,允许客户取车,工人填写 记录,并将车取出;
小组房屋出租系统协作图分析：我们房屋出租系统与上面的汽车租赁流程相似，租客看好房子，在网上订单,房东核对订单,核对后订单存在,允许租客租房,房东填写记录,并将钥匙取出给租客。
2.4 组件图(component diagram)的认知说明：
组件图的主要目的是显示系统组件之间的结构关系。在UML 1.1中，组件表示实现项目，比如文件和可执行文件。不幸的是，这与更常用的术语“组件”相冲突，后者指的是组件等东西。随着时间的推移，在连续的统一建模语言版本中，组件最初的统一建模语言含义大部分都丢失了。UML 2正式改变了组件概念的本质含义；在UML 2中，组件被认为是系统或子系统中提供一个或多个接口的自治的、封装的单元。虽然UML 2规范并没有严格地说明它，但是组件是更大的设计单元，代表通常使用可替换的“模块”来实现的东西。
案例：显示订单系统组件如何依赖于其他组件的组件图
该图显示了订单系统组件依赖于客户存储库和库存系统组件。请注意，在图中，接口CustomerLookup和ProductAccessor的名称是重复的。虽然在这个例子中这看起来是不必要的重复，但是根据实现的不同，符号实际上允许每个组件上有不同的接口(和不同的名称)(例如，一个组件提供的接口是一个更小的所需接口的子类)。
小组房屋出租系统组件图分析：组件图的基本元素很少，都是围绕组件以及组件的关系展开。核心的元素即组件，用于表达系统的物理或逻辑结构。组件通过接口来描述自己对外暴露的行为及依赖，接口包含需求接口（required interfaces）以及提供接口（provided interfaces）。端口是组件对外的交互点，我们约定组件间的交互仅能通过端口，因此端口限制了组件的可见性，通过端口我们可以了解到组件能够支撑的功能范围。 连接器表示的是组件间是通过哪个端口、接口进行通讯的，表明的不是组件关系，而是表明组件间建立通讯的标志。
2.5 部署图(deployment diagram)认知说明：
部署图示例——分布式系统建模
- 针对更简单的客户机/服务器系统，确定系统的设备和处理器。
- 如果您需要对系统网络的性能或网络变化的影响进行推理，请确保将这些通信设备建模到足以进行这些评估的详细程度。
- 请密切关注节点的逻辑分组，这可以通过使用包来指定。
- 使用部署图对这些设备和处理器进行建模。在可能的情况下，使用通过遍历系统网络来发现系统拓扑的工具。
- 如果你需要关注你的系统的动态，引入用例图来指定你感兴趣的行为类型，并用交互图来扩展这些用例。
- 在对一个完全分布式的系统建模时，通常将网络本身具体化为一个节点。即以互联网、局域网、广域网为节点
该示例显示了完全分布式系统的拓扑结构。
小组房屋出租系统部署图分析：系统用部署图主要是对于可视化、指定和记录嵌入式、客户机/服务器和分布式系统非常重要，对于通过正向和反向工程管理可执行系统也很重要。利用部署图主要是对于我们小组的系统好处是显示了运行时系统的结构，捕获将用于实现系统的硬件以及不同硬件项目之间的链接，对物理硬件元素和它们之间的通信路径进行建模，可以用来规划系统的架构，对于记录软件组件或节点的部署也很有用。
2.6 对象图(object diagram)认知说明：
对象是运行时特定时刻的类的实例，它可以有自己的状态和数据值。同样是静态的UML对象图是类图；它显示了系统在某个时间点的详细状态的快照，因此对象图包含了对象及其关系，这些对象及其关系可以被认为是类图或通信图。
对象图显示了实例化的类和定义的类之间的关系，以及系统中这些对象之间的关系。当您的系统类图非常复杂时，它们对于解释系统的较小部分是有用的，有时在图中建模递归关系也是有用的。
说明对象图是什么样子的最好方法是显示从相应类图派生的对象图。
以下订单管理系统显示了它们之间的关系。这个小的类图显示了一个大学部门可以包含许多其他部门，下面的对象图实例化了类图，用一个具体的例子来代替它。
小组房屋出租系统对象图分析：由于类图只是展示了程序的静态类结构，因此通过类图看懂代码的意图是很困难的。系统运用对象图，能够对于我们系统所需要创建的类图或者分析源代码时，可以通过对象图来细化分析。这对于我们小组实现各种功能模块有很大的帮助。
2.7 序列图(sequence diagram)认知说明
序列图主要用于以交互发生的顺序显示对象之间的交互。很像类图，开发人员通常认为序列图是专门为他们准备的。然而，一个组织的业务人员可以通过显示各种业务对象如何交互来发现序列图，这对沟通业务当前的工作方式很有用。除了记录组织的当前事务，业务级序列图还可以用作需求文档来传达未来系统实现的需求。在项目的需求阶段，分析师可以通过提供一个更正式的细化层次，将用例带到下一个层次。当这种情况发生时，用例通常被细化成一个或多个序列图。
实例：下图就是顾客、ATM和银行的序列图
小组房屋出租系统序列图分析：既用来形式化系统的行为，也可用来可视化对象间的通信。包含在用例中的对象称为参与对象，序列图表示发生在这些对象间的相互作用。以下序列图是租房者各自的序列图描述：租房者序列图中可以看出：租房者先提出自租房的要求(房型面积等)房东根据要求进登录查询。查询后如果租房者确认就可以签合同，签好合同再把合同录入。
2.8 状态图(statechart diagram)认知说明：
状态图(Statechart Diagram)是描述一个实体基于事件反应的动态行为，显示了该实体如何根据当前所处的状态对不同的事件做出反应。通常我们创建一个UML状态图是为了以下的研究目的：研究类、角色、子系统、或组件的复杂行为。
在UML中，状态图由表示状态的节点和表示状态之间转换的带箭头的直线组成。状态的转换由事件触发，状态和状态之间由转换箭头连接。每一个状态图都有一个初始状态（实心圆），用来表示状态机的开始。还有一个中止状态（半实心圆），用来表示状态机的终止。状态图主要由元素状态、转换、初始状态、中止状态和判定等组成，一个简单的状态图如下：
小组房屋出租系统状态图分析：可以清晰地在图中看到各种状态事件的发生，开始时房东提供房屋信息，有房客选定房屋，假如房屋为空，则房客可以提交租房申请，系统中收到申请，之后就是房客进行提交房租的三种状态方式，第一种是选择线上支付，成功之后就是租房成功；第二种是选择线下现金支付，交易成功之后事件也结束了；第三种是未按时支付提交的租金，则租房失败，事件结束。
2.9 用例图(use case diagram）认知说明：
用例图是中的动态或行为图UML。用例图使用参与者和用例对系统的功能进行建模。用例是系统需要执行的一组动作、服务和功能。在这种情况下，“系统”是正在开发或运行的东西，如网站。“参与者”是指在系统中按照定义的角色运行的人或实体。
小组房屋出租系统用例图分析：对于房屋出租系统的用例图来说，分为管理员、房东和房客三个角色。对于管理员来说，具有信息管理和合同管理，信息管理包含了增删改查功能；对于房客来说，具有租房和个人信息管理，租房包括提交订单以及订房成功等事件，个人信息管理包含了增删改查功能；对于房东来说，具有房屋管理和个人信息管理，个人信息管理包含了增删改查功能。
2.10 上下文图(Context Diagram)认知说明：
这内外关系图视觉文档是一个简单的图表，显示了向数据仓库/商业智能系统提供数据的源系统，以及支持的主要用户组成部分和下游信息系统。一旦项目架构师完成了所有的研究和它所代表的艰难思考，这个简单的图表只需要几分钟就可以画出来。这个图表的简单性使得它非常适合敏捷需求管理。有了这样一个特定的目的和简单的语法，这个工件的现有版本很容易作为业务来更新在项目的生命周期中，随着条件的变化和设计见解的出现。下图显示了在我们的示例收入保证项目的愿景文档中可能找到的上下文图。
上下文图通常被称为“0级”数据流图因为如果在源和目标之间的连接上放上箭头，图表就可以作为数据流图许多分析师为传统管理的项目准备的数据包。敏捷上下文图只能在中间或少数几个位置显示一个EDW框，如示例所示，这取决于分解数据仓库/商业智能工具的主要层是否为业务涉众和技术团队成员增加了清晰度。通常，要得到正确的图表，最困难的是简单地选择要描述的源。
小组房屋出租系统上下文图分析：上下文图极大地降低了项目风险，因为团队的业务伙伴很容易理解它们。对于房屋出租系统，利用上下文图也清楚地表明了开发团队认为哪些用户组是它的房客。
2.11 数据流图(Dataflow Diagram)认知说明：
数据流图（DFD）是系统内信息流的传统视觉表示。一个整齐而清晰的DFD可以用图形描绘出大量的系统需求。它可以是手动的，自动的或两者的组合。
它显示了信息如何进入和离开系统，什么改变了信息以及信息的存储位置。DFD的目的是显示整个系统的范围和界限。它可能被用作系统分析员和任何参与系统的人之间的交流工具，作为重新设计系统的起点。
它通常以上下文图开始，作为DFD图的0级，这是整个系统的简单表示。为了进一步阐述，我们深入到一级图，将较低级别的功能从系统的主要功能中分解出来。当需要进一步分析时，这可能会继续发展成为二级图。级别3，级别4等等是可能的，但是超出级别3的任何东西都不是很常见。请记住，分解特定函数的细节水平实际上取决于函数的复杂性。
小组房屋出租数据流图分析：对于我们系统来说，可以通过结合来自房客（外部实体）的订单信息和来自房客（数据存储）的房客信息，流程订单（过程）然后在数据库中创建交易记录。创建从流程订单到交易的数据流。
2.12 状态转换图(State Transition Diagram)认知说明：
状态转换图是以指示系统的所有可能状态以及这些状态之间的转换。
案例分析：
在下图中，我们展示了蚊子的生命周期。它开始它的生命，四处移动，直到它死去或被人类杀死。如果这种情况没有发生，它会落在一个人身上，每次都有可能咬他们。在液体交换过程中，一个或另一个相关实体可能感染疟疾。需要注意的是，蚊子从来不休息，只要和人在一个地方，就会咬人。
小组房屋出租系统状态转换图分析：状态转移图对于我们来说，可以清楚地了解房东与房客之间的各种状态之间的转换，例如房客租房事件，房客支付与不支付租金都是两种事件的状态，他们都有不同的结果。
2.13 实体关系图(entity-relationship-diagram)认知说明：
E-R图即实体-联系图(Entity Relationship Diagram)，是指提供了表示实体型、属性和联系的方法，用来描述现实世界的概念模型。E-R方法:是“实体-联系方法”（Entity-Relationship Approach）的简称。它是描述现实世界概念结构模型的有效方法。
实体联系模型，实体关系模型或实体联系模式图(ERD)是由美籍华裔计算机科学家陈品山(Peter Chen)发明，是概念数据模型的高层描述所使用的数据模型或模式图，它为表述这种实体联系模式图形式的数据模型提供了图形符号。这种数据模型典型的用在信息系统设计的第一阶段；比如它们在需求分析阶段用来描述信息需求和/或要存储在数据库中的信息的类型。但是数据建模技术可以用来描述特定论域(就是感兴趣的区域)的任何本体(就是对使用的术语和它们的联系的概述和分类)。在基于数据库的信息系统设计的情况下，在后面的阶段(通常叫做逻辑设计)，概念模型要映射到逻辑模型如关系模型上；它依次要在物理设计期间映射到物理模型上。注意，有时这两个阶段被一起称为”物理设计”。
ER图中包含了实体(即数据对象)、关系和属性等3种基本成分，通常用矩形框代表实体，用连接相关实体的菱形框表示关系，用椭圆形或圆角矩形表示实体(或关系)的属性，并用直线把实体(或关系)与其属性连接起来。
数据对象彼此之间相互连接的方式称为联系，也称为关系。联系可分为以下 3 种类型：
(1) 一对一联系 (1 ∶ 1)
例如，一个部门有一个经理，而每个经理只在一个部门任职，则部门与经理的联系是一对一的。
(2) 一对多联系 (1 ∶ N)
例如，某校教师与课程之间存在一对多的联系“教”，即每位教师可以教多门课程，但是每门课程只能由一位教师来教【见图1】。
(3) 多对多联系 (M ∶ N)
例如，学生与课程间的联系(“ 学 ”)是多对多的，即一个学生可以学多门课程，而每门课程可以有多个学生来学。
小组房屋出租系统实体关系图分析：对于我们系统的E-R图如下：
2.14 交互图(Interaction Diagram)认知说明：
交互图是描述对象之间的关系以及对象之间的信息传递的图。序列图（时序图）、协作图（通信图）、交互概览图统称交互图。
交互图汇集许多现有的模型和建模元素:从用例模型、用例、参与者、用例场景和描述；来自班级图表、每个场景中涉及的对象以及对类的操作。
小组房屋出租系统交互图分析：通过交互图我们可以看出房屋出租系统之中的流程，这有利于我们对系统的了解，特别是租房的步骤。
2.15 状态机图(State Machine Diagram)认知说明：
一个实体的行为不仅是其输入的直接的结果，而且还取决于其之间的状态。一个实体的过去的历史能够通过有限状态机图或者传统上被称为自动机的图来建模。UML状态机图(UML State Machine Diagram)(有时被称为 状态图(state diagram), 状态机(stae machine) 或 状态图(state chart))展示了一个实体的不同的状态。状态机图同样也可以展示一个实体如何通过从一个状态到另一个状态的改变来相应各种各样的事件。
状态机图经常地用来描述一个对象的状态依赖行为。 一个对象会依据其当前所处的状态来以不同的方式响应同样的事件。状态机图通常被应用于对象，但是也可以被应用于对其他实体有行为的任何元素比如: 参与者(actors)、 用例(use case)、 方法(methods)、 (子系统(subsystems systems))等。他们经常与交互图被结合使用(通常是时序图(sequence diagram))。
小组房屋出租系统状态机图分析：通过状态机图，我们可以了解哪种状态会转化为哪种状态结束。在这之间会涉及许多元素，如房东，房客，用例等，让我们知道流程是如何的。
三、模型关键词
3.1 上下文模型(Context model)认知说明：
基于系统上下文图，我们现在查看系统的传入和传出信息。事实上，一个参与者与系统相连意味着他们向系统提供信息，或者从我们的系统，或者两者都有。在这个早期项目阶段，这里交换的信息类型以及谁参与交换是众所周知的。虽然你现在可能会皱眉头，但这不是说外部系统的确切协议应该是什么样子的问题。我们最初寻找的信息要抽象得多。车载电脑从客户那里获得什么样的信息？对，比如卡数据或者个人识别码。
我们想在这一点上写下这些信息，这不是实现完整性的问题。这相当于记录参与者迄今为止获得的知识，并提高对我们的系统嵌入其环境的方式的理解。
系统上下文模型它的信息流基本上服务于两个目标:
1.信息流导致对领域更好的理解。我们只对领域相关信息感兴趣，对技术细节不感兴趣。该图让我们很好地了解了系统是如何嵌入其环境的。该术语的含义领域是相对的。什么是领域相关的取决于系统的类型。如果系统非常专业，比如引擎控制，那么领域相关的东西会比我们的系统更专业。
2.信息流作为基本信息来确定系统所需的服务——用例。流向系统的信息是对环境服务的潜在请求。因此，我们关注这一信息流方向。
信息流是UML 2的一个新概念。它原则上是一种数据流建模。这是许多人在UML 1中忽略的技术。数据流建模是结构化分析的一个组成部分8]，它也用于系统工程，尽管它主要是一种软件开发技术。然而，像UML这样的纯面向对象的符号不太适合支持过程世界的技术。幸运的是，程序世界和面向对象世界互为敌人、互相排斥的时代大多被克服了。今天，来自过程世界的已被证明的技术在面向对象方面没有被拒绝，而是在范例中被进一步开发和集成。软件开发领域的面向对象概念在系统工程中并不占主导地位。事实上，SysML抑制了它们，部分是有意的。例如，SysML中没有类和对象。
现在，看看我们的系统上下文模型。我们逐个演员地思考信息流。我们主要对从演员到系统的方向感兴趣。我们想知道演员从我们的系统中请求什么样的服务。如果你想不出任何有意义的信息，就忽略信息流。我们不必猜测。
参与者和系统之间的信息流由参与者/系统关系顶部的黑色三角形表示。三角形表示信息流的方向。三角形旁边是信息类型，例如卡片数据。
小组房屋出租系统上下文模型分析：在上下文模型中，最重要的是区分出什么是系统内的，显示出哪些参与者与系统交互。使用最初的Booch标记法，系统和参与者都可以使用云图来表示。在云之间的连线用来表示关系；而箭头标识参与者与系统之间的重要信息。例如在我们房屋出租系统之中，当房客请求系统提供信息以便对自己看好的房子签约，系统将返回确认信息，例如账号。当房客启动一个任务（申请租房），系统则返回一个确认的报表。
3.2 类模型(Class model)认知说明：
类是一种标准的UML构造，用于详细说明在运行时将根据其生成对象的模式。类是一种规范-对象是类的实例。类可以从其他类继承（即，它们继承其父类的所有行为和状态并添加自己的新功能），具有其他类作为属性，将职责委派给其他类并实现抽象接口。
类模型是面向对象的开发和设计的核心-它表示系统的持久状态和系统的行为。类封装状态（属性）并提供服务以操纵该状态（行为）。良好的面向对象设计限制了对类属性的直接访问，并提供了代表调用者操纵属性的服务。数据的这种隐藏和服务的公开确保了仅在一个地方并根据特定规则进行数据更新-对于大型系统，在许多地方可以直接访问数据元素的代码的维护负担非常高。
该类表示如下：
小组房屋出租系统类模型分析：在系统中运用了类模型的话，有利于我们编写房屋出租系统的代码，同时又可以清晰的了解到各种模块（如：房源管理模块）的各个数据表的字段以及它们之间的关系，更容易让开发人员与系统进行交互。
3.3 模型精化（model elaboration）认知说明：
模型精化侧重于组合或扩展一个模型，例如将其嵌入到一个更大的系统中，添加元素或子模型，或者将其与其他模型连接起来，形成多级或复合模型。模型精化设计模式描述任务的特征和可变特征，以及潜在的工作成果和观察结果。
小组房屋出租系统模型精化条件分析：在我们软件开发中，往往都需要对一些模型进行精化，特别是UML图，利用一些精化的规则，让我们UML图更加协调，更加通俗易懂。这样，我们可以从软件开发的需求分析和设计阶段检查模型的协调性，通过协调地精化模型后生成代码。用这种方法，我们可在软件设计的早期阶段发现不协调问题，减少生成代码后除错所产生的代价。这样利于我们开发房屋出租系统。
3.4 模型元素（model element）认知说明：
UML中模型元素太多了，比如用例图中的元素有用例，角色，扩展关系，包含关系，类图中专的元素有类，接口，关联等等属，每一种框图都有各自独有的元素。
模型元素之间的可追溯性
每个视角的模型元素通过可追溯性和合理性链接与先前（或有时是先前）视角的模型元素链接。
在大多数情况下，这些链接连接具有相同性质的元素
此外，在PBS中，配置项可以链接到PA的行为和托管组件，也可以链接到物理链接和端口。
但是，可以使用性质不同的模型元素之间的链接：例如，系统与参与者之间的交换或物理链接可以导致负责连接的组件具有以下视角。
此外，透视图内部的可追溯性链接有时可能会有用：我们可以引用分配给端口的交换项之间的链接，或承载这些交换项的功能和行为交换之间的链接（在实现方式上与功能愿景不同）。系统级别和组件级别等的模式。
小组房屋出租系统模型元素分析：对于我们系统来说，需要的模型元素有很多，比如我们系统的房东等一些涉众角色都是模型元素。同时对于模型元素的可追溯性来说，好比我们系统中的用例图，每个涉众角色之间都是一一对应的，如房东对应着房源的管理。
3.5 定义模型[MOF]认知说明：
元对象设施(MOF)是一个对象管理组(OMG)标准，作为定义统一建模语言的元建模架构开发，因此提供了一种定义语言或数据的结构或抽象语法的方法。MOF设计为四层架构；作为一个封闭的、严格的元建模架构，每一层上的每个模型元素都是上一层模型元素的严格实例。
简化后，财政部使用类来定义元层上的概念(模型元素)。然后，这些类(概念)可以通过下面模型层的对象(实例)来实例化。因为M2图层上的元素是一个对象(M3模型元素的实例)以及一个类(M2图层的概念)，所以使用了clabject的概念——类和对象这两个词的合并。
由于模型框架模型和统一建模语言结构模型之间的相似性，模型框架元模型通常被建模为统一建模语言类图表。您还可以使用图表工具箱(单击“汉堡”图标并选择“元模型”)来创建MOF模型元素和连接器。
该图展示了元对象工具的分层体系结构。
小组房屋出租系统定义模型[MOF]分析：通过定义模型，主要是可以通过模型层的对象(实例)来实例化。例如，房屋必须有一个对象，里面存储着有关于房屋的一切，如面积，租金等一些元素，通过定义模型之后能达到很好地封装。
3.6 实体关系模型(Entity-Relationship Model)认知说明：
ER 模型主要有三个关键方面：
- 数据结构：ER 模型中的数据表现为实体与属性之间的关系
- 数据完整性：对于ER模型，键（key）用于实体或者关系类型，而基数约束或者参与约束用于关系类型。
- 数据操作：ER 模型中不存在对数据的任何操作。
ER 模型中的关键概念与关系型数据库的概念联系如下：
ER 模型的基本图表元素有：
构建 ER 模型的流程
- 识别所以实体类型（包括弱实体类型）；
- 识别所有关系类型（包括 ISA 关系和依赖关联）；
- 识别所有实体和关系类型对应的属性（以及每个属性的定义域）；
- 识别每个实体的主键；
- 辨别步骤 2 中找出的所有关系中的基数比例；
- 确定上述关系的参与约束；
- 确定 ISA 关系中的分离约束和完整性约束。
小组房屋出租系统实体关系模型分析：通过E-R模型，能够让我们知道实体与实体之间的关系以及它们的功能，这对于我们房东管理模块和房客管理模块有很大帮助。
3.7 原始类型(Primitive Type)认知说明：
原语类型是指不同技术和编程语法系统中的一系列不太复杂的变量和数据类型。其中一些是由变量是否需要子结构，或者数据类型有多简单来表示来定义的。其他的由它们是机器语言的一部分还是可访问的来定义。
一些被指定为基本类型的常见数据类型包括布尔值、字符串和整数。除了以上，还有很多其他的方法可以对图元类型进行分类。一些开发人员对给定语言(如C#或C++)中什么是基元类型保持激烈的争论，在这些语言中，一些编程语法解释可能没有具体定义基元类型。在其他情况下，基元类型可以是给定编程工具容易呈现的数据类型。例如，如果一个编程资源能够用一个简单的命令生成简单的多边形，但不能生成更复杂的形状，那么更简单的形状可以称为图元类型。
小组房屋出租系统原始类型分析：原始类型是我们高级编程语言的基本类型，我们在开发房屋出租系统时也需要原始类型，例如我们的房子名称就需要String类型来定义。
3.8 需求模型(Requirements model)认知说明：
需求模型的目标是划分系统的边界，并且能够定义系统必须提供的功能。这个模型的功能可以被当作为系统开发者和系统订购者之间的合同，同时他是构成了开发者的视图来理解客户希望的实现的功能。因此对于哪些没有OOSE实践经验的人也必须能够理解需求模型是非常基本的要求。
需求模型将领导和管理其他所有模型的开发工作，因此用例模型是贯穿于整个系统开发过程中最核心的模型。
需求模型将会由分析模型来组织基本框架，由设计模型来描述具体的组成构件，由实施模型来最终完成实现，并由测试模型来验证功能是否到达。所有其他的模型不但需要根据需求模型来进行模型校验，而且其他所有模型需要直接根据需求模型来确定的进行开发。需求模型的功能同时也将作为系统操作指南和说明手册编写开发的基础， 因为系统应当执行的任何事情都是基于一个用户的观点来进行描述的。需求模型，尤其是用例模型，将是在整个OOSE设计过程中运行的一条主线。
需求模型包含3部分，它们是用例模型，问题领域对象模型和用户接口描述。
小组房屋出租系统需求模型分析：对于房屋出租系统，我们需要用到需求模型中的用例模型，问题领域对象模型和用户接口描述，通过用例模型我们可以知道涉众之间的关系，问题领域模型可以了解涉众的问题域，用户接口是用来解决房客在哪里租房的问题。
3.9 规格模型(Specification Model)认知说明：
当根据需求系统地验证设计模型时，开发过程包括为每个需求生成测试用例。这些测试验证了用于产品代码生成的设计模型，并有助于获得设计模型满足需求的信心。规格型号是一个可执行的实体，允许您通过利用仿真设计验证器能力。
如果您有一组用自然语言文本编写的需求，您可以使用Simulink将它们转换成正式的(可执行的)规范。这些然后成为一个规格模型。与设计模型不同，规范模型只指定该做什么而不是怎么做。它在更高的层次捕获需求，在更低的层次隐藏细节。
使用规范模型的优点是:
- 它以系统的方式验证需求集。
- 它自动化了基于需求的测试。
- 它有助于在开发阶段的早期识别您的需求和设计模型中缺失的需求、设计错误或不一致。
小组房屋出租系统规格模型分析：对于房屋出租系统的需求报告中，需要按照一定的规格去完善，否则，需求报告书就会杂乱无章。
3.10 静态模型(Static Model)认知说明：
静态模型用于面向对象分析和面向对象设计活动。下图中显示了一个对象模型对于一个自动取款机系统，并说明主要对象及其关系或关联。这是面向对象分析在寻找系统的关键现实世界抽象时使用的主要模型之一。
小组房屋出租系统静态模型分析：与动态模型不同的是，静态模型是放在那里不动的，一般是供观赏和收藏的。通过静态模型，我们可以对于房屋出租系统的架构更加了解。
3.11 动态模型(Dynamic Models)认知说明：
动态模型，是指描述系统各组成部分之间及系统与外界之间的平衡关系以及这些关系的运动过程的模型。如系统动力学模型，弹簧振子的位移方程式等。
动态模型能反映系统在运动变化过程中各种因素相互作用的动态特征，与静态模型相比，它加进了时间因素，因而能更有效地实现对真实系统的模拟。
动态模型描述与操作时间和顺序有关的系统特征、影响更改的事件、事件的序列、事件的环境以及事件的组织。
大量成功的软件工程实践难了动态模型的补助性，而动态模型的优越性使得该方法被广泛接受。动态建模的优势性列举如下：
1：如同建筑物或永恒的建筑模型可显示施工场地的结构和设计一样，动态模型使用户和开发人员能更容易地理解构思中的系统。
2：建模有助于解释状态的更改，并通过将不重要的方面与重要的方面分开而子降低复杂度。借助每个状态图和时序图可降低系统的复杂度。
3：借助于动态模型，可监视构思中的系统是否存在任何类型的缺陷，如果在开发开始后才发现这些缺陷，则可能需要付出昂贵的代价。
4：维护模型比维护系统容易得多，成本也降低了很多。
小组房屋出租系统动态模型分析：在房屋出租系统中可以借助时序图、状态图和活动图来描述系统的动态模型。动态模型的每个图都有助于理解系统的行为特征。对于开发人员来说，动态建模具有明确性、可视性和简易性的特点。
3.12 结构模型(Structural Model)认知说明：
结构模型的目的在于使知识和组织系统化。有各种分类，如因果结构模型、功能结构模型、机械结构模型、统计结构模型等。因果结构模型为自然科学所普遍使用，观察者依据这种模型而预言系统的未来发展情况；功能结构模型则是对人类社会的观察模式，它把一种文化或一个社会看成是为了达到某种目的而拟定的一系列手段和方法的组织；机械结构模型表现出一个结构的元素与现象的相似程度；统计结构模型是一个结构的元素与现象并不相同，只是在统计意义上的大致分类。这些分类方法很难完全说明结构模型的特征。一般认为，结构模型作为一种说明现象的方法是有用的.在不能以还原的方法说明观察与客体之间的相同与否时，可以用以作为进一步的解释
小组房屋出租系统上下文图分析：在房屋出租系统之中，不仅可以借助实体来表达房屋的结构特点，如面积，价格等特征，更加清晰的解释其中的结构，还可用于观摩、分析、研究实体，更有利于房东进行展示房屋结构和与房客交流。
3.13 模型元素（model element）认知说明：
UML中模型元素太多了，比如用例图中的元素有用例，角色，扩展关系，包含关系，类图中专的元素有类，接口，关联等等属，每一种框图都有各自独有的元素。
模型元素之间的可追溯性
每个视角的模型元素通过可追溯性和合理性链接与先前（或有时是先前）视角的模型元素链接。
在大多数情况下，这些链接连接具有相同性质的元素
此外，在PBS中，配置项可以链接到PA的行为和托管组件，也可以链接到物理链接和端口。
但是，可以使用性质不同的模型元素之间的链接：例如，系统与参与者之间的交换或物理链接可以导致负责连接的组件具有以下视角。
此外，透视图内部的可追溯性链接有时可能会有用：我们可以引用分配给端口的交换项之间的链接，或承载这些交换项的功能和行为交换之间的链接（在实现方式上与功能愿景不同）。系统级别和组件级别等的模式。
小组房屋出租系统模型元素分析：对于我们系统来说，需要的模型元素有很多，比如我们系统的房东等一些涉众角色都是模型元素。同时对于模型元素的可追溯性来说，好比我们系统中的用例图，每个涉众角色之间都是一一对应的，如房东对应着房源的管理。
3.14 元模型(MetaModel)认知说明：
元模型定义了描述某一模型的规范，具体来说就是组成模型的元素和元素之间的关系。元模型是相对与模型的概念,离开了模型元模型就没有了意义。下面来看一个类模型与其元模型的例子：
小组房屋出租系统元模型分析：通过元模型，我们可以清楚地知道每个元素之间的关系，特别是在房屋出租系统之中，我们可以看到房屋的面积与价格之间的关系。
3.15 元元模型(Meta-Meta Model)认知说明：
元元模型层是由元元数据的结构和语义的描述组成，这层的主要职责是为了描述元模型而定义的一种"抽象语言"。元元模型的定义要比元模型更加抽象、简洁(即元元模型是关于元元数据本身的更深一个层次的抽象,即是描述元元数据的抽象.)。
元元模型用来具体化类、用例、构件以及其他所有UML元素的语言，纳入到模型中。一个元元模型可以定义多个元模型，而每个元模型也可以与多个元元模型相关联。通常所说的相关联的元模型和元元模型共享同一个设计原理和构造，这也不是绝对的准则。每一层都需要维护自己设计的完整性。一个元模型是元元模型的一个实例。
小组房屋出租系统元元模型分析：通过元元模型，我们可以清楚地知道每个元素之间的关系，它比元模型更加抽象，但是在房屋出租系统之中，我们可以更紧凑地看出房屋的面积与价格之间的关系。
3.16 平台独立模型(Platform independent model)认知说明：
平台独立模型类似于系统分析模型，它处于中间抽象层次，关注系统的整个架腹实现，但却忽略掉与平台相关的部分。平台独立模型可以转换成多个平台相关模型；
1、侧重于高级业务逻辑，不考虑系统实现技术的特点。
2、模型不包含对底层技术的引用平台。
小组房屋出租系统平台独立模型分析：系统通过平台独立模型可以转换为与多个平台相关的模型，如元模型。
3.17 平台特定模型(Platform specific model)认知说明：
PSM模型是MDA框架里面的一个特定模型，PSM 代表应用具体技术后的模型。
MDA最大的好处就是业务模型的持久价值，但是付出的代价是增加了抽象层，而目前看来，层之间的转换并不是我们所期待的那样顺畅，至少，从PIM到PSM，从PSM到代码，这个实现的过程要远比从3GL生成机器代码来得困难。在建模技术方面，UML正在暴露其固有的缺陷，它需要扩展更多的机制来支持精确建模和分析模型，虽然目前OCL为精确建模提供了一定的支持，但是这种支持距离可执行模型的理想还很遥远。回顾MDA的历史，我们可以看出UML的巨大成功为MDA的产生奠定了坚实的基础，同时也感觉到：在由软件工艺到软件工程的漫漫长路中，MDA只不过是向前迈进了一小步，但却给整个软件业掀起了一场波澜，它在模型定义、开发过程等诸多方面都将对未来IT技术产生深远的影响。
小组房屋出租系统平台特定模型分析：房屋出租系统运用MDA框架可以使得我们的系统能够灵活地被实现、集成、维护和测试，系统的轻便性、互操作性和可重用性都是可以长期保持的，能够应对未来的变化。
四、需求关键词
4.1 需求分析(Requirements analysis)认知说明：
在软件生命周期中，需求分析（Requirements Analysis）是最重要的一个阶段。软件需求分析的质量对软件开发的影响是深远的、全局性的，高质量分析软件需求对软件开发往往起到事半功倍的效果，这就是所谓的“磨刀不误砍柴功”。
软件需求分析任务：
即借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系统的 “做什么” 的问题。
软件需求分析原则：
软件需求分析过程：
在这一阶段形成的文档包括：
软件需求说明书
数据要求说明书
初步的用户手册
修改、完善与确定软件开发实施计划
软件需求分析方法：
小组房屋出租系统需求分析分析：在做需求分析报告时，因为用户的需求在不断变化，所以我们在做需求分析时既要满足当前用户的需求，也要预防用户可能在以后需要到的功能。另外在做需求分析时也要注重用户的参与。我们房屋出租系统的房客需求也是会变的，我们需要不定期地去了解他们的需求。
4.2 需求基准(Requirement Baseline)认知说明：
软件工程验证任务旨在确认软件产品架构是完整的、内部一致的，并且准备好过渡到软件开发的实现阶段。这包括验证软件架构的元素(需求基线、功能和物理架构)，并确认软件实现符合结构配置规格。
需求基线主要分为以下4个方面：
1 验证需求基线
必须对需求基线进行验证，以确保每一个需求都可以追溯到涉众的需求，并且基线代表了软件产品的一整套一致的需求。需求基线由软件需求和接口规格还有运营模式它们的来源。
2 验证功能架构
必须验证功能架构，以确保功能分解是非复杂的，并且在子功能之间有效地分配性能度量。顶层功能必须可追溯到软件需求基线和操作模型。行为模型必须经过验证，以准确表达数据处理交易和控制场景。必须对功能规范进行评估，以验证它们是否准确符合功能分解并表达分配的性能度量。
3 验证物理架构 必须验证物理架构，以确保结构配置为软件实现、集成，和测试。必须对结构单元规范进行验证，以充分吸收分配的功能单元规范，并提供追溯至原始功能单元规范的可追溯性。必须验证概念组件，以确保它们正确反映主要的数据处理事务。必须对结构部件规范进行验证，以解决因吸收结构配置的低层元素而产生的综合功能和性能特征。必须确认结构配置中的要求可追溯性。
4 验证软件实施 验证软件实施计划、时间表和工作包是否正确符合结构配置。这包括设计、编码和测试结构单元，以及执行软件集成和测试。必须审查结构组装工作包，以确保为软件测试存根的准备和验证分配足够的资源。软件单元设计同行评审应该提供证据来验证与结构单元规范的一致性。组件集成同行评审应该提供证据来验证与结构单元规范的一致性。
小组房屋出租系统需求基准分析：对于房屋出租系统，需求基准是非常必要的。要想软件产品架构是完整的、内部一致的，并且准备好过渡到软件开发的实现阶段，我们必须要验证需求基准，对我们系统的审查房屋等元素必不可缺。
4.3 需求获取(Requirement elicitation)认知说明：
一、需求获取的重要性
1、需求获取(requirement elicitation)是需求工程的主体。
2、对于所建议的软件产品，获取需求是一个确定和理解不同用户类的需要和限制的过程。
3、获取用户需求位于软件需求三层结构的中间一层。它描述了用户利用系统需要完成的任务。从这些任务中，分析者能获得用于描述系统活动的特定的软件功能需求，这些系统活动有助于用户执行他们的任务。
（来自项目视图和范围文档的业务需求决定用户需求）
4、需求获取是在问题及其最终解决方案之间架设桥梁的第一步。
5、把需求获取集中在用户任务上—而不是集中在用户接口上—有助于防止开发组由于草率处理设计问题而造成的失误。
6、需求获取、分析、编写需求规格说明和验证（需求开发的4个过程）并不遵循线性的顺序，这些活动是相互隔开、增量和反复的。
当你和客户合作时，你就将会问一些问题，并且取得他们所提供的信息（需求获取）。
同时，你将处理这些信息以理解它们，并把它们分成不同的类别，还要把客户需求
同可能的软件需求相联系（分析）。
然后，你可以使客户信息结构化，并编写成文档和示意图（说明）。
下一步，就可以让客户代表评审文档并纠正存在的错误（验证）。
这四个过程贯穿着需求开发的整个阶段。
二、需求获取的指导方针
1、尽量把客户所持的假设解释清楚，特别是那些发生冲突的部分。
2、尽量使用所有可以利用的需求信息来源
3、在每一次座谈讨论之后，记下所讨论的条目( item)，并请参与讨论的用户评论并更正。
4、尽量理解用户用来描述他们需求的思维过程。充分理解用户在执行任务时做出决定的过程。
5、避免受不成熟的细节的影响。要确保需求讨论集中在适合的抽象层次上。
6、在一个逐渐详细的过程中，重复描述用户需求，以确定用户的目标和任务，并形成USECASE。进而把任务描述成功能需求和非功能需求。
小组房屋出租系统需求获取分析：对于一个系统来说，需求获取是无比重要的，需求获取需要对涉众进行分析，了解他们的需求，如房客需要什么样子的房子，价格等问题都需要考量。
4.4 需求管理(Requirements Management)认知说明：
需求管理的目的是管理一个项目中的需求并且鉴别需求、计划与产品之间的差异。需求管理实践包括变革管理(Change Management)和可追溯性(Traceability)两个方面。
需求管理包含关于权衡(Balance)、沟通(Communication)与调整(Adjustment)的一切内容。为了避免需求分析中一个类超越自身而覆盖了另一个类的功能，团队中成员之间始终如一(Constant)的沟通指关重要。例如，在内部应用的软件开发中，业务需求往往强烈到可能因此而忽略了用户需求，或让人认为在创建用例的时候，用户需求已经了解清楚了。
需求的可追溯性与需求的全程文档相关。若要达到可追溯性的要求，我们应当保证可以追踪到最初的原始需求以及每一次需求的变更都被记录下来。甚至应当将保证在软件系统完成部署并投入使用之后产生的需求具有追踪的可能。[2]
需求来自不同的源头，如业务中购买产品的用户、市场经理和实际用户。这些人对软件产品有不同的要求。使用需求可追溯性原则可以保证实现的功能可以被对应到需求分析时需要此功能的个人或是组织。这种方法可以在开发过程中用于区分需求的优先级，判断对于某用户需求的价值。在部署之后当对用户调查(User Study)发现某个功能未被使用时，这种方法还可以帮助我们找到原先该功能需求被列入开发计划的原因。
小组房屋出租系统需求管理分析：在需求获取之后，我们还要进行需求管理，在开发阶段，我们要通过调研的方式来进行数据的分析，之后便是对于房屋出租系统所需要的数据进行可行性分析、设计、开发和测试、以及对系统的发布。
4.5 需求确认(Requirements validation)认知说明：
需求确认是检查为开发定义的需求，定义客户真正想要的系统的过程。为了检查与需求相关的问题，我们执行需求验证。我们通常在开发的初始阶段使用需求验证来检查错误，因为在开发过程的后期检测到错误时，可能会增加过多的返工。
在需求验证过程中，我们执行不同类型的测试来检查软件需求规范，这些检查包括:
- 完整性检查
- 一致性检查
- 有效性检查
- 真实性检查
- 歧义检查
- 可验证性
需求确认的输出是问题列表和对检测到的问题的一致行动。问题列表表明在需求验证过程中检测到的问题。商定措施的列表说明了应采取的纠正措施，以解决检测到的问题。
小组房屋出租系统需求确认分析：通过需求确认可以让我们的需求分析更加严谨，更加接近房客的需求，让我们房屋出租系统系统的容错率更高。
4.6 软件需求规范说明(Software requirements specification)认知说明：
SRS是对在具体环境中执行确定功能的特定软件产品、程序或一组程序的规格说明。 SRS可由来自供方、顾客或双方的一个或多个人员来编写，推荐双方人员联合编写。
SRS编写人员应该关注以下基本点：
- 功能 - 软件将执行什么功能？
- 外部接口 - 软件如何与人、系统的硬件及其他硬件和其他软件进行交互？
- 性能 - 各种软件功能的速度、响应时间、恢复时间等是多少？
- 属性 - 软件的可用性、可靠性、可移植性、正确性、可维护性、安全性如何？
- 影响产品实现的设计方案 - 是否有使用标准、编程语言、数据库完整性方针、资源限制、运行环境等方面的要求？
编写人员宜避免把设计或项目需求写入SRS中。
小组房屋出租系统软件需求规范说明分析：在房屋出租系统软件需求规范说明中，我们知道房客希望得到什么，系统的房东理解房客想要什么，如房子有什么优惠等问题
4.7 需求抽取技术(Requirements elicitation technique)认知说明：
实际需求获取是对任何软件测试项目的完成至关重要的一个环节。令人震惊的是，这是一个经常被许多业务分析师忽略的过程。
在时间和支出计划方面，这种疏忽对项目来说可能是昂贵的，然而，更重要的是，这可能会导致分散的需求，或者更严重的是，导致项目失败。
有很多需求获取技术，而且任何一种技术都可靠地为你服务是可疑的。
尽管有些人可能只提倡一种启发方法——但人们普遍认为，一种技术不可能对所有项目都合理。
因此，这里有五种最有效的需求获取技术。
1、头脑风暴
2、面谈
3、调查/问卷
4、样机研究
5、文件分析
小组房屋出租系统需求抽取技术分析：对于一个系统来说，需求获取是无比重要的，我们可以通过上面的五种方法来实现对房客的需求获取，能够有效地知道每个房客的问题所在。
4.8 涉众(Stakeholder)认知说明：
涉众是与要建设的业务系统相关的一切人和事。首先要明确的一点是，涉众不等于用户，通常意义上的用户是指系统的使用者，而这仅是涉众中的一部分。如何理解与业务系统相关的一切人和事呢？凡是与这个项目有利益关系的人和事都是涉众，他们都可能对系统建设造成影响。
例如修建一条公路，它预期的使用者是广大的司机；监管方是交通管理局；出资方是国家财政；发展商是某某公司；建筑商是某某工程公司等。显然他们都与此项目有利益关系，都是涉众。这些都好理解。但是在某些情况下，看似与公路完全无关的一些人和事却会成为重要涉众。例如当公路修建需要搬迁居民时，被搬迁的居民就成为重要的涉众；当公路规划遇到历史建筑时，文物管理局就成为重要的涉众。虽然软件项目开发与修建公路相比涉及的人和事要少得多，但是也不能忽略系统使用者之外的其他涉众。另外，当面对一个陌生的问题领域时，往往在项目初期还不能够清楚的获悉究竟谁是系统的使用者，通常得随着需求的深入逐步明确。但是最终的系统使用者将从涉众当中产生，因此涉众分析显得尤为重要。
小组房屋出租系统涉众分析：在我们房屋出租系统之中，具有房东，房客和管理员这几个涉众，后期还可能涉及维修工等一些涉众。
4.9 功能需求(Functional Requirement)认知说明：
功能需求规范记录了系统必须能够执行的操作和活动。
功能要求应包括:
- 输入系统的数据说明
- 每个屏幕执行的操作描述
- 系统执行的工作流的描述
- 系统报告或其他输出的描述
- 谁能把数据输入系统
- 系统如何满足适用的法规要求
小组房屋出租系统功能需求分析：在之前的需求分析报告中清楚地描写了我们系统的功能需求分析，主要是用户需求描述了系统的最终用户需求。功能需求描述了系统必须做什么。
4.10 非功能需求(Non-Functional Requirement)认知说明：
非功能性需求可定义为质量属性(如可用性、可靠性、安全性)或一般系统约束。
系统的非功能需求在质量场景中定义。正如需要通过开发用例使功能需求具体化一样，也需要使质量需求具体化。对于质量场景来说，声明系统应该是“高度可重用的”是不够的一个特定的可重用性要求将声明“信用卡验证服务将被系统x重用”。另一个例子是，当性能要求是根据整体延迟要求而不是使用模式、可伸缩性或对系统可用性的影响来声明的。
在现代基于组件的开发中，特别需要关注非功能性需求，如性能、安全性、可修改性、可重用性、可集成性、可测试性、可用性、可靠性和可移植性。 一旦确定了非功能性服务质量属性，就可以使用网络服务端点语言(WSEL)来描述它们。WSEL允许服务提供商描述诸如服务质量和安全特征之类的东西。
小组房屋出租系统非功能需求分析：非功能需求在需求获取中占了很重要的一部分，对于我们对涉众的分析有了很大的帮助，在我们报告中，我们定义为质量属性，也就是系统完成工作的质量，即系统需要在一个“好的程度”上实现功能需求，如可靠性程度和可维护性程度等
4.11 需求工程程序(Requirement engineering processes)认知说明：
需求工程是定义、记录和维护需求的过程。它是一个收集和定义系统提供的服务的过程。需求工程流程包括以下主要活动:
- 需求获取
- 需求规格
- 需求验证和确认
- 需求管理
小组房屋出租系统需求工程程序分析：我们通过需求工程程序可以对于我们房屋出租系统的需求工程制造有许多帮助，特别是对涉众和问题域的获取。
五、第四类关键词
5.1 行为特征（behavioral feature）认知说明：
在UML规范中，常见行为指定了动态元素所需的核心概念，并提供了支持行为的更详细定义的基础结构。创建行为图时可以使用常见行为的元素。
常见行为包括：行为，行为分类器，事件，触发器，信号，接收，间隔约束，持续时间约束，时间约束。
行为是一个类，它指定拥有该行为的分类器如何随时间改变其状态。该规范可以是可能的行为执行 或 紧急行为的定义，也可以是可能的 执行的有趣子集的选择性说明。后一种形式通常用于捕获示例，例如特定执行的跟踪。
任何行为 都是至少一个对象的动作的直接结果。行为描述了这些对象的状态（如其结构特征所反映的）如何随时间变化。
行为本身并不存在，也无法交流。
实例化一个行为称为“调用”该行为，实例化的行为也称为行为“执行”。调用行为时，将创建并适当地初始化其属性和参数（如果有）。
行为也可以实例化为对象，与普通类相同。当行为被实例化为一个对象时，它成为它自己的上下文。
[UML 2.4.1规范] 定义了两种行为： 执行行为 和紧急行为。注意，这两种行为是非正式的，不是行为的子类。
行为没有特定的符号，可以描述为一个类。
行为可以是专门的，具有特定的符号和由其子类定义的详细语义。多种机制来指定行为由支承UML，诸如自动机为状态机， Petri网状图形为活动，非正式描述为用例，部分有序的序列的事件发生的用于相互作用。配置文件可能会引入行为规范的其他样式。
行为的子类为：
- 活动，
- 状态机，
- 互动，
- 不透明的行为 。
执行行为：
一个执行的行为是一种行为，其由对象（称为执行主机），并且是该对象的行为的描述。可能承载行为的对象由行为分类器的具体子类型指定 。
执行行为是由宿主对象的行为特征的调用或其创建直接引起的。
行为有权访问其宿主对象的结构特征以及行为的参数（如果有）。
当行为与行为特征的方法相关联时，它定义特征的实现。
紧急行为：
紧急行为是一种行为，是由一个或多个参与对象的相互作用引起的。
参与对象可能是部分的复合对象。在这种情况下，紧急行为间接描述了复合材料的行为
小组房屋出租系统行为特征的分析：行为特征中的行为是一个类。它可以实例化对象，与普通类相同。当行为被实例化为一个对象时，它成为它自己的上下文。主要是类的特征，例如在我们房屋出租系统之中可以创建一个关于房源的类，在这里面有房子的大小，位置以及租金等一些特征。在这些特征实例化成为一个对象时，就可以编写属于它的上下文。
5.2 约束（constraint）认知说明：
约束用于限制加入表的数据的类型。
可以在创建表时规定约束（通过 CREATE TABLE 语句），或者在表创建之后也可以（通过 ALTER TABLE 语句）。
主要有以下几种约束：
--主键约束(Primary Key constraint):要求主键列的数据唯一，并且不允许为空。
--唯一约束(Unique Constraint)：要求该列唯一，允许为空，但只能出现一个空值。
--检查约束(Check Constraint):某列取值范围限制、格式限制等，如有关年龄的约束。
--默认约束(Default Constraint):某列的默认值，如我们的男性同学较多，性别默认为男。
--外键约束(Foreign Key):用于在两表之间建立关系需要制定引用主表的哪一列。
语法如下
alter table 表名 add constraint 约束名 约束类型具体的约束说明
示例：
--添加主键约束
alter table stuInfo add constraint PK_stuNo primary key(stuNo)
--添加唯一键约束
alter table stuInfo add constraint UQ_stuID unique(stuID)
--添加默认约束
alter table stuInfo add constraint DF_stuAddress default('地址不详') for stuAddress
--添加检查约束
alter table stuInfo add constraint CK_stuAge check(stuAge between 15 and 40)
--添加外键约束
alter table stuInfo add constraint FK_stuNo foreign key(stuNo) references stuInfo(stuNo)
删除约束
alter table 表名 drop constraint 约束名
---设置列的约束，十一位
CREATE TABLE STUD (STD_NO VARCHAR(10) CHECK (STD_NO LIKE '[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]'))
---------------------------------------------------------------------------------------------------
--ALTER 药品名唯一
alter table yk_ypzd add constraint uq_ypname unique(ypname)
--SQL 插入数据，关闭自增长.txt
SET IDENTITY_INSERT 表名 ON
insert into 表名(字段,字段,字段) values (64,'han','guo')
SET IDENTITY_INSERT 表名OFF
--加约束，档案号长度不可以超过10
select * from gh_daxx where len(dah)>10
小组房屋出租系统约束分析：约束是数据库的一个规范，它主要是为了创建表中添加约束条件，例如在我们房屋出租系统中，我们需要创建许许多多的表，也是需要利用这些约束，最主要的还是主键约束，在每个表中都需要主键约束，同时表与表之间都需要外键约束来实现表与表之间的连接。例如我们系统之中可以创建一个关于房源的表和一个访客信息表，当房东需要查询房屋是否被租，还有被哪个房客租，这时候就需要一个列表提供给房东查看，这时候就需要外键约束来进行表与表之间的连接。
5.3 控制焦点（focus of control）认知说明：
控制焦点主要分为生命线以及激活。
一、生命线
生命线代表时序图中的对象在一段时期内的存在。
时序图中每个对象和底部中心都有一条垂直的虚线，这就是对象的生命线，对象间的消息存在于两条虚线间。
生命线是一个时间线, 从时序图顶部一直到底部都存在, 其长度取决于交互的时间。
二、激活
代表生命线上的窄矩形条被称为激活生命线（也称为控制焦点或方法调用框，表明正在由目标对象/类执行处理以完成消息）。
当对象处于激活时期, 生命线可以拓宽为矩形, 这个矩形条成为激活条; 当一个对象没有被激活时，该对象处于休眠（空闲）状态，什么事都不做，但它仍然存在，等待新的消息来激活它。
矩形框的高度表示对象执行一个操作所经历的时间段，矩形的顶部表示动作的开始，底部表示动作的结束。
小组房屋出租系统控制焦点分析：控制焦点是时序图的一个重要的特征，对于我们房屋出租系统来说，有着不可或缺的作用，在我们看到有控制焦点的时序图，我们可以清晰地知道哪些任务是激活的，哪些是等待激活的，这样有利于我们开发项目。
5.4 防卫条件（guard condition）认知说明：
很多时候，只有当状态(有限的或扩展的)或事件的某些条件满足时，您才会希望状态之间发生转换。例如，假设您正在为搜索表单创建一台机器，并且您只希望在以下情况下允许搜索:
- 允许用户搜索(。可以搜索在这个例子中)
- 搜索事件询问不为空。
这是“保护性转换”的一个很好的用例，这种转换只在某些条件(条件数)通行证。带有条件的转换称为保护过渡。
1、序列化警卫
可以（并且应该）将防护序列化为字符串或具有该{ type: '...' }属性的对象。
2、海关守卫
有时，不仅要序列化JSON中的状态转换，而且还要保护逻辑，是更可取的。
3、多重卫兵
如果您希望在某些情况下将单个事件转换为不同的状态，则可以提供一系列条件转换。
4、“状态”警卫
该in属性将状态ID作为参数，true并仅当该状态节点在当前状态中处于活动状态时才返回。
使用“状态”防护通常是一种迹象，表明可以不需要使用机器的方式来重构机器。尽可能避免使用“状态”防护。
小组房屋出租系统防卫条件分析：防卫条件对于我们的系统创建有很大的帮助，特别是对于我们的用户的安全性问题，通过使用防卫条件里面的这些防卫防护，对于我们系统的安全等级提高了不少。
5.5 二元联想(binary association)认知说明：
可以考虑一些关联更强壮的定义了一种由其他物体组成的物体。例如，一所房子由房间、一本章节书、一门本科职业课程等组成。
如果关联是排他的，即一个对象不能同时是另一个对象的一部分，那么它被认为是一个强的部分-整体关联，这就是所谓的复合聚集，并且它是用黑色菱形绘制在代表整体的角色上。
在复合聚合的情况下，表示复合(菱形所在的一侧)的角色的多样性应为1或0..1，其他什么都没有，因为复合材料不共享零件，即使是同一个类的对象。
复合聚合表示部分-整体关联中的排他性。当这种排他性不是强制性的(该部分可能是其他集合的一部分)时，则使用白色菱形，这种关联称为共享聚合
白色菱形表示一个共享的集合，其中部分可能同时属于不同的整体。在图给定的项目必须是命令，但也可能成为…的一部分销售。
复合和共享聚合是特殊的关联，应该非常简洁地使用，也就是说，只有当团队确信某个对象是真的时，才应该使用它们部分而不仅仅是一个正常的联想。甚至是UML规范(对象管理组，2011)声明共享聚合的精确语义在应用程序区域和建模者之间有所不同。
当非部分-整体相关的对象通过这种关联联系在一起时，在模型中聚合和组合被滥用是很常见的。
小组房屋出租系统二元联想分析：在我们系统之中，也要用到二元联想。例如，房客不是订单的一部分，如果不是因为任何其他原因，而是因为房客是一个人，订单不是实物，而是交易。复合聚合和共享聚合应该将相同性质的元素结合起来:物理的和物理的，抽象的和抽象的。订单可能与房客相关联，但订单不是顾客。
5.6 一般化(generalization)认知说明:
一般化是二元分类(即与分类相关)定向关系更一般的分类器(超类)和更具体的分类器(子类)。
具体分类器的每个实例也是一般分类器的间接实例，这样我们就可以说“病人是人”、“储蓄账户是账户”等。正因为如此，一般化关系也被非正式地称为”是A“关系。
概括就是拥有者特定的分类器。
一般化在表示相关分类器的符号之间显示为带有空心三角形箭头的直线。箭头指向代表通用分类器的符号。这种符号被称为"单独的目标样式。"
引用同一通用分类器的泛化关系也可以在"共享目标样式。"
小组房屋出租系统一般化分析：一般化对于房屋出租系统来说，可以清晰地了解到各种账户等之间的关系。例如，我们系统的账户下有管理员账户，房东账户和房客账户。
5.7 包容层次结构(containment hierarchy) 认知说明：
CMarkup维护一个包含其他元素的元素层次结构(参见在CMarkup中导航级别).在格式良好的XML中，这是标记的明确逻辑表示，因为所有元素都是正确结束和嵌套的。即使在格式不佳的文档中，包含层次结构仍然是有用的。
很多非XML标记使用没有对应结束标记的标记。HTML中的例子有
表示换行，并且
描述要显示的图像。CMarkup解析器使用一个简单的算法来创建元素的包含层次。当遇到子文档容器元素的结束标记时，子文档中的所有非结束元素都将关闭。CMarkup对象为这些非结束元素提供了所有正常的导航方法，并且它们不包含任何子元素。在下面的示例中，当遇到P元素的结束标记时，BR标记被标记为非结束元素，并且两者都被链接为P元素的直接子元素。
We
see
tree
允许无结尾的容器元素，例如
和
小组房屋出租系统包容层次结构分析：对于包容层次结构来说，在我们系统需要编写HTML文件，这对于我们实现系统的一大帮手。
5.8 复合状态(composite state) 认知说明：
复合状态由状态机图通过展开状态元素，添加区域(如果适用)，并在其边界内进一步拖动状态元素、相关元素和连接器。内部状态元素被称为子状态。
(您也可以像许多其他类型的元素一样，将状态元素定义为复合元素；然后，它有一个指向子图的超链接，该子图可以是模型中其他地方的另一个状态机图或其他类型的图。)
如果创建了区域，复合状态可以是正交的。如果复合状态是正交的，则它的条目表示在每个区域中有一个子状态同时活动。复合状态的分层嵌套，加上区域使用，产生多个状态同时活动的情况；这种情况称为活动状态配置。
复合状态要么包含一个区域，要么被分解成两个或多个正交区域。每个区域都有一组互斥的不相交的顶点和一组过渡。给定的状态只能以这两种方式之一进行分解。
封闭在复合状态区域内的任何状态称为该复合状态的子状态。当它不被任何其他状态包含时，称为直接子状态；否则称为间接替代状态。
复合态的每个区域可以有一个初始状态和一个最终态。向封闭状态的转变表示在每个区域中向初始伪状态的转变。新创建的对象采用其最顶端的默认过渡，从每个区域最顶端的初始伪状态开始。
过渡到最终状态表示封闭区域中活动的完成。所有正交区域中活动的完成表示封闭状态下活动的完成，并触发封闭状态下的完成事件。对象最顶端区域的完成对应于它的终止。
小组房屋出租系统复合状态分析：复合状态是状态机图的一种，对于我们系统来说有利于我们了解每一个任务的状态，例如登录模块。
5.9 动态分类(dynamic classification) 认知说明：
动态分类也称为“动态类型”，处理改变“对象分类”的能力。该对象在其存在中可以改变其分类。例如，下图显示了人员工作的动态分类。“鲍勃”对象将其子类型更改为“经理”、“工程师”、“销售员”的实例。即使对象改变了它的子类型，它仍然只属于“人”类型。一般来说，动态分类允许对象从时间到时间。
小组房屋出租系统动态分类分析：在计算机编程语言中，动态分类起着重要的作用。描述对象分类的变化是面向对象分析的一个重要特征。一些编程语言支持有限程度的动态分类，而其他编程语言不提供直接支持。为了在程序中实现动态分类，每当对象改变它的类时，就为该类创建一个新的对象。然后将以前的对象特征复制到新对象中，然后删除旧对象，这有利于我们系统的编程各种模块，如房东管理模块。
5.10 应用程序域(Application Domain) 认知说明：
一个进程中可以有多个应用程序域（ Application Domain），一个应用程序域（ Application Domain）中可以有多个程序集。
应用程序域（Application Domain）的引入的好处在于，如果一个程序集出现错误，不会影响到别的应用程序域（Application Domain），同时他们又是一个进程中的。
在.net中，应用程序域（Application Domain）是用AppDomain类来表示的。
AppDomain CurrentAD=AppDomain.CurrentDomain;
上面的代码实现了获取当有程序集所在的应用程序域（Application Domain）。获取当前应用程序域（Application Domain）还可以通过当前线程来得到，如下：
AppDomain CurrentAD=Threed.GetDomain();
小组房屋出租系统应用程序域分析：在我们房屋出租系统来说，有时候代码汇出行错误，引入应用程序域，如果一个程序集出现错误，不会影响到别的应用程序域，同时他们又是一个进程中的。
5.11 基线(baseline) 认知说明：
基线是软件文档或源码(或其它产出物)的一个稳定版本,它是进一步开发的基础。所以,当基线形成后,项目负责SCM的人需要通知相关人员基线已经形成,并且哪儿可以找到这基线了的版本。这个过程可被认为内部的发布.至于对外的正式发布,更是应当从基线了的版本中发布。
基线是项目储存库中每个工件版本在特定时期的一个“快照”。它提供一个正式标准，随后的工作基于此标准，并且只有经过授权后才能变更这个标准。建立一个初始基线后，以后每次对其进行的变更都将记录为一个差值，直到建成下一个基线。
参与项目的开发人员将基线所代表的各版本的目录和文件填入他们的工作区。随着工作的进展，基线将合并自从上次建立基线以来开发人员已经交付的工作。变更一旦并入基线，开发人员就采用新的基线，以与项目中的变更保持同步。调整基线将把集成工作区中的文件并入开发工作区。
小组房屋出租系统基线分析：房屋出租系统运用基线，当认为更新不稳定或不可信时，基线为团队提供一种取消变更的方法；同时还可以利用基线重新建立基于某个特定发布版本的配置，这样也可以重现已报告的错误。
5.12 上下文边界(context boundary) 认知说明：
我认为通过从业务边界到工作边界再到应用边界这三个层次抽丝剥茧，分别以不同的视角、不同的角色协作来运用对应的设计原则，会是一个可行的识别限界上下文的过程方法。
从业务边界到我们的界限上下文，根据上图的过程展示梳理出来流程：
- 在明确了系统的问题域和业务期望后，开发团队与领域专家经过充分地沟通与交流，可以梳理出主要的业务流程 — 这一阶段需要梳理和输出主要的核心流程图 （N个场景） 最具有业务价值的领域功能
- 业务流程包含了：参与的角色（Who） 业务活动（What） 业务价值（Why） 这里的业务流程不是指的是流程图，而是角色(用户) 活动(操作)的流程 ，所以由业务流程会产生不同的业务场景，比如：用户购买 先登录 或者注册 可以先加入购物车再购买 或者直接购买 加入购物车可以选择优惠卷等方式，然后再进行支付等 里面可能包含了不同的业务场景----如：登陆注册 查找商品 支付等，从业务流程梳理出一个核心的操作流程图和多个业务场景的流程图，
- 现在一个业务流程 -----> 多个业务场景（多个场景的流程图）然后每个场景会对应多种不同的活动，业务活动的描述应该精准地表达领域概念，且通过尽可能简洁的方式进行描述，通常格式为动宾形式。如：收藏商品，购买商品等
可以看到，业务流程是一个由多个用户角色参与的动态过程，而业务场景则是这些用户角色执行业务活动的静态上下文。
- 提取出初步的界限上下文：语义相关系和功能相关性，把活动进行归类
从语义角度去分析业务活动的描述，倘若是相同的语义，可以作为归类的特征。
从功能角度去分析业务活动是否彼此关联和依赖，倘若存在关联和依赖，可以作为归类的特征
- 对于划分活动产生界限上下文会有一些难点：相关联的功能未必是同一个界限上下文，比如：支付和购买 事实上，功能相关性往往会与上下文之间的协作关系有关。由于这种功能相关性恰恰对应了用例之间的包含与扩展关系，它们往往又可成为识别限界上下文边界的关键点。
- 最后的难点就是我们业务边界的划分和边界命名
小组房屋出租系统上下文边界分析：对于我们系统的上下文边界来说，如果我们通过用例图来帮助识别限界上下文，那么，用例图中的包含用例或扩展用例或许是一个不错的判断上下文协作关系的切入点。选择从包含或扩展关系切入，既可能确定了职责分离的逻辑边界，又可以确定协作关系的方向，这就是用例对领域驱动设计的价值所在了。
5.13 关联类(Association Class)认知说明：
关联类允许您向关联添加属性、操作和其他功能，从图表中我们可以看出，一个人可能参加许多会议。我们需要保持那个人有多清醒的信息；我们可以通过将attendence属性添加到关联中来做到这一点。
关联类很可能使其成为一个完整的类，但是提供方法来获取关联类所链接的类的信息。
小组房屋出租系统关联类分析： 在房屋出租系统之中，一个租客可以租多间房屋，房东有多间房屋；这些都是有关联的，并且是一对多的关系，可以通过关联类来实现。
5.14 二元联想(binary association)认知说明：
可以考虑一些关联更强壮的定义了一种由其他物体组成的物体。例如，一所房子由房间、一本章节书、一门本科职业课程等组成。
如果关联是排他的，即一个对象不能同时是另一个对象的一部分，那么它被认为是一个强的部分-整体关联，这就是所谓的复合聚集，并且它是用黑色菱形绘制在代表整体的角色上。
在复合聚合的情况下，表示复合(菱形所在的一侧)的角色的多样性应为1或0..1，其他什么都没有，因为复合材料不共享零件，即使是同一个类的对象。
复合聚合表示部分-整体关联中的排他性。当这种排他性不是强制性的(该部分可能是其他集合的一部分)时，则使用白色菱形，这种关联称为共享聚合
白色菱形表示一个共享的集合，其中部分可能同时属于不同的整体。在图给定的项目必须是命令，但也可能成为…的一部分销售。
复合和共享聚合是特殊的关联，应该非常简洁地使用，也就是说，只有当团队确信某个对象是真的时，才应该使用它们部分而不仅仅是一个正常的联想。甚至是UML规范声明共享聚合的精确语义在应用程序区域和建模者之间有所不同。
当非部分-整体相关的对象通过这种关联联系在一起时，在模型中聚合和组合被滥用是很常见的。
小组房屋出租系统二元联想分析：在我们系统之中，也要用到二元联想。例如，房客不是订单的一部分，如果不是因为任何其他原因，而是因为房客是一个人，订单不是实物，而是交易。复合聚合和共享聚合应该将相同性质的元素结合起来:物理的和物理的，抽象的和抽象的。订单可能与房客相关联，但订单不是顾客。
5.15 布尔表达式(Boolean Expression)认知说明：
布尔是标准的系统验证日志布尔表达式。
布尔表达式可以是单个逻辑变量或公式，例如(请求[0]&&req[1]&&req[2]&&req[3])在上面的封面例子中。
• 顺序是关于布尔值(或其他序列)随时间发生的陈述。它们依赖于明确定义的时钟事件来定义时间流逝。例如，以下序列表示一个请求，随后是两个时钟周期内的授权:
req[0] ##2 gnt[0]
• 性能将序列与附加操作符组合在一起，以显示含义和类似的概念，从而表达设计中预期的一些行为。例如，一个属性可能声明，如果我们在两个周期后收到一个请求，然后是一个授权，这意味着该授权将在下一个周期取消断言:
req[0] ##2 gnt[0] |->E ##1！gnt[0]
• 断言语句是使用关键字之一的语句维护,假设，或涉及，导致SVA属性被检查为断言、假设或覆盖点。属性没有任何作用，除非它用于某种断言语句。例如，导致检查上述属性的断言语句可能是:
gnt _ falls:assert property(req[0]# # 2gnt[0]|-> ##1 !gnt[0])；
小组房屋出租系统布尔表达式分析：在房屋出租系统可以通过布尔表达式来实现检查等操作，假如登录时，我们可以通过布尔表达式来返回账号密码是否正确。
六、第五类关键词
6.1 决策表(decision table)认知说明：
决策表是一种记录在不同条件下采取的不同决策或行动的简洁方法:例如，根据不同的风险因素收取多少保险费，或者是否签发保单。决策表有两种:
1. 有限条目决策表
2. 扩展条目决策表
小组房屋出租系统决策表分析：对于我们系统来说，系统制作一个决策表，根据房客通过电话向他们描述的问题症状，来诊断他们需要解决的问题所在。
6.2 容错(Fault Tolerance)认知说明：
VMware 容错可通过创建和维护等同于主虚拟机并可在发生故障切换时替换主虚拟机的辅助虚拟机来为虚拟机提供连续可用性。当启用Fault Tolerance时，会创建一个重复虚拟机（称为辅助虚拟机），该虚拟机会以虚拟锁步方式随主虚拟机一起运行。VMware vLockstep可捕获主虚拟机上发生的输入和事件，并将这些输入和事件发送到正在另一个主机上运行的辅助虚拟机。使用此信息，辅助虚拟机的执行将等同于主虚拟机的执行。因为辅助虚拟机与主虚拟机一起以虚拟锁步的方式运行，所以它可以无中断地接管任何点处的执行，从而提供容错保护。
主虚拟机和辅助虚拟机可持续交换检测信号。此交换使得虚拟机对中的虚拟机能够监控彼此的状态，以确保持续提供FT保护。如果运行主虚拟机的主机发生故障，系统会执行透明故障切换，此时会立即启用辅助虚拟机以替换主虚拟机，并且将重新启动新的辅助虚拟机，同时在几秒内重新建立FT冗余。如果运行辅助虚拟机的主机发生故障，则该主机也会立刻被替换。在任一情况下，用户都不会遭遇服务中断和数据丢失的情况。容错虚拟机及其辅助副本不允许在相同主机上运行。此限制可确保出故障的主机不会使两个虚拟机同时丢失。也可以使用虚拟机-主机关联性规则来确定要在其上运行指定虚拟机的主机。如果使用这些规则，应了解对于受这种规则影响的任何主虚拟机，其关联的辅助虚拟机也受这些规则影响。
小组房屋出租系统容错分析：容错对于我们房屋出租系统维护有很大的帮助，这能够让我们防止系统无休止地停止工作。
6.3 可维护性(Maintainability)认知说明：
正如应用软件必须设计，以便维护了其使用寿命，你的自动化测试必须如此。
可维护性的一个原因是如此重要，没有它你不能累积试验。平均来说，一个应用程序改写每年25%；如果与修改的部分相关的试验不能以合理的努力去改变，那么他们将被淘汰。因此，而不是逐渐提高测试覆盖率随时间积累越来越多的测试用例，你将重新测试而不是丢弃。因为应用程序的最有可能的每个新版本增加功能，你将有机会在连！
在大多数情况下，应用程序的源代码将由源控制或配置管理系统进行管理。这些系统维护记录更改源代码领域的详细更改日志。如果你不能从开发有关更改应用程序直接获取的信息，请在更改日志被复制。这将至少给你一个预警，变化未来的路，哪些模块受到影响。
可维护性仅通过确保变化可以容易地识别和提出没有实现，而且它们不会对其他领域产生意想不到的影响。意外的影响，可作为发生不良试验设计或实施的结果。例如，一个测试脚本，其选择从根据它在列表中的相对位置的列表框中选择一个项目是受如果未能在列表的变化的顺序或物品的数量。在这种情况下，一个维护的测试脚本将被设计进入选择的项目或选择它根据它的文本值。
小组房屋出租系统可维护性分析：我们做系统都需要对代码具有可维护性，如果没有可维护性，系统可能会停滞不前，甚至有可能崩溃。
6.4 统一建模语言(Unified Modeling Language)认知说明：
统一建模语言（UML，英语：Unified Modeling Language）是非专利的第三代建模和规约语言。UML是一种开放的方法，用于说明、可视化、构建和编写一个正在开发的、面向对象的、软件密集系统的制品的开放方法。UML展现了一系列最佳工程实践，这些最佳实践在对大规模，复杂系统进行建模方面，特别是在软件架构层次已经被验证有效。
UML集成了Booch，OMT和面向对象软件工程的概念，将这些方法融合为单一的，通用的，并且可以广泛使用的建模语言。UML打算成为可以对并发和分布式系统的标准建模语言。 UML并不是一个工业标准，但在Object Management Group的主持和资助下，UML正在逐渐成为工业标准。OMG之前曾经呼吁业界向其提供有关对象导向的理论及实现的方法，以便制作一个严谨的软件建模语言（Software Modeling Language）。有很多业界的领袖亦真诚地回应OMG，帮助她建立一个业界标准。
在UML系统开发中有三个主要的模型：
功能模型：从用户的角度展示系统的功能，包括用例图。 (用户、客户、甲方)
对象模型：采用对象，属性，操作，关联等概念展示系统的结构和基础，包括类别图、对象图。（程序员、产品经理、乙方）
动态模型：展现系统的内部行为。包括序列图，活动图，状态图。（程序员、产品经理、乙方）
UML 2.2中一共定义了14种图形，如活动图，类图等。
小组房屋出租系统统一建模语言分析：UML对于我们房屋出租系统有很大的帮助，能够让我们清晰地知道房东与房客之间的关系，知道他们的具体状态，任务等一些重要的信息获取。
6.5 伪稳态(Pseudosteady State)认知说明：
伪稳态出现以下情况时发生边界主导流并且过渡时期结束。边界控制流是一种流态，当排油半径到达油藏边界。当油藏于假平衡状态时，边界控制流动是一种后期流动行为。非常规页岩产量分析极具挑战性的一个方面是，流动在很长一段时间内处于瞬态模式。因此，决心断裂几何学从现代生产分析来看是困难的，例如区域贸易协定。
小组房屋出租系统伪稳态分析：通过伪稳态能够让我们的系统的容错提高，增强我们系统的可维护性。
6.6 可靠性弱点度量(Reliability)认知说明：
CISQ把可靠性度量作为通过软件属性元素可以度量的指标之一。主要是通过CWE缺陷中的29个来进行度量。
CISQ自动化质量特性可靠性措施中包含的29个缺陷的描述。这些描述已经简化，从他们的描述到出版OMG的规范，这些规范使用其他OMG META模型的形式来规范机器处理XMI中的代表性缺陷。
下表给出了每个缺陷及其唯一的CISQ标识符、简短的描述性名称以及作为补救建议的缺陷的更完整描述。
可靠性弱点
衡量软件中包含导致中断、意外的弱点的程、非预期行为、不稳定、数据损坏、长时间恢复或其他相关问题。
通过对源代码进行静态检测，可以检测出上述29个缺陷和漏洞，则根据针对CISQ度量中包含的弱点检测到的总次数为转化为百万分之一机会的弱点，以确定可靠性度量的西格玛水平。进而对代码质量进行评估。作为软件健康的质量度量之一。
小组房屋出租系统可靠性弱点度量分析：我们系统可以通过可靠性弱点度量的29个缺陷和漏洞进行检测，提高我们编写房屋出租系统代码的质量。
6.7 结构化分析(structured analysis)认知说明：
结构化概念在20世纪80年代达到了顶峰结构化分析方法，它目前以许多不同的形式存在。在结构化分析方法中，当前的应用系统被捕获在“数据流图”中该技术本身主张逻辑设计和物理实现的分离。为了实现这一点，现有的数据存储被视为旧的物理模型，并从中派生出一个新的逻辑模型。如果没有以前的系统，那么手动过程将被分析，就像它是一个系统一样，并被记录下来。这种新的逻辑设计集中在什么完成了而不是怎么完成了。
然后可以将变更应用到包含客户所需变更的逻辑模型中。改变后的模型将成为一个更“新”的新模型，并转化为一个新的物理模型来实现。由于这种方法对业务问题和计划解决方案之间关系的演变产生了影响，因此模块化很精致。这种改进使程序模块结构、模块之间的接口和通信限制以及质量测量一致。
小组房屋出租系统结构化分析分析：结构化分析主要是分析实体与实体之间以一些形式来表现出来，如树形结构，这些实体相互通信并与系统环境通信。
6.8 动作顺序(Action Sequence)认知说明：
确保所有可能的操作都导致提示下一步动作序列或者预示动作完成时系统/对象的状态。
在适当的时候，向用户展示指导用户访问看不见的内容或功能的启示。例如，当歌曲列表出现时制作其动画。用户应该看到最后一首歌曲标题之外的附加内容，例如，部分显示的歌曲标题。这意味着下面列出了更多的歌曲；换句话说，显示的列表不完整。如果用户触摸内容，那么它应该稍微移动一下，以显示它可以滚动。
需要明确和有意的用户输入来激活破坏性功能或导致更大的变化或转换。这种输入对于影响多个用户的转换尤其重要，尤其是当用户正在从事非高度耦合的任务时。例如，要启动一个应用程序，用户必须触摸应用程序一次才能看到应用程序预览，然后再次触摸才能打开应用程序。
预示即将到来的结果，以便用户可以扭转他们的行动。例如，在调整图像大小时，如果图像即将跳转到全屏(模糊其他图像)，则以全屏大小显示图像的轮廓或图像的透明版本。然后，用户可以颠倒和否定该动作(图像不会跳到全尺寸)，或者移除她的手指，使得图像变成全尺寸。
小组房屋出租系统动作顺序分析：在我们操作房屋出租系统时都需要进行动作顺序，否则系统就会错误或者不安全，比如我们的登录模块，如果房客随便注册个账号，之后点击登录管理员系统的话不能成功证明动作顺序的重要，我们必须要按照动作顺序来执行，这时我们要判断该账号是否是管理员，是否有资格登录管理员系统；这些内容都需要按照动作顺序的。
6.9 接口规格(Interface specification)认知说明：
使用总线对象的接口规范查看MATLAB命令
此示例显示了如何将总线信号传播到参考模型中。它还显示了如何使用来自父模型的记录信号数据独立模拟参考模型。
小组房屋出租系统接口规格分析：我们房屋出租系统需要按照接口规格来实现代码的编写以及需求报告的编写，这样才能形成规范化。
6.10 MVC(Model-View-Controller)认知说明：
MVC是一个应用设计模型由三个相互关联的部分组成。它们包括模型(数据)，视图(用户界面)，以及控制器(处理处理输入)。
MVC模型或“模式”通常用于开发现代用户界面。它为设计一个程序为桌面或者可动的，以及web应用程序。它很适合面向对象编程，因为不同的模型、视图和控制器可以被视为对象并在应用程序中重用。
下面是对MVC各个方面的描述:
1.模型
模型是程序使用的数据。这可能是一个资料库,文件、或简单对象，如图标或者电子游戏中的角色。
2.视角
视图是在应用程序中显示对象的手段。示例包括显示窗户或者窗口中的按钮或文本。它包括用户能看到的任何东西。
3.控制器
控制器更新模型和视图。它接受投入并执行相应的更新。例如，控制器可以通过改变视频游戏中角色的属性来更新模型。它可以通过在游戏中显示更新的角色来修改视图。
小组房屋出租系统MVC分析：我们通过创建关于房东等涉众的模型，通过HTML来进行视图的显示，之后通过控制器来进行视图与模型的连接，让房客能够清楚地了解自己所执行的操作。
6.11 单继承(Single Inheritance)认知说明：
在“单一继承”(一种常见的继承形式)中，类只有一个基类。考虑下图所示的关系。
这是一个简单的继承图。
请注意图中从一般到特殊的顺序。在大多数类层次结构的设计中发现的另一个常见属性是派生类与基类有一种关系。在图中，一个书是一种打印文档，和一个平装书是一种书。
小组房屋出租系统单继承分析：在我们房屋出租系统之中，通过单继承来实现每个房客对象都可以继承房屋里面信息，通过这样让它们进行连接起来。
6.12 体系结构(Architecture)认知说明：
业务结构：
业务系统的结构和行为(不一定与计算机相关)。涵盖业务目标、业务功能或能力、业务流程和角色等。业务功能和业务流程通常映射到他们需要的应用程序和数据。
1、商业目标
2、业务功能或能力
3、业务流程和角色
数据结构：
企业和/或其应用程序使用的数据结构。存储中的数据和运动中的数据的描述。数据存储、数据组和数据项的描述。这些数据工件到数据质量、应用程序、位置等的映射。
1、存储和运动中的数据
2、数据存储、数据组和数据项
3、数据质量、应用、位置
应用结构：
业务中使用的应用程序的结构和行为，侧重于它们如何相互交互以及与用户交互。关注应用程序消费和产生的数据，而不是它们的内部结构。在应用程序组合管理中，应用程序通常映射到业务功能和应用程序平台技术。
1、业务中使用的应用程序的结构和行为
2、他们之间以及与用户之间的互动方式
3、应用程序消耗和产生的数据
小组房屋出租系统体系结构分析：要写房屋出租系统，必须要有一种体系结构，例如web-server等技术；只要运用体系结构的知识来编写系统，做出来的才符合软件开发的规范。
6.13 基数(Cardinality)认知说明：
优化器在计算成本的时候，需要从统计信息中取得数据，然后去估计每一步操作所涉及的行数，叫做Cardinality。 比如，一张表T有1000行数据，列COL1上没有直方图，没有空值，并且不重复的值（distinct value）有500个。那么，在使用条件“WHERE COL1=
通常情况下，Cardinality越准确，生成的执行计划就会越高效。
小组房屋出租系统基数分析：基数相当于id，都是唯一的，在房屋出租系统之中，我们查询哪个房客住在哪间房屋这个数据时，我们可以通过基数来查找，大大提高代码的质量。
6.14 组合聚集(Composite aggregation)认知说明：
组合聚集(Composite aggregation) —— 从不同来源创建组合分组，属于多组聚集分析。与其他的多组聚集分析不同，它可以实现多聚集结果进行分页，其提供了对结果进行流化处理，类似于对文档实现滚动操作。
组合分组是从每个文档中抽取特定值进行组合，每个组合作为一个分组。
组合聚集是Elasticsearch中强大特性，可以实现对大量聚集结果进行分页，使得响应时间变得可确定。通过组合不同来源，实现对数据从不同维度进行组合分析。
小组房屋出租系统组合聚集分析：我们在查询房屋列表时可以通过组合聚集进行分页查询，这有利于使得响应时间变得可确定。
6.15 具体类(Concrete Class)认知说明：
实体要么是类(抽象的，要么是具体的)，要么是java接口。如果两个类以某种方式耦合，那么它们之间就存在交互。每次互动的方向很重要。
具体类是被用来直接创建对象实例的类。
小组房屋出租系统具体类分析：在房屋出租系统之中需要用到许许多多的具体类，如房客具体类，通过创建该对象来调用关于房屋的接口或实现类。
七、第六类关键词
6.1 抽象类(Abstract Class)认知说明：
在面向对象编程中，抽象类提供了一个基类，该基类可用于为其他类提供部分实现和接口。它们本身是不完整的，用在Java、C++和C#等很多编程语言的继承情况下。它们作为基类的用法意味着它们通常被称为抽象基类(ABC)。
数据抽象是面向对象编程不可或缺的一部分，它去除了对象不必要的细节。本质上，它将对象归结为它的主要识别特征。这些基本特征提供了一个蓝图，可以用来创建其他具有相同属性的对象，只是细节不同。
这个蓝图定义为一个类。类用于封装代码，使节目编排者，因为他可以引用特定的通用例程，而不是一遍又一遍地编写例程。程序员从类中创建子对象，这些对象继承父类中的函数和方法。
抽象类的目的是成为构建其他类的框架。不能直接从抽象类创建对象，只能从属于抽象类的子类创建。对于从抽象类继承的对象，必须创建一个子类。抽象类的已创建子类的对象继承该抽象类的属性。
小组房屋出租系统抽象类分析：在面向对象编程中，抽象类非常重要。而在房屋出租系统之中也一样，我们需要通过创建抽象类来构建系统的框架。
6.2 衍生元素(Derived Elements)认知说明：
派生元素是报表上的一组属性元素。衍生元素组由列表、过滤器或计算定义。这些组提供了用于分析和格式化目的的报告数据的新视图。
案例：以下报告包含地区、类别和利润。左侧的报告不显示任何派生元素。右侧的报告显示使用区域属性元素组定义的衍生元素:
- 东海岸:该衍生元素结合了大西洋中部、东北部和东南部地区的数据。
- 西海岸:这个派生元素结合了西北和西南地区的数据。
- 中部和南部:该派生元素组合了中部和南部区域的数据。
- 网站:此派生元素显示网站属性元素的数据，该属性元素不包含在上面列出的任何派生元素中。
小组房屋出租系统衍生元素分析：通过衍生元素这个报表，我们可以了解到每间房子的属性以及价格等信息。
6.3 流程开发(development process)认知说明：
流程开发是在特定的要求(质量、成本)下，在一定的时间范围内，通过定义和描述满足过程目标和产生过程预期结果所需的一系列活动来建立和设计过程。
开发是过程生命周期的一个阶段。剩下的阶段是分析、实现、控制和部署。开发阶段旨在完成这三项任务:
- 评估解决过程问题或需求的潜在方法
- 创建指定如何解决问题/需求的流程设计
- 开发一个包含活动流程及其依赖关系的流程模型
列出的任务侧重于流程转换。换句话说，开发过程意味着设计一个详细的行动计划，解释如何将过程输入转化为过程输出，以及使用什么资源进行这种转化。第一个任务确保流程是可转换的；第二个任务分析如何准确地实现所需的转换；第三个任务提出了一个过程转换模型。
小组房屋出租系统流程开发分析：通过流程开发有利于我们对房屋出租系统的各种流程的了解，让我们不会在后期各种改，导致混乱。
6.4 刻板印象(stereotype)认知说明：
虽然所有的刻板印象都是概括，但不是全部一般化是刻板印象。刻板印象是广泛流传的对一群人的过度简化，而概括更多的是基于个人经验，而不是一个被广泛接受的因素。
在美国，某些种族团体与刻板印象有关，比如擅长数学、体育和舞蹈。这些刻板印象是如此众所周知，以至于普通美国人在被问及这个国家哪个种族群体以擅长篮球而闻名时，会毫不犹豫地给出答案。简而言之，当一个人定型时，他就重复了已经存在于特定社会中的文化神话。
另一方面，一个人可以对一个没有在社会上永久存在的民族群体进行概括。例如，有人遇到几个来自某个特定国家的人，发现他们很安静和保守，他可能会说这个国家的所有公民都很安静和保守。像这样的概括不允许群体内的多样性，如果与群体相关的陈规定型观念在很大程度上是负面的，可能会导致对群体的污名化和歧视
小组房屋出租系统刻板印象分析：在现实中刻板印象大部分都是不好的，当在我们软件开发之中，刻板印象主要是为了有一个编程的规范，否则每个人都有它的规范，那么软件工程没有一个统一就很难发展。同时我们房屋出租系统运用刻板印象可以规范化。
6.5 结构特征(Structural Feature)认知说明：
结构特征动作支持读写结构特征。
结构特征动作有两个输入:静态 定义的类目的结构特征和通过object输入引脚指定的操作对象。这个对象可以是拥有结构特征的类目的一个实例（直接或间接），或者当结构特征是是一个二 元关联的被拥有端时，位于关联的反对侧的某种类型的实例。如果结构特征是一个关联端，那么结构特征动作的语义和对一端是结构特征的关联进行操作的链接动作 相同（参考结构特征的特化）。下列情况下语义未定义：当结构特征在结构特征动作的上下文类目中或者在包含它的行为中不可见时；如果不存在上下文类目或者结 构特征的isStatic属性为true时。
结构特征和一个对象参与的关联有可能因为动态分类而随着时间改变。然而结构特征动作的object输入引脚的类型是一个唯一的类目，而且它的语义只在动作执行且接受输 入时，向动作传递被这个类目分类的对象的情况下才有意义。
小组房屋出租系统结构特征分析：房屋出租系统的结构中有许多结构特征，如房屋的新旧等。
6.6 面向对象设计(Object-oriented design)认知说明：
面向对象设计（Object-Oriented Design，OOD）方法是OO方法中一个中间过渡环节。其主要作用是对OOA分析的结果作进一步的规范化整理，以便能够被OOP直接接受。
OOD是一种解决软件问题的设计范式（paradigm），一种抽象的范式。使用OOD这种设计范式，我们可以用对象（object）来表现问题领域（problem domain）的实体，每个对象都有相应的状态和行为。
OO方法以对象为基础，利用特定的软件工具直接完成从对象客体的描述到软件结构之间的转换。这是OO方法最主要的特点和成就。OO方法的应用解决了传统结构化开发方法中客观世界描述工具与软件结构的不一致性问题，缩短了开发周期，解决了从分析和设计到软件模块结构之间多次转换映射的繁杂过程，是一种很有发展前途的系统开发方法。
小组房屋出租系统面向对象设计分析：面向对象设计有利于把对象的属性和操作捆绑在一起，提高了对象（作为模块）的内聚性，减少了与其他对象的耦合，这为复用对象提供了可能性和方便性。在继承结构中，特殊类对一般类的继承，本身就是对一般类的属性和操作的复用。这大大提高房屋出租系统的可用性与对象的复用性，避免了代码的冗余。
6.7 开源程序代码(Open-source code)认知说明：
商务部源代码政策的发布是为了通过使定制开发的联邦源代码在整个商务部和其他联邦机构中可用来促进软件代码的重用。它支持OMB备忘录M-16-21“联邦源代码政策:通过可重用和开源软件实现效率、透明度和创新”的要求。这项政策要求代理机构在委托新的定制软件时，制定计划，以开源软件的形式发布至少20%的新的定制开发源代码。
该政策的目标是:
- 在获取任何定制开发的代码之前，就必须考虑的事项向部门提供指导；
- 要求部门获得定制开发代码的适当政府数据权利，至少包括政府范围内的再利用权利和修改代码的权利，并且此类定制开发代码应在联邦政府内广泛提供，但有有限的例外情况；和
- 建立发布定制开发的源代码的要求，包括获得必要的权利，使一些定制开发的代码作为开放源码软件在该政策的新试点计划下向公众发布。
小组房屋出租系统开源程序代码分析：房屋出租系统通过开源程序代码可以减少代码量，同时让代码更加通俗易懂。
6.8 域名(Domain Name)认知说明：
域名（英语：Domain Name），简称域名、网域，是由一串用点分隔的名字组成的Internet上某一台计算机或计算机组的名称，用于在数据传输时标识计算机的电子方位（有时也指地理位置）。
网域名称系统（DNS，Domain Name System，有时也简称为域名系统）是因特网的一项核心服务，它作为可以将域名和IP地址相互映射的一个分布式数据库，是进行域名(domain name)和与之相对应的IP地址 (IP address)转换的系统，搭载域名系统的机器称之为域名服务器，能够使人更方便的访问互联网，而不用去记住能够被机器直接读取的IP地址数串。
小组房屋出租系统域名分析：对于我们房屋出租系统，当所有的需求分析与代码都已经实现的时候，我们往往需要一个域名来发布我们的系统，这时就要用到了域名了。
6.9 动态分类(Dynamic Classification)认知说明：
动态分类也称为“动态类型”，处理改变“对象分类”的能力。该对象在其存在中可以改变其分类。例如，下图显示了人员工作的动态分类。“鲍勃”对象将其子类型更改为“经理”、“工程师”、“销售员”的实例。即使对象改变了它的子类型，它仍然只属于“人”类型。一般来说，动态分类允许对象从时间到时间。
小组房屋出租系统动态分类分析：在计算机编程语言中，动态分类起着重要的作用。描述对象分类的变化是面向对象分析的一个重要特征。一些编程语言支持有限程度的动态分类，而其他编程语言不提供直接支持。为了在程序中实现动态分类，每当对象改变它的类时，就为该类创建一个新的对象。然后将以前的对象特征复制到新对象中，然后删除旧对象，这有利于我们系统的编程各种模块，如房东管理模块。
6.10 形式参数(Formal Parameter)认知说明：
形式参数就是方法中使用的标识符，代表由调用方传递到方法中的值。 比如，数量是的形式参数processDeposit
形参的作用是实现主调函数与被调函数之间的联系，通常将函数所处理的数据，影响函数
功能的因素或者函数处理的结果作为形参。没有形参的函数在形参表的位置应该写int
main(void) 函数也
可以有形参和返回值，其形参也称为命令行参数，由操作系统在启动程序时初始化，其返
回值传递给操作系统。
小组房屋出租系统形式参数分析：形式参数一般是在创建一个函数或方法之中的，在主函数中通过传递参数到函数或方法，在函数或方法时这个参数就叫形式参数。形式参数尤为重要，比如我们系统中，如果要查一个房屋的信息时，我们可以通过传该房屋的id到方法或者函数之中进行后面的操作。
6.11 实际参数(actual parameter)认知说明：
实参，actual parameters，全称为"实际参数"是在调用时传递给函数的参数，即传递给
被调用函数的值。
实参可以是常量、变量、表达式、函数等，无论实参是何种类型的量，在进行函数调用
时，它们都必须具有确定的值，以便把这些值传送给形参。 因此应预先用赋值，输入等
办法使实参获得确定值。
实参类型
实参可以是常量、变量、表达式、函数等， 无论实参是何种类型的量，在进行函数调用
时，它们都必须具有确定的值， 以便把这些值传送给形参。 因此应预先用赋值，输入等
办法使实参获得确定值。
小组房屋出租系统实际参数分析：实际参数尤为重要，比如我们系统中，如果要查一个房屋的信息时，我们可以通过传该房屋的id（该id为实际参数）到方法或者函数之中变成形式参数进行后面的操作
6.12 警卫条件(Guard Condition)认知说明：
警卫条件就是一种必须满足的条件，以使关联的转换能够启动。
ESS状态机从它参与的所有场景中指定ESS行为。斯洛文尼亚就业服务局评估警卫条件以确定是否触发到下一状态的转换。保护条件指定输入值、电流状态和资源可用性。如果转换被触发，块执行从当前状态的退出动作，执行转换行为(即，效果)，并进入下一个状态。然后，它执行下一个状态的进入动作，接着是由活动定义的do/行为。转换行为可以包括发送信号动作，该动作可以触发另一个系统的状态机中的转换。系统的逻辑和物理设计必须实现系统状态机强加的控制要求。
一个简单的状态机将控制需求指定为一系列语句，如果在当前状态下发生输入事件，并且满足保护条件，则转换到下一个状态并执行选定的操作。
小组房屋出租系统警卫条件分析：房屋出租系统运用警卫条件可以提高系统安全性，当我们系统遇到一些严重的错误时，这时就会触发警卫条件，这时我们可以进行停止运行系统，这也有点像我们的火灾系统的警报器。
6.13 继承(Inheritance)认知说明：
继承是面向对象软件技术当中的一个概念，与多态、封装共为面向对象的三个基本特征。继承可以使得子类具有父类的属性和方法或者重新定义、追加属性和方法等。
继承可以使用 extends 和 implements 这两个关键字来实现继承，而且所有的类都是继承于java.lang.Object，当一个类没有继承的两个关键字，则默认继承object（这个类在 java.lang包中，所以不需要 import）祖先类
小组房屋出租系统继承分析：在房屋出租系统之中，运用继承可以实现类和类之间的关系还有依赖、组合、聚合，就像springboot框架里面的service与serviceImpl一样，通过编写service接口，之后就用serviceImpl来实现继承。
6.14 内部过渡(Internal Transition)认知说明：
如果需要在状态中定义内部转换，可以通过创建外部自转换连接器(其中源和目标是相同的状态)然后更改连接器种类属性来实现。然后，自转换连接器从图表中移除，内部转换显示在状态元素内的一个隔间中。
定义内部转换
小组房屋出租系统内部过渡分析：在房屋出租系统之中通过调用内部过渡可以清晰地看到每一步的操作，运用这个图，能让我们有清晰的思路去开发房屋出租系统。
6.15 数据库服务器(Database server)认知说明：
数据库服务器可以指用于运行数据库的硬件和软件。作为软件，数据库服务器是数据库应用程序的后端部分，遵循传统的客户机-服务器模型。这个后端部分有时称为实例。它也可以指用于托管数据库的物理计算机。在本文中提到时，数据库服务器通常是托管数据库的专用高端计算机。
数据库服务器可以指用于运行数据库的硬件和软件。作为软件，数据库服务器是数据库应用程序的后端部分，遵循传统的客户机-服务器模型。这个后端部分有时称为实例。它也可以指用于托管数据库的物理计算机。在本文中提到时，数据库服务器通常是托管数据库的专用高端计算机。
小组房屋出租系统数据库服务器分析：我们运用数据库服务器主要是为了实现硬件服务器设备上集成软件，完成数据的处理、缓存、转换等作用，这对于我们房屋出租系统处理数据有很大的帮助。
八、第七类关键词
8.1 元对象(MetaObject)认知说明：
元对象是元建模语言中所有元实体（例如元类型、元类、元属性和元关联）的总称。
小组房屋出租系统元对象分析：我们房屋出租系统需要创建元对象来调用里面的元类和元属性等元实体。
8.2 分层架构(Layered Architecture)认知说明：
这分层架构一般来说，它保护上层协议不受网络层变化的影响。然而，有几个问题需要解决。例如，计算数据包校验和的上层协议必须考虑IPv6中的变化，包括使用128位地址和最终目的地，而不是中间目的地路由标题等等。
简化的分层架构如所示图：
1. 门户网站。顶层是用户选择资源和发送请求的门户网站；本质上，有几种类型的虚拟机是预先配置的，供用户选择。
2. 调度的核心层。一旦用户请求被启动，它们就进入下一级云计划，用于根据用户请求选择合适的数据中心和项目经理。CloudSched为以下内容提供支持建模和仿真尤其是分配虚拟机(包括中央处理器、内存、存储、带宽等)。)到合适的PMs。这一层可以管理由数以千计的项目经理组成的大规模CDC。不同的调度算法可以根据客户的特点应用于不同的数据中心。
3. 云资源。最底层是云资源，包括项目管理系统和虚拟机，两者都由一定数量的中央处理器、内存、存储和带宽组成。
小组房屋出租系统分层架构分析：通过分层架构可以把我们系统分为门面网站、调度核心层和云资源。门面网站就是房客进行操作交互的HTML网站；调度核心层就是数据库层，房客可以进行修改个人信息等操作；云资源就是运行此系统的虚拟机，这也是最底层的资源。
8.3 设计模式(Design patterns)认知说明：
设计模式被用来代表一些由有经验的面向对象软件开发人员采用的最佳实践。设计模式系统地命名、激励和解释通用设计，解决面向对象系统中反复出现的设计问题。它描述了问题、解决方案、何时应用解决方案及其后果。
设计模式的六大原则
1、开闭原则（Open Close Principle）
开闭原则的意思是：对扩展开放，对修改关闭。在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果。简言之，是为了使程序的扩展性好，易于维护和升级。想要达到这样的效果，我们需要使用接口和抽象类，后面的具体设计中我们会提到这点。
2、里氏代换原则（Liskov Substitution Principle）
里氏代换原则是面向对象设计的基本原则之一。 里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。LSP 是继承复用的基石，只有当派生类可以替换掉基类，且软件单位的功能不受到影响时，基类才能真正被复用，而派生类也能够在基类的基础上增加新的行为。里氏代换原则是对开闭原则的补充。实现开闭原则的关键步骤就是抽象化，而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。
3、依赖倒转原则（Dependence Inversion Principle）
这个原则是开闭原则的基础，具体内容：针对接口编程，依赖于抽象而不依赖于具体。
4、接口隔离原则（Interface Segregation Principle）
这个原则的意思是：使用多个隔离的接口，比使用单个接口要好。它还有另外一个意思是：降低类之间的耦合度。由此可见，其实设计模式就是从大型软件架构出发、便于升级和维护的软件设计思想，它强调降低依赖，降低耦合。
5、迪米特法则，又称最少知道原则（Demeter Principle）
最少知道原则是指：一个实体应当尽量少地与其他实体之间发生相互作用，使得系统功能模块相对独立。
6、合成复用原则（Composite Reuse Principle）
合成复用原则是指：尽量使用合成/聚合的方式，而不是使用继承。
设计模式的类型
根据设计模式的参考书 Design Patterns - Elements of Reusable Object-Oriented Software（中文译名：设计模式 - 可复用的面向对象软件元素） 中所提到的，总共有 23 种设计模式。这些模式可以分为三大类：创建型模式（Creational Patterns）、结构型模式（Structural Patterns）、行为型模式（Behavioral Patterns）。当然，还有另一类设计模式：J2EE 设计模式。
小组房屋出租系统设计模式分析：我们的房屋出租系统可以运用以上所提供的的设计模式，如工厂模式。运用这些设计模式，可以使软件更容易修改和维护，同时由于模式还提供了观察问题、设计过程和面向对象的更高层次的视角，这能让开发人员提高观察高度。
8.4 多类别分类(Multiclass Classification)认知说明：
多类别分类器的基本思想：（其实一句话总结，还是将复杂问题化简为基础问题，将多类别分类问题转化为多个二值分类问题，然后可以求解出多个预测函数hi(x)，当有新的x到来时，就可以将其带入所有的预测函数中，计算中max时的i值，即可得到其所在的分类。）
小组房屋出租系统多类别分类分析：通过多类别分类可以让我们系统的复杂流程简单化。
8.5 多重继承(Multiple Inheritance)认知说明：
多重继承允许子类都拥有多个基类，要将作为纯接口的基类和具有实现的基类区别开来。
优点：多重实现继承比单继承重用更多代码。
缺点：真正需要用到多重实现继承的时候非常少，多重实现继承看上去是不错的解决方案，但是通常可以找到更加明确、清晰、不同的解决方案。
结论：除第一个基类中含有实现，其他的基类都是以 Interface 为后缀的纯接口类时才会使用多重继承。
小组房屋出租系统多重继承分析：通过多重继承，可以当某个类可能作为其他类的基类的时候，且它继承自某个类，则使用virtual继承，可以让它继承的类中如果有与其它共同基类重名的情况，不会导致保留两份成员而只会保留一份。这有利于我们开发房屋出租系统
8.6 n元联想(N-Ary Association)认知说明：
多维关联元素用于对三个或更多元素之间的复杂关系进行建模，通常在类图中。它不是一个常用的设备，但是当几个元素之间存在依赖关系时，它可以起到很好的效果。它通常与关联连接器一起使用，但是关系可以包括其他类型的连接器。
公司、员工和薪资之间存在关系如下图所示：
小组房屋出租系统n元联想分析：可以通过n元联想来创建我们的数据库，如房屋就包括房价，面积，位置等一些属性。
8.7 外显性质(Emergent properties)认知说明：
外显性质是各种系统组件一起工作的结果，而不是任何单个组件的属性。
换句话说，就是复杂系统或系统部件集合所具有的属性，但个别部分不具备。
该术语用于系统理论、科学、哲学，甚至是创造性的媒介，它概括了“大于其各部分之和”的习语。由于在更宏观的分析层次上可以看到涌现属性，因此只检查系统的单个部分将会阻止人们看到涌现属性。涌现属性的例子包括生化系统、大脑和蚁群。
小组房屋出租系统外显性质分析：在房屋出租系统之中，外显性质是多个系统组件（如订单系统，支付租金系统，房客管理系统等）一起运行的结果。
8.8 对象流状态(object flow state)认知说明：
在活动图中，定义动作间对象流的状态。对象流状态表示分类器实例在给定状态下的可用性，通常是操作的结果。
当需要传输对象时，由于对象是很多属性和行为的封装，数据量很庞大。所以在传输对象之前需要将对象打散成字节序列，以利于传输，这个过程 称为序列化过程。到达目的地以后，又需要将字节序列还原成对象，这个过程称为反序列化过程。
小组房屋出租系统对象流状态分析：房屋出租系统可以将对象的状态转换成字节流，以后可以通过这些值（字节序列）再生成相同状态的对象，这样就可以捕获事件和状态转换。
8.9 对象生命线形状(Object Lifeline shape)认知说明：
对象生命线形状在统一建模语言UML 1的各种交互图中对一个对象（或其他实体）的生存期的表示。在UML 2版本中简称为生命线（lifeline）。
在序列图中使用，对象生命线
表示对象在特定时间的存在。如果对象是在图表所代表的时间段内创建或销毁的，那么生命线将在适当的点停止或开始。一个物体的毁灭是用一个大x标记的。
小组房屋出租系统对象生命线形状分析：对象生命线形状是顺序图中的一个元素，添加该元素可以表示对象在特定时间的存在。这样可以清晰地了解房屋、房客和房东之间的对象的状态
8.10 持久化对象(Persistent Object)认知说明：
对象持久化是指将内存中的对象保存到可永久保存的存储设备中（如磁盘）的一种技术。
何谓“对象数据映射（ORM）” ORM-Object/Relational Mapper，即“对象-关系型数据映射组件”。对于O/R，即 Object（对象）和 Relational（关系型数据），表示必须同时使用面向对象和关系型数据进行开发。除了 ORM 技术，还有以下几种持久化技术：主动域对象模式、JDO 模式、CMP 模式。
小组房屋出租系统持久化对象分析：对于房屋出租系统来说，有时候会丢失数据，这时我们可以利用持久化对象将内存中的对象存储在关系型的数据库中，当然也可以存储在磁盘文件中、XML数据文件中等等，这样我们就可以避免数据丢失。
8.11 事务处理(Transaction processing)认知说明：
事务处理是一种支持交互式应用程序的计算方式，通常由大型服务器计算机执行。在事务处理中，工作被分为独立的、不可分割的操作，称为事务。相比之下，批处理是一种计算方式，其中一个或多个程序处理一系列记录(批处理)，用户或操作员很少或根本不采取行动。
当事务失败时，系统返回到事务开始时的状态。这个取消所有变化的过程称为“回滚”( rollback )。例如，如果一个事务成功更新了两个表，在更新第三个表时失败，则系统将两次更新恢复原状，并返回到原始的状态。
事务处理系统通过将应用程序与事务管理的细节隔离开来，允许应用程序程序员专注于编写支持业务的代码:
1、它管理事务的并发处理。
2、支持数据共享。
3、保证数据的完整性。
4、它管理事务执行的优先级。
小组房屋出租系统事务处理分析：房屋出租系统在录入数据（房屋数据等）的时候会出现一些错误，假如没有事务处理进行回滚操作，就会导致数据库里面的数据紊乱等问题，这时候事务处理的好处就充分发挥出来了。
九、建议
9.1 了解什么是产品需求
用户描述的可能不是他想要的，对于用户的描述每个人都有不同的理解。产品需求就是“想要”、“需要”和“需求”主要包括这三个方面。“想要”是用户外在表达出来的，而“诉求”是用户内在的心理预期。产品需求满足的是用户的内在诉求，这是根本。
对于想要来说，它是是外在的、具体的和有指向性的解决方案；需要是内在的、原始的最终动机；需求是满足内在需要的同时，在可控成本内实现外在想要的解决方案。
9.2 了解需求对象
在我们软件开发当中，需求对象的选取是很重要的，但凡缺少考虑一个涉众，系统都不会完整。所以，我们往往都需要对涉众进行分析，了解他们的需求。涉众是与要建设的项目系统相关的一切人和事，他们与项目有利益关系，都可能对系统建设造成影响。需要注意的是用户并不是涉众，涉众是指那些关注系统的人，而用户是指系统方面的真正使用者，也就是用例图中的角色。
在这个过程中我觉得最重要的过程是换位思考，从他们的角度来模拟他们所需要的需求，从他们的角度出发，扩大思维去思考他们所会遇到的问题，进行全面的分析，只有这样，才能够让我们更加接近涉众的想法，而不是因为涉众的问题导致后面的工作被拖慢，甚至偏离涉众需求的本身。
9.3 获取需求，识别问题
了解完需求对象之后，我们便要对涉众进行分析，识别他们的问题。在软件开发的历史中，有许多都是因为需求考虑不恰当，导致了许许多多的问题出错，达不到项目管理人或投资方的不满意，因此我们需求可以从用户的购买欲望和购买力下手。那么，我们如何识别需求呢？我们可以从视角、效率和体验来分析。
1、视角
作为产品经理，我们要具备多样化的视角来审视需求和产品，分为用户视角和产品视角。比如:关于微信朋友圈可见范围的例子，相比于之前三天可见和半年可见，增加了一个月可见范围。在这个设计里，用户往往会站在自我的角度说，“不想让别人看我的朋友圈”，这是用户视角。而产品视角是考虑群体和整体，是“让用户更小压力去发朋友”。这种视角差异，最终的方案也会有差别。用户视角满足的是“想要”(Want)，产品视角实现的是“需要”(Need)。
2. 效率
另一个识别需求的维度就是效率。在最优效率的前提下，满足尽可能多的用户需求。我们还是用一个例子来说明，用过微信公众号赞赏功能的人都知道，如果自己赞赏过作者，那自己的头像就会始终排在最前面。如果自己没有赞赏过，那每次进入文章，且赞赏人数超过 24 人后，底部的赞赏头像都不是固定顺序展示的。
3. 体验
最后一个识别需求的维度就是体验，关于体验，做产品的同学就比较熟悉了。体现在信息架构设计、流程设计、交互设计还有文案设计等方面。体验也是一个很虚的指标，很难量化，每个人的认知和感受都会因为习惯、文化、个人倾向产生差别。任何细节的体验设计，都会给用户传递一个认知，而我们要明白的是，独立个体的认知差异是很大的。比如:对于“快车”这个概念，刚出来的时候，大众是无认知的，只能找到对标，比如出租车和专车，而快车是介乎于两者之间的一种服务。如何更好的设计快车体验呢，其实用价格比专车低、比出租车干净舒服、且车多三个认知来传递给用户，就能让用户快速接受并理解。
9.4 对需求进行分类
在需求分析中，我们一样需要划分需求等级，可以划分为，“紧急不重要”、“紧急重要”、“不紧急不重要”和“不紧急重要”这四个方面。
紧急不重要：有计划去做，属于重点规划，对当前有强依赖性。
紧急重要：立刻去做，比如线上出现bug，影响到了产品的完整度。
不紧急不重要：暂时不做，属于优化类，也就是锦上添花的需求。
不紧急重要：交给别人做，属于不可缺少最小可行化需求。
9.5 需求价值评判
评判需求价值可以从三个方面去实现，分别为广度、强度和频率。
1. 广度:受众人群以及受众面
2. 强度:用户对于需求的迫切程度
3. 频率:间隔时间及可持续性
所有对需求的价值判断，都基于对行业、市场的探知程度;对人性的认识和了解程度(发现没有，把握人性始终贯穿产品的各个层面)
9.6 提升需求分析能力
对于如何提升分析能力，可以分为三方面，分别为倾听、观察和同理心。
1. 倾听
面对需求方，不论是用户还是运营还是工程师，首先做到先听，这是放下自我做产品的前提。什么是事实? 客观的原因和现象是事实，基于现象去分析背后的原因，基于原因再形成观点。
2. 观察
观察是最好的洞察用户需求的方式，到用户身边去，看他们做了什么，行动往往反映了用户的真实诉求。
3. 同理心
如何切身感受、设身处地呢?最简单的方式就是到用户的环境中去，感受用户不如变成用户。只有切身感受，尤其是感受到了痛，你才真的理解了用户。
十、总结
经过需求分析与建模一学期的学习，我对需求工程有了整体的认识。在我看来，需求分析其实就是一门关于软件工程开发的思想，它教会了我如何去思考和分析软件开发的过程。或许这门课程不需要我们敲代码，但是它确是软件开发中无比重要的一部分，而且也是耗费时间最多的一个过程。一个项目的成功与否都取决于需求分析的完不完整。在学习这门课程之前，我大部分都是接触代码，觉得这个需求分析不重要。在我学习之后，我就发现它的重要性，它是一个项目的灵魂。或许写代码也是其中的一个重要部分，但是需求分析与建模却是重中之重。也许你写代码很厉害，但是不懂得需求获取与分析，那么你写出的代码也是无用功，因为它不符合涉众的需求，只是一个失败的系统。
在这门课程中，我知道了需求分析和需求获取是什么和如何分析、需求建模的目的和建模前的各种细节。需求分析的任务并不是分析系统如何实现用户的需要，而是选择一种业务导向的线索将零散的需求串起来，形成一个体系完整、内容清晰的框架，以指导后续的设计和开发工作。需求分析与获取是通过“四方块”来考虑的，准确理解用户和项目的功能、性能、可靠性等具体要求，将用户非形式的需求表述转化为完整的需求定义，从而确定系统必须做什么的过程。需求建模就是采用文字、图形化、表格化、公式化的方式，按照系统需求情况对系统进行可视化描述，提供一种详细说明系统的结构或行为的方法，帮助我们按照实际情况或按我们需要的样式对系统进行可视化。就好比老师叫我们用EA精灵开模来画的图，通过这些图来描述系统的各个流程或者一些重要的描述，使得我们通过图形更加容易了解我们系统的需求和存在的不足之处。