目录
一.基本概念
- OOAD：Object Orient Analysis & Design，面向对象分析与设计。
- UML：Unified Modeling Language，统一建模语言（一种标准）。
- SDLC：Software Development Life Cycle ，软件生命周期（一种规范的、系统的软件开发方法）。
1.SDLC 软件生命周期
1.1 阶段
- 可行性分析 、需求分析和规范说明 、设计 、编码 、测试 、维护。
- 设计阶段：把 SRS 中指定的需求转换为编程语言能够实现的逻辑结构。
1.2 软件开发方法
- 根据剪裁 SDLC 的不同阶段 得到下面几种方法：
- 瀑布方法 、原型方法 、螺旋方法 、双赢螺旋方法 、增量方法。
1.3 瀑布方法
- 线性顺序 特点，最早使用的软件开发方法。
- 七个阶段：概念、开始、分析、设计、构造、集成和测试、实现和维护。
1.4 原型（演化）方法
- 迭代 特点，展示目标系统主要功能，在 需求收集和分析阶段 用该方法获得确切需求。
- 原型类型：抛弃型原型、演化型原型。
- 局限性：会让客户觉得好改，会让开发人员降低软件质量要求。
1.5 螺旋方法
- 线性顺序 + 迭代 特点，开发的软件是要以 不同版本发布 的情况，用螺旋方法较为理想。
- 六个阶段：客户沟通、制定计划、风险分析、工程、构造和发布、客户评价。
1.6 双赢螺旋方法
- 与螺旋方法的区别：开发团队和客户就 当前迭代需要包含的需求 展开讨论和协商，这样对双方都有利。
- 双赢螺旋方法一般用于 具有发布时间界限 的情形。
1.7 增量方法
- 软件需求被分解为不同的 功能单元，每个功能单元都在一次 增量 中实现。
- 每个增量的三个阶段：设计、实现、分析。
1.8 设计阶段的软件开发方法
- 面向功能方法： 以 模块 为中心，注重 软件功能。
- 面向对象方法：支持继承性、可重用性和数据封装、抽象和多态性。
1.9 多态性
- 多态性是根据运算符或函数的作用对象来以不同的方式使用它们的概念。
- 根据运算符的作用对象来以不同的方式使用它们称为 运算符重载。
- 以不同的方式使用函数称为 函数重载。
2.面向对象分析和设计（OOAD）在 SDLC 中的作用
- OO 方法并不是取代数据流图（DFD）图或实体关系图（ER图）等标准方法，它只是现有工具箱的补充。
- OOAD 是指根据对象、类、封装、继承、多态、抽象和动态绑定来分析需求以及设计软件系统。
- OOAD 是可应用到线性、迭代或增量方法的一种方法。
二.UML 关系图
1.UML 概述
1.1 统一建模语言 UML
- 是一种标准语言，用于创建描述软件系统的结构和设计的系统蓝图。
- 可用的 UML 工具主要有 Rational Rose、Jude、AgroUML 和 Poseidon 等。
1.2 工件
- 工件包括软件系统的需求、架构、用对象或接口表示的设计、源代码、测试、原型及软件系统的软件发行版。
- UML可以：指定工件、可视化工件、构造工件、记录工件
1.3 UML 构建块组成
- 基本的成分：包括 UML 的静态、动态、分组和注释组成部分。
- 关系：描绘 UML 模型各组成部分之间的关系。
- 关系图：以图形方式表示系统的各个工件。
2.UML 提供的关系图
- UML 关系图使用户能通过 各种成分的图形表示 看到软件系统，下面介绍十三种关系图：
- 用例关系图：描述系统执行的各种操作，包含用例、角色及其关系。
- 类关系图：表示一组类、接口及其关系。
- 对象关系图：表示类关系图的实例。
- 通信关系图：以 消息 的形式表示对象之间的交互。
- 序列关系图：以 按时间排列的消息 形式来表示对象之间的交互。
- 状态机关系图：显示了发生事件时类的反应。
- 活动关系图：活动代表类执行的操作，描绘从一活动到另一活动的控制流。
- 包关系图：表示软件系统的各个包以及它们之间的依赖性。
- 组件关系图：包或单独实体结合构成组件，描述各种组件及其依赖性。
- 部署关系图：显示网络上节点中的组件的物理分布。
- 时序关系图：表示对象一段时间里的状态和值的更改，经常用来设计嵌入式软件
- 复合结构关系图：表示分类器的内部结构和交互点，用来浏览通过通信链接协作的互连分类器的运行时实例。
- 交互概览图：表示交互关系图之间的逻辑交互及进程流，交互关系图包括：序列、通信、时序、交互概览。
3.四种建模技术
- 需求建模：使用 用例关系图 描述需求
- 静态建模：使用类、对象和复合结构关系图 来描述软件系统的 静态成分
- 动态建模：使用以下关系图来描述 静态成分的行为：活动关系图、状态机关系图、通信关系图、序列关系图、交互概览图、时序关系图
- 架构建模： 使用以下关系图通过多个层（如，表示层、业务层和资源层）来描述软件系统的架构： 包关系图、构件关系图、部署关系图
4.软件系统架构
- 软件系统的构架：模型里 静态元素 和 动态元素 的安排。
- 软件系统的各个视图包括：
- 用例视图： 表示系统为每个项目提供的 功能。
- 设计视图：侧重于系统的 静态和动态表示。
- 过程视图： 表示在给定的时间段内系统中执行的各种进程。
- 实施视图：表示物理系统，包括组成系统所需的文件和组件。
- 部署视图：表示将执行软件系统的硬件组件。
5.UML 在 SDLC 中的作用
- 测试阶段要用 用例关系图，用例关系图描述测试用例，系统根据该用例进行测试。
- Visio 是一个 Microsoft 工具，它使用 UML 使 OOAD 更简便，有助于建立由 UML 定义的所有关系图。
6.统一开发过程（RUP）
- RUP 是软件开发过程中的指导者，是一种方法学。
- RUP 与 UML 完全兼容，与软件开发工具 Rational 集成。
- RUP 生命周期：起始阶段、细化阶段（分析问题域、风险）、构造阶段、转换。
- RUP 软件开发过程中的最佳实践：迭代开发、基于组件开发、建立可视化模型、控制软件更改、管理需求、检验质量
三.定义系统
- 定义新软件阶段：
- 分析问题
- 确定项目干系人
- 确定、收集、组织并记录需求
1.分析问题
- 构建系统行为和功能模型（确定现有系统的问题及未来系统目标）的建模技术：业务建模、系统建模。
1.1 业务建模
- 业务建模： 是 可视化建模 技术，描述企业流程的 工作方式 以及 每个人员在流程中的角色。
- 业务建模构造 及其相应的 UML 表示法和功能：
- 业务建模提供两个模型来分析现有系统：
- 业务用例模型：业务执行人 和 业务实体 的详细交互。
- 业务对象模型：用 业务角色 和 用例 来表示 现有流程的功能。
1.2 系统建模
1.2.1 系统建模概述
- 系统建模：显示 目标软件系统与其环境 在 层次结构的 不同层上的 信息流
- 可用于系统建模的 业务建模结构：
- 业务用例：确定组成目标解决方案的子流程
- 业务角色：映射到系统模型中的角色。
- 业务执行人的行为：查找系统用例并定义新系统模型的功能。
- 业务实体：当创建类关系图时，有助于查找 实体类。
1.2.2 创建系统建模的用例关系图
- 用例关系图：目标系统的 用例和角色交互、用例和角色关系（关联、泛化）
- 用例包含信息：名称、小结、基本事件过程、可选路径、异常路径、触发器、假设、前置条件、后置条件、业务规则、非功能性需求、作者、日期
- 用例应该：向角色提供值、提供所需功能的描述（就是对需求建模）
- 系统角色：与系统交互、影响系统功能的 外部实体
- 系统角色包括：主要角色（直接与系统交互，启动用例）、次要角色（不与系统交互、启动主要角色与系统交互）
2.确定项目干系人
- 记录项目干系人的需求时，要记录的功能属性：状态、排名（轻重缓急）、工作量、不确定性、稳定性（需求是否易变）、目标发行版（每一版要更新的内容）、分配给（组内人员分工）、源
3.确定、收集并组织记录需求
- 需求管理阶段：需求收集、需求分析协商、需求规范、需求验证
3.1 需求收集
3.1.1 需求收集内容
- 评估目标软件系统的经济、技术和运行可行性。
- 确定指定现有过程的需求和专用术语的项目干系人和最终用户
- 确定目标软件系统的领域约束
- 识别需求获取的方法
- 识别模糊需求
- 识别琐碎的需求
3.1.2 需求收集技术
- 会见项目干系人
- 举行集体讨论会
- 准备调查问卷
- 观察现有流程
- 预约专家
3.1.3 故事板技术
- 正式开发之前，在纸上设计用户界面
- 可分为：被动式（漫画文字）、主动式（视频动画）、交互式（快速原型）
3.2 需求分析协商
- 此过程定义和表示了软件行为
- 需求分类：功能性（系统的功能及特征）、非功能性（不是功能但不可缺少的特质）
3.3 需求规范
- 将 分析阶段提出的需求 转换成可以实现的 技术需求。
- 软件需求规范 (SRS) 是在 分析阶段 最后生成的文档，包含收集到的最终需求。
3.4 需求验证
- 此阶段 确定并去除了模糊需求
- 核对表：确保客户需求付诸实践，确保开发人员理解需求
四.从需求到设计的转化
1.设置系统边界和项目范围
- 项目范围包括：项目功能（交付的产品目标）、项目资源（开发项目的资源）、可用时间（规定完成时间）
1.1 创建项目范围
- 系统边界 可以基于 用例优先级别，确认 SDLC 中包含的迭代
- 在实现系统设计之前，需要 创建项目范围
- 细化医院管理系统的用例：
- “安排预约”和“修改日程” 需要 执行“检查日程”，因此，“检查日程” 包含 在“安排预约”和“修改日程”中
1.2 设计阶段实现用例
- 在设计阶段，需要了解 如何在实现阶段使用类、接口和子系统，进而实现用例功能，这称为实现用例
- 协作：类、接口和子系统的集合，在 UML 中，使用 协作 相互交互，对用例实现建模，协作包括：
- 结构：描述系统的 静态结构，包括用例中类、接口和子系统的 角色
- 行为；描述系统的 动态结构，指定了用例类、接口和子系统间的 交互
1.3 使用用例生成测试用例
- 设置系统边界：要在每个迭代中唯一描述用例和角色的功能，这个范围包括 在指定时间内 完成项目的 所需资源
- 确定系统边界的步骤：
- 以医院管理系统的 系统边界用例关系图 为例：
- 第一个迭代用例：安排预约、修改日程：
- 第二个迭代用例：安排预约、修改日程、打印处方：
2.细化系统定义
- 细化系统定义，应细化系统中 确认的 用例
- 细化用例步骤：
2.1 建立用例之间的关系
- 扩展：通过 附加行为 获取 其它用例 扩展 现有用例
- 包含：一个用例功能 包含在 另一个用例功能之内
2.2 确认用例实例和执行条件
- 确认每个用例实例的执行条件，然后指定执行条件状态，执行条件状态可以是：
- 有效 (V)
- 无效 (I)
- 不适用 (N/A)
2.3 跟踪需求
- 需求可追溯性（需求跟踪）：将 客户需求 与 软件系统功能 映射（系统满足客户各种需求）
- 执行需求可追溯性（需求跟踪），需要使用：
- 后向：包括从 测试阶段 至 需求收集阶段 跟踪需求
- 前向：包括从 需求收集阶段 至 测试阶段 跟踪需求
2.4 迭代用例模型
- 可以为 迭代模型 创建以下用例：
- Facade 用例：用三个术语描述软件系统：信息、输入与输出
- Filled 用例：描述 角色与系统的交互
- Focused 用例：包含 Facade 用例 没有提供的 详细信息
