梦入少年丛
歌舞匆匆
概念
面向对象系统分析与设计概述
- 分析
- 需求分析（调查研究系统要成功所必须满足的需求）
- 面向对象分析（调查研究领域对象以发现重要信息来满足需求）
- 设计
满足需求的概念上的解决方案 - 分析设计方法演变
- 没有方法
- 功能分解
- 结果化方法（数据流法）
- 信息建模法（ERD）
- 面向对象分析设计
- 面向对象
对现实世界理解和抽象的方法 - 面向对象的分析
在问题域内发现和描述对象 - 面向对象的设计
定义软件对象以及其协作来完成需求 - 面向对象方法核心
- 找对象
- 抽象
- 系统分析技能
- 沟通
- 分析
- 管理
- 技术
- 面向对象优点
- 复用
- 应变
- 沟通
- 市场
- 士气
- UML
- UML是一种统一的、标准的建模语言
- UML是一种统一的、标准的建模语言
- UML建模过程
- 定义用例
- 定义领域模型
- 定义交互图
- 定义设计类图
- 可视化建模的优点
- 观察全景
- 发现和分析对象之间的联系
- 忽略或隐藏旁枝末节
迭代敏捷过程
- 软件过程
定义了软件开发、部署、维护的步骤 - 软件过程谱系
- 迭代开发
- 较早对付高风险内容
- 明确看到进展
- 较早获得反馈
- 控制复杂性
- 统一过程
- 敏捷开发
- 进化式精化的计划
- 需求和设计的短时间迭代
- 简易、轻量、沟通、自组团队
- 迭代开发
- 敏捷UP
- 建模是为了理解而非文档
- 敏捷开发原则
- 鼓励用户参与
- 团队决定权
- 需求变化，时间固定
- 高度理解需求
- 开发较小的增量版本并进行迭代
- 专注于频繁交付
- 完成每个功能，然后继续下一个
- 80/20规则
- 尽早且经常测试
- 利益相关者协作
- SCRUM
- 使我们专注于最短时间内完成最有价值的部分
- 快速、经常监督实际产品发展的状况
特点：
- 自组织团队
- 商业价值驱动
- 反复递增
- 检查实际的工作软件
- 敏捷过程之一
- 没有规定具体的工程实践
需求与用例
- 参与者
- 主要参与者
- 协助参与者
- 幕后参与者
- 场景
- 系统的一个特定情节或用例的一条执行路径
- 用例中实例化出来的一组活动，一个用例可以实例化出多个用例实例
- 一个用例定义了一组用例实例，是对一组用例实例的抽象
-
用例
从用户角度观察得到的系统的行为- 用例是相对独立的
- 用例的执行结果对参与者来说是可观测的和有意义的
- 任何用例必须有一个参与者执行
- 用例必是动宾短语
- 用例图
- 显示一组用例、参与者以及他们之间关系的图
- 从用户的角度描述对软件产品的需求，分析产品的功能和行为
- 用例图定义和描述了系统的外部可见行为
- 用户参与前期的系统分析和设计
参与者：
- 在系统之外，通过系统边界与系统进行直接有意义交互的任何事物
- 参与者一定是直接并主动向系统发出动作的
- 参与者一定是能够从系统获得反馈的
- 如何识别用例
- 选择系统边界
- 确定主要参与者
- 确定每个主要参与者的目标
- 定义满足用户目标的用例，根据其目标对用例命名
- 用例描述
- 命名
- 摘要
- 非正式
- 详述
域模型和类图
-
抽象
从众事物中抽取出共同的、本质性的特征，而舍弃其非本质的特征 关键抽象就是构成问题领域词汇部分的类和对象，其很重要：- 强调与系统设计有关的实体
- 排除系统外部多余的实体
- 关键抽象会成为分析模型中的类
-
概念类
描述现实世界的实体与概念,重点反映现实世界问题域如何找到概念类：
- 重用和修改现有模型
- 使用分类列表
- 确定名词短语
-
领域模型
对领域内的概念类或现实中对象的可视化表示
UML中是一组没有定义操作的类图PS：软件制品不属于领域模型，领域模型相当于概念数据模型
优点：降低OO建模之间的表示差异
- 候选关键抽象表格
- 候选关键抽象
所有从软件需求说明书中找出来的名词 - 排除原因
- 属性
- 同义词
- 无关类
- 标识类
- 选定的名字
- 候选关键抽象
- CRC分析法（识别关键抽象）
- 选择一个候选关键抽象
- 确定一个与其高度相关的用例
- 查看用例描述和系统功能需求来确定职责和协作的关系
- 用CRC卡记录抽取出来的关键抽象
- 更新候选关键抽象表格
- 类图
用来表达业务领域或系统内部的静态结构
- 建立领域模型
- 识别概念类
- UML定义类和属性
- 定义关联名和角色名
- 定义并记录关联重数
- 定义并记录关联方向
交互图
- 交互图
- 顺序图
按时间顺序描述对象的交互，强调了消息发生的时间顺序 - 通信图
围绕对象与对象之间的链接来描述对象的交互，强调对象的组织结构
- 顺序图
- 顺序图
- 类角色
代表对象在交互中扮演的角色 - 生命线
表示对象在一段时间内存在 - 激活期
执行操作的时期 - 消息
定义交互和协作中交换信息的类
- 类角色
- 系统顺序图（SSD）
阐述与所讨论系统相关的输入、输出事件而快速、简单创建的制品
- 责任分配原则
- 信息专家
- 创造者
- 低耦合
- 控制器
- 高内聚
- 多态
- 纯虚构
- 间接
- 受保护变化
- 通信图
是对象间消息的结构化视图 - 鲁棒性分析
通过分析用例规约中的事件流，识别出实现用例规定的功能所需的主要对象及其职责，形成以职责模型为主的初步设计 - 鲁棒图
- 边界对象
隔离系统内外，接收响应系统内外的信息 - 控制对象
控制对象执行期间复杂的逻辑 - 实体对象
保存问题领域中重要的信息
- 边界对象
- 鲁棒图原则
- 参与者只能与边界对象交谈
- 边界对象只能与控制体和参与者交流
- 实体对象也只能与控制体交谈
- 控制体既能与边界对象交谈也能与控制体交谈，但不能与参与者交谈
用例关系
- 用例关系
- 包含关系
当两个或多个用例中共用一组相同的动作，这时可以将这组相同的动作抽出来作为一个独立的子用例，供多个基用例所共享。因为子用例被抽出，基用例并非一个完整的用例，所以include关系中的基用例必须和子用例一起使用才够完整，子用例也必然被执行 - 拓展关系
- 泛化关系
泛化关系是一种继承关系，子用例将继承基用例的所有行为，关系和通信关系
- 包含关系
- 术语
- 具体用例
由参与者发起，完成了参与者所期望的完整行为 - 抽象用例
永远不能被自己实例化 - 基础用例
包含其他用例的用例，或者是被其它用例扩展或者泛化的用例 - 附加用例
被其他用例包含的用例，或者扩展、泛化其它用例的用例
- 具体用例
- 分包
- 参与者
- 主题
- 发布情况
- 开发团队
- 分析类和设计类区别
- 分析类高于设计实现
- 分析类高于语言实现
- 分析类高于实现方式
- 设计类是系统实施中一个或多个对象的抽象，应取决于实施语言
-
依赖关系（弱）
是类与类之间的连接，依赖总是单向的
- 使用依赖
- 抽象依赖
- 授权依赖
- 绑定依赖
- 关联关系（强）
是一种结构关系，是指一个类的对象和另一个类的对象之间的关系（具有多重性） - 泛化关系
一般与特殊的关系 - 抽象方法
没有方法体的方法 - 抽象类
包含抽象方法的类，不能直接创建对象 - 保护等级
面向对象设计原则
- 设计目标
- 可拓展性
- 灵活性
- 健壮性
- 可插入性
- 好的设计
- 容易理解
- 容易修改和拓展
- 容易复用
- 容易实现与应用
- 简单、紧凑、经济适用
- 坏的设计
- 僵化（刚性，难以修改，牵一发而动全身 ）
- 脆弱（易碎，牵一发而肝胆俱裂 ）
- 牢固（无法分解成可移植的组件 ）
- 粘滞（修改设计代价高昂 ）
- 不必要的复杂
- 不必要的重复
- 晦涩（不透明，很难看清设计者的真实意图 ）
- 面向对象设计原则
- LSP（Liskov替换原则）
子类对象必须可以替换基类对象 - OCP（开放-封闭原则）
软件实体（类、模块、函数等）应该是可扩展的，但是不可修改的 - SRP（单一职责原则）
就一个类而言，应该仅有一个引起它变化的原因 - ISP（接口隔离原则）
客户不应该依赖他们用不到的方法，只给每个客户它所需要的接口 - DIP（依赖倒置原则）
- 高层模块不应该依赖于低层模块
- 抽象不应该依赖于细节，细节应该依赖于抽象
- 针对接口编程，不要针对实现编程
- LoD（迪米特法则）
一个类对另一个类的了解越少越好
- LSP（Liskov替换原则）
- 启发式原则
- 任何变量都不应该拥有指向具体类的指针或者引用
- 任何类都不应该从具体类派生
- 任何方法都不应该改写其任何基类中已经实现的方法
-
设计模式
- 优秀的设计范例
- 优秀设计方案中发现和总结出来的经验
- 是实践中反复出现的设计问题的优秀解决方案
要素：
- 名称
- 问题
- 解决方案
- 效果
基本思想：
- 适应变化
- 松耦合
- 针对接口编程，而非针对实现编程
- 继承、组合、委托、多态、参数化
-
GRASP（通用职责分配软件模式）
作为设计模式来描述对象设计和职责分配的基本原则模式：
- 创建者
- 信息专家（将职责分配给具有完成该职责所需信息的那个类）
- 低耦合
- 控制器
- 高内聚
- 不要给一个类分派太多的职责，在履行职责时尽量将部分职责分派给有能力完成的其它类去完成
- 不相关的职责不要分派给同一个类
- 多态
- 纯虚构
- 间接性（避开两个或多个事物之间直接耦合）
- 防止变异（使内部的变化或不稳定性不会对其他元素产生不良影响）
- 控制器模式
- 常见缺陷是分配的职责过多，这时，控制器会具有不良(低)内聚，从而违反了高内聚的原则
- 正常情况下，控制器应当把需要完成的工作委派给其它对象，控制器只是协调或控制这些活动，本身并不完成大量工作
GoF设计模式
- 适配器模式
问题：如何解决不相容的接口问题，或者说如何为具有不同接口的相似组件提供一个稳定的接口
解决：通过一个中间的适配器对象，使一个组件的原有接口转变成另一个接口 - 工厂模式
问题：谁有责任创建对象
解决：创建一个纯虚构对象——工厂 - 策略模式
问题：如何设计变化但相关的算法或政策
解决：在单独的类中分别定义每种算法/政策/策略，并且使其具有共同接口
