软件工程中的系统模型

在软件工程中，系统模型是指创建抽象模型来理解待开发系统的过程。这是创建软件时的一个重要步骤，因为借助抽象模型，软件开发人员可以轻松地向客户解释系统的结构和行为。

在本文中，我们将讨论软件工程中的系统模型。

系统模型

系统是由相互关联并执行某些功能的组件组成的集合。捕获并牢记一些关键方面非常重要。关键方面是

• 定义系统内的部分
• 识别这些部分之间的关系类型
• 理解这些部分如何与执行特定功能的整个系统相关联，以及
• 检查整个系统如何与其环境进行交互。

我们可以说，系统模型是一个过程，它使用基于 UML（统一建模语言）符号的图形符号来表示系统的抽象视图。系统模型包含一组相互依赖的元素。这些模型与客户沟通并向他们解释整个系统。

系统视角

抽象模型从不同视角表示系统

• 外部视角：表示系统的上下文。
• 交互视角：处理系统与环境之间的交互。此外，它还处理系统的各个部分。
• 结构视角：模型显示数据结构和系统的组织。
• 行为视角：模型显示系统的动态行为以及它如何响应事件。

系统模型类型

系统模型有四种类型，如下所示

1. 上下文模型

外部视角模型是软件开发中的一个关键步骤。该模型显示正在创建抽象视图的系统如何与环境中的其他系统一起放置。在此步骤中，软件开发人员和利益相关者共同决定要在系统中包含哪些功能。

每当使用系统时，都有许多周边系统需要处理，因为需要它们的 a，这意味着没有任何软件系统是孤立使用的。它定义了系统边界之外的内容。建立系统边界是为了指定系统的外部和内部。系统边界的位置会影响系统的需求。

上下文模型的目的是了解系统将在其中工作的环境，以及周边系统的支持。软件开发人员开发各种架构模型来阐述系统及其与其他系统的关联。

简而言之，我们可以说上下文模型定义了系统如何与其环境交互。

上下文模型示例

下图显示了中心的主要系统，MHC-PMS（精神健康护理患者管理系统）。该系统可用于诊所并帮助他们维护患者记录。它包含各种子系统：患者记录系统、入院系统、处方系统、预约系统、HC 统计系统和管理报告系统。这些子系统连接到主系统。这些子系统支持并与主系统协同工作。

患者记录系统维护所有与患者相关的记录。入院系统保存已入院患者的记录。处方系统跟踪已为患者开出的所有药物。预约系统有助于为患者安排预约。HC 统计系统提供有关就诊患者人数、医生人数等的分析报告。管理报告系统生成并维护患者的每日报告、患者的月度报告、开出的药物及其剂量等。

2. 交互模型

交互视角模型解释了系统组件之间如何相互作用。

交互有三种类型

• 用户交互：涉及用户输入和用户输出。它与用户交互并有助于识别用户需求。
• 系统交互：是待开发系统与其他系统之间的交互。它从系统到系统进行交互，并突出显示通信中可能出现的问题。
• 组件交互：它与同一系统的不同组件进行交互，并有助于理解所提出的系统是否能提供所需的系统性能。

交互模型包含两种图，如下所示

1. 用例图

它由 Ivar Jacobson 于 1987 年在关于用例的文章中提出。它模拟了系统与外部用户或其他系统之间的交互。它是支持需求获取的流行模型，并被纳入UML（统一建模语言）。

这是一个简单的场景，用于解释用户对系统的需求。每个用例都显示一个离散的任务，包括外部系统交互。

用例图示例

最简单的形式是，“传输数据”用例如下所示

用例是一个椭圆形，参与者，即用户或其他系统，显示为火柴人。

该图显示了我们在上下文模型中讨论过的 MHC-PMS 的一个用例。该图有两个参与者：医疗接待员和患者记录系统。在该图中，您可以看到医疗接待员正在发起交易，并且数据被传输到患者记录系统，即它代表将数据上传到PRS（患者记录系统）的任务。UML 中的箭头表示数据流。

接待员必须具有必要的安全权限才能访问 PRS。从主系统 MHC-PMS 传输到 PRS 的数据可以是患者的个人信息、治疗细节等。

为了充分理解，您可以使用表格格式详细说明同一个用例。

传输数据用例的表格描述

如果用例很多，您可以使用复合用例图来描述它们，在一个图中显示多个用例。

复合用例图

您可以看到上面的复合用例图；有五个用例：注册患者、注销患者、传输数据、查看患者信息和联系患者。所有角色都由医疗接待员扮演，这意味着唯一的参与者是医疗接待员，有五个用例。

接待员查看患者是已注册还是未注册；之后，接待员查看患者信息，如联系方式、地址等，然后传输数据并联系患者。

2. 顺序图

它用于对系统组件之间的交互进行建模，也可能涉及外部系统。此图有助于展示参与者与系统内对象之间的交互。它表示在特定用例发生时发生的交互顺序。

顺序图示例

您可以看到下面用于查看患者信息的顺序图。此示例取自 MHC-PMS，其中查看患者信息是 MHC-PMS 提供的一种功能。

我们将看到如何为查看患者信息绘制顺序图，这意味着我们将看到将发生的各种交互序列。

顺序图通过带注释的箭头显示参与者和对象之间的交互。实心带注释的箭头表示请求，响应由虚线带注释的箭头表示。虚线在对象下方绘制，以连接不同的交互序列。

图的顶部列出了参与者，即医疗接待员和对象，即患者信息、MHCPMS 数据库和授权。

如果医疗接待员想查看患者信息，则会发生交互。查看患者信息不是一个单独的活动，而是隐藏在查看患者活动中的各种交互。

最初，医疗接待员将带有患者 ID 和 PID 的请求发送到对象类“P: PatientInfo”以查看患者信息。从“P”请求发送到 MHC-PMS 数据库，同时发送PID（患者 ID）和UID（用户 ID）。信息不是直接提供给医疗接待员，而是首先进行授权，以检查操作是否由授权用户发起，因为它属于安全且私密的信息，不能提供给未经授权的用户，因此将请求发送到授权对象。

名为“Alt”的框显示授权是否OK。如果用户已授权，则仅从数据库返回患者信息到“P: PatientInfo”，然后到医疗接待员。如果授权失败，则会显示一条错误消息，表示您请求的信息无法访问。

垂直矩形框表示对象实例的活动时间。医疗接待员从整个会话的开始到结束都处于活动状态，而授权对象仅在短时间内处于活动状态。因此，您可以看到，为了查看信息，需要进行许多交互序列。

图中显示的所有这些内容都有助于开发人员设计和实现这些内容并保护系统，因此顺序图很重要。

3. 结构模型

结构视角模型表示系统根据构建系统的部分及其关系来组织。结构模型可以是静态模型或动态模型。静态模型表示系统设计的结构，动态模型表示系统在执行期间的组织。当我们想要设计系统架构时，就会创建系统的结构模型。

结构模型有三种类型，如下所示

1. 类图
2. 泛化
3. 聚合 (Aggregation)

我们将逐一理解这些类型。

1. 类图

这是UML中的一种流行图。在创建面向对象的系统模型时，如果系统中显示类及其关联，则使用类图。关联是连接类的类之间的关系。

UML 中的类图描述了不同级别的详细信息。对象类是系统对象的一种类型。

UML 类和关联

让我们了解一下类图是如何创建的。

类名写在矩形框内，两个类之间的关联用实线表示。类图的特点是能够展示关联中包含的对象数量。

您可以在下面看到一个简单的患者和患者记录图

在类图中，患者和患者记录之间的关联是-。关联的两端都标有 1，表示一个患者恰好有一个记录。

MHC-PMS 中的类和关联

在下图中，各种类写在矩形框内。

类是病情、顾问、患者、全科医生、会诊、药物、治疗和医院医生。该图展示了数据实体、它们的关联属性以及这些实体之间的关系。类之间的关联应该很容易显示。

我们可以添加有关类属性和操作的更多信息。我们将看到一个添加更多信息的类图。让我们在类图中看看“会诊”类的属性和操作。

您可以看到上面的图；矩形分为三部分。对象类写在矩形的顶部，类的属性写在中间部分，操作写在底部。

2. 泛化

这是用于管理复杂性的方法。为了便于理解，实体被放置在更通用的类中。在 Java 等面向对象语言中，泛化是通过语言内置的类继承机制实现的。

在泛化中，与高级类相关的操作和属性也与低级类相关，低级类是继承父类属性的子类。

泛化层次结构示例

您可以看到上面的图，其中类，一个更通用的类，通过向上指向的箭头显示。低级类继承父类的所有操作和属性。

高级类是“医生”。低级类是“医院医生”和“全科医生”，泛化为医生。“顾问”和“团队医生”类泛化为医院医生。“实习医生”类和“合格医生”泛化为团队医生。

3. 聚合

UML 提供了类之间一种特殊的关联关系，称为聚合。对象由各种部分组成，聚合模型显示了这些部分。

聚合关联示例

在下图中，“患者记录”是一个对象类，由患者和会诊组成。菱形用于表示类的组成。

4. 行为模型

它是行为视角模型，表示系统的动态行为。行为模型有两种类型

1. 数据驱动建模
2. 事件驱动建模

让我们逐一详细了解这两种类型。

1. 数据驱动建模

这意味着进入的数据必须由系统处理。数据驱动模式是第一个图形软件模型。数据驱动模型表示操作，这些操作包括处理输入数据并生成相关的输出。这些模型用于显示系统中的端到端处理，因此它们有助于需求分析。

数据流图（DFD）是用于跟踪和文档目的的简单图。它有助于理解系统的开发人员。它显示了系统与其环境中的其他系统之间的数据交换。

胰岛素泵操作的活动模型示例

下图显示了胰岛素泵操作的活动模型。您可以在下图中看到处理步骤。这些步骤之间流动的数据表示为对象。您已经知道这是一个用于模拟交互的顺序图。

胰岛素泵订单处理 DFD 示例

胰岛素泵的订单处理 DFD 如下图所示。在此示例中，此模型中使用的符号是用于表示功能框的圆角框，用于表示存储数据，以及用于表示函数之间数据流的箭头。

在此示例中，取血糖，然后通过传感器进行分析。之后，根据血糖，进行所需的胰岛素计算，并将适量的胰岛素给予患者以控制血糖水平。数据以系统化的方式流动以实现目标。

2. 事件驱动建模

这意味着发生了触发系统的事件，该事件可能与数据相关。该模型表示系统对外部和内部事件的响应。

这种建模假设系统有多个状态，事件可能导致状态之间的转换。它用于描绘状态机模型。

状态机模型将系统状态表示为节点，将事件表示为节点之间的弧。事件驱动建模通过状态图来表示，状态图基于状态图。

状态图示例

您可以在下面看到一个微波炉的状态图，但真实的微波炉比这个状态图复杂得多。

在此示例中，使用简单的微波炉来轻松理解状态图。微波炉有一个选择半功率或全功率的开关，一个用于输入烹饪时间的数字键盘，一个字母数字显示屏和一个开始/停止按钮。

当微波炉功率为 250 瓦时，显示屏显示半功率。当微波炉功率指定为 500 瓦时，显示屏显示全功率。

我们假定微波炉的操作顺序如下：第一个顺序是选择功率级别，半功率或全功率；第二个顺序是使用字母数字键盘输入烹饪时间，然后第三个顺序是按下开始按钮。之后，将出现两个条件：“门打开”和“门关闭”。如果门是打开的，则操作无效。如果门是关闭的，则设置计时器，并且操作生效。当微波炉启动时，将进行特定时间的烹饪。烹饪时间结束后，蜂鸣器响起，微波炉显示屏返回到等待状态。

结论

• 在本文中，我们了解了软件工程中的系统模型。
• 系统有四个视角：外部、交互、结构和
• 系统有四种模型：上下文、交互、结构和行为。
• 上下文模型显示了系统的环境。
• 交互模型显示了系统各部分与环境之间的交互。
• 结构模型显示了系统的结构和组织。
• 行为模型显示了系统的动态行为。