软件工程领域建模

领域建模被理解为抽象建模。站点模型可以是在缺陷域中显示的想法或对象的说明。它还捕获了这些对象之间的明显关系。这类抽象对象的样本区域单位为图书、图书登记簿、会员登记簿、图书馆会员等。

建议的策略是快速生成一个粗略的抽象模型，只要压力是发现需求中表达的明显想法，而推迟深入的调查。后来在整个事件方法中，抽象模型被逐步地细化和扩展。领域分析中已知的3种对象。

整个领域分析中已知的对象分为3种类型：

• 边界对象
• 控制器对象
• 实体对象

边界和控制器对象从用例图中是一致的，而实体对象的标识需要应用。因此，领域建模活动的关键是发现实体模型。

在整个域分析中已知的对象的不同样式及其关系单元的区域如下所示：

边界对象：

边界对象区域单位是参与者移动的对象。这些包括屏幕、菜单、窗体、对话框等。边界对象区域单元主要负责用户交互。因此，它们通常不包含任何流程逻辑。但是，它们将负责确认输入、格式、输出等。边界对象早先被称为接口对象。然而，术语interface category用于Java、COM/DCOM和UML，其含义完全不同。对于边界类别的初始标识的建议是，为每个参与者/用例尝试概述一个边界类别。

实体对象：

这些通常保存信息，如信息表和文件，这些信息表和文件需要比用例执行更持久，例如Book、bookrister、LibraryMember等。几个实体对象区域单元“dumb server”。他们通常负责存储信息，赢得信息，并执行一些基本的操作风格，通常不会修改。

控制器对象：

控制器对象协调实体对象集合的活动，并与边界对象接口以生成系统的一般行为。分配给控制器对象区域单元的职责，与特定用例的信念密切相关。控制器对象有效地将边界对象和实体对象相互解耦，从而创建一个能够容忍计算机程序和过程逻辑变化的系统。

控制器对象体现了应用实例实现中提交的大部分逻辑（此逻辑可能会不时修改）。控制器对象与边界和实体对象的典型交互如下图所示。通常，每个用例都是一个控制器对象的完全牺牲品。然而，一些用例是完整的，而不损害任何控制器对象，即仅通过边界和实体对象。这通常是真实的使用案例，赢得只是一些简单的操纵信息保留。

例如，让我们考虑一下图书馆数据系统（LIS）的“查询图书可用性”用例。实现就业情况涉及到只匹配给定的图书名称与目录中提供的图书。其他复杂的用例可能需要相当多的控制器对象来理解用例。一个奇特的用例将有许多控制器对象，比如组操作管理器、资源安排器和错误处理程序。当用例有相当一个控制器对象时，就会出现另一种状态。一般情况下，雇佣案例需要控制器对象通过各种状态进行传输。

在这种情况下，可能需要为每个雇用案例的执行创建一个控制器对象。

软件工程中的分析建模

分析模型是系统的技术表示。它是连接系统描述和设计模型的纽带。在分析建模中，定义系统的信息、行为和功能，并在设计建模中转换为体系结构、组件和接口级设计。

分析建模的目标：

1. 它必须建立一种软件设计的创作方式。

2. 它必须描述客户的要求。

3. 它必须定义一组需求，一旦软件被构建，这些需求就可以被验证。

分析模型要素：

数据字典：

它是由软件使用或产生的所有数据对象的描述组成的存储库。它存储软件中存在的数据集合。它是分析模型中非常关键的元素。它充当一个集中的存储库，还可以帮助对软件需求期间定义的数据对象进行建模。

实体关系图（ERD）：

它描述了数据对象之间的关系，并用于进行数据建模活动。实体关系图中每个对象的属性可以使用数据对象描述来描述。它为与数据设计相关的活动提供了基础。

数据流图（DFD）：

它描述了转换数据流的函数，还显示了在从输入移动到输出时如何转换数据。它提供了在信息域分析过程中使用的附加信息，并作为功能建模的基础。它还使工程师能够同时开发功能域和信息域的模型。

状态转换图：

它显示了系统的各种行为模式（状态），还显示了系统中从一种状态到另一种状态的转换。它还提供了由于外部事件的后果而导致的系统行为的详细信息。它通过呈现系统的状态和导致系统改变状态的事件来表示系统的行为。它还描述了由于特定事件的发生而采取的措施。

工艺规范：

它存储数据流图中每个函数的描述。它描述了函数的输入、用于输入转换的算法以及生成的输出。它还显示了对适用于流程的性能特征施加的法规和障碍，以及可能影响流程实施方式的布局约束。

控制规范：

它存储有关软件控制方面的附加信息。它用于指示发生事件时软件的行为以及由于事件的发生而调用哪些进程。它还提供了为管理事件而执行的流程的详细信息。

数据对象描述：

它存储并提供有关软件中存在和使用的数据对象的完整知识。它还提供了实体关系图中数据对象属性的详细信息。因此，它包含所有数据对象及其属性。

需求工程过程

需求工程是定义、记录和维护需求的过程。它是一个收集和定义系统提供的服务的过程。需求工程过程包括以下主要活动：

• 需求引出
• 需求规范
• 需求验证和确认
• 需求管理

需求引出：

它与获取项目领域和需求知识的各种方法有关。领域知识的各种来源包括客户、业务手册、相同类型的现有软件、标准和项目的其他利益相关者。

用于需求获取的技术包括访谈、头脑风暴、任务分析、Delphi技术、原型设计等。启发不能产生所理解需求的正式模型。相反，它拓宽了分析师的领域知识，从而有助于为下一阶段提供输入。

要求规范：

此活动用于生成正式的软件需求模型。所有的需求，包括功能性需求、非功能性需求和约束，都是由这些模型整体规定的。在说明过程中，可能需要更多关于问题的知识，这可能再次触发启发过程。

这个阶段使用的模型包括ER图、数据流图（DFD）、功能分解图（FDD）、数据字典等。

需求验证和确认：

Verification：指确保软件正确实现特定功能的一组任务。

Validation：它是指一组不同的任务，以确保所构建的软件可跟踪到客户需求。

如果需求没有得到验证，需求定义中的错误将传播到后续阶段，导致大量修改和返工。

此过程的主要步骤包括：

• 要求应与所有其他要求一致，即两个要求不得相互冲突。
• 这些要求在任何意义上都应该是完整的。
• 这些要求应该是切实可行的。

评审、伙伴检查、制作测试用例等是用于此的一些方法。

需求管理：

需求管理是对需求进行分析、记录、跟踪、排序和商定，并控制与相关利益相关者的沟通的过程。这个阶段负责需求的变化性质。应确保SRS尽可能可修改，以便纳入最终用户在后期指定的需求变化。在需求工程过程中，能够系统地、可控地根据需求修改软件是一个极其重要的部分。

原文地址：https://www.geeksforgeeks.org/analysis-modelling-in-software-engineering/