CN116804933A - 数据转换方法、电子设备及计算机可读存储介质 - Google Patents

Abstract

本申请实施例公开一种数据转换方法、电子设备及计算机可读存储介质，该方法包括：基于第一Typescript代码文件中的声明，以及JSDoc标签和/或注解，生成第一Typescript代码文件对应的UML类图；其中，JSDoc标签和/或注解用于标识Typescript代码文件中类与类之间、类与接口之间、接口与接口之间的关系。本申请实施例，可以基于代码文件中的声明，以及JSDoc标签和/或注解，自动生成代码文件对应的UML类图，可以提高UML类图绘制效率。

Description

数据转换方法、电子设备及计算机可读存储介质

技术领域

本申请涉及计算机技术领域，尤其涉及一种数据转换方法、电子设备及计算机可读存储介质。

背景技术

统一建模语言(unified modeling language，UML)类图是一种静态的结构图，描述了程序的结构化设计，可以呈现程序中类的类名、类的属性、类的方法，以及程序中接口的接口名、接口的属性、接口的方法，以及程序中类之间的关系、类与接口之间的关系、接口与接口之间的关系等，可以帮助理解程序。因此，UML类图在软件设计、分析和评审中使用频繁。

Typescript是一种编程语言，提供了丰富的面向对象编程能力，并且还可以支持装饰器等功能，使得用户可以更加轻松地构建复杂的应用程序。因此，越来越多的程序或软件采用Typescript实现。

与此同时，如何帮助用户提高Typescript代码文件对应的UML类图的绘制效率是业界当前关注的问题。

发明内容

本申请实施例公开了一种数据转换方法、电子设备及计算机可读存储介质，可以提高Typescript代码文件对应的UML类图的绘制效率。

第一方面公开一种数据转换方法，该数据转换方法可以应用于电子设备，也可以应用于电子设备中的模块(例如，芯片)，还可以应用于能实现全部或部分电子设备功能的逻辑模块或软件。下面以应用于电子设备为例进行描述。该数据转换方法可以包括：基于第一Typescript代码文件中的声明，以及JSDoc标签和/或注解，生成该第一Typescript代码文件对应的UML类图；其中，该JSDoc标签和/或注解用于标识第一Typescript代码文件中的类与类之间、类与接口之间、接口与接口之间的关系。

本申请实施例中，可以通过JSDoc标签标识类与类之间、类与接口之间、接口与接口之间的关系，也可以通过注解标识类与类之间、类与接口之间、接口与接口之间的关系。因此，电子设备可以基于代码文件中的声明，以及JSDoc标签和/或注解，自动生成代码文件对应的UML类图，可以提高UML类图绘制效率。并且，这种方式可以保证Typescript代码文件与绘制的UML类图是对应的，可以保证UML类图绘制的准确性。

作为一种可能的实施方式，该基于第一Typescript代码文件中的声明，以及JSDoc标签和/或注解，生成该第一Typescript代码文件对应的UML类图，包括：基于第一Typescript代码文件中的声明，以及JSDoc标签和/或注解，生成该第一Typescript代码文件对应的JSON文件；该第一Typescript代码文件对应的JSON文件包括以下一项或多项：该第一Typescript代码文件中定义的类的信息、该第一Typescript代码文件中定义的接口的信息、与该第一Typescript代码文件关联的Typescript代码文件中定义的类的信息、与该第一Typescript代码文件关联的Typescript代码文件中定义的接口的信息、该第一Typescript代码文件对应的JSON文件中包括的类之间的关系、该第一Typescript代码文件对应的JSON文件中包括的类与包括的接口之间的关系、该第一Typescript代码文件对应的JSON文件中包括的接口之间的关系；基于该第一Typescript代码文件对应的JSON文件，生成该第一Typescript代码文件对应的UML类图。

本申请实施例中，电子设备可以先生成第一代码文件对应的JSON文件，然后再基于JSON文件生成第一代码文件对应的UML类图。这种方式，可以为用户提供对应的JSON文件，从而便于用户之后对修改JSON文件进行修改，进而可以使得电子设备基于修改后的JSON文件对应的调整UML类图和/或代码文件，可以提高代码开发效率和UML类图绘制效率。

作为一种可能的实施方式，该基于第一Typescript代码文件中的声明，以及JSDoc标签和/或注解，生成该第一Typescript代码文件对应的JSON文件，包括：基于第一Typescript代码文件中的导入声明层层解析，获取与该第一Typescript代码文件关联的Typescript代码文件的路径；基于该路径访问对应的代码文件，解析与该第一Typescript代码文件关联的Typescript代码文件中的类声明和接口声明，以及JSDoc标签和/或注解，获取与该第一Typescript代码文件关联的Typescript代码文件中定义的类的信息、定义的接口的信息、标识的关系；解析该第一Typescript代码文件中的类声明和接口声明，以及JSDoc标签和/或注解，获取该第一Typescript代码文件中定义的类的信息、定义的接口的信息、标识的关系；基于该第一Typescript代码文件中定义的类的信息、定义的接口的信息、标识的关系，以及与该第一Typescript代码文件关联的Typescript代码文件中定义的类的信息、定义的接口的信息、标识的关系，生成该第一Typescript代码文件对应的JSON文件。

本申请实施例中，电子设备可以基于第一Typescript代码文件中的导入声明层层解析，这样，可以获取与该第一Typescript代码文件关联的所有Typescript代码文件的路径。基于此，电子设备可以获取到与第一Typescript代码文件关联的Typescript代码文件中定义的类的信息、定义的接口的信息、标识的关系等，从而可以保证基于第一Typescript代码文件对应的JSON文件生成的第一代码文件对应的UML类图的完整性。

作为一种可能的实施方式，该方法还包括：将该第一Typescript代码文件的路径，以及与该第一Typescript代码文件关联的Typescript代码文件的路径放入栈中；其中，该栈中任一个路径的依赖元素位于该路径的上方；一个路径的依赖元素为该路径对应的Typescript代码文件中导入的类或接口所属的Typescript代码文件的路径；在获取该代码文件中定义的类的信息、定义的接口的信息、标识的关系的过程中，具体按照出栈顺序依次解析每个路径对应的Typescript代码文件，获取该每个代码文件中定义的类的信息、定义的接口的信息、标识的关系。

本申请实施例中，栈中的任一个元素的依赖元素可以位于其上方，这样，可以保证任一个元素的依赖元素先于该元素被解析，从而可以按照顺序生成对应的JSON文件，进而可以提高生成JSON文件的效率。

作为一种可能的实施方式，该解析该第一Typescript代码文件中的类声明和接口声明，以及JSDoc标签和/或注解，获取该第一Typescript代码文件中定义的类的信息、定义的接口的信息、标识的关系，包括：生成该第一Typescript代码文件对应的抽象语法树；遍历该抽象语法树，获取该第一Typescript代码文件中定义的类的信息、定义的接口的信息、标识的关系；或者，查询该抽象语法树上的类声明节点和接口声明节点，获取该第一Typescript代码文件中定义的类的信息、定义的接口的信息、标识的关系。

本申请实施例中，由于遍历抽象语法树或者查询抽象语法树的相关节点的速度较快，因此，基于抽象语法树可以快速获取代码文件中类的信息、接口的信息等，从而可以快速准确地生成对应的JSON文件。

作为一种可能的实施方式，该JSDoc标签包括实现关系标签、继承关系标签、聚合关系标签、关联关系标签、组合关系标签、依赖关系标签；该实现关系标签用于标识实现关系，该继承关系标签用于标识继承关系，该聚合关系标签用于标识聚合关系，该关联关系标签用于标识关联关系，该组合关系标签用于标识组合关系，该依赖关系标签用于标识依赖关系；该注解包括第一类型的注解、第二类型的注解和第三类型的注解，该第一类型的注解为类或接口对应的注解，用于标识基于类或接口的关系；该第二类型的注解为方法对应的注解，用于标识基于方法的关系；该第三类型的注解为属性对应的注解，用于标识基于属性的关系。

本申请实施例中，可以通过6种JSDoc标签分别标识实现关系、继承关系、聚合关系、关联关系、组合关系、依赖关系，也可以通过三种类型的注解分别标识基于类或接口的关系、基于方法的关系、基于属性的关系。这样，电子设备在解析代码文件时，快速地获取类与类之间、类与接口之间、接口与接口之间的关系，从而可以快速地生成对应的UML类图。

示例性的，实现关系标签、继承关系标签、聚合关系标签、关联关系标签、组合关系标签、依赖关系标签可以分别对应下述@implements、@extends、@aggregation、@association、@composition、@dependency。第一类型的注解、第二类型的注解和第三类型的注解可以分别对应下述@UMLRelation、@UMLRelationMethod、@UMLRelationAttr。

作为一种可能的实施方式，该方法还包括：在该第一Typescript代码文件对应的JSON文件被修改的情况下，基于该修改后的JSON文件调整该第一Typescript代码文件，和/或该第一Typescript代码文件对应的UML类图。

本申请实施例中，电子设备可以支持根据对应的JSON文件自动调整UML类图，也可以支持根据对应的JSON文件自动调整Typescript代码文件，灵活性和实用性较高。

作为一种可能的实施方式，该方法还包括：在该第一Typescript代码文件对应的UML类图被修改的情况下，基于该修改后的UML类图调整该第一Typescript代码文件，和/或该第一Typescript代码文件对应的JSON文件。

本申请实施例中，电子设备可以支持根据对应的UML类图调整Typescript代码文件，可以提高用户的开发效率。

本申请实施例中，电子设备可以支持根据对应的UML类图调整Typescript代码文件，也可以支持根据对应的UML类图调整JSON文件，灵活性和实用性较高。

作为一种可能的实施方式，该基于该第一Typescript代码文件对应的JSON文件，生成该第一Typescript代码文件对应的UML类图，包括：基于该第一Typescript代码文件对应的JSON文件，通过Canvas画图技术生成该第一Typescript代码文件对应的UML类图。

本申请实施例中，电子设备可以使用Canvas画图技术绘制第一Typescript代码文件对应的UML类图，这样，可以便于在浏览器等页面上显示第一Typescript代码文件对应的UML类图。

第二方面公开一种数据转换方法，该数据转换方法可以应用于电子设备，也可以应用于电子设备中的模块(例如，芯片)，还可以应用于能实现全部或部分电子设备功能的逻辑模块或软件。下面以应用于电子设备为例进行描述。该数据转换方法可以包括：基于第一JSON文件，生成第一JSON文件对应的Typescript代码文件，和/或生成第一JSON文件对应的UML类图；该第一JSON文件包括至少一个类的信息、至少一个接口的信息，以及该至少一个类之间的关系、该至少一个类与该至少一个接口之间的关系、该至少一个接口之间的关系。

本申请实施例中，电子设备可以基于JSON文件自动生成对应的Typescript代码文件，也可以基于JSON文件自动生成对应的UML类图，从而可以提高程序开发效率和UML类图绘制效率。

作为一种可能的实施方式，该方法还包括：在该第一JSON文件对应的Typescript代码文件被修改的情况下，基于该修改后的Typescript代码文件调整该第一JSON文件，和/或该第一JSON文件对应的UML类图。

作为一种可能的实施方式，该方法还包括：在该第一JSON文件对应的UML类图被修改的情况下，基于该修改后的UML类图调整该第一JSON文件，和/或该第一JSON文件对应的Typescript代码文件。

本申请实施例中，基于JSON文件可以调整对应的Typescript代码文件和/或UML类图，基于UML类图可以调整对应的Typescript代码文件和/或JSON文件，这样，可以提高用户使用的灵活性，用户可以根据实际情况选择任一个文件进行调整，不需要针对所有文件一一调整。

第三方面公开一种数据转换方法，该数据转换方法可以应用于电子设备，也可以应用于电子设备中的模块(例如，芯片)，还可以应用于能实现全部或部分电子设备功能的逻辑模块或软件。下面以应用于电子设备为例进行描述。该数据转换方法可以包括：基于第一UML类图，生成第一UML类图对应的Typescript代码文件，和/或生成第一UML类图对应的JSON文件；该第一UML类图包括至少一个类的信息、至少一个接口的信息，以及该至少一个类之间的关系、该至少一个类与该至少一个接口之间的关系、该至少一个接口之间的关系。

本申请实施例中，电子设备可以基于UML类图自动生成对应的Typescript代码文件，可以提高程序开发效率。并且，电子设备也可以基于UML类图自动生成对应的JSON文件，以便于之后可以基于JSON文件进行UML类图和/或Typescript代码文件的调整。

作为一种可能的实施方式，该方法还包括：在该第一UML类图对应的Typescript代码文件被修改的情况下，基于该修改后的Typescript代码文件调整该第一UML类图，和/或该第一UML类图对应的JSON文件。

作为一种可能的实施方式，该方法还包括：在该第一UML类图对应的JSON文件被修改的情况下，基于该修改后的JSON文件调整该第一UML类图，和/或该第一UML类图对应的Typescript代码文件。

本申请实施例中，基于Typescript代码文件可以调整对应的JSON文件和/或UML类图，基于UML类图可以调整对应的Typescript代码文件和/或JSON文件，这样，可以提高用户使用的灵活性，用户可以根据实际情况选择任一个文件进行调整，不需要针对所有文件一一调整。

第四方面公开一种计算设备，该计算设备包括处理器、存储器，该处理器调用该存储器中存储的计算机程序实现如上述第一方面以及第一方面中任一可能的实现方式中所提供的数据转换方法，或者如上述第二方面以及第二方面中任一可能的实现方式中所提供的数据转换方法，或者如上述第三方面以及第三方面中任一可能的实现方式中所提供的数据转换方法。

第五方面公开一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序或计算机指令，当该计算机程序或计算机指令运行时，实现如上述各方面公开的数据转换方法。

第六方面公开一种芯片，包括处理器，用于执行存储器中存储的程序，当程序被执行时，使得芯片执行上述各方面公开的数据转换方法。

作为一种可能的实施方式，存储器位于芯片之外。

第七方面公开一种计算机程序产品，该计算机程序产品包括计算机程序代码，当该计算机程序代码被运行时，使得上述各方面公开的数据转换方法被执行。

应理解，本申请上述多个方面或者任一种可能的实施方式的实现和有益效果可互相参考。

附图说明

附图为了更清楚地说明本申请实施例技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其它的附图。

图1A-图1F是本申请实施例提供的一组用户界面示意图；

图1G-图1I是本申请实施例提供的另一组用户界面示意图；

图1J-图1L是本申请实施例提供的又一组用户界面示意图；

图2A是本申请实施例公开的一种系统架构示意图；

图2B是本申请实施例公开的另一种系统架构示意图；

图3是本申请实施例公开的一种数据转换方法的流程示意图；

图4是本申请实施例公开的一种UML类图的示意图；

图5是本申请实施例公开的另一种数据转换方法的流程示意图；

图6是本申请实施例公开的又一种数据转换方法的流程示意图；

图7是本申请实施例公开的又一种数据转换方法的流程示意图；

图8是本申请实施例公开的又一种数据转换方法的流程示意图；

图9是本申请实施例公开的一种电子设备的结构示意图。

具体实施方式

本申请实施例公开了一种数据转换方法，可以提高Typescript代码文件对应的UML类图的绘制效率、TypeScript软件开发效率等。下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。

为了更好地理解本申请实施例，下面先对本申请实施例的相关技术进行描述。

在UML类图中，类和接口可以使用包含类名、属性(attribute)和方法(method)且带有分割线的矩形来表示。一般情况下，UML类图中主要包括以下几种关系：泛化(继承)(extends)、实现(接口实现)(implements)、关联(association)、组合(Composition)、聚合(aggregation)、依赖(dependency)。UML类图可以用于软件分析和设计，也可以用于软件编码和测试等。

ECMAScript(ES)是一种由ECMA国际(前身为欧洲计算机制造商协会，EuropeanComputer Manufacturers Association)通过ECMA-262标准化的脚本程序设计语言，其广泛应用于万维网。其中，JavaScript、TypeScript等可以理解为ECMA-262标准的实现和扩展。ECMAScript包括多个版本，目前普遍采用的版本为ECMAScript 2015，也称为ECMAScript 6(简称ES6)。

JS对象简谱(JavaScript Object Notation，JSON)是一种轻量级的数据交换格式，它基于ECMAScript的一个子集，采用完全独立于编程语言的文本格式来存储和表示数据。JSON具有简洁和清晰的层次结构，易于人阅读和编写，也易于机器解析。下述简要介绍JSON部分语法规则：(1)JSON使用键值对(key:value)表示对象属性和值，(2)JSON使用逗号“，”分隔多条数据，(3)JSON使用花括号{}表示对象，(4)JSON使用方括号[]表示数组。

超文本标记语言(hypertext markup language，HTML)是一种可以用于创建网页的标准标记语言。HTML脚本可以运行在浏览器上，由浏览器来解析。

JavaScript(JS)是一种解释型或即时编译型的编程语言，为ECMA-262标准的实现和扩展。JS代码可以嵌入在HTML脚本中，并且可以运行在浏览器中。

TypeScript是JavaScript的超集，扩展了JavaScript的语法，提供了更多的语言特性，使得用户可以更加轻松地构建复杂的应用程序。例如，相较于JavaScript，TypeScript可以支持接口和类的概念，提供了丰富的面向对象编程能力，并且还可以支持装饰器等功能。装饰器是一种特殊类型的声明，它可以被附加到类声明、方法、属性或参数上。应理解，TypeScript可以通过TypeScript编译器转译为JS代码，可运行在浏览器上。

JSDoc(javascript document)是一个用于JavaScript、TypeScript等的应用程序编程接口(application programming interface，API)文档生成器，其可以将文档注释直接添加到源代码中。JSDoc注释通常放在记录代码之前，并且每个注释一般以/**序列开头，以*/结尾。JSDoc注释中可以添加描述，也可以添加JSDoc标签(如块标签)，以便可以记录程序中类、方法、方法参数等内容。

抽象语法树(abstract syntax tree，AST)是源代码语法结构的一种抽象表示，它以树状的形式呈现，树上的每个节点可以表示源代码中的一种结构。例如，在TypeScript或JavaScript中，AST节点可以表示变量声明、函数声明、属性声明、条件语句、循环语句等语言结构，并且每个节点可以包括与该节点相关的信息，例如节点类型(type)、节点值、节点位置等。

由于Typescript在保留JavaScript的基础上，提供了更多的工具和语言特性，因此，Typescript逐渐成为前端主流的编程语言，越来越多的程序或软件采用Typescript实现。同时，随着软件开发流程的规范化程度越来越高，软件设计和评审的重要程度也越来也高。其中，对于一个软件而言，其所采用的数据结构，在一定程度上决定了软件的稳定性、可维护性、运行效率等，基于此，在软件的评审中，软件所采用的数据结构通常是评审的重点。而UML类图可以对软件所采用的数据结构进行直观的体现，一般更是软件评审中的主要关注点。

目前，UML类图一般需要用户采用单独的UML类图绘制工具进行绘制，也就是说，UML类图的绘制和软件代码的编写为独立分割的两部分。例如，对于PlantUML类图绘制工具来说，其需要用户掌握它自有的命令行语法，然后根据PlantUML语法编写对应代码脚本才能生成对应的UML类图。并且，PlantUML绘图完成后无法修改。再例如，对于Visio来说，其需要用户进行手动绘制。除了PlantUML、Visio等类图绘制工具之外，还有其它的UML类图绘制工具，但这些工具都需要用户额外进行一定的操作，并且，UML类图的绘制和软件代码的编写为独立分割的两部分，从而导致UML类图绘制效率较低。此外，在实际情况中，还可能存在软件代码与UML类图不统一的情况，也即是人工绘制的UML类图和软件代码中定义的关系不统一，例如，软件代码中定义的某两个类的关系为组合关系，但是由于人工绘制的不可控性，导致在UML类图中将这两个类绘制为了聚合关系。

为了解决上述问题，本申请实施例中，提供一种数据转换方法。通过该数据转换方法，可以根据Typescript代码文件自动生成对应的UML类图，可以提高UML类图绘制效率，并且，这种方式还可以避免Typescript代码文件与绘制的UML类图不统一的问题，可以提高UML类图绘制的准确性。同时，本申请实施例中，还支持根据JSON文件生成或调整对应的UML类图，便于用户对UML类图进行调整。此外，本申请实施例中，还支持基于UML类图生成(或者调整)Typescript代码文件和对应的JSON文件，实用性和灵活性较高。

下面结合应用场景，以电子设备的显示界面为例，介绍本申请实施例涉及的一种数据转换方法。

请参见图1A，图1A是本申请实施例提供的一种用户界面示意图。如图1A所示，电子设备的显示器(如显示屏)可以显示有用户界面101，该用户界面101中显示了一个放置有应用图标的页面，该页面可以为电子设备的应用桌面，电子设备可以是任何带有显示屏幕的终端设备，例如，笔记本电脑，台式电脑，平板电脑，手机等终端设备。该页面可以包括显示有时间、日期等信息的任务栏和多个应用图标，例如，该页面中可以包括电子邮件应用图标、计算器应用图标、文件应用图标、音乐应用图标、浏览器应用图标、天气应用图标、代码编辑器应用图标1011等。

用户可以通过鼠标双击代码编辑器应用图标1011，响应于该双击操作，电子设备可以启动代码编辑器，显示代码编辑器页面，可以参见图1B所示的用户界面102。在用户界面102中，左侧可以包括src目录下的各个文件，包括Teacher.ts、Student.ts、People.ts等代码文件。示例性的，当前界面中显示的为Teacher.ts代码文件的具体内容。为了生成Teacher.ts代码文件对应的JSON文件和UML类图，用户可以在Teacher.ts代码文件的显示区域单击鼠标右键，可以打开对应的操作菜单1012。操作菜单1012中可以包括运行当前程序、调试当前程序、启动TSToUML插件1013、剪切、复制和粘贴等菜单项。用户可以通过鼠标单击启动TSToUML插件1013菜单项，响应于该操作，电子设备可以显示用户界面103。

如图1C所示，用户界面103中可以包括信息提示框1014，信息提示框1014中可以包括“正在解析Teacher.ts文件，生成对应的JSON文件和UML类图，请等待...”。当电子设备解析完成之后，可以生成Teacher.ts代码文件对应的UML类图和JSON文件，可以显示用户界面104。

如图1D所示，在用户界面104中，可以显示有Teacher.ts代码文件对应的UML类图，并且，在src目录下，生成了Teacher.ts代码文件对应的Teacher.json文件1015。本申请实施例中，可以支持将UML类图导出为PNG(portable network graphics，便携式网络图形)格式文件、JPG(joint photographic experts group，即联合图像专家组)格式文件、PDF(portable document format，可携带文件格式)文件等。如果用户需要导出，可以在UML类图的显示区域单击鼠标右键，可以打开对应的操作菜单1016。操作菜单1016中可以包括导出为pdf(1017)、导出为jpg和导出为png等菜单项。下面以导出为pdf为例进行说明，用户可以通过鼠标单击导出为pdf(1017)菜单项，响应于该操作，电子设备可以显示用户界面105。

如图1E所示，在用户界面105中，用户可以选择需要存储的位置，当前选择的为桌面。并且，用户可以在文件名输入框1018中输入对应的文件名称进行命名，例如可以为Teacher_uml.pdf。之后，用户可以通过鼠标单击保存控件1019，响应于该操作，电子设备可以将Teacher.ts代码文件对应的UML类图保存到桌面下的Teacher_uml.pdf文件中。

用户可以通过鼠标单击Teacher.json文件1015，可以查看Teacher.json文件1015的具体内容。如图1F所示，在用户界面106中，可以显示有Teacher.json文件1015的具体内容，其中，Teacher.json文件1015中可以包括"uml"对象数组，"uml"对象数组中的一个对象可以与一个类或一个接口对应，并且，每个uml对象可以存储有对应的类的类名、属性、方法、所属的路径、关系等，或者对应的接口的接口名、属性、方法、所属的路径、关系等。

可见，本申请实施例中，电子设备可以基于Typescript代码文件生成对应的UML类图和JSON文件。

本申请实施例中，电子设备也可以支持基于JSON文件生成对应的UML类图和Typescript代码文件，下面对该应用场景进行介绍。

如图1G所示，在用户界面107中，当前在src目录下可以仅包括Teacher.json文件。为了生成Teacher.json文件对应的UML类图和Typescript代码文件，用户可以在Teacher.json代码文件的显示区域单击鼠标右键，可以打开对应的操作菜单1020。操作菜单1020中可以包括启动TSToUML插件1021、剪切、复制和粘贴等菜单项。用户可以通过鼠标单击启动TSToUML插件1021菜单项，响应于该操作，电子设备可以显示用户界面108。

如图1H所示，用户界面108中可以包括信息提示框1022，信息提示框1022中可以包括“正在解析Teacher.json文件，生成对应的Typescript文件和UML类图，请等待...”。当电子设备解析完成之后，可以生成Teacher.json文件对应的UML类图和Typescript代码文件，可以显示用户界面109。

如图1I所示，在用户界面109中，可以显示有Teacher.json文件对应的UML类图，并且，在src目录下，生成了Teacher.json文件对应的Typescript代码文件1023，具体可以包括Teacher.ts、Student.ts、People.ts等代码文件。

本申请实施例中，电子设备也可以支持基于UML类图生成对应的JSON文件和Typescript代码文件，下面对该应用场景进行介绍。

如图1J所示，在用户界面110中，当前在src目录下可以仅包括Teacher_uml.png文件，Teacher_uml.png文件中包括如图1J所示的UML类图。为了生成Teacher_uml.png文件对应的JSON文件和Typescript代码文件，用户可以在Teacher_uml.png文件的显示区域单击鼠标右键，可以打开对应的操作菜单1024。操作菜单1024中可以包括启动TSToUML插件1025、剪切、复制和粘贴等菜单项。用户可以通过鼠标单击启动TSToUML插件1025菜单项，响应于该操作，电子设备可以显示用户界面111。

如图1K所示，用户界面111中可以包括信息提示框1026，信息提示框1026中可以包括“正在解析Teacher_uml.png文件，生成对应的Typescript文件和JSON文件，请等待...”。当电子设备解析完成之后，可以生成Teacher_uml.png文件对应的JSON文件和Typescript代码文件，可以显示用户界面112。

如图1L所示，在用户界面112中，在src目录下，生成了Teacher_uml.png文件对应的JSON文件和Typescript代码文件，具体可以参见矩形框1027部分，可以包括Teacher.ts、Student.ts、People.ts等代码文件以及Teacher.json文件。

可见，本申请实施例中，电子设备可以基于Typescript代码文件生成对应的UML类图和JSON文件，也可以基于JSON文件生成对应的UML类图和Typescript代码文件，还可以基于UML类图生成对应的JSON文件和Typescript代码文件。这样，用户可以通过TSToUML插件灵活地进行转换，不需要分别对每个文件进行对应的修改，可以极大地提高UML类图绘制效率、开发效率等。并且，在上述应用场景中，触发方式为用户通过鼠标单击启动TSToUML插件菜单项，这种触发方式简单便捷，便于用户操作，可以提高用户体验。

可以理解的是，上述以代码编辑器的插件示意本申请实施例的应用场景，但在本申请的另一些实施例中，也可以以小程序、浏览器等方式进行呈现，本申请实施例对此不作限定。

需要说明的是，图1A-图1L所示的用户界面只是示例性说明，并不对其构成限定。在本申请另一些实施例中，上述用户界面可以显示有更多或更少的控件、内容等，或者可以以不同的方式进行内容的排版布局等。应理解，相关描述还可以参考下述图3、图5、图6、图7和图8所示实施例中的描述，在此不再详细赘述。

为了更好地理解本申请实施例，下面先对本申请实施例的系统架构进行描述。

请参阅图2A，图2A是本申请实施例公开的一种系统架构示意图。如图2A所示，该系统架构可以包括电子设备200。电子设备200可以为手机终端、平板电脑、笔记本电脑、台式电脑、服务器等，本申请实施例在此不作限定。

其中，电子设备200可以包括编码工具201，编码工具201可以为支持Typescript的代码编辑器，如Visual Studio Code(VScode)、Webstorm等编辑器。

本申请实施例中，编码工具201可以包括UML类图转换插件2011，该插件可以扩展编码工具201的功能，使其支持UML类图转换。具体地，UML类图转换插件2011可以支持基于Typescript代码文件生成对应的UML类图，也可以支持基于JSON文件生成对应的UML类图，还可以支持基于Typescript代码文件生成对应的JSON文件，还可以支持基于JSON文件生成对应的Typescript代码文件。此外，本申请实施例中，UML类图转换插件2011还可以支持基于UML类图生成或者调整对应的Typescript代码文件和JSON文件。例如，电子设备200可以接收用户针对UML类图的创建、修改、删除等操作，然后可以基于这些操作生成、修改或删除对应的Typescript代码文件和JSON文件。示例性的，上述TSToUML插件可以为UML类图转换插件2011。

在一种可能的实现方式中，UML类图转换插件2011也可以作为独立的应用程序，不用作为插件内置在编码工具201中。请参阅图2B，图2B是本申请实施例公开的另一种系统架构示意图。如图2B所示，该系统架构可以包括电子设备200，电子设备200可以包括UML类图转换模块202。

其中，UML类图转换模块202可以支持基于Typescript代码文件生成对应的UML类图，也可以支持基于JSON文件生成对应的UML类图，还可以支持基于Typescript代码文件生成对应的JSON文件，还可以支持基于JSON文件生成对应的Typescript代码文件，还可以支持基于UML类图生成或者调整对应的Typescript代码文件和JSON文件。

在一种可能的实现方式中，电子设备200的UML类图转换模块202可以接收(如通过浏览器请求接收)来自其它设备的Typescript代码文件或者JSON文件，以及可以基于接收到的Typescript代码文件或者JSON文件生成对应的UML类图，并向对应的设备返回UML类图。此外，电子设备200的UML类图转换模块202还可以接收用户针对UML类图的创建、修改、删除等操作，然后可以基于这些操作生成、修改或删除对应的Typescript代码文件和JSON文件，并向对应的设备返回Typescript代码文件和JSON文件。

需要说明的是，本申请实施例中，上述UML类图转换插件2011和UML类图转换模块202还可以支持将UML类图导出为PNG格式文件、JPG格式文件、PDF文件等。

在一种可能的实现方式中，Typescript代码文件、与Typescript代码文件对应的JSON文件和与Typescript代码文件对应的UML类图之间存在关联关系，可以相互影响，基于此，电子设备200可以动态地对Typescript代码文件、JSON文件、UML类图等进行调整。这种情况下，Typescript代码文件的调整可以导致对应的JSON文件和UML类图进行调整，JSON文件的调整也可以导致对应的Typescript代码文件和UML类图进行调整，UML类图的调整也可以导致对应的Typescript代码文件和JSON文件进行调整。这样，当Typescript代码文件、JSON文件和UML类图中的任意一个发生变化，均可以自动进行调整，不需要人工进行调整，从而可以提高UML类图绘制效率、软件开发效率等。

在一种可能的实现方式中，上述UML类图转换插件2011和UML类图转换模块202可以采用JS或Typescript编程语言实现。进一步地，由于JS或Typescript语言编写的程序可以直接运行在浏览器中，因此，在一种可能的实现方式中，电子设备可以将UML类图转换插件2011或UML类图转换模块202对应的代码文件发送(如通过HTML响应发送)给其它设备，以便其它设备可以在本地浏览器中直接运行UML类图转换插件2011或UML类图转换模块202对应的代码文件，以实现基于Typescript代码生成对应的UML类图等功能。在一种可能的实现方式中，在运行UML类图转换插件2011和UML类图转换模块202之前，可以先启动node.js服务，以为JS或Typescript代码程序提供运行环境。

可以理解的是，上述以插件、应用程序等方式示意本申请实施例可能的实现方式，但在本申请的另一些实施例中，也可以通过前端脚手架的方式实现，也可以通过在浏览器中直接运行对应的JS或Typescript代码文件实现，以提供UML类图转换等功能，本申请实施例对此不作限定。

需要说明的是，图2A和图2B所示的系统架构只是示例性说明，并不对其构成限定。在本申请另一些实施例中，可以包括比图2A和图2B所示更多或更少的模块，或者组合某些模块，或者拆分某些模块，或者不同的模块设置。

基于上述系统架构，请参阅图3，图3是本申请实施例公开的一种数据转换方法的流程示意图，通过图3所示的处理流程，可以基于Typescript代码文件生成对应的UML类图。如图3所示，该数据转换方法可以包括但不限于如下步骤：

301.电子设备基于第一Typescript代码文件中的声明和注解，生成第一Typescript代码文件对应的JSON文件。

其中，第一Typescript代码文件可以为存储在电子设备本地的代码文件，也可以为电子设备接收到的来自其它设备的代码文件，本申请在此不作限定。例如，电子设备可以接收用户针对存储在本地的第一Typescript代码文件的UML类图转换操作，该操作用于解析第一Typescript代码文件，并生成第一Typescript代码文件对应的UML类图。响应于UML类图转换操作，电子设备可以解析第一Typescript代码文件中的声明和注解，生成第一Typescript代码文件对应的JSON文件。示例性的，针对存储在本地的第一Typescript代码文件的UML类图转换操作，可以为图1B所示的单击启动TSToUML插件1013菜单项。再例如，电子设备可以接收来自其它设备的UML类图转换请求，该UML类图转换请求中可以包括第一Typescript代码文件，然后电子设备可以基于UML类图转换请求解析第一Typescript代码文件中的声明和注解，生成第一Typescript代码文件对应的JSON文件。UML类图转换请求用于请求解析第一Typescript代码文件生成第一Typescript代码文件对应的JSON文件，再基于第一Typescript代码文件对应的JSON文件生成第一Typescript代码文件对应的UML类图。再例如，电子设备可以直接接收用户输入(如通过浏览器页面中的输入框输入)的Typescript代码，此时，第一Typescript代码文件可以为用户输入的Typescript代码。之后，电子设备可以接收针对第一Typescript代码文件的UML类图转换操作，该操作用于解析第一Typescript代码文件生成第一Typescript代码文件对应的JSON文件，再基于第一Typescript代码文件对应的JSON文件生成第一Typescript代码文件对应的UML类图。响应于UML类图转换操作，电子设备可以解析第一Typescript代码文件中的声明和注解，生成第一Typescript代码文件对应的JSON文件。

本申请实施例中，对于Typescript代码文件中的类、接口、属性、方法等均设置有对应的注解，该注解可以用于标识类与类之间、类与接口之间、接口与接口之间的关系。并且，注解可以位于对应的类声明(ClassDeclaration)、接口声明(InterfaceDeclaration)、属性声明(PropertyDeclaration)、方法声明(MethodDeclaration)等之前。在一种可能的实现方式中，Typescript代码文件中可以自定义@UMLRelation、@UMLRelationAttr、@UMLRelationMethod等三种注解，@UMLRelation可以为类或接口对应的注解，可以位于类声明或接口声明之前，@UMLRelationAttr可以为属性对应的注解，可以位于属性声明之前，@UMLRelationMethod可以为方法对应的注解，可以位于方法声明之前。需要说明的是，Typescript代码文件中可以包括多种类型的注解，本申请实施例中，可以解析@UMLRelation、@UMLRelationAttr、@UMLRelationMethod这三种注解，其它注解可以不用解析。应理解，在另一种可能的实现方式中，可以仅包括一种类型的注解，如@UMLRelation注解，@UMLRelation注解也可以位于属性声明和方法声明之前，或者可以将属性声明和方法声明对应的@UMLRelation注解也放在类声明或接口声明之前。

举例说明，第一Typescript代码文件可以为“Teacher.ts”，“Teacher.ts”具体内容可以如下所示：

在上述示例中，@UMLRelation(People,'extends')和@UMLRelation(Teaching,'implements')注解位于Teacher类的声明之前，@UMLRelation(People,'extends')注解可以标识Teacher类与People类的关系为继承(extends)，也即是Teacher类继承了People类。@UMLRelation(Teaching,'implements')注解可以标识Teacher类与Teaching接口的关系为实现(implements)，也即是Teacher类实现了Teaching接口。@UMLRelationAttr(Student,'aggregation')注解位于Teacher类的students属性声明之前，可以标识Teacher类与Student类的关系为聚合(aggregation)。@UMLRelationAttr(CourseGroup,'association')注解位于Teacher类的group属性声明之前，可以标识Teacher类与CourseGroup类的关系为关联(association)。@UMLRelationAttr(TeachingAptitude,'composition')注解位于Teacher类的teachingAptitude属性声明之前，可以标识Teacher类与TeachingAptitude类的关系为组合(Composition)。@UMLRelationMethod(Course,'dependency')注解位于Teacher类的teaching方法之前，可以标识Teacher类与Course类的关系为依赖(dependency)。应理解，在类声明、接口声明、属性声明、方法声明等之前，可以包括一个或多个对应的注解。还应理解，带有class关键字的代码段可以为类声明，如上述“export class Teacher extends People implements Teaching{……}”代码段，带有interface关键字的代码段可以为接口声明；属性声明可以为声明属性的代码段，如上述“public students:Student[]”、“public group:CourseGroup”等代码段，方法声明可以为声明方法的代码段，如上述“teaching():Course{……}”等代码段。还可以理解的是，属性声明和方法声明可以位于类声明或接口声明的内部。

为了生成第一Typescript代码文件对应的UML类图，电子设备可以解析第一Typescript代码文件中的声明和注解，生成第一Typescript代码文件对应的JSON文件。在一种可能的实现方式中，第一Typescript代码文件对应的JSON文件中可以包括如下信息：第一Typescript代码文件中定义的类的信息、第一Typescript代码文件中定义的接口的信息、与第一Typescript代码文件中定义的类存在关系的类(如存在关联关系的类)的信息、与第一Typescript代码文件中定义的类存在关系的接口(如存在实现关系的接口)的信息、与第一Typescript代码文件中定义的接口存在关系的类的信息、与第一Typescript代码文件中定义的接口存在关系的接口的信息等。此外，第一Typescript代码文件对应的JSON文件中除了包括上述这些类的信息和接口的信息之外，还可以包括这些类与类之间、类与接口之间、接口与接口之间的关系等，以便于可以基于第一Typescript代码文件对应的JSON文件生成第一Typescript代码文件对应的UML类图。例如，上述“Teacher.ts”代码文件对应的JSON文件中可以包括Teacher类的信息、与Teacher类存在继承关系的People类的信息、与Teacher类存在聚合关系的Student类的信息、与Teacher类存在关联关系的CourseGroup类的信息、与Teacher类存在组合关系的TeachingAptitude类的信息、与Teacher类存在依赖关系的Course类的信息、与Teacher类存在实现关系的Teaching接口的信息等。此外，上述“Teacher.ts”代码文件对应的JSON文件中还可以包括Teacher类与People类、Student类、CourseGroup类、TeachingAptitude类、Course类、Teaching接口之间的关系，以及Student类与People类之间的关系等。

其中，类的信息可以包括类的类名、类的属性、类的方法等，接口的信息可以包括接口的接口名、接口的属性、接口的方法等。进一步地，类的属性和接口的属性可以包括属性名、属性的类型、属性的可见性(修饰符)等，类的方法和接口的方法可以包括方法名、方法的参数、方法的返回值、方法的可见性等。例如，上述Teacher类的信息可以包括Teacher类的类名“Teacher”，以及Teacher类的属性[“students:Student[]”，“group:CourseGroup”，“teachingAptitude:TeachingAptitude[]”]，以及Teacher类的方法[“teaching():Course”]。

下面对基于第一Typescript代码文件中的声明和注解，生成第一Typescript代码文件对应的JSON文件的过程进行示例性说明。在一种可能的实现方式中，电子设备可以基于第一Typescript代码文件中的声明和注解，获取第一Typescript代码文件中定义的类的信息、第一Typescript代码文件中定义的接口的信息、与第一Typescript代码文件中定义的类存在关系的类的信息、与第一Typescript代码文件中定义的类存在关系的接口的信息、与第一Typescript代码文件中定义的接口存在关系的类的信息、与第一Typescript代码文件中定义的接口存在关系的接口的信息等，以及这些类与类之间、类与接口之间、接口与接口之间的关系等。并且，可以将这些类的信息、接口的信息，以及这些类与类之间、类与接口之间、接口与接口之间的关系存储到第一Typescript代码文件对应的JSON文件中。

具体地，电子设备可以解析第一Typescript代码文件中包括的类声明和接口声明，可以获取第一Typescript代码文件中定义的类的信息、第一Typescript代码文件中定义的接口的信息。电子设备也可以解析第一Typescript代码文件中包括的导入声明(ImportDeclaration)，基于ES的导入(inport)规则可以获取第一Typescript代码文件中导入的其它类、其它接口所属的代码文件的路径(存储路径)。然后，电子设备可以基于获取的第一Typescript代码文件中导入的其它类、其它接口所属的代码文件的路径去访问对应的Typescript代码文件，解析这些代码文件中包括的类声明和接口声明，可以获取这些Typescript代码文件中定义的类的信息，以及定义的接口的信息。电子设备还可以解析第一Typescript代码文件中包括的注解，可以获取第一Typescript代码文件中定义的类与第一Typescript代码文件中导入的类或接口之间的关系，也可以获取第一Typescript代码文件中定义的接口与第一Typescript代码文件中导入的类或接口之间的关系。电子设备还可以解析第二Typescript代码文件中包括的注解，可以获取第二Typescript代码文件中定义的类与第二Typescript代码文件中导入的类或接口之间的关系，也可以获取第二Typescript代码文件中定义的接口与第二Typescript代码文件中导入的类或接口之间的关系。第二Typescript代码文件可以为第一Typescript代码文件中导入的其它类、其它接口所属的Typescript代码文件中的任一代码文件。可以理解的是，带有import关键字的代码段可以为导入声明，如上述“import{CourseGroup}from"./CourseGroup"”、“import{Course}from"./Course"”等。下面以第一Typescript代码文件为“Teacher.ts”为例进行说明。

电子设备可以解析“Teacher.ts”代码文件中包括的类声明，如Teacher类声明，可以获取Teacher类的信息。电子设备也可以解析“Teacher.ts”代码文件中包括的导入声明，可以获取“Teacher.ts”代码文件中导入的其它类、其它接口所属的代码文件的路径，例如，可以获取到CourseGroup类所属的代码文件的路径“./CourseGroup”、Course类所属的代码文件的路径“./Course”、People类所属的代码文件的路径“./People”、Student类所属的代码文件的路径“./Student”、TeachingAptitude类所属的代码文件的路径“./TeachingAptitude”、Teaching接口所属的代码文件的路径“./Teaching.interface”等。应理解，上述“./CourseGroup”、“./Course”等文件路径可以为缩写，基于ES的导入规则可以确定完整的文件路径为“src/CourseGroup.ts”、“src/Course.ts”，也就是说上述在导入“./CourseGroup”、“./Course”等文件路径时省略了文件后缀“.ts”，以及上层的目录名“src”。当电子设备获取到“./CourseGroup”、“./Course”等文件路径之后，电子设备可以解析这些文件路径下的代码文件，以获取这些代码文件中定义的类的信息、定义的接口的信息。例如，电子设备可以解析“CourseGroup.ts”代码文件，可以获取到“CourseGroup.ts”代码文件中定义的CourseGroup类的信息。再例如，电子设备可以解析“Course.ts”代码文件，可以获取到“Course.ts”代码文件中定义的Course类的信息。

电子设备还可以解析“Teacher.ts”代码文件中包括的注解，例如，电子设备可以解析“@UMLRelation(People,'extends')”、“@UMLRelation(Teaching,'implements')”、“@UMLRelationAttr(Student,'aggregation')”、“@UMLRelationAttr(CourseGroup,'association')”、“@UMLRelationAttr(TeachingAptitude,'composition')”、“@UMLRelationMethod(Course,'dependency')”等注解，可以获取Teacher类与People类、Student类、CourseGroup类、TeachingAptitude类、Course类、Teaching接口之间的关系。电子设备还可以解析第二Typescript代码文件中包括的注解，此时，第二Typescript代码文件可以为“CourseGroup.ts”、“Course.ts”、“People.ts”、“Student.ts”、“TeachingAptitude.ts”、“Teaching.interface.ts”中的任一代码文件。例如，电子设备可以解析“Student.ts”代码文件中包括的注解“@UMLRelation(People,'extends')”，可以获取Student类与People类之间的关系。

需要说明的是，上述为了便于说明，以第二Typescript代码文件为例示意了相关解析过程，但本申请实施例中，当代码文件中导入了其它代码文件中的接口或类时，电子设备可以基于代码文件层层解析，直到当前解析的代码文件未导入其它代码文件中的接口或类。例如，当第一Typescript代码文件中导入了其它代码文件中的接口或类时，电子设备可以基于第一Typescript代码文件层层解析，可以先解析第一Typescript代码文件，然后可以解析第二Typescript代码文件。如果第二Typescript代码文件中也导入了其它代码文件中的接口或类时，电子设备可以继续解析第二Typescript代码文件中导入的类或接口所属的代码文件。例如，“A.ts”代码文件中导入了“B.ts”代码文件中的B类，“B.ts”代码文件中导入了“C.ts”代码文件中的C类。此时，电子设备可以先解析“A.ts”代码文件，然后可以解析“B.ts”代码文件，然后可以解析“C.ts”代码文件。其中，“C.ts”代码文件中未导入其它代码文件中的接口或类，因此，电子设备可以不用继续解析。在一些情况下，基于第一Typescript代码文件层层导入的其它Typescript代码文件可能较多，此时，电子设备可以解析其中的部分代码文件。示例性的，电子设备可以解析基于第一Typescript代码文件导入的前N层代码文件，N为大于或等于1的正整数。例如，当N为1时，电子设备可以解析第一Typescript代码文件和第二Typescript代码文件，对于其它代码文件可以不用解析，如第二Typescript代码文件中导入的类或接口所属的代码文件不用解析。也就是说，当N为1时，电子设备可以解析第一Typescript代码文件，以及第一Typescript代码文件中导入的其它类、其它接口所属的Typescript代码文件。

应理解，一个代码文件中定义的类或接口可以被多个代码文件导入，如上述“Teacher.ts”代码文件和“Student.ts”中均可以导入“People.ts”代码文件中的People类，因此，电子设备解析生成第一Typescript代码文件对应JSON文件时，针对于多次导入的代码文件，可以进行一次解析，可以避免处理资源的浪费。例如，电子设备可以仅对“People.ts”代码文件进行一次解析。

需要说明的是，由于任一Typescript代码文件中均可能导入其它代码文件中定义的类或接口，因此，在一种可能的实现方式中，第一Typescript代码文件对应的JSON文件中可以包括第一Typescript代码文件中定义的类的信息、第一Typescript代码文件中定义的接口的信息，以及与第一Typescript代码文件关联的其它Typescript代码文件中定义的类的信息、与第一Typescript代码文件关联的其它Typescript代码文件中定义的接口的信息，以及这些类与类之间、类与接口之间、接口与接口之间的关系。应理解，与第一Typescript代码文件关联的其它Typescript代码文件可以包括基于第一Typescript代码文件层层导入的代码文件，例如，与第一Typescript代码文件关联的其它Typescript代码文件可以包括第二Typescript代码文件、第三Typescript代码文件。第三Typescript代码文件可以为第二Typescript代码文件中导入的其它类、其它接口所属的Typescript代码文件中的任一代码文件。还应理解，在实际情况下，可能第三Typescript代码文件中还导入第四Typescript代码文件中定义的类或接口，此时，与第一Typescript代码文件关联的其它Typescript代码文件还可以包括第四Typescript代码文件。其中，第四Typescript代码文件可以为第三Typescript代码文件中导入的其它类、其它接口所属的Typescript代码文件中的任一代码文件。

可见，本申请实施例中，基于Typescript代码文件中的导入声明，可以获取到与第一Typescript代码文件关联的其它Typescript代码文件的路径。基于此，电子设备可以通过解析第一Typescript代码文件，以及与第一Typescript代码文件关联的其它Typescript代码文件中的声明和注解，生成第一Typescript代码文件对应的JSON文件。

例如，电子设备通过解析“Teacher.ts”代码文件，以及与“Teacher.ts”代码文件关联的其它Typescript代码文件(如“CourseGroup.ts”、“Course.ts”、“People.ts”、“Student.ts”、“TeachingAptitude.ts”、“Teaching.interface.ts”)中的声明和注解，可以生成“Teacher.ts”代码文件对应的JSON文件，如“Teacher.json”，具体内容可以如下所示：

/>

/>

/>

上述JSON文件中，采用"uml"对象数组存储每个类的类名、属性、方法等，以及每个接口的接口名、属性、方法等。"uml"对象数组中的一个对象(下述简称为uml对象)可以与一个类或一个接口对应，例如，上述"uml"对象数组中的第一个对象可以与Teacher类对应，第二个对象可以与CourseGroup类对应，第三个对象可以与Course类对应。下面对"uml"对象数组中各个字段的含义进行示例性说明，其中，"id"字段可以用于标识一个uml对象，例如，"Teacher_01"可以用于标识"uml"对象数组中的第一个对象，"Course_01"可以用于标识"uml"对象数组中的第三个对象。"type"字段可以用于标识uml对象对应的类型，取值可以包括"class"和"interface"，"class"可以标识类，"interface"可以标识接口。"classname"字段可以用于标识uml对象对应的类名或接口名，例如，"classname":"Teacher"可以标识"Teacher_01"对应的类名为"Teacher"。"path"字段可以用于标识uml对象对应的路径，例如，"path":"src/Teacher.ts"可以标识"Teacher_01"对应的路径为"src/Teacher.ts"。"attr"对象数组可以用于存储uml对象对应的属性，例如上述"Teacher_01"的"attr"对象数组中可以包括Teacher类的三个属性，对应的属性名和属性类型分别为["name":"students","type":"Student[]"]、["name":"group","type":"CourseGroup"]、["name":"teachingAptitude","type":"TeachingAptitude[]"]，此外，"attr"对象数组中的每个对象还可以包括与属性相关的关系标识(identity document，ID)，如"umlRelationId"，以便与"umlRelation"对象数组中的"umlRelationId"匹配。"method"对象数组可以用于存储uml对象对应的方法，例如，上述"Teacher_01"的"method"对象数组中可以存储Teacher类的teaching方法，对应的方法名和方法返回值可以分别为"name":"teaching"，"return":"Course"，此外，此外，"method"对象数组中的每个对象还可以包括与方法相关的"umlRelationId"，以便与"umlRelation"对象数组中的"umlRelationId"匹配。"umlRelation"对象数组可以用于存储uml对象对应的关系，包括继承、实现、组合、聚合、关联、依赖等关系，"umlRelation"对象数组中的每个对象可以包括"umlRelationId"、"relationType"、"id"这三个属性(字段)，其中，"umlRelationId"主要用于与"attr"和"method"对象数组中"umlRelationId"匹配，"relationType"用于标识关系的类型，"id"用于标识存在关系的对象的标识。例如，上述"Teacher_01"uml对象包括的"umlRelation"对象数组中的第一个对象的"relationType"为"extends"，"id"为"People_01"，而"People_01"uml对象与People类对应，基于此，电子设备可以确定Teacher类与People类之间的关系为继承关系。

需要说明的是，上述JSON文件中的"id"字段和"umlRelationId"字段可以根据实际情况或者预设规则自动生成，如根据类名或接口名生成，本申请实施例对此不作限定。

应理解，上述“Teacher.ts”代码文件对应的JSON文件仅是示例性说明，并不对其构成限定。在本申请另一些实施例中，“Teacher.ts”代码文件对应的JSON文件中可以包括更多或更少的内容，或者可以采用不同的JSON数据结构存储信息。例如，可以删除上述"type"、"path"字段，以及"attr"、"method"、"umlRelation"数组中的"umlRelationId"字段。

在一种可能的实现方式中，电子设备基于第一Typescript代码文件中的声明和注解，生成第一Typescript代码文件对应的JSON文件时，可以先生成第一Typescript代码文件对应的AST语法树，然后电子设备可以遍历第一Typescript代码文件对应的AST语法树或者查询AST语法树的相关节点，可以获取第一Typescript代码文件中定义的类的信息、第一Typescript代码文件中定义的接口的信息，以及第一Typescript代码文件中定义的类与第一Typescript代码文件中导入的类或接口之间的关系，以及第一Typescript代码文件中导入的其它类或接口所属代码文件的路径。应理解，通过遍历AST语法树或者查询AST语法树的相关节点，可以快速获取类的信息、接口的信息等，从而可以快速准确地生成对应的JSON文件。

具体地，AST语法树中可以包括导入声明(ImportDeclaration)节点、类声明(ClassDeclaration)节点、接口声明(InterfaceDeclaration)节点，并且，类声明(ClassDeclaration)节点和接口声明(InterfaceDeclaration)节点中可以包括属性声明(PropertyDeclaration)节点、方法声明(MethodDeclaration)节点和注解声明节点等子节点，属性声明节点、方法声明节点也可以包括注解声明节点等子节点。其中，导入声明节点也就是导入声明对应的节点，如上述导入声明“import{CourseGroup}from"./CourseGroup"”可以对应一个导入节点，导入声明“import{Course}from"./Course"”也可以对应一个导入节点。类声明节点也就是类声明对应的节点，如上述类声明“export classTeacher extends People implements Teaching{……}”可以对应一个类声明节点。接口声明节点也就是接口声明对应的节点。属性声明节点也就是属性声明对应的节点，如上述属性声明“public students:Student[]”可以对应一个属性声明节点，属性声明“publicgroup:CourseGroup”也可以对应一个属性声明节点。方法声明节点也就是方法声明对应的节点，如上述“teaching():Course{……}”可以对应一个方法声明节点。注解声明节点也就是注解声明对应的节点，如上述注解声明“@UMLRelation(People,'extends')”可以对应一个注解声明节点，注解声明“@UMLRelationAttr(Student,'aggregation')”也可以对应一个注解声明节点。需要说明的是，@UMLRelation、@UMLRelationAttr、@UMLRelationMethod这三种注解声明在AST语法树上实际对应的节点可以为装饰器(Decorator)节点，因此，解析注解声明节点可以是解析对应的装饰器节点。

电子设备可以解析第一Typescript代码文件对应的AST语法树，基于第一Typescript代码文件对应的AST语法树中的类声明节点和接口声明节点，以及类声明节点和接口声明节点包括的方法声明子节点和属性声明子节点，可以获取到第一Typescript代码文件中定义的类的信息和第一Typescript代码文件中定义的接口的信息。基于第一Typescript代码文件对应的AST语法树中的注解声明节点，电子设备可以获取第一Typescript代码文件中定义的类与第一Typescript代码文件中导入的类或接口之间的关系，也可以获取第一Typescript代码文件中定义的接口与第一Typescript代码文件中导入的类或接口之间的关系。基于第一Typescript代码文件对应的AST语法树中的导入声明节点，电子设备可以获取第一Typescript代码文件中导入的类或接口所属的代码文件的路径，如第二代码文件的路径。同理，基于第二Typescript代码文件对应的AST语法树中的导入声明节点，电子设备可以获取第二Typescript代码文件中导入的类或接口所属的代码文件的路径，如第三Typescript代码文件的路径。针对与第一Typescript代码文件关联的其它Typescript代码文件，电子设备也可以先将这些代码文件转换为对应的AST语法树，然后对这些AST语法树进行解析，具体的解析过程与解析第一Typescript代码文件对应的AST语法树类似，可以参考上述解析第一Typescript代码文件对应的AST语法树的相关描述。电子设备通过解析与第一Typescript代码文件关联的其它Typescript代码文件对应的AST语法树，可以获取与第一Typescript代码文件关联的其它Typescript代码文件中定义的类的信息、与第一Typescript代码文件关联的其它Typescript代码文件中定义的接口的信息，以及这些类与类之间、类与接口之间、接口与接口之间的关系。并且，电子设备可以将获取的信息存储到第一Typescript代码文件对应的JSON文件中。

在一种可能的实现方式中，电子设备在解析第一Typescript代码文件时，可以以栈的方式存储第一Typescript代码文件以及与第一Typescript代码文件关联的其它Typescript代码文件的路径，并且，可以使得栈中的任一个元素的依赖元素可以位于其上方。其中，一个代码文件的依赖元素可以为该代码文件中导入的其它类或接口所属的代码文件。例如，上述“src/Teacher.ts”的依赖元素可以包括“src/CourseGroup.ts”、“src/Course.ts”、“src/People.ts”、“src/Student.ts”、“src/Teaching.interface.ts”、“src/TeachingAptitude.ts”，“src/Student.ts”的依赖元素可以包括“src/People.ts”。栈是一种先进后出的数据结构，取元素时可以先取栈顶的元素，存元素时也可以将元素存在栈顶。示例性的，电子设备可以基于第一Typescript代码文件中的导入声明层层解析，获取与所述第一Typescript代码文件关联的Typescript代码文件的路径。例如，针对于上述“Teacher.ts”代码文件，电子设备基于“Teacher.ts”代码文件中的导入声明层层解析，可以获取到与“Teacher.ts”代码文件关联的其它Typescript代码文件的路径，如“src/CourseGroup.ts”、“src/Course.ts”、“src/People.ts”、“src/Student.ts”、“src/Teaching.interface.ts”、“src/TeachingAptitude.ts”，电子设备可以将“src/CourseGroup.ts”、“src/Course.ts”、“src/People.ts”、“src/Student.ts”、“src/Teaching.interface.ts”、“src/TeachingAptitude.ts”等路径存入栈中，例如，可以“src/CourseGroup.ts”可以位于栈顶，“src/Teacher.ts”可以位于栈底。之后，电子设备可以继续解析“src/CourseGroup.ts”、“src/Course.ts”、“src/People.ts”、“src/Student.ts”、“src/Teaching.interface.ts”、“src/TeachingAptitude.ts”等代码文件中导入的代码文件，可以解析出“src/Student.ts”中导入了“src/People.ts”，“src/CourseGroup.ts”、“src/Course.ts”、“src/People.ts”、“src/Teaching.interface.ts”、“src/TeachingAptitude.ts”中均未导入其它代码文件，因此，电子设备可以将“src/People.ts”放入栈中。之后，电子设备可以继续解析“src/People.ts”，可以解析出“src/People.ts”中未导入其它代码文件，此时，没有其它需要解析的代码文件，电子设备可以停止解析。在一种可能的实现方式中，电子设备可以按照编码顺序或者其它顺序将基于一个代码文件解析出的路径存储到栈中。

当解析完与第一Typescript代码文件关联的其它Typescript代码文件的路径，并且存储到栈中之后，电子设备可以按照出栈的顺序依次解析。当前栈中依次存储的文件路径可以为“src/People.ts”、“src/CourseGroup.ts”、“src/Course.ts”、“src/People.ts”、“src/Student.ts”、“src/Teaching.interface.ts”、“src/TeachingAptitude.ts”、“src/Teacher.ts”。位于栈顶的元素可以为“src/People.ts”，因此，电子设备可以解析People.ts代码文件，解析完People.ts代码文件之后，可以继续解析下一个栈顶的元素“src/CourseGroup.ts”，直到栈为空。可以理解的是，栈中可能包括重复的元素，此时，针对于重复的元素可以在第一次取出的时候解析，下一次从栈中取出的时候可以不用解析。通过上述方式向栈中加入元素，可以使得栈中的任一个元素的依赖元素可以位于其上方，可以避免之后生成JSON文件时一个元素先于该元素的依赖元素被解析，从而可以按照顺序生成对应的JSON文件。此外，在一些情况下，JSON文件中一个代码文件对应的uml对象的内容，需要基于该代码文件依赖的其它代码文件对应的uml对象的内容生成，例如，上述"umlRelation"对象数组中每个对象的"id"字段用于标识存在关系的uml对象的标识，如果未提前解析出与其存在关系的uml对象，当前可能无法填充"umlRelation"对象数组中对应的"id"字段。因此，在采用上述这种方式入栈时，可以保证任一个元素的依赖元素先于该元素被解析，从而可以提高生成JSON文件的效率。

需要说明的是，上述以JSON格式的文件存储第一Typescript代码文件中定义的类的信息、第一Typescript代码文件中定义的接口的信息，以及与第一Typescript代码文件关联的其它Typescript代码文件中定义的类的信息、与第一Typescript代码文件关联的其它Typescript代码文件中定义的接口的信息，以及这些类与类之间、类与接口之间、接口与接口之间的关系。但本申请实施例另一些实施例中，也可以采用其它的文件格式存储上述信息，对此不作限定。其中，JSON格式更符合用户的代码编写习惯，学习和使用成本低，便于用户使用。并且，JSON具有简洁和清晰的层次结构，易于人阅读和编写，也易于机器解析。

302.电子设备基于第一Typescript代码文件对应的JSON文件，生成第一Typescript代码文件对应的UML类图。

电子设备生成第一Typescript代码文件对应的JSON文件之后，可以基于第一Typescript代码文件对应的JSON文件生成第一Typescript代码文件对应的UML类图。

具体地，在第一Typescript代码文件对应的JSON文件中，每一个uml对象可以与一个类或一个接口对应。因此，基于一个uml对象中的"classname"字段、"attr"对象数组和"method"对象数组，电子设备可以绘制UML类图中一个类或一个接口(该uml对象对应的类或接口)对应的带有分割线的矩形，并且可以在矩形的对应部分填充值。基于一个uml对象中的"umlRelation"对象数组，电子设备可以绘制UML类图中一个类或一个接口与其它类或接口的关系连线。以上述“Teacher.ts”代码文件对应的JSON文件为例，基于“Teacher.ts”代码文件中第一个uml对象中的"classname"字段、"attr"对象数组和"method"对象数组，可以绘制出Teacher类对应的带有分割线的矩形。同理，基于“Teacher.ts”代码文件中第二个uml对象中的"classname"字段、"attr"对象数组和"method"对象数组，可以绘制出CourseGroup类对应的带有分割线的矩形。相应地，电子设备也可以基于“Teacher.ts”代码文件中的其它uml对象绘制出Course类、People类、Student类、TeachingAptitude类、Teaching接口对应的带有分割线的矩形。基于“Teacher.ts”代码文件中第一个uml对象中的"umlRelation"对象数组中的第一个对象，电子设备可以绘制出Teacher类与People类之间的继承关系连线。同理，基于“Teacher.ts”代码文件中第一个uml对象中的"umlRelation"对象数组中的第二个对象，电子设备可以绘制出Teacher类与Teaching接口之间的实现关系连线。相应地，电子设备也可以基于“Teacher.ts”代码文件中第一个uml对象中的"umlRelation"对象数组中的其它对象，绘制出Teacher类与Student类之间的聚合关系连线，以及Teacher类与CourseGroup类之间的关联关系连线，以及Teacher类与TeachingAptitude类之间的组合关系连线，以及Teacher类与Course类之间的依赖关系连线。应理解，电子设备还可以基于“Teacher.ts”代码文件中其它uml对象中的"umlRelation"对象数组绘制出其它类与类之间、类与接口之间、接口与接口之间的关系连线，如Student类与People类之间的继承关系连线。电子设备基于“Teacher.ts”代码文件对应的JSON文件绘制出的“Teacher.ts”代码文件对应的UML类图可以参见图4，如图4所示，电子设备绘制出的“Teacher.ts”代码文件对应的UML类图可以包括类的信息、接口的信息、类与类之间的关系、类与接口之间的关系等。

在一种可能的实现方式中，电子设备在绘制第一Typescript代码文件对应的UML类图之前，可以对第一Typescript代码文件对应的UML类图进行调整优化，以为用户呈现更清楚、更简洁的UML类图，便于用户理解，可以提高用户的体验。其中，调整优化可以包括检测交汇节点，调整相同依赖曲线的绘制顺序。其中，如果多个不同的类或接口与同一个类或接口之间具有相同的关系，这一个类可以为交汇节点，并且，这多个不同的类或接口与同一个类或接口之间具有相同的依赖曲线。例如，如图4所示，Teacher类与People类之间、Student类与People类之间均为继承关系，此时，Teacher类与People类之间、Student类与People类之间均为继承依赖曲线，并且，People类为交汇节点。这种情况下，电子设备可以先绘制People类对应的矩形，然后针对于Student类和Teacher类，可以先解析它们的依赖关系，通过解析可以确定Teacher类依赖Student类，因此，电子设备可以先绘制Student类对应的矩形以及Student类与People类之间的继承依赖曲线，然后可以再绘制Teacher类对应的矩形，以及Teacher类与People类之间的继承依赖曲线、Teacher类与Student类之间的聚合依赖曲线。

示例性的，电子设备可以使用Canvas画图技术将第一Typescript代码文件对应的UML类图绘制在HTML界面(浏览器界面)上。并且，可以支持导出JSON格式的第一Typescript代码文件对应的UML类图，以及pdf格式的第一Typescript代码文件对应的UML类图、png格式的第一Typescript代码文件对应的UML类图或者其它格式的第一Typescript代码文件对应的UML类图。其中，Canvas画图技术是一种可以在HTML界面(浏览器界面)画图的技术，可以基于JS或Typescript，以及<canvas>标签动态绘制图形。

可选地，当第一Typescript代码文件发生了修改时，电子设备可以基于修改后的第一Typescript代码文件动态地修改第一Typescript代码文件对应的JSON文件，也可以基于修改后的第一Typescript代码文件动态地修改第一Typescript代码文件对应的UML类图。

应理解，在一些实施例中，电子设备也可以不生成第一Typescript代码文件对应的JSON文件，可以解析第一Typescript代码文件中的声明和注解，直接生成第一Typescript代码文件对应的UML类图。

上述处理流程中，电子设备可以基于第一Typescript代码文件中的声明和注解，自动生成第一Typescript代码文件对应的UML类图，可以提高类图的绘制效率。

需要说明的是，在一种可能的实现方式中，可以在代码文件中编写有JSDoc注释，JSDoc注释可以标识类与类之间、类与接口之间、接口与接口之间的关系。因此，电子设备可以通过解析第一Typescript代码文件中的JSDoc注释，获取第一Typescript代码文件中定义的类与第一Typescript代码文件中导入的类或接口之间的关系，以及第一Typescript代码文件中定义的接口与第一Typescript代码文件中导入的类或接口之间的关系。同理，电子设备也可以通过解析与第一Typescript代码文件关联的其它Typescript代码文件中的JSDoc注释，获取这些代码文件中定义的类与这些代码文件中导入的类或接口之间的关系以及这些代码文件中定义的接口与这些代码文件中导入的类或接口之间的关系。

下面结合图5所示的处理流程进行说明，请参阅图5，图5是本申请实施例公开的另一种数据转换方法的流程示意图，通过图5所示的处理流程，也可以基于Typescript代码文件生成对应的UML类图。如图5所示，该数据转换方法可以包括但不限于如下步骤：

501.电子设备基于第一Typescript代码文件中的声明和JSDoc注释，生成第一Typescript代码文件对应的JSON文件。

在一种可能的实现方式中，类声明、接口声明、属性声明、方法声明之前可以包括对应的JSDoc注释，JSDoc注释中可以包括@implements、@extends、@aggregation、@association、@composition、@dependency等JSDoc标签。其中，@implements标签可以用于标识实现关系，@extends标签可以用于标识继承关系，@aggregation标签可以用于标识聚合关系，@association标签可以用于标识关联关系，@composition标签可以用于标识组合关系，@dependency标签可以用于标识依赖关系。示例性的，@implements、@extends、@aggregation、@association、@composition、@dependency等JSDoc标签后可以包括存在关系的类或接口名称。

需要说明的是，JSDoc注释中可以包括多种JSDoc标签，本申请实施例中，可以解析@implements、@extends、@aggregation、@association、@composition、@dependency这六种JSDoc标签，其它JSDoc标签可以不用解析。

举例说明，第一Typescript代码文件可以为“Teacher.ts”，“Teacher.ts”具体内容可以如下所示：

/>

在上述示例中，Teacher类声明之前，可以包括以/**序列开头，以*/结尾的JSDoc注释，并且，该JSDoc注释中可以包括@implements和@extends标签。@implements Teaching标签可以标识Teacher类与Teaching接口的关系为实现，@extends People标签可以标识Teacher类与People类的关系为继承。students属性声明之前也可以包括对应的JSDoc注释，该JSDoc注释中可以包括@aggregation student标签，该标签可以标识Teacher类与Student类的关系为聚合。group属性声明之前也可以包括对应的JSDoc注释，该JSDoc注释中可以包括@association courseGroup标签，该标签可以标识Teacher类与CourseGroup类的关系为关联。teachingAptitude属性声明之前也可以包括对应的JSDoc注释，该JSDoc注释中可以包括@composition TeachingAptitude标签，该标签可以标识Teacher类与TeachingAptitude类的关系为组合。teaching方法声明之前也可以包括对应的JSDoc注释，该JSDoc注释中可以包括@dependency Course标签，该标签可以标识Teacher类与Course类的关系为依赖(dependency)。

电子设备可以通过解析第一Typescript代码文件，以及与第一Typescript代码文件关联的其它Typescript代码文件中的声明和JSDoc注释，生成第一Typescript代码文件对应的JSON文件。其中，第一Typescript代码文件对应的JSON文件中可以包括第一Typescript代码文件中定义的类的信息、第一Typescript代码文件中定义的接口的信息，以及与第一Typescript代码文件关联的其它Typescript代码文件中定义的类的信息、与第一Typescript代码文件关联的其它Typescript代码文件中定义的接口的信息，以及这些类与类之间、类与接口之间、接口与接口之间的关系。

在一种可能的实现方式中，电子设备基于第一Typescript代码文件中的声明和JSDoc注释，生成第一Typescript代码文件对应的JSON文件，可以包括以下步骤：电子设备可以先基于第一Typescript代码文件中的声明和JSDoc注释，生成第一Typescript代码文件对应的AST语法树，然后电子设备可以遍历第一Typescript代码文件对应的AST语法树或者查询AST语法树的相关节点，以生成第一Typescript代码文件对应的JSON文件。

AST语法树中还可以包括Commentblock(块注释)节点，块注释节点可以作为类声明节点、接口声明节点、属性声明节点、方法声明节点等节点的子节点。应理解，一个块注释节点可以对应一个JSDoc注释。

电子设备可以解析第一Typescript代码文件对应的AST语法树，基于第一Typescript代码文件对应的AST语法树中的类声明节点和接口声明节点，以及类声明节点和接口声明节点包括的方法声明子节点和属性声明子节点，可以获取到第一Typescript代码文件中定义的类的信息和第一Typescript代码文件中定义的接口的信息。基于第一Typescript代码文件对应的AST语法树中的块注释节点，电子设备可以获取第一Typescript代码文件中定义的类与第一Typescript代码文件中导入的类或接口之间的关系，也可以获取第一Typescript代码文件中定义的接口与第一Typescript代码文件中导入的类或接口之间的关系。同理，针对与第一Typescript代码文件关联的其它Typescript代码文件，电子设备也可以先将这些代码文件转换为对应的AST语法树，然后对这些AST语法树进行解析，具体的解析过程与解析第一Typescript代码文件对应的AST语法树类似，可以参考上述解析第一Typescript代码文件对应的AST语法树的相关描述。电子设备通过解析与第一Typescript代码文件关联的其它Typescript代码文件对应的AST语法树，可以获取与第一Typescript代码文件关联的其它Typescript代码文件中定义的类的信息、与第一Typescript代码文件关联的其它Typescript代码文件中定义的接口的信息，以及这些类与类之间、类与接口之间、接口与接口之间的关系。并且，电子设备可以将获取的信息存储到第一Typescript代码文件对应的JSON文件中。

对于获取第一Typescript代码文件中定义的类的信息、第一Typescript代码文件中定义的接口的信息，以及与第一Typescript代码文件关联的其它Typescript代码文件中定义的类的信息、与第一Typescript代码文件关联的其它Typescript代码文件中定义的接口的信息的方式与步骤301中的获取方式相同，可以参考步骤301中的相关描述，在此不再赘述。

电子设备可以解析第一Typescript代码文件，以及与第一Typescript代码文件关联的其它Typescript代码文件中的JSDoc注释，获取这些类与类之间、类与接口之间、接口与接口之间的关系。

示例性的，电子设备可以解析“Teacher.ts”代码文件中包括的JSDoc注释中的@implements、@extends、@aggregation、@association、@composition、@dependency标签，可以获取Teacher类与People类、Student类、CourseGroup类、TeachingAptitude类、Course类、Teaching接口之间的关系。电子设备还可以解析第二Typescript代码文件中包括的JSDoc注释，此时，第二Typescript代码文件可以为“CourseGroup.ts”、“Course.ts”、“People.ts”、“Student.ts”、“TeachingAptitude.ts”、“Teaching.interface.ts”中的任一代码文件。例如，电子设备可以解析“Student.ts”代码文件中包括的JSDoc标签“@extends People”，可以获取Student类与People类之间的继承关系。电子设备通过解析“Teacher.ts”代码文件，以及与“Teacher.ts”代码文件关联的其它Typescript代码文件(如“CourseGroup.ts”、“Course.ts”、“People.ts”、“Student.ts”、“TeachingAptitude.ts”、“Teaching.interface.ts”)中的声明和JSDoc注释，可以生成“Teacher.ts”代码文件对应的“Teacher.json”文件，具体内容可以参考步骤301中的描述。

可以理解的是，在一种可能的实现方式中，也可以结合注解和JSDoc注释标识类与类之间、类与接口之间、接口与接口之间的关系，相应地，电子设备可以通过解析代码文件中的注解和JSDoc注释，获取当前代码文件中定义的类与当前代码文件中导入的类或接口之间的关系，以及当前代码文件中定义的接口与当前代码文件中导入的类或接口之间的关系。

步骤501与步骤301的原理类似，因此，步骤301中的部分描述未在步骤501中重复赘述，可以参考步骤301中的描述。

502.电子设备基于第一Typescript代码文件对应的JSON文件，生成第一Typescript代码文件对应的UML类图。

步骤502与步骤302相同，可以参考步骤302中的相关描述。

基于上述系统架构，请参阅图6，图6是本申请实施例公开的又一种数据转换方法的流程示意图，通过图6所示的处理流程，可以基于JSON文件生成对应的Typescript代码文件和UML类图。如图6所示，该数据转换方法可以包括但不限于如下步骤：

601.电子设备基于第一JSON文件，生成第一JSON文件对应的Typescript代码文件。

其中，第一JSON文件可以为存储在电子设备本地的JSON文件，也可以为电子设备接收到的来自其它设备的JSON文件，本申请在此不作限定。例如，电子设备可以接收用户针对存储在本地的第一JSON文件的第一生成操作，该第一生成操作用于解析第一JSON文件，并生成第一JSON文件对应的Typescript代码文件。响应于第一生成操作，电子设备可以解析第一JSON文件，生成第一JSON文件对应的Typescript代码文件。示例性的，针对存储在本地的第一Typescript代码文件的第一生成操作，可以为图1G所示的单击启动TSToUML插件1021菜单项。

第一JSON文件可以包括一个或多个类的信息、一个或多个接口的信息，以及这些类与类之间、类与接口之间、接口与接口之间的关系。

在一种可能的实现方式中，第一JSON文件中可以包括"uml"对象数组，"uml"对象数组中的一个对象可以与一个类或一个接口对应，并且，每个uml对象可以存储有对应的类的类名、属性、方法、所属的路径、关系等，或者对应的接口的接口名、属性、方法、所属的路径、关系等。因此，电子设备基于第一JSON文件，可以生成第一JSON文件对应的Typescript代码文件。

在一种可能的实现方式中，"uml"对象数组中的每个uml对象可以包括"id"字段、"type"字段、"classname"字段、"path"字段、"attr"对象数组、"method"对象数组、"umlRelation"对象数组等，具体地可以参考上述步骤301中的相关描述。

电子设备可以基于每个uml对象的"path"字段创建对应的Typescript代码文件，以第一JSON文件为上述“Teacher.json”文件为例，电子设备可以基于"uml"对象数组中的第一个uml对象的"path"字段"src/Teacher.ts"，在src目录下创建Teacher.ts代码文件，电子设备也可以基于"uml"对象数组中的第二个uml对象的"path"字段"src/CourseGroup.ts"，在src目录下创建CourseGroup.ts代码文件。

电子设备创建每个uml对象对应的Typescript代码文件之后，可以基于每个uml对象的"id"字段、"type"字段、"classname"字段、"path"字段、"attr"对象数组、"method"对象数组、"umlRelation"对象数组等填充对应的Typescript代码文件中的内容。例如，电子设备可以基于"uml"对象数组中的第一个uml对象的"id"字段、"type"字段、"classname"字段、"path"字段、"attr"对象数组、"method"对象数组、"umlRelation"对象数组等填充Teacher.ts代码文件中的内容。具体地，电子设备基于"type"字段"class"，可以确定第一个uml对象对应一个类，基于"classname"字段"Teacher"，可以确定对应的类名为"Teacher"，基于此，电子设备可以在Teacher.ts代码文件中声明一个Teacher类。并且，电子设备基于"umlRelation"对象数组中的第一个对象，可以确定Teacher类继承了"id"为"People_01"对应的类，电子设备可以基于"People_01"在"uml"对象数组中查找到对应的uml对象，该对象对应的类名为"People"，对应的路径可以为"src/People.ts"。同理，电子设备基于"umlRelation"对象数组中的第二个对象，可以确定Teacher类实现了"id"为"Teaching_01"对应的接口，并且，电子设备可以基于"Teaching_01"在"uml"对象数组中查找到对应的uml对象，该uml对象对应的接口名可以为"Teaching"，对应的路径可以为"src/Teaching.interface.ts"。基于此，电子设备在Teacher.ts代码文件中声明Teacher类时，可以声明Teacher类继承了People类且实现了Teaching接口，声明代码段可以如下所示：“class Teacher extends People implements Teaching{}”，并且，在Teacher类对应的声明代码段之前，电子设备还可以填充导入声明，如“import{People}from"./People"”和“import{Teaching}from"./Teaching.interface.ts"”，以从"src/People.ts"代码文件中导入People类，以及从"src/Teaching.interface.ts"代码文件中导入Teaching接口。此外，电子设备还可以在“class Teacher extends People implements Teaching{}”之前填充对应的注解，也就是@UMLRelation(People,'extends')注解，和@UMLRelation(Teaching,'implements')注解。此时，Teacher类的类作用域中可以为空，也就是“classTeacher extends People implements Teaching{}”的“{}”中内容可以为空。

电子设备可以继续基于"uml"对象数组中的第一个uml对象的"attr"对象数组、"method"对象数组、"umlRelation"对象数组等填充Teacher类作用域中的内容。例如，基于"attr"对象数组中的第一个对象，电子设备可以确定Teacher类包括"name"为"students"的属性，并且"students"属性对应的类型为"Student[]"，以及与"students"属性关联的"umlRelationId"为"aggregation_01"。基于此，电子设备可以在Teacher类作用域中填充"students"属性对应的属性声明，如“students:Student[]”，并且，基于"aggregation_01"，电子设备可以在"umlRelation"对象数组中查找到对应的关系类型为"aggregation"，对应的"id"为"Student_01"，因此，电子设备还可以在"students"属性声明之前，添加对应的注解@UMLRelationAttr(Student,'aggregation')。"attr"对象数组中的其它对象的处理与上述"students"属性的处理类似，可以参考上述"students"属性对应的相关描述，此处不在赘述。基于"method"对象数组中的第一个对象，电子设备可以确定Teacher类包括"name"为"teaching"的方法，并且"teaching"方法对应的返回值为"Course"，以及与"teaching"方法关联的"umlRelationId"为"dependency_01"。基于此，电子设备可以在Teacher类作用域中填充"teaching"方法对应的方法声明，如“teaching():Course{}”，并且，基于"dependency_01"，电子设备可以在"umlRelation"对象数组中查找到对应的关系类型为"dependency"，对应的"id"为"Course_01"，因此，电子设备还可以在"teaching"方法声明之前，添加对应的注解@UMLRelationMethod(Course,'dependency')。"method"对象数组中的其它对象的处理与上述"teaching"方法的处理类似，可以参考上述"teaching"方法对应的相关描述，此处不在赘述。在解析完"uml"对象数组中的第一个uml对象之后，电子设备还可以在Teacher.ts代码文件填充一些预设代码段(如默认将Teacher类通过export关键字导出)或者根据依赖关系在Teacher.ts代码文件中导入一些模块，如“import{UMLRelation，UMLRelationAttr，UMLRelationMethod}from"./UMLRelation"”，电子设备填充完成之后的Teacher.ts代码文件可以如下所示：

可见，电子设备填充完成的Teacher.ts代码文件中，Teacher类的方法(如teaching方法)可以为空，也就是说，Teacher类的方法可以包括整体架构，但不包括方法的具体代码。应理解，上述电子设备填充完成的Teacher.ts代码文件中，Teacher类的属性和方法均不包括修饰符(如public、protected、private等访问修饰符)，但在本申请另一些实施例中，针对第一JSON文件中每一个uml对象的"attr"对象数组和"method"对象数组中的每一个对象，均可以定义修饰符字段"modifier"，"modifier"字段可以用于标识一个属性或者方法的访问修饰符(可见性)。例如，针对上述“Teacher.json”文件中"uml"对象数组中的第一个uml对象，其"attr"对象数组中的第一个对象的"modifier"字段可以为"public"，可以标识"students"属性的访问修饰符为"public"。这样，电子设备填充完成的Teacher.ts代码文件中，针对Teacher类的属性和方法可以包括对应的访问修饰符，如students属性声明“”可以变为“public students:Student[]”。

可以理解的是，与上述添加注解原理类似，电子设备也可以添加对应JSDoc注释，并且在JSDoc注释填充对应的JSDoc标签。

602.电子设备基于第一JSON文件，生成第一JSON文件对应的UML类图。

其中，第一JSON文件对应的UML类图可以为第一JSON文件对应的Typescript代码文件对应的UML类图。步骤602与步骤302类似，可以参考上述步骤302中的相关描述，在此不再详细赘述。

需要说明的是，本申请实施例中，对于步骤601和步骤602的执行顺序没有限制。步骤601可以在步骤602之前执行，也可以在步骤602之后执行，还可以与步骤602同时执行。还需要说明的是，步骤601和步骤602可以为独立的两个步骤，因此，在本申请的另一些实施例中，步骤601可以不用执行或者步骤602可以不用执行。

可选地，当第一JSON文件发生了修改时，电子设备也可以基于修改后的第一JSON文件动态修改第一JSON文件对应的Typescript代码文件，也可以基于修改后的第一JSON文件动态修改第一JSON文件对应的UML类图。

上述处理流程中，电子设备可以基于第一JSON文件生成第一JSON文件对应的Typescript代码文件，也可以基于第一JSON文件生成第一JSON文件对应的UML类图。这样，可以便于用户基于JSON文件生成对应的Typescript代码文件和UML类图。

基于上述系统架构，请参阅图7，图7是本申请实施例公开的又一种数据转换方法的流程示意图，通过图7所示的处理流程，可以基于UML类图生成对应的JSON文件和Typescript代码文件。如图7所示，该数据转换方法可以包括但不限于如下步骤：

701.电子设备基于第一UML类图，生成第一UML类图对应的JSON文件。

其中，第一UML类图可以为存储在电子设备本地的UML类图，也可以为电子设备接收到的来自其它设备的UML类图，还可以为用户绘制的(如当前通过浏览器网页绘制)UML类图，本申请在此不作限定。例如，电子设备可以接收用户针对存储在本地的第一UML类图的第一生成操作，该第一生成操作可以用于解析第一UML类图生成第一UML类图对应的JSON文件。响应于针对第一UML类图的第一生成操作，电子设备可以解析第一UML类图，生成第一UML类图对应的JSON文件。示例性的，针对存储在本地的第一UML类图的第一生成操作，可以为图1J所示的单击启动TSToUML插件1025菜单项。

第一UML类图中可以包括类，也可以包括接口。针对每个类和接口，可以通过一个矩形表示，矩形中可以包括类的类名、属性、方法等，也可以包括接口的接口名、属性、方法等。并且，第一UML类图中还可以包括类与类之间的关系连线、类与接口之间的关系连线、接口与接口之间的关系连线。

电子设备可以解析第一UML类图中的每个矩形，可以获取到每个矩形对应的类或接口的信息。电子设备还可以解析第一UML类图中的关系连线，可以确定类与类之间的关系，或者类与接口之间的关系，或者接口与接口之间的关系。以第一UML类图为图4所示的UML类图为例，电子设备可以解析图4所示的UML类图中的每个矩形，可以确定该UML类图中包括Teacher类、People类、Student类、Course类、CourseGroup类、TeachingAptitude类和Teaching接口。并且，电子设备还可以获取每个类的类名、属性、方法等信息，或者每个接口的接口名、属性、方法等信息。例如，电子设备可以获取Teacher类的类名“Teacher”，Teacher类的属性“students：Student[]”、“group：CourseGroup”、“TeachingAptitude：TeachingAptitude[]”，以及Teacher类的方法“teaching()：Course”。电子设备还可以解析图4所示的UML类图中的关系连线，可以确定Teacher类、People类、Student类、Course类、CourseGroup类、TeachingAptitude类和Teaching接口之间的关系。例如，电子设备可以基于Teacher类与People类之间的继承关系连线，确定Teacher类与People类之间为继承关系。再例如，电子设备可以基于Teacher类与Student类之间的聚合关系连线，确定Teacher类与People类之间为聚合关系。同理，电子设备也可以基于图4所示的UML类图中的其它关系连线，确定Teacher类与Teaching接口之间为实现关系，Teacher类与CourseGroup类之间为关联关系，Teacher类与TeachingAptitude类之间为组合关系，Teacher类与Course类之间为依赖关系，Student类与People类之间为继承关系。

电子设备可以创建第一UML类图对应的JSON文件，如“Teacher.json”。之后，电子设备可以基于获取到的第一UML类图中每个矩形对应的类或接口的信息，以及第一UML类图中类与类之间的关系、类与接口之间的关系、接口与接口之间的关系填充第一UML类图对应的JSON文件中的内容。第一UML类图对应的JSON文件可以包括"uml"对象数组，"uml"对象数组中的一个对象可以与一个类或一个接口对应，并且，每个uml对象可以存储有对应的类的类名、属性、方法、所属的路径、关系等，或者对应的接口的接口名、属性、方法、所属的路径、关系等。

以图4所示的UML类图为例，电子设备生成的图4所示的UML类图对应的JSON文件中可以包括7个uml对象，分别为Teacher类、People类、Student类、Course类、CourseGroup类、TeachingAptitude类和Teaching接口对应的uml对象。其中，针对每一个uml对象，可以包括"id"字段、"type"字段、"classname"字段、"path"字段、"attr"对象数组、"method"对象数组、"umlRelation"对象数组等。电子设备可以基于获取的每个类或接口的信息，以及类与类之间的关系、类与接口之间的关系、接口与接口之间的关系填充对应的uml对象的内容。以Teacher类为例，电子设备可以基于获取的Teacher类的信息，以及Teacher类与其它类或接口之间的关系填充Teacher类对应的uml对象的内容。

具体地，针对Teacher类对应的uml对象的"id"字段，电子设备可以根据实际情况或者按照预设规则(如类名+“下划线”+编号)填充，如为"Teacher_01"，本申请实施例在此不作限定。由于Teacher类为类，因此电子设备可以将对应的uml对象的"type"字段填充为"class"。由于Teacher类的类名为"Teacher"，因此，电子设备可以将对应的uml对象的"classname"字段填充为"Teacher"。针对Teacher类对应的uml对象的"path"字段，电子设备可以根据实际情况或者按照预设规则(如“src/”+类名+“.ts”)填充，如为"src/Teacher.ts"，本申请实施例在此不作限定。

针对Teacher类对应的"umlRelation"对象数组，电子设备可以根据Teacher类与People类、Student类、Course类、CourseGroup类、TeachingAptitude类、Teaching接口的关系填充，并且，"umlRelation"对象数组中的每一个对象可以与一个关系对应。在一种可能的实现方式中，"umlRelation"对象数组中的每一个对象可以包括"umlRelationId"字段、"relationType"字段和"id"字段。以Teacher类与People类的继承关系为例，电子设备可以根据实际情况或者按照预设规则(如关系类型+“下划线”+编号)填充"umlRelationId"字段，如为"extends_01"。针对于"relationType"字段，电子设备可以填充为"extends"。针对于"id"字段，电子设备可以填充为People类对应的"id"，如为People_01"。针对于Teacher类与其它类或接口的关系，也可以按照类似的方式进行填充，如Teacher类与Student类之间的关系，"umlRe1ationId"字段可以填充为"aggregation_01"，"relationType"字段可以填充为"aggregation"，"id"字段可以填充为"Student_01"。

针对Teacher类对应的"attr"对象数组，电子设备可以根据Teacher类的属性，以及Teacher类与People类、Student类、CourseGroup类、TeachingAptitude类、Teaching接口的关系填充。以students属性为例，电子设备可以确定Teacher类的students属性的名称为"students"，因此，可以将"name"填充为"students"。同理，电子设备可以将"type"字段填充为"Student[]"。针对于"umlRelationId"字段，电子设备可以基于"type"字段确定students属性与Student类有关，而"umlRelation"对象数组中"umlRe1ationId"为"aggregation_01"的对象用于表示Teacher类与Student类之间的关系，因此，可以将"umlRelationId"字段填充为"aggregation_01"。针对于Teacher类的其它属性，也可以按照类似的方式进行填充，在此不再赘述。

针对Teacher类对应的"method"对象数组，电子设备可以根据Teacher类的方法，以及Teacher类与Course类的关系填充。以teaching方法为例，电子设备可以确定Teacher类的teaching方法的名称为"teaching"，因此，可以将"name"填充为"teaching"。同理，电子设备可以将"return"字段填充为"Course"。针对于"umlRelationId"字段，电子设备可以基于"return"字段确定teaching方法与Course类有关，而"umlRelation"对象数组中"umlRe1ationId"为"dependency_01"的对象用于表示Teacher类与Ctudent类之间的关系，因此，可以将"umlRelationId"字段填充为"dependency_01"。针对于People类、Student类、Course类、CourseGroup类、TeachingAptitude类和Teaching接口对应的uml对象，也可以按照与Teacher类相似的方式进行填充，在此不再赘述。电子设备填充完成之后的Teacher.json文件可以如上述步骤301中的Teacher.json所示，可以参考上述步骤301中的Teacher.json文件。

702.电子设备基于第一UML类图对应的JSON文件，生成第一UML类图对应的Typescript代码文件。

步骤702与步骤601类似，可以参考上述步骤601中的相关描述，在此不再详细赘述。

可选地，当第一UML类图发生了修改时，电子设备可以基于修改后的第一UML类图动态地修改第一UML类图对应的JSON文件，也可以基于修改后的第一UML类图动态地修改第一UML类图对应的Typescript代码文件。

应理解，在一些实施例中，电子设备也可以不生成第一UML类图对应的JSON文件，可以基于第一UML类图，直接生成第一UML类图对应的Typescript代码文件。

在一种可能的实现方式中，上述第一Typescript代码文件、与第一Typescript代码文件关联的其它Typescript代码文件、第一Typescript代码文件对应的JSON文件以及第一Typescript代码文件对应的UML类图之间可以建立绑定关系，当Typescript代码文件(包括第一Typescript代码文件、与第一Typescript代码文件关联的其它Typescript代码文件)、第一Typescript代码文件对应的JSON文件以及第一Typescript代码文件对应的UML类图这三者之中的任意一个发生变化，其它两个均可以同步进行变化，也就是说，电子设备可以对第一Typescript代码文件、与第一Typescript代码文件关联的其它Typescript代码文件、第一Typescript代码文件对应的JSON文件以及第一Typescript代码文件对应的UML类图进行动态的调整。例如，当第一Typescript代码文件对应的JSON文件进行了修改，电子设备可以对Typescript代码文件(包括第一Typescript代码文件、与第一Typescript代码文件关联的其它Typescript代码文件)进行对应的修改，也可以对第一Typescript代码文件对应的UML类图进行对应的修改。以上述“Teacher.json”文件为例，当删除了"uml"对象数组中的第三个对象(Course类对应的对象)时，电子设备可以删除Course类对应的代码文件“Course.ts”，也可以删除“Teacher.json”文件对应的UML类图中的Course类对应的矩形。可见，上述这种方式可以将UML类图、Typescript代码文件联系起来，修改其中一个另外一个也可以相应的修改，不需要人工绘制或者人工编写代码，可以极大地提高代码开发效率或者UML类图绘制效率，并且灵活性较高。

上述处理流程中，电子设备可以基于第一UML类图生成第一UML类图对应的JSON文件，也可以基于第一UML类图对应的JSON文件生成第一UML类图对应的Typescript代码文件。这样，可以便于用户基于UML类图生成对应的Typescript代码文件和JSON文件。

需要说明的是，上述对于解析第一Typescript代码文件关联的Typescript代码文件中的类声明和接口声明、以及JSDoc标签和/或注解，解析Typescript代码文件中的类声明和接口声明，以及JSDoc标签和/或注解的解析的先后顺序对执行结果没有影响，因此，不对上述解析顺序作限制。

基于上述系统架构，请参阅图8，图8是本申请实施例公开的又一种数据转换方法的流程示意图，通过图8所示的处理流程，可以基于Typescript代码文件生成对应的UML类图。如图8所示，该数据转换方法可以包括但不限于如下步骤：

801.基于第一Typescript代码文件中的声明，以及JSDoc标签和/或注解，生成第一Typescript代码文件对应的UML类图。

具体地，电子设备可以解析第一Typescript代码文件中包括的类声明和接口声明，可以获取第一Typescript代码文件中定义的类的信息、第一Typescript代码文件中定义的接口的信息。电子设备也可以解析第一Typescript代码文件中包括的导入声明，基于ES的导入(inport)规则可以获取第一Typescript代码文件中导入的其它类、其它接口所属的代码文件的路径(存储路径)。然后，电子设备可以基于获取的第一Typescript代码文件中导入的其它类、其它接口所属的代码文件的路径去访问对应的Typescript代码文件，解析这些代码文件中包括的类声明和接口声明，可以获取这些Typescript代码文件中定义的类的信息，以及定义的接口的信息等。通过电子设备的层层解析，可以获取到第一Typescript代码文件中定义的类的信息、第一Typescript代码文件中定义的接口的信息、与第一Typescript代码文件关联的其它Typescript代码文件中定义的类的信息、与第一Typescript代码文件关联的其它Typescript代码文件中定义的接口的信息。

其中，Typescript代码文件中的JSDoc标签可以用于标识Typescript代码文件中的类与类之间、类与接口之间、接口与接口之间的关系，具体可以参考步骤301中的相关描述。Typescript代码文件中的注解也可以用于标识Typescript代码文件中的类与类之间、类与接口之间、接口与接口之间的关系，具体可以参考步骤501中的相关描述。基于此，电子设备可以基于第一Typescript代码文件中的JSDoc标签和/或注解，获取第一Typescript代码文件中定义的类与第一Typescript代码文件中导入的类或接口之间的关系，也可以获取第一Typescript代码文件中定义的接口与第一Typescript代码文件中导入的类或接口之间的关系。同理，电子设备也可以基于与第一Typescript代码文件关联的其它Typescript代码文件中的JSDoc标签和/或注解，获取这些代码文件中定义的类与这些代码文件中导入的类或接口之间的关系，也可以获取这些代码文件中定义的接口与这些代码文件中导入的类或接口之间的关系。

当电子设备获取到第一Typescript代码文件中定义的类的信息、第一Typescript代码文件中定义的接口的信息，以及与第一Typescript代码文件关联的其它Typescript代码文件中定义的类的信息、与第一Typescript代码文件关联的其它Typescript代码文件中定义的接口的信息，以及这些类与类之间、类与接口之间、接口与接口之间的关系之后，电子设备可以基于这些信息生成第一Typescript代码文件对应的UML类图，可以参考步骤302中的相关描述。

需要说明的是，上述图3、图5、图6、图7和图8所示的数据转换方法可以独立使用，也可以结合起来使用，本申请实施例对此不作限定。

还需要说明的是，上述不同实施例中的相关信息(即相同信息或相似信息)和相关描述可以相互参考。

还需要说明的是，上述以电子设备作为执行主体来示意上述处理流程，但本申请并不限制该执行主体。例如，图3、图5、图6、图7或图8中电子设备执行的相关步骤也可以通过支持该电子设备实现该方法的芯片、芯片系统、或处理器执行，还可以通过能实现全部或部分电子设备功能的逻辑模块或软件(如上述UML类图转换插件、UML类图转换模块)执行。

基于上述系统架构，请参阅图9，图9是本申请实施例公开的一种电子设备的结构示意图。其中，该电子设备900可以包括：处理器901、通信接口902和存储器903。处理器901、通信接口902以及存储器903可以相互连接或者通过总线904相互连接。

示例性的，存储器903用于存储电子设备900的计算机程序和数据，存储器903可以包括但不限于是随机存储记忆体(random access memory，RAM)、只读存储器(read-onlymemory，ROM)、可擦除可编程只读存储器(erasable programmable read only memory，EPROM)或便携式只读存储器(compact disc read-only memory，CD-ROM)等。通信接口902用于支持电子设备900进行通信，例如接收或发送数据。

示例性的，处理器901可以是中央处理器(central processing unit，CPU)、复杂可编程逻辑器件、通用处理器、数字信号处理器、专用集成电路、现场可编程门阵列或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。处理器也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，数字信号处理器和微处理器的组合等等。

在一个实施例中，电子设备900可以为上述电子设备，处理器901可以用于读取上述存储器903中存储的程序，执行上述图3、图5、图6、图7或图8所示的方法实施例中电子设备或电子设备中的组件执行的操作，可以参考上述相关描述，在此不再详细赘述。

需要说明的是，图9所示的电子设备900仅仅是本申请实施例的一种实现方式，实际应用中，电子设备900还可以包括更多或更少的部件，这里不作限制。

本申请实施例还公开一种计算机可读存储介质，其上存储有指令，该指令被执行时执行上述方法实施例中的方法。

本申请实施例还公开一种包括指令的计算机程序产品，该指令被执行时执行上述方法实施例中的方法。

应理解，本申请中的“通信”，可以理解为直接通信；也可以理解为间接通信，也即通过其它器件、模块、装置等进行通信。

显然，上述所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。在本文中提及“实施例”意味着，结合实施例描述的特定特征、结构或者特性可以包含在本实施例申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是相同的实施例，也不是与其它实施例互斥的独立的或是备选的实施例。本领域技术人员可以显式地和隐式地理解的是，本文所描述的实施例可以与其它实施例相结合。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。本申请的说明书和权利要求书及所述附图中术语“第一”、“第二”等是区别于不同的对象，而不是用于描述特定顺序。此外，术语“包括”和“具有”以及它们的任何变形，意图在于覆盖不排他的包含。例如，包含了一系列步骤或单元，或者可选地，还包括没有列出的步骤或单元，或者可选地还包括这些过程、方法、产品或设备固有的其它步骤或单元。

可以理解的是，附图中仅示出了与本申请相关的部分而非全部内容。应当理解的是，一些示例性实施例被描述成作为流程图描绘的处理或方法。虽然流程图将各项操作(或步骤)描述成顺序的处理，但是其中的许多操作可以并行地、并发地或者同时实施。此外，各项操作的顺序可以被重新安排。当其操作完成时所述处理可以被终止，但是还可以具有未包括在附图中的附加步骤。所述处理可以对应于方法、函数、规程、子例程、子程序等等。

在本说明书中使用的术语“部件”、“模块”、“系统”、“单元”等用于表示计算机相关的实体、硬件、固件、硬件和软件的组合、软件或执行中的软件。例如，单元可以是但不限于在处理器上运行的进程、处理器、对象、可执行文件、执行线程、程序和/或分布在两个或多个计算机之间。此外，这些单元可从在上面存储有各种数据结构的各种计算机可读介质执行。单元可例如根据具有一个或多个数据分组(例如来自与本地系统、分布式系统和/或网络间的另一单元交互的第二单元数据。例如，通过信号与其它系统交互的互联网)的信号通过本地和/或远程进程来通信。以上所述的具体实施方式，对本申请的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本申请的具体实施方式而已，并不用于限定本申请的保护范围，凡在本申请的技术方案的基础之上，所做的任何修改、等同替换、改进等，均应包括在本申请的保护范围之内。

Claims (10)

1.一种数据转换方法，其特征在于，包括：

基于第一Typescript代码文件中的声明，以及JSDoc标签和/或注解，生成所述第一Typescript代码文件对应的UML类图；

其中，所述JSDoc标签和/或注解用于标识所述第一Typescript代码文件中的类与类之间、类与接口之间、接口与接口之间的关系。

2.根据权利要求1所述的方法，其特征在于，所述基于第一Typescript代码文件中的声明，以及JSDoc标签和/或注解，生成所述第一Typescript代码文件对应的UML类图，包括：

基于第一Typescript代码文件中的声明，以及JSDoc标签和/或注解，生成所述第一Typescript代码文件对应的JSON文件；所述第一Typescript代码文件对应的JSON文件包括以下一项或多项：所述第一Typescript代码文件中定义的类的信息、所述第一Typescript代码文件中定义的接口的信息、与所述第一Typescript代码文件关联的Typescript代码文件中定义的类的信息、与所述第一Typescript代码文件关联的Typescript代码文件中定义的接口的信息、所述第一Typescript代码文件对应的JSON文件中包括的类之间的关系、所述第一Typescript代码文件对应的JSON文件中包括的类与包括的接口之间的关系、所述第一Typescript代码文件对应的JSON文件中包括的接口之间的关系；

基于所述第一Typescript代码文件对应的JSON文件，生成所述第一Typescript代码文件对应的UML类图。

3.根据权利要求2所述的方法，其特征在于，所述基于第一Typescript代码文件中的声明，以及JSDoc标签和/或注解，生成所述第一Typescript代码文件对应的JSON文件，包括：

基于第一Typescript代码文件中的导入声明层层解析，获取与所述第一Typescript代码文件关联的Typescript代码文件的路径；

基于所述路径访问对应的代码文件，解析与所述第一Typescript代码文件关联的Typescript代码文件中的类声明和接口声明，以及JSDoc标签和/或注解，获取与所述第一Typescript代码文件关联的Typescript代码文件中定义的类的信息、定义的接口的信息、标识的关系；

解析所述第一Typescript代码文件中的类声明和接口声明，以及JSDoc标签和/或注解，获取所述第一Typescript代码文件中定义的类的信息、定义的接口的信息、标识的关系；

基于所述第一Typescript代码文件中定义的类的信息、定义的接口的信息、标识的关系，以及与所述第一Typescript代码文件关联的Typescript代码文件中定义的类的信息、定义的接口的信息、标识的关系，生成所述第一Typescript代码文件对应的JSON文件。

4.根据权利要求3所述的方法，其特征在于，所述方法还包括：

将所述第一Typescript代码文件的路径，以及与所述第一Typescript代码文件关联的Typescript代码文件的路径放入栈中；其中，所述栈中任一个路径的依赖元素位于所述路径的上方；一个路径的依赖元素为所述路径对应的Typescript代码文件中导入的类或接口所属的Typescript代码文件的路径；

在获取所述代码文件中定义的类的信息、定义的接口的信息、标识的关系的过程中，具体按照出栈顺序依次解析每个路径对应的Typescript代码文件，获取所述每个代码文件中定义的类的信息、定义的接口的信息、标识的关系。

5.根据权利要求3或4所述的方法，其特征在于，所述解析所述第一Typescript代码文件中的类声明和接口声明，以及JSDoc标签和/或注解，获取所述第一Typescript代码文件中定义的类的信息、定义的接口的信息、标识的关系，包括：

生成所述第一Typescript代码文件对应的抽象语法树；

遍历所述抽象语法树，获取所述第一Typescript代码文件中定义的类的信息、定义的接口的信息、标识的关系；

或者，查询所述抽象语法树上的类声明节点和接口声明节点，获取所述第一Typescript代码文件中定义的类的信息、定义的接口的信息、标识的关系。

6.根据权利要求1-5任一项所述的方法，其特征在于，所述JSDoc标签包括实现关系标签、继承关系标签、聚合关系标签、关联关系标签、组合关系标签、依赖关系标签；所述实现关系标签用于标识实现关系，所述继承关系标签用于标识继承关系，所述聚合关系标签用于标识聚合关系，所述关联关系标签用于标识关联关系，所述组合关系标签用于标识组合关系，所述依赖关系标签用于标识依赖关系；

所述注解包括第一类型的注解、第二类型的注解和第三类型的注解，所述第一类型的注解为类或接口对应的注解，用于标识基于类或接口的关系；所述第二类型的注解为方法对应的注解，用于标识基于方法的关系；所述第三类型的注解为属性对应的注解，用于标识基于属性的关系。

7.根据权利要求2-6任一项所述的方法，其特征在于，所述方法还包括：

在所述第一Typescript代码文件对应的JSON文件被修改的情况下，基于所述修改后的JSON文件调整所述第一Typescript代码文件，和/或所述第一Typescript代码文件对应的UML类图。

8.根据权利要求2-7任一项所述的方法，其特征在于，所述方法还包括：

在所述第一Typescript代码文件对应的UML类图被修改的情况下，基于所述修改后的UML类图调整所述第一Typescript代码文件，和/或所述第一Typescript代码文件对应的JSON文件。

9.一种电子设备，其特征在于，所述电子设备包括处理器和存储器，所述处理器调用所述存储器中存储的计算机程序或计算机指令实现如权利要求1-8任一项所述的方法。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机程序或计算机指令，当所述计算机程序或计算机指令被运行时，实现如权利要求1-8任一项所述的方法。