程序员技术精进：业务分析与设计，黄金圈法则与UML建模工具

业务分析与设计

业务分析指应用特定的方式或方法，把复杂的需求拆解成简单且容易理解的对象，并找出这些对象之间的关系。业务分析也是系统开发中最重要、最困难的阶段，只有依据业务分析的结果，运用合理的思想和方法，才能设计出理想的系统架构。如图3.1所示，业务分析与设计是程序员进阶时要具备的最重要的能力，是从产品需求到编码实现的重要手段。

图3.1

黄金圈法则

每个人都知道自己要做什么，一部分人知道自己要怎么做，但只有极少一部分人知道自己为什么要这么做，这就是很著名的黄金圈法则，也叫作2W1H分析法。黄金圈法则源于知名广告人Simon Sinek的发现，是由为什么（Why）、怎么做（How）、做什么（What）三部分组成的由内到外的思维方式，如图3.2所示。

图3.2

黄金圈法则的三个层次与人脑的三个皮层精确对应，如图3.3所示。人脑最外层为新皮质，负责理性思维分析和语言；中间层和最里层为边脑，负责情绪和行动，以及行为和决策。从外到内沟通时，通过说明“做什么”能够帮助我们理解大量的复杂信息，利用的是理性思维，它擅长分析，但不会促使人采取行动。但从内到外沟通时，是直接对应控制决策过程的。

图3.3

如果将黄金圈法则对应于工作的话，则大部分人都知道做什么，能使用技术将工作做好，通常处于执行层；有些人知道怎么做，具备组织、管理和协调能力，通常处于管理层；只有极少一部分人知道为什么做，能够制定战略、目标和计划，具有宏观把控能力，通常处于决策层。企业中的执行层、管理层和决策层就形成了人才金字塔，如图3.4所示。

图3.4

所以，我们通过黄金圈法则能够解释为什么一些组织者或领导者能够在别人觉得不可能的地方激发出灵感和潜力，表现出卓越的天赋。那么，程序员如何从被动接收任务的执行层，进阶为具备系统分析和架构设计能力的决策层呢？有什么方法或捷径吗？答案之一是对UML建模工具的熟练运用，因为程序员除了需要具备写代码的能力，还需要具备凌驾于编程语言之上的能力，即系统分析与设计的能力，UML就是用于系统分析与设计的一种工具。

UML建模工具

UML 是一种统一建模语言，是面向对象系统开发过程中非常重要的一部分，主要使用图形符号来表示软件系统的设计，可以帮助项目团队进行内部沟通，找出潜在的需求点并进行设计和验证。

如图3.5所示，UML图可分为用例视图、设计视图、进程视图、实现视图和拓扑视图。用例视图主要有用例图；设计视图主要有类图和对象图；进程视图主要有状态图、活动图、序列图和协作图；实现视图主要有构件图；拓扑视图主要有部署图。

图3.5

用例图

用例图（UseCase Diagram）是业务分析的产物，描述了系统的参与者与系统的交互功能，是参与者所能观察和使用到的系统功能的模型图，主要用于帮助开发团队以一种可视化的方式理解系统的功能需求，包括基于基本流程的角色关系及系统各个功能之间的关系。它通过用例来捕获系统的需求，再结合参与者（Actor）进行系统功能需求的分析与设计。用例图的关系有包含（Include）、扩展（Extend）和泛化（Generalization），如图3.6所示。

图3.6

◎ 包含：该用例包含其他用例的行为，并将所包含的用例的行为作为自身行为的一部分。

◎ 扩展：将某用例的行为纳入已有的用例中，所获得的新用例被称为扩展用例，已有的用例被称为基础用例。

◎ 泛化：子用例将继承父用例的所有结构、行为和关系，而父用例和子用例之间的关系就是泛化关系。

类图

类图（Class Diagram）指用户根据用例图把场景抽象成类，描述类的内部结构，以及类与类之间的关系，是一种静态结构图，如图3.7所示。

图3.7

在 UML类图中，常见的关系有泛化、实现、关联、聚合、组合和依赖，泛化关系由强到弱依次为泛化、实现、组合、聚合、关联和依赖。

◎ 泛化关系：表示类之间是继承关系，为一般与特殊的关系。

◎ 实现关系：表示类与接口的关系，类是接口所有特征和行为的实现。

◎ 关联关系：表示类之间是拥有的关系，它使一个类知道另一个类的属性和方法。

◎ 组合关系：表示类之间是整体与部分的关系。组合关系是关联关系的一种，是比聚合关系还要强的关系，它要求普通的聚合关系中代表整体的对象负责代表部分的对象的生命周期。

◎ 聚合关系：表示类之间是整体与部分的关系，并且部分可以离开整体而独立存在。聚合关系是关联关系的一种，关联关系很强。

◎ 依赖关系：表示类之间是使用的关系，即一个类的实现需要另一个类的协助，所以尽量不要有相互依赖关系。

对象图

对象图（Object Diagram）描述的是一组对象之间的关系，而不是类之间的关系。它是类图的变体，但又与之不同，显示类的多个对象而不是实际的类，如图3.8所示。

图3.8

状态图

状态图（Statechart Diagram）用来描述一个特定对象所有可能的状态，以及由各种事件引起的状态之间的转移和变化，如图3.9所示。

图3.9

活动图

活动图（Activity Diagram）是状态图的一种特殊图，其中的状态大多处于活动状态。活动图在本质上是一种流程图，与交互图强调从对象到对象的控制流不同，它强调从活动到活动的控制流，如图3.10所示。

图3.10

活动图用于表述过程机理、业务过程及工作流程，用来对业务过程、工作流建模，也可以对用例甚至程序实现建模。

序列图

序列图（Sequence Diagram）是交互图的一种，描述了对象之间消息发送的先后顺序，强调时间顺序，主要用于将用例表达的需求做更进一步的精确表达。用例常常被细化为一个或者更多的序列图，序列图能更有效地描述各个类的职责及具备相应职责的原因，如图 3.11所示。

图3.11

协作图

协作图（Collaboration Diagram）是交互图的一种，描述了收发消息的对象的组织关系，强调对象之间的合作关系。时序图按照时间顺序布图，协写作图按照空间结构布图，如图3.12所示。

图3.12

构件图

构件图（Component Diagram）是用来表示系统中构件与构件之间及类或接口与构件之间关系的图。其中，构件图之间的关系表现为依赖关系，定义的类或接口与类之间的关系表现为依赖关系或实现关系，如图3.13所示。

图3.13

部署图

部署图（Deployment Diagram）用于可视化部署软件的物理组件拓扑，并描述系统的静态部署视图。部署图由节点及其关系组成，强调物理设备及其之间的连接关系，如图3.14所示。

图3.14

在敏捷开发中，每一次迭代都可以被看作一个小型的瀑布模式，通常可以分为6个阶段：需求、分析、设计、开发、测试、交付，具体流程如图3.15所示。

图3.15

UML在其中的各个阶段都有不同的应用，如下所述。

（1）需求阶段：采用用例图描述需求。

（2）分析阶段：采用类图描述静态结构，采用顺序图、协作图、活动图和状态图描述动态行为。

（3）设计阶段：采用类图对类的接口进行设计。

（4）开发阶段：采用某种面向对象语言实现。

（5）测试阶段：单元测试采用类图和类的规格说明书；集成测试采用类图、协作图；系统测试采用用例图。

（6）交付阶段：采用构件图和部署图。