第三章 UML类图.ppt

单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,第三章 类图,3.1,类图的概念,3.2 UML,中的类,3.3,类图中的关系,3.4,阅读类图,3.5,如何建立类图,3.6 Rose2003,类图操作,3.1,类图的概念,1,、类图,类图是描述类,、协作,(,类或对象间的协作,),、,接口及其关系的图。,类图是逻辑视图的重要组成部分，用于对系统的静态结构建模，涉及到具体的实现细节。,在系统分析阶段，类图主要用于显示角色和提供系统行为的实体的职责；,在系统设计阶段，类图主要用于捕捉组成系统体系结构的类结构；,在系统编码阶段，根据类图中的类及它们之间的关系实现系统的功能。,3.1,类图的概念,图,3-1,电子商务网站的对象模型,3.1,类图的概念,2,、类图的作用,类图常用来描述业务或软件系统的组成,、,结构和关系。,3,、类图的组成元素,类,接口,协作,关系,注释,约束,包,3.2 UML,中的类,、类的表示,（）类的定义,类是具有相似结构、行为和关系的一组对象的描述符。,（）类的表示,3.2 UML,中的类,（）类的命名,由字符、数字、下划线组成的惟一的字符串；,采用,CamelCase,格式（大写字母开头，混合大小写，每个单词一大写开始，避免使用特殊符号）,类名的两种表示方法,简单名,Order,路径名,java:awt:Rectanget,businessRule:Order,3.2 UML,中的类,（）类的属性,属性描述了类的静态特征；,属性名的第一个字母小写；,属性的定义格式,可见性,属性名,:,类型,多重性,次序,=,初始值,特性,说明：可见性包括,+,、,-,、,#,、,例：,#,visibility:Boolean,=false,colors:Color3,points:Point2.*ordered,name:String0.1,3.2 UML,中的类,（）类的操作,操作名的命名规范习惯采用和属性名相同的命名规则。,类的操作的定义格式,可见性,操作名,(,参数列表,):,返回类型,特性,例：,+,hide():Boolean,#create(),-,attachXWindow(xwin:XwindowPtr,),3.2 UML,中的类,（）类的职责,职责指类承担的责任和义务。在矩形框中最后一栏中写明类的职责。,Washing Machine,Brand name,Model name,Serial number,Capacity,Add clothes(),Add detergent(),Remove clothes(),Take dirty clothes as input and produce clean clothes as output,3.2 UML,中的类,（）类的约束,约束指定了类所要满足的一个或多个规则。在,UML,中，约束是用花括号括起来的自由文本。,Washing Machine,Brand name,Model name,Serial number,Capacity,Add clothes(),Add detergent(),Remove clothes(),capacity=16 or 18 or 20 lb,3.2 UML,中的类,2,、类的种类,（,1,）抽象类,当某些类有一些共性的方法或属性时，可以定义一个抽象类来抽取这些共性，然后将包含这些共性方法和属性的,具体类作为该抽象类的继承,；,抽象类是一种不能直接实例化的类，,不能用抽象类创建对象,；,抽象类,可以实现多态,；,3.2 UML,中的类,（,1,）抽象类,在,UML,中，,抽象类和抽象方法的表示是将其名字用,斜体,表示,。,3.2 UML,中的类,（）接口,接口是一种类似于抽象类的机制，是一个没有具体实现的类。,接口,可以实现多态,；,在,UML,中接口有两种表示方法：,Interface,图标表示法,Collection,构造符号表示法,3.2 UML,中的类,（,3,）关联类,当两个类之间具有多对多的关系，并且有些属性不属于关联两端任何一个类；,关联类通过一条虚线和对应的关联连接；,3.2 UML,中的类,（,4,）主动类,主动类的实例称为主动对象，一个主动对象拥有一个控制线程并且能够发起控制活动；具有独立的控制期。,从某种意义上说，它就是一个线程。,在,UML2.0,中，主动类的表示方法为：在类的两边加上垂直线。,3.2 UML,中的类,（,5,）嵌套类,将一个类的定义放在另一个类定义的内部，这就是嵌套类。,在,UML,中，可以采用一个锚图标来表示这种关系,3.3,类图中的关系,按照关系的性质分为,4,种：,关联,1,、包含,2,、泛化,3,、依赖,4,、实现,关联,association,关联是模型元素间的一种语义联系，当类之间在概念上有连接关系时，类之间的连接叫做关联。,队员和球队之间的关联，可以用短语“队员为篮球队效力”来刻画，图形表示为：,Class1,Class2,association name,rolename1,rolename2,multiplicity1,multiplicity2,关联,关联有名称、角色、多重性和导航性等语法。,（,1,）关联名,描述关联的作用；,通常使用动词或动词短语；,关联,（,2,）角色,关联两端的类可以某种角色参与关联；,通常使用名词或名词短语；,关联,（,3,）多重性,某个类有多少个对象可以和另一个类的单个对象关联；,关联,关于,多重性,（,3,）多重性,在,UML,中，常用的关联的多重性表示格式如下：,0.1 0,或,1,1 1,0.*,（,0.n,）,0,或多个,*,0,或多个,1.*,（,1.n,）,1或多个,8 8,5,，,7.10 5,或,710,关联,当类,A,和类,B,之间是一对零或一（,one-to-zero or one,）,多重性是，就说明类,B,对类,A,是可选的（,optional,）,（,4,）导航性,用箭头显示导航性；,描述源对象通过链接访问目标对象；,A,类有一个成员变量保存的是,B,类的一个引用，也就是说由,A,类可以找到,B,类，可以画成下图所示,关联,（,5,）关联的约束,关联可加上一些约束，以加强关联的含义；,关联,关联,（,5,）关联的约束,一个,BankTeller,为顾客服务，但是服务的顺序要按照顾客排队的次序进行。在模型中可以通过在,Customer类附近加上一个花括号括起来的“,ordered,（有序）”来说明这个规则，也就是指明约束。,另一种类型的约束是,OR,关系，图中标明高中生（,high school student,）选（,choose,）专业课（,academic,），或者选商务课（,commercial,）时的模型。,（,6,）限定符,在关联端紧靠源类图标处可有限定符，带有限定符的关联称为,限定关联,。,限定符的作用：用于将一个多（或一）对多关联转化为一个多（或一）对一关联。,限定符是关联的属性,，而不是类的属性。,关联,（,6,）限定符,关联,（,7,）关联的种类,自返关联,二元关联,(,前述,),N,元关联,关联,1包含关系,一辆汽车有,4,个轮子，我们可以这样表示,你可能觉得这样表示还不太合适，汽车应该包含,4,个轮子，或者说轮子本来就属于汽车的一部分，那怎样画能更加贴切表示这样的关系呢？我们可以这样画：,聚合,组合,聚合,-,Aggregation,类之间的一种整体与部分的关系,体现了一种层次结构，整体类位于部分类的上层，多个部分类处于并列的层次,组合,-,Composition,是一种特殊形式的聚合（强聚合），聚合中的每个部分只能属于一个整体；,表示类之间整体和部分的关系。,整体与部分具有相同的生存期。,关于聚合与组合,“弱”包含表示如果部门没有了，员工也可以继续存在；,“强”包含表示如果部门没有了，员工也不再存在。,在做软件需求时，往往会将所有的包含关系画成“弱”包含，后面发现某些关系可以表示为“强”包含是，才转为实心菱形。,关于聚合与组合,2,、泛化,-,Generalization,表示两个类元间,“,一般,”,与,“,特殊,”,的关系。,对应面向对象编程语言中类与类之间的,继承关系,。,“,is a kind of”,关系，,XX,是一种,XX,Athlete,Swimmer,Golfer,3,、实现,-,Realization,表达一种,说明元素,与,实现元素,之间的关系；,类和接口之间的关系是实现关系，表示类实现接口提供的操作,显示一个类引用另一个类,4,、依赖,-,Dependency,软件开发中，往往会设计一些公用类，供别的类调用，如果这些公用类出问题了，那调用这些公用类的类都会因此而出问题。,两个元素之间的一种关系，其中一个元素（提供者,),的变化将影响另一个元素（客体,),，或向它提供所需信息,显示一个类引用另一个类,你很爱你老婆，没有你老婆你活不下去，可以这样表示,如果一个烟鬼嗜烟如命，用类图可以这样表示：,关于依赖,假设你正在设计一个能显示公司全体成员的制表系统，公司的员工可以填写这个系统中的电子表格。员工要选择菜单来填写表格。在你的设计中，有一个,Syetem,（系统）类和一个,Form,（表格）类。,System,类的众多操作中有一个,displayForm,（,f:Form,），系统所要显示的表格取决于用户选择的表格。,这种设计的,UML,表示法可以画成如下,4,、依赖分类,依赖关系可以分为以下四类：,1,）使用依赖（,Usage,）,2,）抽象依赖（,Abstraction,）,3,）授权依赖（,Permission,）,4,）绑定依赖（,Binding,）,（,1,）使用依赖,表示客户使用提供者提供的服务以实现它的行为，包括：,使用,-,声明使用一个类时需要用到已存在的另一个类。,调用,-,声明一个类调用其他类的操作的方法。,参数,-,声明一个操作和它的参数之间的关系。,发送,-,声明信号发送者和信号接收者之间的关系,。,实例化,-,声明用一个类的方法创建了另一个类的实例。,（,2,）抽象依赖,表示客户与提供者之间用不同的方法表现同一个概念，通常一个概念更抽象，一个概念更具体。包括：,跟踪,-,声明不同模型中的元素之间存在一些连接但不如映射精确,。,精化,-,声明具有两个不同语义层次上的元素之间的映射。,派生,-,声明一个实例可以从另一个实例导出。,（,3,）授权依赖,表达提供者为客户提供某种权限以访问其内容的情形。包括：,访问,-,允许一个包访问另一个包的内容,。,导入,-,允许一个包访问另一个包的内容并为被访问包的组成部分增加别名。,友元,-,允许一个元素访问另一个元素，不管被访问的元素是否具有可见性。,（,4绑定依赖,较高级的依赖类型，用于绑定模板以创建新的模型元素，包括：,绑定,-,为模板参数指定值，以生成一个新的模型元素。,几个练习题,题目,1,：用类图表达出你和你的另外一半的所有关系。,你结婚了吗？如果你已婚，请用类图描绘你和你的另外一半的关系,如果你是单身，你有男朋友或女朋友吗？有的话，请用类图画出你们俩人的关系,如果你还没有另外一半，请你虚拟一位你的意中人，用类图画出你和你的虚拟意中人的关系。,如果你还没有到恋爱或结婚年龄，那么你不需要完成这个练习，直接看后面的参考答案。,题目,1,：,对于已婚的，如果你是男生，在这个关系中的角色就是老公，一个老公只能对应一个老婆，你应该不会画成,1对多吧？,如果你未婚，但你同时有多个男朋友或者女朋友，那么你们的关系可以这样表示,不要因为你能,1,对多个男朋友（或女朋友）就很开心，这是一种很不好的关系，强烈建议你将,1,对多的关系变为,1,对,1,，而且说不定有朝一日你会被别人,1,对多,题目,1,：,如果你还没有另一半，你的另一半是作为“虚拟情人”存在的，你可以画成这样,如果你很爱你的另一半，没有她（他）你简直不能活，她（他）是你的生存必需品，你可以画成这样,题目,2,：请用类图描述公司与雇员的关系。,这个图表示公司“包含”多名员工，而公司这边也是一个“*”号，这表示一名雇员可受雇于多个公司，事实上很多公司是禁止员工同时受雇于另外一个公司或者兼职，这样公司这边就不能画“*”号。,类图描述公司与雇员的关系,这里的包含是弱包含，能不能画成强包含呢？公司如果不存在了，雇员还存在吗？,一个公司没有了，这个公司应该就不会有任何雇员，但不代表原来的雇员都消失了，他们还是存在的，这个问题就比较纠结了，到底是强包含还是弱包含，每个人的标准可能不一样，不建议在弱包含还是强包含上过于纠结，在需求分析是绝大部分情况只会用弱包含，强包含只会在很明显的情况下采用。,题目,3,：用类图画出香蕉、苹果、梨子的关系,你可能觉得有点“无厘头”，这三种水果能有怎样的关系呢？,类图画出香蕉、苹果、梨子的关系,图中表示香蕉、苹果、梨子都是水果的一种，用专业有点的说法就是香蕉、苹果、梨子泛化为水果。泛化后的类，有可能是一种经过“抽象”后的东西，这个东西看不到摸不着，是我们脑袋里面提炼出来的一种概念。,香蕉、苹果、梨子泛化为水果，水果可以在泛化为食物，食物又可以进一步泛化。有没有必要不断的泛化呢？泛化到怎样的程度才是合适的呢？一般说来，如果有,A,、,B,、,C,等两个或以上的业务概念，我们发现它们有一些共同的特征，则可以考虑将它们泛化为另外一个东西，这样能帮助我们发现事物的本质；但如果只有一个,A,时，就没有必要对,A,在进行泛化。,题目,4,：请用类图描述公司的组织架构，该公司有一个行政人事部、一个研发部、一个服务部、一个销售部、一个财务部。,这个图似乎公司有多少个部门，多画一个包含就搞定了，这样画似乎一点都显示不出类图的优势。,抽象部门用斜体，表明这个类是抽象类，抽象类表示这个类是提炼出来的一种概念，是不具体存在的。,这个组织架构图已经一定程度地揭示了公司组织架构的本质，一个公司无非就是由一个个部门组成的，只是每个具体的部门可能不一样而已。这样的表达效果，用普通的组织架构图是表达不出来的，而类图就可以发挥抽象和提炼的优势。,这个图将更进一步揭示公司组织构架的本质,实施部是负责将软件系统安装到客户现场，保障系统上线运行的部门,IT,部主要负责两方面的智能，一方面要保障公司内部的办公软硬件环境，另一方面，会承接一些外部的网络工程，为公司直接盈利。第一方面的工作是属于支持类方面的工作，而第二方面的工作则是生产类的工作。,质量部负责测试和过程保障的工作，这个部门是支援研发部和实施部工作的，故也属于支持类的部门。,公司有一个个部门构成，这些部门分为,3,类,市场类部门：负责公司市场推广、产品营销方面的部门,生产类部门：直接生产公司产品的部门,支持类部门：不直接生产公司产品，但支持产品生产或支撑公司运作必不可少的部门,将部门分为市场类、生产类和支持类，只是其中一种抽象方法，每个人可能会有不同的标准，遇到不同情况会不同的抽象方法，这仅仅是一个例子，千万不要将其当成一个固定的标准。,试画出中北大学的组织构架图,老张开车去东北,神州飞船,根据以下描述，画出相应的,UML,类图,神舟六号飞船是神州飞船系列的一种，它由轨道舱、返回舱、推进舱和逃逸救生塔等组成。,航天员可以在返回舱内驾驶飞船，轨道舱是航天员工作和休息的场所。在紧急的情况下，颗粒利用逃逸救生塔逃生。,在飞船两侧有多个太阳能电池翼，可以为飞船提供电能,神州飞船,递归关系,如果面试的人说懂类图，公司,100%,会问这样一个问题,Windows,操作系统中有文件夹和文件，请用类图表达出文件夹和文件的关系。,接着又会被问到：,文件夹里也可以有文件夹呀，这个怎样表示？,里面的文件夹里面也可能有文件夹，咋办？,递归关系,这个包含关系可以指向自己，可以“自包含”，这个无穷递归问题就解决了。,这种“递归”结构一旦展开就会形成一个树形结构，需求分析时，如果发现树形的业务结构，可以考虑使用“自包含”或者“自关联”来分析。,三角关系,公司和雇员的关系，要求列出公司和雇员至少,3,个关键属性,思考如下问题,1,、薪金是雇员的关键属性吗？合同期、职位呢？,2,、公司和雇员，这两者的关系在法律上是如何确立的,公司与雇员要签署劳动合同，劳动合同上会有薪金、合同期、职位这些重要的内容，那么薪金、合同期、职位算是雇员的属性吗？,在表示公司与雇员的关系的直线上，拉出一条虚线，虚线另一端连接劳动合同类，这样的类叫做关联类，关联类是对两个类的关系的进一步约束。,最开始你可能会认为薪金、职位、合同期似乎应该是雇员的属性，但现在应该认识到，这三个关键内容应该体现在公司和雇员的关系上，这些内容应该体现在劳动合同上。,公司、雇员、劳动合同的关系，还可以画成这样,这个图最能体现“三角”关系了，关联类也可以表达成这样的方式。但实际工作还是以关联类的方式来表达，关联类的表达方式更加贴切和专业一点。,在需求分析时，发现三个类形成了类似的“三角”关系，可以思考其中一个类是不是可能为关联类，但并不是所有的“三角”关系就一定会有关联类,将薪金、职位、合同期这些信息直接当成雇员的属性也不是不可以的，这跟我们做系统的目标有关系，如果只是做简单的员工信息管理，可能就没有必要将合同提炼出来，如果要做一个人事管理系统，就需要我们将业务模型分析的更加透彻。,关联类这样复杂的东西，客户是不大可能直接告诉你的，在需求分析中发现和提炼出关联类，这对需求的理解以及项目后期的设计将会有很大的帮助。,识别关联类,关于画类图,直线、几对几的关系、角色、箭头可以搭配使用，只要能准确反映出业务关系就可以了。,做软件需求分析时，如果觉得两个业务概念之间有联系，但暂时不能确定具体是怎样的，那么就先画一条线将两者连起来再说，随着你对业务的理解，这条线会进一步具体化，你可以为这条线添加更多的元素。,完,3.4,阅读类图,1,、电子商务网站业务描述,3.4,阅读类图,2,、阅读顺序应遵循的原则,先看清有哪些,类；,然后看看类之间存在的,关系；,结合,多重性,来理解类图的结构特点以及各个属性和方法的含义,读图过程,读出类：,读出关系：从图中关系最复杂（也就是线最密集）的类开始阅读，本图中最复杂的就是,Order,类。,1,）,OrderItem,和,Order,之间是组合关系，根据箭头的方向可知,Order,包含了,OrderItem,。,2,）,Order,类和,Customer,、,Consignee,、,DeliverOrder,是关联关系。也就是说，一个订单和客户、收货人、送货单是相关的。,读图过程,多重性：用来说明关联的两个类之间的数量关系,源类及多重性,目标类及多重性,分析,Customer(1),Order(0,n),订单是属于某个客户的，网站的客户可以有,0,个或多个订单,Order(1),Consignee(1),每个订单只能够有一个收货人,Order(1),OrderItem(1,n),订单是由订单项组成的，至少要有一个订单项，最多可以有,n,个,Order(1),DeliverOrder(1,n),一个订单有一个或多个送货单,说明：系统根据订单项的产品所属的商户，将其分发给商户，拆成了多个送货单！,DeliverOrder(1),OrderItem(1,n),一张送货单对应订单中的一到多个订单项,DeliverOrder(1),Consignee(1),每张送货单都对应着一个收货人,Peddlery(1),DeliverOrder(0,n),每个商户可以有相关的,0,个或多个送货单,OrderItem(1),Product(1),每个订单项中都包含着唯一的一个产品,Peddlery(1),Prodcut(0,n),产品是属于某个商户的，可以注册,0,到多个产品,读图过程,理解方法与图,Order,类，有两个方法：,dispatch(),和,close(),，从名字中可以猜出它们分别实现“分拆订单生成送货单”和“完成订单”。而在,DeliveOrder,(),类中则有一个,Close(),方法，同理它应该表示“完成送货”。而在,OrderItem,中有一个,stateChange,(),方法和,deliverState,，不难猜出它就是用来改变其“是否交给收货人”标志位的,先调用,Order,的,dispatch(),方法，它将根据其包含的,OrderItem,中产品信息，来按供应商户分拆成若干个,DeliverOrder,。商户登录系统后就可以获取其,DeliverOrder,，并在执行完后调用,close(),方法。这时，就将调用,OrderItem,的,stateChange,(),方法来改为其状态。同时再调用,Order,的,close(),方法，判断该,Order,的所有的,OrderItem,是否都已经送到了，如果是就将其真正,close(),使用了更多辅助建模元素的类图,增强的辅助建模元素,导航箭头：类的实例之间只能沿着导航箭头的方向传递，在,Order,中可以获取其相应的,Consignee,，而从,Consignee,中是无法了解与其相关的,Order,的,角色名称：,Customer,端有一个“,+Owner”,字符串，这表示,Customer,扮演的角色是,Owner,，也能对关联进行命名,导出属性：是指可以根据其他值计算出来的特性，这种属性应在其名称前加上一个“,/”,符号。,限定符：在,Order,和,OrderItem,之间的组合关系中，,OrderItem,这端多了一个方框，里面写着“,ProductId,”,。它在,UML,中称为限定符，存在限定符的关联称为受限关联。它用来表示某种限定关系。在本例中，它的用途是说明：对于一张订单，每一种产品只能用一个订单项,约束：用来说明规则，,xor,职责：在类的属性栏中添加注释行表示，或增加了一个新的分栏,增强的辅助建模元素,3.5,如何建立类图,1,、类图的抽象层次,概念类,描述应用领域中的概念，仅包含类名，不考虑细节。,分析类,分析不针对具体语言，包含一些类的细节特性。,设计类,针对具体的语言，考虑类的实现细节。,3.5,如何建立类图,2,、建立类图的步骤,分析问题域，确定需求；,寻找类，确定类的含义和职责；,定义类的属性和操作；,确定类之间的关系；,精化类和类间的关系；,绘制类图。,3.5,如何建立类图,3,、寻找类的方法,使用名词,/,动词寻找类：,收集相关信息,补充的需求规格说明,用例,项目说明文档,其他文档,分析信息,名词、名词短语,类或属性,动词、动词短语,操作,3.5,如何建立类图,3,、寻找类的方法,使用,CRC,分析法寻找类：,C-class,（类）,R-responsibility,（职责）,C-collaboration,（协作）,CRC,分析法是根据类所要扮演的职责来确定类。,3.5,如何建立类图,3,、寻找类的方法,根据边界类、控制类、实体类帮助分析系统中的类：,UML,中类有三种主要的版型：边界类、控制类和实体类。,边界类：位于系统与外界的交界处。如：窗体、对话框、报表、以及表示通讯协议的类、直接与外部设备交互的类。,3.5,如何建立类图,3,、寻找类的方法,根据边界类、控制类、实体类帮助分析系统中的类：,UML,中类有三种主要的版型：边界类、控制类和实体类。,实体类：保存要放进持久存储体的信息。持久存储体就是数据库、文件等可以永久存储数据的介质。通常每个实体类在数据库中有相应的表，实体类中的属性对应数据库表中的字段。,3.5,如何建立类图,3,、寻找类的方法,根据边界类、控制类、实体类帮助分析系统中的类：,UML,中类有三种主要的版型：边界类、控制类和实体类。,控制类：是控制其他类工作的类。,需求描述,李小平是一个爱书之人，家里各类书籍已过千册，而平时又时常有朋友外借，因此需要一个个人图书管理系统。该系统应该能够将书籍的基本信息按计算机类、非计算机类分别建档，实现按书名、作者、类别、出版社等关键字的组合查询功能。在使用该系统录入新书籍时系统会自动按规则生成书号，可以修改信息，但一经创建就不允许删除。该系统还应该能够对书籍的外借情况进行记录，可对外借情况列表打印。另外，还希望能够对书籍的购买金额、册数按特定时间周期进行统计。,发现类,李小平,是一个爱书之,人,，,家里,各类,书籍,已过千册，而平时又时常有,朋友,外借，因此需要一个,个人图书管理系统,。该系统应该能够将书籍的,基本信息,按,计算机类,、,非计算机类,分别建档，实现按,书名,、,作者,、,类别,、,出版社,等,关键字,的组合查询,功能,。在使用该系统录入,新书籍,时,系统,会自动按,规则,生成,书号,，可以修改,信息,，但一经创建就不允许删除。该系统还应该能够对书籍的外借情况进行,记录,，可对,外借情况列表,打印。另外，还希望能够对书籍的,购买金额,、,册数,按,特定时间周期,进行统计。,筛选备选类,“,李小平”、“人”、“家里”很明显是系统外的概念，无须对其建模；,而“个人图书管理系统”、“系统”指的就是将要开发的系统，即系统本身，也无须对其进行建模；,很明显“书籍”是一个很重要的类，而“书名”、“作者”、“类别”、“出版社”、“书号”则都是用来描述书籍的基本信息的，因此应该作为“书籍”类的属性处理，而“规则”是指书号的生成规则，而书号则是书籍的一个属性，因此“规则”可以作为编写“书籍”类构造函数的指南。,“基本信息”则是书名、作者、类别等描述书籍的基本信息统称，“关键字”则是代表其中之一，因此无需对其建模；,“功能”、“新书籍”、“信息”、“记录”都是在描述需求时使用到的一些相关词语，并不是问题域的本质，因此先可以将其淘汰掉；,筛选修选类,“,计算机类”、“非计算机类”是该系统中图书的两大分类，因此应该对其建模，并改名为“计算机类书籍”和“非计算机类书籍”，以减少歧义；,“外借情况”则是用来表示一次借阅行为，应该成为一个候选类，多个外借情况将组成“外借情况列表”，而外借情况中一个很重要的角色是“朋友”,借阅主体。虽然到本系统中并不需要建立“朋友”的资料库，但考虑到可能会需要列出某个朋友的借阅情况，因此还是将其列为候选类。为了能够更好地表述，将“外借情况”改名为“借阅记录”，而将“外借情况列表”改名为“借阅记录列表”；,“购买金额”、“册数”都是统计的结果，都是一个数字，因此不用将其建模，而“特定时限”则是统计的范围，也无需将其建模；不过从这里的分析中，我们可以发现，在该需求描述中隐藏着一个关键类,书籍列表，也就是执行统计的主体。,得到候选类,在使用“名词动词法”寻找类的时候，很多团队会在此耗费大量的时间，特别是对于中大型项目，这样很容易迷失方向。其实在此主要的目的是对问题领域建立概要的了解，无需太过咬文嚼字,书籍 计算机类书籍 非计算机类书籍,借阅记录 借阅记录列表 书籍列表,关联分析，建模,多重性分析，再建模,职责分析,书籍类：从需求描述中，可找到,书名、类别、作者、出版社,；同时从统计的需要中，可得知“,定价,”也是一个关键的成员变量。,书籍列表类：书籍列表就是全部的藏书列表，其主要的成员方法是新增、修改、查询（按关键字查询）、统计（按特定时限统计册数与金额）。,借阅记录类：借阅人（朋友）、借阅时间。,借阅记录列表类：主要职责就是添加记录（借出）、删除记录（归还）以及打印借阅记录,限定与修改,导航性分析：,Book,与,BookList,之间、,BorrowRecord,和,BorrowList,之间是组合关系均无需添加方向描述，而,Book,与,BorrowRecord,之间则是双方关联，也无需添加。,约束：,Book,对象创建后就不能够被删除只能被修改，因此在,Book,类边上加上用自由文本写的约束；一本书要么属于计算机类，要么属于非计算机类，因此在,ItBook,和,OtherBook,间加了“,Xor,”,约束。,限定符：一本书只有一册，因此只能够被借一次，因此对于一本,Book,而言只能有一个,RecordId,与其对应。,思考与练习,1,、读图：要求按照,3.4.2(P39),步骤,2,、画类图：一个教室有多张桌子，每一张桌子对应一排椅子，一排椅子可以做两个人。,3,、画类图：一个文件夹由多个文件或文件夹组成，文件有加密和无加密的。,思考与练习,实例：建模类图,思考与练习,