第四章重点：

    1、需求的概念：需求就是陈述系统必须要做的事或者系统必需具备的特征。

    1)需求分为功能需求和非功能需求。能需求与系统必须执行的过程或必须包含的信息有直接关系。非功能需求指的是系统必须具备的行为属性，如性能、安全性和可用性等。功能需求：面向过程-系统必须执行的过程和完成的任务;面向信息-系统必须包含的信息;

    2)在分析阶段，从业务员角度出发，关注的是业务用户的要求，因此也称为业务需求(用户需求);在设计阶段，主要从开发人员角度出发描述，称为系统需求。特征，及其收集需求的技术的优缺点;

    2、需求的特征：描述系统必须实现的功能;描述系统必需具备的特征;在分析阶段关注用户的要求;需求在项目的不同阶段会发生改变。

    典型的非功能性需求：

    1)性能表示为满足用户的需要而要求系统展示的性能--吞吐量、响应时间;

    2)信息表示有关用户的信息，形式为内容、时间性、正确性和格式--需要输入和输出是什么，数据存储在什么地方等，对外接口;

    3)经济表示系统对减少开支或增加收益的需要-必须减少开支的是什么，预算限度是多少;

    4)控制表示系统必须在其中运行的环境以及必须提供的安全类型和程度--访问控制，对数据的特殊处理(脱机备份等);

    5)效率表示系统以最低成本产生输出的能力--在过程中有必须消除的重复步骤，用其资源的方式中存在降低成本的方法吗;

    6)服务表示使系统可靠、灵活和可扩充的需要-不同类型的用户，培训、相关文档资料。

    3、收集需求的技术及其优缺点：

    面谈，问卷，观察现场，联合应用开发，文档分析。

    1)面谈：面谈通过直接、面对面的交互获取需求。这种方式可以用来实现以下目标：发现事实、验证事实、澄清事实、激发热情、让最终用户参与、确定需求以及征求想法和观点。

    面谈的缺点：面谈耗时，费用高;面谈的成功极大地取决与采访者的个人的能力;面谈可能会由于被采访者的地理位置功;面谈有两种类型：结构化面谈和非结构化面谈。非结构化面谈的特点是涉及一般性的问题，被采访者可以引导谈话过程。这种方式容易偏离主题，采访者需要及时的引导。结构化面谈要求采访者询问一套专门设计用于从被采访者处获取特定信息的问题，根据被采访者的回答，采访者将提出额外的问题(计划的问题或非计划的问题)以进一步深入。准备是面谈成功的关键，面谈之前如果没有很好的准备，那么面谈就无法获得满意的结果。在面谈之前最好准备一份面谈指南，安排好提问的问题，每个问题的时间，在什么地方可能需要进一步的提问等。在面谈的过程中，需要注意以下事项：假定答案存在或不存在;提示线索;使用行话;显示个人偏见;谈论而不是聆听;对有关主题和被采访者的情况作出假定;使用录音-聆听能力差的表现。

    2)问卷：问卷调查表可以使分析员从一大群人那里收集到事实，同时保持统一的答复。尤其是当需要面对大量的人时，其他调查研究技术都不可能有如此有效的得到结果。问卷调查表的优点：

    --大多数的调查表可以被快速的回答;

    --调查表提供了一种可以以相对廉价的方式从大量的人中收集数据;

    --调查表可以匿名填写，因此更能得到真实的数据;回答可以快速的表格化和分析;

    问卷调查表可以使分析员从一大群人那里收集到事实，同时保持统一的答复。尤其是当需要面对大量的人时，其他调查研究技术都不可能有如此有效的得到结果。

    问卷调查表的缺点：回答者的数量经常较低;无法保证个人会回答或进一步回答所有问题;调查表往往不灵活;没有机会立即澄清对问题的含糊或不完全的回答。

    制作问卷调查表：确定必须收集什么事实和观点以及你应该从谁那里收集;根据需要的事实和观点，确定是采用自由格式还是固定格式;编写问题，确保问题中没有反映个人的偏好和观点;在小样本中进行测试，发现问题及时修正;进行调查。

    3)联合应用开发：一对一的面谈需要使用大量的时间，使用小组会议的形式进行面谈就可以解决这个问题。JAD就是采用小组会议的形式来获取需求。一般来说，一个成功的JAD需要负责人、主持人、用户和管理员、记录员、参与系统开发建设的其他相关人员等角色的参与.

    第五章

    1、重点用例分析(10分)DFD(10分)、类图(10分)

    2、建模原则(了解)建模的原则：选择建立什么样的模型对如何发现和解决问题具有重要的影响;每个模型可以有多种表达方式;最好的模型总是能够切合实际;孤立的模型是不完整的。任何好的系统都是由一些几乎独立的模型拼凑出来的。

    UML建模(知道)背景：1994年10月，Rational公司的Booch和Rumbaugh决定将其Booch方法和OMT方法综合成一个新的建模语言，并于1995年10月公布了UnifiedMethod0.8。

    1995年秋季，Jacobson及其OOSE方法加入Rational公司，决定将OOSE方法与UnifiedMethod进行综合，更名为UML，并分别于1996年6月和10月公布了UML0.9和UML0.91。

    1996年，DEC、HP、I-Logix、Intellicorp、IBM、ICON、MCI、Microsoft、Oracle、Rational、会，于1997年1月推出了UML1.0，并向OMG申请将其作为一种标准语言。1997年9月产生了UML1.1，11月被OMG正式采纳。1999年6月，OMG发布了UML1.3。1999年7月，UMLRealTime随RoseRealTime推出。2001年9月，OMG发布了UML1.4。2004年4月，OMG发布了UML1.5。2005年7月，OMG发布了UML2.0。

    用例：描述了一系列执行的活动所产生的一些输出结果。每个用例描述了外部用户如何来触发系统必须响应的事件。在事件驱动模型中，系统的一切行为都被认为是对某个触发事件的响应。

    相关：用例是由外部用户触发;每个用例只描述单独的任务，而不能描述多个任务;用例必须产生一个对用户有意义的结果;场景(Scenario)是用例的一个执行实例，是例执行;过程中的一条实际路径，一个用例可能会包含多个场景;

    UML中的用例视图只能反映出两类信息：

    1)哪些外部用户会和统发生交互

    2)系统需要实现哪些功能特性

    基本信息：

    1)每个用例都有一个名称、编号和简要描述。为了明确标识某些用例在整个系统中的相对重要性，需要使用优先级来表示。用例(usecase)是一个行为上相关的步骤序列，代表的是一个相对完整的业务任务。UML中的用例是动作步骤的集合。动作(action)是系统的一次执行(能够给某个参与者输出结果值)。与参与者通信，或进行计算，或在系统内工作都可以称作动作。用例应支持多种可能发生的动作，每个动作由许多具体步骤实现。

    2)用例的元素：参与者是存在于系统之外并与系统交互的人或事。所谓“与系统交互”指的是参与者向系统发送消息，从系统中接收消息，或是在系统中交换信息。参与者是一个群体概念，代表的是一类能使用某个功能的人或事，参与者不是指某个个体。

    3)输入和输出每一个用例的主要输入、输出连同其来源和目的都要进行描述。它包括所有可能的输入输出，而不仅仅是用来通常用的部分。建造用例是一个逐渐提炼的过程，用例在分析的过程中可以逐步的完善。

    4)细节：用例需要描述详细的步骤和它们所使用到的输入和输出，这些步骤就是用例中所执行的活动。

    第六章

    1、活动图的概念：活动图(activitydiagram)显示了组成复杂过程的步骤序列，如工作流或算法。活动图是对系统的行为进行建模，活动图是把系统的一项行为表示成一个可以由计算机、人或其他执行者执行的活动，通过给出活动中的各个动作以及动作之间的转移关系来描述系统的行为。

    2、活动图与流程图的区别：

    流程图着重描述处理过程，它的主要控制结构是顺序、分支和循环，各个处理之间有严格的顺序和时间关系;而活动图描述的则是对象活动的顺序关系所遵循的规则，它着重表现的是系统的行为，而非系统的处理过程。活动图能够表示并发活动的情形，而流程图做不到。活动图是面向对象的，而流程图是面向过程的。

    3、使用活动图的目的：描述一个操作执行过程中(操作实现的实例化)所完成的工作(动作);描述对象内部的工作;显示如何执行一组相关的动作，以及这些动作如何影响它们周围的对象;显示用例的实例是如何执行动作以及如何改变对象状态;说明一次业务活动中的工人(角色)、工作流、组织和对象是如何工作的。

    4、活动图的组成：

    1)动作是构成活动的基本单位，它是原子的、不可中断的，并在动作完成后通过完成转换转向另一个状态。

    动作的特点：动作是原子的，不可以分解成更小单位;动作是不可中断的;动作是瞬时完成的行为;动作可以有入转换，至少有一条出转换;动作不能有入口动作和出口动作;在一张活动图中，动作允许出现多次;

    2)活动是由一系列动作构成的，是对一项系统行为的描述。

    活动的特点：活动可以分解成其他子活动或动作;活动的内部活动可以用另一个活动图来表示;活动可以有入口动作和出口动作，还可以有内部转移;

    3)动作流

    4)条件是让转移修改任何工作流的方向所必须的。

    5、顺序图：顺序图(SequenceDiagram，时序图，序列图)详细描述对象间传送消息的时间顺序，它表示用例中的行为顺序。顺序图它详细而直观地表现了一组相互协作的对象在执行一个(或少量几个)用例时的行为依赖关系，以及操作和消息的时序关系。类图对对象之间的消息(交互情况)表达不够详细;详细说明对消息的表达虽然详细，但不够直观;顺序图既详细又直观，但通常只能表示少数几个对象之间的交互。

    2)活动对象：活动对象可以是系统的参与者或任何有效的系统对象。在活动图中对象的标记如下图所示。将对象置于时序图的顶部意味着在交互开始的时候对象就已经存在了，如果对象的位置不在顶部，那么表示对象是在交互的过程中被创建的。

    生命线是一条垂直的虚线，表示时序图中的对象在一段时间内的存在。每个对象的底部中心的位置都带有生命线。

    ·生命线是一个时间线，从时序图的顶部一直延伸到底部，所用的时间取决于交互持续的时间。

    ·对象与生命线结合在一起称为对象的生命线，对象的生命线包含矩形的对象图标以及图标下面的生命线。

    ·如果对象在图中被创建，那么对象符号画在创建它的消息上，否则画在任何消息箭头上。如果对象在图中被撤销，那么用“×”表示撤销。

    消息定义的是对象之间某种形式的通信，它可以激发某个操作、唤起信号或导致目标对象的创建或撤销。

    ·消息是两个对象之间的单路通信，从发送方到接收方的控制信息流。

    ·消息可以用于在对象间传递参数。

    ·消息可以是信号，也可以是调用。

相关推荐：

谨防受骗：揭露所谓“考前卷子考后付款”的骗子伎俩

论软件架构师的角色和培养:角色与定位

信息系统项目管理师考试成本管理知识点解析