umlchina公共课上课笔记

概述

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的对象，B的对象有时是A的对象。不同领域的类之间不应该形成泛化关系。

12.   关联的含义：一个对象对另一个对象的静态依赖关系。包括连接、聚合和组合。区别于依赖，依赖是动态的。

13.   聚合和组合的区别：都是整体与部分的关系，组合比聚合关系更强。反映到C++中，组合是值包含，聚合是指针包含。当组合对象死掉的话，被组合对象也会随之死掉；但聚合不会。

14.   警惕数据库习惯：如果已经有了关联，则相应的属性应该被删除掉。

15.   分析常见模式

开发流程3 分析顺序图

1.       5.pdf

2.       通过画顺序图完成责任分配

3.       在分析阶段，所有类主要分为边界类、控制类和实体类。

a)       边界类：用例的每个执行者影射为一个边界类。负责与外界交互

b)       控制类：一个用例映射为一个控制类。负责控制事件流，负责为实体类分配责任。

c)        实体类：对必须存储的信息和相关行为建模。一个用例可能有多个实体类。一个实体类也可以应用于多个用例。是业务行为的主要承担者。

4.       顺序图和类图的映射（示例）

a)       消息的传入：类对象所具有的操作----责任。

b)       消息的传出：类对象完成操作所需的合作----协作。

5.       顺序图绘制要点

a)       位置：在每个用例下面，对应用例的路径

b)       基本路径：一张图

c)        简单的扩展点：合并到基本路径，用Text说明条件

d)       复杂扩展点：单独一张图，和主图之间用note连接

6.       责任在实体类之间的分配

a)       总原则：低耦合，高内聚

b)       三个重要原则：

                        i.              专家原则：把责任分配给专家

                       ii.              老板原则：聚合/组合发生时，对被聚合类的调用需要经有聚合类。

                     iii.              可视原则：只有发生关联的类之间才有消息传递。

c)        分配责任时可能会产生新的实体类。

7.       状态图

a)       把某对象从所有顺序图中拿出来单独考察（一个实体类可能应用于多个用例）。

b)       状态：在系统中表现出相同行为的属性值组合。

c)        迁移：属性值变化导致行为变化。

开发流程4 设计

1.       6.pdf

2.       分析强调业务概念，设计强调平台实现。二者有时是合并的。

3.       整个软件分为：表示层、业务层和逻辑层。

4.       数据层

a)       映射存储

b)       构造数据源层

5.       映射存储

a)       映射类与属性：类->表，对象->行，属性->列

b)       映射泛化关系：超类与子类都映射成表，超类主键作为所有类的主键

c)        映射连接关系：1对0..1（外键放在0..1端），1对1（外键放在任意一端），1对多（外键放在多方），多对多（添加第三张表）

d)       映射组合

e)       映射反身连接

6.       建模工具自动映射

7.       构造数据源层（《数据库设计模式》）

a)       表数据入口

b)       行数据入口

c)        活动记录

d)       数据映射器（O/R Mapping）

8.       业务层模式：

事务脚本、领域模型、表模块、服务层。

9.       界面层（MVC，Struts）

10.   设计模式

11.   测试：单元测试。

12.   实现视图：构建图和部署图。