ü 学习总结 Part 1 ---读书笔记
一、UML基础
将现实生活中的实际问题抽象化。
面向对象存在的问题：
（1）对象是怎么被抽象出来的，为什么要这样的抽象（why）
（2）对象可以任意的组合，如何作何才能更好的满足现实世界的需求（how）
（3）如何更好的理解对象所表达的含义（what）
现实世界和对象世界之间的精髓在于抽象：需要一种把现实世界映射到对象世界的方法；一种从对象世界描述现实世界的方法；一种验证对象世界行为是否正确反映了现实世界的方法。
UML是一种建模用的语言，定义了一些建立模型所需要的、表达某种特定含义的基本元素（元模型，如类，用例）。还定义了元模型互相之间关系的规则，以及如何用这些元素和规则绘制图形以建立模型来映射现实世界。
二、实战篇之准备工作
软件项目总是从了解问题领域开始的。
1. 了解问题领域
（1）了解业务概况：大体知道所接触的领域基本业务有哪些。包括项目背景调查、业务前景分析、业务可行性分析、技术可行性分析等。
（2）整理业务目标：也就是最终系统要实现的功能，目标是什么。一般情况下通过业务概况的了解整理业务目标。
2. 做好涉众分析
（1）涉众：业务建模的第一步：发现和定义涉众。凡是与项目有利益关系的人和事都是涉众。
（2）发现和定义涉众：（业主—系统建设的投资者，业务提供者—业务范围、业务模式和业务规则的制定者，业务管理者—实际管理和业务监督的人员，业务执行者—底层业务操作人员，第三方—与项目有关，但是并非业务方的人和事，承建方，相关法律法规，用户…）
业务提供者的期望是系统建设的最高纲领。
不同涉众人群关注的角度不同，业主可能更关心回报。业务提供者可能更关心整体的数据统计。业务管理者可能更关心如何实现他们的管理职能。等
（3）涉众分析报告：一份完整的涉众分析报告包括：
涉众概要（涉众的基本信息和主要角色），
涉众简档（描述涉众在系统中承担的职责），
用户概要（使用系统的用户说明），
用户简档（将典型的用户代表进行描绘）
消费者统计（系统预期使用的人群和他们的特点）
涉众分析报告为我们获取需求指明了方向，规划业务范围、规划优先级和规划需求层次的工作，明确了什么时候对什么涉众的什么期望进行了调研。
3. 规划业务范围
项目中并不是所有的业务目标和涉众期望都要满足，根据项目周期、项目成本、可行性分析等，权衡项目可以容纳的业务范围。
规划业务范围可以从规划业务目标、涉众期望开始。
（1）规划业务目标
（2）规划涉众期望
小结： 本章几节的主要重点是通过对业务领域的了解，明确业务目标，提起涉众，根据业务目标与涉众的期望，确定系统的业务范围。
三、实战篇之获取需求
1. 定义边界
通过业务目标来划分边界。
每个业务目标都可以用来定义边界。每个边界都有不同的涉众参与，也会有不同的用例出现。
获取业务用例必须是以达到业务主角的完整业务目标位标准。
2．发现主角
根据涉众概要得到涉众列表，根据边界定义得到边界外的涉众。用主角的定义去审查这些备选的涉众在此边界内的行为模式，从中找出符合定义的涉众，成为业务主角。
只有直接与系统交互的涉众才能被称为业务主角，一个涉众可能演变多个业务主角。
（1）业务主角与涉众的区别在于，业务主角直接与系统进行交互，而涉众是系统利益的相关者。往往涉众的代理是业务主角。
（2）业务主角总是在边界之外的，只有边界外的事物才有权向边界代表的系统提出要求。
（3）业务主角必须贡献于业务目标。
（4）业务主角用来分析业务，但是不应过分的虚拟化和抽象化。
3. 获取业务用例
对于系统来说，每一件事情便是一个业务用例，每个业务用例都体现了业务主角的一个系统期望，而所有这些期望则完成边界所代表的业务目标。
可以通过以下几点作为引导：期望，内容，目的，结果。
发现和定义业务用例的目的有两个：
一个是了解客户的业务构成：从结构上，整体上了解业务构成。
另一个是确定业务范围：对项目管理有用，估算工作量。
4. 业务建模
（1） 建立业务模型
一个完整的业务模型包括：业务用例视图，业务用例场景，业务用例规约，业务规则，业务对象模型，业务用例实现视图，业务用例实现场景，包图。
1）业务用例视图：在获取业务场景时基本完成。
2）业务用例场景：用来描述该业务用例在该业务的实际过程中是如何做的，绘制业务用例场景可以使用：
活动图：强调参与该业务的各参与者的职责活动。直观描述客户的业务流程，获取关键概念：职责和活动。
时序图：强调业务完成时间。
协作图：强调业务参与者之间的交互过程。
（2）业务对象模型
1）业务用例实现视图
业务用例表达了客户的实际业务，而业务用例实现则表示一个业务用例一个或多个实现方式。
2）业务用例实现场景
业务用例场景用于说明业务怎样执行，而实现机制就是在业务用例实现场景中描述。
3）包图
在业务建模中，包图更多的用于信息分类（业务用例分类，参与者分类等）
ü 学习总结 Part 2 ---回答问题
1. 如何准确的根据业务需求获取到业务用例，业务用例的主要包括哪些内容？如何分析出这些内容？
我的理解：
（1）通过对业务需求的学习理解，确定业务目标，提取相关涉众，根据业务目标和涉众明确业务范围，定于边界。从边界中不同的涉众获取不同的业务用例。
（2）业务用例主要包括：业务用例体现了业主在系统中要实现的功能的期望。简单的说就是某一类人在系统中通过做某一件事达到某种目的。所以我觉得业务用例中主要包括业务主角和业务目标。
提取业务目标：通过对业务概况分析出业务目标，并根据目标划分边界，用于提取涉众。
提取涉众主角：定义完边界后，所有边界外，与系统有利益关系的对象都可以定义为潜在的涉众。可以通过业主、业务提供者、业务管理者、业务执行者、第三方、承建方，相关法律法规、用户的指引进行涉众分析，获取涉众，从中找出直接与系统进行交换的涉众形成业务主角。
2. 业务用例场景是什么？业务用例场景与业务用例是什么关系？用什么方式能清晰的描述业务用例场景？
我的理解：
（1）业务用例场景：用来描述某一个用例在该业务的实际过程中如何实现的。
（2）业务用例 --1---N-- 业务用例场景 --1---1-- 业务用例实现 --1---N--业务环节
（3）书中介绍了3种描绘业务用例场景的方法：
活动图：强调参与该业务的各参与者的职责活动。直观描述客户的业务流程，获取关键概念--职责和活动。
时序图：强调业务完成时间。用于描述对象之间按一定的顺序互通消息而完成一个特定的目标。
协作图：强调业务参与者之间的交互过程。
ü 学习总结 Part 3 ---个人心得
通过对八九章的阅读，主要学习了业务需求的分析过程和方法。下面说下自己的心得：
我们在分析某些问题的时候，经常会使用5W理论作为指引，业务需求的分析也同样受用。
Ø WHAT：了解需求领域，业务概况
我觉得软件的实现过程是将现实事物进行了抽象化，把现实中的一些人来做的事情通过计算机来实现，简单的说软件就是一个工具，就像计算器一样，工具的好坏取决于它能不能帮助人们解决问题，也就是能不能满足人们的需求。所以第一步我们首先了解问题领域，看看有哪些问题需要我们来解决。
如何了解问题领域我在最后的问题中也提出了疑问，我个人的理解是项目负责人会在项目的前期进行项目背景调查，业务分析等。设计人员首先会通过业务需求总结了解实际的问题领域，其次就是项目的负责人对需求领域进行传达，必要的时候由领域的专业人员进行业务的指导。
Ø WHY：业务目标，为什么要这样做，最终实现的目的是什么
人们常说问为什么是一门学问，多问些为什么会更好的更准确的处理问题。对业务概况有了初步了解之后，我们就会通过业务需求整理业务目标，明确一些大的方向。
Ø WHERE：业务范围，从哪些范围，涉众的期望中提取需求
并不是所有的业务目标都要满足并实现，需要根据实际的情况进行分析和决定，所以业务范围的制定就是去除那些不打算完成或满足的涉众需求。
但是业务范围并不是最终的范围，从整体上看这个范围还是比较的模糊，所以我们还需要根据业务目标划分边界。每个业务目标都可以用来定义边界。每个边界都有不同的涉众参与，也会有不同的用例出现。这样提取的用例才更准确。
Ø WHO：系统中相关的人，涉众
软件的最终目的就是给人带来方便，为人解决实际生活中的问题，很多事情都是以人为本，软件开发也是一样。所以接下来要做的就是涉众的分许与提取。书中给出涉众的定义是：与要建设的业务系统相关的一切人和事。但是我觉得这里应该更准确的说就是一切人或物，任何事都应该有执行者，而这个执行者才是涉众。
如何发现和定义涉众，书中提到了很好的方法。我觉得基本上可以满足大多数业务场景的需求。可以通过业主、业务提供者、业务管理者、业务执行者、第三方、承建方，相关法律法规、用户的指引进行涉众分析，获取涉众。
但是涉众不等同于业务主角，业务主角也是在涉众的基础上进行细分。更准确的提取“人“的概念。只有直接与系统交互的涉众才能被称为业务主角，一个涉众可能演变多个业务主角。
涉众和业务主角的一些区别在笔记中有提到，这里就不多说了。
Ø WHEN：什么时间做
在获取业务需求时，似乎没有过多的强调时间上的概念，而是更注重目的性。但是在具体的用例分许和流程中，还是要强调哪个时间点应该做哪些事情的。
Ø 小结：获取业务需求的最终产物是获取业务用例。业务用例的获取可以让我们了解客户的业务构成：从结构上，整体上了解业务构成。同时确定业务范围：对项目管理有用，估算工作量。
ü 学习总结 Part 3 ---疑惑问题
Q：了解业务领域的方法有哪些，对于一个不是很熟悉的领域，如何能快速准确的理解业务。
Q：业务模型和业务对象模型有什么样的本质区别。