外文資料翻譯—英文原文河南科技大學管理學院畢業設計說明書DevelopmentProcessinUMLRationalUnifiedProcessAlthoughtheRationalUnifiedProcess(RUP)isindependentoftheUML,thetwoareoftentalkedabouttogether.SoIthinkit'sworthsayingafewthingsaboutithere.AlthoughRUPiscalledaprocess,itactuallyisaprocessframework,providingavocabularyandloosestructuretotalkaboutprocesses.WhenyouuseRUP,thefirstthingyouneedtodoischooseadevelopmentcase:theprocessyouaregoingtouseintheproject.Developmentcasescanvarywidely,sodon'tassumethatyourdevelopmentcasewilllookthatmuchlikeanyotherdevelopmentcase.ChoosingadevelopmentcaseneedssomeoneearlyonwhoisveryfamiliarwithRUP:someonewhocantailorRUPforaparticularproject'sneeds.Alternatively,thereisagrowingbodyofpackageddevelopmentcasestostartfrom.Whateverthedevelopmentcase,RUPisessentiallyaniterativeprocess.Awaterfallstyleisn'tcompatiblewiththephilosophyofRUP,althoughsadlyit'snotuncommontorunintoprojectsthatuseawaterfall-styleprocessanddressitupinRUP'sclothes.AllRUPprojectsshouldfollowfourphases.Inceptionmakesaninitialevaluationofaproject.Typicallyininception,youdecidewhethertocommitenoughfundstodoanelaborationphase.Elaborationidentifiestheprimaryusecasesoftheprojectandbuildssoftwareiniterationsinordertoshakeoutthearchitectureofthesystem.Attheendofelaboration,youshouldhaveagoodsenseoftherequirementsandaskeletalworkingsystemthatactsastheseedofdevelopment.Inparticular,youshouldhavefoundandresolvedthemajorriskstotheproject.Constructioncontinuesthebuildingprocess,developingenoughfunctionalitytorelease.Transitionincludesvariouslate-stageactivitiesthatyoudon'tdoiteratively.Thesemayincludedeploymentintothedatacenter,usertraining,andthelike.There'safairamountoffuzzinessbetweenthephases,especiallybetweenelaborationandconstruction.Forsome,theshifttoconstructionisthepointatwhichyoucanmoveintoapredictiveplanningmode.Forothers,itmerelyindicatesthepointatwhichyouhaveabroadvisionofrequirementsandanarchitecturethatyouthinkisgoingtolasttherestoftheproject.Sometimes,RUPisreferredtoastheUnifiedProcess(UP).ThisisusuallydonebyorganizationsthatwishtousetheterminologyandoverallstyleofRUPwithoutusingthelicensedproductsofRationalSoftware.YoucanthinkofRUPasRational'sproductofferingbasedontheUP,oryoucanthinkofRUPandUPasthesamething.Eitherway,you'llfindpeoplewhoagreewithyou.FittingtheUMLintoaProcessWhentheylookatgraphicalmodelinglanguages,peopleusuallythinkoftheminthecontextofawaterfallprocess.Awaterfallprocessusuallyhasdocumentsthatactasthehandoffsbetweenanalysis,design,andcodingphases.Graphicalmodelscanoftenformamajorpartofthesedocuments.Indeed,manyofthestructuredmethodsfromthe1970sand1980stalkalotaboutanalysisanddesignmodelslikethis.Whetherornotyouuseawaterfallapproach,youstilldotheactivitiesofanalysis,design,coding,andtesting.Youcanrunaniterativeprojectwith1-weekiterations,witheachweekaminiwaterfall.UsingtheUMLdoesn'tnecessarilyimplydevelopingdocumentsorfeedingacomplexCASEtool.ManypeopledrawUMLdiagramsonwhiteboardsonlyduringameetingtohelpcommunicatetheirideas.RequirementsAnalysisTheactivityofrequirementsanalysisinvolvestryingtofigureoutwhattheusersandcustomersofasoftwareeffortwantthesystemtodo.AnumberofUMLtechniquescancomeinhandyhere:Usecases,whichdescribehowpeopleinteractwiththesystem.Aclassdiagramdrawnfromtheconceptualperspective,whichcanbeagoodwayofbuildinguparigorousvocabularyofthedomain.Anactivitydiagram,whichcanshowtheworkflowoftheorganization,showinghowsoftwareandhumanactivitiesinteract.Anactivitydiagramcanshowthecontextforusecasesandalsothedetailsofhowacomplicatedusecaseworks.Astatediagram,whichcanbeusefulifaconcepthasaninterestinglifecycle,withvariousstatesandeventsthatchangethatstate.Whenworkinginrequirementsanalysis,rememberthatthemostimportantthingiscommunicationwithyourusersandcustomers.Usually,theyarenotsoftwarepeopleandwillbeunfamiliarwiththeUMLoranyothertechnique.Evenso,I'vehadsuccessusingthesetechniqueswithnontechnicalpeople.Todothis,rememberthatit'simportanttokeepthenotationtoaminimum.Don'tintroduceanythingthatspecifictothesoftwareimplementation.BepreparedtobreaktherulesoftheUMLatanytimeifithelpsyoucommunicatebetter.ThebiggestriskwithusingtheUMLinanalysisisthatyoudrawdiagramsthatthedomainexpertsdon'tfullyunderstand.Adiagramthatisn'tunderstoodbythepeoplewhoknowthedomainisworsethanuseless;allitdoesisbreedafalsesenseofconfidenceforthedevelopmentteam.DesignWhenyouaredoingdesign,youcangetmoretechnicalwithyourdiagrams.Youcanusemorenotationandbemorepreciseaboutyournotation.Someusefultechniquesare：Classdiagramsfromasoftwareperspective.Theseshowtheclassesinthesoftwareandhowtheyinterrelate.Sequencediagramsforcommonscenarios.AvaluableapproachistopickthemostimportantandinterestingscenariosfromtheusecasesanduseCRCcardsorsequencediagramstofigureoutwhathappensinthesoftware.Packagediagramstoshowthelarge-scaleorganizationofthesoftware.Statediagramsforclasseswithcomplexlifehistories.Deploymentdiagramstoshowthephysicallayoutofthesoftware.Manyofthesesametechniquescanbeusedtodocumentsoftwareonceit'sbeenwritten.Thismayhelppeoplefindtheirwayaroundthesoftwareiftheyhavetoworkonitandarenotfamiliarwiththecode.Withawaterfalllifecycle,youwoulddothesediagramsandactivitiesaspartofthephases.Theend-of-phasedocumentsusuallyincludetheappropriateUMLdiagramsforthatactivity.AwaterfallstyleusuallyimpliesthattheUMLisusedasablueprint.Inaniterativestyle,theUMLdiagramscanbeusedineitherablueprintorasketchstyle.Withablueprint,theanalysisdiagramswillusuallybebuiltintheiterationpriortotheonethatbuildsthefunctionality.Eachiterationdoesn'tstartfromscratch;rather,itmodifiestheexistingbodyofdocuments,highlightingthechangesinthenewiteration.Blueprintdesignsareusuallydoneearlyintheiterationandmaybedoneinpiecesfordifferentbitsoffunctionalitythataretargetedfortheiteration.Again,iterationimpliesmakingchangestoanexistingmodelratherthanbuildinganewmodeleachtime.UsingtheUMLinsketchmodeimpliesamorefluidprocess.Oneapproachistospendacoupleofdaysatthebeginningofaniteration,sketchingoutthedesignforthatiteration.Youcanalsodoshortdesignsessionsatanypointduringtheiteration,settingupaquickmeetingforhalfanhourwheneveradeveloperstartstotackleanontrivialfunction.Withablueprint,youexpectthecodeimplementationtofollowthediagrams.Achangefromtheblueprintisadeviationthatneedsreviewfromthedesignerswhodidtheblueprint.Asketchisusuallytreatedmoreasafirstcutatthedesign;if,duringcoding,peoplefindthatthesketchisn'texactlyright,theyshouldfeelfreetochangethedesign.Theimplementorshavetousetheirjudgmentastowhetherthechangeneedsawiderdiscussiontounderstandthefullramifications.Oneofmyconcernswithblueprintsismyownobservationthatit'sveryhardtogetthemright,evenforagooddesigner.Ioftenfindthatmyowndesignsdonotsurvivecontactwithcodingintact.IstillfindUMLsketchesuseful,butIdon'tfindthattheycanbetreatedasabsolutes.Inbothmodes,itmakessensetoexploreanumberofdesignalternatives.It'susuallybesttoexplorealternativesinsketchmodesothatyoucanquicklygenerateandchangethealternatives.Onceyoupickadesigntorunwith,youcaneitherusethatsketchordetailitintoablueprint.DocumentationOnceyouhavebuiltthesoftware,youcanusetheUMLtohelpdocumentwhatyouhavedone.Forthis,IfindUMLdiagramsusefulforgettinganoverallunderstandingofasystem.Indoingthis,however,IshouldstressthatIdonotbelieveinproducingdetaileddiagramsofthewholesystem.ToquoteWardCunningham[Cunningham]:Carefullyselectedandwell-writtenmemoscaneasilysubstitutefortraditionalcomprehensivedesigndocumentation.Thelatterrarelyshinesexceptinisolatedspots.Elevatethosespots...andforgetabouttherest.Ibelievethatdetaileddocumentationshouldbegeneratedfromthecode—like,forinstance,JavaDoc.Youshouldwriteadditionaldocumentationtohighlightimportantconcepts.Thinkoftheseascomprisingafirststepforthereaderbeforeheorshegoesintothecode-baseddetails.Iliketostructuretheseasprosedocuments,shortenoughtoreadoveracupofcoffee,usingUMLdiagramstohelpillustratethediscussion.Ipreferthediagramsassketchesthathighlightthemostimportantpartsofthesystem.Obviously,thewriterofthedocumentneedstodecidewhatisimportantandwhatisn't,butthewriterismuchbetterequippedthanthereadertodothat.Apackagediagrammakesagoodlogicalroadmapofthesystem.Thisdiagramhelpsmeunderstandthelogicalpiecesofthesystemandseethedependenciesandkeepthemundercontrol.Adeploymentdiagram,whichshowsthehigh-levelphysicalpicture,mayalsoproveusefulatthisstage.Withineachpackage,Iliketoseeaclassdiagram.Idon'tshoweveryoperationoneveryclass.Ishowonlytheimportantfeaturesthathelpmeunderstandwhatisinthere.Thisclassdiagramactsasagraphicaltableofcontents.Theclassdiagramshouldbesupportedbyahandfulofinteractiondiagramsthatshowthemostimportantinteractionsinthesystem.Again,selectivityisimportanthere;rememberthat,inthiskindofdocument,comprehensivenessistheenemyofcomprehensibility.Ifaclasshascomplexlife-cyclebehavior,Idrawastatemachinediagramtodescribeit.Idothisonlyifthebehaviorissufficientlycomplex,whichIfinddoesn'thappenoften.I'lloftenincludesomeimportantcode,writteninaliterateprogramstyle.Ifaparticularlycomplexalgorithmisinvolved,I'llconsiderusinganactivitydiagrambutonlyifitgivesmemoreunderstandingthanthecodealone.IfIfindconceptsthatarecominguprepeatedly,Iusepatternstocapturethebasicideas.Oneofthemostimportantthingstodocumentisthedesignalternativesyoudidn'ttakeandwhyyoudidn'tdothem.That'softenthemostforgottenbutmostusefulpieceofexternaldocumentationyoucanprovide.文章出處：MartinFowler.UMLDistilled:ABriefGuidetotheStandardObjectModelingLanguage.Publisher:AddisonWesley，2024，51-71外文資料翻譯—中文譯文UML中的開發流Rational統一開發流程雖然Rational統一〔開發〕流程〔RUP〕跟UML并無關系，但人們經常會把兩者相提并論。所以我想這里提一下它應該是值得的。RUP盡管被稱為開發流程，但事實上它是一個開發流程框架，里面提供了跟開發流程有關的一整組字匯與松散的結構。當你使用RUP時，要做的第一件事就是選出自己的開發案例：它是你在工程中將會施行的開發流程。開發案例間的變異很大，所以不要奢望你的開發案例看起來會跟其它開發案例的相似度太大。選出自己的開發案例需要有人事先就非常熟悉RUP，這個人可以針對特定工程的需要去裁減RUP。另一方面，我們也可以從越來越多的套裝開發案例中挑一個出來，以此為根底裁減它。不管你的開發案例是什么，RUP本質上都是反復式開發流程。瀑布式開發風格并不符合RUP的精髓，但是讓人很難過的是，我們經常可以發現很多工程在執行時，雖然宣稱是用RUP，實質上用的卻是瀑布式風格的開發流程。所有的RUP工程都必須遵循下面四個開發階段。1.初始階段：它會對工程做出一個最初的評估結果。一般來說，我們在初始階段中會決定是否要花費足夠的資金來進行詳述階段。2.詳述階段：它會找出工程的主要使用案例，并且會在幾次反復中寫出軟件，以便讓系統的架構成形。在詳述階段結束時，你應該對需求有很好的體會，而且會有一個大致上成形、可運行的系統，我們將把它當作后續開發工作的源頭。很特別的一點是，你應該已經找到工程的主要風險所在，也把它們解決掉了才對。3.建構階段：它會繼續進行寫軟件的過程，寫出夠發行出去的功能性。4.轉換階段：里面會有各式各樣后期、不需要反復進行的開發活動，可能會包含將軟件配置到數據中心、使用者訓練等等類似的事項。在這些開發階段間，有相當多糊涂的地方，特別是詳述階段與建構階段間更是如此。對某些人來說，他們會在作業模式轉到預測式規劃方式時。不過，對其他人來說，轉換開發階段可能只代表他們對需求有廣泛的了解，而且他們認為可持續到工程其它局部結束的架構，也已經存在了。有時候，我們會把RUP稱做統一〔開發〕流程。這么做的原因通常是因為這個組織想要用RUP的術語與整體開發風格，不過卻不想用Ratioanl軟件公司所授權的產品。你可以把RUP視為Rational司以UP為根底所提供的產品，或者干脆把RUP跟UP視為相同東西。不管采用哪一種說法，大家都能夠接受。在開發流程中使用UML當大家在使用圖形模型語言時，心里面通常會以瀑布式開發流程的情境來看待它。瀑布式開發流程在分析、設計與撰寫程序開發階段中，通常會用文件來交接工作。圖形模型通常是這些文件中的主要局部。事實上，從1970、1980年代以來，結構化的方法論中都會談到很多像這樣的分析與設計模型。不管你是不是采用瀑布式解決方案，我們都依然會做分析、設計、寫程序與測試等開發活動。你可以在具有一個星期長的反復式工程中，每個星期施行一次微型的瀑布式開發流程。使用UML其實并沒有隱含說一定要制作文件，或者引進一套復雜的CASE工具。有許多人只會在會議中用白板畫出UML的圖，幫助他們溝通想法。需求分析在需求分析開發活動中，我們會試圖了解：針對我們將花費功夫的軟件，它的使用者與顧客究竟想要系統做些什么事。下面是我們手頭上可用來進行需求分析的一些UML現有相關技術：使用用例圖，我們會在里面描述人們是如何跟系統互動的。由概念性觀點所畫出來的類別圖，它是我們可拿來建構出領域中一組精確字匯的好方法。活動圖里面可顯示出組織的工作流程，以了解軟件跟人類活動間是如何互動的。我們可以用活動圖表達出使用案例的背景環境，也可以顯示出某個復雜使用案例內部是如何運作的詳細情形。狀態圖，如果某個概念具有一種有趣的生命周期時，它就會變得很有用，里面會顯示出各種狀態，以及改變狀態的事件。當我們在進行需求分析時，請記住其中最重要的一件事是跟你的使用者與顧客溝通。一般來說，他們不是軟件開發人員，也對UML或其它技術不熟悉。縱然如此，我還是曾經成功地在一些不具有技術相關背景的人身上使用這些技術。不過，當我們這么做時，請記得要盡量少用一些表示法。不管任何時候，只要是有助于溝通，我們心里面都要有打破那些UML規那么的準備。分析時用UML的最大風險就是：那些領域專家無法完全理解你所畫的圖。如果了解領域的人無法理解這張圖，那么它所造成的后果比沒有用更糟；因為它會引起大家對開發團隊的不信任感。設計當你在進行設計工作時，你可以在圖中參加更多技術細節。這時候，可以使用更多的表示法，也可讓表示法更加精確。一些有用的相關技術包括：由軟件觀點所畫出的類別圖，里面會顯出軟件中的類別，以及它們間是如何相關的。常見活動的順序圖。有一種很有價值的做法是從使用案例中找出最重要、最有意思的活動，然后用CRC卡或循序圖畫出軟件中會發生什么情形。組件圖表達出軟件中大型結構的組織方式。針對有復雜生命歷程的類別，畫出它們的狀態圖。用配置圖畫出軟件的實體安排情形。一旦軟件已經寫好，那么上述這些技術當中，有許多也可以用來記錄文件。如果大家必須要在既有軟件上工作，而且不熟悉這些程序代碼，這時候就可以藉此讓大家理解這個軟件。采用瀑布式生命周期時，你應該在開發階段中畫出這些跟設計相關的開發活動。開發階段結束后的文件中，通常會有這個開發活動適宜的UML圖。瀑布式開發風格通常隱含我們把UML當成藍圖來用。在反復式開發風格中，我們可以把UML的圖當作藍圖，也可以把它們當作草稿。把它視為藍圖時，我們通常會在負責完成此功能性的反復之前的那次反復中，畫出分析圖，而且每次反復都不是從無到有；相反地，它是修該現有文件中的內容，并在新的反復中強調有變動的地方。將UML視為藍圖時，設計工作通常會在反復很早期就做完，而且可能會針對這次反