系统建设的脊柱:表对象建模

0 评论 2691 浏览 8 收藏 15 分钟

随着不断深入的拆解,从产品经理的设计方法到系统的拆解,每一部分都有值得探索的地方。本文将对系统建设的脊柱:表对象建模进行拆解分析,希望对你有所启发。

随着不断深入的拆解,从产品经理的设计方法,到经典系统的拆解,到零代码平台的构建,一直在走系统建设方法路线。如今再看系统,希望打碎打散系统,从系统各个组成部分来拆碎重组,从系统的远近、放大视图多角度来审视系统。

一、MVC的俯瞰

系统类似一座大山,我们从太空逐渐落到系统山上来的角度查看系统。系统首先展示给我们三个部分:展示页面、接口、数据库表。

系统关键组成

展示页面,是用户最有感知的部分,用户可以操作并获取反馈;主要实现页面展现,是View的核心价值。

接口,是随用户操作实现数据更新的手段,并支持用户操作的提交;主要实现数据的交互,是Control的核心价值。

数据库表,是系统数据存储的具体承载,落地为分库分表存储,包括基础数据、业务数据(年度销售计划、生产计划)、操作执行数据、统计数据等;主要实现数据的存储,是Model的核心价值。

随着高度下降,系统展示给我们一个全貌,让三个大部展示更为细致。系统最直观的页面部分,页面一般为左右结构,左边为菜单,右边为具体的页面内容。由页面组件组成,具体可表现为新增页、编辑页、列表页、详情页、操作处理页。在低代码工具中,由“表单”搭建实现。

应用软件展示效果

如上图,展示了一个常见信息化系统的主体页面,左侧菜单包含:字典数据、基础数据、业务填报、数据统计、数据分析,支持基础数据的管理,完成业务数据的收集处理,达成数据统计、分析,形成完整的信息化业务循环。下图为设备管理与巡检的系统截图,展示“设备保修单”的填写内容。

系统页面交互

在上面的交互中,“设备保修单”提交内容,需要通过接口保存到数据库中。如下图所示,展示了设备检查记录的增删改查接口,也是所有操作具体记录的关键控制器。

接口(系统内部)

提交的方式是接口,提交的数据存储在数据库表中。

数据库表

一次提交的数据存在一张表,还是多张表,极大的影响接口实现的难度、数据存储的效率;也极大影响相关人员理解的难易,模型建设是最关键的承接。

MVC新解

二、表对象建模

如何有效进行“模型”建设?模型,也就是我们的对象,是我们需要操作、管理的具体事务的系统抽象。这里可使用面向对象的建模思想。

以线索创建为例,线索创建所有业务逻辑拆解到场景、流程、用户用例、功能点、具体规则或步骤中表达出来。

收集线索场景拆解

系统要实现“线索创建”相关的业务功能,就需要对应去实现功能点,包含:创建线索(联系方式、线索重复、归属人进行校验,并生成线索记录)、标记线索、通知线索、活动记录。如上分析,要更好的实现功能,更核心的是实现线索相关的对象建模。

创建线索领域

依据“线索创建”的业务分析,构建对应的领域。当前建立两个领域:线索、活动领域;线索与活动的关系主要是,线索是在某一个活动中产生的,领域是相对独立而不应该是包含关系。当前支持对线索进行标记,并支持线索通知相关人员,属于线索领域内,则在“线索”领域中构建“标记”、“通知”子领域。

领域划分的关键在于领域边界的确定,划分合理的领域将更好支持系统的扩展与稳定。下面通过问题、需求、缺陷的相互转换来细致分析边界的重要性。现实业务中,我们将不符合现实的情况定义为问题;将不符合现状,有期许的解决目标的情况定义为需求;将期许的解决目标和实际的实现不符的情况定义为缺陷。

问题、需求、缺陷的相互转换

业务意义不一样,其处理过程不一样。仅从 问题、需求、缺陷 信息实体本身来讲,差异并不是很大。都需要记录标题、状态、说明、提出人、提出时间、处理人等信息;但是需求需要经历设计、评审、排期、实现、测试等阶段,会比问题、缺陷多阶段信息;为提高缺陷的有效处理,增加缺陷的重开次数,防止推诿以及无效修改。

问题、需求、缺陷的属性设计

问题状态及操作

问题处理的关键在于符合现状,不管是做了一件事,抑或定了一个流程,亦或是各方同意搁置争议,那么不符合现状的情况被清理掉,问题就得到了解决。

需求状态及操作

需求的关键在于梳理清楚要怎么解决这个情况,并通过产品的方式来实现。

缺陷状态及操作

缺陷的关键在于解决目标和具体实现之间的差异,一般是调整实现方案,处理各种异常情况,最终符合预期。在明确了问题、需求、缺陷的领域后,可通过表对象建模,完成模型的构建。

三、工厂建模

一个制造业工厂的完整运转需要以下四个大环节:工厂建设、组织组建、物料转换、生产管理。

工厂建设主要完成工厂从荒山野地变成具备生产条件的过程管理,需要进行厂房建设、产线搭建、设备安装与调试。在软件系统中也需要恢复工厂基础信息,为后续的生产执行提供基础条件。系统建设中,需要支持工厂管理,包含工厂的基础信息如厂址、位置、法人等;需要支持产线/操组间管理,流程式生成需要完成产线建设,散点式生产需要完成操作间建设,这也需要依据现实情况来落地;需要支持设备管理,如冲压机、铸造机、热熔机等,在后续的管理中用于问题追踪、设备保养等。

工厂设备流

基于工厂建设,模型设计如下,工厂领域包含车间领域,和设备领域部分重叠。

工厂模型

组织建设主要完成工厂的人事架构录入,实现所有工厂用户进入系统。包含部门建设以及人员管理。

人员权限管理

基于系统建设原则,增加组织管理,以支持分子公司形式;增加角色管理,支持权限设置,提高权限设置便捷度。

人员管理模型

组织和人员的领域存在重叠,部门属于组织的子领域,角色属于人员的子领域。物料转换主要实现物料的跟踪,实现从生产原材料到产品的跟踪,管理物料和产品之间的比例关系,可支持物料损耗计算。

物料流

产品和物料分属独立的领域,通过BOM串联起来。产品工艺独属于产品,是产品的子领域。工艺独立成为子领域,是为支持工艺本身的管理,包含工艺的生产条件、工艺的技能需求等。

物料模型

生产管理主要实现生产任务的执行管理,从产品订单生成生产计划,由生产计划具体落实为生产任务,由公司整体的生产任务落地到产线、车间的作业计划。

生产管理

各模块相对独立又顺序关联。

生产模型

以上完成工厂建模的基础部分,但现实业务的复杂需要扩展更多领域进行支持,如设备的子领域、人员的子领域。

设备领域

设备领域中,可支持台账、维修、保养、点检;人员领域可支持:出勤、技能、薪酬、绩效、培训。

人员领域

基于领域,可以扩展各个领域的属性创建,完成表对象建模。表对象建模,更好的支持数据库表的创建,更好的支持数据库接口的实现,更好的明确各个系统模块之间的关系。表对象建模由业务拆分,更贴切的支持业务;表对象建模便捷支持单个领域接口生成,且更为合理支持多表联合查询,更好生成接口;表对象建模支持为所有单个领域提供新建、编辑、列表、详情、操作多个视图,更为便捷和高效。

专栏作家

壹叁零壹,公众号:壹叁零壹,人人都是产品经理专栏作家。攀山零代码产品的行者,产品思维的商贩。

本文原创发布于人人都是产品经理,未经许可,禁止转载

题图来自 Unsplash,基于 CC0 协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
海报
评论
评论请登录
  1. 目前还没评论,等你发挥!