导图社区 软件工程导论
- 515
- 33
- 7
- 举报
软件工程导论
软件工程导论思维导图：面向过程方法学（软件不是程序，而是程序，数据以及开发，使用，维护程序所需文档的完整集合。）等等
编辑于2022-03-31 07:18:28- 软件工程
- 相似推荐
- 大纲
软件工程导论
面向过程方法学
软件
定义
软件不是程序，而是程序，数据以及开发，使用，维护程序所需文档的完整集合。
计算机程序，方法，规则，相关的文档资料以及在计算机上运行程序时所必需的数据。
特点
软件是一种逻辑产品，而不是具体的物理实体，具有抽象性。
软件产品的生产主要是开发研制，没有明显的制造过程。
软件产品在使用过程中，不存在磨损，消耗，老化等问题。
软件产品的开发主要是脑力劳动，还未完全摆脱手工开发方式，生产效率低。
软件产品的成本相当昂贵，软件的研制需要投入大量的人力，物力和资金，生产过程还需要对产品进行质量控制，对每件产品进行严格的检验。
软件对硬件和环境有不同程度的依赖性，为了减少这种依赖性，在软件开发中提出了软件的可移植性问题。
软件是复杂的，软件是人类有史以来生产的复杂度最高的工业产品，软件是一个庞大的逻辑系统。软件开发常常涉及到其它领域的专业知识，这对软件开发人员提出了很高的要求。
分类
计算机系统角度
系统软件和应用软件
计算机软件用途
服务类，维护类和操作管理类
软件危机
在计算机软件开发和维护过程中所遇到的一系列严重问题。
软件工程
指导计算机软件开发和维护的一门学科，采用工程的概念，原理，技术和方法来开发和维护软件。
内容
软件开发技术和过程管理两方面
软件过程
为了获得高质量所需要完成的一系列任务的框架，它规定了完成多项任务的工作步骤。
目标
降低软件开发成本
满足用户要求的全部软件功能
符合用户要求，令用户满意的软件性能
具有良好的易用性，可用性以及可移植性
较低的维护成本和较高的可靠性
按照合同要求完成开发任务，及时交付用户使用
软件开发模型
瀑布模型
应用最广泛的过程模型
定义
也称生存周期模型或线性顺序模型
将软件生存周期各个活动规定为依线性顺序连接的若干阶段的模型
特点
阶段的顺序性和依赖性
推迟实现的观点：充分准备后才编码实现，逻辑设计与物理设计分开。
质量保证的观点
以文档为驱动，适合于需求很明确的软件项目开发的模型
缺点
理想的线性开发模型，缺乏灵活性，无法解决软件需求不明确或不准确的问题。
快速原型模型
快速建立一个能够反映用户需求的原型系统
增量模型
也称渐增加模型，软件在模型中是逐渐开发出来的，把软件产品作为一系列的增量构件来设计，编码，组装和测试。开发出一部分，向用户展示一部分。
灵活，允许软件变化
螺旋模型
加入了风险分析
喷泉模型
典型的面向对象软件开发模型
软件生存周期
定义
指某一软件项目被提出并着手实现开始，直到该软件报废或停止使用为止所经历的时间。
周期
软件计划
问题定义
可行性研究
目的
用最小的代价在尽可能短的时间内确定问题是否存在可行的解法。
任务
首先进行概要的分析研究，初步确定项目的规模和目标，确定项目的约束和限制，必须分析几种可能解法的利弊，从而判定原定系统的目标和规模是否现实，系统完成后带来的效益是否大到值得投资开发这个系统的程度。
从经济，技术，操作和法律四个方面来研究每种解法的可行性。
步骤
复查并确定系统规模和目标
研究目前正在使用的系统
建立新系统的高层逻辑模型
导出和评价各种方案
推荐可行性方案
草拟初步开发计划
编写可行性研究报告提交审查
系统流程图
描述物理系统的工具
作用：用图形符号以黑盒子形式表示组成系统的主要部分
符号表示
应用
软件开发
需求分析
需求分析的任务仅仅是确定系统必须完成哪些工作，也就是对目标系统提出完整，准确，清晰而且具体的需求。需求分析实际上是一个对用户意图不断进行揭示和判断的过程，它并不考虑系统的具体实现，而是完整的，严密的描述应当”做什么“的一种过程。
具体任务
确定对系统的综合需求
分析员和用户双方确定对软件系统的综合要求，具体有功能需求，性能需求，环境需求，接口需求，用户界面需求，另外还有可靠性，安全性，保密性，约束，可移植性和可维护性等方面的需求，这些需求通常可以通过双方交流，调查研究来获取，并达到共同的理解。
分析系统的数据需求
因为绝大多数软件系统的本质都是信息处理系统，系统必须处理的信息和系统应该产生的信息在很大程度上决定了系统的面貌。
建立软件的逻辑模型
编写软件规格需求说明书（SRS）
目的是使用户和开发者能对未来软件有共同的理解，明确定义未来软件的需求，系统的构成及有关的接口。需求说明相当于用户和开发者之间的一份技术合同，是测试验收阶段对软件进行确认和验收的基准，是软件开发的基础。
需求分析评审
步骤
需求获取
调查研究
从分析当前系统包含的数据开始，分析当前信息处理的方法与存储的不足，用户希望改进的主要问题及其迫切性等。
需求提炼
分析建模
主要任务是建立分析模型。把来自用户的信息加以分析，通过抽象建立起目标系统的分析模型。
需求描述
编写SRS
为了使需求描述具有统一的风格，可以采用已有的且满足项目需要的模板，也可以根据项目特点和软件开发小组的特点，对标准进行适当的改动，形成自己SRS模板。
需求验证
由分析员和用户一起对需求分析结果进行严格的审查，验证。确保需求说明可以作为软件设计和最终系统验收的依据。
常用方法
功能分解方法
”自顶向下，逐步求精“
结构化分析方法（SA）
是一种从问题空间到某种表示的映射方法，软件功能由数据流图表示，是结构化方法中重要的，被普遍采用的方法，它由数据流图和数据字典构成系统的逻辑模型。
自顶向下，逐层分解的分析策略
化整为零，各个击破
描述方法
非形式化（文字描述）
半形式化（图形）
数据流图（DFD）
元素
箭头：表示数据流
圆或椭圆：表示加工（处理数据）
方框：数据的源点或终点
外部实体
双杠或单杠：表示数据存储（文件）
基本原则
数据流图中所有的符号必须是前面所述的四种基本符号和附加符号。
数据流图的主图（顶层）必须含有前面所述的四种符号，缺一不可。
数据流图主图上数据流必须封闭在外部实体之间。（外部实体可以是一个，也可以是多个）
加工（变换数据处理）至少有一个输入数据流和一个输出数据流，反映出此加工数据的来源与加工结果。
父子平衡
图上每个元素都必须有名字（流向数据存储或从数据存储流出的数据流除外）。
数据字典（DD）
数据流
数据流分量
数据存储（文件）
加工（处理）
加工逻辑
也称"小说明"，对数据流图中每个加工所作的说明。
结构化语言
自然语言+结构化形式
只有顺序，循环，条件三种控制结构
选择结构
判定表
判定树
清晰的表示复杂的条件组合
形式化（数学类）
信息建模方法
面向对象方法
需求分析图形工具
层次方框图
由一系列多层次的树形结构和矩形框组成，用来描述数据的层次结构。
Warnier图（维纳图）
P1,P2,P3代表若干
IPO图（输入-处理-输出图）
数据库内容需求分析
信息需求
最基本
主要是确定系统需要存储和使用哪些数据，用户需要从数据库中获得信息的内容和性质
处理需求
用户要求软件系统完成的功能，以及对系统功能的处理时间，方式等方面的要求，Eg : 要求批处理还是联机处理。
使用需求
包括：使用数据库时的安全性，完整性和一致性等方面的限制；查询方式，输入、输出格式和多用户等方面的要求；响应速度，故障恢复等性能要求。
实体-联系（E-R）图
描述系统中数据的逻辑模型
建立全局E-R模型时，各局部E-R模型之间可能出现的冲突
属性冲突
命名冲突
结构冲突
元素
实体：用矩形框
属性：用椭圆框
联系：用菱形框
1 ：1 1对1
1 ：n 一对多
m：n 多对多
软件设计
概念和原理
模块
定义
软件结构的基础，是软件元素，是能够单独命名，独立完成一定功能的程序语句的集合。
模块的独立性是一个好的软件设计的关键
耦合
衡量不同模块彼此间相互依赖的紧密程度。低耦合，即每个模块和其他模块之间的关系要简单。
内聚
衡量一个模块内部各个元素间彼此结合的紧密程度的度量。高内聚，每个模块完成一个相对独立的特定子功能。
无直接耦合
两个模块分别从属于不同模块的控制与调用，他们之间不传递任何信息，没有直接的联系，相互独立。软件系统中所有模块之间不可能没有任何联系。
数据耦合
两个模块之间的调用关系，相互传递的信息以参数的形式给出，而传递的信息仅仅是简单的数据。
标记耦合
两个模块之间传递的是数据结构，而且被调用模块不需要作为参数传递过来的整个数据结构，只需要使用数据结构其中部分数据元素。
控制耦合
当一个模块调用另一个模块时，传递的信息控制了该模块的功能。
公共环境耦合
两个或多个模块共用一个数据环境。
内容耦合
一个模块直接访问另一个模块的内部数据；一个模块不通过正常入口而转入另一个模块内部；一个模块有多个入口，都属于内容耦合。内容耦合属于最高程度的耦合，也是最差的耦合，应避免使用。
模块化
指解决一个复杂问题自顶向下逐层把软件系统划分成若干模块的过程，模块化可以降低软件复杂度。
作用
采用模块化原理可以使软件结构清晰
模块化使软件容易测试和调试，因而有助于提高软件的可靠性
模块化能够提高软件的可修改性
模块化也有助于软件开发工程的组织管理
总体设计
目标和任务
总体设计阶段的基本目标是回答“系统应该如何实现？”这个问题，因此，总体设计又称概要设计或初步设计。总体设计的另一项任务是设计软件的总体结构，及确定系统中每个程序是由哪些模块组成的，每个模块的功能及模块和模块之间的接口，调用关系等。
软件结构设计
以模块为基础，以数据流图为依据
任务
软件体系结构设计
体系结构是对复杂事物的一种抽象。良好的体系结构是普通适用的，它能够描述各种风格的软件系统结构，可以高效的处理多种多样的个体需求。
体系结构在一定时间内保持稳定，确保接口一致，既能确保某一体系结构配置描述内相关接口描述的一致，又能确保建立关联的两个构件接口描述的一致性。
良好的体系结构意味着普通，高效和稳定。
软件模块设计
降低模块之间的耦合性，提高模块的内聚性
模块结构的深度，宽度，扇出和扇入应适当
扇出数一般是3-4，不能超过5-9
模块的作用范围应该在控制范围内
模块接口设计要简单，以便降低复杂程度和冗余度
设计功能可预测并能得到验证的模块
适当划分模块规模，以保持其独立性
图形工具
软件结构图（SC）
软件系统的模块层次结构，用来表达软件的组成模块及调用关系
主要内容
模块：用方框表示，方框中写模块的名字
模块的调用关系：两个模块之间用单向箭头或直线连接起来表示它们的调用关系
箭头：表示模块之间传递的信息
辅助符号
弧形箭头：表示循环调用
菱形：表示选择或条件调用
层次图
HIPO图
结构化设计方法
把数据流图映射为软件结构图，信息流的类型决定了映射的方法。
数据流图
变换型
呈线性形状结构，由输入，变换，输出三部分组成，变换是系统的变换中心。
转换为软件结构图
事务型
当一个数据项到达某个模块时，将有多个动作之一
转换为软件结构图
详细设计
详细设计是对总体设计的细节进行完善，给出软件结构中每个模块的内部特征（数据结构，算法和接口）的描述。
目的与任务
根本目的是确定应该怎样具体实现所要求的系统，应该得出对目标系统的精确描述。具体就是为软件结构图中每个模块确定采用的算法和块内数据结构，用某种选定的详细设计工具更清晰的描述，从而在编码阶段可以把这些描述直接翻译成某种程序设计语言书写的源程序。
结构化程序设计
详细设计的逻辑基础
特征
一个入口
一个出口
程序中无死语句
程序中无死循环
结构：顺序，循环，选择
图形工具
程序流程图
附加符号
优点
表达直观，结构清晰，易于理解，易于修改
缺点
本质上不是逐步求精的好工具，它诱使程序员过早考虑控制流程，而不去考虑程序的整体结构
用箭头代表控制流，因此程序员不受任何如约束，可以完全不顾程序设计的精神，随意转移控制，容易造成非结构化的程序结构
不易表示数据结构和层次结构
盒图（N-S图）
优点
强制设计人员按SP方法进行思考并描述他的设计方案，有效的保证了设计的质量，从而也保证了程序的质量。
N-S图形象直观，功能域明确，结构层次清晰。为编程，复查，选择测试用例，维护都带来方便。
N-S图简单，易学易用，可用于软件教育和其他方面。
缺点
随着程序内嵌套的层数增多，内层方框越来越小，不仅会增加画图的难度，还会影响图形的清晰度且不易手工修改。
问题分析图（PAD图）
（Problem analysis diagram）自左向右
优点
使用PAD符号设计的程序必然是结构化的程序。
PAD图所描绘的程序结构十分清晰，PAD图中竖线的总条数就是程序的层次数。
用PAD图表现程序逻辑，易读，易记，易懂。
容易将PAD图转换成高级语言源程序，可用软件工具实现自动转换。
既可以表示程序逻辑，也可以描绘数据结构。
支持自顶向下，逐步求精方法的使用。
过程设计语言（PDL）
也称伪码，PDL是一种用于描述功能模块的算法设计和加工细节的语言。
优点
可以作为注释直接插在源程序中间。这样做能促使维护人员在修改程序代码的同时也相应的修改PDL注释，因此有助于保持文档和程序的一致性，提高文档的质量。
可以使用普通的正文编辑程序或文字处理系统，很方便的完成PDL的书写和编辑工作。
同自然语言（英语）很接近，易于理解。
由于是语言形式，所以易于被计算机处理。
由于同程序是同结构的，较容易从中自动产生程序。
缺点
不如图形工具形象直观
描述复杂的条件组合与动作间的对应关系时，不如判定表清晰简单
人机界面设计
设计风格
系统响应时间
系统响应时间过长或过短，用户都会受到负面影响
用户帮助设施
现代交互式系统的每个用户都需要帮助
出错信息处理
出错信息设计的不好，将向用户提供无用的甚至误导的信息，反而会加重用户的挫折感。
命令交互
设计原则
界面简洁，控件摆放规范，颜色统一，符合用户习惯
“黄金”指导准则
让用户驾驭软件，而不是软件驾驭用户
尽可能减少用户的记忆负担
保持界面的一致性
设计过程
建立任务的目标和意图
建立界面需求规格模型
以界面需求为依据创建用户界面模型
用户使用并评估该界面模型
设计者根据用户的意见修改设计并实现下一模型
不断进行下去，直到用户感到满意为止
软件编码
程序设计语言的分类
软件工程角度
基础语言
是通用语言，特点是适用性强，应用面广，历史悠久。
FORTRAN，COBOL，BASIC，ALGOL
结构化语言
Pascal，C，Ada
面向对象语言
JAVA，C++
按“代”
1GL
面向机器的语言，代表是机器语言和汇编语言
2GL
代表：FORTRAN，COBOL，BASIC，ALGOL
3GL
也称现代编程语言，代表：Pascal，C，Ada，C++，Smalltalk
4GL
代表：VB，VC，JAVA
选择
理想标准
为了使程序容易测试和维护以减少软件的总成本，所选用的高级语言应该有理想的模块化机制，以及可读性好的控制结构和数据结构。
为了便于调试和提高软件可靠性，语言特点应该使编译程序能尽可能的发现程序中的错误。
为了降低软件开发和维护成本，选用的高级语言应该有良好的独立编译机制。
实用标准
待开发软件的应用领域
用户的要求
软件的运行环境
软件开发人员的知识
软件的可移植性要求
设计风格
源程序代码的逻辑简明，易读易懂是好程序的一个重要标准。
分类
源程序文档化
程序内部文档包括标识符的选取，增加注解和好的程序布局。
数据说明
数据说明应遵循一些简单的原则
数据说明的次序应该标准化
当一个说明语句说明多个变量时，最好按字典顺序排列
如果设计时使用了一个复杂的数据结构，则应加注释说明用程序设计语言实现这个数据结构的方法和特点
语句构造
不要为了节省存储空间，把多个语句写在同一行
尽量避免复杂的条件测试，尤其是减少对“非”条件的测试
避免大量使用循环嵌套语句和条件嵌套语句
利用圆括号使逻辑表达式或算术表达式的运算次序清晰直观
变量说明不要遗漏，变量的类型，长度，存储以及初始化要正确
心里换位：“如果我不是编码人，我能看懂它吗？”
输入输出
对所有输入数据都要进行校验
检查输入项重要组合的合法性
保持简单的输入格式
输入一批数据时，使用数据或文件结束标志，不要用计数来控制
人机交互式输入时，要详细说明可用的选择范围和边界值
当程序设计语言对输入、输出格式有严格要求时，应保持输入格式与输入语句的要求一致
输出报表的设计要符合用户要求，输出数据尽量表格化，图形化。
给所有的输出数据加标志，并加以必要的注释
追求效率
效率主要指处理机工作时间和内存容量这两方面的利用率。
原则
效率是属于性能的要求，因此应该在软件需求分析阶段确定效率方面的要求。
良好的设计可以提高效率。
提高程序的效率和好的编码风格要保持一致，不应该一味追求程序的效率而牺牲程序的清晰性和可读性。
代码效率，存贮效率和输入输出效率。
软件测试
目标
为了发现程序中的错误而执行的程序的过程
好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案
成功的测试是发现了至今为止尚未发现的错误的测试
基本任务
根据软件开发各阶段的文档资料和程序内部结构，精心设计一组“高产”的测试用例，利用这些用例执行程序，找出软件中潜在的各种错误缺陷。测试一般不可能发现程序中的所有错误；测试只能证明程序中存在错误，但不能证明程序中不存在错误。
原则
测试用例既要有输入数据，又要有对应的输出结果，这样便于对照检查。
测试用例不仅要选用合理的输入数据，还应选择不合理的输入数据。这样能更多的发现错误，提高程序的可靠性，还可以测试出程序的排错能力。
除了检查程序是否做了它应该做的工作，还应该检查程序是否做了它不应该做的工作。
应该远在测试开始之前就制定测试计划。
测试计划，测试用例，测试报告必须作为文档长期保存。
Pareto原理说明，测试发现的错误80%很有可能是由程序中20%的模块造成的，及错误出现的“群集性”现象。
为达到最佳的测试效果，程序员应该避免测试自己的程序。
方法和分类
静态测试
包括人工测试和计算机辅助静态分析
动态测试
黑盒测试
也称功能测试或数据驱动测试。它不考虑程序内部结构和处理过程，把被测程序看成一个黑盒子，只在软件接口处进行测试，依据需求规格说明书，检查程序是否满足功能需求。
黑盒技术
等价类划分法
如果规定了输入数据必须遵循的原则，可确定一个有效等价类(符合规则)和若干个无效等价类(从不同角度违反规则)。
边界值分析法
错误推测法
因果图法
白盒测试
也称结构测试或逻辑驱动测试。测试人员需了解程序的内部结构和处理过程，以检查处理过程的细节为基础，要求对程序的结构特性做到一定程度的覆盖，对程序中的所有逻辑路径进行测试，并检验内部控制结构是否有错，确定实际的运行状态与与其是否一致。
白盒技术
逻辑覆盖
语句覆盖
语句至少执行一次（最弱）
判定覆盖（辅）
语句至少执行一次，判定的真假至少执行一次
条件覆盖（主）
语句至少执行一次，判定表达式中条件的各种结果要至少执行一次。
判定条件覆盖
既满足判定覆盖又满足条件覆盖
条件组合覆盖
条件的全部排列组合至少执行一次
路径覆盖
所有路径至少执行一次
循环覆盖
基本路径测试
在程序控制流程图的基础上，通过分析控制结构的环路复杂性，导出基本可执行路径集合，从而设计测试用例。设计出的测试用例保证这些路径至少通过一次。
步骤
一条边必须终止于一个结点
程序流程图 à 程序图
计算环形复杂度
V(G)=E(边的个数)-N(结点的个数)+2
V(G)=P(判定结点的个数)+1
结点：有两个分支的 判定结点有n个分支(n>2),看作n-1个判定
V(G)=区域数
软件测试过程
阶段
单元测试
发现的是编码和详细设计中的错误
对软件基本组成单元进行测试。检查每个独立的模块是否正确地实现了规定的功能。
任务
模块接口测试
模块局部数据结构测试
模块出错处理通路测试
模块中重要的执行路径测试
模块边界条件测试
集成测试
发现的是软件设计中的错误
原则
尽早测试关键模块
将已分别通过测试的单元按设计要求组合起来再进行测试，以检查这些单元之间的接口是否存在问题，同时检查与设计相关的软件体系结构的有关问题。
包括子系统测试和系统测试两个过程
测试技术
非渐增式测试技术
渐增式测试技术
自顶向下集成
深度优先策略
宽度优先策略
自底向上集成
确认测试
发现的是需求分析阶段的错误
检查所开发的软件是否满足需求规格说明书中所确定的功能和性能的需求。Eg : 对用户需求的误解，有冲突的用户需求等。完成确认测试后，得到的应该是用户确认的合格的软件产品。
系统测试
保证各组成部分不仅单独的正常运行，而且在系统的各部分统一协调下也能正常运行。
信息
软件配置：指需求说明书，设计说明书和源程序等。
测试配置：指测试方案，测试用例和测试驱动程序等。
测试工具：指计算机辅助测试的有关工具。
调试
为了解决存在的错误，即对错误定位，分析并找出原因改正错误。
软件运行
维护
时间最长
定义
特点
如果维护不当，会产生一些意想不到的副作用，甚至引起新的错误。
实际上是修改和简化了的软件开发活动
长期以来，未受到软件设计者们的足够重视
分类
改正性维护
适应性维护
完善性维护
预防性维护
软件的可维护性
指纠正软件系统出现的错误和缺陷，以及为满足新的要求进行修改，扩充或压缩的容易程度。
再工程
是一类软件工程活动，能够使人们增进对软件的理解；准备或直接提高软件的可维护性，复用性或演化性。
逆向工程
是分析程序，力图在比源代码更高的抽象层次上建立程序表示的过程。
面向对象方法学
出发点和基本原则
尽可能模拟人类习惯的思维方式，使开发软件的方法和过程尽可能接近人类解决问题的方法与过程。
优点
与人类习惯的思维方式一致
软件稳定性好
可重用性好
较易
可维护性好，易于测试开发大型软件产品
缺点
相对面向过程而言比较麻烦，需要写更多的代码
占用空间比较多，程序效率比较低，如多态等特性会降低性能
创建对象实例的过程往往是非常耗时的工作
对系统动态特征表述不充分（主要是整体动态特征），且反应系统整体功能特征的能力较差。
面向对象方法学4大特征（抽象，封装，继承和多态），有效的阻止错误的扩散，减轻了维护工作量，但是也加大了测试的难度，给软件测试带来不便。
从软件工程过程的角度讲，包括管理，过程和技术
概念
OO
=Object+Classes+Inheritance+Communication with messages
面向对象包括既使用对象，又使用类和继承等机制，而且对象之间仅能通过消息传递消息实现彼此通信。
对象
对问题域中客观存在的事物的抽象，是一组属性和在这些属性上的操作的封装体。
现实世界中的实体
包括两大要素：属性（用来描述对象的静态特征）和操作(用来描述对象的动态特征)
类
具有相同属性和操作的一组相似对象（实体）的集合，类为属于该类的全部对象提供了统一的抽象描述。
同类对象具有相同的属性和方法
属性：类中所定义的数据
方法：对象所能执行的操作
消息
面向对象系统中对象之间交互的途径，是向另外一个对象发出的服务请求，请求对象参与某一处理或回答某一要求的信息，是对象之间建立的一种通信机制。
封装
把对象的属性和操作结合成一个独立的系统单位，并尽可能隐藏对象的内部细节，又称信息隐藏。
作用
使对象形成接口和实现两个部分
封装的信息隐藏将所声明的功能（行为）与内部实现（细节）分离
封装可以保护对象，避免用户误用
关系
类与类
继承
子类自动地共享父类中定义的数据和方法的机制
相反，从子类抽取共同通用的特征形成父类的过程叫做泛化。
多态性
指子类对象可以像父类对象那样使用，他们可以共享一个操作名，却有不同的实现方法。换句话说，指在父类中定义的属性或操作被子类继承后可以具有不同的数据类型或表现出不同的行为。
比如吃饭，英国人，中国人，印度人方式各不相同
形式
编译时的多态性
运行时的多态性
关联
模拟元素间的一种语义联系，它是对具有共同的结构特性，行为特性，关系和语义的连接的描述，相互关联的两个对象间的连接是关联的一个实例。
依赖
一个类A使用到了另一个类B，而这种使用关系具有偶然性，临时性，非常弱，但类B的变化会影响到类A。
实现
用来规定接口和实现接口的类之间的关系，接口是操作的集合，而这些操作就用于规定类或者构件的一种服务。
聚集和组合
组合：整体拥有各部分，部分与整体具有同样的生存期，如整体不存在了，部分也会随之消失。组合是一种特殊形式的强类型的聚集。Eg：需求描述中的“包含”,“组成”,“分成......部分”等。
大雁和翅膀
聚集：部分与整体不是相同的生存期，如整体不存在了，部分还存在。Eg：......是......的一部分
大雁和雁群
类和对象
类给出了属于该类的全部对象的抽象定义，而对象则是符合这种定义的一个实体。
对象又称是类的一个 "实例"，类又称为是对象的 "模板"。
类代表一类抽象的概念或事物，对象是在客观世界实际存在的类的实例。
画图
统一建模语言UML
一种标准的可视化（即图形化）建模语言
组成
元模型
给出图的定义，是UML的语义
图
是UML的语法
UML的语义
元元模型层
元模型层
模型层
用户模型层
UML的表示方法
视图
图
模型元素
公共机制
UML的主要特点
统一的标准
面向对象
可视化，表示能力强大
独立于过程
易于掌握应用
模型视图
用来描述系统的结构以及静态特征结构以及动态特征结构
静态图
类图，对象图，用例图，构件图，部署图，包图，组合结构图
动态图
状态图，顺序图，通信图，活动图，计时图，交互概览图
视图
用例视图，逻辑视图，进程视图，实现视图，部署视图
面向对象的分析过程（建模类型）
用例模型
由用例和场景表示的用例（功能）模型
从用户需求的角度来描述系统，指明系统应该“做什么”，直接反映用户对目标系统的需求，描述数据在系统中的变换过程及系统的功能。
建立用例模型
用例是从用户的角度出发来描述系统的功能，用例图用于展示系统将提供什么样的功能，以及用户将如何与系统交互来使用这些功能。
步骤
确定系统范围和系统边界
确定参与者
参与者为外部实体
确定用例
一个用例描述系统的一项功能
确定用例之间的关系
包含(include)
用例A在其内部说明的某一位置上显示地使用用例B行为的结果，叫做用例A包含用例B.
扩展(extend)
泛化
使用(use)
对象模型
用类和对象表示的对象（静态）模型
对模拟世界的对象及彼此之间的关系静态结构的描述，为建立动态模型和用例模型提供了实质性的框架。
动态模型
由状态机图和交互图表示的动态行为模型
物理实现模型
由构件图和部署图表示的物理实现模型
从实现子系统和实现元素的角度来表现系统实现的物理组成。
4种模型的关系
对象模型是必须建立的，是核心模型之一，为其他3种模型奠定了基础
用例模型指明系统应该“做什么”，一般选择用例图或数据流图来描述，用例模型从用户角度描述系统功能，是整个后续工作的基础，也是测试和验收的依据。
动态模型明确规定什么时候做什么事情，当问题涉及交互作用和时序时，动态模型尤为重要。
物理实现模型通过构件图和部署图描述系统实现和分析设计中的对应关系
软件项目工程
软件工程进度计划
Gantt图
缺点
不能显示每次安排作业彼此间依赖关系
进度计划关键部分不明确，难以分辨主攻和主控的对象
计划中有潜力的部分和潜力大小不明确
工程网络（PERT图）
工程网络中用箭头表示作业
用圆圈表示事件（一项作业的开始和结束）
对于作业a，A为它的开始事件，B为它的结束事件，事件仅仅代表作业开始或结束的时间点（时刻），作业代表消耗时间。
事件的最早时刻EET
指的是该事件可以发生的最早时间，通常工程网络第一个事件的最早时刻定义为0，其他事件的最早时刻从左向右按事件发生顺序计算。
计算规则
考虑进入该事件的所有作业
计算每个作业的持续时间和它的起始事件EET之和
选出计算出来的最大值作为该事件的EET
事件的最迟时刻LET
指的是在不影响工程竣工时间的前提下，该事件的最晚可以发生的时刻
注：最后一个事件（工程结束）的最迟时刻=其最早时刻
其他事件的最迟时刻在工程网络上从右向左按逆作业流的方向计算
计算规则
考虑离开该事件的所有作业
从每个作业的结束事件的LET中减去该作业的持续时间
选取上述差数中的最小值作为该事件的最迟时刻LET
关键事件
最早时刻和最迟时刻相同的事件
关键路径
由关键事件组成的路径
用粗线箭头表示
全部关键作业持续时间之和＝工程的最短时间
方法
找出起点到终点所有路径
求作业持续时间之和
选最大的即为最短时间
关键作业的实际持续时间不能超过估计的持续时间
机动时间
不在关键路径上的作业有一定的机动余地，即：实际开始时间可以比预定时间晚一些，或持续时间长一些。
作业机动时间＝（LET）结束－（EET）开始－持续时间
不影响工程的结束时间
关键路径上作业机动时间一定为０