软工题解
软工题解
注：括号后的⭐️表示复习优先级，越多表示优先级越高（⭐️⭐️⭐️最高，⭐️最低）
Chapter 1 软件的本质 The Nature of Software
1. 软件是什么：（⭐️⭐️）
- 完成软件的特性，功能，性能等所需要的 计算机程序，指令代码——程序
feature特性： 非功能需求 non-functional：如安全性，兼容性，可移植性，可扩展性等
function功能：与非功能需求相对应
performance：feature的一部分，但因为很重要所以单拉出来
使得程序可以充分利用操纵信息所使用的 数据结构——数据
描述程序操作使用的硬拷贝和虚拟形式的 描述性信息——文档
2. 生命周期：（⭐️）
硬件的生命周期——浴缸曲线（早期的infant mortality是由于设计引起问题，当设计问题解决后可以平稳运行，直到硬件损耗，期间替换硬件不影响failure rate）(早期故障多，后期磨损）
理想曲线——开发后可以一致运行实际曲线——考虑：1.功能增强的update；2. 功能修改和错误修复modify & bugfixed不断改变后failure rate的突然上升与总体上升: 修改change后导致其他新的问题出现，有”传染性”错误的可扩展性，这是功能调整增强的代价 (错误的扩展性，修复某问题的副作用 )
3. 软件的划分：（⭐️⭐️）
1、系统软件（System Software）
2、应用软件（Application Software）
3、工程/科学软件（Engineering/scientific software）
4、嵌入式软件（Embedded software）
5、产品线软件（Product-line software）
6、Web/移动App（Web/Mobile applications）
Mobile app包括：
user interface 用户界面
interoperability with Web-based resources 与基于web的资源的互操作性
local processing capabilities 本地处理能力
7、人工智能软件（AI software）
4. 遗留软件的特点：（⭐️⭐️）
生命周期长（老不死）
业务关键性（涉及ys的底层代码了）
质量差：设计难以扩展，代码令人费解，文档混乱
5. 遗留系统演化原因：（⭐️）
AUEA
A 需要进行适应性调整，满足新的计算环境和计算需求（比如：密码升级到指纹） new tech adapted
U 升级以实现商业需求 enhanced implementation
E 扩展使得可以与更多的系统交互，如现代系统或数据库 extend
A 架构需要重新部署来适应新环境（例如下面以前没有mobile，或部署微服务框架等） rearchitected
6. 云平台架构包括：（⭐️⭐️⭐️）
IaaS层（资源层)
虚拟机（跨IaaS与PaaS）
Paas层（平台层：资源监测；预警；优化决策，资预优)
SaaS层 (软件，可视化界面)
Chapter 2 软件工程 Software Engineering
1. 软件工程的定义：（⭐️⭐️⭐️）
（1）将系统化的（systematic）、规范化的(disciplined)、可量化的(quantifiable)方法应用于软件的开发、运行和维护
（2）对（1）方法的研究
2. 软件工程的层次：（⭐️）
Q 质量: 为什么要有软件工程⇒因为要提高软件的质量，质量是根基
P 过程：回答了如何提高质量的问题
M 方法：方法贯穿于过程中，eg：UseCase建模，数据库设计方法，架构方法，分析方法，设计方法，测试方法等多种方法
T 工具：现在很多方法和技术都工具化了
3. 软件工程的通用过程框架包括：（⭐️⭐️⭐️）
CPMCD
- 交流Communication：需求收集requirement gathering& 需求诱导 elicitation
- 计划Planing：planning是一个大的，阶段的计划（如人员安排等），有很多template
- 建模Modeling：包括分析建模(Analysis modeling)，概要设计(high-level design)， component design 组件设计(detailed design)
- 构建Construction：coding & testing 写代码&测试,测试包括单元测试，系统测试
- 部署Deployment：delivery & maintenance & feedback 交付，维护，反馈
软件开发过程包括很多迭代，并不是线性顺序的模型，而是循环往复
Standard Process包含的Activity
requirement elicitation 需求诱导
requirement analysis modeling 需求分析建模
architecture design 架构设计
component design 组件设计
coding 写代码
unit testing 单元测试
integration testing 集成测试
system testing 系统测试
acceptance testing 验收测试（用户在开发环境下的测试）
Release & Delivery， Feedback & Support 发布，交付，反馈，支持
对应CPMCD：
Communication: 1
Planning:(umbrella activity)
Modeling: 2、3、4
Construction: 5、6、7、8、9
Deployment:10
4. 伞形活动（umbrella activity）包括：（⭐️⭐️⭐️）
跟风质技测配复工（跟风至极，则配复工）
软件项目跟踪控制：根据计划评估进度，采取措施保证计划实施（如：人员计划，发挥成员特长能力，了解人员是tracking，调整人力是control）
风险管理：对可能影响成果或产品质量的风险进行评估(例如，人员流失跳槽风险，新技术、云平台、数据库不熟悉等)
软件质量保证：确定和执行保证软件质量的活动(编程管理，代码规范，需求规约等）
技术评审：评估软件工程 (比如代码Review，需求Review等）
测量：定义和收集过程、项目以及产品的度量（对schedule进行测量，对发现的缺陷进行度量，对人员工作量进行度量等）
软件配置管理：整个软件过程中变更带来的影响（用Git进行版本控制）
可复用管理：定义工作产品复用的标准，建立构建复用机制（苹果的复用做的很好，通过标准化可以降低成本）
工作产品的准备和生产：包括生成产品所必须的活动（例如模型、文档、日志、表格和列表）
Chapter 3 软件过程 Software Process
1. 过程模式（ process patterns）包括：（⭐️⭐️）
混个眼熟
1、模式名称（Pattern name）：
2、驱动力（Forces）：
3、类型：（Type）
4、启动上下文（Initial context）
5、问题（Problem）
6、解决方案（Solution）
7、结果上下文（Resulting context）
8、相关模式（Related pattern）
9、已知应用和实例（Known uses and examples）
2. 过程流分为：（⭐️）
线代进行
Linear 线性
Iterative 迭代
Evolutionary 进化/演化
Parallel 并行
3. 任务集的内容：（⭐️）
T：work tasks:
P：work products: 在work tasks之后形成一个work products
Q：quality assurance( QA ) points: 产生work products后要有质量保证
M：milestone: 形成里程碑
4. 软件改进方法有：（⭐️）
用于过程改进的CMMI标准评估方法：
用于组织内部过程改进的CMM评估
SPICE
软件ISO
5.软件过程框架中定义了许多activities, actions, 和tasks, 举例说明并解释它们之间的关系（⭐️⭐️）
活动activity主要实现宽泛的⽬标，与应⽤领域，项⽬⼤⼩，结果复杂性或者实施软件⼯程的重要程度没有直接关系
动作action包含了主要⼯作产品⽣产过程中的⼀系列任务
任务task关注⼩⽽明确的⽬标，能够⽣产实际的产品
例如testing这个activity,包括actions：单元测试、集成测试、系统测试、验收测试
单元测试这个action包括tasks:计划、⽤例分析、设计测试⽤例、技术评审、运⾏测试⽤例、debug、软件配置管理
Chapter 4 过程模型 Process Models
1. 简述瀑布模型，简述瀑布模型与V模型的关系：（⭐️⭐️⭐️）
瀑布模型：⼜称为经典⽣命周期，它提出了⼀个系统的，顺序的软件开发⽅法，从⽤户需求规格说明开始，通过策划、建模、构建、部署的过程，最终提供完整的软件⽀持。
瀑布模型的⼀个变体称为V模型
随着软件团队⼯作沿着V模型左侧步骤向下推进，基本问题需求逐步细化，形成了对问题及解决⽅案的详尽且技术性的描述。⼀旦编码结束，团队沿着V模型右侧的步骤向上推进⼯作，其本质上是执⾏了⼀系列测试，与瀑布模型没有本质区别。
2. 瀑布模型的问题：（⭐️⭐️⭐️）
实际项目很少遵守瀑布模型的顺序。虽然线性模型可以加入迭代，但它是用直接的方式实现的，可能造成混乱。
客户很难描述清楚需求，瀑布模型要求客户明确需求，很难适应项目开始阶段的不确定性。
客户必须要有耐心，因为只有项目接近尾声才能得到可执行程序。
对于系统中的重大缺陷，如果在可执行程序评审前没有发现，可能造成惨重损失。
线性特性在某些项目中会导致阻塞状态。
3. 增量过程模型的例子：（⭐️⭐️）
例如，采用增量模型开发文字处理软件，
在第一个增量中提供基本的文件管理、编辑和文档生成功能；
在第二个增量中提供更为复杂的编辑和文档生成功能；
在第三个增量中提供拼写和语法检查功能；
在第四个增量中提供高级页面排版功能。
4. 增量过程模型的特点：（⭐️⭐️）
每一次增量都生成可发布的产品increment producut，第一个增量形成核心基本产品，后续增量形成完善版本
每次增量是一个waterfall，一次增量内不主张迭代
不同增量间可并行开发（比如：第2个做coding时，第3个可做需求建模）——纵轴重合
5. 为什么要用Prototype：（⭐️）
客户定义了一组软件的一般目标但没有具体需求时；开发者不知道具体开发细节时，可帮助您和其他利益相关者更好地了解在需求模糊时要构建的内容。
6. 螺旋模型 Spiral Model的特点：（⭐️⭐️⭐️）
一是采用循环的方式逐步加深系统定义和实现的深度，同时降低风险。
二是确定一系列里程碑作为支撑点，确保利益相关者认为系统解决方案可行且令各方满意
适合大型项目，风险较高的项目，需求不明确的项目(big,risky,unclear)，将原型设计的迭代性质与瀑布模型的受控和系统方面相结合。
其他process models: 在软件交付时结束；
spiral model: 在整个软件的生命周期中都适用
Chapter 5 敏捷开发 Agile Development
1. 敏捷开发强调：（⭐️⭐️⭐️）
注重”客户的满意度“和”尽早提交可增量的软件产品“（增量交付，开发过程存在迭代）
快速交付，不看重中间产品
小型，积极的项目团队，协调能力强，看中团队结构，协作态度
可用非正式的方法（e.g. 数据库设计没有写完整的设计文档，中间建模尽量简单）
最小的work product（开发过程简单，会要求尽量减少work product且work product简单，不完全按照template）
整体发展简单（e.g. 封闭开发）
软件工程师和其他项目利益相关者（管理人员，客户，最终用户）在一个敏捷的团队，命运共同体，其中roles和responsibility随时调整
敏捷开发适应需求变更
2. Change Cost图（⭐️）
理解敏捷模型的曲线：
regression testing回归测试——变更多了后，回归测试成本越来越高，最终翘了上去
3.敏捷过程原则：（⭐️⭐️⭐️）
Highest 最高优先级：通过早期early和连续continuous交付有价值的软件来满足客户
Change 鼓励需求改动，哪怕是开发过程晚期（好的改动可以提升顾客的竞争优势）
Frequently 经常提供work product，最好有短的schedule
Together 甲方和开发者daily紧密合作
Motivated 和有动力的人开发，给他们好的环境和支持，信任他们
F-to-F 面对面讨论，实时解决问题，这是最高效率的
WorkingSoftware 进度的最好指标就是产出的可工作的软件
Sustainable 敏捷过程保持稳定的开发过程，赞助人，开发者和用户应该maintain a constantpace indefinitely (不定期同步跟踪）
Excellence 持续关注追求技术的改进和设计的优化
Simplicity 文档尽量简单
Self-organizing 一个self-organizing的team可以做出最好的架构、需求和设计
Reflection 定期进行回顾
4. 描述极限编程（XP）的过程：（⭐️⭐️⭐️）
Planning: 策划
- 客户设定一系列stories，故事的单位是use case，被放在索引卡上
- 客户基于特征或功能的整体业务价值为story分配优先级，划分依据：
业务上重要性(importance)
此功能(story)是否有高风险(high risk)
交付时间(deadline要求）
3.XP团队评估每个故事，并为每个故事分配开发周，如果估计故事需要超过三个开发周(工作量太大），请客户拆分为较小的故事
一旦基本承诺定下，XP团队会将以三种方式之一开发story：
所有story将被立即实施（几周之内）
最高优先级的story将在计划中提前并首先实施
最高风险的story将在计划中提前并首先实施
在第一个project（software increment）发布后，团队计算目前完成的速率(project velocity)，即第一个release版本中部署user stories数量占总数量的比例。它可以用于评估：
i. 估计后续发行版本的发布日期和开发进度安排schedule
ii. 确定是否有过分承诺，如果有，则要修改发布内容或推迟交付日期
迭代
Design：设计
鼓励使用CRC卡片
采用Spike解决方案：如果在进行某个功能设计时遇到困难，立即建立这部分设计的可执行原型并进行单独测试。
Coding：编码
- 首先开发一系列unit test，该测试将测试当前版本中包含的每个story（软件增量software increment）
- 进行Pair Programming 结对编程，两个人共同为一个故事开发代码
- 进行Continuous integration持续集成，将pair program结对编程小组的代码整合，提供“烟雾测试”环境
- Refactoring 重构， 让代码规范化、标准化以进行复用
Test：测试
- 修改代码时使用回归测试策略
- 将单元测试组织到通用测试集，使得媒体都可以进行集成和确认测试
- 进行验收测试（客户测试），测试客户可见的整体系统特性和功能
5. Scrum流程：（⭐️⭐️⭐️）
scrum是一种敏捷开发过程模型。下面举例描述一下scrum开发全过程：
1、首先确定Scrum角色。
产品负责人（Product Owner）
Scrum Master：将team leader和product owner紧密地工作在一起。
团队（team）：人数一般在5-9个左右
2、开发调研：我们⾸先要确定⼀个product Backlog(按优先顺序排列的⼀个产品需求列表)
3、工作量估算：团队根据product backlog做⼯作量的估算
4、Sprint计划会议：通过Sprint 计划会议, 来从中挑选出⼀个Story作为本次迭代完成的⽬标，然后把这个Story进⾏细化，形成⼀个Sprint Backlog。团队从Sprint Backlog中挑选承诺完成的条目，并分解条目成为工作项，评估工作项工时（小时为单位）。过程中要进⾏每日站立会议，汇报昨天完成了什么，今天要做什么，遇到了哪些问题。做到每日集成，每天都可以有⼀个成功编译，并且可以演示的版本
5、Sprint评审会议：当⼀个Story完成，业绩就是Sprint backlog完成，这时，要进⾏Sprint 评审会议，团队向 PO 及相关干系人演示产品增量收集意见，为下一个Sprint 做准备
6、Sprint回顾会议：最后就是回顾会议，每个⼈总结并讨论改进，检查哪些方法是值得保留的，哪些是要废弃的。放⼊到下⼀次Sprint的产品需求中
6. DevOps流程：（⭐️⭐️）
开测集部监
- Continuous development： 持续开发
- Continuous testing：持续测试
- Continuous integration：持续集成
- Continuous deployment：持续部署
- Continuous monitoring：持续监控
Chapter 7 软件工程实践原则 Principlesthat guide practice
1. 代码进行重构的方法：（⭐️⭐️）
1、重命名：对类，接口，方法，属性等重命名，以使得更易理解。
2、抽取代码：将方法内一段代码抽取为另一个方法，以使得这段代码可以被其他方法调用。
3、封装字段：将类的某个字段转换成属性，可以更加合理的控制字段的访问
4、抽取接口：将类的某些属性、方法抽取组成个接口，将类自动实现该接口。
5、提升方法内的局部变量变为方法的参数：这主要是是在写代码的过程中会使用到。
6、删除参数：将方法的一个或多个参数删掉
7、重排参数：将方法的参数顺序重新排列。
2. 引导过程Process的原则（Principles）：（⭐️⭐️）
- Agile 过程要灵活agile(尽量用敏捷模型开发）
- Quality 在每一步产生迭代work product时注重质量
- Adapt 做好适配的准备
- Team 建立高效团队
- Communication 建立沟通和协调coordination机制
- Change 管理变更
- Risk 风险评估
- Value 产品要有价值
3. 引导实践Practice的原则（Principles）：（⭐️）
- D&C 分而治之
- Abstraction 理解和进行分析抽象
- Consistency 前后一致尽量做到
- Transfer 注意信息的转换
- Modularity 构建表现出有效模块化的软件(类就是模块化)，即类的定义
- Pattern 寻找模式
- Perspective 当可能时，从许多不同的角度来看，代表问题及其解决方案
- Maintain 版本控制，保证人员调整后能接上工作
引导每个framework activity的原则：CPMCD
Chapter 8 需求 Requirements
1. Requirement Engineering（需求工程）的七大步骤：（⭐️⭐️⭐️）
IEENSVM
- Inception 初始化——项目启动阶段
- elicitation 诱导——需求调研
- 确定商业目标establish business goals（要驱动甲方尽量不保留地表达他们的目标）。
- 一旦捕获了目标，就应该建立优先级机制
- 形成一套潜在的软件系统架构设计依据
- elaboration 阐述——细化进行建模
进一步明确需求，开发一个细化的需求模型。
在这个基础上进行需求分析建模：解析每个用户场景以提取分析类，定义每个分析类的属性，并标识每个类所需的服务。识别类之间的关系和协作，并生成各种补充图。
- negotiation 谈判——需求谈判
- specification 规约——形成2个规约
需求规约——文字描述，UseCase
需求分析规约——文字描述，功能建模，数据建模，行为建模
- validation 验证——对规约进行评审（Formal Technical Review正规技术评审(见指南v1.0)）
- management 管理——对需求进行版本控制和管理
其产品包括需求规约和需求分析规约
2. 分析模型的组成元素：（⭐️⭐️⭐️）
基于场景的元素：use case diagram ， activity diagram (功能建模）
基于类的元素：class diagram （数据建模）
行为模型： state diagram (sequence diagram)（行为建模）
3. 非功能需求包括：（⭐️⭐️）
软件项目评估：十大常见非功能性需求描述案例整理 - 知乎 (zhihu.com)
4. 软件需求规约包括：（⭐️）
(a) Environment description and system objectives. 环境描述和系统目标。
(b) Functionality.功能。
(c) Non-functional requirements.非功能需求。
(d) User interface requirements. 用户界面需求。
(e) System architecture. 系统架构。
(f) Data requirements. 数据需求。
(g) Assumptions and dependencies.假设和依赖关系。
(h) Constraints.限制条件。
(i) Glossary.术语表。
Chapter 9 需求建模：基于场景的方法 Requirement Modeling:Scenario-BasedMethods
1. 需求建模的3个目的：（⭐️）
描述客户需要什么
为软件设计奠定基础（架构设计、组件设计）
定义在软件完成后可以被确认的一组需求
2. 举例说明领域建模：（⭐️⭐️⭐️）
领域分析目的(为什么要Domain Analysis）：创建或提取那些广泛适用的分析类和分析模式，以便于它们可以被复用。
- ⽐如我做⼀个进销存系统，⾸先需要学习领域知识
从已经开发过的项⽬获取
通过⽤户调研获取
调研⽬前和将来的需求
- 然后进⾏领域分析
通过需求规约⾥⾯的⽂字描述，把潜在类提取出来.
对于⼀些通⽤的业务类，定义标准的⽅法和属性，然后以后做其他类型的进销存系统可以复⽤
- 然后进⾏类的功能建模
功能建模要构建activity diagram，反映类的功能逻辑：⽐如有⼀个订单类，客户产⽣订单成功了，就往订单加物品，如果没有成功，就返回尝试产⽣⼀个新订单
- 最后要选择⼀种建模语⾔进⾏建模，⽐如UML
3. 软件需求工程分析模型的各个分析模型的内容和作用：（⭐️⭐️⭐️）
关键词：用户、系统、数据、对象、外部
基于场景的模型包括用例、user stories和活动图等，描述了用户如何与系统交互（用例图），以及在使用软件时发生的活动序列（活动图）。
类模型包括类图、协作图等，为系统将操作的对象建模，描述了对象包含的属性、应用于对象的操作（方法）、对象之间的关系(一些层次结构)，以及类之间发生的协作（协作图）。
行为模型包括状态图、时序图等，描述了外部事件如何改变系统或内部类的状态（状态图）。
流模型包括DFSDs等，将系统以信息流转的形式表现出来，描述数据对象在流经各种系统功能时如何转换。
Chapter 10 类建模 REQUIREMENTS MODELING: CLASS-BASED METHODS
1. 类图构建方法：（⭐️⭐️）
类——找到潜在的类（业务类）
检查在Chapter 9 中的需求模型中的一部分usage scenarios；以UseCase为单位和依据，对对用例进行语法分析grammatical parse(每个UseCase检查有实义的名词或名词词组等*)*
属性和操作——每个UseCase在类定义下来后，初步定义类里面的属性和方法
CRC+聚合继承——建立CRC模型，构建聚合和继承关系
关联和依赖——构建类与类之间的关联关系、依赖关系
根据UseCase定义的类之间可能的关联（包括同一个UseCase中的类和不同UseCase中的类）
- 完整类图——构建完整的类图
2. 潜在类的6个特征：（⭐️⭐️⭐️）
Retained Info 潜在类拥有需要保存在数据库中的信息——持久信息 比如：学生有学号信息等
Needed Service 潜在类中有很多方法服务——服务（方法）比如：学生需要获取成绩
Multiple Attributes 潜在类应该有多个属性→低耦合——多属性 只有一个属性的潜在类往往并入到其他类中
Common Attributes 潜在类有通用属性（泛化，父子关系，基础关系）——通用属性
Common Operations 潜在类有通用方法——通用方法
Essential Requirements 潜在类应该体现基本需求，外部实体、必须的生成和消费信息等几乎总是在需求模型中被定义为类(?)——需求相关
上面的6种特征要全部满足或几乎全部满足。不过提取这些类是主观的过程，之后的评估可能会导致类的增加减少
如何确定潜在类：对用例描述进行语法扫描，提取名词或名词词组以及动词，合并同义词、近义词后，考察上述六个特征，最终确定潜在类
3. 类关系有：（⭐️⭐️⭐️）
聚合：汽车与轮胎
关联（类之间获取彼此的信息）：老师与学生
依赖：现代人与计算机，现代人中的方法用到了计算机这个类
泛化：鸟和动物
组合：公司和部门
组合与聚合：
聚合 部分可以离开整体存在
组合 部分不能离开整体存在
Chapter 11 行为,模式和Web/Mobile应用 Behavior, Pattern and Web/Mobile App
1. 行为建模的基本步骤：（⭐️）
评估所有用例以完全理解系统内交互的顺序
识别驱动交互序列的事件，并理解这些事件如何与特定对象关联
为每个用例创建一个序列
为系统或类构建状态图
回顾行为模型以验证准确性和一致性
2. 举例说明Web/Mobile应用中交互建模、功能建模、内容建模、导航建模之间的关系：（⭐️⭐️⭐️）
内容建模，借助数据树确定界面中的内容对象，相应的控件布局，是界面设计的基础
交互建模，以界面交互为导向，用界面驱动活动图的功能逻辑，借助活动图，利用内容模型构建的界面进行交互
功能建模，借助活动图，在交互模型的基础上，为完成特定功能的界面进行细化，将用例的活动图改为界面来驱动
导航建模，即构建前端界面的导航，它把内容建模中的内容对象放在⼀起，形成⼀个内容对象流，完成特定功能
Chapter 12 设计概念 Design Concepts
1. 举例说明软件建模活动从需求模型向设计模型的转换过程：（⭐️⭐️⭐️）
- 数据设计、类设计
将类模型转化为设计类以及其他要求实现的数据结构，CRC中的对象与关系、类属性以及其他表示法描述的数据内容为数据设计活动提供了基础。部分类设计可能与软件体系结构的设计一起进行。在设计每个软件组件时，会出现更详细的类设计。
- 体系结构设计
定义软件的主要结构化元素、结构风格和模式之间的关系，表示一个基于计算机系统的框架，它以类图和类之间协作关系作为重要依据，设计时基于类图和CRC片，把功能相关的类构建为一个子系统，并明确子系统间的通信方式，进而增加接口类。
- 接口设计
描述软件和使用人员之间、软件和协作系统之间如何通信。因此，场景和行为建模（用例图、状态图）提供了接口设计所需的许多信息，如参考用例图中用例与用户的交互、状态图中类状态切换时需要传递的信息。
- 构件级设计
将软件体系机构设计的结构化元素变换为对软件构件的过程性描述。从基于类的模型和行为模型（时序图）中获得的信息可以作为组件设计的基础，如从类图中获取类内方法，以及从时序图中获取某类调用其他类的方法。
2. 软件质量属性包括：（⭐️⭐️）
Furps
Functionality 功能性，评估程序的特性与功能、功能通用性generality与系统安全性security
Usability 可用性，评估整体美观性aesthetics、一致性consistency和文档等使用体验
Reliability 可靠性，评估通过测量失败的频率和严重程度,输出结果的准确性accuracy,程序的可预测性predictability
Performance 性能，衡量处理速度、响应时间、资源消耗,吞吐量和效率
Supportability 可支持性，可维护性maintainability，包括了可扩展性、适应性和可服务性，还有可测试性testability，兼容性compatibility，可配置性configurability
3. 模块化和软件成本：（⭐️）
随着模块数量的增多，用于integrate的开销越大，而每个模块开发的成本平摊越少，两者加起来类似一个二次函数，这个二次函数有个最优区间，叫最小开销区间（M）
Pi：某功能
C：复杂度
E：工作量
一般对任务$P1$，$P2$，如果$C(P1)>C(P2)$ ，那么$E(P1)>E(P2)$
另外有:
$E(P1+P2)>E(P1)+E(P2)$
$C(P1+P2)>C(P1)+C(P2)$
分而治之在这里体现，合在一起做工作量更大，分而治之可以节约成本
4. 设计类的种类：（⭐️⭐️⭐️）
User Interface classes 用户界面类（sequence diagram & use case diagram)
Business domain classes 业务类（由分析类直接转过来，基本是一对一，可能有优化比如一个分析类分成2个类等）
Process classes/Control classes 控制类（往往没有属性，只有方法）对系统的可维护性很重要
Persistent classes 持久类（用于数据持久化，比如被Hibernate持久化到数据库中的类，持久化类的实例对象将保存在数据库或文件中）
System classes 系统类（如Java的主类有main()方法）
5. 设计类的四个指标：（⭐️⭐️）
Complete and Sufficient 完整充分（属性方法的完整封装encapsulation）封装良好
Primitiveness 原始性（同样的功能和属性不能在2个或多个类中出现） 不重复，每个属性方法都是原始的
High Cohesion 高内聚（属性和方法与类本身相关）
Low Coupling 低耦合（交互接口要简单）
接口类的存在就是为了低耦合；一个类更多应该访问邻界类，尽量少访问其他package或subsystem；子系统中的一个类不需要知道其他类太多信息，最好通过内部 接口或外部接口这些控制接口类去访问得到
Chapter 13 概要设计 Architectural Design
1. 体系结构典中典的例子：（⭐️⭐️⭐️）
2. 体系结构设计包括：（⭐️⭐️⭐️）
软件架构设计
数据/数据库设计（以类图为依据，有时涉及数据字典设计，和接口紧密相关）
接口设计（内部接口（类内方法互相调用) ，类间，子系统间方法调用，外部接口，用户接口）
3.系统上下文的建立：（⭐️⭐️⭐️）
在体系结构设计层，ACD图对软件与其外围实体的交互方式进行建模。
上级系统：这些系统把目标系统作为某些高层处理方案的一部分。
下级系统：这些系统被目标系统使用，并为完成目标系统的功能提供必要的数据和处理。
同级系统：这些系统在对等的基础上相互作用（即信息或者由同级系统和目标系统产生，或者被同级系统或目标系统使用）
参与者：通过产生和消耗必要的信息，实现与目标系统交互的实体
4. 举例说明ACD在体系结构设计中的作用：（⭐️⭐️）
提供系统需要如何与其他企业交互的组织视图，描述软件所在的业务生态系统。
标识外部系统。
提供了业务上下文的分解，并提供了对业务上下文信息的可跟踪性。
帮助标识构建完整的解决方案所需的一些主要体系结构构件。
信息流还表示对体系结构而言非常重要的活动，这些活动可以回溯到业务流程模型，而后者是表示系统需求的一个主要部分。
Chapter 14 详细设计 Component-LevelDesign
1. 实施构件级设计的方法：（⭐️）
- 标识所有问题域对应的设计类
- 确定所有与基础设施相对应的设计类
- 细化不需要作为复用构件的设计类
a. 在类或构件协作时说明消息细节
b. 为每个构件确定适当接口
c. 细化属性，并根据定义实现属性所需要的数据类型和结构
d. 详细描述每个操作的处理流
- 说明持久数据源并确定管理数据源所需要的类
- 开发并且细化类或构件的行为表示
- 细化部署图
- 考虑构件级设计表示，并且时刻考虑其他可选方案