详细的图书馆管理系统UML图终极版

图书馆管理系统UML图1.要求通常，需求规范文档由系统最终用户的代表以文本形式编写。对于这个库应用程序，需求规范文档应该如下所示：1.这是一个图书馆支持系统；图书馆把书和杂志借给借款人。借款人已经预先登记，书籍和杂志也已经预先登记。图书馆负责购买新书。每本书都会买很多书。过期或破旧的旧书要从图书馆搬走。图书管理员是图书馆的雇员。他们的工作是与读者打交道，并在软件系统的支持下工作。借款人可以预订目前没有的书籍和杂志。这样，当他订购的书籍和杂志被退回或购买时，他将通知图书管理员。当预订了一本书的借书人借了这本书，预订就被取消了。或者通过显式取消过程强制取消预订。6.图书馆可以轻松地建立、修改和删除书名、借阅者、借阅信息和预订信息。7.该系统可以在所有流行的技术环境中运行，包括Unix、Windows和OS/2，并且应该具有现代图形用户界面(GUI)。8.该系统易于扩展新功能。该系统的第一版不需要考虑预订到达时通知预订人的功能，也不需要检查过期图书的情况。一般来说，最终用户代表由系统调节书写文本的文档需求。对于库应用程序，它应该类似于标准文档需求so:1.这是一个图书馆支持系统；2.图书馆将借书和杂志接书者。借书者已提前登记，书刊杂志也将提前登记；3.图书馆新书采购。这本书不仅仅是买每一本书。当旧书延长或磨损，从图书馆移走。4.图书管理员是图书馆的工作人员。他们的工作是在软件支持系统工作中与读者打交道。5.借书的人可以预定没有电流的书籍和杂志。所以，当他的书和杂志回来或购买，确认。当预定了借书者借书的预约被取消后。或者通过显式取消过程强制取消预订。6.图书馆可以方便地建立、修改和删除书名、借书者、借阅信息和预约信息。7.系统可以在所有流行的技术环境下运行，包括Unix、Windows和OS/2，并且应该具有现代图形用户界面(GUI)。8.该系统易于扩展新功能。第一版无需考虑图书到货确认后的预订系统，不检查图书过期功能。2.分析系统分析的目的是捕获和描述所有的系统需求，并建立一个模型来定义系统中的主要领域类。通过系统分析，可以达到开发者和需求者之间的理解和沟通。因此，分析通常是分析师和用户之间合作的产物。在这个阶段，程序开发人员不应该考虑代码或程序问题。这只是理解需求和实现系统的第一步。2.1需求分析分析的第一步是确定系统能做什么。谁将使用这个系统？这些分别被称为参与者和用例。用例描述了系统提供的功能。通过阅读和分析文档以及与潜在用户讨论系统来分析用例。图书馆的角色被设定为图书管理员和借阅者。图书馆员是软件系统的用户；借款人是来借或预订书籍和杂志的顾客。偶尔，图书管理员或其他图书馆工作人员也可能是借款人。借款人不直接与系统交互，借款人的功能由图书管理员执行。系统分析的目的是捕获和描述所有的系统需求，并建立一个模型来定义系统中的域。通过系统分析，使开发者和需求者理解和交流。因此，分析一般是分析师和用户合作的产品。在这个阶段，程序开发者不应该考虑代码或程序问题；它只是了解需求和实现系统的第一步。图书馆系统中的用例有：1.借书2.归还这本书3.保留4.取消预订5.添加标题6.修改或删除标题7.增加书目8.删除书目9.增加借款人10.修改或删除借款人由于一本书通常有多个备份，系统必须区分书名和书目的概念。库系统分析的结果写在UML用例图中，如图1所示。每个用例都附有一个描述用例细节和客户交互的文本文档。文本是通过与客户讨论获得的。用例“借书”描述如下：1.如果借款人没有预订：确定标题确定本标题下的有效书目。确定借款人。图书馆将借出书籍。注册新的贷款2.如果借款人有预订：确定借款人。确定标题确定本标题下的有效书目。图书馆将借出相应的参考书目注册新的贷款取消预订除了定义系统的功能需求之外，用例还被用于分析过程，以检查是否已经定义了相应的域类，然后它们可以被用于设计阶段，以确保解决方案能够有效地处理系统功能。实现细节可以在序列图中可视化。案例库系统是：1.借书2.还有书3.保留4.取消5.添加标题6.修改或删除标题7.增加书目8.删除书目9.增加结树者10.接书者修改或删除由于一本书往往有多个备份，因此系统必须将书名和书目概念分开。用UML用例图编写的库系统分析结果，如下图1所示。每个案例都堆满了文本文档，描述案例和客户互动细节。文字是与客户讨论得到的。案例借用描述如下33601.如果借了没有预约：当然可以确保此标题在书目下有效确定接话者图书馆将预订茅斯注册新的lendingh2.如果借了一本书决定性书籍当然可以确保此标题在书目下有效图书馆将相应的书目输出注册新的lendingh取消预订h除了定义用于分析流程的系统的功能需求之外，还用于检查是否已经定义了相应的范例域类，然后它们可以在设计阶段使用，保证解决方案能够有效地处理系统功能。可以在序列图中可视化实现细节。图1:角色和用例。分析的第一步是指出系统可以用于什么，以及谁将使用它。它们分别是用例和角色。所有用例必须从角色开始，一些用例也以角色结束。角色是你工作的系统之外的人或其他系统。打印机或数据库可以是一个角色。这个系统有两个角色：借用者和图书管理员。通过与用户或客户的讨论，每个用例都可以用语言来解释。2.2领域分析系统分析还详细列出了域(系统中的关键类)。为了得到一个领域分析，你可以阅读规范文档和用例来找出哪些概念应该被系统处理。或者组织一个有用户和领域专家参与的小组讨论，指出系统中必须处理的关键概念及其关系。图书馆系统中的领域类如下：借阅者信息(如此命名以区别于用例图中的角色借阅者)、标题、图书标题、杂志标题、项目、预订和借阅。这些类及其关系记录在类图文档中，如图2所示。域类被定义为业务对象版本。业务对象版本是用户定义的版本，它指定该类的对象是关键域的一部分，应该永久存储在系统中。其中一些类有UML状态图，用于显示这些类的对象可能具有的不同状态以及触发其状态改变的事件。本例中带有状态图的类是项目类和标题类。用例借出项的序列图如图3所示。所有用例的序列图可以在在线模型中找到。它们之间的关系记录在类图文档中，如图2所示。域对象类定义为一个朋友，一个朋友对象版本的版本类型是一个用户定义的类类型的版本，指定的部分对象是关键域，并且应该在系统持久存储。这些类型的UML中的一些状态图，用来显示一个类的这些对象可能有不同的条件，并触发它们的事件状态的变化。这