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-06
全文显示

知识丰富的设计

1、业务活动与规则对于一个领域来说与其涉及的实体同样重要。   2、领域也会包含各种类别的概念。对知识的消化要能够产生出反映这种理解的模型。   3、超越实体与值之上的变化可能会对知识消化产生剧烈的影响，因为业务规则之间可能存在不一致。   4、领域专家通过与软件专家的密切合作，进行知识消化，才使得规则明晰化。   5、提炼隐藏概念，将业务规则可以放到一个领域对象中。   6、任何业务专家都不可能阅读代码来检对规则。   7、一个非业务人员的技术人员，要将需求文档与代码联系起来是很困难的。   8 ...
2008-07-05
全文显示

Replace Array with Object 以对象取代数组

1、如果一个数组中的各个元素代表了不同的东西，考虑用Object来代替数组。   2、数组应该只用于容纳一组相似对象。   3、如果一个数组容纳了不同对象，会给array用户带来麻烦。
2008-07-05
全文显示

常见的软件隐喻

1、重要的研发成果常常产自类比。通过把你不太理解的东西和你较为理解、十分类似的东西进行比较，你可以对这些不太理解的东西产生更深刻的理解。这种使用隐喻的方法叫做“建模”。   2、软件隐喻不会告诉你到哪里去找答案，仅告诉你该如何找到答案。隐喻的作用更像启示，而不是算法。   3、“增量的”、“迭代的”、“自适应的”、“演进的”，以增量的方式进行设计、编码和测试，是目前已知的最强有力的软件开发概念。   4、进行增量开发时，我们先做出软件 ...
2008-07-05
全文显示

知识消化

1、高效的建模人员就是知识的消化器。   2、知识消化并不是一个孤立的行动，它由开发团队与领域专家共同合作，由开发人员领导。   3、老式的瀑布方法中，业务专家与分析人员会谈，分析人员提取摘要，进行抽象后将结果转达给程序员，由程序员进行编码。这种方法并不成功，因为没有反馈机制。   4、优秀的程序员会自然地开始进行抽象来开发一个模型。   5、在团队成员一起讨论模型的过程中，他们之间的交互也会发生变化。模型的不断精化使得开发人员不断学习他们所需要的重要业务原理。领域专家通过提炼他们认为必须的知识来精化他们的理解。   6、程 ...
2008-07-05
全文显示

有效建模的因素

1. 模型与实现相互绑定。未经加工的原型建立了早期必需的联系，在随后的迭代中始终对它进行维护和完善。   2. 基于模型生成了一种语言。随着项目的进行，我们中的每个人都可以自如地使用来自模型的术语，将它们组织成与模型结构一致的句子，不需翻译，也不会引起歧义。   3. 开发了一个包含丰富知识的模型。对象都具有行为和一些强制性的规则。模型并不仅仅是一个数据方案，它是解决一个复杂问题必不可缺的。它捕获了各种类型的知识。   4. 提炼模型。在模型变得更加完善的过程中，一些重要的概念被加入其中。同样重要的是，如果概念被证明没有用处或并不重要，则应该丢弃。如果 ...
2008-07-05
全文显示

用例的编写

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