# sailmi-ucs

**Repository Path**: tsony/sailmi-ucs

## Basic Information

- **Project Name**: sailmi-ucs
- **Description**: ucs
- **Primary Language**: Unknown
- **License**: 0BSD
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 1
- **Forks**: 2
- **Created**: 2021-03-10
- **Last Updated**: 2025-03-29

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# sailmi-ucs
   项目名称：Sailmi-UCS（通用创新服务平台unified creative service）</br>
   项目目标：为开发者提供一个通用的信息化实施框架，包含低代码与零代码工具，让开发人员把重点放到业务实现，将自己的思想快速转化为软件服务，并提供给企业使用，而非重复的人员、组织结构、权限等实现上,是知识转化为服务变现的手段。也做为个人技术实验室。</br>
   项目愿景：零代码！！！</br>
# 零代码
   为什么提零代码，而不是低代码？一是低代码，中间环节多，终归还是摆脱不了开发人员，只有零代码，业务人员才能真正不依赖开发人员，去实现自己的管理理念；二是零代码迭代更快，更符合当下企业快速变化的节奏；三是零代码更好做版本控制与迭代，系统的版本实质是模型版本的控制；四是零代码，通过建模去实现系统，即软件定义系统更有利于通过AI去生成系统，否则，生成系统的时候，需要参与的角色太多，而如果采用零代码的模式，AI只需要生成模型即可。当然，零代码也有一些限制，在使用过程中发现，主要是无法应对复杂业务，因此，最终的形态很可能是零代码+低代码，但是，零代码也会进化，谁又能说加入AI能力后，零代码只能应对简单场景呢？本项目希望通过对系统模型化的零代码尝试，为后续AI生成系统建立基础。
# 低代码与AI
   这里的低代码与现在比较火的Dify下的AI低代码框架不同，这里是基于确定的数据模型去生成系统，是传统的低代码。而Dify是开发智能体。个人认为这是两个不同的场景，所以UCS中也不准备集成这方面的内容，后续只会关注AI模型生成的问题，包括软件的表现层模型，但还没有具体思路，需要后期再思考，有想法的同学，可以一起沟通。此外，从多年信息化的角度来看，个人认为信息化系统应是确定性的，所有输入，其反馈应是可预测的，因此，在信息系统中，尤其是过程控制型系统中过多的引入智能体，个人认为有待考虑，毕竟，系统的一个变更，牵涉到的可能不是某个人，而是会影响到整个企业成百上千的人，如果把这些交给智能体，那么上线审批的人能确定其输出结果吗？如果能，那么还好，但自主智能的概念又何在？如果不能，那么对于企业，不一定是机遇，也有可能是灾难。从情感的角度上，信息系统是权威的，也不太能接受将整个公司的人的行为交给智能体去掌控：）
# 功能概述
  平台采用运营商、企业网状结构，即平台可以有多个运营商入驻，每个运营商又可以为多个企业服务。</br>
  具体功能包括：租户管理，各租户企业管理、服务包、字典管理。企业内部人员、权限及特性字典管理，建模工具，系统引擎等。</br>
  目前状态，策划与原型阶段，暂无文档支持。</br>
# 蓝图
  企业信息助理由System（SAAS基座）、EIMP（企业信息建模平台）、EICS(企业信息协同服务)、EISC（企业信息服务控制台）及GACT（通用物联采集终端）组成，完整概念图如下：
![UCS完整概念](ucs-docs/arch.png)
# 技术理念
  1、大前端，当下软件开发成本高，周期长，很大一部分原因是因为分工过细，十年前，一个后端，通过servlet与 jsp，一人可以单撸一个小系统，现在很难，毕竟从数据库、Java到前端都熟练的人，太少了，这种分工有他的好处，各个方向可以更专业，但实际上，增加了大量的沟通协调成本，大前端的概念就是打掉后台，打掉后台不是说不要服务端这一层，从权限控制、负载路由、复杂逻辑处理这一角度来看，后台是必要的，只是后台很小，在一个项目的研发中，他可能只占很少一部份，而工作量加到了前端的身上，前端不再只是画界面，做交互的事了，他还需要了解数据库，了解用户需求，了解JQL（个人起的一个名字，Json Query Languag,通过json来定义数据库访问），这样，后台提供通用的接口，业务变更，前台甚至都不需要后台处理，即可完成需求的迭代，这样提高开发效率，又不牺牲性能与前端用户体验。基于这个，所以在UCS中，是基于MPJ的基类生成的实体，接口可以实现联合、条件等常规查询。这种想法在几个项目中实践，效果还不错。</br>
  2、工业、企业信息化界面应至简，与C端界面不一样，C端的产品多种多样，所以，为了吸引客户，需要将大量的精力放到炫上，但企业应用不一样，因此在UCS中，会大量采用svg，x3d等技术，不会引入太多canvas相关的内容，主要就是考虑到够用就行，更便于用户专注到业务上，而不是奇炫的界面上。所以，下面的建模工具会考虑mxgraph，而不是gojs这些。
# 下一步计划
    1、可视化建模工具与系统引擎实现
    2、引入AI建模
# 里程碑
    1、可视化建模与引擎，预计年中形成Demo
    2、AI建模，预计年底形成Demo
# 主要业务流程
    企业入驻，运营服务团队可以通过建模平台(EIMP)建模，通过EISP对模型进行解析，企业其它部门访问EISP，消费服务。    

# 图片
![登录后首页](ucs-docs/main.png)    
![运营商首页](ucs-docs/Op_main.png)
![添加企业并初始化企业管理信息](ucs-docs/op_enterprise.png)
![添加系统模块](ucs-docs/op_system.png)
![添加菜单](ucs-docs/op_menu.png)
![构建服务包供企业订购](ucs-docs/op_servicepackage.png)
![企业申请开通服务包](ucs-docs/en_orderservice.png)