提示6-7:使用带有泳道的活动图来描述或指定运行时场景!
提示6-7:使用带有泳道的活动图来描述或指定运行时场景! #runtime-view #scenario #activity-diagram 泳道是一种将同一演员执行的活动分组在活动图上或将活动分组到单个线程中的方式(由Scott Ambler引用)Swimlanes are standard (UML) option to group activities by actor or building block (or thread, see quote above). ...
提示5-7:使用表格高效地记录和描述黑盒的功能和行为!
提示5-7:使用表格高效地记录和描述黑盒的功能和行为! #building-block #table #blackbox 记录或指定黑框的简单而有效的方法是表格,如以下各节所示。 最小的黑盒模板 目的/责任 接口 <目的的简短描述> <界面的简短描述> 完整的黑匣子模板 目的/责任 <目的的简短描述> 接口 <界面的简短描述> (可选)质量/性能特征 <简短描述 ...
提示9-10:使用轻量级工具来支持ADR的创建
提示9-10:使用轻量级工具来支持ADR的创建 #decision #adr #tooling 我们建议在任何轻量级工具中编写ADR,最好是任何文本格式,如Markdown或AsciiDoc。这将使这些决定接近开发团队,他们最终属于哪里! Nat Pryce创建了一个(基于bash的)开源工具包,用于处理ADR。许多其他技术(Ansible、C#、Go、Java、Node等)都有端口 例如,您只需键入即可创建新的ADR 1adr new Implement PDF cre ...
提示6-8:使用带有分区的活动图来描述或指定运行时场景!
提示6-8:使用带有分区的活动图来描述或指定运行时场景! #runtime-view #scenario #activity-diagram 看看下面的示例-它显示了活动图的模块化或分区。 上图由PlantUML用以下代码渲染: 1234567891011121314151617181920212223@startumlpartition Checker { (*) -> "check input" -->If &quo ...
提示9-8:决策应该有时间戳!
提示9-8:决策应该有时间戳! #decision #adr adr: (Activity Driven Requirements) 活动驱动的需求 可能是显而易见的,但决定(例如ADR)应该包含一个时间戳属性。将来,知道在什么时候做出某个决定可能很重要。 ...
提示9-9:遵循_建议以获得良好的ADR_
提示9-9:遵循_建议以获得良好的ADR_ #decision #adr 架构决策记录的支持者之一乔尔·帕克·亨德森收集了关于良好架构决策记录的建议。 我们建议遵循他的建议: 我们只引用他收藏的第一部分: 良好ADR的特点: 理性:解释做特定AD的原因。这可以包括各种潜在选择的上下文、利弊、功能比较、成本/效益讨论等。 具体:每个ADR应该是关于一个AD,而不是多个AD。 时间戳:识别ADR中每个项目何时写入。这对于可能随着时间的推移而变化的方面尤为重要,例如成 ...
提示1-4:通过分组或集群需求创建概述!
提示1-4:通过分组或集群需求创建概述! #requirement #cluster #functional-requirement 分组或集群类似的用例、用户故事、过程、功能、流程、任务或其他功能要求。 为了概述您的系统功能,请在架构文档中仅描述这些组的重要性,而无需详细说明个人要求。 下图显示了一个示例:一些椭圆组(集群)多个要求、功能或用例。其中一些可以在表格中找到。 需求集群 描述 进口处理 从Mandator导入,导入von-PrintShop,从 ...
提示1-7:使用BPMN图来描述功能要求!
提示1-7:使用BPMN图来描述功能要求! #requirement #bpmn #functional-requirement 如果您的利益相关者认为活动图技术性太强,您可以使用BPMN图。业务流程模型符号明确针对业务利益相关者,因此可以被视为描述业务或技术流程的活动图的替代方案。 ...
提示3-10:区分业务和技术背景!
提示3-10:区分业务和技术背景! #context #technical-context #business-context 特别是对于信息系统,您通常可以忽略上下文中基础设施的技术细节,并专注于与领域或业务相关的方面。 但是,如果硬件或技术对您的系统起着重要作用,那么您既需要业务(领域),也需要技术背景。 嵌入式系统(汽车)示例在下图中,您可以找到嵌入式世界的简化示例:左侧部分显示业务(领域)上下文,右侧部分描述技术上下文。 基于网络的系统示例下图显示了具有业务和技 ...
提示3-11:在业务环境中,显示数据流(而不是依赖项)!
提示3-11:在业务环境中,显示数据流(而不是依赖项)! #context #business-context 此提示主要适用于信息系统,较少适用于实时、嵌入式、面向硬件或更面向流程的系统。 您将使用上下文与各种利益相关者进行讨论,这些利益相关者的建模技能可能有限,并且有限(或没有!)UML的知识。 直观地说,许多人将软件系统之间的箭头理解为数据流。(指导)依赖性、关联等UML关系对这些人来说可能相当令人困惑。 因此:在上下文中,通过反转来自UML的通常依赖或方法&#x ...