在为整个系统进行整体结构设计时,系统功能需求就是其要满足的外部表现,子系统、模块划分及其结构是其内部结构。
1.内部结构
如果忽视了内部结构的复杂性和坚固性,就容易产生 N 个功能→ N 个(子系统)模块的错误设计思路。
如果认识到内部结构还要考虑坚固性和美感,那么非功能需求、环境与约束都会成为(子系统)模块结构的塑造因素。例如:
● 为了安全性需求增加安全验证模块。
● 为了错误诊断增加日志模块等。
● 为了交互界面的灵活性分离界面和业务逻辑。
● 为了数据持久化的灵活性分类业务逻辑和数据持久化。
● 为了高性能封装实时算法。
● 为了可修改性,寻找功能实现的重复冗余和关联依赖重构(子系统)模块结构。
2.外部表现
如果忽视了外部表现的抽象和简洁性,就会将系统内部的功能分解提供给用户使用,用户在界面上看到系统的分解结构和方法接口,导致低易用性。
如果认识到外部表现需要简洁和抽象,就会根据用户任务需求进行功能整合,让界面上出现用户最想看到的任务。
例如,图1-20是一个压缩软件的界面,很明显它是根据其内部方法设计的——新建压缩、更新压缩、解压三个方法,于是在界面上设置了三个选项。对比一下市场的主流压缩软件,就可以发现它们在易用性上的鲜明区别。
图1-20 依据内部结构设计外部表现示例
又如,用户修改密码这一常见场景。在设计上,通常会存在一个用户类User,它有一个属性是密码password,相应的有一个方法setPassword()。如果按照这个内部结构设计交互,那么用户修改密码的界面操作过程是:找到“个人信息管理(维护User类)”→信息编辑或者信息修改→修改密码。如果按照用户的功能任务(外部表现)来设计交互,那么“修改密码”会比“个人信息管理”更常用,所以“修改密码”的界面位置应该超过“个人信息管理”,或至少是同级的位置。
再例如,学校新生报到时,要在多个部门登记个人信息,这些部门包括:校园出入管理、教务、图书馆、财务、宿舍管理等。在软件系统中,这些不同的部分是不同的用户,会被设计成不同的子系统和模块。如果按照软件的内部结构划分来设计交互,那么就需要学生分别在校园出入管理、教务、图书馆、财务、宿舍管理等多个子系统和模块上分别登记个人信息。可是如果按照功能业务逻辑(外部表现)来设计交互,那么就只需要一个功能“新生报到”,由系统自己在内部将“新生报到”的信息分发给各个子系统和模块。