2008-07-06
全文显示

准则：采用参与者与参与者目标的视点

1、一组用例实例，每个实例是系统所执行的一系列活动，以此产生对特定参与者具有价值的可观察结果。   2、关注系统的用户或参与者来编写需求，询问其目标和典型情况。   3、关注理解参与者所考虑的有价值结果。
2008-07-06
全文显示

准则：编写黑盒用例

1、黑盒用例是最常用的和推荐使用的类型。它不对系统内部的工作、构件或设计进行描述。   2、黑盒用例以职责来描述系统，这是面向对象思想中普遍统一的隐喻主题-软件元素具有职责，并与其他具有职责的元素进行协作。   3、黑盒用例定义系统职责，可以规定系统必须做什么，而不必关心系统如何去做。   4、分析与设计的区别，就在于”什么“和”如何“。   5、在分析中应避免进行”如何“的决策，而是规定系统的外部行为。   6、在设计过程中，创建满足该规则说明的解决方 ...
2008-07-06
全文显示

准则：编写简洁的用例

1、应该编写简洁的用例，删除“噪音”词汇。   2、即使是一些细微之处也会积累为繁琐。
2008-07-06
全文显示

准则：以无用户界面约束的本质风格编写用例

1、通过对目标层次的研究，系统分析员会发现与实现机制无关的目标。   2、这种对根源目标的发现过程能够扩展视野，以促成新的和改进的解决方案。   3、摈除用户界面于思考范围之外，集中于意图。   4、以本质风格编写用例，摈除用户界面并且关注参与者的意图。   5、具体风格的用例编写方式，不适合于早期的需求分析工作，应该避免。
2008-07-05
全文显示

用例的编写

1、用例、UML图等保证不会是完美的。它们可能会遗漏关键信息或者包含错误陈述。解决方案并不是以瀑布的态度试图近乎完美地记录规格说明并且在开始阶段就完成此项工作。   2、编写用例的折中方案是介于瀑布和即兴编程之间的迭代和进化式开发。   3、以增量式进化、验证用例和其他模型，并且通过及早的编程和测试加以明确。   4、如果在第一次开发迭代之前，小组就视图详尽地编写所有或大部分用例时，此时要意识到你已经走入歧途了。反之，则恭喜你！
2008-06-22
全文显示

[读书笔记]UML和模式应用 ---- 用例

关键字: uml 读书笔记       通俗地讲，用例是文本形式的情节描述， 用以说明某参与者使用系统以实现某些目标。       注意：用例不是图形，而是文本。 用例初学者的常见错误就是注重于次要的UML用例图，而非重要的用例文本。         本质上，用例是通过编写使用系统实现用户目标的情节来发现和记录功能性需求 ，也就是使用的案例(cases of use) ...
jokermanager
搜索本博客
最近加入圈子
存档
最新评论