概述
1. 开发过程粗略解析。软件开发要做的两件事情：需求（做什么）与设计（怎么做）
2. 开发过程详细解析：业务建模、需求||||分析、设计、实现、测试。
a) 业务建模是可以略过的
b) 分析跟设计可能合并
3. 所有开发方法都是要满足上面的流程。例如之前的瀑布模型，新生的RUP，XP和MS方法。但目前新的方法都是用例驱动、架构为核心、迭代的。
4. UP中整个产品流程包括多个循环，每个循环包括多个阶段，每个阶段包括多个迭代，每个迭代对应多个工作流。先启阶段决定是否要可行，细化阶段完成架构，构建阶段完成大部分编码，移交阶段产生出货版本。每个迭代都会经过所有核心工作流，但侧重点不同。
5. 每次迭代的步骤：需求、分析、设计、实现、测试五个核心工作流。
6. 为了支持UP，一般使用UML。但UML不仅应用于UP。
7. 难点不在于怎么画，而在于画什么。
开发流程0：业务建模
1. 在8.pdf中
2. 目标：描述现实，帮助发现软件需求。业务流程就是业务用例。业务用例对业务执行者提供价值。什么是IBM？一堆价值流。
3. 并非必须，不一定和软件开发相关
4. 业务建模能帮助明确愿景。
5. 结果工件：业务用例模型和业务对象模型
6. 业务建模步骤：
a) 确定业务单元：包含大多数使用系统的人的组织。
b) 识别业务执行者
c) 识别业务用例。注意，业务用例必须是提供价值的。一般对应一个子系统，粒度很大。两条途径来识别。
d) 详细描述业务用例：使用活动图插入文字（+注释+标注基本路径）。
e) 建立业务对象模型
7. 活动图
起点、终点、活动、泳道、迁移和迁移条件、判定、并行、对象流。
8. 建立业务对象模型：现实生活中的人、事物和关系。包括业务工人和业务实体。
9. 业务模型到系统模型的改进点
a) 信息自动流转
b) 演绎复杂业务逻辑
c) 访问和操作业务实体
d) 自动工作
10. 业务模型到系统模型的可能对应
a) 业务用例->系统（子系统）
b) 业务执行者->系统执行者
c) 业务工人->系统执行者
d) 活动->系统用例
e) 业务工人、业务执行者、业务实体->实体类
开发流程1 需求
1. 2.pdf
2. 愿景：为何开发一个系统？愿景目标必须是可以度量的。
3. 需求的特点和对策：
a) 难捕获->从用户角度看问题
b) 易变化->合理的结构
4. 用例是满足上面两个条件的合理方法。用例文档就是需求文档。
5. 用例：有层次的需求组织形式，所以容易产生合理的结构。
用例 低精度，稳定
路径
步骤
补充约束 高精度，不稳定
6. 步骤：
a) 识别执行者
b) 识别用例
c) 书写用例文档
d) 通过关系整理用例
e) 用例的排序和分包
7. 系统执行者：在系统之外通过系统边界直接与系统进行有意义交互的任何事物。
a) 系统之外
b) 通过系统边界
c) 直接与系统交互
d) 有意义的交互
e) 任何事物
8. 用例实例是在系统执行的一系列动作，这些动作将生成特定执行者可见的价值结果。一个用例定义为一组用例实例。
a) 价值结果->有意义的目标
b) 系统执行->价值结果由系统生成
c) 执行者可见->业务语言，用户观点
d) 一组用例实例->用例的粒度
9. 用例命名：动宾结构，避免弱动词和弱名次。
10. 用例没有粒度，不要把步骤当作用例。尽量不要用CRUD为用例，因为它们一般不提供价值，过于在乎细节，是从数据库角度进行考虑的。多个用例也可能操作同样的数据，一个用例背后可能隐藏多个数据操作。如果确定为CRUD，则合并为管理***，可以把Create当作主路径，Read，Update，Delete当作其它可选的路径。不要牵涉界面细节。
11. 在“Patterns for Effective Use Cases" 一书中有这样一段话：
It is relatively easy to identify low-level transactions while it can be difficult to identify useful services. It is usually easier to describe the individual routine transactions that a system may provide than it is to discover what the user really wants to do with the system. Doing it the easy way often leads to the so-called ‘CRUD’ (Create, Read, Update, and Delete) style use cases. It is not unusual to see use cases with names like “Create Employee Record”, “Read Employee Record”, or “Delete Employee Record”. While such use cases may be technically correct, they do not capture what is valuable to the user. Is creating an employee record important, or do we they
really want to “Hire Employee”?
12. 每个用例只有一个主执行者。
13. 每个用例是否满足愿景？是否所有愿景都通过用例得到满足？
14. 书写用例文档。参看uctext.pdf文件。
a) 编号、名称
b) 执行者
c) 前置条件、后置条件
d) 涉众利益。涉众表示关心用例的人。
e) 基本路径
f) 扩展路径。
g) 字段列表、业务规则、非功能需求、设计约束。它们统称补充约束。
1) 字段列表：描述每个步骤地名次，包括内涵和外延。
15. 用例关系：（不重要）
a) 扩展：分离扩展路径。参看UC4。
b) 包含：提取公共路径，便于复用。
c) 泛化：同一业务目的的不同技术实现。可以用扩展替代。
开发流程2 分析类图
1. 4.pdf
2. 职能分配，从面向过程角度就是分解，从面向对象角度就是协作。
3. 用例通过分析和设计转换为类、对象、关系、职责、协作。用例是外观，后者是机理。
4. 对象具有状态、行为和标识。
5. 类：共享公用结构与行为的对象的集合。
6. 分析类图的步骤
a) 识别类及属性
b) 识别类之间的泛化
c) 识别类之间的关联
d) （注意，不分析行为）
7. 识别类和属性的方法：
用例—抽取à名次表—识别à类和属性，同时参考领域模型。
从用例的基本路径、扩展罗经和补充约束来获得。
8. 两种分析路线：实体驱动和职责驱动。
9. 审查类图：
a) 类的属性：什么的什么
b) 可能有冗余，但有时冗余是合理的
c) 处理复杂结构属性：如果1对1，可以在原类中展开；如果1：N，独立出去形成关联。
d) 属性是否对类的所有对象都有意义。如果不是，则分解只属于部分对象的属性到子类中。
10. 类的关系：
a) 泛化：集合关系，子类通过继承具有超类的特征
b) 关联：个体关系，对象通过组装具有其他对象的特征
11. 识别泛化的方法：A的对象总是B