目录
UML类图绘制实例
下面将使用如属官的借阅管理系统做一个图书馆管理系统的UML类图。参考自*Library Domain Model*
最终的绘制结果大致如下：
前期建模
对于图书馆的借阅系统的建模，首先我们把所有需要定义的基础类定义出来。分别是Book(书籍)、Library(图书馆)、Patron(顾客)、Librarian(图书管理员)四个基础的对象。
我们尝试将四个基础类进行关系连接，最后的到的关系图如***，就算没有图书，图书馆也不会消失，因此使用空心的关联关系：
业务扩展
增加用户账号管理
由于客户借还书籍过程中，图书馆里系统的后台会希望能够查看该顾客的曾借用书籍，已借阅待还书籍，以及当前客户是否有权限进行新书的借阅。
因此我们需要在图书馆管理系统中，引入**Account（账户系统）**作为代理，用于方便关联借阅的顾客和馆中的书籍。
该UML中，图书馆持有多个账号，这个不难理解；每个账号代理以前每一个借书者去依赖书，也不难理解；账号有指向Partron的关联关系我们也不难理解，毕竟账户作为代理方，肯定需要有被代理的人的信息；但是可能存在的困惑点在于Account和Patron之间的聚合关系，这里我理解是因为在本项目设计中，账号被设计成了可以回收利用的号码，因此如果该账号闲置的时候，是可以不关联任何用户的，直到账号被下一次利用重新分发给新人。
增加书籍借阅信息
管理好了借书的人，我们的图书馆管理系统还需要增加书籍管理系统，用来标记每本书籍自身的状态，比如该书籍的条码、RFID中的信息、是否允许借出图书馆、图书的类别、图书的借出时间、图书的借阅周期（时长）、图书的应归还时期等等信息。这些都是图书馆自身作图书管理所需要信息而非书籍本身的信息。
因此我们需要在原始图书的基础之上扩展一个图书馆的书目实体Book Item，里面除了书籍自身的信息之外，还包含了该书管理过程中的信息。
更新之后的UML如下：
增加检索和管理功能
随着图书馆书籍越来越多，图书馆管理员需要对这些书籍进行分类有序放置、对特定的书目进行查找，顾客需要根据条件检索自己需要的书目。因此我们需要继续扩展我们的Book Item类，给其更多的信息便于分类：比如定义其书籍语言、书籍名称、总页数、书目类别等等信息。
此外我们扩展了原始书籍的作者信息，虽然作者通常是在书籍分类时才会使用，但是其本身作为书籍的通识信息，因此在类设计时，将其关联Book而非Book Item。
同时我们需要对图书馆内所有的图书都进行完整的归档管理，所以需要新增一个Catalog类来统一管理。
这里，因为我们现在已经完成了Book Item的属性扩展，同时建立了Catalog用于专门的图书管理机制，Catalog本身虽然不受是否有书的影响，但是图书馆的管理和检索的规则，是一定建立在我们的Catalog之上的，因此这里使用组合关系。
由于赋予了顾客检索的功能，也赋予了图书馆管理员检索和管理图书的功能。这里我们不难发现两种不同的角色都有一个重复的操作——查找search。同时因为这个Search其实仅仅只和图书馆的目录Catalog相关，无论谁来这个图书馆，他们其实只关心能不能找到自己需要的书，至于怎么从Catalog中找到这本书，以及Catalog是怎么维护所有数目的，对于查找的人来说其实并不需要关心。
因此外部的调用方（比如Patron、Librarian）其实只需要调用这个系统提供的API（也即接口）即可，这个API是一个大家对齐过的统一的规范，比如search就是查找本座图书馆有没有某本书，manage就是管理这本书。外部只需要直到调用这个api可以达到这个目的，而至于怎么达到这个目的则由图书馆的Catalog自行决定和具体实现。
因此最终的类图如下：
结语
至此一个比较清晰的图书馆的UML类图已经绘制完成。这次在准备继续阅读Spring源码过程中，发现自己不能老是单纯只看实现，而应该从中吸取架构设计经验的时候，发现自己在设计模式层面，知其然而不知其所以然，遂这里先把自己的底子打好，然后再继续我的源码阅读之路。
抬头仰望星空而不是滞于眼前三尺之地，才会知道自己有多渺小～～