小组EA作业GA003

1.Complete Composite Structure Diagram

在这里插入图片描述

该图显示描述组件的组成的组件层次结构。组件上的复合标记表示用户可以深入到另一个图。

在这里插入图片描述

该图显示表示组成组件的组件的部件,以及流经连接组件部件的接口和端口的信息项。
在这里插入图片描述
该模式的目的是允许设计师和架构师描述组件的组成,以及这些组件(其他组件)如何“连接”在一起以执行组件的工作。信息流充当管道,携带信息项连接显示信息的接口,其他有效载荷从一个组件移动到另一个组件。
模式通常在设计或实现阶段使用,通过描述组件(其他组件)之间的交互来显示复合组件或复杂组件如何交付价值。
它可以用来分解显示系统逻辑部分如何产生和消费信息的组件层次结构。

下面列出了使用此模式时可能需要执行的一些操作。
通过添加或删除组件来更改层次结构。
更改组件、部件和接口的名称以适合您的计划。
在接口元素中更改和创建其他操作。
向类添加属性以描述概念的属性。
以下是应用该模式时的一些后续步骤的列表。
创建额外的层次结构和复合结构图来表示部件之间的交互作用。
创建一个或多个序列图,以显示组件之间消息的时间顺序。
为其他访问群体创建组件文档。

2.Basic Use Case Model with Collaboration

在这里插入图片描述

目的:
是允许业务分析师和其他涉众描述参与者(用户扮演的角色)在与系统交互时想要实现的价值。

该模式通常用于计划的分析阶段,可用于实现任意数量的需求,并作为为实现团队提供规范的一种方式。它可用于:
描述由用例定义的交互是如何由协作元素执行的。

下面列出了使用此模式时可能需要执行的一些操作:
更改系统边界的名称以适应方案。
更改参与者和用例的名称以适合该方案。
添加描述来描述用例提供的价值。
以下是应用该模式时的一些后续步骤的列表。
使用场景生成器定义一个或多个用例中的详细步骤。
生成一个行为图,直观地描述详细的步骤。
在用例和需求之间创建跟踪关系。
在用例和实现它们的组件之间创建实现关系。
使用扩展、包含和泛化关系构建用例模型。

3.Component Interfaces with JSON Payload

在这里插入图片描述
该图显示了通过端口和接口进行通信的两个组件。
JSON负载被定义为一个信息流,允许用户深入到建模的有效负载元素。

在这里插入图片描述

该图显示了与图中折叠的端口和接口通信的两个组件,以向非技术受众隐藏详细信息。

在这里插入图片描述
该图显示了一个序列图,其中有两个组件与端口和接口通信。该图允许可视化按时间排序的消息流。

目的
描述两个组件如何通过端口和接口进行通信,并显示两个接口之间的信息流。传递的信息项(有效载荷)也被建模,并且可以作为模型中的元素找到。

该模式通常用于计划的设计或实现阶段,设计师或架构师需要描述系统组件之间如何通信。正式描述接口(包括接口提供的方法或服务)也很有用。

下面列出了使用此模式时可能需要执行的一些操作。
更改组件、端口和接口的名称以适合您的计划。
更改接口操作的名称以适合您的计划。
更改信息流所传递的名称或元素,以适合您的计划。

下面列出了使用此模式时可能需要执行的一些操作。
创建描述系统重要逻辑部分的附加组件和接口。
向接口添加操作以描述接口提供的方法或服务。
创建序列图,直观地记录按时间顺序调用消息。

4.Single Device with Execution Environment

在这里插入图片描述
通常,当在企业级或模式级定义了一种方案和模式时,或者一个设备都需要将进一步专门化为制造商的设备,代表一个组织所做的技术选择。

例如,一个组织可能已经为网络路由器选择了一个特定的供应商,并且通常会有一个给定供应商产品的多个不同型号。

下面列出了使用此模式时可能需要执行的一些操作。
更改包和图表的名称以适合该计划。
更改节点、工件和部署描述符的名称,以适应该计划。
为元素添加注释,以描述它们的用途和功能。
在包或关系图中添加或删除元素以适应计划。
向通信路径末端添加多重性以反映基数。
以下是应用该模式时的一些后续步骤的列表。
如果需要,可以将层次结构扩展到另一个级别。
创建另一个部署图以显示设备如何相互作用。
定义跟踪关系,显示设备如何与上游流程元素(如组件、需求)和跨流程元素(如工件和数据库表)相关。
使用内置或用户定义的模板创建从模型自动生成的高质量文档。

5.Two level Class Type Hierarchy with Attributes

在这里插入图片描述

目的:
允许分析员和其他涉众创建或查看讨论域中重要事物的分类法,该分类法可分为两个级别。

这种模式通常在项目的早期使用,作为分析领域中“事物”的家族特征的一种方式。该模式也有助于共享知识和理解,并有助于确保所有利益相关者对一个领域的要素及其类型化的方式有一个共同的理解。它还为重用提供了基础,允许使用更通用的元素版本,除非需要专用的元素。

下面列出了使用此模式时可能需要执行的一些操作。
更改包的名称和图表以适合该计划。
更改类的名称以适应计划。
添加一个或多个泛化集来对关系进行分组。

创建其他类以将层次结构向下扩展到另一个级别。 以下是应用该模式时的一些后续步骤的列表。 在系统描述中添加对其角色的描述。 如果需要,向层次结构中添加另一个级别。 添加一个或多个状态机来描述特定类可以显示的离散状态。 使用内置或用户定义的模板,使用文档生成器自动生成文档。