作业GA003-185-18

作业GA003-185-18
课程名称 软件需求分析与建模
班级 18软件工程5班
教导教师 董瑞生
陈丹 1814080902539
李林 1814080902502
日期 2020.10.30

---

目录

---

---

一、Starter Communication Diagram（启动通信图）

该图显示具有两个通过共享消息进行通信的对象的通信图。

初学者通信图模式创建两个对象和一个通信图，显示如何在对象之间交换消息。 消息被编号，指示它们被调用的序列。

该模式的目的是允许Designers和Architects描述Objects将消息调用序列与ny通信 的方式。可以在类或组件图上叠加消息，以显示元素如何通信。

该模式通常用于设计或实现阶段，以通过描述其部件（其他组件)的交互来显示复 合或复杂组件如何传递值）。可用于：显示类、组件和其他分类器之间消息的时间序列。

下面是您在使用此模式时可能想做的一些事情的列表:
1.更改包和图的名称以适应主动。
2.更改元素名称以适应主动。
3.更改消息调用的名称。
4.将属性添加到类中以描述概念的属性。

下面是应用模式时可用的一些下一步步骤的列表。
1.创建其他对象和消息。
2.为其他对象创建对象的文档。

二、Basic Sequence Diagram with Boundary Control and Entity（具有边界控制和实体的基本序列图）

如图， 显示一个序列图和一个演员和三个业务对象的交互以及它们交换的消息。

具有边界控制和实体模式的基本序列图创建元素和序列图，该序列图描述一个参与 者和三个业务对象的交互，显示消息的时间顺序调用。 业务建模图标的使用允许 建模模型-视图-控制器模式（三层）交互。 边界通常表示人机界面，控件表示应 用程序逻辑，实体表示信息或对象的持久性。

其目的是允许元素之间的交互被可视化。 设计人员和实现团队通常将序列图创建为 设计工具或文档目的。 业务建模图标允许对模型-视图-控制器类型的交互进行建 模。消息序列通常可以通知设计决策，或者使操作系统中发现的问题变得清晰。

该模式通常在设计或实现阶段使用，但也可以在完成倡议和需要文档时使用。 可 用于：· 模拟从人机界面（边界)、应用程序处理(控制器)到持久化数据或对象 (实体)的三层交互）。

下面是您在使用此模式时可能想做的一些事情的列表。
1.更改演员和部件的名称以适应该倡议。
2.更改图表名称以适应主动性
3.更改组件中定义的操作名称以适应该倡议。
4.更改交互期间创建的类的名称。

下面是您在使用此模式时可能想做的一些事情的列表。
1.扩展图以包括反映需要分析的序列的其他元素。
2.创建额外的类和其他需要在交互期间使用的元素。
3.使用Visual ExecutionAnalyzer自动创建Sequence并构建、调试、记录、 配置文件实现的系统。

三、Component Interfaces with JSON Payload（组件接口与JSON有效负载）

如图，显示两个组件通过端口和接口进行通信。 JSON有效载荷定义为信息流，允许用户向下钻取建模的有效载荷元素。

如图，显示了图中折叠的两个与Ports和Interfaces通信的组件以隐藏非技术对象的细节。

如图，显示了图中折叠的两个与Ports和Interfaces通信的组件以隐藏非技术对象的细节。

使用JSON有效负载模式的组件接口描述了表示系统逻辑部分的两个组件如何通过端口和接口进行通信。 信息流允许将有效载荷建模并指定为流经连接器的一个或多个信息项。

目的是描述两个组件如何通过端口和接口与每个组件通信，并显示两个接口之间的信息流。 传递的信息项（有效载荷）也是建模的，可以作为模型中的元素找到。该模式通常用于计划的设计或实现阶段，其中Designers或Architects需要描述系统的组件如何相互通信。 正式描述接口也很有用，包括接口提供的方法或服务。

下面是您在使用此模式时可能想做的一些事情的列表：
1.更改组件、端口和接口的名称以适应您的主动。
2.更改接口操作的名称以适应您的主动性。
3.更改信息流传递的名称或元素以适应您的主动。

下面是您在使用此模式时可能想做的一些事情的列表：
1.创建描述系统重要逻辑部分的附加组件和接口。
2.将操作添加到接口中，以描述接口提供的方法或服务。
3.创建序列图，直观地记录消息的时间顺序调用。

四、Node with Component and Artifact Instances（具有组件和工件实例的节点）

如图， 具有组件和工件实例模式的节点创建元素和部署图，该图描述组件实例如何在工件实例中表现出来，而这些实例又可以部署到节点实例中。

该模式的目的是允许设计人员或技术架构师创建或查看虚拟或物理部署环境的模型，包括节点，如机器服务器执行环境，如操作系统、容器、基于软件的服务器。 artifacts和Deployment specification是如何将软件部署到节点或执行环境的。

模式通常用于在企业级别或主动级别定义技术架构时。 可用于：
模拟组件实例如何在可以部署到节点实例的工件实例中显示。

下面是在使用此模式时可能想做的一些事情的列表：
1.更改Package和图表的名称以适应主动性。
2.更改节点、Artifacts和部署描述符的名称以适应该倡议。
3.在元素中添加注释，以描述它们的目的和功能。
4.添加或删除包或图表中的元素以适应主动。

下面是应用模式时可用的一些下一步步骤的列表：
1.该图可以扩展到对部署环境的其他部分进行建模。
2.将图元素的默认外观替换为图像库中的图像，使图更具吸引力。 图像库包含服务器、路由器、网络等的图像。
3.定义跟踪关系，显示设备如何与上进程元素(如组件、需求和跨流程元素(如Artifacts和数据库表)相关。
4.使用内置或用户定义的模板创建从模型自动生成的高质量文档。

五、Structured Use Case Model（结构化用例模型）

如图，显示与参与者的用例图和系统边界中包含的一些用例。 一个演员代表一个系统， 并使用矩形表示法显示。 该模型是通过使用包含、扩展和泛化关系来构建的。

结构化用例模型模式创建元素和结构化用例模型的用例图，其中使用Include关系 对公共文本进行分解，并使用Extend关系删除和建模扩展功能。 专门功能也使用 泛化关系建模。

其目的是要有一个模型来表示Actors（用户角色）希望从系统中派生的值。 结构化模型使业务分析人员能够分解出通用文本和通用功能。

该模式通常是在完成一些分析之后使用的，并且对更简单的用例模型有了理解。结构化模型将通过消除任何冗余以及专门的文本和行为来帮助实现团队。 可用于：
协助实现团队和Ux设计人员比基本用例模型更详细地理解用户-系统交互

下面是您在使用此模式时可能想做的一些事情的列表：
1.更改系统边界的名称以适应主动。
2.更改演员和用例的名称以适应该倡议。
3.添加描述以描述用例提供的值。

下面是应用模式时可用的一些下一步步骤的列表：
1.使用场景生成器在一个或多个用例中定义详细步骤。
2.生成一个行为图，直观地描述详细的步骤。
3.在用例和需求之间创建跟踪关系。
4.在用例和实现它们的组件之间创建实现关系。

---