软件工程复习笔记.doc

CH0 概论
本章重点：
v 软件工程的定义
v 什么是软件退化
v 软件与程序的区别
v 软件工程的组成
v 客户和用户的定义
v 常见的软件神话，他们错在何处？
v 软件工程的目标有哪些？
v 软件工程的目标中最重要的是哪个？
v 软件过程是一种层次化的技术，其层次结构是什么样的？
v 软件是想改就能改的吗？
v 软件开发时是不是越早开始写代码越好

1.为什么需要软件工程：
个人、企业和政府在日常活动、管理和战略战术决策时越来越依赖于软件，因此必须确保软件的质量；
鉴于软件开发成本巨大，因此必须确保开发出来的软件能够满足目标用户的真实要求；
随着软件越来越复杂，其开发和实际也越来越复杂，必须确保开发活动的有序、有效；
随着软件用户数量和寿命的增加，对其适应性、可扩展性的要求也在增加。必须确保软件具备良好的可维护性。
2.软件工程定义
最经典的定义：软件工程是对合理工程原则的建立和使用，其目的是为了经济地获得可靠的、可以在实际机器上高效运行的软件。
IEEE给出的定义：将系统化的、规范的、可量化的方法应用于软件的开发、运行和维护。即将工程化方法应用于软件。
课程给出的定义：软件工程是为了经济的开发出高质量的软件，并有效的维护它，将工程、管理手段与技术手段相结合应用于软件的方法的集合
目的：经济的开发出高质量的软件，并有效的维护它
方法：将工程、管理手段与技术手段相结合
3.软件工程要实现多个目标，这些目标之间的重要性不一样——价值观问题
软件工程的目标如下：又好又快
Ø 保证软件质量
Ø 提升开发效率、降低开发成本
Ø 提高维护效率、降低维护成本
4.软件的定义：计算机系统中与硬件相互依存的另一部分，是程序、数据及其相关文档的完整集合。软件是逻辑的而非物理的系统元素。

5.软件的特点：
Ø 没有物理实体
Ø 设计开发成本高昂，生产复制则几乎是零成本的
Ø 软件不会磨损、老化，但是也会退化
软件退化：随着软件的维护升级，软件结构逐渐偏离原有设计并导致了软件质量的下降，称为软件退化。
Ø 软件发展的速度落后于硬件和实际需求
Ø 软件占计算机系统成本的比重越来越大
Ø 软件开发尚未真正实现标准化
6.软件与程序的区别：
软件不仅仅只是计算机程序
7.软件工程组成：
软件工程是一种层次化的技术
Ø 质量优先是整个软件工程的核心价值观（以质量为中心）
Ø （软件）过程：由为建造、维护高质量软件所需要完成的一系列相互关联的活动组成的框架，即形成软件产品的一系列步骤。过程是软件工程管理和实施的基础。
Ø 方法：软件开发和维护过程中一些具体问题的最佳解决手段。方法是软件工程的核心手段
Ø 工具：为实现软件工程中各种过程和方法的自动化和半自动化而开发的程序系统。工具是软件工程的效率倍增器。
8.软件工程必须重视人员的培训。
9.软件工程中的相关人员：
Ø 用户User：软件使用者。目的是使用软件解决问题或提高工作效率。
Ø 客户Customer：为软件付钱的人。他们的目标是增加利润，或只是使业务运作更为有效。
Ø 软件开发人员Developer：开发并维护软件的人。
Ø 开发管理人员Manager：管理软件开发过程的人员。其目标是花最少的钱满足客户要求
10.软件神话：关于软件及其开发过程的一些错误说法。
Ø 神话一：因为软件是由弹性的，因此可以很容易的适应需求变化。（修改软件要付出成本）
Ø 神话二：如果我们无法按时完成计划，可以通过增加电脑和程序员人数赶上速度。
Ø 神话三：软件过程就是严格按照完成的软件开发标准和规程来开发软件。（错在把手段当成了目的，应该根据项目实际需要，灵活安排实际的软件过程活动）
Ø 神话四：当程序编写完成并交付给客户后，任务就完成了，因此应该尽快开始编写代码。
Ø 神话五：软件工程会导致我们产生大量无用的文档，因此降低了效率。（创建文档的目的是保证开发软件的质量）文档最重要的作用是（1）促使开发者认真思考和（2）促进交流。

CH1 软件过程与方法
本章重点：
v 过程管理的任务
v 过程的定义
v 五个核心软件活动
v 几种软件过程模型，其活动间的顺序关系是怎样的（顺序、迭代、演化还是并行？）
v 原型及其作用
v 敏捷开发的价值观
v 敏捷开发的基本推动力

1.过程管理：辨识出一连串的商业活动，并针对这些活动的作业流程进行管理。
2.过程管理的目标：
Ø 确保企业中各种商业活动的执行成果能具有一定的水平和精确度。
Ø 确保能持续改善活动的进行方式，串连活动的作业流程
Ø 让企业能保持市场上的竞争力
3.过程管理的任务：
Ø 寻找、发现企业中有价值的业务过程（过程识别）
Ø 发现、去除非增值活动，简化过程；通过合理安排活动顺序提高过程效率（过程梳理和优化）
Ø 对过程各个活动进行规范，形成标准（过程固化）
Ø 对过程执行情况加以监控（过程监控）
Ø 寻找过程中的错误、薄弱、低效环节并加予以纠正（过程改进）
4.过程：也称业务过程，指为客户创造价值的一系列相互关联、有组织的活动或任务的集合。
v 管理学意义上的过程是有明确目的性的：为客户（或企业）创造价值
5.（业务）过程的特点：
Ø 可确定性：有明确的输入、输出和边界；
Ø 顺序：构成过程的活动，必须在时间和空间里具有确定的顺序；
Ø 客户：过程的结果必须有接收者——客户。
Ø 增值：在过程中发生的转换必须为接收者增加价值，无论接收者是在过程的上游还是下游。
6.软件过程：构建、维护软件产品时所执行的一系列步骤（活动、动作和任务）的集合。
v 活动：组成软件过程的最主要的宏观步骤。
Ø 例如：需求分析、设计、编码、发布等。
v 动作：对活动进一步细分的得到的步骤。
Ø 例如设计活动，可以细分分为总体设计、模块设计等多个动作。
v 任务：具体的工作步骤
7.核心软件活动：所有合理的软件过程都包含一些共同的必要的活动（步骤），这些活动我们称为核心软件活动。
8.软件过程通常包括下列五个核心软件活动：
Ø 需求分析：通过与客户的沟通协作，了解客户的真实需要，决定软件特性和功能，制定项目目标。
Ø 建模（设计）：通过构造软件模型(通常是图形形式的模型）的方法来研究、理解具体问题，（向客户和其他开发人员）展现具体解决方案。
Ø 编码与测试：实际编写代码、验证代码的正确性
Ø 运行与部署：将软件交付用户使用。通常用户会对软件进行一段时间的试用，并给出反馈意见
Ø 维护：修复用户使用过程中发现的软件缺陷，或者根据用户使用意见对软件进行改进
9.在实际软件过程中往往还存在一些贯穿整个过程的普适性活动，以帮助软件团队管理和控制项目进度、质量、变化和风险。项目管理的角度说，这些“普适性活动”实质上是项目管理活动。常见普适性活动包括：
Ø 策划：创建软件项目的“地图”，以指导团队的项目旅程。通常包括：需要执行的具体任务、每个任务需要的资源分配，每个任务的具体产品，以及工作计划等
Ø 项目跟踪和控制：定期评估项目进度情况，采取必要措施确保项目按期完成
Ø 风险管理：对可能影响项目进度和产品质量的风险进行评估，并采取必要措施来降低风险
Ø 测量：定义和采集关于过程、项目和产品的度量数据，以帮助管理和改进其他活动。例如：开发人员的生产率等
Ø 软件质量保证：确保软件质量的措施和活动
Ø 软件配置管理：管理软件（代码、配置信息及其文档）的版本变化历史
Ø 可复用管理：建立产品（代码等）复用的机制和标准（如公用函数库等）
Ø 人员培训：对相关人员进行必要的培训，使其具备必要的知识和技能，掌握相关工具的使用方法
10. 软件过程模型是从一特定角度提出的软件过程的简化描述。
过程流（模型）是最主要的一类软件过程模型。
过程流描述了如何在执行顺序和执行时间这一层面上，组织软件过程中（除维护之外的）的活动。
11.几种主要的过程流及典型过程模型：
Ø 线性过程流：瀑布模型
Ø 迭代过程流：原型开发模型
Ø 演化过程流：螺旋模型
Ø 并行过程流
Ø 混合过程流：增量模型

12.瀑布模型：又称软件生存周期模型，瀑布模型严格按照软件生存周期各个阶段来进行开发，上一阶段的输出即是下一阶段的输入，并强调每一阶段的严格性。每一阶段的任务完成后，都必须对其阶段性产品（主要是文档）进行评审，通过后才能开始下一阶段的工作。
是一种以文档作为驱动的模型
v 软件生存周期：软件从定义开始，经过开发、使用和维护，直到最终退役的全过程称为软件生存周期。瀑布模型将软件生命周期分成软件定义、软件开发、运行、维护及退役五个时期组成。
v 优点：可强迫开发人员采用的规范方法；
严格规定了每一阶段必须提交的文档；
要求每一阶段交付之产品都必须经过质量保证小组的仔细审查；
清晰区分了逻辑设计与物理设计，尽可能推迟程序的物理实现；
提供了软件开发的基本框架，有利于大型软件开发过程中人员的组织、管理，有利于软件开发方法和工具的研究与使用，因此，在软件工程中占有重要的地位。
v 缺点：要求在项目开始的需求分析阶段就能够完整的得到客户的所有需求，现实中很难实现
客户要到项目接近尾声的验收阶段才能够看到实际的程序执行效果。如果这时才发现程序和客户实际要求有重大偏差，就可能会造成重大的损失
13.原型开发模型：
原型，就是软件的一个模拟的可执行界面。用户可在原型上进行操作，直观的感受软件的执行效果。
原型开发就是软件开发人员根据用户提出的软件基本需求快速开发一个原型，向用户展示软件界面和功能。在征求用户对原型的评价意见后，进一步改进、完善原型，如此迭代，直到软件开发人员和用户都确认软件系统的需求并达成一致的理解为止。
优点：
Ø 原型的开发和评审时系统分析员和用户/客户共同参与的迭代过程，有利于双方充分理解和沟通。
Ø 比瀑布模型更符合人们认识事物的过程和规律，项目成员能够更清晰的理解用户实际需求。
Ø 如果原型的开发语言和实际软件相同，那么它的若干高质量的程序片段和开发工具也可被用于工作程序的开发。
快速原型的开发途径：原型仅仅是需求分析的一部分，因此必须尽可能快速的开发原型。
建造原型应尽量采用相应的软件工具和环境，并尽量采用软件重用技术，在运行效率方面可做出让步，以便尽快提供。同时，原型应充分展示软件系统的可见部分，如人机界面、数据的输入方式和输出格式等。
缺点：
v 原型开发模型要求开发者和用户在一段时间内紧密配合、共同参与完成原型系统的开发，特别是需要用户的及时反馈。如果用户对此不够重视，那么原型开发的意义也就大打折扣了。
v 原型的快速构造容易让用户误以为实际软件的开发也是可以很容易、很快就完成的，或者要求开发者直接将原型稍加修改使之成为实际运行的产品。
v 而实际上，为了快速开发原型，开发者往往会牺牲软件质量和可维护性而采取了最快速的开发手段，因此实际的高质量软件产品需要抛弃原型从头开发。
v 如果不能够充分的向客户解释这一点的话，就容易导致软件开发人员和用户之间产生矛盾。
v 原型开发模型最大的缺点在于，它仍然没有解决需求变化的问题。
14.螺旋模型：一种演化式的软件过程模型。结合了原型开发模型的迭代性和瀑布模型的系统性和可控性特点。
螺旋模型的每一个迭代周期都包括计划（需求定义）、风险分析、工程实现和评审4个阶段。
螺旋模型是一个风险驱动的模型，每个迭代周期都不应该太长（一般是2-8周左右）
螺旋模型优点：
Ø 支持用户需求的动态变化
Ø 原型可看作形式的可执行的需求规格说明，易于为双方共同理解；开发者和用户共同参与软件开发，可尽早发现软件中的错误。
Ø 螺旋模型特别强调原型的可扩充性和可修改性。既保持瀑布模型的系统性、阶段性，又可利用原型评估降低开发风险。
Ø 螺旋模型为项目管理人员及时调整管理决策提供了方便，进而可降低开发风险
螺旋模型缺点：
Ø 如果每次迭代的效率不高，致使迭代次数过多，将会增加成本并推迟提交时间
Ø 使用该模型需要有相当丰富的风险评估经验和专门知识，要求开发队伍水平较高
适用场合：支持需求不明确、特别是大型软件系统的开发，并支持面向规格说明、面向过程、面向对象等多种软件开发方法
15.增量过程模型：螺旋模型基础上的改进。采用并行方式 解决阻塞带来的浪费问题
16.敏捷开发提出的背景：
传统过程开发模型都是从管理者的角度来看待软件开发，存在重大缺陷：
忽视变化的存在；忽视了软件开发是一个智力密集型的工作；忽视了人与人之间的直接交流；过分注重过程。
17.敏捷开发宣言：敏捷开发的价值观
Ø 个人与交流 胜于 开发过程和工具
Ø 可运行的软件 胜于 面面俱到的文档
Ø 客户协作 胜于 合同谈判
Ø 响应变化 胜于 按部就班遵循计划
18.敏捷的基本推动力：普遍存在的变化
19.敏捷鼓励：
Ø 使沟通更便利的团队结构和协作态度
Ø 快速交付可运行产品而非中间文档
Ø 客户以开发团队中的一员的身份参与项目
Ø 根据实际情况灵活调整项目计划
20.敏捷开发非常强调人的因素在软件项目开发中的重要性
敏捷开发强调团队及其成员应该具备下列要素：基本能力、共同目标、精诚合作、决策能力、相互尊重和信任、不断学习、自我组织。
21.敏捷过程模型：
Ø 极限编程（eXtreme Programming,XP）
Ø Scrum
Ø 特征驱动开发（FDD）
Ø 精益软件开发（LSD）
Ø 统一过程（AUP）
22.极限编程：

XP定义了五个有重要意义的要素：
Ø 沟通：强调口头的、面对面的交流
Ø 简明：为了简化设计，只对当前的需要做设计。当设计需要改进时，使用重构来实现。
Ø 反馈：通过测试、增量交付和持续集成等手段，快速获得反馈
Ø 鼓励：鼓励符合极限精神的实践。例如，尽可能减少过度设计。
Ø 尊重：敏捷团队应在内部成员之间，以及内部成员与其他利益相关者之间，灌输相互尊重的思想。减少推诿和扯皮，增加协作。
23. Scrum是一种迭代式增量软件开发过程
冲刺：一个15-30天周期
在冲刺的过程中，没有人能够变更冲刺订单
24.软件过程领域最新的流行趋势是DevOps，强调开发和运营的密切协作，运营部门在软件的产品设计、开发和测试过程中都要深度介入。DevOps也强调最新工具，如持续集成等自动化工具的使用，以提高工作效率并实现快速反应。
25.小结：
v 需要将软件开发划分为一系列规范化的步骤，使之便于实施和管理。
v 软件开发需要客户的深入参与和合作
v 软件开发的主体是人，必须重视人的需求和交流沟通
v 软件开发过程必须具备高度的灵活性，以适应变化。
v 总之，软件开发过程在不断引入新的技术和工具的同时，对管理者也提出了越来越高的要求

CH2 需求分析概述
本章重点：
v 软件需求的概念
v 需求分析的目标
v 功能需求与非功能需求
v 企业管理各个层级对信息系统的需求主要是什么？企业管理信息系统可分为哪两大模块，各自对应哪个管理层级的需求
v 需求分析的五个阶段（都做什么）；
v 需求跟踪与需求状态跟踪各自都做什么？

1.导致项目不能按计划完成的最重要的三个原因是：
Ø 缺少用户反馈（12.8%）
Ø 需求不完整（12.3%）
Ø 需求变化（11.8%）
软件需求是决定软件开发成败的关键因素
2.(软件)需求(Requirement)：为了解决客户的特定问题，软件所必须提供的能力和必须遵从的约束条件。
3.需求分析：项目人员确定用户需求所需要做的工作
需求分析的目标：
Ø 弄清楚客户/用户究竟想用软件来干什么。
Ø 弄清楚用户究竟想怎么用。
Ø 让客户明确他最终能得到什么样的产品
需求分析的成果：软件需求说明书
4.需求通常分为功能需求和非功能需求两大类
功能需求：描述系统应该提供的功能或服务，通常涉及用户或外部系统与该系统之间的交互。即软件必须提供的能力。
Ø 业务需求、用户需求、功能需求、系统需求
非功能需求：从各个角度对系统的约束和限制，反映了应用对软件系统质量和特性的额外要求，例如响应时间、数据精度、可靠性、开发过程的标准等。即软件的约束。非功能需求难以被测试和雁阵；容易被忽视。
业务规则、质量属性、外部接口、约束条件
5.除非必要，否则需求中不应该包含技术细节
6.软件需求的固有困难：
Ø 用户不一定清楚的知道他到底想要什么；
Ø 软件开发人员不了解项目的业务背景知识；
Ø 日常交流所用的语言文字本身具有很大的模糊性；
Ø 用户企业不同部门之间需求彼此矛盾；
Ø 用户的需求经常会发生变化
7.需求工程就是：形式化、工程化的需求分析
8.软件需求工程的五个阶段
Ø 需求获取：软件开发人员通过与用户之间的有效沟通,了解用户对软件真实需要的过程。
本质：开发人员与用户间的沟通
目的：了解用户对软件的真实需要
需求获取的内容：
v 客户的战略
v 相关的业务过程
v 相关规章制度、业务规则等
v 相关票据、记录、报表等

业务规则:描述业务处理可能遇到的情况及相应的处理措施或约束。
需求获取方法：个别访谈、会议、调查、观察

Ø 需求分析与协商：对需求获取采集的信息进行汇总、分析，形成详细、规范的需求描述。
需要获取的成果最终必须以可见成果的形式描述出来
需求描述工具：
v 用例：一段用文字表述的故事，阐述用户如何使用软件来实现某个具体的业务目标。
相关工具：系统范围图/表
业务流程图（活动图）
用户目标表：用表格形式汇总展现系统所涉及的全部用例及其优先级(用例的目录)
用户情况表
数据流模型：用图形方式表示数据的输入、输出和加工过程。

Ø 需求规约：形成正式需求分析文档的过程
软件需求说明书（软件需求规约，SRS）是分析任务的最终产物，是用户和开发者双方对于软件产品要求的正式约定。
需求说明书模板：
Ø 第一章 目标与范围
ü 1a 项目的整体范围与目标是什么？
ü 1b 利益相关者（Who cares?）
ü 1c 项目范围内包括什么？什么不在项目范围内？
Ø 第二章 词汇表
Ø 第三章 用例
ü 3a 项目的主要参与者与他们的目标
ü 3b 概要级别用例（以主要参与者的视角来分别描述各个主要的业务流程）
ü 3c 用户目标级别用例（具体描述主要参与者如何使用系统来实现他们的目标）
ü 3d 用户目标表
Ø 第四章技术要求
Ø 第五章其他要求
Ø 第六章人工备份、法律、政治与组织问题

Ø 需求验证
Ø 需求管理：是一组用于帮助项目组在项目进展中的任何时候去标识、控制和跟踪需求的活动

² 目的：
v 保障需求说明书与产品的一致性
v 控制需求变更对项目开发的影响
v 使需求活动与计划保持一致
² 内容：变更控制
版本控制
需求跟踪
需求状态跟踪
² 需求变更：在软件需求基线已经确定之后又要添加新的需求或进行较大的需求变动。
需求变更管理：由专人统一负责接收、评估、审批和实施需求变更请求
需求变更管理的目的：确保需求变更的利大于弊
² 需求跟踪：在软件开发的全过程中，记录和维护每项需求与软件其他系统元素（如设计模块、程序代码、测试用例等等）之间的关系
作用：建立与维护“需求－其他需求-设计－编程－测试”之间的一致性
方式：正向跟踪、逆向跟踪、双向跟踪
目的：
v 确保所有的工作成果最终符合用户需求。
v 当需求发生变更时能够快速定位所有被影响的系统元素
需求跟踪矩阵（RTM）是表示需求和其他系统元素之间的联系链的一种常用工具

需求状态跟踪：在项目整个生命周期中对项目所处状态（即其在当前时刻的情况）进行追踪
·目的：确保用户提出的每一项需求都得到了妥善的处理
·工具：单独的需求状态跟踪表；也可合并到需求跟踪矩阵中

9.管理层级与信息系统
关注：用户使用场景和业务流程
关注：绩效指标体系和数据流

还要关注：岗位与权限、数据量
10.不能说的秘密：需求分析必须重视利益干系人

CH3 需求分析——场景分析与用例
本章重点：
v 用例的组成部份及其写法
v 各用例相关工具的作用
v 用例图的画法
v 活动图的画法
v 基于用例的场景分析

1.需求分析的两个最主要的视角：
Ø 业务（流程）视角
Ø 绩效（信息）视角
2.目前的主流是使用以用例为核心的一套方法和工具来描述企业业务
用例（Use Case）：一种通过描述用户的使用场景来获取需求的技术。
客观（第三者视角）描述使用场景
对业务场景中有明确目标的参与者之间的行为描述；
用例是利益相关方关于（待开发）系统行为的契约。
3.用例的组成
v 用例名称
Ø 动词、动词+宾语结构词组或简短的主谓宾结构短语
Ø 能够清晰的反映用例的功能或要实现的目标
v 参与者及其目标
参与者（Actor）是在用例中具有行为或职责的人事物。
参与者可能是人，也可能是某个组织（部门、企业），还可能是某个软硬件系统。待分析的系统（SuD）一般不会作为参与者。
Ø 主要参与者：SuD的主要服务目标或使用对象。使用SuD实现其目标。
Ø 协助参与者：为SuD提供服务的参与者
v 利益相关者及其关注点
间接受用例影响的组织或个人，我们称之为利益相关者。
SuD必须确保利益相关者的利益得到了切实的保护
v 范围与目标级别
范围界定了用例中要分析的系统
目标级别：描述用例中主要参与者的目标层级
Ø 概要：描述企业业务流程或用户流程的总体步骤，如采购流程、研发流程等（可能跨度很长；可能涉及多个非系统参与者）
Ø 用户目标：业务流程中的某一步，在这一步骤中，主要参与者使用待开发系统来实现一个具体的目标。如（超市）用户结账等。
Ø 子功能：对用户目标级别用例中的单个步骤的进一步描述，如（超市）用户刷卡付款等。
判断：
Ø （图书馆管理系统）读者登录
Ø （图书馆管理系统）读者借书
Ø （超市管理系统）用信用卡支付
Ø （超市管理系统）处理退货
Ø （超市管理系统）寻找供货商
Ø （ATM系统）使用ATM取现金
Ø (ATM系统）使用ATM修改密码
Ø (ATM系统）使用ATM办理业务

v 前置条件：在用例中的场景开始之前，必须保证为真的条件
用例中不要出现对前置条件进行检查的步骤
可以不写
触发条件：导致用例中的场景开始的事件。
基本保证：在用例执行后，系统对各利益相关者的利益的最小保证
² 无论用例最终执行是否成功，系统都必须确保基本保证中的承诺。
成功保证：承诺如果用例成功执行完毕，利益相关者的哪些利益将会得到满足（不重复基本保证中的内容）
v 主成功场景和步骤
v 扩展描述了用例中的其他所有场景或者场景分支片段
Ø 为什么扩展是需求中最容易出问题的部分？
n 扩展中主要是各种异常或错误情况的处理。
n 这往往是业务人员并不熟悉的。
n 不熟悉就会导致遗漏。
n 一个只能处理正常情况的系统显然不是一个完善的系统。
即使扩展中的异常情况系统最终不处理或无法处理，预先把它写出来，甲乙双方充分讨论，能够避免以后的扯皮
Ø 触发条件：对应于主成功场景中的某个步骤的特殊情况。在该步骤中，如果满足该触发条件，则改为执行扩展场景。（注意序号的对应，数字代表步骤，字母代表触发条件）
Ø 目标：消除异常或特殊情况，以继续执行主成功场景
Ø 场景结束：通常是重新并入主成功场景（缺省情况），或者是中止处理（即处理失败）
v 其他
链接、特殊需求（与用例直接相关的非功能性需求、质量属性或约束）、技术和数据变元表（用户对于系统实现的特殊技术要求）——因为用例中避免设计和实现细节、发生频率、优先级、未决问题
4用例相关工具
·项目愿景：用一两句话对项目目标做出的概括性描述。帮助项目团队成员建立起共同的项目目标
·设计范围图：以直观图形的方式描述系统范围。通常使用UML用例图。
·In/Out表：一个简单的工作主题列表，用于帮助讨论和确定系统范围。
·用户目标列表：汇总列出系统的主要使用者、目标及其优先级
·用户情况表：汇总列出系统所有使用者的背景、技能水平等情况。
用例应该让用户来写。

5.用例图：用于描绘用例、系统、参与者及其之间的关系（语境图）
主要参与者——系统（多个用例）——协助参与者
作用：
Ø 展示系统边界
Ø 展现关系

参与者泛化：参与者A泛化参与者B，表明参与者B参与的所有用例也被参与者A参与
6.活动图（本质是流程图）

基本组成元素：
活动：流程中的一个步骤。动作：基础的、逻辑上内部不能再细分的活动，是UML活动图中的最小
分支与合并
分叉与汇合：显示并行线程 都会发生、但发生次序任意（一个时间段内，同时进行的活动）
甬道 每个活动只能明确属于一个甬道 用垂直实线分隔 甬道本身没有顺序

7.活动图与用例
Ø 活动图不能替代用例，因为用例中还有利益相关者及其关注点等大量信息。
Ø 活动图能代替用例中的场景描述吗？
对于用户目标级别的用例而言：不能。因为目标级别用例存在大量扩展分支；过多分支会导致活动图难以理解
适合辅助表达概要级别的用例
8.基于用例的场景分析：自顶向下的过程
Ø 找出企业中需要信息化的业务过程。（有哪些业务&核心业务是啥）
Ø 将业务过程（Business Process）划分为规范的步骤，并加以描述（概要级别用例）——（用用例和活动图）
Ø 针对过程中的每个步骤编写对应的使用场景（用户目标级别用例）

CH4 需求分析——数据流分析
本章重点：
v 如何绘制DFD
v 什么是KPI

1.数据流图（DFD）：描绘软件系统逻辑模型的图形工具
2. DFD分层：按照系统的层次结构进行逐步分解
子图是对父图中某一加工步骤的详细展开；
每一层所包含的加工通常不超过7个；
各层数据流保持平衡：父图中某加工的输入输出数据流应该同其子图的输入输出相同(相对应）。
3.系统环境图（顶层数据流图）——0层DFD
仅包括一个数据处理过程，也就是要开发的目标系统
作用是确定系统边界
4.数据字典 若X,a,b都是数据项
Ø X= a + b x由a和b构成
Ø X= [a , b] x由a或b构成
Ø X= [a | b] x由a或b构成
Ø X= (a) a可在x中出现，也可能不出现
Ø X= {a} x由0次或多次重复的a构成
Ø X= m{a}n x由m至n个a组成，即至少有m个a,至多有n个a
Ø X= a..b x可以取a至b的任一值
Ø X= “a” x为取值a的基本数据元素，即a无需进一步定义
5.DFD绘制步骤
Ø 识别数据源、数据流和存储
Ø 建立系统环境图，确定系统边界
Ø 自顶向下，逐步求精，建立逐层建立系统的DFD
Ø 定义数据流、数据存储的内容和结构（数据字典）
Ø 给出加工的具体信息，如，如业务规则等
6.DFD的缺陷
完全聚焦于信息处理本身，对实际业务的描述不全面

7.关键绩效指标KPI
通过对组织业务流程的关键参数进行设置、取样、计算、分析，从而得到的用于衡量流程绩效的一套目标式量化管理指标
理论依据：20/80原则（帕累托原则）
KPI业绩考评体系是一整套覆盖各项职能和各个层级的关键业绩指标管理系统，是从分析和计划、汇报和指导、考核等三个方面实现管理规范化，提高业务水平
KPI是企业管理信息系统的数字仪表盘中仪表的来源。
KPI体系制定：
第一步：开发业务“价值树”；
第二步：确定影响大的“关键业绩指标”；
第三步：将“关键业绩指标”分配给有关经理；
第四步：确定 “关键业绩指标”的目标。
v 需求分析阶段，必须落实KPI与报表中每一项指标的：
Ø 计算方法
Ø 数据来源

OOP建模
本章重点
v 对象与类的关系
v 什么是封装;封装的意义
v 什么是继承;什么是多态
v 什么是覆盖, 什么是动态绑定
v 什么是接口

1.为什么要面向对象
从本质上说：软件开发过程是一个开发人员对开发项目不断深入学习、理解和认识，并将其用代码的形式固化的过程
认识复杂事物的两种主要方法：抽象（舍弃次要特征）和分治
2.面向对象
Ø 以对象而非数据作为问题表示和描述的基本单位
Ø 用日常认识世界的思维来指导软件开发
Ø 变解决问题为认识问题、用程序来反映的问题的认识
Ø 是抽象和分治方法的综合应用
Ø 本质上是以人为本，是软件工程的返朴归真！
3.对象：一组数据和操作的集合；现实概念、问题在程序中的反应；是对人类抽象思维基本单位——“概念实体”的直接模拟
概念实体具有：静态属性和动态特征
即把非生物对象当成能听懂我们命令的生物，将它能够实现的被动行为当作它的动态特征。
数据：属性；操作：方法
面向对象（Object Oriented）：使用对象作为基本单位来认识问题、设计开发程序
4.类：创建对象的模板。对象：类的实例
v 类与对象之间的关系是抽象与具体的关系：
Ø 对象是对所研究的某一个具体事物的逻辑简化。
Ø 而类是对同一类事物的抽象和归纳，相当于概念。
Ø 狗是一个类，我养的那只小狗就是一个对象。
v 类创建对象的模板，类定义决定了该类型对象所具备的属性和行为。
Ø 只有先定义类，才能去定义该类对象。
v 变量中保存的是对象，变量的类型是类。
实例——对象——产品
概念——类——模具

5.面向对象的三个主要特性：封装、多态、继承
6.封装：
v 把数据和及其对应的操作（方法）用对象和类的形式组织起来，使之形成一个有机的整体
v 将数据处理的细节隐藏在对象内部，外部无法干扰
封装的目的：
v 隐藏对象的使用者不必关心的细节
v 避免使用者无意中破坏对象的属性或方法的正常工作
Java中实现封装：
v 构造函数
作用：保证新产生的对象实例的属性一定是合理的（可用的）

v 访问限定符
作用：保证外界无法随意修改对象的特定属性或执行对象的特定方法
7.继承
类和类之间的从属关系 is - a
Dog继承Animal，意味着Dog自动具有了Animal所有的属性和方法
继承是OOP中实现代码复用的重要途径
8.多态：可以把子类的对象实例当成父类的对象实例
(由于继承)一个对象变量可以引用多种实际类型；由此，同一段代码，可以用于多种不同的对象。这种现象就是所谓的多态
9.覆盖：override
子类可以重新实现父类定义的方法（覆盖的作用是让子类可以选择性的去继承父类已经实现的功能）
重载：overload （同一个类中的）多个方法可以使用同一个名字（解决做同一件事，可能需要不同参数的情况）
Ø 重载和多态、OOP没有关系！

10.动态绑定：一段方法代码的具体行为是在程序运行时，才由传递给它的实参到底是什么类型决定的
public class Test {
public static void main(String[] args) {
Animal ani=new Dog("旺财");
ani.run();
ani.cry();
}
}
11.抽象类：在父类中的某些方法（抽象方法）只是起到一个定义契约的作用，没有具体实现。 Abstract关键字 Shape s=new Circle();
public abstract class Shape {
public abstract double getArea();
public abstract void draw();
}
抽象类中也可以包含具体的方法。
接口与抽象类的区别：
Ø 接口的所有方法都是抽象的public方法，而抽象类既可以有抽象方法，也可以有非抽象方法、即可以有public方法，也可以有private、protected方法
Ø 抽象类依然是类，因此受到Java语言中一个类只能有一个父类的限制；而一个类可以同时实现零到多个接口
接口就相当于一个纯粹的契约
实现一个接口，就是实现接口中声明的所有方法
通常我们用继承关系表示类在概念上的包含与从属关系（is-a关系）
用接口实现关系，表示类具有的某种特性（has-a关系）

CH5 需求分析——领域建模
本章重点：
v 领域建模方法
v 系统顺序图的绘制方法

1.领域模型（domain model）：用图形可视化的方式表示的领域内的实体概念及其相互关系
领域模型展现了：领域中的对象类或概念、概念之间的关系、概念的重要属性
2.概念类一定对应于现实中的某个具体的概念或者事物
出现在领域模型中的类都是概念类
3.领域模型本质上是关于特定领域的一个可视化的词汇列表,但不能完全取代词汇表
4.领域模型中的类没有职责（方法）；领域模型不包括软件制品，如数据库、网页
领域模型不是数据模型：
Ø 不需要考虑概念类的相关信息是否需要持久保存
Ø 不需要考虑概念类到底都有哪些属性

5.领域建模基本步骤：
Ø 寻找概念类：重用已有模型；使用分类列表；语言分析（与分类列表一起使用）
概念类中有一类是对事物的描述，即描述类，避免：数据冗余；信息丢失
概念类分析准则：
² 准则1:不要把概念类误认为属性
如果我们认为某事物X不是现实世界中的数字或文字，那么X可能是概念类而不是属性
² 准则2：报表对象——模型中是否要包括“票据”
² 准则3：像地图绘制者一样思考——使用领域术语
Ø 将其绘制到模型中
使用简化的UML类图
Ø 添加关联和属性
6.关联分析：
关联（assosiation）：类的实例，即对象之间的关系，表示有意义和值得关注的连接。关联不一定是永久性的
关注那些现实业务需要关注和记录的关联
注意点：避免加入大量关联；模型中的关联不一定会在软件中实现
² 关联的表示：
关联表示为类之间的连线，并冠以首字母大写的关联名称。末端包含多重性表达式；本质是双向的
关联命名准则：格式为“类名—动词短语—类名”；动词短语应是可读的、有意义的
多重性：定义了类A有多少个实例可以和类B的一个实例关联
多重性的数值表示在特定时间点上有效关联的实例数量
多重性的数值还与建模者的关注角度有关
多重关联
7.属性分析：
属性：表示对象某一方面性质的逻辑数据值
属性分析的目的：在领域模型中进一步确定概念类的属性，可以更好的展现当前所开发场景的信息需求。
导出属性：有些属性可以从其他属性，或关联类的信息中推导出来（冗余，一般不应该在领域模型中出现。）
一般来说属性的类型不应该是复杂的领域概念（即其他概念类）
8.系统顺序图：使用简化的UML顺序图来描述外部参与者与SuD之间的输入和输出事件。
使用系统顺序图(System Sequence Diagram, SSD）来阐述系统的动态特性
时间顺序、自上而下描述外部参与者和系统之间的交互

CH6 架构设计
本章重点：
v 什么是系统架构
v 什么是性能，如何衡量？什么是可用性？
v 在架构中，什么是封装？什么是耦合？什么是解耦？什么是分层
v 典型的软件架构：C/S架构，B/S架构，三层C/S架构各自的优缺点。选择合适的软件架构
v 逻辑三层结构
v 什么是ＡＡＡ。如