资源描述：
《《类图对象包图》PPT课件》由会员上传分享，免费在线阅读，更多相关内容在教育资源-天天文库。
第五章类图、对象图、包图计算机科学学院董兆安 内容提要类图由类以及类之间的关系组成。类图是所有面向对象建模方法的核心部分。类图描述了系统的静态结构。类可以表示程序设计中的一个类型。也可以表示现实世界的一类事物或概念。信息系统开发的各个阶段都要使用UML中的类图。在系统开发的不同阶段，类图表示了不同层次的抽象。概念层（Conceptual）：在需求分析阶段，类图主要用于领域内的一些概念类的描述，形成概念模型；规格说明层：（Specification）：在设计阶段，类图着重描述类与类之间的接口等外部特性，形成设计模型；实现层（Implementation）：在实现阶段，类图主要用于描述类的在软件系统中的内部实现。Page2 Classifiers(类目、分类器)Aclassifierisamechanismthatdescribesstructuralandbehavioralfeatures.Classifiersincludeclasses,associations,interfaces,datatypes,signals,components,nodes,usecases,andsubsystems.Page3 类（Classes）Aclassisacollectionofthingsorconceptsthathavethesamecharacteristics.Eachofthesethingsorconceptsiscalledanobject.类是具有相同特征（属性）和行为（方法）的对象的集合。aclassdescribesagroupofobjectswith:similarproperties(attributes)commonbehavior(operation,method)commonrelationshipstootherobjectscommonmeaningclassdiagramsshowclasseswiththeirattributesandoperations,togetherwiththeassociationsbetweenclassesPage4 describingaclassThelevelofdetailyouchoosetoshowforyourclassesdependsonwhoisreadingthediagramsonwhichtheyappear.Forexample,astakeholderwho'sfocusedonthe"bigpicture"isprobablyinterestedonlyinthenamesoftheclasses,whileadeveloperworkingatamoredetailedlevelprobablywantstoseeafullsetofattributesandoperations.Page5 简化表示（IconNotation）Somemodel'srepresentationscanbeswitchedbetweenIconNotationandClassNotation.Page6 类的名称（Classnames）UML中的名称是标识某个模型元素的字符串。简单名(simplename)：字母、数字和下划线的序列，通常以字母开始。复合名(pathname)：以分隔符分开的一个或者多个简单名的组合序列。例如：java::awt::Rectangle;java::util::Date复合名称中的最后一个一般指某个实体，如：类或者用例。虽然UML具有非常宽松的命名规定，许多标点都可以使用。但是为了避免混乱，我们还是建议采用简单名称的命名约定，尽量使用字母、数字、下划线构成字符串的命名方式。在分析和设计的不同阶段，类的图符可以使用恰当的精简方式，省略一些细节，甚至属性、方法两个要素都可省略。但是类的名称是三个要素中，必须具备的要素，不可以省略。Page7 属性attributeThefullformofaUMLattributedeclarationisasfollows:[visibility]name[:type][multiplicity][=default-value][{property-string}]visibilityNametypemultiplicitydefault-valueproperty-string+(public),#(protected),-(private)e.g.CustomerName,DiscountRatee.g.Point,String,Date,etc.e.g.[0..1],[2..*]e.g.=(0,0),=nullchangeable(default),addOnly,frozen6examplesoflegalattributedeclarationsoriginorigin:Point=(0,0)+originid:integer{frozen}origin:Pointname:[0..1]:StringPage8 可见性visibility：TheUMLsupportsthefollowingfourlevelsofvisibility:Packagevisibility(shownwithatilde[~])meansthatobjectsbelongingtoanyclassinthesamepackagecanseeandusethegivenclassit.Publicvisibility(+)meansthatobjectsbelongingtoanyclasscanusethegivenattributeoroperation.Protectedvisibility(#)meansthatonlyobjectsthatbelongtosubclassesofthegivenclass(atanylevelbelowthatclass)canusetheattributeoroperation.(SubclassesarediscussedinChapter2.)Privatevisibility(-)meansthatonlyobjectsbelongingtotheclassitselfcanusetheattributeoroperation.Page9 visibilityWhenyouspecifythevisibilityofaclassifier'sfeatures,yougenerallywanttohideallitsimplementationdetailsandexposeonlythosefeaturesthatarenecessarytocarryouttheresponsibilitiesoftheabstraction.That'stheverybasisofinformationhiding.Page10 属性的类型type：Examplesofbuilt-inattributedatatypesincludeDouble,Int(shortforInteger),andString.Anattributetypecanalsobeauser-definedtypeorthenameofaclass.Page11 多重性（Multiplicity）Multiplicityindicateshowmanyofonethingcanexistrelativetoanotherthing.Amultiplicityvalueonanattributeindicateshowmanyinstancesofthatattributearepresentforeachinstanceoftheclass.Amultiplicityexpressioncantakeseveralforms,includingthefollowing:Afixedvalue(suchas1or3)Anasterisk(*),whichmeans"many"Arangeofvalues,expressedaslower..upper(forinstance,0..1or3..*)Asetofvalues(forexample,[1,3,5,7])Page12 anexampleAnobjectbelongingtotheAccountclasscanhavefromonetothreeemailaddresses.EachAccountobjecthasanIDthatcan'tbedeleted;youmightthinkofthisasbeingtheequivalentofthekeywithinadatabasetable.And,there'saninitialvalueforanAccountobject'spassword,whichtheCustomerislikelytochangebutwhichisusefulincasetheCustomerforgetstodefineapasswordwhenheorshesetsupanAccount.Page13 operationsignatures操作签名ThefullformofaUMLoperationdeclarationisasfollows:[visibility]name[(parameter-list)][:return-type]Theparametersofanoperation,whichappearinalistseparatedbycommas,representthedataprovidedbythecalleroftheoperation,thedatathattheoperationreturnstothecaller,orboth.visibilitynameparameter-listreturn-type+(public),#(protected),-(private)e.g.restart,addStudentseenextpagee.g.Integer,String,etcPage14 parameterdeclaration参数声明Thefullformofaparameterdeclarationisasfollows:[direction]name:type[multiplicity][=default-value]Aparametercanhaveoneofthefollowingthreedirections:in(Theoperationcan'tmodifytheparameter,sothecallerdoesn'tneedtoseeitagain.)out(Theoperationsetsorchangesthevalueoftheparameterandreturnsittothecaller.)inout(Theoperationusesthevalueoftheparameterandmaychangethevalue;thecallerexpectstoseeaninoutparameteragain.)directionnametypedefault-valuein,out,inoute.g.getId,calculateBonusBoolean,Money,etc.e.g.42,JohnPage15 anexampleThecheckAvailabilityoperationreceivesaBookobjectandreturnsavalueoftheuser-definedtypeOrderStatus.TheisFulfilledoperationisaquerythatreturnsTrueifeverythingthecustomerorderedisinplaceorFalseotherwise.TheUMLdefinesaseparatelanguage,calledtheObjectConstraintLanguage(OCL),thatyoucanusetospecifyconstraints.Page16 Note对象约束语言简称OCL(ObjectConstraintLanguage)，它是一种用于施加在指定的模型元素上约束的语言。UsingtheOCLenablesyoutoreachacertainlevelofrigorinyourmodelingwithoutsideeffects.Inotherwords,theevaluationofOCLexpressionscan'talterthestateoftheexecutingsystem.对象约束语言是一种形式化语言，它主要用于表示UML模型中施加于模型上的约束。OCL表达式以附加在模型元素上的条件和限制来表现对该对象的约束，其中包括附加在模型元素上的不变量或约束的表达式，附加在操作和方法上的前置条件和后置条件等。Twokindsofconstraintsareofparticularinterestinthecontextofoperations:preconditionsandpostconditions.Page17 NOTEAbstract:把一个类名写为斜体表示是抽象的；leaf，表示它是叶子操作，意味着该操作不是多态的，不可以被覆写(这类似于java中的final操作)。除了leaf之外，还有：查询(query)，操作不会改变系统的状态；顺序(sequential)，调用者必须在对象外部进行协调；监护(guarded)，通过将所有对象监护操作的所有调用顺序化；并发(concurrent)，静态(static)；Page18 responsibilities职责指的是类所担任的任务，类的设计要完成什么样的功能，要存担的义务。一个类可以有多种职责，设计得好的类一般至少有一种职责，在定义类的时候，将类的职责分解成为类的属性和方法。类的职责其实只是一段或多段文本描述。通常在UML中在类图的最下方用单独的部分列出类的职责。It'softendesirabletodefineexplicitresponsibilitiesforaclass.TheserepresenttheobligationsthatoneclasshaswithregardtootherclassesTheideaofassigningresponsibilitiestoclassesisatthecenterofClass-Responsibility-Collaboration(CRC)cards.ThisideaisalsocentraltoResponsibility-DrivenDesign.Page19 UMLobjectnotationThenotationforanobjecttakesthesamebasicformasthatforaclass.Therearethreedifferencesbetweenthenotations,asfollows:Withinthetopcompartmentoftheclassbox,thenameoftheclasstowhichtheobjectbelongsappearsafteracolon.Theobjectmayhaveaname,whichappearsbeforethecolon,oritmaybeanonymous,inwhichcasenothingappearsbeforethecolon.Thecontentsofthetopcompartmentareunderlinedforanobject.Eachattributedefinedforthegivenclasshasaspecificvalueforeachobjectthatbelongstothatclass.Page20 classesandsubclasses继承，指的是一个类（子类）继承另外的一个类（超类）的功能，并增加它自己的新功能的能力。考虑银行账户的类型：CheckingAccount和SavingsAccount类从BankAccount类继承而来。Page21 继承和泛化继承关系由每个超类的单独的线画出，这是在IBMRationalRose和IBMRationalXDE中使用的方法。然而，有一种称为树标记的备选方法可以画出继承关系。当存在两个或更多子类时，除了继承线象树枝一样混在一起外，你可以使用树形记号。Page22 抽象类(AbstractClasses)Anabstractclassisaclassthatcan'thaveanyinstances.Abstractclassesaregenerallydesignedtocaptureoperationsthatsubclassesinherit.Theideaisthattheoperationsdefinedforanabstractclassarerelativelygeneral,andeachclassthatinheritstheseoperationsrefinesandexpandsuponthem.InUMLnotation,thenameofanabstractclassappearsinitalicsYoucanalsousean«abstract»stereotypeforreadersofthemodelwhomightnotrealizethesignificanceoftheitalics.前面的图中,父类的类名BankAccount和withdrawal操作使用斜体。这说明父类BankAccount是一个抽象类，而withdrawal方法是抽象的操作。换句话说，BankAccount类使用withdrawal规定抽象操作，并且两个子类CheckingAccount和SavingsAccount都分别地执行它们各自版本的操作。然而，超类（父类）不一定要是抽象类。标准类作为超类是正常的。Page23 主动类（ActiveClasses）Anactiveclassisaclassthatrepresentsanindependentflowofcontrol,suchasaprocessorathread.Theclassboxforanactiveclasshasthinverticalbarsjustinsidetheborders,asshownbelow.TheinstancesofanactiveclassarecalledactiveobjectsPage24 Scope（作用域/有效范围/辖域）Theownerscopeofanattribute(respectivelyanoperation)specifieswhethertheattribute(theoperation)appearsineachinstanceoftheclassorwhetherthereisjustasingleinstanceofthefeatureforallinstancesoftheclass.IntheUML,therearetwokindsofownerscope:instanceeachinstanceoftheclassholdsitsown value(definition)fortheattribute(operation)classthereisjustonevalue(definition)ofthe attribute(operation)forallinstancesoftheclassPage25 ScopeTheclassscopeisrenderedbyunderliningtheattribute(operation)Attribute(operation)attheclassscopeClass(operation)attributeDonotapplytoaninstance,buttotheclass(e.g.,constructors)Frameheader:FrameHeaderuniqueId:LongCarnumCars:Int…increaseNumCars()…Page26 ClassMultiplicityHowmanyinstancesofaspecificclasswillbecreatedatruntime?Zero:foranabstractclass,orifyouwanttheclasstoexposeonlyclassscopeattributesandoperationsOne:thisisasingleton（单体）X(aspecificnumber)Many(default)Themultiplicityofaclassiswrittenintheupper-rightcorneroftheclassiconNetworkControllerconsolePort[2..*]:Port1ControlRod3Page27 接口（Interfaces）Aninterfaceisacollectionofoperationsthatrepresentservicesofferedbyaclassoracomponent.Bydefinition,alloftheseoperationshavepublicvisibility.Theinterfacespecifiessomethinglikeacontractthataclassmustadhereto;theclassrealizes(orprovidesarealizationfor)oneormoreinterfaces.UML中的接口是一种实现继承的形式，但这种继承形式与Java中通过关键词extends实现的继承有所不同。一个类和一个接口不同：一个类可以有它形态的真实实例，然而一个接口必须至少有一个类来实现它。在UML2中，接口长方形的顶部区域有版型《interface》，如图：Page28 接口的类型TheUMLdefinestwokindsofinterfaces:providedinterfaces（供接口）andrequiredinterfaces（需接口）。"lollipop"notation棒棒糖Page29 接口的类型Youcanalsoshowoneclassprovidinganinterfacethatanotherclassrequires,using“ballandsocket”notation,wheretheballrepresentstheprovidedinterfaceandthesocketindicatestherequiredinterface。TheInventoryclassprovidestheRetrieveBooksinterfacethattheOrderclassrequiresPage30 端口portAportspecifiesadistinctinteractionpointbetweenaclassanditsenvironment.Portsgroupprovidedinterfacesand/orrequiredinterfacesintwoways.Theyserveasfocalpointsthroughwhichrequestscanbemadetoinvoketheoperationsthattheclassmakesavailable.Theyalsoserveasgatewaysforcallsthattheclassmakestooperationsofferedbyotherclasses.AninstanceoftheOrderclassreceivesarequesttofulfilltheactualorderthattheinstancerepresentsviathePerformFulfillmentinterface.TheOrderinstanceusestheRetrieveBooksinterfaceinmeetingthisrequest.Afterthegivenorderisshipped,theassociatedCustomermayrequesttrackinginformationviatheProvideTrackingInfointerface.TheOrderinstance,inturn,usestheRetrieveTrackingInfointerfacetoacquirethenecessaryinformationtoreturntotheCustomer.端口作为互作用点并且在类封装的“壳”中提供开放的门Page31 ClassDiagram:StereotypesAnalysisclassstereotypesdifferentiatetherolesobjectscanplay:BoundaryobjectsmodelinteractionbetweenthesystemandactorsEntityobjectsrepresentinformationandbehaviourintheapplicationdomainControlobjectsco-ordinateandcontrolotherobjects(ControlflowofUseCasescenarioexecutions)Identifiedbyatextlabelintheclassnamecomponentshownbetweenguillemets.Page32 ClassDiagram:StereotypesUserInterface::AddAdvertUIUserInterface::AddAdvertUIstartInterface()assignStaff()selectClient()selectCampaign()<>UserInterface::AddAdvertUIstartInterface()assignStaff()selectClient()selectCampaign()Alternativenotationsforboundaryclass:Page33 ClassDiagram:StereotypesAlternativenotationsforentityclass:CampaignCampaigntitlecampaignStartDatecampaignFinishDategetCampaignAdverts()addNewAdvert()<>CampaigntitlecampaignStartDatecampaignFinishDategetCampaignAdverts()addNewAdvert()Page34 ClassDiagram:StereotypesAlternativenotationsforcontrolclass:AddAvertControl::AddAdvertshowClientCampaigns()showCampaignAdverts()createNewAdvert()<>Control::AddAdvertshowClientCampaigns()showCampaignAdverts()createNewAdvert()Page35 ClassDiagrams:DefiningrelationshipsbetweenclassesPage36 ClassRelationshipsClasses,bythemselves,aren'tparticularlyuseful.It'stherelationshipsamongclassesthatprovidethefoundationforthestructureofanewsystem.ThefollowingsectionsexplorehowyouusetheUMLtoillustratevariouskindsofclassrelationships.Page37 ThedifferentrelationshipsThedifferentrelationshipsinaclassdiagramAssociation关联aggregation聚合；聚集composition组合；合成Generalization泛化Realization(interfaces)实现Dependency依赖Page38 Associations关联Association:astructuralrelationshipthatspecifiesthatobjectsofoneclassareconnectedtoobjectsofanotherAnassociationdescribesagroupoflinks(semanticconnectionamongobjects)withcommonstructureandsemanticsAssociationsrepresent:ThepossibilityofalogicalrelationshiporconnectionbetweenobjectsofoneclassandobjectsofanotherIftwoobjectscanbelinked,theirclasseshaveanassociationMathematicallycorrespondtoasetoftuples(Relation)Canbeimplementedinmanyways,dependingontheprogramminglanguage.Graphically:asolidlineconnectingthesameordifferentclassesPage39 AssociationsRefiningthesemanticsofanassociationusing:BasicfeaturesAnameMultiplicitiesAroleAnavigationAggregationandcompositionadornmentsAdvancedfeaturesVisibilitiesQualifications条件InterfacespecifierArity元数，度，目AssociationclassesConstraintsPage40 AssociationnameThenameofanassociationdescribesthenatureoftherelationshipYoucangiveadirectiontoanamebyprovidingadirectiontrianglethatpointsinthedirectionyouintendtoreadthenameDanGoldinNASABillGatesMicrosoftJohnSmithRockwell......Works-forPersonOrganizationWorks-forEmploysPage41 AssociationmultiplicityLimitthenumberofinstancesofoneclassthatmayberelatedtoaninstanceofanotherDefinetheallowednumberoflinksbetweenobjectsClassClassClassClassClassmany(zeroormore)optional(zeroorone)mandatory(oneormore)numericallyspecified1..*2..4,6..8exactlyone0..*0..11Page42 MeaningofMultiplicityConstraintsCourse1teachesProfessor*ProfessorCourseSWEN5232CSCI3233SWEN5233Dr.SmithDr.WhiteDr.BrownDr.JonesCSCI4432Dr.WhiteCSCI3233Dr.SmithCSCI4432Dr.BrownSWEN5232teachesDr.BrownSWEN5233Page43 AnalyzingandvalidatingassociationsMany-to-oneAcompanyhasmanyemployees,Anemployeecanonlyworkforonecompany.Thiscompanywillnotstoredataaboutthemoonlightingactivitiesofemployees!AcompanycanhavezeroemployeesE.g.a‘shell’companyItisnotpossibletobeanemployeeunlessyouworkforacompany*worksForEmployeeCompanyPage44 ExampleImplementationinJavaLayerLayerElement1*LayerElement-containedIn:Layer+getLayer()+setLayer(l)Layer-layerElements:Set+elements()+addElement(le)+removeElement(le)Page45 AnalyzingandvalidatingassociationsMany-to-manyAsecretarycanworkformanymanagersAmanagercanhavemanysecretariesManagerscanhaveagroupofsecretariesSomemanagersmighthavezerosecretaries.Isitpossibleforasecretarytohave,perhapstemporarily,zeromanagers?Page46 AnalyzingandvalidatingassociationsOne-to-oneForeachcompany,thereisexactlyoneboardofdirectors（董事会）AboardistheboardofonlyonecompanyAcompanymustalwayshaveaboardAboardmustalwaysbeofsomecompanyAvoidunnecessaryone-to-oneassociationsAvoidthisdothisPage47 AmorecomplexexampleAbooking(预约)isalwaysforexactlyonepassengernobookingwithzeropassengers（飞机旅客）abookingcouldneverinvolvemorethanonepassenger.APassengercanhaveanynumberofBookingsapassengercouldhavenobookingsatallapassengercouldhavemorethanonebookingPage48 MultiplicityExamplesProfessornamesubjectheadsCoursetitleteaches11..**Departmentname0..11studiesStudentnamenumber4..6Page49 Multiplicity:SnapshotversusHistory?Whatisthescopeofmultiplicityconstraints?Shouldtheycoverpast,presentandfutureorjustpresent?AnswerdependsonthecontextWomanManmarried_toWomanManmarried_to=>whenahistoryofmarriagesisuseful(e.g.,police)=>whenonlycurrentmaritalstatusneeded(e.g.,bank)0..*0..*0..10..1Page50 RolesCorrespondtooneendofanassociationEachendofanassociationmaybeassignedarolewhichservesasitsuniqueidentifierProvideawayoftraversingabinaryassociationfromoneobjecttoasetofrelatedobjects(moreinthesectionontheObjectConstraintLanguage)ArewrittennexttotheassociationlinePage51 Rolesconductsmission_specialist0..*1..*PersonCompanyemployeeemployerAstronautExperimentAPersonplayingtheroleofemployeeisassociatedwithaCompanyplayingtheroleofemployer.AnAstronautplayingtheroleofmissionspecialistisassociatedwithinstancesofExperiment.Page52 Reflexiveassociations自反关联ItispossibleforanassociationtoconnectaclasstoitselfCourse**prerequisitesuccessorPage53 Navigation导航导航描述关联终端的两个类是否能够发现对方。导航一般是双向的，但是也有单向的导航。例如：UserGroup和User之间的关联是双向的。通过一个UserGroup对象可以找到一个User对象，反之亦然。然而：User和Password之间的导航是单向的。给定一个User对象，需要找到对应的Password，然后对于给定的Password却没有必要识别出对应的User对象。UserGroupUserPassword+user-key1***Page54 NavigationUML2SyntaxNavigationAtoBisnavigableBtoAisnavigableAtoBisnavigableBtoAisnotnavigableAtoBisnavigableBtoAisundefinedAtoBisundefinedBtoAisundefinedAtoBisnotnavigableBtoAisnotnavigablePage55 Aggregation聚集；聚合Inaplainassociation,thetwoclassesareatthesamelevel:noonemoreimportantthantheotherAggregation:aspecialformofassociationbetweenawholeanditspartsRelatesanassemblyclasstoitscomponentclassesRepresentsa“has-a”relationship,meaningthatanobjectofthewholehasobjectsofthepart(s)Theassemblyobjectpropagates（传播）instructionstocomponentobjects(accessandcontrolthroughtheassemblyclass)Twopossibilities:Physical:apartcannotbeinmorethanone‘whole’Catalog:apartcanbeinmorethanone‘whole’Page56 Odell对Whole-Part的关系的分类JamesOdell根据3项特性而将聚合关系分为6种。配置（Configuration）：“部分”和“整体”是否有着特定的功能或结构关系。例如：引擎在汽车里扮演驱动功能。同质性（Homeomorphic）：“部分”和“整体”是否是同一类东西，例如：一片面包和一个面包都是面包。不变性（Invariance）：“部分”是否可以从整体中抽取出来。奶酪里有奶油成分，但是很难分离出来。如果是可变性就使用UML的Aggregation符号表示，如果是不变性则使用composition符号。Page57 6种组合关系为：组件/整体（component-integral）：CPU、硬盘等组件和电脑整体材料/对象（meterial-object）:ismadeof不变性不同质切割部分/对象（portion-object）:一盒饼干与一块饼干同质可变性地方与地区（place-area）：一个旅行团的旅程，由一系列小旅程组成成员/聚集（member-bunch）:俱乐部/会员容器/内容成员/合伙（member-partnership）:例如，四世同堂Page58 AggregationExample1--ModelingaSchemaThebellowingfigureshowsasetofclassesdrawnfromaninformationsystemforaschool.You'llseethedetailsoftheseclassesrevealedtoalevelsufficienttoconstructaphysicaldatabase.Startingatthebottom-leftofthisdiagram,youwillfindtheclassesnamedStudent,Course,andInstructor.There'sanassociationbetweenStudentandCourse,specifyingthatstudentsattendcourses.Furthermore,everystudentmayattendanynumberofcourses,andeverycoursemayhaveanynumberofstudents.Thisdiagramexposestheattributesofallsixoftheseclasses.Noticethatthetypesofalltheattributesareprimitivetypes.Whenyouaremodelingaschema,you'llgenerallywanttomodeltherelationshiptoanynonprimitivetypesusinganexplicitassociationratherthananattribute.Page59 Page60 AggregationExample2DocumentSentenceWord1..*CrewAstronaut4..6**1..*1..*TeamPerson15DepictedbyadiamondattheassemblyendPage61 Aggregationexample:graphicalinterfaceWindowPaneTitleBarScrollBarBorderCloseButtonTitleArrowIndicator*20..2Page62 Aggregation-Tree-likeNotationWindowPaneTitleBarScrollBarBorderCloseButtonTitleArrowIndicator*20..2Page63 RecursiveAggregationAggregationcanbe:Fixed:thenumberandtypesofthepartsisfixedVariable:thetypesofpartsmayvary,butthenumberoflevelsisfixedRecursive:thenumberoflevels,andhenceparts,isunlimitedBlockCompoundstatementSimplestatementProgram**Page64 titleCompositionAformofphysicalaggregationwithstrongownershipandcoincidentlifetimeofpartwithwhole:Multiplicityatassembly/aggregateendmaynotexceed1(i.e.,thecomponentisnotshared)DistinguishedfromregularaggregationbymeansofafilleddiamondIftheaggregateisdestroyed,thenthepartsaredestroyedaswellWindowHeaderSliderPanelscrollbarbody112Page65 AlternativeCompositionNotationstitleWindowHeaderSliderPanelscrollbarbody112Windowscrollbar:Slidertitle:Headerbody:Panel112WindowHeaderPanelSlidertitlescrollbarbody112Page66 Propagation传播Amechanism,commonincompositions,whereanoperationonanaggregateisimplementedbyhavingtheaggregateperformthatoperationonitspartsAtthesametime,propertiesofthepartsareoftenpropagatedbacktotheaggregateIntheexamplebelow,iflinesegmentschangeinapolygon,thenitssurfaceareamaychangeasaresultIfthepolygonisscaledup,thenthisispropagatedtoallitslinesegmentsPage67 Attributevs.Association:PrintingSystemPage68 Generalization/SpecializationDefinition:arelationshipwhichorganizesclassesbasedontheirsimilaritiesanddifferencesIsimplementedwithinheritanceinobject-orientedlanguages(moreinlatersectionson*proper*generalization)Sometimescalledan“is-a”relationshipShouldmean(butnotalwaysthecaseinpractice):Objectsofthechildclassmaybeusedanywheretheparentmayappear,butnotthereverseThechildissubstitutablefortheparentIstransitiveacrossanarbitrarynumberoflevelsPage69 Generalization/SpecializationAclassmayhavezero,oneormoreparentsRoot(base)class:aclasswithnoparentandoneormorechildrenLeafclass:aclassthathasnochildrenSimpleinheritance:aclasshasexactlyoneparentMultipleinheritance:aclasswithmorethanoneparent(notsupportedbyallprogramminglanguages)Notation:asoliddirectedlinewithalargeopenarrowhead,pointingtotheparentPage70 Simple/MultipleInheritancemultipleinheritancemultipleinheritancesingleinheritancePage71 Subclasses子类继承了其超类的所有attributes,operations,andassociations，semanticrestrictionsCanoverride（重写）theimplementationofanoperationvehiclesizespeedlandvehiclewheelswatervehiclepropellerPage72 Ancestors/DescendantsThediscriminator（判别式）isalabelthatdescribesthecriteriausedinthespecialization（特化）Thetermsancestoranddescendantrefertogeneralizationacrossmultiplelevels.一个类的实例，同时也是该类所有祖先的一个实例。Page73 UsingMultipleInheritanceAnimalhabitattypeOfFoodHerbivoreCarnivoreLandAnimalAquaticAnimalAquaticCarnivore水生食肉动物AquaticHerbivore水生食草动物LandCarnivore陆地食肉动物LandHerbivore陆地食草动物Avoidduplication（复制）ofproperties(attributes)IncreasescomplexityPage74 SpecializationConstraints特化约束Constraintscanbeusedtodescribetherelationshipbetweenaclassanditssubclasses.TheSpecializationcanbe:Complete完备：超类中的每一个实体，必须是特化中每一个子类的成员。allsubclasseshavebeenspecified(nomoreareexpected)Incomplete部分：允许超类中的实体，不属于任何一个子类。somesubclasseshavebeenspecifiedbutitisknownthatothersexist.Disjoint不相交:子类必须是不相交的。e.g.classPersoncanbespecializedintodisjointclassesManandWoman.Overlapping重叠：一个实体，可以出现在多个子类中。e.g.classVehiclecanbespecializedintooverlappingsubclassesLanVehicleandWaterVehicle(anamphibiousvehicleisboth)Page75 {complete}人女人男人性别完全泛化交通工具drive()汽车drive()轮船drive()drive()启动轮子转动drive()启动螺旋浆Person驾驶drive()是抽象操作泛化中的多态性及带判别式的泛化{propulsion}{propulsion}{overlapping}交通工具重叠泛化汽车船水陆两栖车Page76 MeaningofRoles角色RolescanbethoughtofasashorthandformofspecializationandcanbechangedassuchifneededExperimentAstronautconducts1..*1..*Mission_SpecialistAstronautShepherdCollinsArmstrongAldrinMissionSpecialistExperimentFrogsSpawningCrystalFormationconductsmission_specialist0..*1..*AstronautExperimentPage77 Abstract,Root,Leaf,andPolymorphicElementsAbstractclass:maynothaveanydirectinstanceThenameoftheclassisinitalics(samethingforabstractoperations)OrTheproperty{abstract}iswrittenbelowtheclass’snameAclassthatmayhaveinstance(s)isaconcreteclassLeafclass/operation:mayhavenochildren/redefinitionsTheproperty{leaf}iswrittenbelowtheclass’snameTheproperty{leaf}iswrittenafteraleafoperationRootclass:mayhavenoparentTheproperty{root}iswrittenbelowtheclass’snamePolymorphicoperation:contrarytoleafoperations,mayhaveseveralimplementationsinaninheritancehierarchy(default)Page78 Abstract,Root,Leaf,andPolymorphicElementsIcon{root}origin:Pointdisplay()getId():Int{leaf}RectanglarIconheight:Intwidth:IntArbitraryIconedge:LineCollectionisInside(p:Point):BooleanButtondisplay()OKButton{leaf}display()baseclassabstractclassabstractoperationconcreteoperationconcreteclassleafclasspolymorphicoperationPage79 ClassDiagramsAdvancedFeatures&GuidelinesPage80 Visibilityforassociation关联的可见性给定两个类的关联，一般情况下，一个类的对象能够看见并导航到另外一个类的对象。然而，有些情况下要限制关联外部的对象通过关联访问相关对象的可见性。Example:GivenaUserobject,itispossibletoidentifyitscorrespondingPassword.However,aPasswordisprivatetoaUserObject(unless,ofcourse,theUserexplicitlyexposesaccesstothePassword)GivenaUserGroupobject,youcannavigatetoitsUserobjects(andviceversa),butyoucannotinturnseetheUserobject’sPasswordobjectsUserGroupUserPassword+user-key1***Page81 Qualifiers限定符Qualifier:在关联的语境中，最常见的一种建模惯用法是查找。给定关联一端的对象如何识别另外一端的对象？考虑一个制造厂的工作台的建模问题：工作台上对返回的工件进行维修，给定一个WorkDesk对象，能够有一组ReturnItem与之对应；给定一个WorkDesk对象，如何确定一个ReturnItem对象与之对应呢？这需要WorkDesk的语境内有一个具体标识JobID作为关联的属性。而不是ReturnItem的特征，因为工件不知道也不具备维修的信息。然后，给定一个给定一个WorkDesk对象，和一个确定的JobID值，就可以确定0个或者1个ReturnItem对象与之对应。Page82 Qualifier在UML中，限定符是关联的一个属性，它的值将对方的对象集合划分若干个子集。也就是说，使用限定关联（QualifiedAssociation）可以把关联的多重性从一对多变成一对一；或者从多对多变成多对一。限定关联提高了语义的精确性，增强了查询能力。AstronautMissionPartpart_noCatalogseat-no:IntPage83 InterfacespecifierTheroleoftheclassinanassociationisrefined(specified)byaninterfacenameExample:theselfassociationwithclassPersonandthetworolesworkerandsupervisorAPersonintheroleofsupervisorpresentsonlytheIManagerfacetotheworkerAPersonintheroleofworkerpresentsonlytheIEmployeefacetothesupervisorPersonworker:IEmployeesupervisor:IManager*1Page84 AssociationArity元数Arity:thenumberofclassesthatareinvolved(connected)inanassociationAssociationsmaybebinary,ternary,orhigherorderTernaryorhigherorderassociationsarefairlyrare.Andtheycanbetransformedintoasetofbinaryassociations(butlossofinformation)ternaryassociationAstronaut_hasseat_on_missionAstronautMissionJobPage85 MeaningofTernaryAssociationsMissionJobAstronautChapmanSTS-65BarkerAstronaut_has_Job_on_MissionChapmanBarkerMurraySTS-68STS-65STS-69STS-69pilotpilotm_specialistm_specialistcommanderanastronautcanonlydoonejobonamissionAstronaut_has_Jobon_Mission**tripletsPage86 Associationclasses为了说明关联的性质，可能需要加入一些附加信息。可以引入关联类来记录这些信息。Associationclass:Inanassociationbetweentwoclasses,theassociationitselfmayhaveproperties(attributes,operations)Thesepropertiesdonotbelongtoanyoftheclassesoftheassociation,buttothepairAnassociationclassisjustlikeanotherclass.Itmayhave:AttributesOperationsRelationshipswithotherclassesPage87 AssociationClassesAstronautMissionMedicalReporttimes-sickperformanceDatabaseflew-on0..*4..6stores0..*PersonCompanyJob1..*employer0..1periodsalaryPage88 AssociationClassesPromotinganassociationclasstoafullclass。有时可能想让一个关联类与几个关联相关。PersonCompanyJob1..*employer0..1periodsalaryPersonCompany1..*1..*Jobperiodsalary**Page89 Exampleofagenealogysystem家谱建模IssuesApersonmusthavetwoknownparents?Apersonmayhavemultiplemarriagesandchildrenwithseveraldifferentpartnersoverthecourseofhis/herlife2childPersonnameplaceOfBirthdateOfBirthplaceOfDeathdateOfDeathplaceOfMarriagedateOfMarriagedateOfDivorce*parents0..10..1wifehusband{husband.sex=#male}{wife.sex=#female}{parent->forAll(p1,p2:p1<>p2impliesp1.sex<>p2.sex)}sexPage90 Genealogyexample:PossiblesolutionPersonnameplaceOfBirthdateOfBirthplaceOfDeathdateOfDeathUnionplaceOfMarriagedateOfMarriagedateOfDivorceparents0..2child*child***malePartner*0..1child**femalePartner0..1WomanManApersonisnotrequiredtohavetwoparentsknowninthesystemThepartnerroleallowsforonlyzerooronepartnertobeknownPage91 AnalysismodelvsDesignmodelTheAnalysismodelomitsmanyclassesthatareneededtobuildacompletesystemDomainmodelCancontainlessthanhalftheclassesofthesystem.Shouldbedevelopedtobeusedindependentlyofparticularsetsofuserinterfaceclassesarchitecturalclasses(e.g.,designpatternsclasses)ThecompleteDesignmodelincludesThesystemdomainmodelUserinterfaceclassesArchitecturalclasses(e.g.,neededforclassestocommunicate)UtilityclassesPage92 SuggestedsequenceofactivitiesIdentifyafirstsetofcandidateclassesAddassociationsandattributesFindgeneralizationsListthemainresponsibilitiesofeachclassDecideonspecificoperationsIterateovertheentireprocessuntilthemodelissatisfactoryAddordeleteclasses,associations,attributes,generalizations,oroperationsIdentifyinterfacesApplydesignpatternsDon’tbetoodisorganized.Don’tbetoorigideither.Page93 类图的设计原则开闭原则Liskov替换原则依赖倒置原则接口分离原则Page94 开闭原则指一个模块在扩展性方面是开放的，在更改性方面是封闭的。下例：oupput逻辑复杂，修改复杂根据开闭原则添加具有print方法的接口。Page95 LiskovLiskov替换原则子类可以替代父类出现在任何父类出现的地方Page96 依赖倒置原则依赖关系尽量依赖接口（或抽象类），而不是依赖具体类。Page97 接口分离原则设计时采用多个与特定客户类有关的接口比采用一个通用的接口好。Page98 类的识别是面向对象方法的一个难点，但又是建模的关键。常用的方法有：1.名词识别法2.系统实体识别法3.从用例中识别类4.利用分解与抽象技术关键是要定义类的“属性”及“操作”。Page99 １.名词识别法识别问题域中的实体，实体的描述通常用名词、名词短语、名词性代词的形式出现。用指定语言对系统进行描述；从系统描述中标识名词、名词短语、名词性代词；识别确定（取、舍）类。为了发现对象和类，开发人员要在系统需求和系统分析的文档中查找名词和名词短语，包括：可感知的事物、角色、事件、互相作用、人员、场所、组织、设备和地点等。描述过程应与领域专家共同合作完成，并遵循问题域中的概念和命名。根据下述原则进一步确定类：①去掉冗余类：如两个类表述同一信息，应保留最具有描述能力的类。②去掉不相干的类：删除与问题无关或关系不大的类。③删除模糊的类或性质独立性不强的类：有些初始类边界定义不确切，或范围太广，应该删除。⑤所描述的操作不适宜作为对象类，并被其自身所操纵，所描述的只是实现过程中的暂时的对象，应删去。Page100 2识别问题域中的实体不关心系统的运作流程及实体之间的通信状态，而只考虑系统中的人员、组织、地点、表格、报告等实体，经过分析将他们识别为类（或对象）。被标识的实体有：系统需要存储、分析、处理的信息实体；系统内部需要处理的设备；与系统交互的外部系统；系统相关人员；系统的组织实体。Page101 Example1SpecificoccurrencesofageneraltypePeople(‘JonDoe’),organizations,organizationunitsStructuresinherenttotheproblemdomainVolunteerteam,carsharerAbstractionssuchaspeopleandroles,physicalartifacts,concepts‘Insurancesalesadvisor’‘car’,‘insurancepolicy’‘sale’,‘skill’Enduringrelationshipsbetweenotheridentifiedclasses‘agreement’,‘registration’Duringdesign:classneededtosolveaparticulardesignproblemPage102 识别问题域中的实体例2:有一个购物超市，顾客可在货架上自由挑选商品，由收款机收款，收款机读取商品上的条型码标签，并计算商品价格。收款机应保留所有交易的记录，以备帐务复查及汇总使用。通过分析问题的陈述，确定以下几类实体：⑴信息实体：交易记录、商品、税务信息、销售记录、货存记录。⑵设备：收款机、条型码扫描器。⑶交互系统：信用卡付款系统。⑷人员职责：收款员、顾客、会计、经理。⑸系统的组织实体：本例不考虑。以上列出的实体，都可以直接识别为类。Page103 Asimpletechniquefordiscoveringdomainclasses根据用例的描述来识别类;如用例的描述中出现哪些实体?用例执行过程中产生并存储哪些信息?与用例关联的角色向用例输入什么信息?用例又向该角色输出哪些信息?在确定类时，常使用两类技术：⑴分解技术 将整体类和组合类分解。可控制单个类的规模。⑵抽象技术 根据一些类的相似性建立抽象类，并建立抽象类与这些类之间的继承关系。抽象类实现了系统内部的重用，很好地控制了复杂性，并为所有子类定义了一个公共的界面，使设计局部化，提高系统的可修改性和可维护性。Page104 学生选课系统的例子学生选课系统中，“选修课程”用例的事件流描述如图：参与者学生功能描述本用例描述学生选择将要学习的课程的过程前置条件执行“登陆”用例后置条件无基本流1.学生选择要选修的课程。2.系统通过财务系统检查学生是否缴费3.系统更新该学生所选课程4.系统显示学生所选课程5.学生确认所选课程6.系统保存学生所选课程备选流2.a如果学生没有缴费，给出提示，结束5.a如果学生没有确认，给出提示，结束Page105 提取被选的概念类事件流描述是一个需求的主要内容。正对学生选课的事件流进行分析，可以得出一些概念类：学生：学校中的在校学生课程：学校中开设的课程学费:学生需要交纳的学费财务系统:学校中的一个软件系统，负责学校的财务管理通过进一步的分析，发现“财务系统”是一个外部执行者，不是系统内部的概念类。这样最终确定三个类：学生、课程、学费。学生学费财务系统课程Page106 获取概念类的属性和方法获取类的属性有两个途径。第一：从类的概念中查找显而易见的基本属性。例如：学生的学号、姓名。第二：从问题分析和描述（包括用户对需求的描述）中找到名词和术语，可能是某些类的属性。例如：学生在选课之前，可能先要查看课程简介，“课程简介”就可以作为“课程”的一个属性。在同用户交流以及分析需求文档时，要注意用户描述需求提到的动词，因为这些动词可能成为类的方法。对每一个方法进行分析，可以得出主要的类之间的关系。分析阶段的类图Page107 获取设计类分析阶段的类图主要用来描述现实世界的问题，而设计阶段的类图主要对解决方案的描述。在设计阶段，需要从软件系统的角度重新来设计类图。因此，设计阶段的类图描述了软件系统的架构。分析阶段的类到了设计阶段有的可能变成一组类，有的可能消失了；同时还有有一些新的类补充进来，形成设计类图。创建设计类图一般可以分为以下几个步骤：识别在软件设计阶段出现的类。主要依据软件解决方案、概念类、用例描述、描述系统行为的顺序图和合作图。为这些类添加属性和方法：主要依据概念类模型中类的属性和方法，描述系统行为的顺序图和合作图。建立类之间的关系。在关联类之间添加关联，对有共同之处的进行泛化，根据需要适当应用设计模式。对关联、属性和方法完成细节描述：可见性、类型、初始化，约束等等Page108 细化设计类图在开始系统设计时，首先要给出一个概要的设计，也可以称为软件架构设计。根据这个架构，就可以确定哪些类是设计阶段需要的类。首先分析学生类，与之有关的类还有“班级”和“系”的概念。同样，与“课程”有关的类有“系”和“教师”两个概念。这样，在分析阶段的两个类，在设计阶段变成了一组类。有可能还继续对“课程”进行分析，发现“课程”按照组织方式、考核方式的不同分为两类“理论课”和“实训课”。因此，为了确切的描述这种关系，对课程类进行了泛化处理。Page109 设计类图的一些建议创建设计类图的过程是一个不断重复的过程，直到完成主要的设计类的描述。不要试图使用所有的符号。有些符号只有当需要才去使用。根据项目开发不同阶段、不同层次的观点来画类图。不要为每一个事物都画一个模型。把精力放在关键位置、核心部分。避免过早的陷入细节。类的具体内部实现主要包括类的方法和全部的属性的说明，这些细节和具体程序设计语言以及程序设计方法有关。Page110 IdentifyingassociationsandattributesStartwithclassesyouthinkaremostcentralandimportantDecideontheclearandobviousdataitmustcontain(attributes)anditsrelationshipstootherclasses.Workoutwardstowardstheclassesthatarelessimportant.AvoidaddingmanyassociationsandattributestoaclassunlessclearlyrelevantAsystemissimplerifitmanipulateslessinformationPage111 SimpleTechniqueforassociationsVerbphrasescanindicateassociationsbetweenclassesExample:‘customerholdsaccount’‘volunteersholdparticularskills’‘carsharersregistersjourney’AnassociationshouldexistifaclasspossessescontrolsisconnectedtoisrelatedtoisapartofhasaspartsisamemberofhasasmembersPage112 ActionsversusassociationsAcommonmistakeistorepresentactionsasiftheywereassociations*LibraryPatronborrowLoanborrowedDatedueDatereturnedDateBad,duetotheuseofassociationsthatareactions*****returnCollectionItem**LibraryPatronCollectionItem**Better:TheborrowoperationcreatesaLoan,andthereturnoperationsetsthereturnedDateattribute.Page113 IdentifyingattributesLookforinformationthatmustbemaintainedabouteachclassSeveralnounsrejectedasclasses,maynowbecomeattributesAnattributeshouldgenerallycontainasimplevalueorenumerationsstring,number{1,2,3}Page114 AggregationGuidelinesFoursemanticspossibleExclusiveOwns(e.g.BookhasChapter)Existence-dependencyTransitivityAsymmetricityFixedpropertyOwns(e.g.CarhasTire)NoFixedpropertyHas(e.g.DivisionhasDepartment)NoExistenceDependencypropertyNoFixedpropertyMember(e.g.MeetinghasChairperson)NospecialpropertiesexceptmembershipPage115 UMLAggregationandCompositionUMLsupportsAggregation(conceptualnotion,suggestshighercoupling)HollowdiamondCorrespondstoHasandMemberaggregationsComposition(coincidentlifetime)SoliddiamondCorrespondstoExclusiveOwnsandOwnsaggregationsPage116 Example:UniversityEnrolmentAcademicRecordcourse_code:Stringyear:Datesemester:Integergrade:StringCoursecourse_code:Stringcourse_name:Stringcredit_points:IntegerAcademicInChargeStudentstudent_id:Stringstudent_name:Stringcurrent_fees:Money0..*0..*CourseOfferingyear:Datesemester:Integerenrolment_quota:Integer0..*0..*0..*0..*0..1**takes**takes_crsoffhas_studPage117 IdentifyinggeneralizationsandinterfacesTherearetwowaystoidentifygeneralizations:bottom-upGrouptogethersimilarclassescreatinganewsuperclasstop-downLookformoregeneralclassesfirst,specializethemifneededCreateaninterface,insteadofasuperclassifTheclassesareverydissimilarexceptforhavingafewoperationsincommonOneormoreoftheclassesalreadyhavetheirownsuperclassesDifferentimplementationsofthesameclassmightbeavailablePage118 Bottom-up/Top-downGeneralizationBottom-up:Classesthatshareproperties,responsibilities,andcollaborationsmaybecomeapparent.Commonpropertiesaregeneralizedintoasuitablesuperclass.CareshouldbetakenwiththisapproachthatgeneralizationisnotintroducedsimplyasameansofgraphicaltidyingofacomplexdiagramTop-Down:Generalizationisintroducedasawaytomakethedesignmoreresilienttochange.Theanalystshouldensurethattheproperties,responsibilities,andcollaborationsofthesuperclassapplycompletelytoallsubclassesPage119 ExampleClassDiagram*supervisorRegularFlighttimeflightNumber*******Passenger******************SpecificFlightdatenameemployeeNumberEmployeejobFunctionBookingseatNumbernamenumberPage120 案例—银行网络系统问题的陈述银行网络系统包括人工出纳和分行共享的自动出纳机；各分理处用自己的计算机处理业务（保存帐户、处理事务等）；各分理处与出纳站通过网络通信；出纳站录入帐户和事务数据；自动出纳机与分行计算机通信；自动出纳机与用户接口，接受现金卡；发放现金；打印收据；分行计算机与拨款分理处结帐。要求系统正确处理同一帐户的并发访问；网络费用平均摊派给各分理处。Page121 银行网络ATM系统ATM(AutoTradeMachine)银行网络系统包括人工出纳和分行与分理处共享的自动出纳机。自动出纳机自动出纳机自动出纳机出纳站分理处计算机分理处计算机出纳站帐户帐户用户分行计算机自动出纳机…Page122 一、确定类采用名词识别法：检查问题陈述中的所有名词，得到初始类：软件 银行网络 出纳员 分行 系统 自动出纳机帐户 帐户数据 出纳站 分理处 访问 分理处计算机事务 事务数据 现金卡 用户 顾客 分行计算机现金 收据 费用 安全措施 记录保管根据下述原则进一步确定类：①去掉冗余类：如两个类表述同一信息，应保留最具有描述能力的类，如“用户”与“顾客”是重复的描述，由于“顾客”更具有描述性，故保留它，删除“用户”。②去掉不相干的类：删除与问题无关或关系不大的类，如“费用”。Page123 (一)确定类采用名词识别法：检查问题陈述中的所有名词，得到初始类：软件 银行网络 出纳员 分行 系统 自动出纳机帐户 帐户数据 出纳站 分理处 访问 分理处计算机事务 事务数据 现金卡 用户 顾客 分行计算机现金收据 费用 安全措施 记录保管③删除模糊的类：有些初始类边界定义不确切，或范围太广，应该删除。如“系统”、“安全措施”、“记录保管”、“银行网络”。④删除那些性质独立性不强的，而应该是类“属性”的候选类：如“帐户数据”、“收据”、“现金”、“事务数据”。Page124 采用名词识别法：检查问题陈述中的所有名词，得到初始类：软件 银行网络 出纳员 分行 系统 自动出纳机帐户 帐户数据 出纳站 分理处 访问 分理处计算机事务 事务数据 现金卡 用户 顾客 分行计算机现金收据 费用 安全措施 记录保管⑤所描述的操作不适宜作为对象类，并被其自身所操纵，所描述的只是实现过程中的暂时的对象，应删去。如“软件”，“访问”。Page125 最终确定的11个类为：分行计算机 分行 出纳站 出纳员 分理处 计算机 自动出纳机 帐户 现金卡 事务 顾客采用名词识别法：检查问题陈述中的所有名词，得到初始类：软件 银行网络 出纳员 分行 系统 自动出纳机帐户 帐户数据 出纳站 分理处 访问 分理处计算机事务 事务数据 现金卡 用户 顾客 分行计算机现金收据 费用 安全措施 记录保管Page126 （二）为每个建模实体准备数据词典—描述模板对类进行精确描述，如ＡＴＭ系统中类的范围、成员、方法的限制等。（三）确定关联关联通常用描述性动词和动词词组表示。1.从问题陈述中抽出所有可能的关联表述。2.问题陈述中是不明显的，或是隐含的。3.还有一些关联与客观世界或应用领域有关，必须同用户一起确定这种关联。关联通常由以下方面确定：１、银行网络系统问题陈述中抽取可能的关联（动词词组）２、隐含的动词词组３、基于问题域的知识４、去掉不必要和不正确的关联Page127 确定关联１.银行网络系统问题陈述中的关联银行网络包括出纳站和自动出纳机。分行共享自动出纳机分理处提供分理处计算机分理处计算机保存帐户分理处计算机处理帐户支付事务分理处拥有出纳站出纳站与分行计算机通信出纳员为帐户录入事务自动出纳机接受现金卡自动出纳机与用户接口自动出纳机发放现金自动出纳机打印收据系统处理并发访问分理处提供软件费用分摊给分理处２.隐含的动词词组分行由分理处组成分理处拥有帐户分行拥有分行计算机系统提供记录保管系统提供安全顾客有现金卡３.基于问题域的知识分理处雇佣的出纳员现金卡访问帐户Page128 案例2医院病房监护系统要求根据现场情景，对医院病房监护系统进行需求分析，建立系统的用例模型。为了对危重病人进行实时监护，随时了解病人病情，及时进行处理，建立病房监护系统。病症监视器安置在每个病床，通过网络将病人的组合病症信号实时传送到中央监护系统进行分析处理。在中心值班室里，值班护士使用中央监护系统对病员的情况进行监控，监护系统实时地将病人的病症信号与标准的病诊信号进行比较分析，当病症出现异常时，系统会立即自动报警，并打印病情报告和更新病历。系统根据医生的要求随时打印病人的病情报告，系统定期自动更新病历。Page129 产生病情报告请对系统需求进行分析！经过初步的需求分析，得到系统功能要求：1、监视病员的病症（血压、体温、脉搏等）2、定时更新病历3、病员出现异常情况时报警。4、随机地产生某一病员的病情报告。例案：医院病房监护系统监视病情更新病历Page130 根据名词识别法和实体识别法,确定了以下初始类:监视器网络值班护士医生病人病症监视中央监护系统报警信号标准病症信号库病历库病人病症信号病情报告标准病症信号病历中心值班室处理组合病症信号分析确定类：①去掉冗余类：保留最具有描述能力的类。②去掉不相干的类：删除与问题无关或关系不大的类。③删除模糊的类或性质独立性不强的类：有些初始类边界定义不确切，或范围太广，应该删除。⑤所描述的操作不适宜作为对象类，并被其自身所操纵，所描述的只是实现过程中的暂时的对象，应删去。Page131 通过名词识别法和系统实体识别法可以确定系统的12个类：值班护士医生病人病症监视中央监护系统报警信号标准病症信号库病历库病人病症信号病情报告病历标准病症信号医生用户名密码查看病情报告（）要求打印病情报告（）查看病历（）要求打印病历（）病人姓名性别年龄病症提供病症信号（）用户名密码查看病情报告（）打印病情报告（）值班护士病症监视采集频率病症信号格式化信号数据（）采集信号（）信号组合（）Page132 病人病症信号脉搏血压体温生成病症信号（）病历格式病人基本情况打印时间生成病历（）查看病历（）打印病历（）标准病症信号脉搏血压体温生成标准信号（）标题格式生成病情报告（）查看病情报告（）打印病情报告（）病情报告报警信号声音灯光文字报警（）数模转化（）病历库类型大小容量生成病历（）更新病历（）查看病历（）打印病历（）类型大小容量提供标准信号（）标准病症信号库输入输出分解信号（）比较信号（）报警（）数据格式化（）中央监护系统Page133 使用下列标准去掉不必要和不正确的关联：(1)若某个类已被删除，那么与它有关的关联也必须删除或者用其他类来重新表述。(2)不相干的关联或实现阶段的关联。删除所有问题域之外的关联或涉及实现结构中的关联，(3)动作。关联应描述应用域的结构性质而不是瞬时事件。(4)派生关联，省略那些可以用其他关联来定义的关联,因为这种关联是冗余的。Page134 医院病房监护系统类图*******1111111111111111值班护士医生病人病症监视病人病症信号病历病历库病情报告报警信号中央监护系统标准病症信号11报警监视标准病症信号库1Page135 案例：商品预定一个顾客从零售商处预定商品的模型的类图。中心的类是Order。连接它的是购买货物的Customer和Payment。Payment有三种形式：Cash，Check，或者Credit。订单包括OrderDetails（lineitem），每个这种类都连着Item。Page136 对象图Objectdiagrams假如暂停一个正在运行的系统，就会发现系统在这个时刻包含一组对象，其中每个对象都处于一个具体的运行状态，每个对象都与其它对象有特定的关系，把这一时刻的系统状态绘制下来，就是对象图。对象图是对包含在类图中的各个类进行实例建模，对象图用于描述系统的静态进程，它显示了在某一时间点上系统中的一组对象以及他们之间的关系。包括某一时刻系统的快照，系统地对象集合，对象的状态以及相互的关系。对象可以看作是类的实例；对象图可以看作是类图的实例，对象之间的链看作是类和类关联的实例。Page137 对象的概念与特性对象代表一个单独的、可确认的物体、单元或实体，它可以是具体的也可以是抽象的，在问题领域里有确切定义的角色。换句话说，对象是边界非常清楚的任何事物状态：对象的状态包括对象的所有属性（通常是静态的）和这些属性的当前值（通常是动态的）行为：没有一个对象是孤立存在的，对象可以被操作，也可以操作别的对象。而行为就是一个对象根据它的状态改变和消息传送所采取的行动和所做出的反应标识：为了将一个对象与其它所有对象区分开来，我们通常会给它起一个“标识”Page138 Page139 对象图Objectdiagrams用来表示类的实例。他们在解释复杂关系的细小问题时（特别是递归关系时）很有用。这个类图示一个大学的Department可以包括其他很多的Departments。UML中实例名带有下划线。只要意思清楚，类或实例名可以在对象图中被省略。这个对象图示上面类图的实例。用了很多具体的例子。Page140 包为了简单地表示出复杂的类图，可以把类组合成包packages。包在UML中被视为文件夹，一个包是UML上有逻辑关系的元件的集合。下面这个图是是一个把类组合成包的一个商业模型。Page141 包的作用包图经常用来组织用例图和类图,当然，包图的用途并不仅限于这些UML元素。对语义上相关的元素进行分组；定义模型中的“语义边界”；提供配置管理单元；在设计时，提供并行工作的单元；提供封装的命名空间，其中所有名称必须惟一。Page142 包的表示法名称：每个包都必须有一个与其它包相区别的名称拥有的元素：在包中可以拥有各种其它元素，包括类、接口、构件、节点、协作、用例，甚至是其它包或图Page143 包的版型《system》表示正在建模的整个系统《subsystem》表示正在建模的系统中某个独立的部分《facade》只是某个其它包的视图，它主要用来为其它一些复杂的包提供简略视图《stub》是一个代理包，它服务于某个其他包的公共内容，这通常应用于分布式系统的建模中《framework》用来表示一个框架的，框架是一个领域内的应用系统提供可扩充模板的体系结构模式Page144 包的关系（3种）dependencies关系：如果两个包中任意两个类存在依赖关系，那么两个包之间也存在依赖关系。如果另一个的包B改变可能会导致一个包A改变，则包A依赖包B。包之间的依赖关系概述了包中元素的依赖关系，即包间的依赖关系可从独立元素间的依赖关系导出。但是，包之间的依赖关系一般没有传递关系。也就是系统中某个包发生变化，不一定会引起系统大范围的改变。包是用一个在上方带有小标签的矩形表示的。包名写在标签上或者在矩形里面。点化线箭头表示依赖Page145 dependencies关系Import说明提供者包的命名空间将被添加到客户包的命名空间中，客户包中的元素也能够访问提供者包的所有公共元素源包可以存取目的包中内容，并且引用目的包时无需包名，直接用元素名称就可。Page146 《use》关系是一种默认的依赖关系，说明客户包（发出者）中的元素以某种方式使用提供者包（箭头指向的包）的公共元素，也就是说客户包依赖于提供者包《access》关系只想使用提供者包中的元素，而不想将其命名空间合并则应使用该关系《trace》关系想表示一个包到另一个包的历史发展，则需要使用《trace》关系来表示Page147 包的关系（3种）泛化关系包的泛化关系符号和类图中相同。包的细化关系包的细化关系与细节有关，当一个包和另外一个包包含相同元素，但却带有更多细节时，就称两个包是细化关系。例如：Complete包中包含了一本书的全部完整章节。而Proposal包中包含了本书每个章节的简要概括。那么Complete包就是Proposal包的细化。细化用一条带有空心三角箭头的虚线表示。箭头指向被细化的包Page148 Uml2.0正式图形Page149 包图的关系举例保险单填写界面系统内部保险单客户数据库界面（abstract)Oracle界面Sybasec界面包的继承包的依赖包Page150 包图的关系举例财务子系统数据库子系统数据库操作数据库接口Oracle接口Sybasec接口Page151 例：用包图描述医院监护系统的体系结构用户医生值班护士病人病历管理病历用户界面病情报告局部监视报警信号病症监视器中央监护系统病人病症信号标准病症信号数据库病历库标准病症信号库用户层用户界面层应用层数据库层Page152 包图的注意事项在较大的项目中，包图是一种重要的工具。一般情况下，当涉及的整个系统的类图不能够画在一张A4纸上时，就应该考虑使用包图。使用包图时注意一些问题：在包图中，依赖会产生耦合，因此应尽量将包之间的依赖关系减到最低，并一定要避免循环依赖的产生。包在测试时也可以作为测试单位。尽量把概念和语义上比较接近的元素包含在同一个包中。对于每一个包，应找出那些包内的元素可以在包外访问，把这些元素标记为公共的。其它的都应该标记为受保护或者私有的。Page153 包的可见性和类一样包也有可见性，利用可见性控制外部包对包的内容的存取方式，UML中定义了四种可见性：私有(private)，公有(public)，保护(protected)实现(implementation)。缺省值为公有。包也可以有接口，接口与包之间用实线相连，接口通常由包的一个或多个类实现。Page154 包的可见性Page155 设计类包的原则复用等价原则把类放入包时，应把包作为可复用的单元。共用闭包原则把需要同时改变的类放在一个包中。共用使用原则不会一起使用的类不要放在一个包中。非循环依赖原则包之间的依赖关系不要形成循环。Page156 案例：学生课程注册系统某大学准备开发一个学生课程注册系统学生可以使用该系统查询新学期将开设的课程和讲课教师情况，选择自己要学习的课程进行登记注册，并可以查询成绩单;教师可以使用该系统查询新学期将开设的课程和选课学生情况，并可以登记成绩单;注册管理员使用该系统进行注册管理，包括维护教师信息、学生信息和课程信息等。在每个学期的开始，学生可以获得该学期的课程目录表，课程目录表列出每门课程的所有信息，诸如基本信息、教师、开课系和选课条件等。新学期开始前两周为选课注册时间，在此期间学生可以选课注册，并且允许改变或取消注册申请，开学两周后注册管理员负责关闭课程注册。每个学生可以选择不超过4门课程，同时指定2门侯选课程以备主选课程未选上。每门课程最多不能超过10人，最少不能低于3人，低于3人选课的课程将被取消。一旦学生的注册过程完毕，注册系统将有关信息提交收费系统以便学生付费。如果在实际注册过程中名额已满，系统将通知学生在提交课程表之前予以更改。在学期结束时，学生可以存取系统查看电子成绩单。由于学生成绩属于敏感信息，系统必须提供必要的安全措施以防非法存取。Page157 用例分析分析对象行为补充用例描述对每一个用例实现从用例行为中发现（分析）类把用例行为分发给（分析）类对每一个（分析）类描述职责描述属性和关系统一分析类Page158 Page159 分析类边界类（Boundary）实体类（Entity）控制类（Control）Page160 边界类位于系统与外界的交界处，例如窗体、对话框、报表、与外部设备或系统交互的类等等；边界类可以通过用例确定，因为活动者必须通过边界类参与用例；Page161 实体类保存永久信息，最终可能映射数据库中的表和字段；Page162 控制类协调其他类工作和控制总体逻辑流程，一般每个用例有一个控制类。控制类会向其他类发送消息。Page163 Page164 表一:学生课程注册系统的实体类:实体类说明Professor学校中讲课的老师Student学校中注册课程的学生Schedule学生在新学期选择登记的课程列表CourseCatalog学校所有课程的目录Course课程的基本信息CourseOffering新学期课程的开设信息,如讲课老师,时间,地点等信息Page165 表二:学生课程注册系统的边界类:边界类说明LoginForm登录窗体RegisterCoursesForm为学生提供学生选课注册ViewReportForm为学生提供成绩查询的操作SelectTeachCourseForm为教师提供查看学生选课情况SubmitGradesForm为教师提供登记成绩MaintainProfessorsForm为注册管理员提供维护教师信息MaintainStudentsForm为注册管理员提供维护学生信息MaintainCoursesForm为注册管理员提供维护课程信息CloseRegistrationForm为注册管理员提供关闭注册的操作BillingSystemNotice提供与收费系统的信息交换接口Page166 表三:学生注册系统的控制类控制类说明RegisterCourseControl负责新学期学生的选课登记ViewReportControl负责学生成绩的查询SelectTeachCourseControl负责新学期的学生的选择情况SubmitGradesControl负责学生成绩的登记CloseRegistrationControl负责关闭课程注册Page167 Page168 案例：个人图书管理系统小王是一个爱书之人，家里各类书籍已过千册，而平时又时常有朋友外借，因此需要一个个人图书管理系统。该系统应该能够将书籍的基本信息按计算机类、非计算机类分别建档，实现按书名、作者、类别、出版社等关键字的组合查询功能。在使用该系统录入新书籍时系统会自动按规则生成书号，可以修改信息，但一经创建就不允许删除。该系统还应该能够对书籍的外借情况进行记录，可对外借情况列表打印。另外，还希望能够对书籍的购买金额、册数按特定时间周期进行统计Page169 “小王”、“人”、“家里”很明显是系统外的概念，无须对其建模；而“个人图书管理系统”、“系统”指的就是将要开发的系统，即系统本身，也无须对其进行建模；很明显“书籍”是一个很重要的类，而“书名”、“作者”、“类别”、“出版社”、“书号”则都是用来描述书籍的基本信息的，因此应该作为“书籍”类的属性处理，而“规则”是指书号的生成规则，而书号则是书籍的一个属性，因此“规则”可以作为编写“书籍”类构造函数的指南。“基本信息”则是书名、作者、类别等描述书籍的基本信息统称，“关键字”则是代表其中之一，因此无需对其建模；“功能”、“新书籍”、“信息”、“记录”都是在描述需求时使用到的一些相关词语，并不是问题域的本质，因此先可以将其淘汰掉；Page170 “计算机类”、“非计算机类”是该系统中图书的两大分类，因此应该对其建模，并改名为“计算机类书籍”和“非计算机类书籍”，以减少歧义；“外借情况”则是用来表示一次借阅行为，应该成为一个候选类，多个外借情况将组成“外借情况列表”，而外借情况中一个很重要的角色是“朋友”—借阅主体。虽然到本系统中并不需要建立“朋友”的资料库，但考虑到可能会需要列出某个朋友的借阅情况，因此还是将其列为候选类。为了能够更好地表述，将“外借情况”改名为“借阅记录”，而将“外借情况列表”改名为“借阅记录列表”；“购买金额”、“册数”都是统计的结果，都是一个数字，因此不用将其建模，而“特定时限”则是统计的范围，也无需将其建模；不过从这里的分析中，我们可以发现，在该需求描述中隐藏着一个关键类—书籍列表，也就是执行统计的主体Page171 得到候选类在使用“名词动词法”寻找类的时候，很多团队会在此耗费大量的时间，特别是对于中大型项目，这样很容易迷失方向。其实在此主要的目的是对问题领域建立概要的了解，无需太过咬文嚼字Page172 关联分析，建模，多重性分析，再建模Page173 职责分析书籍类：从需求描述中，可找到书名、类别、作者、出版社；同时从统计的需要中，可得知“定价”也是一个关键的成员变量。书籍列表类：书籍列表就是全部的藏书列表，其主要的成员方法是新增、修改、查询（按关键字查询）、统计（按特定时限统计册数与金额）。借阅记录类：借阅人（朋友）、借阅时间。借阅记录列表类：主要职责就是添加记录（借出）、删除记录（归还）以及打印借阅记录Page174 限定与修改导航性分析：Book与BookList之间、BorrowRecord和BorrowList之间是组合关系均无需添加方向描述，而Book与BorrowRecord之间则是双方关联，也无需添加约束：Book对象创建后就不能够被删除只能被修改，因此在Book类边上加上用自由文本写的约束；一本书要么属于计算机类，要么属于非计算机类，因此在ItBook和OtherBook间加了“{Xor}”约束限定符：一本书只有一册，因此只能够被借一次，因此对于一本Book而言只能有一个RecordId与其对应Page175
