商業(yè)企業(yè)的購銷存管理信息系統(tǒng)的設(shè)計與實現(xiàn)

外文資料翻譯—英文原文河南科技大學(xué)管理學(xué)院畢業(yè)設(shè)計說明書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中的開發(fā)流Rational統(tǒng)一開發(fā)流程雖然Rational統(tǒng)一〔開發(fā)〕流程〔RUP〕跟UML并無關(guān)系，但人們經(jīng)常會把兩者相提并論。所以我想這里提一下它應(yīng)該是值得的。RUP盡管被稱為開發(fā)流程，但事實上它是一個開發(fā)流程框架，里面提供了跟開發(fā)流程有關(guān)的一整組字匯與松散的結(jié)構(gòu)。當(dāng)你使用RUP時，要做的第一件事就是選出自己的開發(fā)案例：它是你在工程中將會施行的開發(fā)流程。開發(fā)案例間的變異很大，所以不要奢望你的開發(fā)案例看起來會跟其它開發(fā)案例的相似度太大。選出自己的開發(fā)案例需要有人事先就非常熟悉RUP，這個人可以針對特定工程的需要去裁減RUP。另一方面，我們也可以從越來越多的套裝開發(fā)案例中挑一個出來，以此為根底裁減它。不管你的開發(fā)案例是什么，RUP本質(zhì)上都是反復(fù)式開發(fā)流程。瀑布式開發(fā)風(fēng)格并不符合RUP的精髓，但是讓人很難過的是，我們經(jīng)?？梢园l(fā)現(xiàn)很多工程在執(zhí)行時，雖然宣稱是用RUP，實質(zhì)上用的卻是瀑布式風(fēng)格的開發(fā)流程。所有的RUP工程都必須遵循下面四個開發(fā)階段。1.初始階段：它會對工程做出一個最初的評估結(jié)果。一般來說，我們在初始階段中會決定是否要花費足夠的資金來進(jìn)行詳述階段。2.詳述階段：它會找出工程的主要使用案例，并且會在幾次反復(fù)中寫出軟件，以便讓系統(tǒng)的架構(gòu)成形。在詳述階段結(jié)束時，你應(yīng)該對需求有很好的體會，而且會有一個大致上成形、可運行的系統(tǒng)，我們將把它當(dāng)作后續(xù)開發(fā)工作的源頭。很特別的一點是，你應(yīng)該已經(jīng)找到工程的主要風(fēng)險所在，也把它們解決掉了才對。3.建構(gòu)階段：它會繼續(xù)進(jìn)行寫軟件的過程，寫出夠發(fā)行出去的功能性。4.轉(zhuǎn)換階段：里面會有各式各樣后期、不需要反復(fù)進(jìn)行的開發(fā)活動，可能會包含將軟件配置到數(shù)據(jù)中心、使用者訓(xùn)練等等類似的事項。在這些開發(fā)階段間，有相當(dāng)多糊涂的地方，特別是詳述階段與建構(gòu)階段間更是如此。對某些人來說，他們會在作業(yè)模式轉(zhuǎn)到預(yù)測式規(guī)劃方式時。不過，對其他人來說，轉(zhuǎn)換開發(fā)階段可能只代表他們對需求有廣泛的了解，而且他們認(rèn)為可持續(xù)到工程其它局部結(jié)束的架構(gòu)，也已經(jīng)存在了。有時候，我們會把RUP稱做統(tǒng)一〔開發(fā)〕流程。這么做的原因通常是因為這個組織想要用RUP的術(shù)語與整體開發(fā)風(fēng)格，不過卻不想用Ratioanl軟件公司所授權(quán)的產(chǎn)品。你可以把RUP視為Rational司以UP為根底所提供的產(chǎn)品，或者干脆把RUP跟UP視為相同東西。不管采用哪一種說法，大家都能夠接受。在開發(fā)流程中使用UML當(dāng)大家在使用圖形模型語言時，心里面通常會以瀑布式開發(fā)流程的情境來看待它。瀑布式開發(fā)流程在分析、設(shè)計與撰寫程序開發(fā)階段中，通常會用文件來交接工作。圖形模型通常是這些文件中的主要局部。事實上，從1970、1980年代以來，結(jié)構(gòu)化的方法論中都會談到很多像這樣的分析與設(shè)計模型。不管你是不是采用瀑布式解決方案，我們都依然會做分析、設(shè)計、寫程序與測試等開發(fā)活動。你可以在具有一個星期長的反復(fù)式工程中，每個星期施行一次微型的瀑布式開發(fā)流程。使用UML其實并沒有隱含說一定要制作文件，或者引進(jìn)一套復(fù)雜的CASE工具。有許多人只會在會議中用白板畫出UML的圖，幫助他們溝通想法。需求分析在需求分析開發(fā)活動中，我們會試圖了解：針對我們將花費功夫的軟件，它的使用者與顧客究竟想要系統(tǒng)做些什么事。下面是我們手頭上可用來進(jìn)行需求分析的一些UML現(xiàn)有相關(guān)技術(shù)：使用用例圖，我們會在里面描述人們是如何跟系統(tǒng)互動的。由概念性觀點所畫出來的類別圖，它是我們可拿來建構(gòu)出領(lǐng)域中一組精確字匯的好方法?；顒訄D里面可顯示出組織的工作流程，以了解軟件跟人類活動間是如何互動的。我們可以用活動圖表達(dá)出使用案例的背景環(huán)境，也可以顯示出某個復(fù)雜使用案例內(nèi)部是如何運作的詳細(xì)情形。狀態(tài)圖，如果某個概念具有一種有趣的生命周期時，它就會變得很有用，里面會顯示出各種狀態(tài)，以及改變狀態(tài)的事件。當(dāng)我們在進(jìn)行需求分析時，請記住其中最重要的一件事是跟你的使用者與顧客溝通。一般來說，他們不是軟件開發(fā)人員，也對UML或其它技術(shù)不熟悉?？v然如此，我還是曾經(jīng)成功地在一些不具有技術(shù)相關(guān)背景的人身上使用這些技術(shù)。不過，當(dāng)我們這么做時，請記得要盡量少用一些表示法。不管任何時候，只要是有助于溝通，我們心里面都要有打破那些UML規(guī)那么的準(zhǔn)備。分析時用UML的最大風(fēng)險就是：那些領(lǐng)域?qū)＜覠o法完全理解你所畫的圖。如果了解領(lǐng)域的人無法理解這張圖，那么它所造成的后果比沒有用更糟；因為它會引起大家對開發(fā)團(tuán)隊的不信任感。設(shè)計當(dāng)你在進(jìn)行設(shè)計工作時，你可以在圖中參加更多技術(shù)細(xì)節(jié)。這時候，可以使用更多的表示法，也可讓表示法更加精確。一些有用的相關(guān)技術(shù)包括：由軟件觀點所畫出的類別圖，里面會顯出軟件中的類別，以及它們間是如何相關(guān)的。常見活動的順序圖。有一種很有價值的做法是從使用案例中找出最重要、最有意思的活動，然后用CRC卡或循序圖畫出軟件中會發(fā)生什么情形。組件圖表達(dá)出軟件中大型結(jié)構(gòu)的組織方式。針對有復(fù)雜生命歷程的類別，畫出它們的狀態(tài)圖。用配置圖畫出軟件的實體安排情形。一旦軟件已經(jīng)寫好，那么上述這些技術(shù)當(dāng)中，有許多也可以用來記錄文件。如果大家必須要在既有軟件上工作，而且不熟悉這些程序代碼，這時候就可以藉此讓大家理解這個軟件。采用瀑布式生命周期時，你應(yīng)該在開發(fā)階段中畫出這些跟設(shè)計相關(guān)的開發(fā)活動。開發(fā)階段結(jié)束后的文件中，通常會有這個開發(fā)活動適宜的UML圖。瀑布式開發(fā)風(fēng)格通常隱含我們把UML當(dāng)成藍(lán)圖來用。在反復(fù)式開發(fā)風(fēng)格中，我們可以把UML的圖當(dāng)作藍(lán)圖，也可以把它們當(dāng)作草稿。把它視為藍(lán)圖時，我們通常會在負(fù)責(zé)完成此功能性的反復(fù)之前的那次反復(fù)中，畫出分析圖，而且每次反復(fù)都不是從無到有；相反地，它是修該現(xiàn)有文件中的內(nèi)容，并在新的反復(fù)中強(qiáng)調(diào)有變動的地方。將UML視為藍(lán)圖時，設(shè)計工作通常會在反復(fù)很早期就做完，而且可能會針對這次反