软件设计至关重要。 它是应用程序的基础。 就像一个蓝图，它为来自不同背景的聚会提供了一个通用平台。 它有助于理解，协作和发展。

设计不应仅视为开发的要素。 它不应该只存在于开发人员的头脑中，否则团队将发现它几乎无法增长，因为知识很难获得。 而且，当员工离职时，公司会损失更多的价值。

应用程序代码应通过将领域模型有效地转换为清晰的抽象来描述设计。 这些应该经过良好的编码，良好的命名和良好的定义。 但这还不够。

设计不仅应存在于代码中。 尽管使用该层来表达设计对于开发团队来说可能已经足够，但其他可能对应用程序设计感兴趣的人却被拒绝访问。 他们要么无法物理检索代码，要么没有软件开发背景，要么就没有时间自己弄清楚设计。

有时，在编写大量代码之前，需要在多团队组织中讨论和完善高级设计。 在这种情况下，很明显，即使代码表达了设计，也不应仅将其包含在代码中。 为此，设计建模已成为一个单独的过程。

表达系统设计

设计不仅涉及类以及它们之间的相互关系。 这也与合作和行为有关。 关于用例，状态和活动。

交流设计的主要形式如下。 由于UML的普及性， UML被用作参考，但是没有人会受制于其符号或术语，因为重点应该放在有效的沟通上。

结构体

概述图

使用一组描述部署策略，程序包，模块和组件的图来描述系统结构概述。

最高级别的概述之一是部署，根据应用程序使用的基础结构实体进行描述。 UML描述了实现该目的的部署图 ，该部署图由节点组成，例如Web服务器，应用程序服务器，数据库服务器和客户端。

系统中部署的组件具有外部依赖性。 这些应记录在案。 UML为此目的规定了程序包图 ，它描述了程序包合并和导入关系。

详细图

在较低的层次上，通过展示类及其之间的关系来描述系统的结构。

类图

类图描述了系统的类，包括它们的属性，操作（或方法）以及它们之间的关系。

关系可以具有多种类型，例如，依赖关系，关联关系，组成，继承。 应该清楚地表达它们，以便开发人员团队可以手动设计系统，也可以使用根据类图生成类的工具来设计系统。

在UML中 ，类成员可以具有以下类型的可见性：

• 公开 ：+
• 私人的 ：–
• 受保护的 ：＃
• 派生 ：/，该属性是根据另一个元素的属性计算得出的
• 包装方式 ：〜

在UML中 ，定义了以下关系：

• 关联 ：表示一系列链接，可以是单向或双向的； 关联可以被命名；
• 继承/泛化 ：一类是另一类的专门形式
• 实现/实现 ：一个类实现一个接口
• 依赖性 ：两个元素之间的单向关系，当对一个元素的更改导致需要更改另一个元素时发生
• 集合 ：“具有”关联，只能是双向的； 在聚合关系中，聚合组件可以存在于容器外部
• 组成 ：更强大的聚合关系，其中聚合的组件不能“生活”在容器外部，例如汽车的引擎

类结构图

这种类型的图显示了类的内部结构。 它们可以包括其协作者如何与之交互以及如何与之交互。

在UML中 ， 复合结构图包括内部零件，端口和连接器。 端口促进了班级内部以及与外界的交流。 连接器位于零件和端口之间。

斐波那契系统的复合结构图如下所示：

互动互动

系统中发生的交互与其结构一样重要，甚至更多。 实际上，行为是用户体验的，因此对其进行精确描述和早期建模可以使参与该项目的每个人都省去很多麻烦。

用例

用户与系统进行交互以满足目标。 实现目标所需的一组交互作用形成一个用例 。

与一组用户故事相反，表示这些交互对于以紧凑的形式可视化需求非常重要。 UML定义了用例图 ，其中涉及不同的参与者和系统。

互动概述

在更高的层次上，可以用模块之间的交互来描述系统，通常是为了建模控制流。 就此而言， UML定义了交互概述图和活动图 。 交互概述图可以描述由多个交互组成的控制流，而活动图的详细程度较低，描述了实际条件，逻辑和动作。

详细互动

消息序列图捕获了协作类之间的操作顺序。 在UML中 ，它们称为序列图。 这些类型的图不仅描述了类如何交互，而且还包括时间元素，建立了交互的顺序或顺序：

水平箭头显示两个协作者之间交换的消息。 垂直线（也称为生命线）捕获了两个类之间可能发生的所有通信。

州

在具有复杂约束和条件的环境中，系统状态可能难以可视化。 最直观地，该系统可以表示为状态机，其节点数量与状态一样多，并且条件在状态之间切换，这些状态附加到标记过渡的箭头上。 为了提高可读性，应抽象出复杂的条件并以简洁的方式表达。

在UML中 ，状态图使用标准化表示法表示状态。 实心圆表示初始状态。 空心圆代表最终状态。 圆角矩形表示给定的命名状态。 箭头表示与事件关联的过渡。 还提供了事件名称：

建模技术

可以使用文本和图形两种基本方法来描述设计。 通常，人们倾向于对图像更感兴趣，但文本模型倾向于更具描述性。 存在混合功能，可以同时进行高级概述和可视化详细信息的功能。

执行文本建模，以形式化语言表达需求。 这些模型倾向于以牺牲整体概观为代价提供更多细节。 在某些方面，创建速度被认为比图形方法要高，因为在图形方法中，设计人员需要在鼠标和键盘之间进行切换。 格式化趋向于更快，更高质量。 同样，鉴于基于文本的格式，版本控制的使用变得更加自然。

但是，对于文本建模，理解模块往往是一项更具挑战性的任务。 更现代的工具提供了显示基于树的结构或状态机的方法来克服此问题，但这并不总是足够的。 无法解决的一个特定问题仍然是动画和模拟，如果需要，应将其视为转向图形方法的基础。

使用图形建模，用户无需使用建模工具即可学习任何东西。 设计往往不太像编程，因为用户可以将更多的内容与他们要建模的概念联系起来。 学习系统时，从高级到低级再回到高级很容易。

结论

交流设计与设计同等重要。 必须避免将设计锁定在开发人员的思想和/或代码中。 相反，应该有效地进行沟通，以便项目中的每个人都可以访问它。

翻译自: https://www.javacodegeeks.com/2016/08/communicating-design.html