我正在浏览一些 Java 软件包（Guice、GWT、JAX-RS 等），我的脑袋有些晕眩，因为我真的不知道这些特定软件包在哪些用例上大放异彩。这些教程似乎向您展示了如何使用他们的包做某事，但没有告诉您为什么要使用他们的包（或者在哪些情况下您不想使用）。

所以我想知道人们是否可以为 Java 库发布一些可能不明显的用例（或“不使用用例”），以补充规范的 what-are-good-free-Java-libraries 问题。我对 Guice 特别感兴趣，但这是一个更普遍的问题。

编辑：如果您知道一个非常好的网页可以回答特定包的这个问题（例如解释 Hibernate 或 JAXB 或其他的用例），请链接到它。

我正在建模一个系统，我有以下是我的一些用例{任命老师（adimin），记录成绩（老师），管理学生（管理员），记录出勤（老师），管理课外活动（管理员）}我有一些提出用例步骤和用例场景的问题。我已经画了我的概念类图。有没有人知道如何去做？

提前致谢

使用用例对系统行为建模的最佳实践是什么？系统行为是根据计划定期执行的（而不是作为显式用户交互的直接结果执行）？

如果将“时间”建模为参与者，那么描述如何使用时间来触发用例的公认方法是什么（例如，时间段是否可配置、有效范围等）？

概括：

您在 TD 设计与开发中包含和/或交付了哪些模型和图表，为什么？

细节：

新的 4 开发人员项目，在一个商店中，我们正在逐步取得进展，使管理层在 TDD 采用/预期中从“买进”到“行动”毕业。我（一名开发人员）想要为新项目进行测试驱动设计。管理层愿意允许测试驱动的开发——在创建了一些模型和图表之后（这些将补充 UI 模型，以便在重大开发开始之前向客户传达详细的设计）。

那么，鉴于这种情况，您认为哪些模型和图表是合理的？这个项目的可交付成果是一个既不简单也不复杂的 web 应用程序。我们有一个需求文档（有时含糊不清，但对于编写测试来说是一个好的开始）。

但是到目前为止，我所拥有的 TDD 经验（一个非常低缺陷的项目，我独自使用 TDD，以及一些设计成熟的同行测试创作在这里和那里）让我想要继续进行测试驱动设计。

创建模型/图表的过程（看起来我们将提供一些类模型和一些高级用例和序列图）似乎给我们（开发人员）没有 TDD 不会的设计洞察力，他们'技术/复杂性足以让我担心任何非开发人员在呈现它们时都会有效地忽略它们（阅读：盲目接受它们）。

您在 TD -design 与 -development 中包含和排除模型和图表之间的界限在哪里？

我正在寻找一本书，它告诉您如何将软件（或任何东西；不必是特定于软件的）任务或项目拆分为离散的块，并帮助阐明所有不明显的问题和细微差别当你刚开始编程时。

我应该买一本关于用例的书吗？如果是这样，是什么？

我正在寻找一本书，它可以帮助我从“用户希望能够为自己指定电子邮件地址，或指定他们没有电子邮件地址”之类的简单故事转变为 UI 图，以及编码任务列表和测试要求（因此编写单元测试变得非常简单）。

我厌倦了开始一项任务，却因为没有经过适当的考虑而在其中感到困惑。

谢谢！

我在哪里可以找到一些免费的用例场景模板？

谢谢

PS。我知道他们很容易在 google 上找到，但我问了这个问题，以便最好的可以升到顶部。

在我现在的雇主，我们通常采用写传统功能需求规范，然后执行完整的技术设计的老派方法。如果应用程序很大，那么我们将它分成更小的块并一次攻击一个块，但遵循相同的基本模式。

多年来，这项技术对我很有帮助。对于用例建模，您似乎需要收集几乎相同的信息，只是组织方式不同。

所以我的问题是：遵循用例驱动的软件开发方法有什么实际好处？

我是编写用例的新手。我听说用例是非技术表达。

我有以下任务，我必须为此编写用例。
（我降低了你理解的要求）

ABC公司的注册客户使用凭证登录系统以检索特定服务提供商的完整地址。他在TextBox上搜索服务提供商。系统与数据库通信并在监视器上显示结果。

我是技术人员，
我必须编写用例来向客户解释系统的行为。

我写了用例如下：

用例名称：地址定位系统
主要参与者：客户
利益相关者：ABC公司
前提条件：客户成功登录系统

成功场景：

1. 客户 在提供的框中输入搜索词。
   • 系统在搜索词中搜索匹配项。
   • 系统向客户提供地址。

扩展点：没有成功匹配时通知客户端
发布条件：无

问题。

1. 上面描述的用例是否正确？
   • 技术人员真的需要编写用例吗？

这个问题很笼统。识别有效用例时应牢记哪些要点？如何处理用例？

我一直在阅读有关使用灵活属性而不是通过使用 Dictionary 或类似的东西来存储它们的强类型固定属性的信息。使用灵活属性的一个明显优势是您可以在运行时更改对象具有的属性。

这种行为有哪些有趣的用例？

一些相关文献：

• 马丁福勒 http://martinfowler.com/apsupp/properties.pdf
• 史蒂夫·耶格 http://steve-yegge.blogspot.com/2008/10/universal-design-pattern.html