关于书写用例文档中有关备用路径，异常路径的问题!

[stillfire]

1.
所谓异常事件书上这么说的，由于用户没有正确的正确操作，造成的异常。
是用户的操作顺序的错误，造成一个事件的发生在它的前置事件之前 ， 还是系统的缺陷？

2.
而 备用路径 是不是就是讲 由于 添加，修改，删除，查询 遭成的 操作呢？

3。
写好详细的 用例文档是不是 方便的建立 序列图等等呢？

[ozzzzzz]

异常的问题看来我还是要解释一下。
实际上异常并不是程序的错误，也不是系统的缺陷。而是由于使用者的操作，超出了设计者的预期。比如要你填姓名，可是你的名字有500多个字符。要你使用有效的名称，但是你误操作，加入了不可识别的字符。又或者你没有安装操作的步骤，比如你应该先注册，再使用，但是你没有注册也要使用，或者你注册以后没有激活。这些都是异常。
而备用的路径则是你给那些未使用主要流程的人提供的路径，比如基本来说网上支付都是用信用卡，但是你只能用现金支票。

用例文档其实是可以包括序列图的，但是请注意用例中没有涉及到类。而且用例的过程往往非常复杂，序列图和活动图等图示，很难表达这样一个复杂的流程。所以根本的解决方法，还是使用文字说明。而详细的用例文档，对于uml的使用只有间接的好处，实际的帮助并不是很大。

[stillfire]

1.基本上看懂了，就是用户的误操作，比如 用户不按照顺序 进行 也算做是 异常路径了，这样的操作 是不是一部分还是能够通过 程序进行控制的！

2。
备用的路径 按照楼上的 说，比如基本来说网上支付都是用信用卡，但是你只能用现金支票。 ------不是成了另外 一条 业务路径了啊？
Create , Reasearch, Update ,Delete 算不算 备用路径呢？？？

3。
我也发现基本上 在画图的时候，什么都懂，而没有 讨论细节，也就发现不了问题！

基本上建立和设想一个 系统的原型，把所有的情况尽量 走一边，是不是呢？？~~~~~~~~`

[stillfire]

顶一下

[ozzzzzz]

異常並不僅僅是用戶的誤操作，還包括其他不經常發生的問題，比如系統部分司機，網絡傳遞問題，都可以作爲異常處理。
備用路徑的問題其實也包括其他的方面。比如你的系統中某個部分在某种情況下不能使用，而需要完成原來的業務目標。你就可以採用備用路徑的做法。而實際上這個概念並不是十分重要，即便不清楚這個概念，對於你書寫用例也沒有什麽影響。
用例還是應該用文字表達，這個更加有效和明確。

[stillfire]

谢谢 ： ozzzzzz(希望敏捷)

主要是，刚刚开始学习 UML ,又想 让 开发更加规范一点， 尤其 是文档方面！，，

基本上明白了，但是向 异常处理 ，网络问题，这些 方面 是不是 应该建立一个 影子用例呢？？？

再次谢谢楼上的！

[ozzzzzz]

用例和uml沒有關係。你學不學uml和你學不學用例不是一個概念。
用例其實和其他技術一樣，我們考慮的不應該是規範不規範，而是好用不好用。
很多概念不需要去了解，只要你能找到角色和角色的目標，然後描述好這個目標實現的途徑就可以了。太多的概念並不利於你理解用例的本質。

[stillfire]

但是，
UML 采用 用例 驱动的 软件开发过程，就 和 SA的 数据流 法 不是一个角度上的，
这里只考虑客户的需求，并且转化成用例

Use case 还可以应用在其他的 软件开发模型中吗？？？

[bigpig]

用例本身就可以称为一种建模方法，比如独立得用例脚本描述，UML是吸取了这种方法。

[ozzzzzz]

用例1992年就已经比较完整的出现了。要是追随历史可以到60年代。（大概我的记忆还是可靠的）
uml要晚于用例，而且uml只是一种表达面向对象模型的语言，不是面对对象的方法。你说的采用用例驱动的面向对象过程最著名的是UP，而其中RUP最常见，其余还有EUP和AUP XUP等等多种有差别的方法。同时用例也不是一种面向对象的方法，其本质上说还是功能分解，其实是面向过程的。
实践中几乎所有的开发方法中都可以利用用例来了解和解释需求，这一点并不困难。

[stillfire]

谢谢楼上的，真是张了不少的见识，——————能不能留下Msn ,qq, popo， 向前辈请教！！ ：）

是的，方法是面向对象分析 ood ,语言采用 uml ,

就是就是，在分析用例的时候，发现采用用例和DFD的分析方法，在开始的时候，基本上相同，只是
用例 有一个粒度的问题，还有，就是不用向DFD一样的分析 数据流，（但是，我发现要是想设想一个简单的概念原型，还必须找出关键的数据流）
------------------------------------个人见解，各位还往多指点我！谢谢~~~

[ozzzzzz]

用例的粒度问题可以说已经是讨论烂了的问题，基本没有办法靠其自身解决。而同时由于用例的非面向对象性，使得其在面向对象的分析过程中不是很适合。面向对象的分析，我认为标志在于概念面向的模型的建立，同时确认职责的归属。而用例需要进一步的加工才能得到这个的结果。

[stillfire]

再次感谢： ozzzzzz(希望敏捷) (

最后，在问一个问题，

备用路径：
比如你的系統中某個部分在某种情況下不能使用，而需要完成原來的業務目標。你就可以採用備用路徑的做法

但是，如果，没有这样的路径，是不是系统就不完善？？？


--------------------------解决后，马上结帖！:)

[ozzzzzz]

我劝你不要过分纠缠这些词汇，因为不同的地方可能会对这些词汇有不同的解释。还是保持最小的词汇量，去了解具体的形式比较好，这样不容易产生不必要的误差。

其实系统内部需要不需要提供一些容错的问题，要看你具体的项目。备用路径从这个角度看也是选择的。而如果你的备用路径，表达的是一种对客户的备选方案，比如支持现金支票的问题，则是一种对于客户的易用性的关注。但是不管怎么说有没有备用路径，在大多数情况下，并不代表这个系统是不是有功能的缺陷。而只有在你的系统完全性，可运行性，客户友好程度，稳定性等指标上升到一定的程度的时候，你才可以用此去衡量系统的完善与否。

[stillfire]

恩，
我觉得的那种 if (exist) {create} else{update}
就可以暂时理解成为备用方案！

有的时候 太 钻牛角尖 了，

按照自己的方法和 UML 匍匐前进了，

ozzzzzz(希望敏捷) 真是热心人！，，，，，，，，，向你学习! 结贴

[xxhm]

关注.