基于模型的系统工程(MBSE)服务建模技术详解

本文深入探讨了如何使用基于模型的系统工程方法进行服务建模,详细介绍了UAF框架中的服务视点、服务分解结构、接口设计以及服务与能力需求的追踪关系,为系统架构师提供实用的建模技术指导。

基于模型的系统工程(MBSE)服务建模

基于模型的系统工程(MBSE)在政府和行业数字化转型推动下持续展现强劲的增长势头。企业架构(EA)是特别受益于MBSE应用的领域之一。在之前的文章《使用基于模型的系统工程建模能力》中,我们讨论了EA的一个领域——能力及其建模的好处。在本博客文章中,我们将探讨EA的另一个领域:作为架构概念的服务使用,它提供了业务和IT实体成功对齐的方法。

服务建模将帮助实践中的业务架构师、企业架构师和解决方案架构师通过面向服务的架构视角呈现功能组。系统工程师也可以在其能力分解和进一步的架构分析中使用服务概念。

本文探讨了使用MBSE和OMG统一架构框架(UAF)设计服务的方法,特别是在服务建模中使用UAF的服务视点。我们将服务展示为连接能力、操作活动和底层软件解决方案的抽象层。建模服务与这些类型对象之间的关系可能会揭示需要进一步分解被分析的服务、能力和操作活动。服务建模可以发现现有的功能差距或已购买/部署软件的重叠。在本文中,我们将证明服务分解能清晰区分服务接口和功能。

服务在架构分解中的作用

UAF将服务定义为"展示能力或支持操作活动所需的规范以及这些规范提供的服务水平"(图1)。

服务规范定义了能够执行特定业务功能、流程、事务或操作的对象。例如,客户关系管理(CRM)工具可以建模为负责管理客户档案、联系人管理、销售活动客户行为趋势分析等的服务。CRM服务可能协助发送定制通知,扮演跨职能团队的协作和沟通工具角色,提供客户偏好分析以及许多其他持续活动。

图2所示的CRM服务可以执行"发送定制通知"和"提供客户偏好"活动,这些活动代表日常业务操作并展示两种能力。真实世界的模型将揭示更复杂的结构,将服务与能力以及业务需求相匹配。

例如,如图3所示,服务规范可以包括与流程自动化、报告生成或访问控制相关的高级业务需求。现在,CRM服务可以追溯到它应该满足的业务需求,以确保使用依赖图(如图4所示)的服务规范完整性。

一旦服务与已识别的能力和已知需求匹配,任何现有系统或评估平台都可以作为实现服务的资源引入模型。

选择的CRM工具可能不包含所有必需的能力。它可以通过商业智能系统、消息服务、规划工具等进行增强。

可以构建类似于图6的依赖图来追踪服务相关的资源。这种类型的图可以展示所有服务,包括冗余平台,以及建模或分析中的任何差距。图6显示Pipedrive和Salesflare尚未追溯到CRM服务。

另一方面,服务可能由多个工具实现,一个工具可能提供各种能力,可以匹配到多个服务。例如,如图7所示,Norton Deluxe提供防病毒和恶意软件防护、诈骗防护、密码管理器、云备份、VPN、家长控制和其他服务。

服务分解与结构

在UAF领域元模型(DMM)中,服务被描述为一种启用对一个或多个能力访问的机制,其中访问使用规定的服务接口提供,并与服务约束和政策一致执行,如图8所示。网络安全领域的服务示例包括用户或设备授权和认证、访问管理、身份管理、敏感信息保护、静态代码分析、加密和安全监控。

让我们更仔细地看看敏感信息保护作为服务的一个例子。假设被调查系统操作和存储敏感信息,其核心网络安全能力之一将是敏感信息保护。为了实现这一能力,架构师需要考虑如何发现、识别/验证敏感信息并将其标记为敏感信息,以及如何在静止状态和传输过程中保护敏感信息。甚至在选择任何具体解决方案之前,可以识别相关功能的高级分组作为服务,并且必须阐明相应的业务规则、条件和政策。因此,敏感信息的发现、识别、验证和标记(以及相应的数据集)以及在传输过程中的保护可以使用UAF及其建模语言建模为服务,如图9所示。

根据定义,服务接口是声明服务方法和服务消息处理程序的契约,这些定义了服务之间的交互。服务接口可以包括执行活动或操作所需的规范。服务分解可以建模为代表服务行为的函数。服务函数指定服务可以执行的活动。

图10显示了高级服务(如"敏感信息扫描器"服务)如何分解为更具体的服务:“敏感信息发现”、“敏感信息验证"和"敏感信息标记”,并识别了接口和函数。接口应建模为独立元素以便重用,并用作位于服务上的服务端口的类型。为了说明这一点,在图10的服务结构视图中,第二层"敏感信息发现"服务有一个由"敏感信息发现"接口类型的服务端口,并通过<能够执行>关系链接到行为元素服务函数"发现敏感信息"。进一步的建模可以像CRM示例所示,向服务函数添加活动和实现可追踪性。

真实世界的服务有约束服务的业务规则和条件。为了建模这些,架构师可以使用称为服务策略的元素,可以在特定服务的上下文中创建,并且是UAF中称为规则的抽象元素的约束类型,如图8中的策略1和策略2所示。

在分解服务之后,架构师可能需要建模这些服务如何相互连接和交换信息。在我们的示例中,“敏感信息扫描器"服务从"敏感信息监控"服务接收信号,第二层服务交换信息,例如提供给发现服务的潜在敏感信息位置以及用于验证或标记服务的敏感信息(图11)。

图12下方的依赖矩阵显示了模型中服务之间的所有连接类型。“敏感信息监控"服务通过分配了信息交换的服务关联与"敏感信息扫描器"服务交互。构成"敏感信息扫描器"服务的服务使用服务连接器、端口到端口,并分配了信息交换,以与上述相同的方式相互交互。该矩阵是批量分析服务间连接性、识别错误连接的服务或缺失连接以及如果其中一个服务发生变化时受影响服务的有用工具。

UAF服务可用性总结

UAF服务在连接能力和操作活动到代表软件和物理资源抽象层的规范框架中扮演重要角色。服务规范可以追溯到高级业务需求,以确保需求的全面覆盖。随着架构师执行能力和操作流程的分解,服务结构可以演变。在此过程中,服务关系和函数开始塑造底层资源的设计。服务接口可用于为资源交互、交换信息、API设计等分析奠定基础。

架构师可以利用基于服务的可追踪性分析来提高对现有系统中潜在功能差距和获取平台冗余的认识。包括服务的可追踪性矩阵可以促进影响分析,通过服务视角提供操作环境的视图。在任何技术细节变得清晰之前,服务建模可以在新产品和系统的规范中发挥关键作用。

comments powered by Disqus
使用 Hugo 构建
主题 StackJimmy 设计