|
以下为上篇总结，补充在此; 角色矩阵、系统主流程以及状态图，三者之间相互补充与制衡，最终达到完美的统一; 状态图梳理后调整补充系统主流程，系统主流程调整后调整补充角色矩阵; 同样，角色矩阵也限制、指导着系统的主要功能，防止在梳理需求时被无限放大; 相关阅读： 建模知识在需求分析、梳理中的应用(中) 数据库建模知识：在需求获取与分析中的应用(上) 一、原型线框图 在角色矩阵、系统主流程和状态图达到统一后，接下来就来到原型设计的阶段，此阶段的主要目的是把每个实体的属性以及实体之间的联系，以我们日常可见、理解的方式呈现; 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 遵循“高内聚，低耦合”的设计原则 这应该是我从大学，老师就一直强调的，就像一项指明灯指引我们前进;你会发现，所有不好用的设计逻辑，都会忽略这个原则。 官方解释： 高内聚：又称块内联系。指模块的功能强度的度量，即一个模块内部各个元素彼此结合的紧密程度的度量。若一个模块内各元素(语名之间、程序段之间)联系的越紧密，则它的内聚性就越高。 低耦合：一个完整的系统，模块与模块之间，尽可能的使其独立存在。也就是说，让每个模块，尽可能的独立完成某个特定的子功能。模块与模块之间的接口，尽量的少而简单。 官方给出的解释中，主要是针对模块之间，实际上，这个结论对大至平台，小至实体都是适应; (责任编辑：admin) |
