共计 1526 个字符，预计需要花费 4 分钟才能阅读完成。
UML 类图绘制实例
上面将应用如属官的借阅管理系统做一个图书馆管理系统的 UML 类图。
最终的绘制后果大抵如下：
后期建模
对于图书馆的借阅零碎的建模，首先咱们把所有须要定义的根底类定义进去，再把咱们的网页游戏插入进去。别离是 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 自行决定和具体实现。
