提示6-1:始终将现有构建块映射到运行时场景中的活动!
提示6-1:始终将现有构建块映射到运行时场景中的活动! #scenario #runtime-view #essential #runtime-scenario 运行时场景显示(文档或指定)构建块或其实例的交互。在这些场景中,您应该始终使用构建块视图(或其运行时对应元素,如类实例)中的元素。它们描述了系统如何履行某些职责或任务,涉及哪些构建模块。 请将这些运行时场景与所需的功能进行对比:这些描述了系统需要以某种方式执行或执行的所需过程或步骤序列(但无论系统的哪个元素实 ...
提提示6-4:记录详细的场景(谨慎)!
提提示6-4:记录详细的场景(谨慎)! #scenario #runtime-view #thorough #runtime-scenario 这个提示与提示6-3(原理图场景)形成鲜明对比。 UML序列图的初衷是显示类的具体实例之间的相互作用,以及方法调用和参数, 你能拥有的最低细节水平。在这个层面上,我们谈论的是实例“Homer Simpson”,而不是classPerson。 这些细节的优点是彻底性和准确性:您可以可视化源代码的单次执行。 请谨慎记录细节-仅 ...
提示6-5:主要使用场景来“发现”构建块,而不是用于文档!
提示6-5:主要使用场景来“发现”构建块,而不是用于文档! #runtime-view #scenario 您可以使用场景来澄清、沟通或指定构建块的责任。 通过可视化场景或流程,您可以创建对团队内构建模块的共同理解。 使用轻量级工具-即纸质或基于文本的工具。使用全面建模工具,您可以实现视觉美学效果-以更高的维护工作成本。 示例:使用PlantUML渲染序列图 PlantUML是一个免费工具,可以从文本描述中呈现序列图。 考虑一个例子:在以下列表中,您可以找到简单序列的描述, ...
提示6-6:描述场景(部分场景)的摘录!
提示6-6:描述场景(部分场景)的摘录! #runtime-view #scenario #sequence-diagram 我们看到了太多类似于以下内容的序列图:只是在几个参与者中传播日期的场景——通常是无趣的东西。 更有效:部分场景仅描述此类场景的摘录或部分内容。 专注于有风险、困难、复杂或有趣的部分。 不要犹豫,在更长(整体)过程中开始 剪掉无聊、标准、简单明了的东西 将下面的(紧凑)图表与上面的(无聊且更长)版本进行比较。 顺便说一句:两张图表都是从Pla ...
提示8-4:在概念中,解释它是如何工作的!
提示8-4:在概念中,解释它是如何工作的! #concept #source-code #example 您应该记录或指定具体、真实的解决方案方法,而不是抽象的理论。 解释这些概念如何在现实中应用,它们如何在源代码中实现。 您可以参考现有代码,或在文档中包含代码示例。 另请参阅 提示8-8(用源代码解释概念)。 ...
提示8-8:使用源代码记录概念!
提示8-8:使用源代码记录概念! #concept #source-code #example #test “用戒律教学是一条漫长的道路,但以身作则是短暂而有益的道路。”(引用小塞内卡) 开发人员通常会是arc42概念的使用者,开发人员对完成工作非常感兴趣。他们需要知道他们如何能够或应该实现他们的目标? 回答这些问题的最具体方法是……源代码: 显示选定的单元测试 单元测试有其先决条件(在设置方法中)和其断言/后果(在断言语句中)是明确的。 自动包含代码工件 ...
提示9-2:文件决策标准!
提示9-2:文件决策标准! #decision #criteria #stakeholder #essential 开发人员、架构师和其他利益相关者将根据各种决策标准做出与架构相关的决策。 另一方面,标准可能对不同的利益相关者有不同的优先级。 询问您的利益相关者关于重要决策的具体标准:除了纯粹的技术标准外,可能还有组织、正式、业务相关或法律(法律)标准。 您可以将重要性/优先级记录为数字权重或类别(即A,B,C)。 下面你会发现一组假设的决策标准。 示例:选择 ...
提示12-4:在术语表中包含翻译!
提示12-4:在术语表中包含翻译! #glossary #i18n #translation #thorough 你知道情况吗: 你的一些要求是用德语写的您的开发团队部分位于德国,部分位于非德语国家您的管理层想要一份“国际上可理解的文件”然后,您需要您最重要的术语的规范性翻译参考: 只需在术语表中添加一列,即可查看您需要支持的每种语言,请参阅以下示例: Term (EN) Definition Translation DE <Term-1> & ...
提示5-8:对每个白盒结构提供合理依据!
提示5-8:对每个白盒结构提供合理依据! #building-block #whitebox 每个白盒结构都是将黑盒分解成更小的部分(我们称之为包含的黑盒)以及它们的相互依赖性或关系。 在每个白盒中,您应该简要解释特定分解或结构的原因: 为什么这个白盒由五个黑盒组成? 为什么包含的黑盒A与B交谈? 这些信息有时被称为这个特定白盒的设计原理。 ...
提示9-6:文档拒绝的替代方案!
提示9-6:文档拒绝的替代方案! #decision #thorough 在记录架构决策时,您应该包括被拒绝的替代方案以及这些被拒绝的原因。 ...