图书管理系统-领域分析阶段

图书管理系统实例—领域分析阶段（1）工作任务经理给出项目计划，各项目组按工作计划进入项目周期召开用户访谈会议获取用户需求，进行领域分析中的数据建模提交内容访谈提纲与访谈记录领域类图项目计划{领域分析{需求分析{设计编码测试验收标识号名称工期开始时间完成时间1领域分析4.d2009-10-198:002009-10-2217:002业务需求与数据模型分析1.d2009-10-198:002009-10-1917:003业务需求细化3.d2009-10-208:002009-10-2217:004需求分析6.d2009-10-238:002009-10-3017:005系统需求确定2.d2009-10-238:002009-10-2617:006用例规约3.d2009-10-278:002009-10-2917:007需求评审1.d2009-10-308:002009-10-3017:008系统设计7.d2009-11-28:002009-11-1017:009GUI设计1.d2009-11-28:002009-11-217:0010系统静态结构设计2.d2009-11-28:002009-11-317:0011系统动态结构设计4.d2009-11-48:002009-11-917:0012设计评审1.d2009-11-108:002009-11-1017:0013系统编码实现11.d2009-11-118:002009-11-2517:0014系统测试2.d2009-11-268:002009-11-2717:0015项目验收4.d2009-11-308:002009-12-317:00项目的任务分解图（WBS）阶段目标

通过用户访谈获取需求，形成需求陈述，并在此基础上完成领域分析，建立业务领域的数据模型。提交内容：访谈提纲与访谈记录领域类图、业务用例我们的进度，在这里阶段能力目标及对应工作任务能力目标工作任务1掌握用户访谈的基本技能1-用户访谈2掌握领域分析方法，能为简单项目进行领域建模2-建立领域类图3掌握Visio中类图的画法4掌握Visio中用例图和活动图的画法阶段知识目标访谈技巧类、关系类图用例图活动图Visio中类图、用例图、活动图画法数据建模业务用例建模、业务流程建模我们的进度，在这里工作任务2：

召开用户访谈会议，了解用户业务情况。

学习情境：知识1：如何进行用户访谈与用户进行访谈可以通过正式会议或者一般访谈的形式进行。在进行访谈前，业务员需要了解用户所在行业的一些背景情况和相关行业知识。无论何种访谈，在进行前都应该准备访谈提纲，在得到一些访谈信息后，要有针对性的设置访谈问题。我们的进度，在这里访谈提纲的编写技巧技巧一：如何发现用户业务需求通过一些问题，可以使得系统分析员获知系统某一功能执行步骤，所需或者产生的数据，计算公式，以及企业的特殊约束。例如：您（业务人员）通常都怎么执行某操作的呢？请告诉我执行这些步骤会用到什么数据？以及会产生什么数据？在执行某操作时，有没有什么重要的约束需要注意或遵守的？我们的进度，在这里访谈提纲的编写技巧技巧二：发现需要的数据及其属性在系统中，必不可少的会用到数据，那么系统中的数据及数据属性如何被发现呢？可以通过类似以下问题来进行访谈：某物会记录什么数据呢？某物可以提供我们哪些数据呢？某物的某属性有范围码？可被接受的数字，最大最小是多少？可被接受的字符串，最长最短是多少？我们的进度，在这里图书管理系统的第一次访谈提纲访谈对象：图书馆工作人员Q1：请问您平时主要有哪些工作要做呢？A1：我的日常工作包括图书管理（图书的入库，报废，遗失）、图书的借阅（包括借出图书和归还图书）、还有就是借阅管理（主要是为学生办理学生借阅证）。Q2：您在进行图书管理工作，比如图书入库的时候是怎样的流程？图书报废的时候又是怎样的，您能谈一下吗？A2：一般来讲，我们每学年都需要采集一些图书。当图书从采购部采集进来之后，我们为每本图书建立条码和图书信息，在每本书上粘贴条码，并登记图书信息到图书信息表。学校图书馆的图书很少报废，如果报废的话就需要在图书信息表中的备注栏登记一下。如果丢失的话，会在图书信息表中备注栏记录遗失情况。我们的进度，在这里图书管理系统的第一次访谈提纲Q2：我还想问一下您在进行学生办理图书证的时候是如何进行的。A2：就是按照学生的入学信息，办理一张卡片（当然需要学生交照片过来）。同时要在学生信息登记表里面记录他的情况。Q3:如果学生借阅证丢失，您是怎么处理的。A3：学生借阅证丢失了，他需要主动联系我们进行“遗失补办”。其实也很简单了，就是重新发一张卡片给他，然后在学生信息登记表里面重新登记他的信息。Q4:您刚才提到的“卡片”是不是就是借阅证？A4：是的Q5：您在新办和补办借阅证的时候，上面都写些什么呢？A5:借阅证编号，姓名，学号，班级。图书管理系统的第一次访谈提纲Q6：您刚才提到了一个叫做借阅证编号的东西，我想问一下，你们在办理学生借阅证的时候，都需要填写学生信息表里面哪些数据呢？A6：有姓名，学号，班级，专业，性别Q7：图书在入库的时候，你们在图书信息表里面要登记哪些内容啊？A7：图书登录号，书名，ISBN，图书类别，作者，出版社，出版日期，总页数，定价，图书分类Q8：下面谈一下您的另外一个工作任务——当学生借书和还书的时候又是什么样的吧？A8：学生出示他的借阅证，然后把书交给我登记就可以了。Q9：你都登记什么信息呢？A9：学生的姓名，学号，班级，图书登录号，图书名，ISBN。最重要的就是借阅时间。Q10:学生的借阅时间有没有限定？A10：有，三个月。我们鼓励学生多进行借阅，但是如果超过这个时间的话，我们就会通知辅导员让学生进行归还了。我们的进度，在这里图书管理系统的第一次访谈提纲访谈对象：图书馆负责人（项目委托者）Q1：刚才我们同工作人员进行了访谈，我们现在想问一下您关于系统的一些情况。这个系统开发出来之后，供谁使用呢？A1：就是工作人员来使用。Q2：你们一般有几个工作员会同时使用这个系统？A2：我们图书馆规模比较小，只有这么一个图书室，同一时刻最多一个工作员使用。Q3：你们图书馆藏书规模有多大？另外，你们学院有多少学生啊？是不是每个学生都有借书证？还是他们申请办理才会有？A3：图书馆藏书大概有六千册吧。学生一般有1500人，一般在学生入学的时候，我们会为主动按班级给每个学生办理借书证的，学生不用单独来申请。当然，要求学生离校办理手续的时候，也必须先到我们这里将借阅证和借阅的书籍归还后才能离校。Q4：你们有没有计划保存离校学生的信息？A4：这个，一般我们都不保存的。在现有的情况下，他们的借书证档案，也是在离校后，就交给档案室，他们处理了。Q5：你们学院的教职员工借书跟学生借书一样吗？又是怎么样的情况？A5：我们学院的教职员工有专门的图书馆，目前我们这个图书馆还没有负责教师的业务，可能以后随着图书馆规模的变化，会有教师业务的吧。这个现在还不确定。我们的进度，在这里图书管理系统的第一次访谈记录（节选）用户访谈结束后，要整理访谈的内容，形成访谈记录。图书管理系统的访谈记录如下：1.用户主要业务：图书管理，图书借阅\归还，借阅管理。其中，图书管理包括图书的入库和报废以及遗失。借阅管理包括学生借阅证的办理和补办。2.图书信息包括：图书登录号，书名，ISBN，图书类别，作者，出版社，出版日期，总页数，定价，图书分类3.学生信息包括：姓名，学号，班级，专业，性别4.借阅信息包括：借阅时间，应归还时间5.系统只有一个角色使用6.系统数据容量为：图书——10000左右，学生——2000左右我们的进度，在这里需要注意的是选择关键人物进行访谈。访谈的记录要条例清晰，真实有效。根据实际的情况，访谈可能会进行很多次，直到确实明确用户的需求。我们的进度，在这里我们的进度，在这里工作任务3：

内容——通过访谈进行需求获取后，根据需求获取信息，进行领域分析

交付——图书管理系统领域类图学习情境：

知识2：用类图进行图书管理系统数据建模

主要知识点：类关系我们的进度，在这里类类主要包含以下几个部分

（1）名称（Name）名称是每个类所必有的构成，用于和其他类相区分。

（2）属性（Attribute）类的一个组成部分描述了类所代表事物的属性

（3）操作（Operation）操作是对类的对象所能做的事务的抽象

我们的进度，在这里类的UML图示类在UML中由专门的图符表达，是分成3个分隔区的矩形,顶端为类的名字，中间存放类的属性、属性的类型和值，第3个分隔区放操作、操作的参数表和返回类型，如下图：在给出类的UML表示时，可以根据建模的实际情况来选择隐藏属性区或操作区，或者两者都隐藏。我们的进度，在这里类的名字每个类都必须有一个名字，用来区分其它的类。例：Flight，BankAccountUML约定：类名的首字母要大写，放在矩形的偏上部。如果类名是由两个单词组成，那么将两个单词合并，第二个单词首字母大写。正体字说明类是可被实例化的，斜体字说明类为抽象类。（人和神）我们的进度，在这里类的属性例：publicflightNumber：Integer；UML约定：单个单词的属性名小写。如果属性名是由多个单词组成，那么将多个单词合并，除了第一个单词外。其它单词首字母大写。属性的语法：可见性名称:类型=默认值[约束特性]可见性表示该属性对类外的元素是否可见。常用的有公有、受保护和私有三种。名称表示属性的名称，是一个字符串。类型定义属性的种类（基本类型或自定义类型）默认值表示属性的初始值。约束特性表示描述对属性的约束。我们的进度，在这里类的操作例：getArriveTime（）：DateUML约定：单个单词的操作名小写。如果操作名是由多个单词组成，那么将多个单词合并，除了第一个单词外。其它单词首字母大写。我们的进度，在这里图书管理系统的数据建模——

步骤1：对系统中关键词的抽象我们从与用户的访谈中间可以发现一些关键词汇：学生信息，图书信息，以及借阅信息。因此，可以在系统中抽象出3个类：学生，图书，借阅信息。我们的进度，在这里图书管理系统的数据建模——

步骤2：为类添加属性学生信息表包含：姓名，学号，班级，专业，性别图书信息表包含：图书登录号，书名，ISBN，图书类别，作者，出版社，出版日期，总页数，定价，图书分类借阅信息表包含：借阅时间,归还时间。我们的进度，在这里我们的进度，在这里图书管理系统的数据建模——

步骤3：分析和建立类之间的关系学生——借阅信息1：n图书——借阅信息1：n我们的进度，在这里我们的进度，在这里课程小结本次课中，用到以下知识用户访谈类的建模：类图我们的进度，在这里图书管理系统实例—领域分析阶段（2）工作任务根据访谈内容，进行业务用例建模根据访谈内容，进行业务流程的建模提交内容业务用例图业务流程活动图我们的进度，在这里我们的进度，在这里工作任务1：业务用例建模

交付的工作产品：业务用例图

学习情境

知识点1：业务用例建模1概述2参与者3用例4用例建模我们的进度，在这里1概述画好用例图（UseCaseDiagrams）是由软件需求到最终实现的第一步，在UML中用例图用于对系统、子系统或类的行为的可视化，以便使系统的用户更容易理解这些元素的用途，也便利软件开发人员最终实现这些元素。UML中的用例图描述了一组用例、参与者以及它们之间的关系，因此用例图包括以下3方面内容1）用例（UseCase）；

（2）参与者（Actor）；

（3）参与者之间的关系，泛化关系、包含关系、扩展关系等我们的进度，在这里2用例（UseCase）2.1用例的概念2.2识别用例2.3用例与事件流我们的进度，在这里2.1用例的概念用例是对一个系统或一个应用的一种单一的使用方式所作的描述，是关于单个活动者在与系统对话中所执行的处理行为的陈述序列。每个用例都必须有一个惟一的名字以区别于其他用例。图形上用例用一个椭圆来表示，用例的名字可以书写在椭圆的内部或下方。用例的UML图标如图所示。我们的进度，在这里2.2识别用例识别用例最好的办法就是从分析系统的参与者开始，考虑每个参与者是怎样使用系统。在识别用例的过程中，通过以下的几个问题可以帮助识别用例：（1）特定参与者希望系统提供什么功能；（2）当系统改变状态时，通知参与者吗；（3）存在影响系统的外部事件吗；（4）是哪个参与者通知系统这些事件。（5）系统是否存储和检索信息，如果是，这个行为由哪个参与者触发；我们的进度，在这里3参与者（Actor）参与者（Actor）是系统外部的一个实体（可以是任何的事物或人），它以某种方式参与了用例的执行过程。参与者通过向系统输入或请求系统输入某些事件来触发系统的执行。参与者由他们参与用例时所担当的角色来表示。UML中，参与者用“人形”图标来表示，名字写在图标的下方。我们的进度，在这里3参与者（Actor）参与者一般分为三种：系统用户其他系统可运行的进程3参与者（Actor）在获取用例前要先确定系统的参与者，可以根据以下的一些问题来寻找系统的参与者。（1）谁或什么使用该系统；（2）交互中，它们扮演什么角色；（3）谁安装系统；（4）谁启动和关闭系统；（5）谁维护系统；（6）与该系统交互的是什么系统；（7）谁从系统获取信息；（8）谁提供信息给系统；（9）有什么事发生在固定事件。系统的主要功能使用者系统的维护、管理人员系统的硬件设备对系统产生结果感兴趣的人或者其他系统3参与者（Actor）在建模参与者过程中，记住以下要点。（1）参与者对于系统而言总是外部的，因此它们在你的控制之外。（2）参与者直接同系统交互，这可以帮助定义系统边界。（3） 参与者表示人和事物与系统发生交互时所扮演的角色，而不是特定的人或特定的事物。（4）一个人或事物在与系统发生交互时，可以同时或不同时扮演多个角色。例如，某研究生担任某教授的助教，同职业的角度看，他扮演了两个角色——学生和助教。（5） 每一个参与者需要有一个具有业务一样的名字，在建模中，不推荐使用诸如NewActor这样的名字。（6）每个参与者必须有简短的描述，从业务角度描述参与者是什么。（7）像类一样，参与者可以具有分栏，表示参与者属性和它可接受的事件。一般情况下，这种分栏使用的并不多，很少显示在用例图中。我们的进度，在这里4用例间、用例与参与者的关系1.泛化关系（Generalization）：一个用例可以被特别列举为一个或多个子用例，这被称为用例泛化;(交易：证券交易，房产交易)2.包含关系（Include）一个用例可以简单地包含其他用例具有的行为，并把它所包含的用例行为作为自身行为的一部分，这被称作包含关系。（取款，存款：打印凭证）3.扩展关系（Extend）：一个用例也可以被定义为基础用例的增量扩展，这称作扩展关系，扩展关系是把新行为插入到已有用例的方法。（基本通话：呼叫等待，呼叫转移）4.关联关系：关联关系表示参与者与用例之间的通信。我们的进度，在这里4用例间、用例与参与者的关系四种关系的UML图释包含关系扩展关系泛化关系关联关系用例图建模技术5对语境建模6对需求建模我们的进度，在这里5对语境建模在UML建模过程中，可以使用用例图对系统的语境进行建模，强调系统外部的参与者。系统语境是由处于系统外部并且与系统进行交互的事物所构成。对系统语境建模可以参考如下方法。（1）识别系统外部的参与者（2）在需要加深理解的地方，为每个参与者提供一个构造型。（3）将参与者放到用例图中，并说明参与者与用例之间的通信路径。（4）将类似参与者组织成泛化的层次结构。6对需求建模软件需求就是根据用户对产品功能的期望，提出产品外部功能的描述。需求分析所要做的工作是获取系统的需求，归纳系统所要实现的功能，使最终的软件产品最大限度的贴近用户的要求。一般要考虑系统做什么（what），而尽可能的不去考虑怎么做（how）。UML用例图可以表达和管理系统大多数的功能需求。对系统功能建模可以参考如下方法：（1）识别系统外部的参与者，从而建立系统的语境；（2）考虑每一个参与者期望的行为或需要系统提供的行为；（3）把公共行为命名为用例；（4）确定供其他用例使用的用例和扩展其他用例的用例；（5）在用例图中对这些用例、参与者和它们间的关系建模；（6）用描述非功能需求的注释修饰用例图。我们的进度，在这里图书管理系统的业务用例建模现在我们要对图书管理系统进行业务用例建模。在上次进行的访谈中，我们得知：该系统只有一种使用者：图书馆工作人员，并且同一时刻只有一个工作人员使用该系统。图书馆工作人员，日常的业务主要有：图书管理，借阅管理和图书的借阅/归还。我们的进度，在这里根据以上访谈内容，我们识别出参与者——图书馆工作人员用例——图书管理、借阅管理和图书的借阅/归还我们的进度，在这里我们的进度，在这里注意：这个用例图是从用户业务的视角出发，用来进行业务用例建模的。在今后的需求分析阶段，我们会从系统的视角来进行系统用例建模。我们的进度，在这里工作任务2：业务流程建模

交付的工作产品——业务流程活动图

学习情境：

知识点2：活动图与业务流程建模通过UML中的活动图，可以帮助我们进行用户业务流程建模，帮助我们站在用户的视角上进行业务分析。在业务流程建模中，我们关注的是用户进行某项业务的执行步骤。我们的进度，在这里1活动图（ActivityDiagram）的概念和内容1.1活动图的内容1.2活动图的用途1.3活动图的建模技术我们的进度，在这里1.1活动图的内容活动图是UML中描述系统动态行为的图之一，它用于展现参与行为的类的活动或动作。UML中，图形上活动图里的活动用圆角矩形表示活动图的主要内容是：1.活动2.转换3.分支（Branch）4.分叉和汇合5.泳道6