架构文档总结
包图规范
1、格式
● 包
● 关系
○ 泛化
○ 依赖
2、包图中元素
● 类
● 接口
● 构件
● 节点
● 协作
● 用例
● 其他包或图
3、包图中关系
● 泛化
● 依赖
○ use ：使用关系，是一种默认的依赖关系，说明客户包（发出者）中的元素以某种方式使用提供者包（箭头指向的包）的公共元素，也就是说客户包依赖于提供者包。
○ import：引用关系，最普遍的包依赖类型，说明提供者包(箭头指向的包)的命名空间（包本身代表命名空间）将被添加到客户包（发出者）的命名空间中，客户包中的元素也能够访问提供者包的所有公共元素。
○ access：访问关系，只想使用提供者包中的元素，而不想将其命名空间合并则应使用该关系。
○ trace：追溯关系，想表示一个包到另一个包的历史发展，则需要使用《trace》关系来表示。
4、包的可见性
● “+” ：public
● “-” ：private
● “#” ：protected
5、绘制包图原则
● 每个包都必须有一个唯一的包名
● 包图中拥有的元素不得超出规范中的六种元素
● 最小化包间的依赖，最小化每个包中的 public , protected 元素个数，最大化每个包中 private 元素个数
● 包间关系不能出现循环依赖的情况
● 包中可以嵌套子包
● 包图需体现出包间的层级关系，一个层级的包放到一张图。一般情况下，只绘制第一层级的包关系即可。
6、示例
类图规范
1、格式
● 接口：
● 抽象类
● 类
TIPS：
● 接口一定有 <> 的标识，接口中的方法必须斜体（默认都是抽象方法）
● 抽象类名和抽象方法必须斜体，非抽象方法不斜体
● 注意访问控制符、返回值、参数等格式的正确性
● 类中属性、方法要描述全面
○ 类中使用注解或者new的方式声明的其他类的成员变量也是该类的属性：
■ 原因一：对此类本身而言，此类的类内结构包括属性（成员变量）和方法（成员方法）
■ 原因二：对类间关系而言，虽然这个类与其他类（这个类声明其他类对象）之间有关联（或其他关系），但是这个关系是体现在类间的。
● 类图中要标注使用的设计模式
2、类间关系
种类：
● 继承 实线+空心三角 继承父类
● 实现 虚线+空心三角 实现接口
● 组合 实线+实心菱形 成员变量
● 聚合 实线+空心菱形 成员变量
● 关联 实线+箭头 成员变量
● 依赖 虚线+箭头 局部变量、方法的参数或者对静态方法的调用
3.标准：
● 1.类间关系的格式与描述要做到准确无误，紧密贴合代码，与代码保持一致。
● 2.符合UML规范。
● 3.在UML基础上，不能有二义性，图要能表达出来明确的含义。
● 4.统一，整体看着整洁，一致，比如关系：继承和实现关系纵向画，其他关系横向画。
4.常见误区：
①类中包含其他类的对象作为成员变量，这个成员变量也是类的属性
错误的：
②类图中方法名要按照编码规范进行命名，以此保证可以通过英文方法名便可知道方法的作用和含义，不需要加中文注释。
对于代码中的注释，是要详细写清楚实现逻辑的，所以详细的注释在代码中体现即可。
3.配置文件在类图中不需要体现，eg：yml,properties,xml
1.类中静态不可变属性如何表示？ 只表示访问权限修饰符即可。
2.方法入参和返回值都是泛型如何表示？
3.自定义注解用什么类来表示？
4.内部类如何表示？
成员内部类：
局部内部类：没有单独的表示方法
匿名内部类：idea生成的类图中匿名内部类没有任何形式的体现
静态内部类
NS图规范
介绍
N-S（Nassi Shneiderman）图又被称作为盒图，是用于取代传统流程图的一种描述方式，在描述过程中去掉了流程线。在NS 图中，每个“处理步骤”是用一个盒子表示的，所谓“处理步骤”可以是语句或语句序列。需要时，盒子中还可以嵌套另一个盒子，嵌套深度一般没有限制，只要整张图在一页纸上能容纳得下，由于只能从上边进入盒子然后从下边走出，除此之外没有其他的入口和出口，所以，NS图限制了随意的控制转移，保证了程序的良好结构。
基于结构化程序设计方法(structured programming, SP）实现。
Ns图的结构及画法
1、顺序结构
顺序结构：表示程序中的各操作是按照它们出现的先后顺序执行的。
2、选择结构
选择结构：表示程序的处理步骤出现了分支，它需要根据某一特定的条件选择其中的一个分支执行。选择结构有单选择、双选择和多选择三种形式。
3、循环结构
直到型循环：表示从结构入口处直接执行循环体，在循环终端处判断条件，如果条件不满足，返回入口处继续执行循环体，直到条件为真时再退出循环到达流程出口处，是先执行后判断。因为是"直到条件为真时为止"，所以称为直到型循环。
当型循环：表示先判断条件，当满足给定的条件时执行循环体，并且在循环终端处流程自动返回到循环入口；如果条件不满足，则退出循环体直接到达流程出口处。因为是"当条件满足时执行循环"，即先判断后执行，所以称为当型循环。
注意事项
1、图形清晰、整齐。
2、全局到局部思路来画
先画整体：
再画局部：
3、最终粒度到不可拆分。
常见误区
- NS图没有开始,结束模块
2.NS图，必须要有返回结果，返回内容要写明确。如上图，返回两个字，不合格。
3.不允许出现不属于图的元素，如指向线，和注释标签（NS图完全去掉了流程线，算法的每一步都用一个矩形框来描述，把一个个矩形框按执行的次序连接起来就是一个完整的算法描述。 ）
4.像下面这样红框内的业务，十分相近，则合并为一个框.
架构图规范
宏观出发
1、整体结构
2、色彩搭配
● ①架构图让读者看到的第一眼，应该给读者留个好印象，从色彩搭配上来看，颜色不超过5个，颜色搭配要有所区分，不同层级、不同类型要颜色不同，但是也不能太跳脱，整体上颜色风格要一致，图的美观设计最起码要符合大众审美。
● ②第二眼看的应该是整体结构，整张图一共分为几个层次模块，架构图是不是能清晰的表达模块与模块之间的关系？纵向：分层——上层依赖于下层越底层，越是基础服务；横向：并列关系，级别相同。
● ③线框的使用，虚线框与实线框的意义是不同的，使用虚线框还是实线框更能准确清晰的表达想要表达的意思。多个模块，逻辑上可以归为一块时可以使用虚线框。
● ④对称：要讲究对称美，尽可能地功能结构分配均匀；
局部细节
1、用词表达
● 要用词准确，可以让开发人员或者用户理解描述的意思
● 命名上要统一，英文名体现专业性，命名要尽可能使用短名称且一致；
2、是否全面
3、模块划分粒度
● 细节要进行抽象，抽象出模块，模块的粒度要合适，不可太具体，也不可太宽泛
4、模块摆放以及层级关系
● 同一个级别的模块要统一级别，粒度大小要统一；
5、图形间距离适中，避免间距过大、过小，影响美观。
● 大小、格式：要注意大小一致，格式统一；
说明：
● 架构图的名词表达要到位，比如：业务架构图和运维架构图中不能出现技术的字眼。因为不同架构图的读者是不同的，要保证你的读者能迅速的get 到你想表达的意思，这是很重要的。
● 架构图表达的内容是否全面，不管是业务，技术还是运维架构图要表达的内容一定要全面，包括软件系统依赖的第三方服务等都要体现出来。
● 关于架构图中模块的划分粒度，一定要合适，既不能太宽泛，也不能太细粒度，要达到对具体的小功能模块进行一层抽象的粒度即可。
● 包括模块摆放的逻辑是否准确，架构图的每一个模块的摆放，都是有讲究的，要能说出为什么这个模块放在这？放在那行不行？为什么？能回答出这几个问题，相信你的架构图问题不大。
参考
技术架构图：
业务架构图：
运维架构图：要求加上服务器的ip/域名
注意：画生产环境。
总结：
画架构图的最大原则：让别人能看的懂，理解的明白！
验收标准：
1.参考架构设计中的三种图：业务架构图、技术架构图、运维架构图。
2.包图作为技术架构图的一部分，要体现分层、包间关系。
要求：
1.准确的表达类关系的图标。
2.标明已有的设计模式。
