# easy_script

**Repository Path**: hzxcodecode/easy_script

## Basic Information

- **Project Name**: easy_script
- **Description**: 点击型事件脚本构建平台！
- **Primary Language**: Unknown
- **License**: Not specified
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2022-12-19
- **Last Updated**: 2023-04-17

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# 模块设计


***
## 1. 任务管理模块
> 主要负责任务的管理，相关功能实现，任务的提供（面向任务执行模块），任务的增加（面向数据库，持久化进数据库），
> 任务的加载（面向内存，将任务取到内存中准备执行），任务的删除（面向数据库），任务的移除（面向内存）
> ***
> ### 1.1 任务模型
> 每个任务里面包含有以下信息
> + 任务状态集 ：每一个任务都有一个状态集，里面包含该任务的所有状态，所谓的状态可以理解为屏幕上的一个页面，状态的转移相当于你点击屏幕上的一个按钮。然后
> 应用转移到另外一个页面这就是状态的转移。
> + 入口集 ：每一个状态都有自己的入口集，入口集相当于上文中提到的状态触发状态转移的按钮。
> + 操作集 ：每一个任务都有一个操作集，每个操作相当一连串的状态转移。用户可以提前设定好操作集提交给系统，系统将按照这个
> 给定的操作进行预订的状态变换，以此来达成脚本的功能，操作分为两个种类，循环性操作以及线性操作。
> + 步骤集 ： 每一个操作都有自己的一个步骤集，每个步骤可以理解为触发状态转移所需要执行的动作，有些步骤只需进行简单的点击事件即可完成
> 而有些步骤则可能需要滑动页面后再进行点击事件。
> ***
> 通过以上的模型可以容易看出，这是数据结构中的有向图模型，我们每一个状态可以认为是一个点，每一个入口可以认为是一个单向边，对于我们使用软件的这个行为
> 则可以抽象成在图中进行连续点的遍历。
> *** 
>### 1.2 任务模型的好处
> 对于传统的脚本来说，状态的转移通常是靠代码if逻辑来实现的，这样做的话就有极强的专一性，因此业务逻辑和代码逻辑的耦合就会导致一个结果，脚本
> 的编写会难以维护，每当要更换业务逻辑时就要去修改代码难以拓展，而对于任务模型来说他的主要优势在于将代码的执行逻辑与业务逻辑解开了，当我们去
> 修改脚本的时候不是直接去对代码修改，而是值修改我们用户创建的“状态集”（业务逻辑）来实现的，因此通用性更强。
> ***
> ### 1.3 任务管理模块功能
> + 向任务总控提供获取任务的相关接口如获取下一个可执行任务，判断是否有可执行任务。
> + 向用户提供对任务增删改查的对应接口
> + 向用户提供操作集修改的接口
***


## 2. 任务执行模块
> 主要独立负责对独立的任务进行执行，隐藏任务的执行细节，模块对总控只暴露一个执行任务的接口。
> 在了解任务执行器工作之前要描述一下任务在内存中存在时的模型。
> ***
> ![avatar](doc/image/task_in_memory.png)
> ***
> ### 2.1 任务内存模型 
>> #### 2.1.1 状态图：
>>  状态图如上文所述包括了状态集和入口集等属性，而临接矩阵则是将状态集和入口集融合抽象出我们的有向图的一种数据结构，
>>  方便我们使用最短路径算法来寻找状态转换的路径。
>> #### 2.1.2 操作集
>>  该状态对应的用户预先设置好的操作集。
>> #### 2.1.3 当前状态与实际状态
>>  对应当前任务所对应的任务的真实状态，该状态由我们系统去主动维护，也是系统与对应应用的唯一一个连接点,当前状态的
>>  确定对于系统来说极其重要。
>> #### 2.1.4 目标状态
>>  与当前状态相对应，即运行程序在经过我们系统的一些列变换之后预期将要达到的状态，当当前状态与目标状态吻合时才能
>>  进行任务的下一步。
>> #### 2.1.4 目标操作
>>  当前系统正在执行的操作，该操作由用户提前进行选定。
>> #### 2.1.5 目标步骤
>>  当前系统正在执行的操作的步骤，随系统的运行而变换。
> ***
> ![avatar](doc/image/task_runner.png)
> ***
> 以下是任务执行模块的简要执行流程
> ### 2.2. 任务处理器流程
> 1. 任务加载: 将总控传回来的任务加载到任务执行器的上下文中
> 2. 判断当前任务的当前状态是否丢失
> 3. 如果当前状态丢失则去确定当前状态，如果没有丢失则判断当前状态是否与实际状态相吻合
> 4. 不吻合则确定当前状态，吻合则判断当前状态是否与目标状态一致。
> 5. 与目标状态一致则可以尝试获取目标操作的下一个步骤，与目标不一致，尝试查找转移到目标的路径，找到路径则可以进行下一步
> 6. 如果目标操作已经是最后一个则可以进行状态的切换处理，否则进入下一个目标。

***

## 3. 总控模块
> 主要负责协调任务管理模块和任务执行模块，并且向用户暴露开始执行任务以及停止执行任务等操作。
> + 开始执行系统（面向用户）
> + 停止系统（面向用户）
> + 初始化系统（系统内部调用）

***
## 4. 主要业务
在介绍项目之前，先引入一个概念：任务模型 
在一个任务中包含如下信息 
任务状态集 ：每一个任务都有一个状态集，里面包含该任务的所有状态，所谓的状态可以理解为应用上的一个页面，
状态的转移相当于你点击屏幕上的一个按钮，然后应用转移到另外一个页面这就是状态的转移。 
入口集 ：每一个状态都有自己的入口集，入口集相当于上文中提到的触发状态转移的按钮。 
操作集 ：每一个任务都有一个操作集，每个操作相当一连串的状态转移。用户可以提前设定好操作集提交给系统，系统将按照这个 
给定的操作进行预订的状态变换，以此来达成脚本的功能，操作分为两个种类，循环性操作以及线性操作。 
步骤集 ： 每一个操作都有自己的一个步骤集，每个步骤可以理解为触发状态转移所需要执行的动作，
有些步骤只需进行简单的点击事件即可完成 而有些步骤则可能需要滑动页面后再进行点击事件。

通过以上的模型可以得出，这是数据结构中的有向图模型，我们每一个状态可以认为是一个点，每一个入口可以认为是一个单向边，对于我们使用软件的这个行为，则可以抽象成在图中进行连续点的遍历。

该项目向用户提供一个平台，用户可以在该平台上传对应软件的各个状态截图，再由这些截图来构建软件的任务模型，平台将托管该任务模型，并且执行用户预先编辑好的的操作， 以此来实现对相应软件的自动化操作。