├── 27f30b093b7237104dd9b098e70758e.jpg
├── LICENSE
├── README.md
├── on-the-criteria-to-be-used-in-decomposing-systems-into-modules
    ├── README.md
    └── figure1.drawio.svg
└── 今日阅读.md


/27f30b093b7237104dd9b098e70758e.jpg:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/taowen/awesome-lowcode/5de5c9201c46dd350607d53394b34303731baca0/27f30b093b7237104dd9b098e70758e.jpg


--------------------------------------------------------------------------------
/LICENSE:
--------------------------------------------------------------------------------
  1 | Creative Commons Legal Code
  2 | 
  3 | CC0 1.0 Universal
  4 | 
  5 |     CREATIVE COMMONS CORPORATION IS NOT A LAW FIRM AND DOES NOT PROVIDE
  6 |     LEGAL SERVICES. DISTRIBUTION OF THIS DOCUMENT DOES NOT CREATE AN
  7 |     ATTORNEY-CLIENT RELATIONSHIP. CREATIVE COMMONS PROVIDES THIS
  8 |     INFORMATION ON AN "AS-IS" BASIS. CREATIVE COMMONS MAKES NO WARRANTIES
  9 |     REGARDING THE USE OF THIS DOCUMENT OR THE INFORMATION OR WORKS
 10 |     PROVIDED HEREUNDER, AND DISCLAIMS LIABILITY FOR DAMAGES RESULTING FROM
 11 |     THE USE OF THIS DOCUMENT OR THE INFORMATION OR WORKS PROVIDED
 12 |     HEREUNDER.
 13 | 
 14 | Statement of Purpose
 15 | 
 16 | The laws of most jurisdictions throughout the world automatically confer
 17 | exclusive Copyright and Related Rights (defined below) upon the creator
 18 | and subsequent owner(s) (each and all, an "owner") of an original work of
 19 | authorship and/or a database (each, a "Work").
 20 | 
 21 | Certain owners wish to permanently relinquish those rights to a Work for
 22 | the purpose of contributing to a commons of creative, cultural and
 23 | scientific works ("Commons") that the public can reliably and without fear
 24 | of later claims of infringement build upon, modify, incorporate in other
 25 | works, reuse and redistribute as freely as possible in any form whatsoever
 26 | and for any purposes, including without limitation commercial purposes.
 27 | These owners may contribute to the Commons to promote the ideal of a free
 28 | culture and the further production of creative, cultural and scientific
 29 | works, or to gain reputation or greater distribution for their Work in
 30 | part through the use and efforts of others.
 31 | 
 32 | For these and/or other purposes and motivations, and without any
 33 | expectation of additional consideration or compensation, the person
 34 | associating CC0 with a Work (the "Affirmer"), to the extent that he or she
 35 | is an owner of Copyright and Related Rights in the Work, voluntarily
 36 | elects to apply CC0 to the Work and publicly distribute the Work under its
 37 | terms, with knowledge of his or her Copyright and Related Rights in the
 38 | Work and the meaning and intended legal effect of CC0 on those rights.
 39 | 
 40 | 1. Copyright and Related Rights. A Work made available under CC0 may be
 41 | protected by copyright and related or neighboring rights ("Copyright and
 42 | Related Rights"). Copyright and Related Rights include, but are not
 43 | limited to, the following:
 44 | 
 45 |   i. the right to reproduce, adapt, distribute, perform, display,
 46 |      communicate, and translate a Work;
 47 |  ii. moral rights retained by the original author(s) and/or performer(s);
 48 | iii. publicity and privacy rights pertaining to a person's image or
 49 |      likeness depicted in a Work;
 50 |  iv. rights protecting against unfair competition in regards to a Work,
 51 |      subject to the limitations in paragraph 4(a), below;
 52 |   v. rights protecting the extraction, dissemination, use and reuse of data
 53 |      in a Work;
 54 |  vi. database rights (such as those arising under Directive 96/9/EC of the
 55 |      European Parliament and of the Council of 11 March 1996 on the legal
 56 |      protection of databases, and under any national implementation
 57 |      thereof, including any amended or successor version of such
 58 |      directive); and
 59 | vii. other similar, equivalent or corresponding rights throughout the
 60 |      world based on applicable law or treaty, and any national
 61 |      implementations thereof.
 62 | 
 63 | 2. Waiver. To the greatest extent permitted by, but not in contravention
 64 | of, applicable law, Affirmer hereby overtly, fully, permanently,
 65 | irrevocably and unconditionally waives, abandons, and surrenders all of
 66 | Affirmer's Copyright and Related Rights and associated claims and causes
 67 | of action, whether now known or unknown (including existing as well as
 68 | future claims and causes of action), in the Work (i) in all territories
 69 | worldwide, (ii) for the maximum duration provided by applicable law or
 70 | treaty (including future time extensions), (iii) in any current or future
 71 | medium and for any number of copies, and (iv) for any purpose whatsoever,
 72 | including without limitation commercial, advertising or promotional
 73 | purposes (the "Waiver"). Affirmer makes the Waiver for the benefit of each
 74 | member of the public at large and to the detriment of Affirmer's heirs and
 75 | successors, fully intending that such Waiver shall not be subject to
 76 | revocation, rescission, cancellation, termination, or any other legal or
 77 | equitable action to disrupt the quiet enjoyment of the Work by the public
 78 | as contemplated by Affirmer's express Statement of Purpose.
 79 | 
 80 | 3. Public License Fallback. Should any part of the Waiver for any reason
 81 | be judged legally invalid or ineffective under applicable law, then the
 82 | Waiver shall be preserved to the maximum extent permitted taking into
 83 | account Affirmer's express Statement of Purpose. In addition, to the
 84 | extent the Waiver is so judged Affirmer hereby grants to each affected
 85 | person a royalty-free, non transferable, non sublicensable, non exclusive,
 86 | irrevocable and unconditional license to exercise Affirmer's Copyright and
 87 | Related Rights in the Work (i) in all territories worldwide, (ii) for the
 88 | maximum duration provided by applicable law or treaty (including future
 89 | time extensions), (iii) in any current or future medium and for any number
 90 | of copies, and (iv) for any purpose whatsoever, including without
 91 | limitation commercial, advertising or promotional purposes (the
 92 | "License"). The License shall be deemed effective as of the date CC0 was
 93 | applied by Affirmer to the Work. Should any part of the License for any
 94 | reason be judged legally invalid or ineffective under applicable law, such
 95 | partial invalidity or ineffectiveness shall not invalidate the remainder
 96 | of the License, and in such case Affirmer hereby affirms that he or she
 97 | will not (i) exercise any of his or her remaining Copyright and Related
 98 | Rights in the Work or (ii) assert any associated claims and causes of
 99 | action with respect to the Work, in either case contrary to Affirmer's
100 | express Statement of Purpose.
101 | 
102 | 4. Limitations and Disclaimers.
103 | 
104 |  a. No trademark or patent rights held by Affirmer are waived, abandoned,
105 |     surrendered, licensed or otherwise affected by this document.
106 |  b. Affirmer offers the Work as-is and makes no representations or
107 |     warranties of any kind concerning the Work, express, implied,
108 |     statutory or otherwise, including without limitation warranties of
109 |     title, merchantability, fitness for a particular purpose, non
110 |     infringement, or the absence of latent or other defects, accuracy, or
111 |     the present or absence of errors, whether or not discoverable, all to
112 |     the greatest extent permissible under applicable law.
113 |  c. Affirmer disclaims responsibility for clearing rights of other persons
114 |     that may apply to the Work or any use thereof, including without
115 |     limitation any person's Copyright and Related Rights in the Work.
116 |     Further, Affirmer disclaims responsibility for obtaining any necessary
117 |     consents, permissions or other rights required for any use of the
118 |     Work.
119 |  d. Affirmer understands and acknowledges that Creative Commons is not a
120 |     party to this document and has no duty or obligation with respect to
121 |     this CC0 or use of the Work.
122 | 


--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
  1 | # 国内低代码平台
  2 | 
  3 | ## 全栈平台
  4 | 
  5 | * 阿里-云凤蝶
  6 |   * [蚂蚁杨周璇：我做前端这十多年来的感悟](https://mp.weixin.qq.com/s/GiFpswpm_N_5MlnBywRTgw)
  7 |   * [云凤蝶可视化搭建的推导与实现](https://zhuanlan.zhihu.com/p/101665976)
  8 |   * [云凤蝶中台研发提效实践](https://zhuanlan.zhihu.com/p/78425921)
  9 |   * [中台建站的智能化探索](https://zhuanlan.zhihu.com/p/54422324)
 10 |   * [云凤蝶如何打造媲美 sketch 的自由画布](https://zhuanlan.zhihu.com/p/92469406)
 11 |   * [云凤蝶自由画布之道：分层模型](https://zhuanlan.zhihu.com/p/97768853)
 12 | * 阿里-金蝉
 13 |   * [长夜未央——企业级研发提效的下一阶段](https://zhuanlan.zhihu.com/p/66474056)
 14 |   * [十倍效能提升——Web 基础研发体系的建立](https://zhuanlan.zhihu.com/p/34790596)
 15 |   * [前端服务化——页面搭建工具的死与生](https://www.cnblogs.com/sskyy/p/6496287.html)
 16 | * [阿里-宜搭](https://www.aliwork.com/)
 17 | * 阿里-通用低代码基础设施
 18 |   * [低代码引擎搭建协议规范](https://lowcode-engine.cn/lowcode) | [低代码引擎物料协议规范](https://lowcode-engine.cn/material) | [低代码引擎资产包协
 19 | 议规范](https://lowcode-engine.cn/assets)
 20 |   * [阿里开源的低代码引擎](https://github.com/alibaba/lowcode-engine) | [官网](https://lowcode-engine.cn)
 21 |   * [阿里低代码引擎和生态建设实战及思考](https://mp.weixin.qq.com/s/MI6MrUKKydtnSdO4xq6jwA)
 22 | * 阿里-天马
 23 |   * [如何设计阿里经济体都在用的搭建服务—天马](https://zhuanlan.zhihu.com/p/137470317)
 24 | * 腾讯-积木
 25 |   * [积木系统v2@江源.pptx](https://vdisk.weibo.com/s/cSKQveSBDMPco)
 26 |   * [积木系统，将运营系统做到极致](https://cloud.tencent.com/developer/article/1055079)
 27 | * 腾讯-lowcode
 28 |   * [腾讯云开发低码平台](https://console.cloud.tencent.com/lowcode)
 29 |   * [腾讯无极低码平台](https://wujicode.cn)
 30 | * 葡萄城-活字格
 31 |   * [活字格企业级低代码开发平台](https://www.grapecity.com.cn/solutions/huozige)
 32 |   * [活字格产品经理胡耀：看活字格低代码平台是如何诞生的](https://www.soft6.com/news/2021/08/24/377493.html)
 33 |   * [驳“低代码开发取代程序员”论 为什么专业开发者也需要低代码？](https://segmentfault.com/a/1190000040842990)
 34 | * [无远开发平台](https://wuyuan.io/)
 35 |   * [案例](https://wuyuan.io/case)
 36 |   * [为什么专业开发者都选择无远](https://zhuanlan.zhihu.com/p/382493959)
 37 | * [得帆云](https://edu.definesys.cn/community/)
 38 |   * [得帆信息获评《2023年中国低/零代码行业研究报告》代表厂商](https://www.definesys.com/news/215)
 39 |   * [得帆信息连续两年荣获“最佳企业级低代码”称号](https://www.definesys.com/news/209)
 40 | * [奥哲](https://www.authine.com/)
 41 |   * [氚云](https://h3yun.com/index.php?g=Chuanyun&m=Index&a=index)
 42 | * [ivx](https://www.ivx.cn/index)
 43 |   * [关于iVX平台实现的总体技术栈【低代码/无代码、可视化开发语言】](https://blog.csdn.net/troymeng/article/details/110384703)
 44 |   * [iVX是怎么开发出来的？0代码开发的理论基础是什么？](https://zhuanlan.zhihu.com/p/100838156)
 45 |   * [iVX和其它低代码的平台的区别，“低代码/无代码”分三类](https://blog.csdn.net/qq_42146402/article/details/130836825)
 46 |   * [如何正确全面评价一个低代码平台？分析数十家国内外低代码平台得出的经验](https://devpress.csdn.net/low-code/645e124b59eeb95b5bb9b0e1.html)
 47 |   * [对程序员最友好的低代码平台——iVX（个人开发者终身免费）](https://devpress.csdn.net/low-code/647d9cd2762a09416a07f613.html)
 48 |   * [不能真“生成代码”的“低代码”平台，不可能真正获得程序员的认可](https://devpress.csdn.net/low-code/647dcaef762a09416a07f642.html)
 49 |   * [ih5](https://www.ih5.cn/)
 50 | * [闪电数据管理](http://www.gitmen.com/lightning)
 51 |   * [闪电数据管理 —— 无代码数据管理(开发)系统](https://zhuanlan.zhihu.com/p/162964986)
 52 |   * [lightning —— 基于Django的无代码Admin及低代码开发框架](https://github.com/git-men/lightning)
 53 | * [巴克云](https://www.buckycloud.com/)
 54 | * [轻魔方](https://team.qingmofang.cn/)
 55 | * [数式科技](https://shushi.pro/technology)
 56 | * [明道云](https://www.mingdao.com/) 支持公共云和私有部署，私有部署在Github可获得[免费社区版下载](https://github.com/mingdaocom/private-deployment)
 57 | * [轻流](https://qingflow.com/)
 58 | * [速融云](https://www.surongyun.cn/)
 59 | * [简道云](https://www.jiandaoyun.com/)
 60 | * [启业云](https://www.qycloud.com.cn/)
 61 | * [双链DaaS](https://github.com/doublechaintech/daas-start-kit)
 62 |   * [直接通过Github Actions体验](https://github.com/doublechaintech/daas-with-github-actions)
 63 |   * [大型系统构建案例-1.5K Stars](https://github.com/doublechaintech/scm-biz-suite)
 64 |   * [包含实时预效果的KSML操练场-开发中](http://kg2x.doublechaintech.com/view/playground)
 65 | * [炎黄盈动](https://www.actionsoft.com.cn/)
 66 | * [广州天翎myApps](http://www.teemlink.com/)
 67 | * [起步科技](http://www.wex5.com/)
 68 | * [金蝶云-苍穹](http://www.kingdee.com/products/cosmic)
 69 | * [普元](http://primeton.com/products/ep/overview.php)
 70 | * OpsMind
 71 |   * [OpsMind 前端低代码开发平台--MPlatform](https://mp.weixin.qq.com/s/gTVUii6ekVZNoX-6k5UCcg)
 72 | * [xdeer](https://www.xdeer.cn/)
 73 | * [湘北智造](https://www.xjrsoft.com/)
 74 | * [表单大师](https://www.jsform.com/)
 75 | * [Zion/载航](https://functorz.com/)
 76 | * [Appsmith](https://www.appsmith.com/)（[Github](https://github.com/appsmithorg/appsmith)）
 77 | * [ILLA Cloud/艾拉云](https://www.illacloud.com/)（[Github](https://github.com/illacloud/illa-builder)）
 78 | * [白码](https://www.bnocode.com/product.html)
 79 | * [捷码](https://gemcoder.com/)
 80 |   * 支持业务系统/管理系统、可视化大屏、3D园区低码快速开发
 81 |   * 支持离线部署
 82 | * [明源云-天际开放平台](https://open.mingyuanyun.com)
 83 |   * [移动平台](https://open.mingyuanyun.com/product/mpaas)
 84 |   * [建模平台](https://open.mingyuanyun.com/product/platform)
 85 | * [织信低代码平台](https://www.informat.cn/)
 86 |   * [平台简介](https://www.informat.cn/promotion)
 87 |   * [生产领域实践案例&君乐宝](https://www.informat.cn/case/jlb)
 88 |   * [织信Informat携手低码星球探讨「企业数字化转型之路」](https://www.informat.cn/detail/248)
 89 |   * [如何通过织信Informat快速搭建流程审批系统？](https://www.informat.cn/detail/228)
 90 |   * [5K字深度讲解：如何用织信Informat搭建OA和进销存？](https://zhuanlan.zhihu.com/p/393588263)
 91 | * [crudapi-增删改查接口平台](https://crudapi.cn)
 92 |   * [无需编程，通过配置零代码生成crud增删改查RESTful API和UI](https://help.crudapi.cn/helloworld.html)
 93 |   * [前端（开源）](https://github.com/crudapi/crudapi-admin-web)：Vue + Quasar实现Web管理UI，可任意修改。
 94 |   * [后端（商业使用永久免费，无任何功能限制）](https://github.com/crudapi/crudapi-example)：Java + Jdbc实现Service，数据库支持MySQL、PostgreSQL、SQL Server和Oracle，支持二次开发和私有部署。
 95 |   * [demo演示](https://demo.crudapi.cn/crudapi/)
 96 | * [Gadmin企业级低代码开发平台](https://www.gadmin8.com/)
 97 |   * [平台简介](https://www.gadmin8.com/index/about.html)
 98 |   * [平台演示](https://demo.gadmin8.com/)
 99 | * [象传智慧](https://www.iqka.com/docs/?engine)
100 |   * [Yao](https://yaoapps.com/)
101 | * [引迈信息](https://www.jnpfsoft.com/)
102 | * [兰途科技](http://www.app8848.com)
103 |   * [aPass软件工厂](https://www.yuque.com/books/share/9aab5860-6301-4519-a8ae-ac1d3b9dee11)
104 | * [矩阵低代码](https://www.deepmatrix.cn/) : 支持私有化部署，支持离线部署，私有化部署版本可跟随主版本免费升级
105 | 	* [平台演示](https://server.deepmatrix.cn/) : 账户：15000000000 密码： 123456
106 | 	* [平台介绍](https://www.deepmatrix.cn/)
107 | 	* [系统文档](https://www.yuque.com/dawei-ktv92)
108 | * [星云座插件式低代码](https://www.xingyunzuo.com/)
109 | 	* 插件方式融入现有的业务系统，贯通用户权限和业务数据，赋能业务系统具备低代码开发能力
110 | 	* 支持开发平台/项目私有化部署，开发平台与项目相互独立互补依赖
111 | 	* [产品介绍](https://mp.weixin.qq.com/s/3PyctlBCIbOQRiCunFlR3Q)
112 | 	* [平台演示](https://dev.xingyunzuo.com/): 用户名：18888888888 密码：888888
113 | 	* [产品视频](https://space.bilibili.com/2045740689)
114 | * [瓦立应用](https://www.waliapp.cn/)
115 | 	* 支持可视化小程序搭建、
116 | 	* 支持各种业务系统开发（具有表单、工作流、报表设计等模块）
117 | 	* [系统文档](https://www.yuque.com/zhonglixunni/wali)
118 | * [瀚码工业低代码](https://www.hancode.com/products/lcdp)
119 | 	* 四大工业特性：工业组件（工艺流程图、工作日历、脑图、树形图、鱼骨头...）、工业模版（MES、TPM、QMS、WMS、AMES）、移动PDA支持、系统对接（PLC、CNC、注塑机、ERP...）
120 | 	* 模型驱动、应用可与开发平台分离【重点】
121 | 	* [系统文档](https://hancode.yuque.com/ibi3kw/qzp9ku/ywwzqm)
122 | 	* [产品介绍](https://www.zhihu.com/question/402663485/answer/2772342587)
123 | * [网易数帆](https://sf.163.com/?opener=https%3A%2F%2Fsf.163.com%2F&productId=neteasecloud)
124 |   * [CodeWave 智能开发平台](https://sf.163.com/product/lcap?opener=https%3A%2F%2Fsf.163.com%2Fsolutionlowcap%3Fsite%3Dbanner&productId=homesite_product_qz)
125 |   * [文档中心](http://community.lcap.qz.163yun.com/CommunityParent/fileIndex)
126 | * OpenTiny TinyEngine低代码引擎
127 |   * [低代码引擎官网](https://opentiny.design/tiny-engine#/home)
128 |   * [Github](https://github.com/opentiny/tiny-engine)
129 |   * [低代码平台在线体验](https://opentiny.design/tiny-engine#/tiny-engine-editor)
130 | * [LuBase](https://lubase.cn)
131 |   	* [Gitee](https://gitee.com/lubase)
132 | 	* 框架简介：以数据模型驱动，可视化表单和页面设计，内置工作流引擎以及集多应用管理功能于一体的软件快速开发工具。
133 | 	* 框架定位：面向开发人员，针对管理软件领域，对页面交互和通用功能进行高阶封装，逐步打造成平台型、生态型开发工具。
134 | 
135 | ## 页面搭建
136 | 
137 | 仅包含前端部分的 low code 平台
138 | 
139 | * [MAKA](http://maka.im/)
140 | * [易企秀](https://store.eqxiu.com/)
141 | * [上线了](https://www.sxl.cn/)
142 | * [兔展](https://www.rabbitpre.com/)
143 | * [稿定设计](https://m.gaoding.com/)
144 | * [壹伴](https://yiban.io/)
145 | * [创客贴](https://www.chuangkit.com/)
146 | * [点石](https://www.h5ds.com/)
147 | * [Chameleon Engine](https://github.com/hlerenow/chameleon)
148 |   * 高自由度的可视化编辑引擎
149 | * 腾讯-tmagic-editor
150 |   * [开源的页面可视化搭建编辑器tmagic-editor](https://github.com/Tencent/tmagic-editor)
151 | * 京东-通天塔
152 |   * [京东商城活动页面构建系统——通天塔](https://blog.csdn.net/zl1zl2zl3/article/details/84661421)
153 | * [阿里-imgcook](https://imgcook.taobao.org/)
154 | * 转转-魔方
155 |   * [持续迭代的电商可视化运营页面生成系统](https://www.cnblogs.com/zhuanzhuanfe/p/10500786.html)
156 | * 人人贷-活动运营平台
157 |   * [活动运营自动化平台实践](https://zhuanlan.zhihu.com/p/68108055)
158 | * 美团-乐高
159 |   * [美团外卖前端可视化界面组装平台 —— 乐高](https://zhuanlan.zhihu.com/p/27288444)
160 | * [百度-h5](https://h5.bce.baidu.com/)
161 |   * [前端即服务-通向零成本开发之路](https://os.alipayobjects.com/rmsportal/sJqXvOtwePsVWGNIwlas.pdf)
162 | * 政采云-鲁班
163 |   * [前端工程实践之可视化搭建系统（一）](https://juejin.im/post/5d8774bff265da03ae78b2a1)
164 | * 携程-民宿CMS
165 |   * [活动专题系统搭建过程中我的一些思考](https://www.dazhuanlan.com/2019/10/07/5d9a698bdde35/)
166 | * 携程-乐高
167 |   * [干货 | 已配置4000+页面，携程前端组件化探索之“乐高”运营系统](https://mp.weixin.qq.com/s/WDCkXEBa0bA-h_8L6cBcJw)
168 | * 云智慧-FlyFish
169 |   * [低门槛、高拓展性的低代码应用开发平台](https://www.cloudwise.ai/flyFish.html)
170 | * 知乎-Versatile Editor
171 |   * [「可视化搭建系统」——从设计到架构，探索前端领域技术和业务价值](https://zhuanlan.zhihu.com/p/164558106)
172 | * [阿里-bi designer](https://github.com/dt-fe/weekly/blob/v2/164.%E7%B2%BE%E8%AF%BB%E3%80%8A%E6%95%B0%E6%8D%AE%E6%90%AD%E5%BB%BA%E5%BC%95%E6%93%8E%20bi-designer%20API-%E8%AE%BE%E8%AE%A1%E5%99%A8%E3%80%8B.md)
173 | 
174 | 
175 | * [360 - 即视](https://arena.360.cn/)
176 | * http://h5.dooring.cn/
177 | * https://quarkly.io/  No-code / Low-code platform for creating websites and web apps.
178 | * [乐搭云](https://ledayun.com.cn/)
179 | * [愚公](https://yugong.dawenxi.art/dashboard/#/project)
180 | * [榫卯（sunmao-ui）](https://sunmao-ui.com/)
181 | * [Everright-formEditor](https://github.com/Liberty-liu/Everright-formEditor) 一个可视化低代码表单编辑器，拥有多个组件、适配跨平台、多语言支持
182 | * [LLMStack] (https://github.com/trypromptly/LLMStack)
183 | 
184 | ## 店铺装修
185 | 
186 | 非独立页面，依附于业务系统存在的页面搭建
187 | 
188 | * [shopify](https://apps.shopify.com/browse/store-design-page-builders)
189 | * 有赞-微页面
190 | * 淘宝店铺装修
191 | 
192 | ## ![Open Source Love svg3](https://badges.frapsoft.com/os/v3/open-source.svg?v=103)
193 | 
194 | * [阿里-飞冰](https://ice.work/)
195 | * [阿里-formilyjs](https://formilyjs.org/)
196 |   * [MegaLayout - 下一代Formily表单布局解决方案](https://zhuanlan.zhihu.com/p/133906363)
197 |   * https://github.com/alibaba/designable
198 | * [阿里-gaea-editor](https://github.com/ascoders/gaea-editor)
199 |   * [可视化在线编辑器架构设计](https://juejin.cn/post/6844903455417434119)
200 | * [阿里-sula](https://github.com/umijs/sula)
201 | * [视搭-视频可视化搭建](https://github.com/tnfe/shida)
202 | * https://github.com/alibaba/lowcode-engine
203 | * [blockVisualEditor](https://github.com/sww1230/blockVisualEditor)
204 | * [pager](https://github.com/laispace/pager)
205 | * [运满满-码良](https://github.com/ymm-tech/gods-pen)
206 |   * [如何设计高扩展的在线网页制作平台](https://juejin.im/post/5bd83daee51d4524b50d23b5)
207 | * [X-Page-Editor](https://github.com/OXOYO/X-Page-Editor-Vue)
208 | * [Vue-Layout](https://github.com/jaweii/Vue-Layout)
209 | * [antd-visual-editor](https://github.com/xinyu198736/antd-visual-editor)
210 | * [pipeline-editor](https://github.com/page-pipepline/pipeline-editor)
211 |   * [【第1524期】页面可视化搭建工具技术要点](https://mp.weixin.qq.com/s/90JJAFhGokKmicOQZxdAGg)
212 | * [panel-magic](https://ricbet.github.io/panel-magic/)
213 |   * [基于 Angular 的小程序可视化编辑器 Panel-Magic 的实现解析](https://zhuanlan.zhihu.com/p/101677992)
214 | * [百度外卖-blocks](https://github.com/Eyot424/blocks)
215 |   * [百度外卖如何做到前端开发配置化](https://juejin.im/post/59536bad6fb9a06ba024d96d)
216 | * [Esview ](https://github.com/furioussoul/esview)
217 | * [gen](https://github.com/genany/gen)
218 | * [bee gen pro](https://gocn.vip/topics/10724)
219 | * [百度-amis](https://github.com/baidu/amis)
220 |   * [Ovine](https://github.com/CareyToboo/ovine)：基于 amis 补全了路由、权限相关的组件
221 |   * [爱速搭](https://suda.baidu.com/)
222 | * [唯品会-ams](https://github.com/vipshop/ams)
223 | * [vue-admin](https://github.com/jiangshanmeta/vue-admin)
224 | * [鲁班 H5](https://github.com/ly525/luban-h5)
225 | * [华炎魔方](https://github.com/steedos/steedos-platform/)
226 |   * [低代码 DevOps 平台协议](https://low-code-protocol.com/docs/overview)
227 | * [h5-factory](https://github.com/yangyuji/h5-factory)
228 |   * [一个简单易用的电商活动页面生成系统](https://juejin.im/post/5cf328706fb9a07f042030f0)
229 | * [vision](https://github.com/tuoxiansp/vision)
230 | * [brick-design](https://github.com/brick-design/react-visual-editor)
231 | * [随心秀](https://github.com/lzuntalented/lz-h5-edit)
232 | * [yh5](https://github.com/qq15725/yh5)
233 | * [rxeditor](https://github.com/rxwater/rxeditor)
234 | * [activity-YD](https://github.com/vkcyan/activity-YD)
235 | * [layoutit](https://github.com/justjavac/layoutit)
236 | * [Ramiko](https://github.com/fantasticit/ramiko)
237 |   * [使用 React 构建页面可视化搭建工具](https://www.v2ex.com/t/685143)
238 | * [jeecg-boot](https://github.com/zhangdaiscott/jeecg-boot)
239 | * [sparrow-js](https://github.com/sparrow-js/sparrow)
240 |   * [实时输出前端代码，折腾大半年的开源项目 sparrow-js](https://www.v2ex.com/t/718505)
241 | * [Tefact](https://github.com/staringos/tefact): Tefact 轻量级无代码/低代码，H5、表单编辑器
242 | * [星搭](https://staringos.com): 星搭无代码平台，快速构建中后台、小程序
243 | * [好未来晓黑板go-zero微服务框架](https://github.com/tal-tech/go-zero): 你不需要懂微服务，懂业务就行
244 | * [cube](https://github.com/fantasticit/cube)：快速搭建中后台页面
245 | * [react-visual-design](https://github.com/react-visual-design/react-visual-design): 基于react的h5组件搭建
246 | * [Web Designer](https://github.com/xiaoai7904/web_designer)
247 | * [h5maker](https://github.com/zhengguorong/h5maker)
248 | * [pl-drag-template](https://github.com/livelyPeng/pl-drag-template)
249 | * [form-generator](https://github.com/JakHuang/form-generator)：Element UI表单设计及代码生成器
250 | * [form-render](https://github.com/alibaba/form-render)：通过 JSON Schema 生成标准 Form，基于React
251 | * [Vue Json Design](https://github.com/fyl080801/vjdesign)
252 | * [rebuild](https://gitee.com/getrebuild/rebuild)
253 | * [W5 SOAR](https://github.com/w5teams/w5)
254 | * [Moria - Lowcode development platform](https://github.com/MudOnTire/moria)
255 | * [NocoBase](https://github.com/nocobase/nocobase)：极易扩展的无代码开发平台
256 | * [Mall-Cook](https://github.com/wangyuan389/mall-cook)
257 | * [全象低代码平台渲染引擎 Artery Renderer](https://github.com/quanxiang-cloud/one-for-all/tree/main/packages/artery-renderer)
258 | * https://github.com/bojue/Web-Editor
259 | * [OpenDataV - 基于Vue3的拖拽式、低代码数据可视化平台](https://github.com/AnsGoo/openDataV)
260 | * [StaringOS MtBird](https://github.com/staringos/mtbird): 开源小程序、H5、网站低代码平台，无需代码，拖拽操作快速生成页面应用，数据可视化接入，定制业务自由拓展.
261 | * [quick-boot](https://github.com/csx-bill/quick-boot): 基于 Spring Cloud 2022 、Spring Boot 3、AMIS 和 APIJSON 的低代码系统.
262 | ---
263 | 
264 | * https://github.com/blocks/blocks
265 | * https://github.com/frappe/frappe
266 | * https://github.com/ipselon/structor
267 | * https://github.com/vigetlabs/colonel-kurtz
268 | * https://github.com/BuilderIO/builder
269 | * https://github.com/vuegg/vuegg
270 | * https://webcodesk.com/
271 | * https://github.com/odoo/odoo
272 | * https://github.com/imgcook/imove
273 | 
274 | ## 办公/管理系统 a.k.a no-code
275 | 
276 | * [黑帕云](https://hipacloud.com/)
277 | * [极星协作](https://app.bjx.cloud/template)
278 | * [维格表](https://vika.cn/)
279 | * [阿里云-Teambition](https://www.teambition.com/tour)
280 | * [阿里云-RPA](https://cn.aliyun.com/product/codestore)
281 | * [SeaTable](https://seatable.cn/)
282 | * [蒲公英-Tracup](https://www.tracup.com/)
283 | * [蒲公英-Seed](https://seed.pgyer.com/)
284 | * [伙伴云](https://www.huoban.com/)
285 | * [monday.com](https://monday.com/)
286 | * [Airtable](https://airtable.com/)
287 | * [Notion](https://www.notion.so/)
288 | * https://welovenocode.com/nocodelist
289 | * [Taskade](https://www.taskade.com/)
290 | 
291 | ## 声明式编程
292 | 
293 | * ["Probabilistic scripts for automating common-sense tasks" by Alexander Lew](https://www.youtube.com/watch?v=MiiWzJE0fEA)
294 | 
295 | ## 行业综述
296 | 
297 | * [Forrester《The State Of Low-Code Platforms In China》（中国低代码平台发展报告）](https://zhuanlan.zhihu.com/p/436106248)
298 | * [精读《对低代码搭建的理解》](https://zhuanlan.zhihu.com/p/161783546)
299 | * [页面可视化搭建工具前生今世](https://zhuanlan.zhihu.com/p/37171897)
300 | * [React.js 可视化编辑工具](https://juejin.im/post/5d7ae944f265da03c5033e38)
301 | * [对低代码、零代码产品的一些看法](https://zhuanlan.zhihu.com/p/156887528)
302 | * [对 aPaaS 的产品认知](https://zhuanlan.zhihu.com/p/149801853)
303 | * [无代码编程](https://zhuanlan.zhihu.com/p/61288928)
304 | * [万物代码化：从低代码、云开发到云研发的思考](https://zhuanlan.zhihu.com/p/141742525)
305 | * [《早早聊搞搭建》搞过搭建的我收获了什么？](https://juejin.im/post/6844904106767695880)
306 | * [工程化之低代码体系](https://juejin.cn/post/6913698066935578631)
307 | * [LowCode平台前端实战之京东投放素材中心](https://zhuanlan.zhihu.com/p/386761240)
308 | 
309 | ## 技术点
310 | 
311 | * 可逆计算
312 |   * [可逆计算：下一代软件构造理论](https://zhuanlan.zhihu.com/p/64004026)
313 |   * [从可逆计算看声明式编程](https://zhuanlan.zhihu.com/p/85492497)
314 | * [161.精读《可视化搭建思考 - 富文本搭建》](https://github.com/dt-fe/weekly/issues/262)
315 | * [面向 Model 编程的前端架构设计](https://zhuanlan.zhihu.com/p/144157268)
316 | * [流动的数据——使用 RxJS 构造复杂单页应用的数据逻辑](https://github.com/xufei/blog/issues/38)
317 | * [使用 React 写个简单的活动页面运营系统 - 设计篇](https://segmentfault.com/a/1190000004540256)
318 | * [【电商】用可视化编辑，解构看起来非常炫酷的专题页面](https://www.jianshu.com/p/c4359a7338d3)
319 | * [如何搭建一个功能复杂的前端配置化框架(一)](https://www.cnblogs.com/wukong-holmes/p/9287763.html)
320 | * [可视化拖拽组件库一些技术要点原理分析](https://juejin.cn/post/6908502083075325959)
321 | * [可视化拖拽组件库一些技术要点原理分析（二）](https://juejin.cn/post/6918881497264947207)
322 | * [可视化拖拽组件库一些技术要点原理分析（三）](https://juejin.cn/post/6929302655118344200)
323 | * [可视化拖拽组件库一些技术要点原理分析（四）](https://juejin.cn/post/7129311619963682830)
324 | * [低代码与大语言模型的探索实践](https://github.com/woai3c/Front-end-articles/issues/45)
325 | * [揭秘活字格最受程序员喜爱的三大功能背后的设计思路](https://www.grapecity.com.cn/blogs/huozige-the-three-most-popular-features-for-programmers)
326 | 
327 | ## 国外
328 | 
329 | * https://www.honeycode.aws/
330 | * https://developers.google.com/appmaker
331 | * https://powerapps.microsoft.com/zh-cn/
332 | * https://www.zoho.com/creator/
333 | * https://www.salesforce.com/
334 | * https://www.appian.com/
335 | * https://bubble.io/
336 | * https://momen.app/
337 | * https://www.adalo.com/
338 | * https://thunkable.com/
339 | * http://www.vvveb.com/vvvebjs/editor.html
340 | * https://www.forestadmin.com/
341 | * https://mobirise.com/
342 | * https://paperbits.io/
343 | * https://builderx.io/
344 | * https://grapesjs.com/
345 | * https://reactstudio.com/
346 | * https://www.wix.com/
347 | * https://university.webflow.com/
348 | * https://www.squarespace.com/
349 | * https://www.framer.com/
350 | * https://www.figma.com/
351 | * https://linx.software/
352 | * https://www.mendix.com/zh/
353 | * https://www.outsystems.com/
354 | * https://retool.com/
355 | * https://www.quickbase.com/
356 | * https://layoutit.com/
357 | * https://www.claris.com/zh/filemaker/
358 | * FoC 聊天记录：https://marianoguerra.github.io/future-of-coding-weekly/history/?fromDate=2017-06-13&toDate=2017-06-14&channel=general&filter=
359 | * https://www.joget.com/
360 | * https://help.appsheet.com/en/
361 | * https://appery.io/
362 | * [ERD Lab](https://www.erdlab.io/) - Free cloud based entity relationship diagram (ERD) tool made for developers.
363 | 
364 | # 一切改进都是源自于人类的缺陷
365 | 
366 | ## How we think
367 | 
368 | * 人脑是串行的，无法有效并行思考多条线索
369 |   * 人脑不适合思考并行执行的多线程
370 |     * 【单线程】把共享变量的编程模式改成事务整体提交的模式
371 |   * 人脑不适合思考同时呈现在屏幕上的多个独立的业务流程
372 |     * 代码是按发生时间组织的，在一起的代码未必是逻辑上有关联的业务流程
373 |       * 【按业务切分文件】阅读者应该可以按照自己的任务目标来跟踪索引，而不是默认一个按钮点击引起的处理逻辑都一定要写在一个大文件里
374 |       * 【按变更频率切分文件】业务变更是阅读的首要原因，代码应该按照业务变更的频率来组织。会同时变更的代码应该放在一起
375 |   * 人脑很难管理多份独立可变的状态，本质上每个独立变化的状态就是一个独立的线程
376 |     * 驱动状态数量熵增的三大因素：
377 |       * 因为交互体验的要求，从后端到富客户端到3d动画，状态被复制多份，越来越靠近展示层
378 |       * 因为硬件物理的约束，内存从CPU统一寻址，到异构计算，CUDA，每个硬件核都有一层自己的内存
379 |       * 因为数据量的增长，从统一的OLAP从库，到Data Lake，Data Mart，数据被复制成越来越多份，流水线越来越长
380 |     * 对抗状态数量熵增的手段：
381 |       * 【声明式数据联动】减少独立变化的状态，用表达式来表达 derived state
382 |       * 【全局虚拟数据层】借鉴Unix的统一文件抽象，引入一层统一的虚拟数据层。尽可能把状态转化成 cache
383 |   * 人脑很难理解新增对原有行为的剧烈变化，更习惯逐层稳定叠加。也就是人更希望“控制变量”
384 |     * css 最大的难度在于不正交，新增一条对规则会引起意想不到的效果
385 |       * 【局部化布局】swiftui 的 HStack/VStack/ZStack 布局规则数量少，每条规则作用都是局部的稳定的叠加
386 |     * 性能优化往往需要破坏局部性，因为局部的自治容易引起重复劳动
387 |       * 【局部化IO】系统自动实现 I/O 的批量等可以自动化做的全局优化
388 |       * 【局部化IO】业务写成自治的，但是可以附加额外的手工全局调优。而不是强制要求把业务逻辑从局部抽出去
389 | 
390 | ## How we perceive
391 | 
392 | * 人眼只能在狭窄的感受野里获得信息
393 |   * 人对时间的感知是来自于对空间的感知
394 |   * 人希望在一个屏幕内从上往下的获取时间顺序上从早到晚的信息
395 |     * callback 的编程方式破坏了屏幕上的顺序和时间顺序的直接映射关系
396 |       * 【协程式IO】用协程取代 callback，把屏幕上的代码撸直
397 |     * 通过 status 字段驱动的业务状态机破坏了屏幕上的顺序和时间顺序的直接映射关系
398 |       * 【协程式业务流程】用协程取代 status 状态机，把屏幕上的代码撸直
399 |   * 因为感受野的限制，源代码没有空间展示所有的细节
400 |     * 类型定义，内存分配等“细节”占用了大量的视觉区域
401 |       * 【IDE细节隐藏】在文本上省略掉细节，由 IDE 进行补全，当鼠标移动上去的时候才展示出来
402 |     * 人最习惯的空间整理方式仍然是层状的文件夹
403 |       * 所有的“架构”设计，最终都是对文件夹和文件的设计。但是一个维度的静态索引（文件夹嵌套）无法满足所有可能的检索需求
404 |         * 【IDE按需索引】由 IDE 来补全文件夹分类不能满足的索引需求，针对阅读者的任务来设计IDE索引
405 |   * 视杆细胞容易忽略形状和顺序的差异，但是对颜色更敏感
406 |     * 语法高亮占用了宝贵的资源，但是并没有考虑阅读者的诉求
407 |       * 【IDE按需高亮】对于不同的任务，阅读者希望找到的重点是不同的，语法高亮应该结合任务来做
408 | 
409 | ## How we collaborate
410 | 
411 | * 人与人之间最高效的沟通的方式是面对面的交互式声波震动
412 |   * 人类低下的沟通带宽根本上限制了一个团队的规模
413 |     * 上线速度要求越快越好，但是加人带来的边际效益递减
414 |       * 减少开会拉齐，团队应该尽可能地自治，而不是什么都要靠 feature team 横向拉通
415 |         * 高内聚，低耦合
416 |           * 【静态链接包】编程工具应该提供更多的组合可能，而不是所有的组合都要在运行时用面向对象的多态来实现
417 |           * 【按变更频率切分包】分工应该按照变更频率来确定，分工应该是明确的
418 |   * 尽可能由最终用户，或者靠近最终用户的团队来解决问题，而不是长距离传递需求
419 |     * 最终用户编程：直接让需求提出者自己来实现需求
420 |       * 把“学习”内置到工具里，需要内置一个教学工具
421 |         * 最终用户的编程工具开发难度高，成本高，投入超过了单个软件的回报
422 |           * 【编辑器预制】把“公式编辑”，“店铺装修”等常见共性需求提前预制
423 |       * 教学工具的目标是教学，而不是把自己标杆为更先进的生产力
424 |         * 【教学内置】提供教学模式和生产力模式的无缝切换
425 |     * 低代码编程：通过提前预制，把工作量前置，减少应用开发者的规模，从而可以在组织架构上把开发者内置到用户组织内部。与此相对应的是文档驱动的外包式开发。
426 |       * “预制”来自于对共性需求的提前预判
427 |         * 【非功能性需求云化】非功能性需求的实现，都是运行在相似的机器上
428 |           * 操作系统
429 |           * k8s
430 |           * RPC 框架
431 |         * 开发者都是人类
432 |           * 编程工具
433 |           * 沟通工具
434 |         * 用户都是人类
435 |           * 【SaaS组件】IM / 电话 / 短信
436 |           * 【Ui组件】字处理器 / 表格
437 |           * 【CRUD生成】惯用的展现和交互
438 |             * 列表详情
439 |             * 树状层级
440 |             * 表格结构
441 |             * 可拖拽白板
442 |         * 【SaaS组件】相对稳定的业务流程
443 |           * 登录注册
444 |           * 支付
445 |         * 行业内相对稳定的业务共性流程
446 |           * 电商
447 |           * HR / 招聘
448 |           * 销售管理 / CRM
449 | 
450 | ## How we learn
451 | 
452 | * 人的“归纳/理解/学习”能力高度依赖于可视化交互式地操纵与反馈
453 |   * 帮助应该放在任务执行的地方，与其说“可视化”，不如说是“可发现”
454 |     * 【填空题变选择题】单独的语法手册是不好使的，必须提供界面上的按钮，把填空题变成选择题，这样才能启发学习
455 |       * GUI 设计器 / 店铺装修
456 |       * 公式编辑器
457 |       * 审批 / 工作流设计器
458 |       * trigger 流程设计器
459 |   * 人习惯于用手触碰一下对象，然后观测其反馈，从而归纳学习
460 |     * 不可观测的行为无法学习
461 |       * 生产环境的bug无法本地复现，我怎么找规律？
462 |         * 【TestInProduction】tracing，大量的 tracing，流量回放
463 |       * lowcode 平台的bug没有任何线索，除了找平台开发者，我能怎么办？
464 |         * 不能要求用户了解所有的内部细节，“平台”要做到可依赖
465 |         * 业务逻辑问题的定位和生产环境的bug定位一样，靠 tracing
466 |     * 反馈太慢的行为给人的负面感受是指数增加的
467 |       * 本地机器太慢了跑不起来，需要上公司的沙盒环境来复现问题
468 |         * 【云IDE】
469 |       * 改完了代码需要重新编译重新加载
470 |         * 【LanguageServer】交互式开发的时候跳过不必要的编译
471 |         * 【所见即所得】所见即所得的 GUI 开发，本质上就是用解释器执行，换取编译时间的缩减
472 |         * 【HMR】重加载的时候保持页面状态
473 | 
474 | # no code / low code / pro code
475 | 
476 | 一切的改进都是源自于人类的缺陷
477 | 
478 | * no code：自己编程给自己用，给用户的感觉是一个更强大的办公/实用软件。主要的手段是用图形化操作等方式降低学习曲线。no code 一定要面向非常固定的领域才能做到好用。
479 | * low code：编程给其他人用，为此创造了一个 citizen developer 的概念。主要的手段是平台预制好常见的需求，减少需要从头写的代码。low code 也要面向指定的领域才能让平台提前预测需求，但相比 no code 可以不把使用场景限定得那么死。
480 | * pro code：low code 的平台自己不会选择 low code 来创建这个平台本身，因为 low code 并没有降低从头构建一个系统的成本。但是 pro code 的平台自己会选择 pro code 来创建这个平台本身，比如 react 开发者会选择用 react 来创建自己的开发工具，因为 pro code 的工具和平台都是以从根本上降低从头构建一个系统的复杂度为目标的。
481 | 
482 | # RSS 订阅【今日阅读】
483 | 
484 | https://github.com/taowen/awesome-lowcode/commits.atom
485 | 


--------------------------------------------------------------------------------
/on-the-criteria-to-be-used-in-decomposing-systems-into-modules/README.md:
--------------------------------------------------------------------------------
  1 | # On the criteria to be used in decomposing systems into modules
  2 | 
  3 | D. L. Parnas
  4 | 
  5 | Department of Computer Science Carnegie-Mellon University
  6 | 
  7 | Pittsburgh, Pa.
  8 | 
  9 | August, 1971
 10 | 
 11 | This works as supported by the Advanced Research Projects Agency of the Office of the Secretary of Defense (F44620-70-C-0107) and is monitored by the Air Force Office of Scientific Research. This document has been approved for public release and sale; its distribution is unlimited.
 12 | 
 13 | # Abstract 
 14 | 
 15 | This paper discusses modularization as a mechanism for improving the flexibility and comprehensibility of a system while allowing the shortening of its development time. The effectiveness of a "modularization" is dependent upon the criteria used in dividing the system into modules. Two system design problems are presented, and for each, both conventional and unconventional decomposition are described. It is shown that the unconventional decompositions have distinct advantages for the goals outlined. The criteria used in arriving at the decompositions are discussed. The unconventional decomposition, if implemented with the conventional assumption that a module consists of one or more subroutines, will be less efficient in most cases. An alternative approach to implementation which does not have this effect is sketched.
 16 | 
 17 | # Introduction
 18 | 
 19 | If programmers sang hymns, some of the most popular would be hymns in praise of modular programming. A lucid statement of this philosophy is to be found in a new textbook on the design of system programs which we quote below:
 20 | 
 21 | > "A well-defined segmentation of the project effort ensures system modularity. Each task forms a separate, distinct program module. At implementation time each module and its inputs and outputs are well-defined, there is no confusion in the intended interface with other system modules. At checkout time the integrity of the module is tested independently; there are few scheduling problems in synchronizing the completion of several tasks before checkout can begin. Finally, the system is maintained in modular fashion; system errors and deficiencies can be traced to specific system modules, thus limiting the scope of detailed error searching."[1, paragraph 10.23]*
 22 | 
 23 | I must begin by saying that I am in complete agreement with this statement though I might not agree with some possible interpretations. Note, however, that nothing is said about the criteria to use in dividing the system into modules. Because the decision to divide a system into n modules of a given size does not determine the decomposition, this paper will discuss that issue and, by means of examples, suggest the type of criteria that should be used in decomposing the system into modules.
 24 | 
 25 | # A brief status report
 26 | 
 27 | The major progress in the area of modular programming has been the development of coding techniques and assemblers which (1) allow one module to be written with little knowledge of the **code** used in another module and, (2) allow modules to be reassembled and replaced without reassembly of the whole system. This facility is extremely valuable for the production of large pieces of code, but its use has not resulted in the expected benefits. In fact, the system most often used as examples of the problems involved in producing large systems are themselves highly modularized programs which make use of the sophisticated coding and assembly techniques mentioned above.
 28 | 
 29 | # Expected benefits of modular programming
 30 | 
 31 | The expected benefits of modular programming fall into three classes: (1) managerial -- development time could be shortened because separate groups would work on each module with little need for communication (and little regret afterward that eree had not been more communication); (2) product flexiibility -- it was hoped that it would be possible to make quite drastic changes or improvements in one module without changing others; (3) comprehensibility -- it was hoped that the system could be studied a module at a time with the result that the whole system could be better designed because it was better understood.
 32 | 
 33 | # What is a "modularization"?
 34 | 
 35 | In the sequel I give several partial system descriptions called "modularizations". In this contexst "module" is best considered to be a work assignment unit rather than a subprogram. The modularizations are intended to describe the deisgn decisions which must be made **before** the work on independent modules can begin. Although quite different decisions are made in each alternative, in all cases the intention is to describe all "system level" decisions (i.e., decisions which affect more than one module).
 36 | 
 37 | # Example system 1: a KWIC index production system
 38 | 
 39 | For those who may not know what a KWIC index is the following description will suffice for this paper. The KWIC index system accepts an ordered set of lines, each line is an ordered set of characters. Any line may be "circularly shifted" by repeatedly removing the first word and adding it to the end of the line. The KWIC index system outputs a listing of all circular shifts of all lines in alphabetical order. This is a samll sytem. Except under extreme circumstances (huge database, no supporting software), such a system could be produced by a good programmer within a week or two. Consequently it is a poor example in the none of the reasons motivating modular programming are important for this sytem. Because it is impractical to treat a large system thoroughly, we shall go through the eexercise of treating this problem as if it were a large project. We give two modularizations. One, we fell, typifies current projects; the other has been used successfully in an undergraduate class project.
 40 | 
 41 | ## Modularization 1
 42 | 
 43 | We see the following modules:
 44 | 
 45 | **Module 1**: **Input**: This module contains a single main program which reads the data lines from the input medium and stores them in core for processing by the remaining modules. In core the characters are packed four to a word, and an otherwise unused character is used to indicate end of a word. An index is kept to show the starting address of each line.
 46 | 
 47 | **Module 2**: **Circular Shift**: This module is called after the input module as completed its work. Rather than store all of the circulaar shifts in core, it prepares an index which gives the address of the first character of each circular shift, and the original index of the line in the array made up by module 1. It leaves its output in core with words in pairs (original line number, starting address).
 48 | 
 49 | **Module 3**: **Alphabetizing**: This module takes as input the arrays produced by modules 1 and 2. It produces an array in the same format as that produced by module 2. In this case, however, the circular shifts are listed in another order (alphabetically).
 50 | 
 51 | **Module 4**: **Output**: Using the arrays produced by module 3 and module 1, this module produces a nicely formatted output listing all of the circular shifts. In a sophisticated system, the actual start of each line will be marked, pointers to further information may be inserted, the start of the circular shift may actually not be the first word in the line, etc., etc.
 52 | 
 53 | **Module 5**: **Master Control**: This module does little more than control t he sequencing among the other four modules. It may also handle error messages, space allocation, etc.
 54 | 
 55 | It should be clear that the above does not constitute a definitive document. Much more information would have to be supplied before work could start. The defining documents would include a number of pictures showing core formats, pointer conventions, calling conventions, etc., etc. Only when all of the interfaces between the four modules had been specified could work really begin.
 56 | 
 57 | This is a modularization in the sense menat by all proponents of modular programming. The system is divided into a number of relatively independent modules with well defined interfaces; each one is small enought and simple enough to be thoroughly understood and well programmed. Experiments on a small scale indicate that this is approximately the decomposition which would be proposed by most programmers for the task specified. Figure 1 gives a picture of the structure of the system.
 58 | 
 59 | Figure 1
 60 | 
 61 | Structure of KWIC index decomposition 1
 62 | 
 63 | ![figure1](./figure1.drawio.svg)
 64 | 
 65 | ## Modularization 2
 66 | 
 67 | We see the following modules:
 68 | 
 69 | **Module 1**: **Line Storage**: This module consists of a number of functions each one of which is given a precise specification in Figure 2. By calling these functions one may add a character to the end of the last word in the last line, start a new word, or start a new line. One may call other functions to find  the kth character of the kth word in the jth line. Other routines in this module may be called to reveal the number of lines, the number of words in a line, or the number of characters in any word. A precise definition of this module is  given in Figure 2. The method of specification haas been explained in [3].
 70 | 
 71 | **Module 2**: **Input**: This module reads the original lines from the input media **and calls the Line Storage module to have them stored internally**.
 72 | 
 73 | **Module 3**: **Circular Shifter**: This module contains a number of functions. CSSTUP cause the others to have defined values. The others are intended to be analogue of  the information giving functions in module 1. Using them one may refer to the kth character of jth word of  the ith circular shift, as well as getting the lengths of lines and words, etc. This is shown in Figure 3.
 74 | 
 75 | **Module 4**: **Alphabetizer**: This module consists principally of two functions. One, ALPH, must be called before the others will have a defined value. The second, ITH, will serve as an index. ITH(i) will give the index of the circular shift which comes ith in the alphabetical ordering. Formal definitions of these functions are given in Figure 4.
 76 | 
 77 | **Module 5**: **Output**: This module will give the desired printing of any circular shift. It calls upon Circular Shift functions.
 78 | 
 79 | **Module 6**: **Master Control**: Similar in function to the modularization above.
 80 | 
 81 | Figure 2
 82 | 
 83 | Definition of a "Line Storage" Module
 84 | 
 85 | **Introduction**: This definition specifies a mechanism which may be used to hold up to p1 line, each line consisting of up to p2 words, and each word may be up to p3 characters.
 86 | 
 87 | ```
 88 | Function WORD
 89 |   Possible values: integers
 90 |   initial values: undefined
 91 |   parameters: l,w,c all integer
 92 |   effect:
 93 |     call ERLWEL* if 1 < 1 or 1 > p1
 94 |     call ERLWNL if 1 > LINES
 95 |     call ERLWEW if w < 1 or w > p2
 96 |     call ERLWNW if w > WORDS(1)
 97 |     call ERLWEC if c < 1 or c > p3
 98 |     call ERLWNC if c > CHARS(1, w)
 99 |     
100 | ---
101 | * The routine named are to be written by the user of the module. The call
102 | informs the user that he has violated a restriction on the module; the sub-
103 | routine should contain his recovery instructions [3].
104 | ```
105 | 
106 | ```
107 | Function SETWRD
108 |   possible values: none
109 |   initial values: not applicable
110 |   parameters: l,w,c,d all integers
111 |   effect:
112 |     call ERLSLE if l < 1 or l > p1
113 |     call ERLSBL if l > 'LINES' + 1
114 |     call ERLSBL if 1 < 'LINES'
115 |     call ERLSWE if w < 1 or w > p2
116 |     call ERLSBW if w > 'WORDS'(1) + 1
117 |     call ERLSBW if w < 'WORDS'(1)
118 |     call ERLSCE if c < 1 or c > p3
119 |     if l = 'LINES' + 1 then LINES = 'LINES' + 1
120 |     if w = 'WORD'(1) + 1 then WORDS(1) = w
121 |     CHARS(1,w) = c
122 |     WORD(1,w,c) = d
123 | ```
124 | 
125 | # Comparison of the Two Modularizations 
126 | 
127 | Both schemes will work. The first is quite conventional; the second has been used successfully in a class project [7]. Both will reduce the programming to the relatively independent programming of a number of small, manageable, programs. We must, however, look more deeply in order to investigate the progress we have made towards the stated goals. 
128 | 
129 | I must emphasize the fact that in the two decompositions I **may not** have changed any representations or methods. It is my intention to talk about two different ways of cutting up what **may** be the same object. A system built according to decomposition 1 could conceivably be identical after assembly to one built according to decomposition 2. The differences between the two systems are in the way that they are divided into modules, the definitions of those modules, the work assignments, the interfaces, etc. The algorithms used in both cases **might** be identical. I claim that the systems are substantially different even if identical in the runnable representation. This is possible becuase the runnable representation is used only for running; other representations are used for changing, documenting, understanding, etc. In those other representations the two systems will not be identical. 
130 | 
131 | ## (1) Changeability. 
132 | 
133 | There are a number of design decisions which are questionable and likely to change under many circumstances. A partial list: 
134 | 
135 | 1. Input format. 
136 | 1. The decision to have all lines stored in core. For large indices it may prove inconvenient or impractical to keep all of the lines in core at any one time. 
137 | 1. The decision to pack the characters four to a word. In cases where we are working with small indices it may prove undesirable to pack the characters, time will be saved by a
138 | character per word layout. In other cases, we may pack, but in different formats. 
139 | 1. The decision to make an index for the circular shifts rather than actually store them as such. Again, for a small index or a large core^writing them out may be the preferable
140 | approach. 
141 | 1. The decision to alphabetize the list once, rather than search for each item when needed, or partially alphabetize as is done in Hoare's FIND [2]. In a number of circumstances it would be advantageous to distribute the computation involved in alphabetization over the time required to produce the index. 
142 | 
143 | It is by looking at changes such as these that we can see the differences between the two modularizations. The first change is, in both decompositions, confined to one module, but the second change would result in changes in every module for the first decomposition. The same is true of the third change. In the first decomposition the format of
144 | the line storage in core must be used by all of the programs. In the second decomposition the story is entirely different. Knowledge of the exact way that the lines are stored is entirely hidden from all but module 1. Any change in the manner of storage can be confined to that module! 
145 | 
146 | In fact, in some of the versions of this system there was an additional module in the decomposition. A symbol table module as described in [3] was used within the line storage module. This fact, where true, was completely invisible to the rest of the system. 
147 | 
148 | The fourth change is confined to the circular shift module in the second decomposition but in the first decomposition, the alphabetizer, and the output routines will also know of the change. 
149 | 
150 | The fifth change will also prove difficult in the first decomposition. The output module will expect the index to have been completed before it began. The alphabetizer module in the second decomposition was designed so that a user could not detect when the alphabetization was actually done. No other module need be changed. 
151 | 
152 | ## (2) Independent development. 
153 | 
154 | In the first modularization the interfaces between the modules are the fairly complex formats and table organizations described above. These represent design decisions which
155 | cannot be taken lightly. The table structure and organisation are essential to the efficiency of the various modules and must be designed carefully. The development of those formats will be a major part of the module development and that part must be a joint effort among the several development groups. In the second modularization the interfaces
156 | are more abstract, they consist primarily in the function names and the numbers and types of the parameters. These are relatively simple decisions and the independent development of modules should begin much earlier. 
157 | 
158 | ## (3) Comprehensibility. 
159 | 
160 | To understand the output module in the first modularization, it will be necessary to understand something of the alphabetizer, the circular shifter and the input module. There will be aspects of the tables used by output which will only make sense because of the way that the other modules work. There will be constraints on the structure of the tables due to the algorithms used in the other modules. The system will only be comprehensible as a whole. It is my subjective judgment that this is not true in the second modularization
161 | 
162 | # The Criteria 
163 | 
164 | Many readers will now see what criteria were used in each decomposition. In the first decomposition the criterion used was make each 'major step' in the processing a module. One might say that to get the first decomposition one makes a flowchart. Figure 1 is a flowchart. This is the most common approach to decomposition or modularization. It is an outgrowth of all programmer training which teaches us that we should begin with a rough flowchart and move from there to a detailed implementation. The flowchart was a useful abstraction for systems with on the order of 5,000-10,000 instructions, but as we move beyond that it does not appear to be sufficient; something additional is needed. 
165 | 
166 | The second decomposition was made using "information hiding" [4] as a criteria. The modules no longer correspond to steps in the processing. The line storage module, for example, is used in almost every action by the system. Alphabetization may or may not correspond to a phase in the processing according to the method used. Similarly, circular shift might, in some circumstances, not make any table at all but calculate each character as demanded. Every module in the second decomposition is characterized by its knowledge of a design decision which it hides from all others. Its interface or definition was chosen to reveal as little as possible about its inner workings. 
167 | 
168 | # Improvement in Circular Shift Module 
169 | 
170 | To illustrate the impact of such a criterion let us take a closer look at the definition of the circular shifter module from the second decomposition. Hindsight now suggests that this definition reveals more information than necessary. While we have carefully hidden the method of storing or calculating the list of circular shifts, we have indicated an order to that list. Programs could be effectively written if we specified only (1) that the 'lines1 indicated in circular shift's definition will all exist in the "table", (2) that no one of them would be included twice and (3) that a function existed which would allow us to identify the original line given the "shift". By prescribing the order for the shifts we have given more information than necessary and so unnecessarily restricted the class of systems that we can build without changing the definitions. For example, we have not allowed for a system in which the circular shifts were "produced" in alphabetical order, alph is empty, and ITH simply returns its argument as a value. Our failure to do this in constructing the systems with the second decomposition must clearly be classified as a design error. 
171 | 
172 | # Efficiency and Implementation 
173 | 
174 | If we are not careful the second decomposition will prove to be much less efficient. If each of the "functions" is actually implemented as a procedure with an elaborate calling sequence there will be a great deal of such calling due to the repeated switching between modules. The first decomposition will not suffer from this problem because there is relatively infrequent transfer of control between modules. 
175 | 
176 | To save the procedure call overhead yet gain the advantages that we have seen above we must implement these modules in an unusual way. In many cases the routines will be best inserted into the code by an assembler; in other cases, highly specialized and efficient transfers would be inserted. To successfully and efficiently make use of the second type of decomposition will require a tool by means of which programs may be written as if the functions were subroutines but assembled by whatever implementation is appropriate. If such a technique is used, the separation between modules may not be clear in the final code. For that reason additional, program modification, features would also be useful. In other words, the other representations of the program (which were mentioned earlier) must be maintained in the machine together with a machine supported mapping between them.
177 | 
178 | # A SECOND EXAMPLE: A MARKOV ALGORITHM TRANSLATOR 
179 | 
180 | Although the first example makes most of the points of this paper it will be useful to look briefly at a somewhat different example. This one is a translator intended to execute Markov Algorithms. Markov Algorithms have been described in numerous places; the description of them as a programming language is best found in Galler and Perils [6]. For those who are not familiar with them, Markov Algorithms might be described as a poor man's SNOBOL. The only memory in the machine is a character string (always expandable if needed). The algorithm is described by a set of rules. Each rule consists of a pattern to be matched and a substitution part specifying a string to be used to replace the matched wtring. The sequencing rule is that the first rule which can be applied (its pattern matches) is applied at the leftmost part of the register where it will match. When the substitution is complete, the first applicable rule again applies (i.e., there is no memory of the last rule to be applied or the last change made). 
181 | 
182 | # Conventional Modularizations 
183 | 
184 | There are two conventional modularizations of this type of translator, They are: 
185 | 
186 | ## 1. Interpretor 
187 | 
188 | **Input module**: Reads the input, parsing it into rules and storing a direct representation of the rule in core. 
189 | 
190 | **Interpretor**: Attempts to apply each rule to the register. It accesses the data structure storing the rules, uses the pattern to look for a match, and if a match is found, then uses the substitution to change the register. 
191 | 
192 | There may also be an output module doing appropriate printing. 
193 | 
194 | ## 2. Compiler: 
195 | 
196 | **Input module**: Reads the input, parses it, and passes a representation of each syntactic unit as a parameter to the next module, encoder. 
197 | 
198 | **Encoder**: This consists of routines which are passed a rule or part of a rule and produce machine code which would enact it, e.g., they produce a machine code program for each pattern which searches for the occurrence of that pattern. This is known as the compiled code. 
199 | 
200 | **Run Time Routines**: Consist of a standard set of machine code routines used in every algorithm. The compiled routines link to these routines for such functions as output, etc. 
201 | 
202 | # An Alternative Approach 
203 | 
204 | We have used successfully the following modularization: 
205 | 
206 | **Rule Storage**: Stores a representation of the rules in core. This module is in many ways analagous to the Line Storage Module. 
207 | 
208 | **Rule Interpretation**: Knows the meaning of a rule, e.g., knows how to examine the stored rule and apply any given rule. 
209 | 
210 | **Register Manipulation**: Consists of a set of routines which make all manipulations on the register. 
211 | 
212 | **Sequencing**: Chooses the next rule to be applied.
213 | 
214 | **Input**: Reads the input and calls rule storage and register manipulation modules for the purpose of internal storage. 
215 | 
216 | **Output**: Does necessary printing of register, last rule to apply, etc. 
217 | 
218 | # Discussion of Second Example
219 | 
220 | Many of the arguments from the first example could be repeated here. For example, the separation of register manipulation from the other modules allows easier changing of the register representation. The separation of rule sequencing from rule interpretation allows one to experiment easily with some of the other forms of Markov Algorithms described in [6]. 
221 | 
222 | We have chosen this example to make another point, however. This modularization has not made a decision between interpretor and compiler. We can switch between an interpretive translator and a compiler relatively easily and we can also choose many points on a spectrum between the two. Register manipulation, sequencing, input and output will remain (or may remain) with little changes. The major change is in the rule interpretation module, which in the compiler stores a machine code program once, but in the interpretor applies the rule when called to interpret. There can be a great deal of code in common between the two systems. For example, the register manipulation code is used in both versions. In the computer it is part of the run time routines; in the interpretor it is called by the rule interpretation module. 
223 | 
224 | # HIERARCHICAL STRUCTURE 
225 | 
226 | We can find a program hierarchy in the sense illustrated by Dijkstra [5] in the system defined according to decomposition 2. If a symbol table exists, it functions without any of the other modules, hence it is on level 1. Line storage is on level 1 if no symbol table is used or on level 2 otherwise. Input and Circular Shifter require line storage for their functioning. Output and Alphabetizer will require Circular Shifter, but since circular shifter and line holder are in some sense compatible it would be easy to build a parameterized version of those routines which could be used to alphabetize or print out either the original lines or the circular shifts. In the first usage they would not require circular shifter; in the second they would. In other words, our design has allowed us to have a single representation for programs which may run at either of two levels in the hierarchy. 
227 | 
228 | In discussions of system structure it is easy to confuse the benefits of a good decomposition with the benefits of a hierarchical structure. We have a hierarchical structure if a certain relation may be defined between the modules or programs and that relation is a partial ordering. The relation we are concerned with is "uses11 or "depends upon".  It is better to have a relation between programs since in many cases one module depends upon only part of another module (e.g.,  Circular Shifter depends only on the output parts of the line holder and not on the correct working of SETWORD). It is conceivable that we could obtain the benefits that we have been discussing without such a partial ordering, e.g., if all the modules were on the same level. The partial ordering gives us two additional benefits. First, parts of the system are benefited by (simplified) because they use the services of lower levels. Second, we are able to cut off the upper levels and still have a usable and useful product. For example, the symbol table can be used in other applications, the line holder could be the basis of a question answering system. The existence of the hierarchical structure assures us that we can "prune" off the upper levels of the tree and start a new tree on the old trunk. If we had designed a system in which the "low level" modules made some use of the "high level" modules we would not have the hierarchy, we would infd it much harder to remove portions of the system,and "level" would not have much meaning in the system. 
229 | 
230 | Since it is conceivable that we could have a system with the type of decomposition described shown in version 1 (important design decisions in the interfaces) but retain a hierarchical structure, we must conclude that hierarchical structure and "clean" decomposition are two desirable but independent properties of a system structure. 
231 | 
232 | # CONCLUSION
233 | 
234 | We have tried to demonstrate by these examples that it is almost always incorrect to begin the decomposition of a system into modules on the basis of a flowchart. We propose instead that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others. Since, in most cases, design decisions transcend time of execution, modules will not correspond to steps in the processing. To achieve an efficient implementation we must abandon the assumption that a module is one or more subroutines, and instead allow subroutines and programs to be assembled collections of code from various modules. 
235 | 
236 | # References
237 | 
238 | 1. Gauthier, Richard and Stephen Ponto, Designing Systems Programs, (C) 1970, Prentice-Hall, Inc.
239 | 2. Hoare, C. A. R., "Proof of a Program, FIND,11 Comm. ACM. January 1971.
240 | 3. Parnas, D. L., A Paradigm for Software Module Specification with Examples, Technical Report, Department of Computer Science, Carnegie Mellon University, Pittsburgh, Pa., 1971.
241 | 4. Parnas, D. L., Information Distribution Aspects of Design Methodology, Technical Report, Department of Computer Science, Carnegie-Mellon University, Pittsburgh, Pa., 1971. Also to be presented at the IFIP Congress 1971, Ljubeljana, Yugoslavia.
242 | 5. Dijkstra, E. W., "The T.H.E. Multiprogramming System," CACM, May 1967.
243 | 6. Galler, B. and A. J. Perils, A View of Programming Languages, Addison Wesley, 1970.
244 | 7. Parnas, D. L., A Course on Software Engineering, in preparation. 
245 | 
246 | 
247 | 
248 | 
249 | 


--------------------------------------------------------------------------------
/on-the-criteria-to-be-used-in-decomposing-systems-into-modules/figure1.drawio.svg:
--------------------------------------------------------------------------------
  1 | <svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1" width="203px" height="519px" viewBox="-0.5 -0.5 203 519" content="&lt;mxfile host=&quot;2ba402da-b815-4a6f-9014-d97ba9f3960a&quot; modified=&quot;2020-08-03T06:48:19.209Z&quot; agent=&quot;5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Code-Insiders/1.48.0-insider Chrome/83.0.4103.122 Electron/9.1.0 Safari/537.36&quot; etag=&quot;IIHzSllt-CbMB4q7pdeT&quot; version=&quot;13.1.3&quot;&gt;&lt;diagram id=&quot;6hGFLwfOUW9BJ-s0fimq&quot; name=&quot;Page-1&quot;&gt;7Vdbb5swFP41vE4BQrI8rmm2Vdq0SnnY+ujgE/DkcJBjGuiv3zE2t5BGVaOlq7SXhPPZx5jvwsULl7vyi2J5+h05SC+Y8NILb70gWPgR/RqgssB8PrFAogS3kN8Ba/EEDmymFYLDfjBRI0ot8iEYY5ZBrAcYUwoPw2lblMOz5iyBEbCOmRyjPwXXqUU/BvMO/woiSZsz+7OFHdmxZrK7kn3KOB56ULjywqVC1PZoVy5BGu4aXmzf52dG240pyPRLGma24ZHJwl3bXVYTp4D+FOQK9rQU0wINjlvTm+WFdtvXVcMJcKLIlah0iglmTK469EZhkXEwJ55Q1c35hpgT6BP4G7SunN6s0EhQqnfSjUIp9C/T/iFy1UNv5LZ0K9dF5Qq7T7O5Zxly0B4LFbtZgTMVUwm4WWGrDrkacAdaVTVFksh5HK7OnL+Sdl4nAR04FU4rEpxQpOZ7QjEqiMhj4jtaDROHVGhY56y+kgOlb0ihWxyUhvI8IeNLdQ0zZ12X3cbJhy4IfoOlvRA0bZdwMz/rVi4UhR3rvXLYikxkiTlhvUQsVFxIpurMia3ee8FM0tZuNgTNEnPUN/dEiozuMKau7xkbQV4wC6PioN6L+UlRVfWaTPnQH+va6uqy0ITj0EyvFJpwZIxlq/exzGsjf22NfytIfnTFJC1ek6QTGbL5GJPMZJ6yDWhBD83/qTmXmuk4NdGVUjMdmeBTI9vTCbne+kGzuGI+mjfNHjf3yjiNsDtioXwvZn6dKS91oGu9R5HpTtBWLadoFB4pZUPguo7EarfxIv2ikXw/Cn3qtfWNTT31/56pqew+JCyH3ddYuPoD&lt;/diagram&gt;&lt;/mxfile&gt;">
  2 |     <defs/>
  3 |     <g>
  4 |         <path d="M 101 60 L 101 123.63" fill="none" stroke="#000000" stroke-miterlimit="10" pointer-events="stroke"/>
  5 |         <path d="M 101 128.88 L 97.5 121.88 L 101 123.63 L 104.5 121.88 Z" fill="#000000" stroke="#000000" stroke-miterlimit="10" pointer-events="all"/>
  6 |         <g transform="translate(-0.5 -0.5)">
  7 |             <switch>
  8 |                 <foreignObject style="overflow: visible; text-align: left;" pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility">
  9 |                     <div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 1px; height: 1px; padding-top: 95px; margin-left: 101px;">
 10 |                         <div style="box-sizing: border-box; font-size: 0; text-align: center; ">
 11 |                             <div style="display: inline-block; font-size: 11px; font-family: Helvetica; color: #000000; line-height: 1.2; pointer-events: all; background-color: #ffffff; white-space: nowrap; ">
 12 |                                 In core representation of input
 13 |                             </div>
 14 |                         </div>
 15 |                     </div>
 16 |                 </foreignObject>
 17 |                 <text x="101" y="98" fill="#000000" font-family="Helvetica" font-size="11px" text-anchor="middle">
 18 |                     In core representation of input
 19 |                 </text>
 20 |             </switch>
 21 |         </g>
 22 |         <rect x="41" y="0" width="120" height="60" rx="9" ry="9" fill="#ffffff" stroke="#000000" pointer-events="all"/>
 23 |         <g transform="translate(-0.5 -0.5)">
 24 |             <switch>
 25 |                 <foreignObject style="overflow: visible; text-align: left;" pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility">
 26 |                     <div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 118px; height: 1px; padding-top: 30px; margin-left: 42px;">
 27 |                         <div style="box-sizing: border-box; font-size: 0; text-align: center; ">
 28 |                             <div style="display: inline-block; font-size: 12px; font-family: Helvetica; color: #000000; line-height: 1.2; pointer-events: all; white-space: normal; word-wrap: normal; ">
 29 |                                 Input Module
 30 |                             </div>
 31 |                         </div>
 32 |                     </div>
 33 |                 </foreignObject>
 34 |                 <text x="101" y="34" fill="#000000" font-family="Helvetica" font-size="12px" text-anchor="middle">
 35 |                     Input Module
 36 |                 </text>
 37 |             </switch>
 38 |         </g>
 39 |         <path d="M 101 190 L 101 263.63" fill="none" stroke="#000000" stroke-miterlimit="10" pointer-events="stroke"/>
 40 |         <path d="M 101 268.88 L 97.5 261.88 L 101 263.63 L 104.5 261.88 Z" fill="#000000" stroke="#000000" stroke-miterlimit="10" pointer-events="all"/>
 41 |         <g transform="translate(-0.5 -0.5)">
 42 |             <switch>
 43 |                 <foreignObject style="overflow: visible; text-align: left;" pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility">
 44 |                     <div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 1px; height: 1px; padding-top: 230px; margin-left: 101px;">
 45 |                         <div style="box-sizing: border-box; font-size: 0; text-align: center; ">
 46 |                             <div style="display: inline-block; font-size: 11px; font-family: Helvetica; color: #000000; line-height: 1.2; pointer-events: all; background-color: #ffffff; white-space: nowrap; ">
 47 |                                 In core directory defining all circular shifts
 48 |                                 <br/>
 49 |                                 of input lines in arbitary order
 50 |                             </div>
 51 |                         </div>
 52 |                     </div>
 53 |                 </foreignObject>
 54 |                 <text x="101" y="233" fill="#000000" font-family="Helvetica" font-size="11px" text-anchor="middle">
 55 |                     In core directory defining all circular shifts...
 56 |                 </text>
 57 |             </switch>
 58 |         </g>
 59 |         <rect x="41" y="130" width="120" height="60" rx="9" ry="9" fill="#ffffff" stroke="#000000" pointer-events="all"/>
 60 |         <g transform="translate(-0.5 -0.5)">
 61 |             <switch>
 62 |                 <foreignObject style="overflow: visible; text-align: left;" pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility">
 63 |                     <div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 118px; height: 1px; padding-top: 160px; margin-left: 42px;">
 64 |                         <div style="box-sizing: border-box; font-size: 0; text-align: center; ">
 65 |                             <div style="display: inline-block; font-size: 12px; font-family: Helvetica; color: #000000; line-height: 1.2; pointer-events: all; white-space: normal; word-wrap: normal; ">
 66 |                                 Circular
 67 |                                 <br/>
 68 |                                 Shifting
 69 |                             </div>
 70 |                         </div>
 71 |                     </div>
 72 |                 </foreignObject>
 73 |                 <text x="101" y="164" fill="#000000" font-family="Helvetica" font-size="12px" text-anchor="middle">
 74 |                     Circular...
 75 |                 </text>
 76 |             </switch>
 77 |         </g>
 78 |         <path d="M 101 330 L 101 383.63" fill="none" stroke="#000000" stroke-miterlimit="10" pointer-events="stroke"/>
 79 |         <path d="M 101 388.88 L 97.5 381.88 L 101 383.63 L 104.5 381.88 Z" fill="#000000" stroke="#000000" stroke-miterlimit="10" pointer-events="all"/>
 80 |         <g transform="translate(-0.5 -0.5)">
 81 |             <switch>
 82 |                 <foreignObject style="overflow: visible; text-align: left;" pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility">
 83 |                     <div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 1px; height: 1px; padding-top: 360px; margin-left: 101px;">
 84 |                         <div style="box-sizing: border-box; font-size: 0; text-align: center; ">
 85 |                             <div style="display: inline-block; font-size: 11px; font-family: Helvetica; color: #000000; line-height: 1.2; pointer-events: all; background-color: #ffffff; white-space: nowrap; ">
 86 |                                 In core directory defining circular shifts in 
 87 |                                 <br/>
 88 |                                 alphabetical order
 89 |                             </div>
 90 |                         </div>
 91 |                     </div>
 92 |                 </foreignObject>
 93 |                 <text x="101" y="363" fill="#000000" font-family="Helvetica" font-size="11px" text-anchor="middle">
 94 |                     In core directory defining circular shifts in...
 95 |                 </text>
 96 |             </switch>
 97 |         </g>
 98 |         <rect x="41" y="270" width="120" height="60" rx="9" ry="9" fill="#ffffff" stroke="#000000" pointer-events="all"/>
 99 |         <g transform="translate(-0.5 -0.5)">
100 |             <switch>
101 |                 <foreignObject style="overflow: visible; text-align: left;" pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility">
102 |                     <div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 118px; height: 1px; padding-top: 300px; margin-left: 42px;">
103 |                         <div style="box-sizing: border-box; font-size: 0; text-align: center; ">
104 |                             <div style="display: inline-block; font-size: 12px; font-family: Helvetica; color: #000000; line-height: 1.2; pointer-events: all; white-space: normal; word-wrap: normal; ">
105 |                                 Alphabetizer
106 |                             </div>
107 |                         </div>
108 |                     </div>
109 |                 </foreignObject>
110 |                 <text x="101" y="304" fill="#000000" font-family="Helvetica" font-size="12px" text-anchor="middle">
111 |                     Alphabetizer
112 |                 </text>
113 |             </switch>
114 |         </g>
115 |         <path d="M 101 450 L 101 503.63" fill="none" stroke="#000000" stroke-miterlimit="10" pointer-events="stroke"/>
116 |         <path d="M 101 508.88 L 97.5 501.88 L 101 503.63 L 104.5 501.88 Z" fill="#000000" stroke="#000000" stroke-miterlimit="10" pointer-events="all"/>
117 |         <g transform="translate(-0.5 -0.5)">
118 |             <switch>
119 |                 <foreignObject style="overflow: visible; text-align: left;" pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility">
120 |                     <div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 1px; height: 1px; padding-top: 480px; margin-left: 101px;">
121 |                         <div style="box-sizing: border-box; font-size: 0; text-align: center; ">
122 |                             <div style="display: inline-block; font-size: 11px; font-family: Helvetica; color: #000000; line-height: 1.2; pointer-events: all; background-color: #ffffff; white-space: nowrap; ">
123 |                                 Pretty Index
124 |                             </div>
125 |                         </div>
126 |                     </div>
127 |                 </foreignObject>
128 |                 <text x="101" y="483" fill="#000000" font-family="Helvetica" font-size="11px" text-anchor="middle">
129 |                     Pretty Index
130 |                 </text>
131 |             </switch>
132 |         </g>
133 |         <rect x="41" y="390" width="120" height="60" rx="9" ry="9" fill="#ffffff" stroke="#000000" pointer-events="all"/>
134 |         <g transform="translate(-0.5 -0.5)">
135 |             <switch>
136 |                 <foreignObject style="overflow: visible; text-align: left;" pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility">
137 |                     <div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 118px; height: 1px; padding-top: 420px; margin-left: 42px;">
138 |                         <div style="box-sizing: border-box; font-size: 0; text-align: center; ">
139 |                             <div style="display: inline-block; font-size: 12px; font-family: Helvetica; color: #000000; line-height: 1.2; pointer-events: all; white-space: normal; word-wrap: normal; ">
140 |                                 Output
141 |                             </div>
142 |                         </div>
143 |                     </div>
144 |                 </foreignObject>
145 |                 <text x="101" y="424" fill="#000000" font-family="Helvetica" font-size="12px" text-anchor="middle">
146 |                     Output
147 |                 </text>
148 |             </switch>
149 |         </g>
150 |     </g>
151 |     <switch>
152 |         <g requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility"/>
153 |         <a transform="translate(0,-5)" xlink:href="https://desk.draw.io/support/solutions/articles/16000042487" target="_blank">
154 |             <text text-anchor="middle" font-size="10px" x="50%" y="100%">
155 |                 Viewer does not support full SVG 1.1
156 |             </text>
157 |         </a>
158 |     </switch>
159 | </svg>


--------------------------------------------------------------------------------