UML Distilled (UML精粹)

Posted on 2016-07-27 Edited on 2016-08-07

~~Edit~~

我有史以来，见过的翻译的最最最烂的中文译本，没有之一。大家记住这个名字徐家福。通篇狗屁不通半文半白的叙述，业务不精还以为自己是孔圣人。每次看他的译本就有真想抽丫的冲动。
书是好书，Martin Fowler-很有经验的UML专家。书中不乏他关于使用UML的真知灼见。刚阅览了第九章，忍不住要写点笔记记录一下。

UML Distilled (UML精粹)

Chapter 8. Deployment Diagrams

The nodes contain artifacts, which are the physical manifestations of software: usually, files. These files might be executables (such as .exe files, binaries, DLLs, JAR files, assemblies, or scripts), or data files, configuration files, HTML documents, and so on. Listing an artifact within a node shows that the artifact is deployed to that node in the running system.

Chapter 9. Use Cases

Use cases are well known as an important part of the UML. However, the surprise is that in many ways, the definition of use cases in the UML is rather sparse.

Use case在UML中很重要，但他的定义却比较随意。

What the UML describes is a use case diagram, which shows how use cases relate to each other.

UML中提到的use case，往往指的是用例图，但其实用例图用处并不大，真正重要的use case本身，按Martin的说发就是，那一条条的steps和extensions。

定义

Use Scenario

A scenario is a sequence of steps describing an nteraction between a user and a system.

Use Case

Use cases are a technique for capturing the functional requirements of a system.
A use case is a set of scenarios tied together by a common user goal.
Use Case = several Use Scenarios

Extension

An extension within the use case names a condition that results in different interactions from those described in the main success scenario (MSS) and states what those differences are.

翻成扩展吧，感觉就是steps中的特例。具体可以看下面的例子。

Levels

这个很有意思。按Martin的说法，分成三个level

Sea Level
- Sea-level use cases typically represent a discrete interaction between a primary actor and the system.
Fish Level
- Use cases that are there only because they are included by sea-level use cases are fish level. Sea level的子use case，被sea level use case包含。
Kite Level
- kite-level use cases show how the sea-level use cases fit into wider business interactions. 在business case的时候用到这个level的use case。

Fowler大师给出建议：

You should have most of your use cases at the sea level.

在系统设计的时候，尽量只用sea level的use case，也就是中间级，既不是太细也不太粗。

Feature

Many approaches use features of a system—Extreme Programming calls them user stories—to help describe requirements.

所谓Feature，我理解，是系统的特性，根据use case要用到的特性来定义系统需要提供什么，这是一种对正在设计的系统的requirement。
但是Feature本身与use case并没有对应关系，他们是系统设计时，先后被用到的两个用途的两件东西。现有use case，再有features (user stories)。我认为feature这个词更贴切，以区分use case。

Fowler大师再次给出建议：

Although you can go directly to describing features, many people find it helpful to develop use cases first and then generate a list of features.

Misc.

A pre-condition describes what the system should ensure is true before the system allows
the use case to begin. This is useful for telling the programmers what conditions they don’t
have to check for in their code.
A guarantee describes what the system will ensure at the end of the use case. Success guarantees hold after a successful scenario; minimal guarantees hold after any scenario.
A trigger specifies the event that gets the use case started.

这些在严格定义use case，并促成系统界限设定时用得上。
此时Fowler大师再次给出建议：

It’s better to do too little than too much. The amount of detail you need in a use case depends on the amount of risk in that use case.

后面Fowler大师接着说（我就不放原文了），通常，在开始的时候，你只需要几个关键的use case，慢慢地其他的use case会被添进来。你并不需要把他们都写下来，口头的交流效率往往更高。
不要花太多的时间画用例图，focus在文字描述上。画图容易让事情变得复杂而失去焦点，并且图越复杂，看得懂的人越少。

例子

什么时候用Use Case

Use cases are a valuable tool to help understand the functional requirements of a system.

接着Fowler大师又给出真知灼见：

A couple of pages per use case is just fine for most cases.

一般一个use case一到两页纸足矣。不要太多或太少。

Chapter 10. State Machine Diagrams

When to Use State Diagrams

State diagrams are good at describing the behavior of an object across several use cases. State diagrams are not very good at describing behavior that involves a number of objects collaborating.
Many people find that UI and control objects have the kind of behavior that is useful to depict with a state diagram.

例子&基本概念

When developers talk about objects, they often refer to the state of the objects to mean the combination of all the data in the fields of the objects.

开发人员说的object，一般指的是object的某一个状态。

高级概念

Internal Activities

Activity States

regular activities occur “instantaneously” and cannot be interrupted by regular events, while do-activities can take finite time and can be interrupted

Superstates

Concurrent States

history pseudostate. This indicates that when the clock is switched on, the radio/CD choice goes back to the state the clock was in when it was turned off.上一次关机时的状态，就是history pseudostate。

Implementing State Diagrams

有三个方法implement

nested switch
the State pattern
state tables
第一个最简单也最常见就是switch-case。Fowler大师说不建议用这个，即便是简单的case。因为很容易失控。
第二个是state设计模式，具体请见［Gang of Four］The state pattern is easier to put together when you need it, and although it needs a new class for each state, it’s a small amount of code to write in each case.

Obviously, the state table is more work to do once, but then you can use it every time you have a state problem to hold.

Chapter 11. Activity Diagrams

基本概念

我翻译之为活动图。其最重要的功能就是阐明动作序列——串行&并行。

Initial node & activity final
fork & join
decision & merge
每一个圆角的方框框是一个action，所有的这一切组成一个activity

如果需要每一个action可以转化成一个子活动(sub activity)。然后在主图中用一个叉子(rake)表示。

When to Use Activity Diagrams

The great strength of activity diagrams lies in the fact that they support and encourage parallel behavior.

不过在这一章节中，Fowler大师这里有一段话颇为耐人寻味：

In principle, you can take advantages of the forks and joins to describe parallel algorithms for concurrent programs. Although I don’t travel in concurrent circles that much, I haven’t seen much evidence of people using them there.
I think the reason is that **most of the complexity of concurrent programming is in avoiding
contention on data, and activity diagrams don’t help much with that**.

并没有很多人或者有很强的理由使用活动图来描述并行结构，原因是活动图并不能很好的描述对资源的争夺(contention)。

send signal
accept signal
time signal

Tokens

这个按照Fowler大师的说法，有些UML的大部头著作花了大篇幅的文章介绍token的使用。在复杂系统中token可以让系统可易于理解，可视化更好。

You can visualize the tokens with coins or counters moving across the diagram. As you get to more complicated examples of activity diagrams, tokens often make it easier to visualize things.

Flows and Edges

这里提供了几种图例，来丰富活动图的画法。看例子就可以了：

Pins and Transformations

看一个pin and transformation的例图：

Pins are best when you want to look at the data needed and produced by the various actions.
If you use pins, it’s safe to show multiple flows coming into the same action. The pin notation
reinforces the implicit join

Big Ben