第5篇　设计工程——应用设计

第15章　应用设计概述

        业务设计是在不考虑软件实现方式的前提下进行的，因此如何实现业务设计的价值和如何体现信息化带来的业务价值提升就是应用设计的核心，而应用设计的成果可以展示客户信息化体验的效果。理解和掌握应用设计能力需要有业务知识和一定的技术基础知识，对于业务设计师来说可能有些难度，但这部分内容对后续实现设计师的理念、构想和价值是非常重要的。设计师如果不能理解这部分的内容，就很难在系统的设计阶段设想到未来系统完成后的效果。

15.1　基本概念

15.1.1　定义与作用

        1．定义

        应用设计，是将业务设计成果结合技术实现的要求，给出系统开发完成后的应用样式和应用模式。

        在业务设计阶段，是站在客户的业务视角来看待设计对象的，此时尚未考虑如何实现系统。进入了应用设计阶段后，就把业务设计的要素看成是系统“构件（或是零件）”，此时的关注点已不在业务方面，而是放在构建“人-机-人”的信息化工作环境方面，重点是实现企业管理的信息化、智能化的设计。

        2．作用

        应用设计的作用非常重要，前面对业务设计得再完美、价值再大，如果要想让用户体验到业务设计的完美和价值，就必须通过“对系统的操作”来感受，因此应用设计的作用就是结合IT技术，用信息化的设计方法让用户感受到信息化环境所带来的工作变化和价值。

15.1.2　内容与能力

        1．作业内容

        应用设计的主要工作是对业务设计工作分解的三层成果（架构、功能、数据）进行应用转换，以及增加相应的非业务处理用功能（系统功能）的应用设计

        1）工作分解——架构层面

        （1）系统功能：以业务功能的框架图为基础，增加系统功能、数据库等规划内容。

        （2）业务转换：设计业务流程在系统中的机制，如实现“事找人”的流程推送机制。        

        2）工作分解——功能层面

        （1）业务转换：将业务功能转换为业务组件，将业务原型转换为应用原型（加入按钮控件）。

        （2）系统功能：增加按钮控件（新增、保存等），权限、时限等。

        3）工作分解——数据层面

        （1）业务转换：将文字型数据转换为数字型数据等。

        （2）系统功能：建立数据的复用、共享机制。

        2．能力要求

        这个部分是处于业务设计和技术设计的转换之处，应用设计需要非常多的知识和技能（包含业务、技术、UI、美工等知识），这个角色对产品最终的应用价值起着非常大的作用。这个角色的人才比较缺乏，也比较难培养，因此为了强调其重要性以及与其他传统角色的不同，应用设计师，可以由技术设计师或是业务设计师兼任。

15.1.3　思路与理解

        1．从业务设计到应用设计的转换

        应用设计是对业务设计成果的不同维度的深化设计。

        （1）业务设计：对客户业务的梳理、优化，最终获得了业务逻辑、业务功能和业务数据。

        （2）应用设计：构建由机制、组件等构成的信息化环境，让用户体验到信息化管理的价值。

        进入了应用设计后，设计师看待设计对象的视角就要从“业务思维”转向“系统思维”，要将业务设计中的“业务功能”转换为应用设计的“业务组件”，功能间的关联关系“业务逻辑”转换为应用设计中的“系统机制”，用“组件+机制”的概念替代“功能+逻辑”的概念。只有建立了这样的概念，才能理解业务设计与应用设计的区别，及应用设计的价值所在。“组件+机制”的概念是软件工程化设计的一个重要步骤，这个设计的结果是对未来实现系统的灵活应变、支持功能碎片化的系统构建不可或缺的基础。应用设计的方法以构建用户的“信息化工作环境”为目标，应用设计方法中也融合业务设计与技术设计的知识。应用设计的作用不仅是业务和技术之间的桥梁，用户感受到的信息化体验的价值主要就是由应用设计的结果体现出来的，可以用一句话概括应用设计的方法，即应用设计是以“技术知识为基础的业务设计手法”。

        2．应用设计的目的和价值

        应用设计横跨在业务设计和技术设计之间，涉及业务、技术、UI等多方面的知识，在软件行业中对这个部分的定位和需要的知识等都不是很清晰，与建筑行业的建筑设计师（相当于软件的业务设计师）做个对比就容易理解了，建筑设计师要掌握的知识是复合型的，他不但要熟知自己的专业，还必须了解和掌握一定的其他专业的知识，如美术知识、结构知识、材料知识、设备知识、现代智能建筑知识等。可以说一个仅掌握某个很窄专业知识的设计师是很难设计出好产品的。由于应用设计整合了全部的设计要素，所以系统完成后用户感受到信息化价值的大小就主要取决于应用设计的效果。业务设计的成果在完成系统前用户就可以判断出设计的优劣，但是一般来说用户很难在系统完成前判断出系统的工作效率和使用价值，这也往往是造成系统完成后用户不认可、不满意的主要原因之一。如何能做到预先评估呢？这是应用设计存在的最大价值点，通过应用设计基本上可以做到在系统开发完成前就能够体验到完成后的效果，这个效果是单纯的业务设计和单纯的技术设计都无法独立做到的。

        3．应用设计不是UI或美工设计

        UI、美工是应用设计的一部分。

        （1）美工设计：研究外形的设计，包括界面的构图、颜色、各类控件的形状等。

        （2）UI设计：研究软件的人机交互、操作逻辑、界面美观的设计，范围大于美工设计。应用设计的作用是将这些内容，与业务设计成果以及未来的系统功能集成在一起。应用设计师尽管可以不做美工、UI的工作，但是作为一名合格的应用设计师至少需要具有对这些内容做出判断、建议的知识和能力。特别是针对企业管理类的信息系统来说，一个对业务和业务设计的内容没有十分理解的UI专职人员是很难做出对客户体验的贡献的，尽管企业管理类网站与电商类网站对UI的要求是有差异的。从前述内容可以看出，“应用设计”不是技术设计，更不等于UI、美工设计，而是它们的集大成，是以用户的使用效果和使用价值为设计目的的。应用设计的目的就是要从用户应用的视角出发，在软件开发完成前就可以预知完成后的价值和效果（效果不仅是界面的颜色、布局）。本书的应用设计部分内容作为从事业务设计读者的参考资料。

        4．谁来学习和掌握应用设计

        从应用设计的作用来看，传统的需求工程师、架构师或者开发工程师是难以满足这个要求的。做应用设计的设计师除需要熟练地掌握业务设计和应用设计的方法，最好能够有一定的技术背景（如计算机专业、有开发经历、有系统实施经验等）。应用设计的知识，不仅从事业务分析与设计的工程师应该掌握，作为技术设计和编码工程师也应该有所掌握。用建筑行业做个比喻，不论是建筑设计师（业务），还是结构工程师、设备工程师等（技术），他们都对未来要完成建筑的形体、使用是清楚的。同理，如果软件工程师们（业务、技术）能够对将要开发的软件在应用设计层面上有共同的理解，那么这个软件开发的成功率在设计阶段就会获得充分的保障。总的来说，如果掌握了应用设计部分的知识，软件工程师们在开发完成前就可以判断出系统的形式、使用效果了。

        分享应用设计师，飞机的试飞员

15.2　基干原理

        在业务设计阶段完成了业务设计，业务设计阶段各要素之间的关系是基于业务逻辑建立的。在应用设计阶段，业务功能转换成为了业务组件（系统形式）。那么，业务逻辑在系统中的表达方式是什么呢？如何转换呢？基干原理给出了解答。组合原理给出了业务要素的架构方法；基干原理给出了系统要素之间的架构方法。

15.2.1　基干原理的概念

        1．基干原理的定义

        1）构成要素       

         进入应用设计阶段，设计对象就从业务转向了系统。构成系统架构的要素与业务架构中的要素不同，系统架构中的流程与业务架构中的流程运行机理也不同，因此在业务设计阶段的“组合原理”就被应用设计阶段的“基干原理”所替代。基干原理是组合原理的不同表达方式

        （1）组合原理：三元素=要素、逻辑、模型，表达的是业务的要素、逻辑和事理。

        （2）基干原理：三元素=组件、机制、系统，表达的是系统的要素、逻辑和机理。

        基干原理给出了系统设计时的组合理念、方法、标准。

        2）原理作用

        基干原理从软件实现的视角说明了，不论是什么业务内容，不论是什么样的业务处理方式，系统的构成和运行原理都是一样的，基于原理模型说明了运行模式。

        所有的业务处理过程都是由基干原理三元素，按照基干模型给出的规律进行反复的循环。这样就找到了在系统中业务的运行机理。业务架构的形态可以有无数种，但是在系统中对应的形态只有一种。基干原理是在应用阶段对设计对象进行的又一次不同维度的抽提。

        2．组件+机制

        前述内容说明了组件与机制的作用和关系，“组件”完成了业务数据的处理，“机制”是用来保证业务处理的。为了完成一个业务的处理需要很多的机制来做支持和保障工作，机制分别对组件和流程提供支持。

        有了“组件”和“机制”的概念后，就知道了在系统中这些常见的要素各自起着什么作用、谁是主要要素、谁是辅助要素，在做设计时就有了主次之分。组件和机制都是系统提供的功能，只是组件是用来直接处理业务数据的，机制是用来做关联、约束、流转用的，“组件+机制”的概念是建立软件工业化生产体系的基础。这个原理称为“基干原理”，这是应用设计的主要指导思想，也是实现软件工业化生产目标的重要路径之一。基干原理，也可以看成是组合原理在应用设计阶段的延伸，是应用设计版的“组合原理”，但是需要注意，这两者之间在理论、方法方面有着极大的不同，理解业务逻辑需要有一定的专业知识和相关经验；理解机制需要有一定的技术设计知识和相关经验。

        注：“基干”的含义“基干”取“基础”与“骨干”之意，是设计可随需应变系统的概念原理。

15.2.2　机制的概念

        1．机制的概念与作用

        1）概念

        “机制”用通俗的话说就是“相互作用关系”，如前所述，业务逻辑是从实际业务活动中抽提出来的事理和规律。进入了应用设计阶段，还要对其再进一步抽提。按照“知识→逻辑→机制”的过程，距离技术设计越近，业务知识的内容就越少。最终是“逻辑”替代了“知识”，而“机制”又替代了“逻辑”。可以把“机制”理解为“系统的逻辑表达方式”，但不同的是，业务逻辑是静态地表达要素之间的关联关系，机制不但要包含逻辑的关联关系，而且机制是系统反复运行的驱动力。应用设计中的“机制”，可以有很多种形式，例如架构设计中实现流程自动化推送的“流程机制”，功能设计中对组件进行管控的“管控机制”，等等。所有要素之间的关联关系在系统中都可以称为“系统机制”。系统机制包含了架构、功能数据、管理各层的机制。

        2）系统机制的作用

        为什么要引入机制的概念呢？主要还是源于软件工业化生产的概念。

        为了满足软件的工业化生产，第一步先完成软件设计的工程化，下一步还要研究如何实现系统的构件化，也就是用代码将软件的各个部分预先开发成如同建筑构件、机器零件一样，再用连接的物件将分散的小部件组合成一个大的系统，“机制”就起了这个连接的作用，而构件就是构成系统的模块、组件、控件等要素。

        2．从逻辑到机制

        机制，是对业务逻辑的进一步抽提，机制实际上不等于逻辑，机制本质上是将业务逻辑中呈现出具有“规律性行为”的部分抽提出来，并用系统的实现方式固定下来的功能，“对应业务逻辑中规律性行为的系统固化功能”就是系统的机制。

        从需求分析到业务设计阶段，通过业务架构的设计，完成了将需求调研中的专业知识和经验向业务逻辑的转换，下一步，从业务设计到应用设计阶段，需要将业务设计中的业务逻辑向系统机制进行转换。

        系统不但可以应变，而且可以复用。这就是用“逻辑”表达流程和用“机制”表达流程的不同之处，也可以看出“业务架构图”与“系统架构图”的不同。

15.2.3　系统的构成

        前面多次提到了“系统”，在业务设计阶段提到的系统是由“功能+逻辑”组成的，在应用设计阶段讨论的系统是由“组件+机制”构成的。系统划分的粒度基本上是与业务设计阶段的划分粒度一致的。有了机制的概念后，不同目的的组件与机制在一起可以构成不同目的的系统，例如，处理业务用的“组件+机制”形成了处理业务的系统；处理管控用的“模型+机制”形成了管控的系统。

        1．业务组件与机制的组合

        信息系统是由多个子系统构成的，每个子系统的组合都是同样的原理，按照业务设计的成果构建系统。

        ①给出了预定要设计开发的各个子系统名称。

        ②设计系统的应用架构图。

        ③向应用架构图中加入组件（使用组件库已有的或是按业务功能资料新设计）。

        ④按照业务逻辑、规则等业务设计要求，在组件上、组件间配置相应的机制。

        ⑤参考相关的专业知识，保证组合后的系统符合业务和管理的要求。对这个设计过程进行反复的循环，就可以完成①中所有子系统的设计。

        2．管控模型与机制的组合

        管控模型，实际上可以被看成一个可以灵活配置的机制集合体。根据需要可以对模型的规则、参数、功能等进行调整（不依赖代码），不论处理什么样的业务，只要将需要的业务组件和这样的管控机制相关联，就可以实现基干原理提倡的工业化的软件生产方式。

        “系统”指的是未来要完成的软件，系统设计包括了目标、理念、价值、业务、应用、技术等内容，以及各项设计内容的不同层面（架构、功能、数据、管理等）。

15.3　工作分解

15.3.1　工作分解1——架构层

        架构的应用设计，主要是针对业务框架图和业务流程图的转换设计

        1．业务框架图业务设计中要完成的业务功能规划，包括业务的系统、子系统和模块，在应用设计阶段，加入辅助的系统功能，完整地构成一个系统。

        2．业务流程图业务设计中已完成了未来业务流程上的节点、分歧判断等设计，应用设计的重点是分析和设计该业务流程的运行机制，这个机制可以让业务流程运行起来，见（a）是业务流程的设计；（b）表达的是业务流程在系统中的运行机制。

        业务设计与应用设计的表达形式是完全不同的。

15.3.2　工作分解2——功能层

        功能的应用设计，是在业务设计中完成的业务功能详细设计基础上，将业务功能转换为业务组件，并加入按钮控件，最终将业务原型转换为一个应用原型，这个应用原型是后续技术设计和开发的依据。

        对功能设计的主要内容包括以下两大类。

        （1）控件：字段控件（在业务设计中完成）、按钮控件、其他控件（接口、列表、滚动条、导航栏等）。

        （2）系统功能：登录、注册、权限、时限、流程等。

15.3.3　工作分解3——数据层

        数据的应用设计，是对企业积累的大量数据进行价值的再发掘，重点通过介绍以下三个方面的内容理解数据应用设计的作用和价值。

        （1）数据的共享：对已产生的数据提供给其他的部门或系统共同使用。

        （2）数据的复用：历史数据经过了标准化加工后，作为下一次生产循环的参考信息。

        （3）数据的增值：将文字类数据转换为数字类数据，为客户带来更大的信息化价值。

小结

        应用设计，重点是构建出“人-机-人”的工作环境，这个设计的成果决定了客户对信息化的直接感受和满意度。应用设计是软件工程中最能够体现出设计师创造能力的部分，因为这个部分的设计需要具有全面的知识和能力，包括：专业知识、设计知识和IT知识，以及将这些知识和客户项目结合起来的综合能力。仅仅是业务设计能力强或是有过技术开发的经验都不足以胜任应用设计的工作，它要求设计师首先能够理解什么是“人-机-人”的信息化环境，在这个环境中如何利用好计算机提供的手段，让用户体验到在“人-人”环境中完全无法体验的工作效率和便利。所谓的用信息化手段改变业务模式、管理模式甚至是商业模式，主要依靠的就是应用设计。应用设计既不是业务设计，也不是技术设计，更不是UI或美工设计。业务设计完成的是业务价值方面的设计，技术设计完成的是如何实现软件设计，应用设计是将前述所有的设计成果（业务、技术、UI、美工等），用应用设计的方法整合在一起的设计，发挥出“1+1＞2”的效果，可以说，应用设计是获得管理信息系统最高价值的重要保证。

        应用设计，决定体验价值

        如何将相同的业务功能和技术，用不同的信息化手段体现出来，让用户在这个“人-机-人”的信息化环境中充分地体验到信息化带来的价值（效率、效益），这个不同之处极大地影响着用户对系统的满意度，因此也就最有可能成为客户选择的决定因素。通常所说的“用信息化手段为企业赋能”，这个赋能指的就是“信息化的能力”，而这个赋能的工作主要就是在应用设计阶段完成的。