软件建模设计(领域驱动设计)

作者:xinwang_m@163.com
发布时间: 2020-07-20 03:58:30 (4年前)
关键词: 软件建模
摘要:

                              
                                     软件设计是至关重要的。它是应用程序的基础，又很像一个蓝图，它提供了一个拥有不同背景的人进行理解、合作和发展的共同的平台。

软件设计是至关重要的。它是应用程序的基础，又很像一个蓝图，它提供了一个拥有不同背景的人进行理解、合作和发展的共同的平台。软件设计不应该被视为软件开发中的一个要素。它不应该只存在在开发者的头脑里，否则团队会发现这样做不利于设计的发展成长，因为设计知识存在个人头脑中，难以分享或者获得。此外，当该员工离开时，公司会失去很多价值。软件设计也不应该只存在代码中。虽然开发团队成员迟早都能看懂代码并了解设计，但是其他有兴趣于设计的人员可能无法获得，他们无法查阅代码，因为可能没有软件开发背景，或他们只是没有时间来弄清楚这个系统的设计。有时，高层次的设计需要以多团队组织形式进行讨论和完善，这一步骤应该在编写代码之前完成。这样，才能清晰地表达设计，也只有这样设计才不会只包含在代码中，即使代码能够完整表达设计。为了这个目的。设计建模目前已成为一个独立的过程。设计不仅仅是关于类以及它们如何相互关联。还有关类之间的合作和交互行为，有关用例，状态和活动等。类图 类图描述了系统的类，包括它们的属性、操作（或方法）以及它们之间的关系。类的关系可以是多种类型的，例如，依赖性、关联性、组合性、继承性。他们都应该清楚地被表达出来，这样一个团队的开发人员可以一起设计系统，无论手动或使用工具，根据类图类的代码。在UML中类成员有以下可见性类型：Public: + Private: – Protected: # Derived: /, 这个属性是从另外一个类成员计算得来 Package: ~ 类的关系有如下：![](/user/files/bjCBcel_47DF9f6OXw6PQ6DtxThhcIK5kEBR76j2kT8.png)Association关联: 代表类之间的联系，可以是单向或双向。根据高聚合低关联原则，普通关联尽量少用。 Inheriance 继承/ Generalization实现: 一个类是另外一个类的特定形式。 Realization / Implementation: 一个类实现一个接口 Dependency: 一个单向依赖关系，一个元素的改变导致其他元素改变，这种改变体现了依赖关系。关联是一种结构的静态关系，而依赖则是一种行为的动态关系。 Aggregations聚合: 聚合中的子部分或子元素可以脱离聚合这个容器存在。只能是双向关系。 Composition组合: 比聚合更强的关系，聚合中的子部分或子元素不可以脱离聚合这个容器独立存在。比如Car的引擎。用例 用户与系统交互以满足一个目标。实现一个目标所需的相互作用的集合是一个用例。表示这些相互作用是非常重要的，需要以一个紧凑的可视化形式，而不是以一组用户故事形式表达。UML定义了用例图，其中涉及不同的行动者和系统。序列图 类之间的业务合作使用消息序列图实现；在UML中，他们被称为序列图。这种类型的图表描述的不仅是类之间的相互作用，而且还包括一个时间元素，建立了相互作用的顺序或顺序：![](/user/files/VkxR0caNBPrH2-AUd7rn7MmeIpAEJPBndeI71XmkId4.png)水平箭头显示了两个合作者之间交换的消息。垂直线，也叫生命线，捕获所有在两个类之间发生的通信。状态图 在复杂的约束和条件的环境中，系统状态可能难以想象。最直观的是，该系统可以被表示为一个状态机，有尽可能多的节点，因为有状态和状态之间切换连接使用箭头标记。为了提高可读性，复杂的条件应抽象和简洁的表达。UML中通过状态图表示状态，使用一套标准化的符号：填充的圆表示初始状态；一个中空的圆圈代表最后的状态；一个圆角矩形表示一个指定的状态。箭头表示与事件关联的转换。还提供了事件名称：![](/user/files/L5JHTHTUCadDwKbhiMKfbB6PBs6An85–FBNW79pt9A.png)建模技术 设计可以描述使用两种基本方法：文本和图形。在一般情况下，人们往往对图像更有兴趣，但文本模型往往是更多具有描述性。这两种混合存在，能够从一个更高层次进行概述和描述细节。文本建模是需要使用一个正式的语言进行表达的。这些模型往往提供更多的细节，以牺牲整体概述换得的。文本创建速度要比图形方法要高，因为在图形化的方法中，设计者需要在鼠标和键盘之间切换。文本格式往往要快得多，质量更高。同时，版本控制的使用是非常自然的。使用文本建模，了解一个模块往往是一个更具挑战性的任务。更多现代的工具提供了方法来显示基于树的结构或状态机来克服这个问题，但这些并不总是足够的。对于一个特定的问题，不能解决的仍然是动态图示和模拟流程，如果需要的话，这些应该被视为移动到一个图形化方法的理由。使用图形建模，用户不需要学习任何东西，只需要使用建模工具。设计往往感觉不太像编程，因为用户可以涉及更多的涉及模型的概念。当学习一个系统时，它也更容易从高层次到低层次来回浏览理解。,软件设计是至关重要的。它是应用程序的基础，又很像一个蓝图，它提供了一个拥有不同背景的人进行理解、合作和发展的共同的平台。软件设计不应该被视为软件开发中的一个要素。它不应该只存在在开发者的头脑里，否则团队会发现这样做不利于设计的发展成长，因为设计知识存在个人头脑中，难以分享或者获得。此外，当该员工离开时，公司会失去很多价值。软件设计也不应该只存在代码中。虽然开发团队成员迟早都能看懂代码并了解设计，但是其他有兴趣于设计的人员可能无法获得，他们无法查阅代码，因为可能没有软件开发背景，或他们只是没有时间来弄清楚这个系统的设计。有时，高层次的设计需要以多团队组织形式进行讨论和完善，这一步骤应该在编写代码之前完成。这样，才能清晰地表达设计，也只有这样设计才不会只包含在代码中，即使代码能够完整表达设计。为了这个目的。设计建模目前已成为一个独立的过程。设计不仅仅是关于类以及它们如何相互关联。还有关类之间的合作和交互行为，有关用例，状态和活动等。类图 类图描述了系统的类，包括它们的属性、操作（或方法）以及它们之间的关系。类的关系可以是多种类型的，例如，依赖性、关联性、组合性、继承性。他们都应该清楚地被表达出来，这样一个团队的开发人员可以一起设计系统，无论手动或使用工具，根据类图类的代码。在UML中类成员有以下可见性类型：Public: + Private: – Protected: # Derived: /, 这个属性是从另外一个类成员计算得来 Package: ~ 类的关系有如下：![](/user/files/bjCBcel_47DF9f6OXw6PQ6DtxThhcIK5kEBR76j2kT8.png)Association关联: 代表类之间的联系，可以是单向或双向。根据高聚合低关联原则，普通关联尽量少用。 Inheriance 继承/ Generalization实现: 一个类是另外一个类的特定形式。 Realization / Implementation: 一个类实现一个接口 Dependency: 一个单向依赖关系，一个元素的改变导致其他元素改变，这种改变体现了依赖关系。关联是一种结构的静态关系，而依赖则是一种行为的动态关系。 Aggregations聚合: 聚合中的子部分或子元素可以脱离聚合这个容器存在。只能是双向关系。 Composition组合: 比聚合更强的关系，聚合中的子部分或子元素不可以脱离聚合这个容器独立存在。比如Car的引擎。用例 用户与系统交互以满足一个目标。实现一个目标所需的相互作用的集合是一个用例。表示这些相互作用是非常重要的，需要以一个紧凑的可视化形式，而不是以一组用户故事形式表达。UML定义了用例图，其中涉及不同的行动者和系统。序列图 类之间的业务合作使用消息序列图实现；在UML中，他们被称为序列图。这种类型的图表描述的不仅是类之间的相互作用，而且还包括一个时间元素，建立了相互作用的顺序或顺序：![](/user/files/VkxR0caNBPrH2-AUd7rn7MmeIpAEJPBndeI71XmkId4.png)水平箭头显示了两个合作者之间交换的消息。垂直线，也叫生命线，捕获所有在两个类之间发生的通信。状态图 在复杂的约束和条件的环境中，系统状态可能难以想象。最直观的是，该系统可以被表示为一个状态机，有尽可能多的节点，因为有状态和状态之间切换连接使用箭头标记。为了提高可读性，复杂的条件应抽象和简洁的表达。UML中通过状态图表示状态，使用一套标准化的符号：填充的圆表示初始状态；一个中空的圆圈代表最后的状态；一个圆角矩形表示一个指定的状态。箭头表示与事件关联的转换。还提供了事件名称：![](/user/files/L5JHTHTUCadDwKbhiMKfbB6PBs6An85–FBNW79pt9A.png)建模技术 设计可以描述使用两种基本方法：文本和图形。在一般情况下，人们往往对图像更有兴趣，但文本模型往往是更多具有描述性。这两种混合存在，能够从一个更高层次进行概述和描述细节。文本建模是需要使用一个正式的语言进行表达的。这些模型往往提供更多的细节，以牺牲整体概述换得的。文本创建速度要比图形方法要高，因为在图形化的方法中，设计者需要在鼠标和键盘之间切换。文本格式往往要快得多，质量更高。同时，版本控制的使用是非常自然的。使用文本建模，了解一个模块往往是一个更具挑战性的任务。更多现代的工具提供了方法来显示基于树的结构或状态机来克服这个问题，但这些并不总是足够的。对于一个特定的问题，不能解决的仍然是动态图示和模拟流程，如果需要的话，这些应该被视为移动到一个图形化方法的理由。使用图形建模，用户不需要学习任何东西，只需要使用建模工具。设计往往感觉不太像编程，因为用户可以涉及更多的涉及模型的概念。当学习一个系统时，它也更容易从高层次到低层次来回浏览理解。

0 条回复

动动手指，沙发就是你的了！

登录后才能参与评论