建模知识在实际设计中的应用下

　　本篇主要唠唠建模知识在日常工作、实际设计中的应用。
　　以下为上篇总结，补充在此；
　　角色矩阵、系统主流程以及状态图，三者之间相互补充与制衡，最终达到完美的统一；
　　状态图梳理后调整补充系统主流程，系统主流程调整后调整补充角色矩阵；
　　同样，角色矩阵也限制、指导着系统的主要功能，防止在梳理需求时被无限放大；
　　相关阅读：
　　建模知识在需求分析、梳理中的应用（中）
　　数据库建模知识：在需求获取与分析中的应用（上）
　　一、原型线框图
　　在角色矩阵、系统主流程和状态图达到统一后，接下来就来到原型设计的阶段，此阶段的主要目的是把每个实体的属性以及实体之间的联系，以我们日常可见、理解的方式呈现；
　　1。1模块划分
　　基础模块的划分遵循实体的界限，一般来说，一个实体就是一个基础模块，通常模块首页以列表形式展示；如普通的电商后台系统，即用户、商品、订单这些基础模块，这些其实也是实体；
　　统计，关联类，根据实际需求定义模块，通常以图表、列表形式展示；
　　1。2站点地图
　　系统涉及到的页面以及页面之间的流转以地图索引的方式展示；一般以模块划分，如系统功能较简单，可以系统为单位。
　　1。3页面信息架构
　　即页面呈现的信息，从建模角度来看，其实就是实体属性以及实体之间联系的展示；
　　实体属性，即实体的基本属性，比如员工有员工号、姓名、身份证号、职位、性别、邮箱等基本属性；实体之间的联系，即该实体与其他实体之前的联系，如我们在上篇中写到的部门人员的关系；
　　1：1，当实体之间为1：1的联系时，当前实体的页面展示可以将对面实体以其属性的形式展示；如某公司业务支撑部，经理张三，在员工基本信息页，职位：部门经理，部门：业务支撑部；在部门基本信息查看时，部门：业务支撑部，部门经理：张三；
　　1：N，当实体之间为1：N的联系时，为1的实体页面信息展示时，可以将对面的N以下级页面或列表的形式展示；为N的实体页面信息展示时，可以将对面的1以其属性的形式展示；如业务支撑部下属员工有2个，分别是小丽、小黄，查看业务部信息时，可以设置下属员工链接到下级页面，也可以以列表的形式展示这2个员工信息。同理，在员工基本信息页面时，可以将该员工的所在所属部门以其基本属性展示；
　　N：N，当实体之间为N：N的联系时，对面实体以下级页面或列表的形式展示；如学生课程，在学生模块，可以将所选课程以下级页面的形式展示，也可以以列表的形式展示；同理在课程模块，该课程被哪些学生选修，可以以下级页面展示，也可以以列表的形式展示；
　　二、设计原则
　　2。1始终把用户需求放在第一位
　　用户：即该系统的最终用户，可遵循我们在上两篇中讲到的角色实体；
　　需求：即功能，用户通过系统想要达到的目的；
　　用户需求：即考虑该功能的实际应用场景，根据实际场景把控设计的方向；
　　实际场景应考虑的因素如下，持续补充：
　　用户年龄大小，这直接影响到视觉上的配色、字体、字号等；
　　用户整体素质水平，在流程跳转、提示等节点尽量简洁易懂；
　　用户所处环境，用户是处在比较庄严的机关单位还是新潮的互联网行业，都有一套行业规则；
　　功能使用周期、频率；这直接影响到表结构的设计，在大频率的功能上，访问速度是需要着重考虑的问题；
　　2。2遵循高内聚，低耦合的设计原则
　　这应该是我从大学，老师就一直强调的，就像一项指明灯指引我们前进；你会发现，所有不好用的设计逻辑，都会忽略这个原则。
　　官方解释：
　　高内聚：又称块内联系。指模块的功能强度的度量，即一个模块内部各个元素彼此结合的紧密程度的度量。若一个模块内各元素（语名之间、程序段之间）联系的越紧密，则它的内聚性就越高。
　　低耦合：一个完整的系统，模块与模块之间，尽可能的使其独立存在。也就是说，让每个模块，尽可能的独立完成某个特定的子功能。模块与模块之间的接口，尽量的少而简单。
　　官方给出的解释中，主要是针对模块之间，实际上，这个结论对大至平台，小至实体都是适应；
　　下面举个关于实体之间的栗子：我之前接过的一个项目，其中有一条这样的逻辑一个经销商下最多3个联系人；这时我们会疑问，为啥会有这种设定，这样的规则在后续会产生哪些问题呢：
　　当经销商下联系人超过3个时，系统是不支持的；
　　系统是由简到繁的过程，一开始设定这样的限制，如果后面想在撤销这种设定的话会涉及很多改动；
　　实体之间不够独立且依赖太多，所以这不遵循高内聚低耦合的原则；其实这就是简单的1：N的关系，只是在某些特定方式下，如导入经销商及其联系人的时候，这时我们可以设定这个联系人最多是3个，但是，在系统的使用中，这种关系反而是一种负担；
　　2。3遵循复用性原则，所有设计力求复用最优化
　　官方解释：
　　可复用性，复用又叫重用，是重复使用的意思。复用的好处可以得到较高的生产效率以及随之而来的成本降低、较高的软件质量（错误可以更快的被纠正）以及恰当的使用复用可以改善系统的可维护性。
　　模块之间的复用，即实体的复用，当实体之间是N：N的关系时，一定会存在这样的复用关系；如果不存在，那这个设计可能没有达到复用最优化的标准；
　　如我们常见的组件与商品的关系，是N：N，在商品新建时会以属性的方式增加组件；
　　这样做的好处是：
　　组件不需要重复新建，直接在商品新增时引用加入即可；
　　可对组件进行管理、控制；
　　如果我们换一种设计思维，如新建商品时，一个个编辑填写组件信息，这样做会带来
　　如不同商品的组件信息相同时，要重复录入；
　　组件是以属性的方式附属在商品上，达不到组件可控可管的需求；
　　阶梯性关联关系的设计，即多个实体之间有阶梯性关联关系，建议采用断层式数据结构设计，不建议跨级发生联系，即使需要跨级也要把中间那层关系加上；
　　为了便于理解，以下实例奉上。
　　背景：项目经销商是N：N的关系，经销商联系人是1：N的关系；
　　需求1：当项目新增成功后，会根据一定条件匹配经销商，确认此项目可能推送的经销商，或者叫预推送；此时的预推送表结构的设计应该是项目经销商，而不是项目联系人或项目经销商联系人；这样设计的好处有，
　　我们只固定了前半边的关系，后面的关系可以通过经销商来匹配带出，当经销商人员发生变更时也不会有任何影响；如果采用其他方式，在经销商人员变更时会多出很多复杂的数据操作，以保证此功能不受影响；
　　经销商联系人是1：N的关系，插入一条项目经销商关系就要插入多条项目联系人或项目经销商联系人的关系，从数据的冗余角度考虑，也是项目经销商的关系比较适合；
　　需求2：项目推送，项目预推送匹配成功后，可以对项目进行推送，这是真正的推送，有了这条推送，联系人才能在前端看到对应的项目；而此时的设计应该是如何呢
　　答案是，项目经销商联系人；为什么会加入经销商呢？前面的背景也说到，项目与联系人其实是没有这种关系的，他们产生关系的载体其实就是经销商；这样做的好处是
　　明确该联系人时通过什么载体（即经销商）来获得这从推送关系的，当联系人与载体的关系发生变更时，有个依据来对关联数据进行相关操作；如联系人从载体A变更到B，那此时，联系人当时通过A获得的项目推送关系就应该删除；
　　相反的，如果不加入经销商的载体，那联系人可见的项目是只增不减，因为我们没有这个载体的依据去操作数据；
　　注：一切实际需求为标准，仅供参考；
　　三、日常设计要点
　　3。1保持对需求的严谨态度
　　虽然需求多如牛毛，产品累成狗（微笑），但我们也要始终保持一颗严谨、谦逊的态度；做软件的都知道，即使是一个很小的需求，他的改动有时也不一定比一个大的需求少；所以，在需求被提出时，我们要保证我们已经了解到该需求的所有细节，以及涉及到的所有改动点；
　　3。2尽量囊括所有扩展场景
　　好的产品，流程极简且不容易发生异常；为什么说不容易呢，因为即使是神，也有考虑不周的地方，所以在设计时，应尽量囊括所有场景。
　　（1）外部条件导致的异常如断网、服务挂掉等，应给出合适的提示信息；
　　（2）另外还有一种，即在常规流程外的分支流程，这个是特别需要我们注意且控制的。
　　重复提交：提交按钮没有控制可用状态页面流程较慢的情况下会出现多次重复提交的现象，一般前端后台，双重控制，杜绝重读提交；
　　流程异常，无法继续走下去：充分考虑扩展场景，避免出现操作异常，即使异常，也应给出相关提示，指导用户继续走下去。
　　3。3模块关联性，版本规划
　　模块、需求，都有可能产生关联，有前后的这种关系，这种情况应该考虑先规划前置位的模块或功能，然后再是后置位；版本的规划，以系统核心模块为基础，遵从关联性模块中的前置模块，优先级高于后置模块的规则，来规划版本；
　　3。4其他
　　（1）唯一性校验，当实体有唯一性要求时，如用户的手机号码，身份证号等，在实体新增、修改时，校验是否已存在、保证唯一性；
　　（2）关联性关系，当删除父节点时，子节点也会对应删除或软删除；
　　（3）在对实体进行变更时，应首先以用户的角色看问题；如已经发出去的优惠券，此时应设置不可再进行变更，因为发生变更后，用户看到的将是更改后的优惠券；
　　相关阅读
　　数据库建模知识：在需求获取与分析中的应用（上）
　　建模知识在需求分析、梳理中的应用（中）