发布时间：2022-6-22 分类： 行业资讯
本文重点介绍建模知识在日常工作和实际设计中的应用。
以下是上一篇文章的摘要，在此补充;
角色矩阵，系统主要过程和状态图，三者相辅相成，平衡，最后实现完美统一;
梳理状态图后，调整补充系统的主要过程，调整系统主过程，调整补充角色矩阵;
同样，角色矩阵也限制和指导系统的主要功能，防止在梳理需求时无限放大;
相关阅读：
建模知识在需求分析与梳理中的应用（中）
数据库建模知识：在需求获取和分析中的应用（上）
一、原型线框图
在角色矩阵，系统主流程和状态图统一后，下一步是到原型化阶段。此阶段的主要目的是将每个实体的属性和实体之间的连接连接到我们的日常可见性和理解。提出的方式;
1.1 模块划分
基本模块的划分遵循实体的边界。一般而言，实体是基本模块。通常，模块的第一页以列表的形式显示;例如，通用的电子商务后端系统，即用户，商品和订单的基本模块，这些实际上是实体。 ;
统计，关联类，根据实际需要定义模块，通常显示在图表和列表中;
1.2 站点地图
系统中涉及的页面和页面之间的流程以地图索引的形式显示;一般按模块划分，如系统功能比较简单，系统可以是一个单元。
1.3 页面信息架构
也就是说，从建模的角度来看，页面呈现的信息实际上是实体属性和实体之间关系的显示;
实体属性，即实体的基本属性，如员工具有员工属性，姓名，身份证号，职位，性别，邮箱等基本属性;实体之间的关系，即实体与其他实体之间的先前联系，例如我们在文章中写的部门 - 人关系;
1: 1，当实体为1: 1时，当前实体的页面显示可以以其属性的形式显示对方实体;如公司的业务支持部门，经理张三，在员工基本信息页面，职位：部门经理，部门：业务支持部门;当部门的基本信息被查看时，部门：业务支持部门，部门经理：张三;
1：N，当实体为1：N联系时，当显示实体页面信息“1”时，可以以“下一页”或列表的形式显示; ““ N”的当显示物理页面信息时，可以以其属性的形式显示相反的“1”;例如，业务支持部门下有两名员工，即小莉和小黄。查看商家信息时，可以设置“ld”;下属员工”链接到下级页面，您还可以以列表的形式显示这两个员工信息。同样，当员工基本信息页面时，员工的部门/下属部门可以显示其基本属性;
N：N，当实体之间的关系为N：N时，相反的实体以下面的页面或列表的形式显示;对于学生课程，在学生模块中，所选课程可以以下面的页面形式显示，或以列表的形式显示;同样在课程模块中，学生选择哪些课程，可以在以下级别页面上显示，或以列表的形式显示;
二、设计原则
2.1 始终把“用户+需求”放在第一位
用户：系统的最终用户，遵循我们在前两篇文章中讨论过的角色实体;
要求：用户希望通过系统实现的功能，目的;
用户+要求：考虑功能的实际应用场景，并根据实际场景控制设计方向;
实际情景中应考虑的因素如下，并继续补充：
用户的年龄，直接影响视觉颜色，字体，字体大小等;
在过程跳转和提示中，用户的整体质量水平尽可能简单易懂;
用户所处的环境，无论用户是在更庄严的机构还是时髦的互联网行业，都有一套行业规则;
功能使用期限，频率;这直接影响了表结构的设计。在大频率的功能中，访问速度是一个需要考虑的问题;
2.2 遵循“高内聚，低耦合”的设计原则
这应该是我从大学一直强调的，就像指示灯指引我们前进;你会发现所有糟糕的设计逻辑都会忽略这个原理。
官方解释：
高内聚力：也称为块内接触。指模块功能强度的度量，即模块中每个元素彼此组合的紧密程度。如果模块中的元素（名称之间，块之间）更紧密地链接，则它更具凝聚力。
低耦合：尽可能在模块和模块之间建立一个完整的系统。换句话说，让每个模块尽可能独立地完成特定的子功能。模块和模块之间的接口尽可能小而简单。
官方解释主要针对模块。实际上，这个结论适用于大型平台和小型实体;
实体之间是一个板栗：我之前收到过一个项目，有一个这样的逻辑：“一个经销商最多有3个联系人”;在这个时候我们会怀疑，会有这样一个集合，这个规则在下面会有什么问题：
当经销商有超过3个联系人时，系统不支持;
该系统是一个简单到复杂的过程。在开头设置此类限制，如果您想稍后取消此设置，则会涉及许多更改;
实体不够独立并且过于依赖，因此不遵循高内聚和低耦合的原则;事实上，这是一个简单的1：N关系，只是在某些特定的方式，如导入经销商和他们的联系人这时，我们可以设置这个联系最多三个，但在使用系统，这关系是一种负担;
2.3 遵循“复用性”原则，所有设计力求复用最优化
官方解释：
可重用性，重用也称为重用，意味着重用。重用的好处可以带来更高的生产率，从而降低成本，提高软件质量（可以更快地纠正错误），正确的重用可以提高系统的可维护性。
模块之间的复用，即实体的复用，当N: N之间存在关系时，必须存在这样的复用关系;如果不存在，则设计可能不符合多路复用优化的标准。 ;
例如，我们的通用组件和产品之间的关系是N: N，它会在新创建产品时将组件添加为属性;
这样做的好处是：
该组件不需要重新创建，可以在添加产品时直接添加;
管理和控制组件;
如果我们改变设计思路，例如创建新产品，则逐个编辑组件信息，这将带来
如果不同产品的组件信息相同，请重复输入;
组件以属性的形式附加到产品，无法满足组件的可控要求;
层次关系的设计，即多个实体之间的层次关系，建议使用错误的数据结构设计，不建议跨层连接，即使有必要越过层次添加中间层层关系; p>
为了便于理解，提供以下实施例。
背景：Project-Reseller是N: N的关系，经销商联系是1：N的关系;
要求1：新增项目时，根据一定条件与经销商匹配，确认项目推送的经销商或预推;此时预推台结构的设计应该是项目经销商，而不是项目 - 联系或项目 - 经销商 - 联系;这种设计的好处是，
我们只修复了上半场的关系。后者的关系可以由经销商匹配。当经销商人员更换时，它不会产生任何影响。如果使用其他方法，经销商人员更换时会有更多。复杂的数据操作，以确保此功能不受影响;
经销商联系是1：N关系，插入项目 - 经销商关系是插入多个项目 - 联系或项目 - 经销商 - 联系关系，从数据冗余的角度来看，也是项目 - 经销商的关系是更合适;
要求2：项目推送，项目预推匹配成功后，可以推送项目。这才是真正的推动力。通过这种推动，触点可以看到前端的相应项目;而设计应该是如何
答案是：项目经销商联系;为何加入“经销商”？前面背景还说项目和联系人之间没有这种关系，产生关系的运营商实际上是“经销商”;这样做的好处是
当联系人清楚时，使用什么运营商（即经销商）来获得推送关系。当联系人和运营商之间的关系改变时，存在对关联数据执行相关操作的基础;例如，联系人从承运人A改变。转到B，此时，联系人通过A获得的联系关系应该被删除;
相反，如果您不加入“经销商”运营商，联系人可见的项目只会增加，因为我们没有此运营商的基础来运营数据;
注：所有实际需求均为标准，仅供参考;
三、日常设计要点
3.1 保持对需求的严谨态度
虽然需求量如此之大，但产品是一只狗（微笑），但我们必须始终保持严谨和谦逊的态度;软件知道即使是很小的需求，他的变化有时也不一定大于一。需求减少;因此，当提出要求时，我们希望确保我们拥有所有要求的细节和所涉及的所有变更;
3.2 尽量囊括所有扩展场景
产品好，过程极其简单，不易异常;为什么不容易说，因为即使是上帝也没有得到充分的考虑，所以设计应该包括所有的场景。
（1）网络断线，服务挂起等外部条件引起的异常应提供适当的及时信息;
（2）在正常过程之外还有另一种分支过程，这是我们注意和控制所特别需要的。
重复提交：提交按钮无法控制可用状态&&页面流量很慢，会有多次重复提交，一般是前端+后台，双重控制，以防止重新提交提交;
该过程异常，无法继续。考虑扩展方案以避免操作异常。即使它不正常，您也应该提供相关提示以指导用户继续。
3.3 模块关联性，版本规划
模块和要求可能彼此相关。之前和之后应该有这样的关系。在这种情况下，您应该考虑规划前置位置的模块或功能，然后是后置位置;版本规划基于系统核心模块。按照相关性模块中预模块的规则规划版本，其优先级高于后置模块;
3.4 其他
（1）唯一性检查，当实体具有独特的要求时，如用户的手机号码，身份证号码等，当添加或修改实体时，验证是否已经存在并保证唯一性;
（2）关联关系，删除父节点时，子节点也将被删除或软删除;
（3）在对实体进行更改时，首先应该查看用户角色中的问题;如果优惠券已经发出，您应该将其设置为不再可更改，因为在更改后，用户将看到更改的优惠券;
