红橙Darren视频笔记 UML图简介

整体架构复制自红橙原视频的课堂笔记 因为他这一课没有博客，所以没有转载链接，CSDN没有转载地址是无法作为转载类型的文章发表的，暂时标记为原创

参考链接

https://blog.csdn.net/ruren1/article/details/81584232

本节的UML图使用SmartUML绘制

1.UML图分类

注意 我们开发常用的有类图 时序图这两种图，其他的可以适当了解。

1.1 类图：类图是描述系统中的类，以及各个类之间的关系的静态视图。能够让我们在正确编写代码以前对系统有一个全面的认识。类图是一种模型类型，确切的说，是一种静态模型类型。

1.2 时序图：时序图是用来显示你的参与者如何以一系列顺序的步骤与系统的对象交互的模型。时序图可以用来展示对象之间是如何进行交互的。时序图将显示的重点放在消息序列上，即强调消息是如何在对象之间被发送和接收的

1.3 用例图：描述角色以及角色与用例之间的连接关系。说明的是谁要使用系统，以及他们使用该系统可以做些什么。一个用例图包含了多个模型元素，如系统、参与者和用例，并且显示了这些元素之间的各种关系，如泛化、关联和依赖。

1.4 协作图：和时序图相似，显示对象间的动态合作关系。可以看成是类图和顺序图的交集，协作图建模对象或者角色，以及它们彼此之间是如何通信的。如果强调时间和顺序，则使用序列图；如果强调上下级关系，则选择协作图；这两种图合称为交互图。

1.5 状态图：描述类的对象所有可能的状态，以及事件发生时状态的转移条件。可以捕获对象、子系统和系统的生命周期。他们可以告知一个对象可以拥有的状态，并且事件(如消息的接收、时间的流逝、错误、条件变为真等)会怎么随着时间的推移来影响这些状态。一个状态图应该连接到所有具有清晰的可标识状态和复杂行为的类；该图可以确定类的行为，以及该行为如何根据当前的状态变化，也可以展示哪些事件将会改变类的对象的状态。状态图是对类图的补充。     

1.6 活动图/流程图：描述用例要求所要进行的活动，以及活动间的约束关系，有利于识别并行活动。能够演示出系统中哪些地方存在功能，以及这些功能和系统中其他组件的功能如何共同满足前面使用用例图建模的商务需求。

1.7 构件图：组件图提供系统的物理视图。它的用途是显示系统中的软件对其他软件组件（例如，库函数）的依赖关系。组件图可以在一个非常高的层次上显示，从而仅显示粗粒度的组件，也可以在组件包层次2上显示。

1.8 部署图：部署图表示该软件系统如何部署到硬件环境中。它的用途是显示该系统不同的组件将在何处物理地运行，以及它们将如何彼此通信。因为部署图是对物理运行情况进行建模，系统的生产人员就可以很好地利用这种图。

2. 类图 （类与类之间的关系）

2.1 Generalization 泛化（继承）

MainActivity继承自AppCompatActivity

 

2.2 Realization ：实现

AppCompatActivity实现了接口

 

2.3 Dependency 依赖

是一种使用关系，即一个类的实现需要另一个类的协助。逻辑上能用"use a"表示 ，尽量不要使用双向依赖。代码体现：局部变量、方法的参数和静态方法的调用。

Activity1.java
public class Activity1 {
    public void click1(View view) {
        if (Utils.isNetworkOK()){
            //Do some thing
        }
    }
}


Utils.java
public class Utils {
    public static boolean isNetworkOK() {
        return true;
    }
}

比如上面的代码中Activity1依赖Utils

 

2.4 Association 关联

体现在成员变量，包含双向关联，单向关联

是整体与部分的关系。逻辑上能用"has a"表示。代码体现：成员变量。

双向关联用一条实线或者一条实线+两个箭头表示；单向关联，一条实线+一个箭头表示。

比如一个老师有多名学生 一名学生有多名老师就是典型的双向关联

Student.java
class Student {
    List<Teacher> teachers;
}


Teacher.java
class Teacher {
    List<Student> students;
}

 

2.5 Aggregation 聚合

整体与局部的关系,并且没有了整体 , 局部也可单独存在。逻辑上能用"has a"表示。如公司和员工 ， 车与轮胎 

Employee.java
public class Employee {
}

Company.java
public class Company {
    List<Employee> departments;
}

 

2.6 Composition 组合

整体与局部的关系,是一种强烈的包含关系，部分不能脱离整体存在。逻辑上能用"has a"表示。代码体现：成员变量。例如部门与公司

Company.java
public class Company {
    List<Department> departments;
}

Department.java
public class Department {
}

 

可以看到 仅仅从代码上看 2.6 与2.5 应该是完全一样的关系，但是如果按照部分能不能脱离整体来区分 就有了聚合与组合的差别

2.7 小结

泛化和实现最容易区分

依赖注意“局部变量、方法的参数和静态方法的调用”即可

组合，聚合的关系其实不是很明显 一般绘制类图时区分不是很严谨

关联记住存在双向关联就容易记住了

泛化和实现体现了逻辑上的"is a"的关系，组合、聚合和关联体现了逻辑上的"has a"的关系，“依赖”体现了逻辑上的"use a"的关系。

2.8 实战 绘制Window 简单架构   

我直接画图了 分析可以参考我之前写的两篇文章

红橙Darren视频笔记setContentView源码分析

https://blog.csdn.net/u011109881/article/details/111085949 

红橙Darren视频笔记 自定义View总集篇

https://blog.csdn.net/u011109881/article/details/113273632

 

Activity Window WindowManager WindowManagerService的关系大致如下

Activity中含有一个Window Window中有一个DecorView DecorView是一个FrameLayout 因此 Window是Activity负责显示的部分，同时window中还有一些标志位记录当前window的类型 位置 对齐方式 键盘状态等

WindowManager继承自ViewManager 而ViewManager只有有以下方法

    public void addView(View view, ViewGroup.LayoutParams params);
    public void updateViewLayout(View view, ViewGroup.LayoutParams params);
    public void removeView(View view);

所以WindowManager主要职责是管理Window中的View的 

但实际我们查看WindowManaWindowManagerImpl时发现WindowManaWindowManagerImpl啥都没做 工作直接扔给了WindowManagerGlobal

因此WindowManager并不是直接管理Window中的View 而是通过WindowManagerGlobal间接管理，WindowManagerGlobal则通过Session跨进程通信，依赖于WindowManagerService

具体的对View操作实际交给了WindowManagerService

这块参考了

https://juejin.cn/post/6844903893634138120

3. 时序图  （方法调用流程关系）

时序图没什么特别的介绍，了解代码执行流程后还是比较容易绘制的

Activity 启动流程的时序图我之前已经分析和绘制了 参见

https://blog.csdn.net/u011109881/article/details/117716367