社保网站做员工用工备案吗,微信公众号如何做微网站,电商平台如何推广运营,做网站图片需要什么格式交流伺服系统设计指南软件设计至关重要。 它是应用程序的基础。 就像蓝图一样#xff0c;它为所有背景的聚会提供了一个通用平台。 它有助于理解#xff0c;协作和发展。 设计不应仅视为开发的要素。 它不应该仅仅存在于开发人员的脑海中#xff0c;否则团队将发现它几乎无… 交流伺服系统设计指南 软件设计至关重要。 它是应用程序的基础。 就像蓝图一样它为所有背景的聚会提供了一个通用平台。 它有助于理解协作和发展。 设计不应仅视为开发的要素。 它不应该仅仅存在于开发人员的脑海中否则团队将发现它几乎无法增长因为知识很难获得。 而且当员工离职时公司会损失更多的价值。 应用程序代码应通过将领域模型有效地转换为清晰的抽象来描述设计。 这些应该经过良好的编码良好的命名和良好的定义。 但这还不够。 设计不仅应存在于代码中。 尽管使用该层来表达设计对于开发团队来说可能已经足够但是拒绝了其他对应用程序设计感兴趣的人。 他们要么无法物理检索代码要么没有软件开发背景要么就没有时间自己弄清楚设计。 有时在编写大量代码之前需要在多团队组织中讨论和完善高级设计。 在这种情况下很明显即使代码表达了设计也不应仅将其包含在代码中。 为此设计建模已成为一个单独的过程。 表达系统设计 设计不仅涉及类以及它们之间的关系。 这也与合作和行为有关。 关于用例状态和活动。 交流设计的主要形式如下。 由于UML的普及性 UML被用作参考但是没有人会受其符号或术语的约束因为重点应该放在有效的沟通上。 结构体 概述图 使用一组描述部署策略程序包模块和组件的图来描述系统结构概述。 最高级别的概述之一是部署按照应用程序使用的基础结构实体进行描述。 UML描述了实现该目的的部署图 该部署图由节点组成例如Web服务器应用程序服务器数据库服务器和客户端。 系统中部署的组件具有外部依赖性。 这些应记录在案。 UML为此目的规定了程序包图 它描述了程序包合并和导入关系。 详细图表 在较低的层次上通过展示类及其之间的关系来描述系统的结构。 类图 类图描述了系统的类包括它们的属性操作或方法以及它们之间的关系。 关系可以具有多种类型例如依赖性关联性组成继承。 应该清楚地表达它们以便开发人员团队可以手动设计系统也可以使用根据类图生成类的工具来设计系统。 在UML中 类成员可以具有以下类型的可见性 公开 私人的 – 受保护的 派生 /该属性是根据另一个元素的属性计算得出的 包装方式 〜 在UML中 定义了以下关系 关联 表示一系列链接可以是单向或双向的 关联可以被命名 继承/泛化 一类是另一类的专门形式 实现/实现 一个类实现一个接口 依赖性 两个元素之间的单向关系当对一个元素的更改导致需要更改另一个元素时发生 集合 “具有”关联只能是双向的 在聚合关系中聚合组件可以存在于容器外部 组成 更强大的聚集关系其中聚集的组件不能“存在”于容器外部例如汽车的引擎 类结构图 这种类型的图显示了类的内部结构。 它们可以包括其协作者如何与之交互以及如何与之交互。 在UML中 复合结构图包括内部零件端口和连接器。 端口促进了班级内部以及与外界的交流。 连接器位于零件和端口之间。 斐波那契系统的复合结构图如下所示 互动互动 一个系统内发生的交互与其结构一样重要甚至更多。 实际上行为是用户所体验的因此对其进行精确描述和早期建模可以使参与该项目的每个人都省去很多麻烦。 用例 用户与系统进行交互以满足目标。 实现目标所需的一组交互作用形成一个用例 。 与一组用户故事相反表示这些交互对于以紧凑形式可视化需求非常重要。 UML定义了用例图 其中涉及不同的参与者和系统。 互动概述 在更高的层次上可以用模块之间的交互来描述系统通常是为了建模控制流。 就此而言 UML定义了交互概述图和活动图 。 交互概述图可以描述由多个交互组成的控制流而活动图的详细程度较低描述了实际条件逻辑和动作。 详细互动 消息序列图捕获了协作类之间的操作顺序。 在UML中 它们称为序列图。 这些类型的图不仅描述了类如何交互而且还包括时间元素建立了交互的顺序或顺序 水平箭头显示两个协作者之间交换的消息。 垂直线也称为生命线捕获了两个类之间可能发生的所有通信。 州 在具有复杂约束和条件的环境中系统状态可能难以可视化。 最直观地讲该系统可以表示为状态机其节点数量与状态一样多并且条件会在附加到标记过渡的箭头的状态之间进行切换。 为了提高可读性应抽象出复杂的条件并以简洁的方式表达。 在UML中 状态图使用标准化表示法表示状态。 实心圆表示初始状态。 空心圆代表最终状态。 圆角矩形表示给定的命名状态。 箭头表示与事件相关的过渡。 还提供了事件名称 建模技术 可以使用文本和图形两种基本方法来描述设计。 通常人们倾向于对图像更感兴趣但文本模型倾向于更具描述性。 存在混合功能可以同时进行高级概述和可视化详细信息的功能。 执行文本建模以形式化语言表达需求。 这些模型倾向于以牺牲总体概观为代价提供更多细节。 在某些方面创建速度被认为比图形方法要高因为在图形方法中设计人员需要在鼠标和键盘之间进行切换。 格式化趋向于更快更高质量。 同样鉴于基于文本的格式版本控制的使用变得更加自然。 但是对于文本建模理解模块往往是一项更具挑战性的任务。 更现代的工具提供了显示基于树的结构或状态机的方法来克服此问题但这并不总是足够的。 无法解决的一个特定问题仍然是动画和仿真如果需要应将其视为转向图形方法的基础。 使用图形建模用户无需使用建模工具即可学习任何东西。 设计往往不太像编程因为用户可以将更多的内容与他们要建模的概念联系起来。 学习系统时从高级到低级再回到高级很容易。 结论 交流设计与设计同等重要。 必须避免将设计锁定在开发人员的思想和/或代码中。 相反应该有效地进行沟通以便项目中的每个人都可以访问它。 翻译自: https://www.javacodegeeks.com/2016/08/communicating-design.html交流伺服系统设计指南
