软件工程PPT 笔记摘录（2）
分析软件需求
UML 提供了用例图来分析和描述用例视角的软件需求模型
UML 提供了交互图和状态图来描述行为视角的软件需求模型
UML 提供了类图来描述和分析业务领域的概念模型
顺序图：强调消息传递的时间序
通信图：突出对象间的合作
类图，描述系统的类构成，刻画系统的静态组成结构
用单数名词来描述类名，少用缩写
对象图是一种静态瞬时快照，归于静态视图范畴
一般而言，控制类并不负责处理具体的任务细节，而是负责分解任务，并通过消息传递，将任务分派给其他对象类来完成，协调这些对象之间的信息交互
如果系列规模较大，分析类的数量多，关系复杂，难以用一张类图来完整和清晰地表示，那么可以分多个子系统来绘制分析类图
评审软件需求：内容的完整性，正确性，准确性，一致性，多余性，可追踪性，文档规范性，表述可读性，图表一致性（我想知道简答题到底是怎么考察，考这些知识确实是写不出来）
软件设计基础
功利一点，现在是期末考试复习，考试会挖什么空，接下来的内容尽量选这方面的
类的地位：类既是最基本的设计单元，也是最基本的模块单元（有点像初中政治，就怕是无用功）
软件设计的基本原则之一：模块化、高内聚度和低耦（ǒu）合度原则（感觉可能可以用上）
（简答题会不会就是每一个ppt的小结部分的内容）
软件设计是要给出软件需求的实现解决方案
设计既要满足需求，也要关注质量；设计用于指导实现和编码
软件设计有其过程，要循序渐进地开展设计
从体系结构设计、用户界面设计、详细设计
软件设计要遵循一系列的基本原则
模块化、信息隐藏、逐步求精、多视点等
面向对象软件设计的特点
基于面向对象的概念和抽象，系统性的设计支持，具有多种优点
对软件设计结果进行文档化和评审
撰写软件设计文档，发现和纠正软件设计中存在的缺陷
软件体系结构设计
包间关系：构成关系，依赖关系
之前一直弄不清楚的图之间的关系的汇总
包在模型管理过程中是配置管理的基本单元，同时也为访问控制提供基本手段
（像是要考察的句子）
软件系统的输入由数据源（data source）提供
管道与过滤器模式的特点
自然地解决具有数据流特征的软件需求
可独立地更新、升级过滤器来实现软件系统的扩展和进化
子系统是服务提供方，边界类是服务请求方
//怎么感觉没有什么内容，根本记不下来
软件体系结构的输出：软件模型和软件文档
软件体系结构设计的特殊性
具有宏观、全局、层次、战略、多视点、关键性等特点
逻辑视点、物理视点等，可用包图、部署图来表示
软件体系结构设计的重要性
针对软件系统全局性、基础性技术问题给出技术解决方案
软件体系结构的风格
管道、层次、MVC、黑板等等，针对不同软件需求及特点
软件体系结构设计的过程、策略和成果
考虑软件关键需求、利用已有软件资产、关注软件质量
软件体系结构的设计模型和文档
用户界面设计
用户界面元素：静态元素，动态元素，输入元素，命令元素
用户界面初步设计不关注美观和布局，关注界面元素及其内容
交互图
表示特定场景下的跳转及跳转发生时的消息传递
类图
表示界面间所有可能发生的跳转及跳转的原因
用户界面设计
以用户为中心
遵循理解性、易操作性、一致性、容错性和人性化等原则
用户界面设计的过程
以软件需求为依据
概念设计、跳转关系设计、界面精化、设计评审
用户界面设计的结果
用户界面原型
UML类图、交互图等模型
（ppt是不是把所有小结整合即可）
软件详细设计
所有设计元素最终通过代码加以实现
如果A与B有消息，那么它们间有关系：关联、聚合和组合（这句话看见很多次了）
有些数据需要持久保存的，存放在永久存储介质中
开展数据设计，以支持信息的抽象、组织、存储和读取
子系统设计的结果
包图、构件图、顺序图、活动图、类图
构件是可独立部署和运行的设计元素
在子系统中设置哪些设计元素
构件、设计类或子系统
下面这个非常重要
如果一个对象a向对象b发消息，那么对应的类A与类B之间存在关联或者依赖关系
如果子系统外的设计元素通过子系统的接口与子系统进行交互，那么这些设计元素与子系统之间存在依赖关系
如果多个设计类之间具有一般和特殊的关系，那么它们之间存在继承关系
软件实现基础
软件测试包括集成测试，确认测试，系统测试
c语言是结构化的程序设计语言
编写必要的异常定义和处理代码，使得程序能够对异常情况进行必要的处理，防止由于异常而导致的程序终止或崩溃
软件实现的输出：
源程序代码
部署在不同计算节点上的可执行程序代码
软件测试报告等
编写代码
软件缺陷是指软件制品中存在不正确的软件描述和实现
每个软件缺陷都被给予一个唯一的标识符
借助于技术问答社区来解决编码和和调试中遇到的问题（以后自己有代码方面的问题，可以多借助互联网平台来进行提问）
软件测试
软件缺陷不可避免
软件测试的目的是为了发现软件中的缺陷。它只负责发现缺陷，不负责修复和纠正缺陷（只专注于完成一件事情）
软件测试的前提和关键是要设计出有效的测试用例
集成测试是黑盒测试
单元测试是白盒测试
α测试（内测与外侧，游戏有这个说法，接触过，所以觉得比较贴近生活）
软件开发公司组织内部人员模拟各类用户行为对即将面市的软件产品（称为α版本、内部测试版）进行测试，发现错误并修正
尽可能逼真地模拟实际运行环境和用户对软件产品的操作，并尽最大努力涵盖所有可能的用户操作方式
经α测试并进行修改后的软件产品称为β版本（也称外部测试版）
β测试
软件开发公司组织各方面的典型用户在日常工作中实际使用β版本，或为对外进行宣传而将β版本免费赠送给典型用户（很多情况下，β版本可以通过Internet免费下载，也可以向软件公司索取），并要求用户报告异常情况、提出批评意见
β测试是在与开发者无法控制的环境下进行的软件现场应用
回归测试最好能够自动化
单元测试是回归测试的基础
穷举测试是不可能的（这个就像我们刷题，题是穷举不完的，我们只可以尽可能多做不同类型的题目举一反三，积累经验）
黑盒测试用例的开发可以与软件实现并行进行，能够缩短软件开发周期
（按照我的理解，就是在不知情的情况下直接测试）
软件部署
软件部署是指将目标软件系统进行收集、打包、安装、配置和发布到运行环境的过程
单机部署和分布式部署
软件维护与演化
何为改善性维护?
对软件进行改造以增加新的功能、修改已有的功能
所以改善性维护改变了软件的功能（有一个选择题考察了这个知识）
软件演化：主动面对变更，功能增强粒度大
负面变更会破坏软件的结构和质量，进而增加维护的成本和难度（改变其实不一定是好的）
软件逻辑老化
解决软件逻辑老化的有效方法之一就是对软件进行重构
（确实啊，缝缝补补不如一切重头再来，但是我们谁可以直接remake呢）
软件项目管理
软件项目管理要管好三类对象：过程、人员和产品
定义和明确过程是软件开发的前提
支持敏捷方法过程：迭代模型
基于甘特图表示的软件项目计划
软件项目规模的估算结果过于乐观（很多时候我们都是对结果过于乐观，其实盲目的乐观还是不行的）
软件质量的保证内容
掌握软件产品质量
软件测试
提交软件质量报告
软件测试报告，说明质量问题
汇报项目组和管理层
例行的质量回报，便于改进管理和技术手段
基线：已经通过正式复审和批准的软件产品、标准或规约
重要内容
迭代性的开发 – 分阶段持续提交可演示产品
以代码为中心 – 开源软件
以敏捷为手段 – 敏捷方法
必须系统模型 – UML模型
适当软件文档 – 文档规范
程序及其质量保证方法
程序质量的保证方法：
遵循编码风格
采用程序设计方法
开展代码重用
进行结对编程
分析、发现和审查代码
人工审查、静态分析、程序测试
软件及其特点
要编写出高质量的程序需要循序渐进地开展工作（做大部分事情感觉都是这个步骤）
支撑软件
辅助软件开发和运维，帮助开发人员完成软件开发和维护工作的一类软件
示例：SonarQube、Visual Studio、Eclipse等
常见的一些软件，第一个软件我没有怎么接触过
结语
简答题出自于ppt和教材，感觉还是不怎么能找到终点，简答题占比30分，把ppt全部看了一遍，感觉也差不多了