前一篇Post因为绘图的关系导致理解上有所误区，所以重构一下，重新更新了图形，让我们重新来审视一下这个被多次讨论的设计。
首先是图书馆的用例：
其实用例的情况大家都很清楚了，简而概之就是用户在图书馆的书架上找到自己想要的书，然后向管理员出示借书卡后借到想要的书。
用例图。
这是一个很简单的用例，我没有分析完所有的用例以及子用例，这里到此就可以打住了，我们可以在以后的迭代过程当中来继续完善
然后根据需求我们来建立业务规则表：
规则一：借书需要出示身份证明以及借书卡 （来源：图书馆馆规）
规则二：每个用户一张借书卡 （来源：图书馆规定）
规则三：每张借书卡可以借N本书 （来源：图书馆规定）
然后得到领域模型：
这个模型也是一个很粗略的模型，不过足够我们开始下面的分析了。这个模型是动态的，在我们分析的过程中还可能发生变化。我们不要害怕变化，优秀的开发过程和设计模型都是应对变化的丰富实践经验的结晶。我们可以通过这个领域模型清楚的看到概念类的属性以及概念类之间的关系。注意，概念类不是我们在编程的过程中所写的类，当然对于很多简单的模型来说，领域里的概念类可以直接变成程序里的类，但是并不表示其之间可以画上等号，我们还需要继续分析系统中对象的行为。我们可以通过时序图和通信图来表示这些行为的过程。
我们在之前所界定的系统边界之内分析系统的操作，然后定义系统操作的操作契约。最后我们综合用例分析，领域模型和操作契约的分析，最终得到了系统的设计。
这里我们没有看到任何的代码，也不涉及任何贫血充血的争论，我们先建立一个粗略的模型，然后在实现的过程中不断的迭代优化它，最终实现我们的软件，不会出现过度设计，也不会出现一上手就是代码的盲目。
由于时间关系，LP吹促觉觉，故下文明日再说。