OO系统分析员之路 笔记1

1,用例分析的首要目标不是要弄清楚某项业务是如何一步一步完成的，而是要弄清楚有多少参与者？每个参与者都做什么？业务流程分析则是后续的工作 了。其次，用例简直就是为OO而生的，其思想完美的符合OO。用例分析方法试图找到问题领域内所有相对独立的参与者和事件，并把业务流程当成是这些参与者 和事件之间的交互结果（在UML用活动图或序列图来描述）
2,笔者认为软件复用可以分为三个层次，最低层次的复用是代码级 复用，这是由OO语言特性提供支持的，例如继承，聚合，多态；较高层次的复用是组件级复用，这是由设计模式提供支持的，例如Factory模式, Builder模式；最高层次的复用则是服务级复用，这在很大程度上是由应用服务器和通讯协议来提供支持的，例如最近炒得火热的SOA（面向服务的应用） 架构。用例分析的好坏也许对代码级和组件级的复用影响不太大，但对服务级的复用影响却是巨大的
3,如果你的分析习惯是在调研需求时最先弄清楚有多少业务流程，先画出业 务流程图，然后顺藤摸瓜，找出业务流程中每一步骤的参与部门或岗位，弄清楚在这一步参与者所做的事情和填写表单的结果，并关心用户是如何把这份表单传给到 下一个环节的。那么很不幸，你还在做面向过程的事情。
如果你的分析习惯是在调研需求时最先弄清楚有多少部门，多少岗位，然后找到每一个岗位的业务代表，问他们类似的问题：你平时都做什么？这件事是谁交办的？做完了你需要通知或传达给谁吗？做这件事情你都需要填写些什么表格吗？....那么恭喜你，你已经OO啦！
4,用例分析系列中所有的工作，都是系统分析员做的，架构师不做这些工作。但这些工作的成果是架构师工作最主要的输入之一
5,系统分析员可以完全不懂计算机知识。他是领域专家，是行业顾问，或者有着对陌生问题领域敏锐的视角和极强的总结，归纳能力。能够把客户分散的，杂乱的，矛盾的需求整理成为完备的，自洽的，有弹性的结构，并且能够与客户共同探讨。
6,架构师是计算机专家，软件的行家里手。需要深入了解各种各样的软件结构，应用模式，中间件，服务器，甚至硬件知识...具备这么全面的知识目的是为接下来 的开发工作定下基调。根据需求规模，应用环境要求，客户特殊要求，应用程序特性等，再根据公司的基本情况，来选择或决定技术路线，中间件，开发工具等。为 开发定下基调，大的架构。小公司，中，小型项目我个人意见是根本用不到架构师这个角色的，顶多一个高级设计师把握整体框架就行了。架构师还要高于高级设计 师，只有当一个项目或产品大到需要很多个开发组，产品由很多个可独立的组件组成的时候，架构师才有意义
7,需求分析中的各个阶段要描述和分析的目标不同，为表达不同的视角和分析目标，需要使用不同的用例类型。笔者的观点是，用例类型的区分是为了形式上的统一，但用例类型既然可以自定义，它就是一个很灵活的用法，不必墨守成规，大可在工作中根据实际情况定义适合自己项目特点和软件过程的用例类型。不过，默认的用例类型已经几乎可以满足需求分析的各个阶段，自定义的必要性并不大，并且UML的意义就是使用统一的形式描述需求，因此最好使用默认的类型
8,说到需求分析阶段，那么需求分析都有些什么阶段呢？一般来说，需求分析要经过业务建模，用例分析和系统建模三个阶段才能完成需求工作
9,业务建模的目标是通过用例模型的建立来描述用户需求，需求规格说明书通常在这个阶段产生。这个阶段通常使用业务用例和业务用例实现两种类型；
10,用例分析是系统分析员采用OO方法来分析业务用例的过程，这个阶段又称为概念模型阶段。这个阶段通常使用无类型的用例。用例分析是一个过渡过程，但笔者认为其非常重要，业务架构通常在这个阶段产生
11,系统建模是将用户的业务需求转化为计算机实现的过程。这个阶段通常使用无类型的用例和用例实现两种类型。系统范围，项目计划，系统架构通常在这个阶段形成雏形（在系统分析阶段确定）。
12,所谓business usecase，是用来描述用户原始需求的，它的含义是站在用户的角度，使用用户的业务术语来描述用户在其业务领域所做的事情。业务用例命名，描述都必须采用纯业务语言，而不能出现计算机术语。因为业务模型是系统分析员与用户讨论需求，达到一致理解的基础，必须使用用户熟悉的，不会有歧义的专业术语以避免系统分析员与用户对同一事件的理解误差。business usecase realization是达到需求可追溯要求的一个连接点，是用户在其业务场景中如何做这一件事的载体
13,用例分析阶段，用例主要是从 业务模拟的概念上，从OO的视角来分解、组合业务用例，粗略的建立一个业务架构。而在系统建模阶段，用例主要是从计算机视角描述需求，规定开发范围，作为项目计划的依据，为系统设计做准
14,在业务建模阶段，用例的粒度以每个用例能够说明一件完整的事情为宜。即一个用例可以描述一项完整的业务流程。这将有助于明确需求范围。例如取钱，报装电话，借书等表达完整业务的用例，而不要细到验证密码，填写申请单，查找书目等业务中的一个步骤。在用例分析阶段，用例的的粒度以每个用例能描述一个完整的事件流为宜。可理解为一个用例描述一项完整业务中的一个步骤。需要注意的是，这个阶段需要采用OO方法，归纳，抽象业务用例中的概念模型。例如，宽带业务需求中有申请报装，申请迁移地址用例，在用例分析时，可归纳和分解为提供申请资料，受理业务，现场安装等多个业务流程中都会使用的概念用例。在系统建模阶段，用例视角是针对计算机的，因此用例的粒度以一个用例能够描述操作者与计算机的一次完整交互为宜。例如，填写申请单，审核申请单，派发任务单等。可理解为一个操作界面，或一个页面流
15,用例粒度的划分依据（尤其是业务用例）最标准的方法是一个用例的粒度是否合适，是以该用例是否完成了参与者的某个目的为依据的。这个说法比较笼统，也比较难以掌握。，举个例子，某人去图书馆，查询了书目，出示了借书证，图书管理员查询了该人以前借阅记录以确保没有未归还的书，最后借到了书。从这段话中能得出多少用例呢？请记住一点，用例分析是以参与者为中心的，因此用例的粒度以能完成参与者目的为依据。这样，实际上适合用例是：借书。只有一个，其它都只是完成这个目的过程--这里讨论的用例指的是业务用例--这个例子是比较明显的能够区分出参与者完整目的的
16,一个大型系统和一个很小的系统用例粒度选择会有较大差异。这种差异是为了适应不同的需求范围。比如， 针对一个50人年的大型项目应该选择更大的粒度，如果用例粒度选择过小，可能出现上百甚至几百个业务用例，造成的后果是需求因为过于细碎和太多而无法控制，较少的用例有助于把握需求范围，不容易遗漏。而针对一个10人月的小项目应该选择小一些的粒度，如果用例粒度选择过大，可能只有几个业务用例，造成的后果是需求因为过于模糊而容易忽略细节。一般来说，一个系统的业务用例定义在多于10个，少于50个之间，否则就应该考虑一下粒度选择是否合适了
17,不论粒度如何选择，必须把握的原则是在同一个需求阶段，所有用例的粒度应该是同一个量级的。这应该很好理解，在描述一栋建筑时，我们总是把高度，层数，单元数等合在一起介绍，而把下水道位置，插座数量等合在一起介绍。如果你这样介绍一栋楼：这栋楼有10层，下水道在厨房东南角，预留了15个插座，共有5个单元，听众一定会觉得云山雾罩，很难在脑子里形成一个清晰的影像。