北京umlchina实训第一天笔记

一、愿景（就是老大的涉众利益）

愿景定义：在老大看来，购买（开发）这个系统的目的。（是改善组织的指标，不是具体能做什么事）

    要点：①必须来自老大②必须指出度量指标

老大定义：购买这个系统的人或是群体代表，并不一定是使用这个系统的人。

二、业务建模

目的：把视角从系统转向组织，看看系统能给组织带来什么好处。

用例一定是能卖的，是卖给外面执行者的

步骤：

①    选定业务组织（愿景所波及的需要改进的）

从外部看：价值的集合－－业务用例图

从内部看：系统的集合－－业务序列图

业务组织的改进点：

①     改善信息的流转（尽量让信息自动的流转）

②     封装人脑的信息

注意：业务组织是名词，不是动词，也不是一个系统，是实实在在的组织单位

②    画业务用例图（一定要以选定的业务组织为研究对象）

业务执行者：在组织之外和组织交互的人或组织（业务执行者一定要看以什么为研究对象）

业务工人：在组织内部

业务实体：组织内部的非人实体

用例的选取基本点一定要是为业务执行者提供价值的

业务流程就是业务用例的实现，业务用例（对外的价值）基本不会变化，内部的实现每次会变化一部分

注意点：①业务用例只针对业务执行者 ②内部活动不是业务用例

③    画现状业务序列图   

序列图是面向对象的，活动图是面向过程的，活动图往往只表现事件，序列图则表现责任和协作

业务序列图上消息的名字代表的是责任和目的，是A请求B做某事，消息的方向是责任委托，不是数据流动

在可能的改进点处画得细一些，这些改进点可能在扩展路径中

特殊点：画业务序列图时可以把时间看成特殊的业务实体

注意点：只画领域相关的系统，比如讲课系统中需要向公司系统请求发布讲座消息，不要把公司系统画进序列图中，可以写成公司系统接口

④    画改进业务序列图

业务序列图的改进点：

①     尽量让信息自动的流转

②     封装复杂的业务逻辑

③     访问和操作业务对象（涉及到什么业务对象？需要系统管理起来吗？）

使用“阿布”思考法：在寻求系统的改进时不要考虑资金等方面的限制，但是在真正选择实现方案时再根据现有的实力确定最好的解决方案

三、需求（需求要具体，设计要抽象，赚取差价）

① 画系统用例图

系统执行者定义：

在系统之外，透过系统边界与系统进行有意义交互的任何事物，有三点要注意，系统执行者是在系统外有交互功能需求的（有意义的），按照责任边界划分，并不是物理边界（什么叫物理边界？），而且执行者与重要性无关，是直接与系统交互

系统执行者有主执行者和辅执行者之分，两者的差别是前者主动后者被动，但在系统中都有接口。（辅执行者的定义：必须有它的辅助才能完成，并不是数据流对象）

系统用例的定义：

RUP (IvarJacobson) ：用例实例是在系统中执行的一系列动作，这些动作将生成特定执行者可见的价值结果。一个用例定义一组用例实例。

通俗一些：执行者通过系统达到某个目标，这个目标是能“卖”的

寻找系统用例的方法：

（1）       通过业务序列图可以找到系统用例，对于特定的研究对象，箭头指向它的请求行为就是一个用例

（2）       写出涉众可理解和验证的的路径、步骤都可以作为用例

系统用例的命名注意：一定要是动宾结构，并且慎用弱动词弱名词－－会掩盖真正的业务

选定系统用例的误区：

（1）       粒度问题：用例不存在粒度问题，我们总容易把步骤当成用例，或者以系统的实现方式选定用例（四轮马车：CRUD），选取用例只有一个视角，就是涉众的视角

（2）系统用例图与业务用例图并没有什么不同，只是研究对象不一样，可以是一对多，也可以是多对一

画系统用例的注意点：

（1）       一定要说清楚研究对象

（2）       哪种画法更合适取决于涉众的看法

（3）       没有谁对谁错，只有谁更好

（4）       有些看起来很相似，想合并为一个用例，实际上根据契约和价值的不同，应该分为多个用例

（5）       选定完系统用例一定要检查，看看是不是每个用例都有愿景目标

写用例文档（书写用例文档的时候把系统看成一个黑箱）

总原则：如果涉众不能理解和验证，它就不是需求（如果删掉它，会不会有涉众的正当权益受侵害？）

用例文档格式：

用例编号：用例名

执行者

前置条件

后置条件

涉众利益

基本路径

1…..××××

2……××××

3…..××××

扩展

2a.××××：

2a1….×××××

字段列表

业务规则

非功能需求

设计约束

一些规则：

前置条件的形式：必须是系统在用例开始前能检测到的，内容：不满足会伤害涉众的利益

涉众利益（最重要）要考虑当事人，上游，下游，操作对象的主人。。。。。。（涉众其实指前排涉众）

基本路径: 客户最想看到、最关心的路径

路径步骤四部曲：请求---验证---改变---回应

路径用语的基本原则：

（1）       可理解可验证

（2）       使用主动语句（理清责任）

（3）       主语只能执行者或者系统

（4）       路径中没有“如果”，把分支写在扩展里（基本和扩展分开）

（5）       不要涉及界面组件

（6）       不要假想系统不能负责的事情

扩展：必须是系统能感知和要处理的，扩展！＝选项，要看交互行为变化

字段列表：可以用自然语言，也可以用表达式（细到什么程度看涉众共识）

不同于数据模型－－只是一部分

可以用E/R图或业务对象图作为辅助说明，但不宜直接作为需求

不等于数据字典－－容易过早把时间花在细节上

一开始好像做了很多事情，其实却回避了困难的业务问题

业务规则！=实现算法

非功能需求：激烈竞争的决胜点（可用性，可靠性，可支持性，性能）

设计约束：必须来自涉众

补充：

  识别用例关系（不要滥用）

扩展：分离扩展路径

包含：提取公共步骤集合，便于复用

泛化：同一业务目的的不同技术实现

大量用例时的组织

  按执行者分包

按主题分包

按开发团队分包

按发布情况分包

用例是执行者一份一份地和系统签订的契约，用例是否用对了的判断标准：是否加强了和涉众的联系。

把设计当需求的原因往往是没有从卖的角度考虑问题而是从做的角度

寻找涉众利益是需求的重要的点

需求是指没有这个系统会怎么样，而不是这个系统能做什么

用例只有一份，是模型，视图有很多（没有开发用例，设计用例之分）