今天再度要进入新的篇章啦！！！
身为软件工程师，想要设计出好的系统架构，或是综观地去理解系统的话，UML 都是不可或缺的，但我在转职自学的过程中却迟迟没有碰到这个观念，直到开始工作才从前辈那边知道这个东西的，真的觉得相见恨晚！
那以下就让我来概述一下 UML，并在後续几天实际画一些 UML 来给各位看看！

为什麽要用 UML？

其实在上面介绍时就已经回答这个问题了 — 「厘清软件系统架构」。

随着日复一日的开发，一开始简简单单的网页就会变成超出我们想像的大系统，这种时候可不能继续只把架构跟逻辑放在各个开发者的脑袋里，这样不论是日後有其他人要进来协作还是自己回去重构、Debug 上都会造成很大的认知负担。

因此，这时候就需要像 UML 这种东西来协助我们去统整跟梳理软件系统的架构，当然应该还有很多种方式可以去做到类似的事情，但我自己在元件库的开发上是有使用到 UML 的，也认为透过这张图让我更理解元件之间的关系了。

那什麽是 UML？

UML (Unified Modeling Language) ，直翻过来是「统一塑模语言」，相信光看名字绝对不知道这是在说什麽，那我们先来看看维基百科怎麽说：

「UML是一种开放的方法，用於说明、可视化、构建和编写一个正在开发的、物件导向的、软件密集系统的制品的开放方法」

「塑模」的意思就是以图形的方式，先将系统的功能与结构画成模型与蓝图，然後再依据蓝图进行实体开发，类似「流程图」的概念。

一言以蔽之，UML 就是 「以图形的方式，将系统的功能与结构画成的模型与蓝图」。

而 UML 有很多种图表可以呈现，不同的 UML 来满足不同的需求，今天会介绍的是描述元件之间的依赖链的是元件图 (Component Diagram) ，常见的还有物件导向的类别图 (Class Diagram) 和壮态管理会用的状态图 (State Diagram)。

元件图 Component Diagram

https://upload.wikimedia.org/wikipedia/commons/7/74/Component-4.png

元件图这边很单纯，就是反映出元件之间的依赖关系反映出元件之间的依赖关系。

介面（ Interface ）就如同 Day 04 所说的，是一项功能的抽象化。

元件（ Component ）就是指那一个个的 UI 元件。

大多数的元件都可以追溯到一个介面，也就是先实作介面，再慢慢扩充成一个个元件，接下来这系列每天都会画一个 UML 来让大家更理解这个概念。

那先给大家看看一个 UI 元件库的元件图可能会长成什麽样子：

简易清晰一点的版本：

大方向就是 介面（Interface） 会是基底，并连接许多元件，而单一元件不一定只会连接到一个介面，还是觉得看不清楚的没关系，後续几天会各自去介绍里面的每个小区块的！
简易版的是我实作的版本，那其实还有很多介面是可以再抽出来的，就等全部介绍完再跟大家说说有哪些优化方向了！

这系列会怎麽介绍？

除了透过 UML 来介绍元件间的依赖关系之外，这个篇章还有一大重点是：

希望把所有（或至少会把九成的元件介绍一遍）会用到的 UI 元件介绍一轮，介绍的主要方向会是「开发者会预期怎麽去使用这些元件（也就是元件的 API 设计）」、「各个元件的使用情境（为什麽需要这些 UI 元件的，它们解决网站互动或呈现上的什麽需求）」。

小结

今天是新篇章，所以其实算是导览的性质，带大家理解 UML 的概念跟介绍我们会使用的 元件图 (Component Diagram) 之後，明天开始就会一个个去画这些图并跟大家介绍了！

而在各家对元件分类的方式都不一样的情况下，元件的 UML 也是可以不一样的，该如何去规划元件之间的关系跟封装它们都没有绝对，大原则就是团队使用起来顺手、有共识，或是文件要写得好，避免使用者踩到一些莫名其妙的雷！

那就明天见罗！

References
https://app.diagrams.net/
https://hooo.medium.com/工作笔记-关於uml的一点小分享-a06cdd9d912d
http://tx.liberal.ntu.edu.tw/InfoMgt/Jx/IS_IM/uml.htm
https://ithelp.ithome.com.tw/articles/10223499
https://glj8989332.blogspot.com/2018/02/design-pattern-uml.html