大象Thinking.in.UML第二版读书笔记第6、7章：统一过程核心工作流简介

6.1业务建模工作流程

先启阶段，主要用到业务用例模型，概念用例模型和领域模型

6.1.1工作流程

6.1.2 活动机和工件集

完整的业务建模工作完成后应当得到如下工件集

6.1.3 业务建模的目标和场景

6.1.3.1场景#1-----组织图
客户的组织机构图

6.1.3.2场景#1-----领域建模
如果程序的主要目的是管理和提供信息，在业务级别上构件该信息的模型，而不考虑该业务的工作流程。

6.1.3.3场景#1-----单业务多系统
一个业务建模工作成为数个软件工程项目的输入

6.1.3.4场景#1-----通用业务模型
供多个组织使用的应用程序

6.1.3.5场景#1-----新业务
全新的业务，业务建模成为必要

6.1.3.6场景#1-----修改
业务经营方式彻底修改（重建）

6.2系统建模工作流程

6.2.1工作流程

系统建模处于先启和精化阶段。

• 先启阶段侧重分析问题和理解涉众需求
• 精化阶段侧重定义系统和改进系统定义。管理系统规模和管理需求变更的活动贯穿项目始末。
  

6.2.1.1分析问题
通过了解问题及涉众的最初需要，并提出高层解决方案来实现。对“始末是面临的实际问题”和“谁是涉众”等为题达成一致

6.2.1.2理解涉众需求
可以使用访谈，集体讨论，概念原型设计，问卷调查和竞争分析等

6.2.1.3定义系统
解释涉众需求，并整理成对构建系统的意义的明确和说明。在系统定义的初期要确定：
需求构成，文档格式，语言形式，需求的具体程度、需求的优先级和雨季工作量、技术和管理风险以及最初规模

系统定义活动还可包括与最关键的涉众请求直接联系的初期原型和设计模型。系统定义的结果是用自然语言和图解方式表达的系统说明。

6.2.1.4改进系统定义
实际是系统的详细定义

6.2.1.5管理系统规模
对涉众的需求确定优先级，并对项目规模进行管理

6.2.1.6管理需求变更
管理变更包括建立极限，确定需要最终的重要依赖关系，建立相关项之间的可追踪性，以及变更控制等活动

6.2.2 活动集和工件集

同意过程定义了系统建模工作流程中的主要角色以及他们应当执行的活动。

6.2.2.1前景
商业前景，产品所具有的特征，涉众需求分析，雨季的目标客户，产品说明，产品要求等

6.2.2.2涉众请求
涉众对系统的需求，发现涉众，通过访谈，问卷，需求讨论会来手机涉众请求。

6.2.2.3需求属性
需求属性是一个管理工具，用来管理和最终每个需求在项目进行过程中的变化情况。如优先级变化，需求变更过程，进展情况等。

6.2.2.4软件需求规约
需求规格说明书

6.2.2.5用例示意板
用来描述界面是如何使用用例这一信息

6.2.3 系统建模的目标

• 与客户和涉众在系统的工作内容方面达成并保持一致
• 是开发人员清楚地了解系统需求
• 定义系统边界
• 为计划迭代的技术内容提供基础
• 为估算开发系统所需成本和时间提供基础
• 定义系统的用户界面，重点是用户的需求和目标。

6.3分析设计建模工作流程

分析设计建模即我们所熟知的概要设计和详细设计过程。主要使用分析模型和设计模型来完成分析设计过程。她主要在精化阶段实施。

6.3.1工作流程

分析和设计合并为一个流程

6.3.1.1定义和改进架构
一下图形略复杂，实际未必这么复杂

6.3.1.2分析行为
分析用例场景，使用分析类或设计类，并结合架构来实现用例场景的过程

6.3.1.3设计组件(构件Component)
组件是实施单元，他们被安放在架构的某一个位置然后由架构驱动执行。其实，组件的意义在于复用。

实时响应的组件和非实时响应的组件

6.3.1.4设计数据库
在面向对象的设计中，关系型数据库仅是用来持久化数据的一种方式，并非设计的重心，重要的是对象设计。

6.3.2 活动集和工件集

6.3.3 分析设计的目标

目的：
将需求转换为未来系统的设计
逐步开发强壮的系统架构
使设计适合于实施环境，为提高性能而进行设计

6.3.4 推荐的分析设计工作流程简介

6.4实施建模工作流程

实施模型将开发工作分成许多工作包，因而可以写作生产这些工作包，然后组装他们以形成最终系统。

6.4.1工作流程

6.4.2 活动集和工件集

6.4.3 推荐的实施建模工作流程简介

按照用例的优先级，采用多个迭代的方式来实施项目的

作者建议：采用实施模型的思想，以用例为基础来分工，因为一个用例就是一个可独立执行的单元，所以每一次迭代的目标可定义为实现哪些用例。分工是最先考虑的事哪些逻辑组件（模块、子系统、库）可以实现这些用例。为了快速搭建出一个可运行的系统，可以只实现一个类的部分功能。设置所谓的核心模块也不需要最先开发完成，只需要开发出于实现用例先关的那一部分。

下面的文字，作者很好的诠释了一个敏捷开发的思路。

第七章：迭代式软件生命周期

迭代不是里程碑
每一次迭代都有需求、分析、设计、实施。每一次迭代的结果都能得到一个可运行的系统。

迭代中，需求人员总能够从众多需求中发现对客户来说最为关键，或者最为复杂，或者嘴不稳定的那部分需求。

迭代开发能够将风险控制在可接受的范围。