面向对象分析设计导论
什么是OOAD？
面向对象的分析和设计 （OOAD） 是一种技术方法，通过应用面向对象的编程来分析和设计应用程序、系统或业务，并在整个软件开发过程中使用可视化建模来指导利益相关者的沟通和产品质量。
OOA
强调在问题域中查找和描述对象或概念——需要相关领域的专家以及面向对象的专家
OOD
强调定义具有属性和方法的逻辑软件对象——根据OOA阶段的结果定义，包括软件逻辑解决方案以及类方法的定义
OOAD基本能力
巧妙地将职责分配给软件组件
分析与设计
- 分析强调对问题的调查——what
- 设计强调逻辑解决方案——how
抽象与分类与类
- 抽象：忽略事物的非本质特征，只注意那些与当前目标有关的本质特征，从而找出事物的共性
- 分类：把具有共同性质的事物划分为一类，得出一个抽象的概念
- 类：具有相同属性和操作的一组对象的集合
敏捷开发与迭代开发
敏捷开发是以用户的需求为核心，采用迭代、循序渐进的方式开发软件。
优点：
- 具备进化式精化的计划、需求和设计的短时间定量迭代是这些方法所共有的基本实践
- 倡导反映简易、轻量、沟通、自组织团队等更多敏捷性的实践和原则
方法：
- 通常应用时间定量的迭代和进化式开发
- 使用自适应计划
- 提倡增量交付
- 并包含其他提倡（快速和灵活的响应变更）的价值和实践
迭代开发整个工作被划分为一系列袖珍的、固定时间的小项目，这叫系列迭代。
优点：
- 减少项目失败可能性，提高生产率、降低缺陷率
- 在早期缓解高风险
- 早期可见的进展
- 早期反馈、用户参与和调整，会产生更接近涉众真实需求的精华系统
- 可控复杂性
- 一次迭代中的经验可以被系统地用于改进开发过程本身32
瀑布模型的错误
- 假设规格说明是可预知的和稳定的，并且能够在项目开始时就正确定义
- 典型的软件项目在需求上会经历25%的变更
- “新产品开发”领域-软件开发是（平均而言）变更极大且不稳定的领域
反馈和改写
- 早期开发中的反馈
- 来自测试中的反馈，有助于开发者精化设计或模型
- 来自团队处理早期特性过程的中反馈,有助于精化时间表和估计
- 来自客户和市场的反馈，有助于重新定义下一次迭代实现特性的优先级
敏捷建模
- 使用敏捷方法并不意味着不进行任何建模
- 不要单独建模，建模和模型的目的主要用于理解和沟通，并不是构建文档
- 不要对所有或大多数软件设计建模或使用UML。
- 尽可能使用最简单的工具。例如在白板上画UML草图，使用相机拍照等。
统一过程（UP）
软件开发过程——描述构造、不熟以及维护软件的方式
四个阶段：
- 初始——大体上的构想、业务案例、范围和模糊评估
- 细化——已精化的构想、核心架构的迭代实现、高风险的解决、确定大多数需求和范围以及进行更为实际的评估
- 构造——对遗留下来的风险较低和比较简单的元素进行迭代实现，准备部署
- 移交——beta测试
UML图
用例图、静态图（类图、包图）、行为图（状态图、活动图）、交互图（顺序图、协作图）、实现图（构建图、部署图）
UML图中的关系
泛化——继承关系，A继承B就是A泛化B，三角箭头指向父类
实现——实现interface接口，带三角箭头的虚线指向父类
关联——指一个类成为另一个类的成员，带普通箭头的实心，分为双向与单向（双向为纯实现）
依赖——类成员也属于依赖的一种，依赖还包括：函数参数，函数内局部变量，虚线普通箭头指向被依赖
聚合——特殊的关联，has-a关系，空心菱形+实线箭头，菱形是整体
组合——特殊的关联，contains-a关系，实心菱形+实线箭头，菱形是整体（组合关系共享生命周期）
需求分析
- 系统需求：从系统的角度描述要提供的服务以及所受到的约束。
- 功能性需求：描述系统应该做什么，即为用户和其它系统完成提供的功能和服务。
- 非功能性需求：产品必须具备的属性或品质。
需求分析的具体任务
1.确定对系统的综合要求
2.分析系统的数据要求
3.导出系统的逻辑模型
4.修正系统开发计划
需求分析的作用
1.客户与开发人员之间的桥梁
2.明确系统做什么的问题
3.降低开发风险
需求分析过程
1.需求获取
2.需求建模
3.需求文档
FURPS+
Functional——功能性
Usability——可用性
Reliability——可靠性
Performance——性能
Supportability——可支持性
”+“指以下因素：
实现、接口、操作、包装、授权
用例模型
强调用户的目标何观点，目的是说明系统的功能性或行为性需求
- 用例use case：一组相关的成功和失败场景集合，用来描述参与者如何使用系统来实现其目标
- 场景scenario：是参与者和系统之间的一系列特定的活动和交互，也称为用例实例use case instance
- 参与者actor：是某些具有行为的事物，可以是人、计算机系统或组织
三种格式：
- 摘要brief：成功场景的简短摘要
- 非正式casual：段落格式覆盖不同场景
- 详述full-dressed：有前置条件何成功保证的各个步骤的各个变化
用例的特点
①用例用于描述系统的功能，这个功能是外部使用者看到的系统功能，不反映功能的实现方式。
②用例描述用户提出的一些可见需求，对应一个具体的用户目标。
③用例反映系统与用户的一次交互过程，应该具有交互信息的传递。
④用例是对系统功能的描述，属于需求建模（功能性需求）。
如何发现用例
1.选择系统边界——硬件还是软件？一个人还是多个人？
2.确定主要参与者
3.确定主要参与者的目标
4.命名
用例模型准则
- 以无用户界面约束的本质风格编写用例
- 编写简洁的用例
- 编写黑盒用例
用例关系
- 关联关系——用户与用例
- 泛化关系——参与者与参与者
- 包含关系——include其他用例
- 扩展关系——extend其他用例
领域模型
定义：对领域内的概念类或现实世界中对象的可视化表示。
领域模型是没有方法的类图的集合，并且在领域模型中不会出现软件构件
领域模型是现实世界的一个可视化抽象字典
领域模型中的概念类越多越好
Q：为什么要建模？
A：因为建模能帮助团队提炼出事物的本质，以便能更好的指导应用系统规划建设。
创建领域模型的原因之一就是理解该业务的关键概念和词汇
创建领域模型，就是以当前迭代中所要设计的需求为界：
1.寻找概念类
2.将其绘制为UML类图中的类
3.添加关联和属性
找到概念类
1.重用和修改现有模型
2.使用分类列表
3.确定名词短语