类图

目录 1、啥是UML类图？ 2、UML类图有啥用？ 3、正式理解UML类图 4、使用idea画第一个UML类图 5、类之间的关系图【必须牢记】 6、类之间的关系 6.1、依赖 6.2、泛化 6.3、实现 6.4、关联 6.5、聚合 6.6、组合 7、简单总结类之间的六种关系 前言 关于UML类图的这篇文章，我觉得把它放在设计模式专栏的篇首最为合适，因为在学习设计模式的时候，经常会遇到有关UML类图，没有去专门学过的童鞋肯定会感觉很复杂。学到后面，发现不掌握UML类图，对设计模式或者某一个框架没有整体的把控。所以学好UML类图，你将会更加有自信！ 如果你对类之间的依赖、聚合、关联、组合等关系还很抵制的话，那么这篇文章就很有必要看了，随着对设计模式的慢慢深入了解，或许你也会发现，UML类图就显得格外重要了，是的，UML类图主要是用来描述类之间的轮廓图，而类之间的常见关系就是泛化（Generalization）、实现（Realization）、依赖（Dependence）、关联（Association）、聚合（Aggregation）、组合（Composition）等。类之间关系的强弱：依赖 < 关联 < 聚合 < 组合 < 泛化（继承） @ 1、啥是UML类图？ 首先来看一个专业一点的定义【来自维基百科】 UML即 统一建模语言 （Unified Modeling Language）

类图显示集合的类，接口，关联，协作和约束. 类图绘制目的 : 分析和设计应用程序的静态视图。 描述一个系统的责任。 基地组件图和部署图。 正向和逆向工程。 类图绘制要点： 类图中的名称应该是有意义的描述，并且是面向系统的。 画类图前应先确定每个元素之间的关系。 类图中的每个类职责（属性和方法）应该清晰标明。 类的属性的最小数量应符合规定，去除不必要的属性。 类图的用处（多用于构建） ： 描述系统的静态视图。 显示静态视图中的元素之间的协作。 由系统执行的功能的描述。 构建软件应用面向对象的语言 例子： 下图是一个二阶系统的一个应用程序的一个例子： 系统中的两个要素是所有订单以及客户，一个客户可以有多个订单。 Order 类是一个抽象类，它有两个实例SpecialOrder 和 NormalOrder。 两个继承类 Order 类的所有属性,并分别有额外的功能 dispatch ()和 receive (). 来源： https://www.cnblogs.com/feichangnice/p/11947711.html

前言 关于UML类图的这篇文章，我觉得把它放在设计模式专栏的篇首最为合适，因为在学习设计模式的时候，经常会遇到有关UML类图，没有去专门学过的童鞋肯定会感觉很复杂。学到后面，发现不掌握UML类图，对设计模式或者某一个框架没有整体的把控。所以学好UML类图，你将会更加有自信！ 如果你对类之间的依赖、聚合、关联、组合等关系还很抵制的话，那么这篇文章就很有必要看了，随着对设计模式的慢慢深入了解，或许你也会发现，UML类图就显得格外重要了，是的，UML类图主要是用来描述类之间的轮廓图，而类之间的常见关系就是泛化（Generalization）、实现（Realization）、依赖（Dependence）、关联（Association）、聚合（Aggregation）、组合（Composition）等。类之间关系的强弱：依赖 < 关联 < 聚合 < 组合 < 泛化（继承） @[toc] 1、啥是UML类图？ 首先来看一个专业一点的定义【来自维基百科】 UML即 统一建模语言 （Unified Modeling Language）,它是一种开放的方法，用于说明、可视化、构建和编写一个正在开发的、面向对象的、软件密集系统的制品的开放方法。UML展现了一系列最佳工程实践，这些最佳实践在对大规模，复杂系统进行建模方面，特别是在软件架构层次已经被验证有效。 不得不说，越专业的描述越让人看得越发懵逼..

一、业务领域建模的概念 领域模型是对领域内的概念类或现实世界中对象的可视化表示。又称概念模型、领域对象模型、分析对象模型。它专注于分析问题领域本身，发掘重要的业务领域概念，并建立业务领域概念之间的关系。 业务对象模型（领域模型 domain model）是描述业务用例实现的对象模型。它是对业务角色和业务实体之间应该如何联系和协作以执行业务的一种抽象。业务对象模型从业务角色内部的观点定义了业务用例。该模型为产生预期效果确定了业务人员以及他们处理和使用的对象（“业务类和对象”）之间应该具有的静态和动态关系。它注重业务中承担的角色及其当前职责。这些模型类的对象组合在一起可以执行所有的业务用例。 二、业务领域建模的意义 建立领域模型的好处： 1，通过建立领域模型能够从现实的问题域中找到最有代表性的概念对象 2，并发现出其中的类和类之间的关系，因为所捕捉出的类是反馈问题域本质内容的信息。 经典的面向对象的分析或调研的步骤，是把一个相关的领域，分解为单个领域类或者对象（是一个我们能够理解的概念）。 领域模型是领域类或者是我们感兴趣的现实对象的可视化表示。 它们也被称之为：概念模型、领域对象模型、分析对象模型等。 在UML中，领域模型是不定义操作（方法）的一组类图来说明，它主要表达： 1） 领域对象或者领域类 2） 领域类之间的关联 3） 领域类的属性 属性用以表达对象的状态。 三

类图如下： 来源： https://www.cnblogs.com/minikobe/p/11927658.html

一、业务领域建模的要求 1.收集应用领域信息 -关注功能需求-也考虑其他需求和文档 2.头脑风暴 -列出重要的应用领域概念-列出它们的属性/属性-列出它们之间的关系 3.将业务领域概念分类 -类-属性/属性值-关系 4.关联、继承、聚合 阐述了UML类图对结果的文档化 二、领域建模的十大方法 1.关注现实世界（问题领域）对象。 创建领域模型时，请确保将问题领域与实际对象集中在一起。 尝试着围绕现实世界来组织软件架构。 现实世界往往比软件需求变化要小。下图显示了两种不同类型的类符号。在完整的详细类图上，将使用左侧的版本，其属性和操作。然而，在初始领域建模过程中，分配类的这些部分为时尚早。最好使用右边所示的简单符号。此版本仅显示领域类的名称。 2.使用泛化（is-a）和聚合（has-a）关系来显示对象如何相互关联。 随着时间的推移，会使用新的领域类别来识别领域模型。会注意到他们之间的联系（或关联） - 例如，书评属于书，采购订单（purchase order）和信用卡（credit card）是两种，因为它们都是付款类型。 第一个关系（书评属于一本书）被称为聚合（has-a，因为一本书都会有一书评）。第二个关系（采购订单和信用卡都是付款类型）被称为泛化（is-a，因为采购订单是付款类型）。图2-3显示了这些概念的说明。 这些所谓的一般关系是领域模型中最重要的关系

1：领域建模 领域建模（Domain Modeling）表示开发团队用来获取知识的过程； 2：为什么进行领域建模 因为软件工程师在不同的项目或者领域里面工作，他们需要不同领域各自的模型知识来开发系统。而且，开发工程师可能来自不同的背景，这可能会影响他们对整个系统的理解。事实上，领域模型最不同于传统模型的地方在于，领域建模下，接触到需求第一步就是考虑领域模型，也就是将需求大致划分为几个大的领域，而不是按照数据和行为对其进行分割。然后数据部分依靠数据库实现，行为操作使用服务实现，最后使得需求界限清晰明了。也就是说，领域建模首先考虑的是业务，而不是行为，不是数据。它强调业务抽象和OO编程，这和传统的面向过程式的编程有明显差别。 3：模型和领域建模 模型由元素和元素之间的关系组成，这些元素自身和关系依靠简单图形图表来描述，是一种更为简单的类图，能清晰表达元素的本质特征和各个元素模块的的之间的主要关系，领域模型下，元素之间的关系大致分为继承（Inheritance）、聚集（Aggregation）和关联（Association）三种联系： 继承（Inheritance）：表达概念之间的通用型和专业性关系，在继承关系下，通常是一方比另一方更为通用或者专业，这种关系也会称为IS-A关系； 聚集（Aggregation）：表达这样的一个事实：一个对象是另一个对象的一部分。这种关系也称为所属关系。

我的工程实践选题为ESP32低功耗的实现，本项目基于ESP32嵌入式开发平台.下文将以需求为基础，对该项目进行领域建模。 一、概念介绍 1、业务建模 1.1 概念介绍 业务建模(Business Modeling)是以 软件 模型方式描述企业管理和业务所涉及的对象和要素、以及它们的属性、行为和彼此关系，业务建模强调以体系的方式来理解、设计和构架 企业信息系统 。 1.2 分类 业务建模(Business Modeling)是一种建模方法的集合，目的是对业务进行建模。这方面的工作可能包括了对 业务流程 建模，对 业务组织 建模，改进业务流程，领域建模等方面。 2 领域建模 2.1 概念介绍 领域模型是对领域内的概念类或现实世界中对象的可视化表示。又称概念模型、领域对象模型、分析对象模型。它专注于分析问题领域本身，发掘重要的业务领域概念，并建立业务领域概念之间的关系。 业务对象模型(也叫领域模型 domain model)是描述业务用例实现的对象模型。它是对业务角色和业务实体之间应该如何联系和协作以执行业务的一种抽象。业务对象模型从业务角色内部的观点定义了业务 用例 。该模型为产生预期效果确定了业务人员以及他们处理和使用的对象("业务类和对象")之间应该具有的静态和动态关系。它注重业务中承担的角色及其当前职责。这些模型类的对象组合在一起可以执行所有的业务用例。

定义: Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from the clients that use it. (定义一组算法, 将每个算法都封装起来, 并且使它们之间可以互换. 策略模式使得算法可以独立于客户端变化.) 类图: [UML 类图] UML 类图分析: Context 叫做上下文, 起承上启下的封装作用, 屏蔽客户端对策略算法的直接访问, 客户端只需要调用 Context#operation() 方法即可调用底层的策略方法. Strategy 为策略接口, 声明策略算法方法, 具体策略需要实现 Strategy 接口, 如 ConcretedStrategyA, ConcretedStrategyB. 策略模式的应用: javax.servlet.http.HttpServlet#service() 方法, java.util.Comparator#compare() 方法, javax.servlet.Filter#doFilter() 方法 策略模式的不足: 增加新的策略就需要增加新的类, 策略类需要对外暴露, 客户端需要知道具体策略的存在.

UML类图几种关系的总结，泛化 = 实现 > 组合 > 聚合 > 关联 > 依赖 在UML类图中，常见的有以下几种关系: 泛化（Generalization）, 实现（Realization），关联（Association)，聚合（Aggregation），组合(Composition)，依赖(Dependency) 泛化（Generalization） 【泛化关系】：是一种继承关系，表示一般与特殊的关系，它指定了子类如何特化父类的所有特征和行为。例如：老虎是动物的一种，即有老虎的特性也有动物的共性。 【箭头指向】：带三角箭头的实线，箭头指向父类 2.实现（Realization） 【实现关系】：在这里插入图片描述是一种类与接口的关系，表示类是接口所有特征和行为的实现. 【箭头指向】：带三角箭头的虚线，箭头指向接口 3.关联（Association) 【关联关系】：是一种拥有的关系，它使一个类知道另一个类的属性和方法；如：老师与学生，丈夫与妻子关联可以是双向的，也可以是单向的。双向的关联可以有两个箭头或者没有箭头，单向的关联有一个箭头。 【代码体现】：成员变量 【箭头及指向】：带普通箭头的实心线，指向被拥有者 上图中，老师与学生是双向关联，老师有多名学生，学生也可能有多名老师。但学生与某课程间的关系为单向关联，一名学生可能要上多门课程，课程是个抽象的东西他不拥有学生。 4.聚合