UML建模语言、设计原则、设计模式( 四 )


? ..................
关键字表示方式public用 + 表示private用 - 表示protected用# 表示package用~ 表示abstract用*表示static用 $ 表示泛型用~泛型类型~表示 如:List~int~ position注解用以<<开头 注解内容 以>>结尾可以用一个特定的标记文本来注释,如:<<Interface>> 代表一个接口<<abstract>> 代表一个抽象类<<Service>> 代表一个服务类<<enumeration>> 代表一个枚举注释用%%注释内容表示注释开始到下一个换行符之前的任何文本都将被视为注释 , 包括任何类图语法这是对类图进行注释,即:说明,不是说属性、方法.....都搞这个对于类:以 https://www.processon.com 网址中的为例(下列名字见名知意,对照上面的人话定义即可)

UML建模语言、设计原则、设计模式

文章插图
对于接口:和上面的类图是相通的
UML建模语言、设计原则、设计模式

文章插图
1.2.3.1、类图之间的关系名字指向示例图示泛化 / 继承子类 指向 父类 子抽象类 指向 父抽象类学生类 继承 人类实心三角箭头 和 空心三角箭头都行
UML建模语言、设计原则、设计模式

文章插图
组合菱形部分指向整体是属于包含关系中的一种(组合、聚合、关联)是A has - a B的关系 。一句话:一荣俱荣、一毁俱毁整体和部分关系、整体部分不可分离、比聚合更强如:一个类中的一个属性为private Head head = new Head(); ,直接绑定在一起的大雁和大雁翅膀的关系,两者是同生共死的
UML建模语言、设计原则、设计模式

文章插图
聚合菱形部分指向整体[箭头指向个体 , 这个箭头可有可无]是属于包含关系中的一种(组合、聚合、关联)是A has - a B的关系 。还是整体和部分的关系,但是创建时有可能是分隔开的如:一个类中的属性为private IDCard card;这个属性值可能会后续在其他地方传进来(有参构造)大雁和雁群之间的关系更如:电脑和主板
UML建模语言、设计原则、设计模式

文章插图
关联 / 关联类箭头指向成员变量类(单关联) 。这种单关联注意一种模型图(最严格的一种写法):在没有箭头的一方可能会有一个“×”,这表示:箭头的一方一定没有关联“×”的一方 。反之:没有“×”表示当前模型中没有明确说明无箭头一方是否关联有箭头一方箭头指向彼此(双关联),如:A类中有B类作为成员变量(属性) , B类中有A类作为属性,此时彼此都产生关联,即为双向箭头 / 双关联还有一种写法:两边都没有箭头,就是一根实线,这种直接说是包含关系(是一种不严谨的写法) , 这种直接当做属性,A类和B类至于是单关联还是双关联都行注意一种情况:下面这种 下图不等价于上图(它们表示“不同组”,即:上图表示Car关联的是驾驶这辆Car的Person,而Person驾驶的是同一辆Car;而下图表示Car关联的是驾驶这辆Car的Person,但Person关联 / 驾驶的是另外的Car[某辆车需要人类中的某个人来驾驶 , 而人类中的另外某个人可以驾驶另外型号的车])
UML建模语言、设计原则、设计模式

文章插图
关联关系是属于包含关系中的一种(组合、聚合、关联)是A has - a B的关系是整体和部分的关系,可以分割,是后来组合在一起的换言之:两个类之间的关联,也可以是一个类和自身的关联班级类和学生类,学生类作为成员变量存在于班级类中也如:人有汽车、人有电脑
UML建模语言、设计原则、设计模式

文章插图
类关联这就是比关联类更细节性的画图(让某些情景不产生歧义)抽象了多对多的本身(A集合和B集合各自全集的笛卡尔乘积的子集)下图为关联类
UML建模语言、设计原则、设计模式

文章插图
上图表达的逻辑:1、一个人有多条出席会议记录 , 对应的是一个会议[图符合,因为这个人可能会和不同的人开同一个会议];2、一个会议有2或以上条出席会议记录 , 对应的是一个人[图也符合,因为这个会议某个人可能参加了多次] 。所以虽然图看起来没问题 , 但是不贴合现实[一个人出席了同一个会议那记录为1就可以了,按上图来看就会出现某个人有多条出席会议记录 - 即:重复了] , 所以上图中“总的出席会议记录数量大小”在数学上应该是:多人、多会议各自全集的笛卡尔乘积的子集[会排除重复的],因此为了贴合现实图就改造为如下的类关联:

推荐阅读