使用uml对图书管理系统建模

《使用uml对图书管理系统建模》由会员分享，可在线阅读，更多相关《使用uml对图书管理系统建模（16页珍藏版）》请在金锄头文库上搜索。

1、使用UML对系统进行建模面向对彖的软件工程，同传统的面向过程的软件工程相比，在需求的获取、系统分析、 设计和实现方面都有着很大的区别。UML是OOA和OOD的常用工具。使用UML来构建 软件的面向对象的软件工程的过程，就是一个对系统进行不断精化的建模的过稈。这些模型 包括用例模型、分析模型、设计模型，然后，我们需要使用具体的计算机语言来建立系统的 实现模型。当然，在整个软件T程中，我们还需要建立系统的测试模熨，以保证软件产品的 质量。使用面向对彖的工具来构建系统，就应该使用面向对象的软件工程方法。然我，我们经 常会发现，在实际的开发过稈中，很多开发人员虽然能够理解UML的所有图形，却仍然不 能

2、得心应手的使用UML来构建整个项日，其很大的原因，是仍然在使用原有的软件工程方 法，而不淸楚如何使用UML来建立系统的这些模型，不清楚分析和设计的区别，以及他们 之间的转化。应用软件系统，就其木质来说，是使用计算机对现实世界进行的数字化模拟。应用软件 的制造过程，按照UML的方法，就是建立这一些列模型的过稈。木文将就一个图书馆系统, 说明如何使用UML来对系统进行这一系列的建模。关于这个图书馆系统，基木的需求比较简单，就是允许学生可以在图书馆借阅和归还图 书，另外，也可以通过网络或者图书馆的终端来杏阅和预订书。当然，图书馆管理员也可以 对图书进行管理。为了简化系统，我们没有把图书馆中的人员作细

3、分。之所以采用这个相对简单案例，是因为很多人都对图书馆系统有很强的感性认识,这样, 读者不需要花很多的时间来理解系统包含的业务知识。同时，也因为木文只是对使用UML 的过程做一个探讨，着眼于使用UML进行建模的过程，说明备个层次的模型Z间的区别和 联系，展示系统演进的过程，而不会深入UML的细节方面。对于更加复杂的系统，其分析 和设计的方法是相通的，可以举一反三。用例模型系统需求的获取用例模型定义系统做什么，是用来获取系统需求的有效手段。用例模型由“角色”和“用 例”组成。我们在构建一个用例的时候，通常要做的第一件事情是识别角色，或者说，参与 者。然后我们需要识别系统为参与者提供的服务，或者说

4、，参与者的行为，也就是用例。最 后，我们确定角色和用例之间的关系。在这个图书馆系统中，我们可以识别出的角色有学生 和图书管理员。報个用例模型包含的用例有：借书、还书、查阅图书、预订图书，以及图书 维护。用例模型可以用用例图表示如下：图书管理员管理图书确定冇效用例的关键是，检查用例是否包含了一个完整的功能。用例不能定的过细，不 能把一个完整的功能的一个部分作为一个用例，也不能在一个用例中包含过多的功能。例如, 用户的登录。学生在预定图书的时候，可能会需要首先登录系统，这是系统的一个功能。但 是，这个功能只是预定图书这个完整的功能中的一个步骤，或者说一个了功能，就不适于做 成一个用例。另一方面，借

5、书和还书，都是相对完整的功能，如果把这两个用例合并成一个 类似于“处理图书”的用例，显然是不能明确的表达用例需要表达的含义的。描述用例需耍了解的是，使用UML行系统建模，并非只是意味il!li UML图形，对UML图 的文档说明是同样重要的。学习UML,不仅仅要学习UML图形，相应的文档描述方法也 同样要学习，也同样重要。在描述用例时，我们可以用文字来描述，也可以用其他图形来描述，例如，顺序图或者 活动图等等。下瓯给出了一个RUP中推荐的描述用例的完整的结构：名称。名称无疑应该表明用户的意图或用例的用途，如“研究班招生”。标识符可选。唯一标识符,如”UC1701”，在项目的其他元素（如类模型）

6、中可 用它来引用这个用例。说明。概述用例的几句话。参与者可选。与此用例相关的参与者列表。尽管这则信息包含在用例本身中，但 在没有用例图时，它有助于增加对该用例的理解状态冋选。指示用例的状态，通常为以下儿种z：进行中、等待审查、通过审 杳或未通过审查。频率，参与者访问此用例的频率。这是一个H由式问题，如用户毎次录访问一次或 每月一次。前置条件。一个条件列表，如果其中包含条件，则这些条件必须在访问用例Z前得 到满足。后置条件。一个条件列表，如果其中包含条件，则这些条件将在用例成功完成以后 得到满足。被扩展的用例可选。此用例所扩展的用例(如果存在)。扩展关联是一种广义关 系，其中扩展用例接续基用例的

7、行为。这是通过扩展用例向基用例的操作序列中插 入附加的操作序列来实现的。这总是使用带有extend的用例关联来建模的。被包含的用例可选。此用例所包含用例的列表。包含关联是一种广义关系，它表 明对处于另一个用例Z中的用例所描述的行为的包含关系。这总是使用带有 include的用例关联来建模的。也称为使用致具有(hasa)关系。假设冋选。对编写此用例时所创建的域的任何重要假设。您应该在一定的时候检 验这些假设，或者将它们变为决策的一部分，或者将它们添加到操作的基本流程或 可选流程中。基本操作流程。参与者在用例中所遵循的主逻辑路径。因为它描述了当各项工作都 正常进行时用例的工作方式，所以通常称其为适

8、当路径(happy path)吸主路径 (main path)。可选操作流程。用例中很少使用的逻辑路径，那些在变更工作方式、出现异常或发 生错课的情况下所遵循的路径。修改历史记录可选。关于用例的修改时间、修改原因和修改人的详细信息。问题可选。如果存在，则为与此用例的开发相关的问题或操作项目的列表。决策，关键决策的列表，这些决策通常由您的SME作出，并属于用例的内容。将 这些决策记录下来对于维护团体记忆库(group memory)是相当重要的。下面，我们对借书这个用例来做描述：名称：借书说明：学生在图书馆挑选好需要的图书后，通过图书管理员把书借冋去参与者：学生，图书管理员频率：每天可能会有很多

9、次。最繁忙的情况是，借书的人非常多，按照现在的速度，大 约每分钟完成一个人的结束工作前置条件：无后置条件：修改所借岀的图书的剩余数量假设：借书者总是从图书馆找到书，然后才能拿书办理借书手续，因此，总是有足够的 书可以出借基本操作流程：借书成功1) 学生将所借图书和借书证交给图书管理员2) 图书管理员将学生借书证号码和所借图书输入系统3) 系统校对借书信息，比对该学生以往借书情况和当前借书情况，如果不存在不 允许借书的情况，则记录借书交易的信息，并且修改相应的馆藏图书的数量信 息4) 如果该学生已经预订了这木图书，则撤销该预定5) 报告交易成功可选操作流程：所借图书超岀最大借书数量1) 学生将所

10、借图书和借书证交给图书管理员2）图书管理员将学生借书证号码和所借图书输入系统3）系统校对借书信息，比对该学生以往借书情况和当前借书情况，发现已超出最 大借书数量，则停止当前交易，并且提示用户错误原因4）图书管理员可以应学生的意见，减少借书数量，并重新提交系统流程活动图：见图一。V（显示借书界面）输入借书证屯码和所借图书/验证借书数量修改借书信息借书数量超出范I韦I通知用户借书数量在允许范围内图一：借书活动图问题：暂无。决策：略。上面，我们就这个用例做了一个比较详细的描述。按部就班，我们就可以逐步把敕个系 统的用例模型完成。再次强调一点，使用UML建模，文档说明和图形同样重要，并且，要使用UML

11、的方法来编写文档。分析模型一一开发者的视野在系统分析的过程中，我们所关注的依然是问题，但是，同用例模型不同的是，用例模 型是从最终用户的角度来看待问题，而分析模型是从开发者的角度来描述问题。用例模型的 主要丁作是描述现实世界的业务流程，而很少会涉及系统的概念。分析，则是从系统的角度 来来看待软件应该为用户提供的服务。同样，同设计不同的是，分析仍然停胡在“做什么” 的层次，。而设计，则需要解决“怎么做的问题”。开发语言等技术选择通常不会在分析模型中考虑。分析模樂是独立于实现的，这样，可 以提供最大的复用，并且，可以帮助开发人员方知过早的陷入技术的细节中去，从而能够从 一个更加一般的角度去理清思路

12、。进行分析建模的第一步，通常是识别对象，然后提取出类。考虑著名的MVC模式，我 们需要识别实体、控制和边界三种对象。按照MVC模式来为识别对象做指导，是非常好的 做法。对象识别的结果，就是我们所需要的静态模型，通常表现为类图。我们首先识别出实体对象，这些对象通常来说是比较明显的，例如系统中的角色，系统 需要处理的资料，如木系统中需要处理的图书资料等；有些实体对象需要稍微分析一下才能 得到，例如，在木系统中，为了记录图书借还的信息，我们可能需要一个对象來专门记录这 一信息。这些对彖就是所谓的Modal (实体类)。然后我们需要识别为了完成系统业务逻辑而需要的业务逻辑对象，以及同用户进行交互 的界

13、血类，在MVC模式中，他们分别对应于Control (控制类)和View(边界类)。在分析 阶段，这些对象通常祁按照比较白然的方式来组织，例如，为了完成一个业务功能，我们通 常需要一个控制类和一个边界类，控制类执行业务逻辑，边界类同客户进行交互。当然，这 不是绝对的，在进行进一步深入的分析后，这些类可能会被分解和合并。一口不能把所冇的饭都吃掉，系统分析也是这样。我们需要一个一个用例的来进行分析。 现在，我们首先来分析借书这个用例。在这个用例中，我们首先可以识别出一些肓接的对象，包括图书管理员(BookAdmin). 学生(Student).图书(Book),然后，稍作分析，我们会发现我们需要一

14、个实体对象來记录图 书的借还信a(BorrowInfo)o最示，我们发现，在借书的过程中，我们会使用到预定图书的 信息(SubscribHnfo)。到这一步，我们基木完成了实体对象的识别。然后，我们发现我们需 要一个借书的控制(Borrow)来执行借书的动作，以及一个用户界血(Borrowinterface)来 接受用户的输入。这样，初步的模型我们就可以建立了。图二：借书类图在分析模型中，我们也需要识别出类的一些属性和方法。同样的，为了避免过早的陷入 细节中，以及适应将来在设计时类的变化，在分析模型中，我们一般只把一些主要的属性和 方法标识出来。例如，对于Student类,我们只需要Name和

15、CardNo （借书证号）属性,对 于Book,我们只需要BooKID AllCount（书的总数）、CurrentCount（当前数量）等属性。现在, 我们为我们的类图添加上述属性，就可以得到下面的结果：StudentOName CoCardNo图书管理员(from Use Cast.)Borrowinterface mBorrowBorrowOCheckCanBorrowQBorrowinfoaBorrowTimeStudentOBookStibscribrlnfoBookDBookIDQAIICount ?CurrentCount图三：借书类图不过，把这些属性祁标上后，图形就比较难布置。因为文章版面的问题，在以后的文字 中，除非必要，一般会把属性都隐藏起來，这样，看起来会整洁一些。依样画葫芦，我们把还书、杏阅图书、预定图书、管理图书这些用例一并分析后，我们 就能够得到整个系统的静态分析模型。当然,我们随后需要对这个初步的模型作进一步的整理和分析，类图会发生变化，各个 类Z间会产生一些联系。我们也可能会使用一些分析模式，来进一步优化我们的分析结果。 关于分析模世的知识，叫以参见Martin Fowler所著的Analys