影响用例书写格式的因素

张开发
• 2026/5/7 5:03:16 • 15 分钟阅读

最新文章

推荐文章

相关文章

分享文章

影响用例书写格式的因素
在1998年的OOPSLA大会上12个资深的用例设计者和教师聚集在一起讨论一些常见的编写用例容易混淆的地方和困难以及是什么使得人们写出的用例都各不相同。大会的组织者Paul Bramble收集了这些意见并将意见分类。用例在不同情况下可能会不同你不用担心这个问题这是大家都无法避免的。你可能发现在下面所列的情况中有些情况组合起来迫使你不能按期望工作。耐心一点宽容一点你就可以写出符合要求的用例。在列出了所有这些影响因素后我们可以找到一个一致的问题答案:“怎样写出可读的用例?”矛盾的因素:业务环境、社会作用、不同文化你想要描述用例但是可能遇到下面的情况或争论(我不是想平息这样的争论而是要你认识到并不是只有你会遇到这样的情况)。我们总是按照另外一种方式去做事情。在不同的文化背景中你可能发现:在小组中存在偏见。存在不同的工作文化在这些文化的影响下人们只不过在“以不同的方式做事”。写用例的人和读用例的人使用不同的词汇表。理解层次在不同的时间、地点不同的人对同一件事情会有不同的理解。你可能会修改推荐的用例编写格式这可以根据:现在你知道多少:关于领域关于用例你知道当前阶段是处于软件生命周期的哪个阶段吗?你是否需要确定工程的内容或花费?你现在是需要广度的研究还是深度的研究?暗中分析或慢慢地分析现状。人们都强调他们所知道的内容。时间计划、知识深度与领域知识的对立。项目相关人员的要求你同意下面哪些观点?用户是读者也是用例的使用者他们关心用例的高层次描述。IT公司的技术人员是编写者或实现者他们关心细节描述。一些开发组可能想通过一些服务小组来表达关于用例的多个观点或者对建立一个完整模型还是部分模型产生分歧。是否还涉及其他不同的读者?如果有他们是谁?经验与格式经验(experience):每个小组中都有用例的初学者但是他们很快就成为“有经验”的编写者。有经验的人知道一些捷径初学者则希望有清晰的方向和一致的指令。格式(formality):不管是对有经验的设计者还是初学者领导者或部门传统的工作方式都需要有一种正式(或非正式)的书写格式。覆盖面用例的覆盖面依赖于开发组的组成、编写技巧、成员之间的交流及他们是需要覆盖整个问题还是只需要与读者交流信息。覆盖面的变化可能是由于:领域问题专家(他们关心的问题可能集中在某一个方面)编写者人数读者人数实现者人数业务人员是否知道他们需要什么按照一个通常模式来工作的决定开发组成员的地理位置分布一致性用例内容一致性的要求可能会与客户需求的不一致性和不确定性冲突。需求的易变性格式的一致性复杂度用例的复杂度涉及下面几个方面。对用例完整性的要求描述整个问题领域多角度的描述简化系统视图表达的简化细化用例表达范围窄的视图和范围宽的视图问题的复杂度加入技术细节的要求(特别是在问题很难解决的时候)下面的因素影响了系统的复杂度。分析停滞(系统的复杂度超过了分析师的分析能力)执行者的数目功能点的数目系统的种类用户系统的简单性实时系统嵌入式系统(必须有容错能力)冲突需求是为了解决用户冲突但需求的不确定性又掩饰了冲突。完整性妨碍用例完整性有下面几个因素。工程的需求不完整。设计者没有接触过用户(用户不是你的客户)。目标与任务-完成什么与怎样完成用户经常细化需求而不是系统的使用方法。系统环境可能和使用方法冲突。活动和任务描述了系统会发生什么而不是为什么发生。资源写出好的用例是需要时间的但项目的时间是有限的。在编写项目的用例时就必须引入管理机制。其他因素其他影响用例的因素有:工具需要/支持不明确的目标将需求分块并分别进行分析无约束的设计与将要进行的设计的层次清晰与可理解的设计抽象用例与具体用例可描述性合作的积极性这个列表有些与众不同。尽管本书中大部分内容适用于所有的情况但你可以参考这个列表来决定采用多少形式化的东西是否现在少做一些而将来多做一些设计到什么程度或怎样来安排设计的阶段在深入编写用例之前理解问题的广度和精确程度。

更多文章