考虑真实世界中可能遇到的问题

狗门 2.0 运行一阵后又出现了问题，不只是主人自己的狗狗，其他任何狗叫唤，狗门都会打开。

Paste_Image.png

软件都有其运行的上下文环境，真实世界和设计时候的理想世界是不同的，要充分可虑可能遇到的各种情况。

更新用例

出现问题是因为原先的用例描述不准确造成的，下面修改用例：

• 将特指的狗改为通用的狗，即将“狗的名字”改为“主人的狗”
• 将特指的用户改为通用的用户，即将“用户名字”改为“主人”
• 增加判断特定狗狗声音的步骤

修改用例

增加新用例

系统需要存储狗狗的声音，这是一个新的目标，所以需要新的用例来描述。

Paste_Image.png

类图

到目前为止，系统出现的对象可以用下面几个类图表示

Paste_Image.png

两种不同的设计

第一个程序员用一个字符串表示狗狗的声音，并存放在狗门类中。

Paste_Image.png

而另外一个程序员设计个了一个狗叫类，存储狗狗的声音

Paste_Image.png

可以对比一下二者的狗门类，非常相似，只是狗叫声一个用字符串表示，另外一个用狗叫类表示：

Paste_Image.png

下面修改狗叫识别器中的识别函数，二者也非常相似，只是数据结构不同

Paste_Image.png

委托很重要

在 Sam 的方式中，识别函数将比对叫声的任务委托给了狗叫类，如果狗叫类发生了变化，对识别类的影响非常小，因此更具有灵活性

Paste_Image.png

更好的设计

上面两个人的设计都可以正常工作，虽然 Sam 的设计更好一点，但是二者都没有考虑到一个问题：狗狗可能会有多种叫声。Maria 考虑到了这个问题，在狗门中存储了狗狗的多种叫声，她的设计更加合理。Maria 是怎么做到的呢？

Paste_Image.png

文本分析：找出用例中的名词

用例中的名词通常是系统中的类，就算不是类也是系统的焦点

Paste_Image.png

用例应该准确的描述系统工作方式

不同的描述方式中，会出现不同的名词，造成不同的焦点，导致不同的设计结果

Paste_Image.png Paste_Image.png

名词不一定是类，但一定是焦点

焦点表示你应该关注的重点对象。如果狗狗是焦点，那个不管他怎么叫你都应该让他进门；如果叫声是焦点，那么只有正确的叫声才能进门。

动词一般是类中的方法

Paste_Image.png

有些名词虽然是焦点，但是并不需要创建类

狗狗这个名词虽然是焦点，但是并不需要为他创建一个类，原因如下

• 在系统之外，不需要系统表示
• 不需要他的信息（这里不需要狗狗太多的信息）
• 放在系统中不符合现实世界的逻辑（将狗狗存储在狗门中进行对比？）

Paste_Image.png

UML 类图

用例分析完成以后，先绘制类图，而不要立刻编写代码

Paste_Image.png

类图抽象层级较高，还有很多细节需要考虑

Paste_Image.png

总结

• 软件都有其运行的上下文环境，真实世界和设计时候的理想世界是不同的，要充分可虑可能遇到的各种情况。
• 用例的描述应该准确
• 委托很重要
• 多个目标应该编写多个用例
• 用文本分析找出用例中的名词和动词，可以将他们转换为类、属性、方法
• 类图可以对系统进行描述，但是缺乏细节
• 名词不一定是类，但一定是焦点