UML2面向對象分析與設計(第2版)譚火彬全套教案課件_第1頁
UML2面向對象分析與設計(第2版)譚火彬全套教案課件_第2頁
UML2面向對象分析與設計(第2版)譚火彬全套教案課件_第3頁
UML2面向對象分析與設計(第2版)譚火彬全套教案課件_第4頁
UML2面向對象分析與設計(第2版)譚火彬全套教案課件_第5頁
已閱讀5頁,還剩855頁未讀 繼續免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領

文檔簡介

UML2面向對象分析與設計

Object-OrientedAnalysis&DesignwithUML2譚火彬第01章上升到面向對象AnApproachtotheObjectOrientation-3-第01章上升到面向對象第一個案例課程介紹面向對象技術對象和類面向對象技術相關原則上升到面向對象-4-第01章上升到面向對象第一個案例課程介紹面向對象技術對象和類面向對象技術相關原則上升到面向對象-5-素數問題素數的定義:除了1與本身之外,不能被其他正整數整除的數,叫作素數,也叫質數按照習慣規定,1不算素數,最小的素數是2,其余的是3、5、7、11、13、17、19……等等由定義判斷素數對于數n,從i=2,3,4,5…到n-1判斷n能否被i整除,如果全部不能整除,則n是素數,只要有一個能除盡,則n不是素數,為了壓縮循環次數,可將判斷范圍從2~n-1改為2~sqrt(n)-6-篩選法求素數序列篩選法:生成2<i<n的素數序列,設n=50篩掉2的倍數:234567891011121314151617…篩掉3的倍數:2357911131517192123252729…篩掉5的倍數:23571113171923252931353741…篩掉7的倍數:2357111317192329313741434749留下素數序列:23571113171923293137414347-7-思考?用結構化思維解決上述問題用對象思維解決上述問題將解決思路用合適的方式記錄下來思考:結構化思維與對象化思維有什么本質的不同?體現了怎樣的思維差異?對象思想有何優勢?如何表達設計思想:代碼?圖形?-8-結構化實現//PrimerNumber.cmain(){int*sieve,n;intiCounter=2,iMax,i;printf("Pleaseinputmaxnumber:");scanf(“%d",&n);sieve=malloc((n-1)*sizeof(int));for(i=0;i<n-1;i++){sieve[i]=i+2;}iMax=sqrt(n);while(iCounter<=iMax){for(i=2*iCounter-2;i<n-1;i+=iCounter)sieve[i]=0;iCounter++;}for(i=0;i<n-1;i++)if(sieve[i]!=0)printf("%d",sieve[i]);}-9-結構化設計-10-結構化小結通過流程圖(結構化建模)可以更清楚表達設計思想針對過程的抽象過程(函數)是系統的核心,通過過程實現系統功能數據是靜態的,由過程來控制對數據的訪問面向對象的方法如何解決呢?-11-Java實現-是對象思維嗎?importjava.lang.Math;publicclassPrimerNumber{publicstaticvoidmain(Stringargs[]){intn=50;intsieve[]=newint[n-1];intiCounter=2,iMax,i;for(i=0;i<n-1;i++){sieve[i]=i+2;}iMax=(int)Math.sqrt(n);while(iCounter<=iMax){for(i=2*iCounter-2;i<n-1;i+=iCounter)sieve[i]=0;iCounter++;}for(i=0;i<n-1;i++)if(sieve[i]!=0)System.out.println(sieve[i]);}}-12-用對象思維解決問題?篩選法:生成2<i<n的整數序列,設n=50篩掉2的倍數:234567891011121314151617…篩掉3的倍數:2357911131517192123252729…篩掉5的倍數:23571113171923252931353741…篩掉7的倍數:2357111317192329313741434749留下素數序列:23571113171923293137414347篩子:存儲源數據過濾器:表明當前過濾因子計數器:記錄當前正在篩選的數據什么是對象?對象在哪?-13-這才是對象思維!抽象基類,為程序提供多態-14-面向對象的編程—C++語法classItem{public: Item*source; Item(Item*src){source=src;}

virtualintout(){return0;}};classCounter:publicItem{ intvalue;public:

intout(){returnvalue++;} Counter(intv):Item(0){value=v;}};-15-面向對象的編程-過濾器classFilter:publicItem{ intfactor;public:

intout(){ while(1){ intn=source->out(); if(n%factor)returnn; } } Filter(Item*src,intf):Item(src){factor=f;}};-16-面向對象的編程-篩子classSieve:publicItem{public: intout(){ intn=source->out(); source=newFilter(source,n); returnn; } Sieve(Item*src):Item(src){}};-17-驗證設計方案voidmain(){ Counterc(2); Sieves(&c); intnext,n; cin>>n; while(1){

next=s.out(); if(next>n)break; cout<<next<<""; } cout<<endl;}關鍵代碼只有一行,

篩子自己知道如何找出素數-18-對象方法小結通過UML類圖(面向對象建模)可以更清楚表達設計思想,并為代碼實現提供框架針對數據的抽象:類類擁有自己的數據和行為,能夠完成自身的工作職責過程是類的組成部分,為類提供行為通過類的對象之間的協作完成系統功能-19-面向對象技術的思考對象思維具有更大的靈活性,更好的模塊化,可以進行更大規模的設計面向對象設計和開發的難度更大,面臨著對象識別、職責分配、多態抽象等一系列問題學習更多知識和技術,并掌握一系列面向對象的設計原則和模式圖形化工具(UML)有助于表達和交流設計思想,并簡化實現的過程-20-總結:結構化VS面向對象結構化思維用過程刻畫數據間關系對象思維直接用類表達數據間關系結構化中,數據是死的,全部依賴算法操作對象思維中,數據是活的,“她”知道自己的信息(屬性),并能完成自己的工作(操作)結構化思維更像是一個人在解決所有問題對象思維更像是一個團隊的分工協作-21-面向對象VS結構化-1揚棄,不是否定-22-面向對象VS結構化-2(程序)實現角度數據結構+算法=程序設計以對象為中心組織數據與操作數據對象屬性操作對象的行為類型與變量類與對象實例函數(過程)調用消息傳遞類型與子類型一般類與特殊類,繼承構造類型整體-部分結構,聚合指針關聯面向對象VS結構化-3傳統結構化方法面向對象方法(UML)需求模型輸入I、處理P、輸出O的視角,面向功能的文檔(用戶需求規格說明書)需求變化,其功能變化,所以系統的基礎不穩固從用戶和整體角度出發使用系統抽象出用例圖、活動圖,獲取需求;如需求變化,對象的性質相對功能穩定,系統基礎穩定分析模型面向過程的數據流圖DFD、實體—關系圖ERD、數據字典DD表示分析模型功能分解,數據和功能/過程分開把問題作為一組相互作用的實體,顯式表示實體間的關系數據模型和功能模型一致類、對象圖表示分析模型,狀態、順序、通信、活動圖細化說明設計模型功能模塊(SC圖),模塊之間的連接/調用是模塊的附屬形式類和對象實現,類/對象的關聯、聚集、繼承等連接、連接規范和約束作為顯式定義實現模型偽代碼、算法等構件圖,部署圖測試模型根據文檔進行單元測試,集成測試,確認測試單元測試采用類圖,集成測試用實現圖和交互圖,確認測試采用用例圖-23--24-第01章上升到面向對象第一個案例課程介紹面向對象技術對象和類面向對象技術相關原則上升到面向對象-25-課程目標三大目標:OO:建立對象的思維方式,對面向對象思想和理論有進一步的理解UML:能夠熟練地使用UML表達面向對象的設計思想Model:運用對象技術的一般原則和模式進行應用系統的分析和設計建模-26-課程目標(續)三大目標之間的關系Model:建模是最終目的OO:面向對象技術是一種建模理論UML:統一建模語言是一種體現OO的建模語言,是將OO理論轉化為實踐的工具-27-關于本課程…本課程是軟件工程類專業課程,側重于工程實踐能力的培養,強調分析和設計技能,不關注文檔、過程、規范等,重點在建模方法的應用過程驅動:圍繞分析和設計過程,關注各階段建模技術的應用案例驅動:圍繞具體案例,講解面向對象分析和設計的思維方式和解決問題的方法課程重點不是理論或知識,而是通過實踐建立對象思維方式,并培養運用UML來表達這種思維方式的技能,從而完成面向對象分析和設計通過課外閱讀、作業和實踐來彌補課堂不足不考概念,不需死記硬背,在實踐中掌握相關理論和方法為什么選擇本課程?需要理由嗎?我們從事軟件行業面向對象是最主流的軟件開發思想UML是最主流的建模方法-28-UMLOOAD軟件工程師的“飯碗”對于今天的軟件開發者來說,UML是他們的面包和黃油-29-本課程適合我?基礎知識儲備:軟件工程、面向對象程序設計實踐儲備:了解工程項目的特點,最好有實際工程項目開發背景定位從事軟件相關行業工作:分析、設計、編碼、測試或管理、維護工作-30-課程安排1基礎(3):

上升到面向對象2基礎(3):

可視化建模技術3起源(2):

業務建模4需求(4):

用例建模5分析(3):

用例分析6設計基礎(3):

面向對象設計原則7設計基礎(3):

面向對象設計模式8設計(3):

架構設計9設計(3):

構件設計10實現&展望(3):

從模型到代碼

模型技術的發展-31-學習路線圖OOUMLOOPDP…

教學案例

…學習路線圖……

……

……

……12345678910-32-考核方式作業(50%)結合課程進度,圍繞一個案例,安排多次實踐作業根據情況對作業進行詳細講解考試(50%)課程結束后安排考試開卷課程教材自編教材:UML2面向對象分析與設計(第2版),清華大學出版社,2019.01在多年授課經驗基礎上整理而成主要按照此教材內容講解ISBN:978-7-302-50698-0-33-其它參考資料ApplyingUMLandPatterns-AnIntroductiontoObject-OrientedAnalysisandDesignUML和模式應用-面向對象分析與設計導論Object-OrientedAnalysisandDesignwithApplications(3rd)面向對象分析與設計(第3版),UML創始人GradyBooch的代表作TheUnifiedModelingLanguageUserGuide(UML用戶指南,第二版)GradyBooch,JamesRumbaugh,IvarJacobsonUMLDistilled(3rd):ABriefGuidetotheStandardObjectModelingLanguageUML精粹:標準對象建模語言簡明指南-34--35-第01章上升到面向對象從結構化到面向對象課程介紹面向對象技術對象和類面向對象技術相關原則上升到面向對象-36-面向對象技術是一種看待計算機軟件系統的觀點是一種系統分析和設計的思想是一種編程方法是一組設計原則和模式是實踐者的日常工作是吹鼓手、騙子和市場人員口中的“萬靈丹”面向對象技術面向對象技術是一系列指導軟件構造的原則(如抽象、封裝、多態等),并通過語言、數據庫和其它工具來支持這些原則從本質上講,對象技術對一系列相關原則的應用面向對象技術=類+對象+抽象+封裝+繼承+多態+消息…-37--38-面向對象技術的發展歷史Simula基本思想19671972Smalltalk實用化C++

商業化1980s1995Java

編程方法的成熟UML

統一方法學19972010+構件

服務

云計算

(縱深發展)-39-面向對象技術的優勢-1溝通順應人類思維習慣,讓軟件開發人員在解空間中直接模擬問題空間中的對象及其行為PUSHEBXMOVEBX,EDXMOVEDX,EAXSHREDX,16DIVBXAHare.Run;ALion.Catch(AHare);ALion.Kill(AHare);AHare.Dead;ALion.Eat;ALion.Happy;在計算機中模擬現實世界的事和物-40-實例:“東北一家人”東北人都是活雷鋒人、東北人、雷鋒老張開車去東北……撞啦!老張、汽車、開車撞啦-41-class人

{Region籍貫;}classRegion{}interface雷鋒

{helpPeople(){}}class東北人

extends人implements雷鋒

{

籍貫=東北;

helpPeople(){}}classCar{DriveTo(Region)throwsException(撞車){}

人Driver;}MainProgram{

人老張;

Car夏利;夏利.Driver=老張;

try{

夏利.DriveTo(東北);}catch(Exception){}}面向對象的表示-42-面向對象技術優勢-2穩定較小的需求變化不會導致系統結構大的改變當需求變化時……功能:最易變數據:較易變對象:較穩定穩定性增加用較穩定把不穩定的包起來-43-面向對象技術優勢-3復用代碼重用:類庫、框架等重用機制能提高質量,減少由于編制新的系統代碼而產生的成本通過繼承、關聯、封裝等手段軟件開發組越大,組中每個成員的生產率就越低--PhilippeKahn,Borland公司創始人構造大型軟件不能靠堆人-44-第01章上升到面向對象從結構化到面向對象課程介紹對象技術對象和類對象技術相關原則上升到面向對象對象對象(Object)是一個實體、一件事、一個名詞,可以獲得的某種東西,可以想象有自己標識的任何事物物理實體概念實體軟件實體-45-化學過程鏈表對象-正式定義對象是一個實體,這個實體:具有明確定義的邊界和標識邊界意味著對象是一個封裝體,通過封裝來與其它對象分隔標識則表明每一個對象都是唯一的對象封裝了狀態和行為對象的狀態通過對象的屬性(attribute)和關系(relationship)來表達對象的行為通過對象的操作(operation)、方法(method)和狀態機(statemachine)來表達-46-在UML中表示對象在UML中,對象用矩形框來表示,對象的名字寫在矩形框內部,并加上下劃線來表示-47-對象名+類名只有類名(匿名對象)只有對象名類類就是一系列對象的抽象描述,這些對象共享相同的屬性、操作、關系和語義一個具體的對象是該類的一個實例類是一種抽象將相似的實體抽象成相同的概念抽象過程強調相關特征而忽略其它的特征-48--49-示例:類類Employee屬性NameAddressPositionSalaryStartDateEndDate操作HireFirePromoteIncreaseSalaryRetireUML中的類在UML中,采用矩形框表示類,可以將矩形框劃分為三個區域,分別表示類名、屬性和操作-50-屬性操作屬性屬性(attribute)是類的特征或特性屬性的值是某一特定對象的屬性值在類中屬性名必須是唯一的每一個類的實例都有為這個類定義的所有屬性的值-51-銀行帳戶類屬性帳號銀行名稱擁有者金額Mary的銀行帳戶屬性值12345678FirstNationalBankMarySmith$1024.48-52-操作操作(operation)訪問或修改對象的屬性值對象的行為是由為此對象定義的一系列操作決定的一個類可能同時存在多個實例,也可能在某一時刻沒有實例一個類的所有實例都可以使用在這個類中定義的操作-53-類和對象對象實體類抽象數據類型計算機世界實例化抽象映射映射現實世界-54-內容安排從結構化到面向對象課程介紹面向對象技術對象和類面向對象技術相關原則上升到面向對象-55-面向對象技術相關原則面向對象技術基本原則抽象(Abstraction)封裝(Encapsulation)分解(Decomposition)泛化(Generalization)多態(Polymorphism)分層(Hierarchy)復用(Reuse)……-56-抽象-Abstraction抽象是揭示事物區別于其他事物的本質特征的過程是一個分析和理解問題的過程抽象的結果取決于使用者的目的,應該包括使用者所感興趣的那些職責,而忽略掉其它不相關的部分對象到類的過程就是抽象即將所見到的具體實體抽象成概念,從而在計算機世界中進行描述和各種操作如何進行抽象的?左圖中存在哪些類?抽象取決于項目的上下文(需求)人男人、女人老板、員工老師、學生57-58-封裝-Encapsulation封裝是對客戶(使用者)隱藏具體實現細節客戶只依賴于接口通過封裝實現信息隱藏和數據抽象-59-為什么要封裝結構化程序設計:程序=算法+數據結構全局數據算法算法算法算法如何保證數據的一致性?-60-范例:數據一致性struct

ShippingAddress{longcityCode;Stringaddress;}城市代碼例如:北京為01上海為02郵政地址“北京朝陽區靜安里6號”操作這個數據結構的程序員,必須嚴格遵守一系列業務邏輯規則,否則很容易破壞數據的一致性結構化程序設計處理大項目時,多人協同開發時,本質上無法保證數據的一致性class

ShippingAddress{

privatelongcityCode;

privatestringaddress;

publiclongModifyAddress(Stringaddress)}-61-封裝:可見性問題Visibility-可見性層次public:+package:~protected:#private:-作用域(類/方法),默認作用域friend友元分解-Decomposition分解是指將單個大規模復雜系統劃分為多個不同的小構件分解的構件通過抽象、封裝等技術形成相對獨立的單元,可以獨立設計和開發,從而實現化繁為簡、分而治之分解的方法結構化方法:函數、模塊進行功能分解面向對象:基于類和對象的分解基礎上,進行合理的打包和分層,從而形成更加復雜的分解結構-62--63-泛化-Generalization是類之間的一種“是”(isa/iskindof)關系,通過該關系一個類(子類)可以共享另外一個或多個類(父類)的結構和行為采用繼承(Inheritance)實現泛化關系通過泛化關系,可以建立類之間的層次結構,根據繼承層次中父類的個數不同,分為:單一繼承多重繼承-64-單一繼承一個類繼承另外一個類-65-多重繼承一個類繼承另外多個類Usemultipleinheritanceonlywhenneededandalwayswithcaution!繼承子類繼承父類所有的內容:屬性、操作、關系和語義其訪問權限仍受可見性的約束子類還可以:添加新的屬性、操作、關系和語義重定義繼承的操作(小心!)設計繼承層次父類定義公共的屬性、操作、關系和語義針對不同的情況定義不同的子類,以擴展父類的屬性、操作、行為和語義-66-范例:繼承什么?classStudent{ protectedstringname;

publicstringgetName(){…}

publicAccounttheAccount;

}classGraduateStudentextendsStudent{

}派生類(子類)從基類(超類、父類)中派生,繼承了基類全部數據成員和方法。所以即使GraduateStudent中沒有定義getName(),也會從Student中得到getName()方法的全部實現派生類也會繼承基類中的關系,因此GraduateStudent與Account也有聚合關系-67--68-多態-Polymorphism多態是在統一外表(接口)下隱藏不同實現的能力即一個接口可以有不同的實現行為是面向對象技術的本質特征-69-范例:多態classabstractShape{publicabstractvoiddraw();}classRectangleextendsShape{//覆蓋(override)基類方法

publicvoiddraw(){...

/*繪制矩形*/}}classCircleextendsShape{

//覆蓋(override)基類方法

publicvoiddraw(){…

/*繪制圓形*/}}-70-應用多態性假設我們有一個數組sharr,里面放著一排Shape,但是不知道哪些是Rectangle,哪些是Circle。利用多態性,我們可以:

for(inti=0;i<sharr.length;++i){ Shapeshape=(Shape)sharr[i]; shape.draw(); }遍歷整個數組的過程中,各個Shape自己知道應當如何在畫布上繪制自己。shape.draw()這同一行代碼在shape指向不同的對象時表現出不同的行為,這就是所謂多態性分層(Hierarchy)分層是指面向不同的目標建立不同的抽象級別層次,從而在不同的抽象層次對系統進行分解,進一步簡化對系統的理解兩種分層結構類層次結構:在不同的抽象級別進行對象的抽象,通過泛化關系,行程類間的繼承層次結構對象層次結構:是指對象間的組成結構,即大的對象由小的對象組成-71-兩種層次結構-72-復用(Reuse)復用是借助于已有軟件的各種有關知識建立新的軟件的過程將軟件看成是由不同功能部分的構件所組成的有機體,每個構件在設計編寫時可以被設計成完成同類工作的通用工具如果完成各種工作的構件被建立起來以后,編寫特定軟件的工作就變成了將各種不同構件進行組合的簡單問題,從而對軟件產品的最終質量和維護工作都有本質性的改變-73-應用復用原則系統開發各個階段都可能涉及到復用從最底層的代碼復用,到設計復用、架構復用,再到需求復用,甚至于延伸到特定業務領域的復用復用原則要求設計者不僅針對當前的業務需求開展設計,還需要考慮業務的通用性和可擴展性等問題,從而設計抽象層次高、復用粒度大的組件-74--75-第01章上升到面向對象從結構化到面向對象課程介紹對象技術對象和類對象技術相關原則上升到面向對象-76-本節目標通過簡單通俗的事例來演繹對象建模的基本概念,初步認識UML模型開闊視野,輕松樹立面向對象的觀點掌握用面向對象方法分析問題的要領為學習對象建模方法熱身-77-實例1:OO觀點的個人簡介tanHuobin是Teacher類的一個實例,該實例是基于beiHangUniversity對象的softwareSchool成員對象工作類GraduateStudent的所有實例都可以通過Course類對象ooTechnology建立關聯,并可發送phone消息(消息內容或email消息(消息內容:thbin@)-78-OO個人簡介的UML表示-79-實例2:對象思維分析問題昨天我的一個朋友結婚了-80-問題分析-1A.這里面有什么事物?月老,小伙,姑娘,戀人,玫瑰花B.每個事物看上去是什么樣的?月老,看上去有些年紀了,挺熱心的小伙,看上去很強壯,很誠實的姑娘,看上去好漂亮,還很溫柔戀人,看上去很黏糊,當然就結婚了玫瑰花,火紅火紅的,難怪姑娘動情了-81-問題分析-2C.每個事物能做點什么用?月老:牽線搭橋,介紹認識小伙:追求獻花,表達愛意姑娘:仰慕傾情,以身相許戀人:拍拖,…,結婚玫瑰花:令姑娘頭暈,傳情示愛-82-問題分析-3D.這些事物都呆在什么地方?月老:婚介所,交友網站小伙:軟件園,住回龍觀姑娘:人民醫院,住望京戀人:情侶路,電影院,…玫瑰花:花店里,小伙手中,姑娘手中-83-問題分析-4E.這些事物之間有什么關系?關系月老小伙姑娘戀人玫瑰月老干媽舅媽撮合者沒關系小伙干兒子男友老公男主角買送主姑娘外甥女女友太太女主角受主戀人作品組成組成使用者玫瑰沒關系信物受物心意信物-84-問題分析-5F.這些事物是怎么成事的?月老牽線搭橋,介紹小伙和姑娘認識姑娘和小伙一見鐘情,成為一對戀人一對戀人開始拍拖小伙追求獻花,表達對姑娘的愛意姑娘收到999火紅玫瑰,激動得頭暈目眩小伙真心求婚,姑娘以身相許一對戀人終于走入婚姻殿堂-85-—上升到面向對象—

用面向對象觀點觀看事物用對象觀點認識事物A.這里面有什么事物?

類和對象B.每個事物看上去是什么樣的?

類的屬性C.每個事物能做點什么用?

類的操作D.這些事物都呆在什么地方?

類的狀態、部署E.這些事物之間有什么關系?

類之間間的關聯F.這些事物是怎么成事的?

類之間間的交互(用例實現)-86-DACBEF我的一個朋友結婚了-AA.這里面有什么事物?對象

類我—本劇與我無關我的朋友 小伙我朋友的妻子 姑娘月老戀人玫瑰……-87-DACBEF我的一個朋友結婚了-BB.每個事物看上去是什么樣的?每個事物看上去都有自己的屬性,在每個屬性上都有一個特征值(對象的屬性)小伙:體格,特征值:強壯姑娘:性情,特征值:溫柔月老:年紀,特征值:較大戀人:關系,特征值:黏糊玫瑰花:顏色,特征值:火紅-88-DACBEF我的一個朋友結婚了-CC.每個事物能做點什么用?每個事物都具備某種能力(對象的操作)小伙:追求、送花、娶親姑娘:愛慕、相許、出嫁月老:牽線搭橋玫瑰:示愛-89-DACBEF我的一個朋友結婚了-DD.這些事物都呆在什么地方?每個事物都會有它合理的或者必須的空間位置和邏輯位置。尤其當這些位置對事物的行為造成重要影響的時候,表明他們的位置極其重要本劇列出的位置對故事主要情節沒有太大的影響,系統中不予考慮-90-DACBEF我的一個朋友結婚了-EE.這些事物之間有什么關系?事物之間的關系非常多,面向對象的觀點一般分為主要的三類(關系):整體-部分關系(聚合和組合),甲是乙的一個組成部分:如戀人和小伙,戀人和姑娘的關系抽象-具體關系(泛化),甲是乙的一個特例:如人和小伙,人和月老,人和姑娘的關系協作關系(關聯),甲會對乙做點什么:如月老和小伙、姑娘,小伙和玫瑰,小伙和姑娘的關系-91-DACBEF我的一個朋友結婚了-FF.這些事物是怎么成事的?(協作)每個事物都會盡量利用伙伴的能力整體事物的能力依靠部分事物的能力抽象事物的屬性和能力就是具體事物的屬性和能力;具體事物除了有抽象事物的屬性和能力外,還可以有自己特殊的事物分工協作,互通信息,共同完成整體的目標面向對象的分析和設計的核心-92-DACBEF-93-俗語和術語間的對應俗語術語例子出了什么事?用例我的一個朋友結了婚。具體事物對象我的一個朋友,他未婚妻…事物類型類小伙,姑娘,玫瑰,月老…屬性屬性年齡,體格,性情…能力操作牽線,追求,結婚…位置部署軟件園,情侶路…整-部關系聚合關系戀人-小伙,戀人-姑娘抽-具關系繼承關系人-小伙,人-姑娘協作關系關聯關系小伙-姑娘,小伙-玫瑰成事過程協作(用例實現)相識,相戀,結婚-94-—上升到面向對象—

用UML表達面向對象觀點-95-利用UML描述分析過程完整故事情節的靜態模型-96-搞清過程的活動圖-97-復述情節的順序圖初次見面順序圖-98-理清頭緒的通信圖-99-定點觀察的狀態機圖謝謝!UML2面向對象分析與設計

Object-OrientedAnalysis&DesignwithUML2譚火彬第02章可視化建模基礎EssentialsofVisualModelingwithUML2學習路線圖-103-OOUMLOOPDP…

教學案例

…學習路線圖……

……

……

……12345678910-104-第02章可視化建模基礎可視化建模基礎統一建模語言UML2組成結構UML2概念模型應用UML2建模-105-第02章可視化建模基礎可視化建模基礎統一建模語言UML2組成結構UML2概念模型應用UML2建模-106-模型模型是現實世界的簡化模型的重要性-107-紙飛機噴氣式戰斗機不重要非常重要建模的目的建模的根本目的是為了更好地理解待開發的系統模型有助于按照所需的樣式可視化(Visualize)目標系統模型能夠描述(Specify)系統的結構和行為模型提供構造(Construct)系統的模板模型可以文檔化(Document)設計決策-108--109-建模的基本原則建模過程需要遵循的原則選擇合適的模型:所創建的模型對解決方案的形成具有重要的影響模型具有不同的精確程度:面向不同的用戶提供不同抽象層次的模型好的模型是與現實相聯系的:簡化不能掩蓋掉任何重要的細節單一的模型是不夠的:需要從多個視角創建不同的模型-110-第02章可視化建模基礎可視化建模基礎統一建模語言UML2組成結構UML2概念模型應用UML2建模-111-統一建模語言(UML)UML—YouMustLearnUML—UnifiedModelingLanguageUML是一種標準的圖形化建模語言,是面向對象分析與設計的標準表示,它:不是一種程序設計語言,而是一種可視化的建模語言(用于分析設計)不是工具或知識庫的規格說明,而是一種建模語言規格說明,是一種模型表示的標準不是過程,也不是方法,但允許任何一種過程和方法使用它-112-WhatIs統一建模語言?統一建模語言isalanguageforVisualizingSpecifyingConstructingDocumentingtheartifactsofasoftware-intensivesystemUnifiedModelingLanguage(統一建模語言)是對象管理組織(OMG)制定的一個通用的、可視化的建模語言標準,可以用來可視化(visualize)、描述(specify)、構造(construct)和文檔化(document)軟件密集型系統的各種工件(artifacts,又譯制品)-113-選擇UML很多情況下,推薦使用UML:1)OO方法是項目決定采用的方法論,是整個項目或產品成功的關鍵2)開發人員感覺用源碼說明不了真正的問題,希望提高交流效率3)系統的規模和設計都比較復雜,需要用圖形抽象地表達復雜概念,降低開發風險4)組織希望記錄已成功項目、產品的設計方案,在開發新項目時可以參考、復用過去的設計5)有必要采用一套通用的圖形語言和符號體系描述組織的業務流程和軟件需求,促進業務人員、開發人員之間一致、高效的交流-114-不選擇UMLUML不是萬能,有些場合并不適合1)傳統的做法已完全適用,對面向對象技術的要求也不高,項目非常成功,無任何改進的必要2)開發的系統比較簡單,直接用源碼配上少量的文字就能解決問題,軟件開發文檔也無需添加圖形來輔助說明3)開發的系統本身不屬于OO方法、UML適用的范圍-115-UML發展背景90年代:面向對象分析設計方法學之戰P.Coad和E.Yourdon提出OOA和OODG.Booch提出面向對象開發方法Jacobson提出OOSERumbaugh提出的OMT……UML的出現結束了這場方法學戰爭-116-UML發展歷程UML企業聯盟UML1.0(1997.1)UML1.1(1997.9)UML1.5(2003.3)UML2.0(2005.7)OtherMethodsBooch‘91OMT-1OOSEBooch’93OMT-2公眾反饋UnifiedMethod0.8(OOPSLA’95)UML0.9(June‘96)UML0.91(Oct.‘96)and工業化標準化統一化

分散的各部分UML2.4(2011.3)UML2.5(2015.6)UML現狀UML1.x目前應用較為普及,包括從1.1~1.52003年3月發布的UML1.5UML22005年7月正式發布UML2.0,分為基礎結構和上層結構2011年3月UML2.4,2011年8月UML2.4.1,2012年5月ISO/IEC19505-1:2012,ISO/IEC19505-2:20122015年6月UML2.52017年12月UML2.5.1-117--118-UML的統一GradyBooch

(Booch)IvarJacobson

(OOSE)JamesRumbaugh

(OMT)“3amigos”-119-UML的統一(續)統一了什么?開發生命周期應用領域實現語言和平臺開發過程自身的內部概念-120-第02章可視化建模基礎可視化建模統一建模語言UML2組成結構UML2概念模型應用UML2建模UML組成結構從UML2開始,整個UML規范被劃分成基礎結構和上層結構兩個相對獨立的部分基礎結構(Infrastructure)是UML的元模型,它定義了構造UML模型的各種基本元素上層結構(Superstructure)則定義了面向建模用戶的各種UML模型的語法、語義和表示從UML2.5開始,為了消除冗余并簡化UML規范,基礎結構部分不再作為UML規范的一部分,UML元類在UML規范相應的章節中被完整地定義-121-UML語法結構UML的抽象語法使用UML元模型來定義這個元模型本身也是用UML來定義(準確來說是一個受限的UML子集,這個子集符合OMG的MOF規范)在UML規范中,主要采用UML類圖來描述各元素的抽象語法,采用約束機制和自然語言(文本)來描述模型語義-122-類的元模型(語法結構)-123-UML語義結構UML自身的語義與被建模系統的UML模型上所聲明的標準含義有關,這有時被稱為UML運行時語義UML模型劃分為兩類語義域。結構語義:定義了在建模域中關于個體的UML結構化模型元素的含義,也稱為靜態語義行為語義:定義了在建模域中關于個體如何隨著時間變化而做出不同行為的UML行為模型元素,也稱為動態語義。-124-UML語義域-125--126-第02章可視化建模基礎可視化建模基礎統一建模語言UML2組成結構UML2概念模型應用UML2建模-127-UML2概念模型UML概念模型

structure構造塊buildingblocks通用機制commonmechanisms架構architecture基本UML建模元素、關系和圖達到特定目標的通用UML方法系統構架的UML視圖-128-構造塊構造塊(buildingblocks)事物(things)結構、行為、分組、注釋關系(relationships)依賴、關聯、泛化、實現圖(diagram)靜態(7種):類圖、對象圖、構件圖、部署圖、包圖、組合結構圖、外廓圖動態(7種):順序圖、通信圖、時間圖、交互縱覽圖、活動圖、狀態機圖、用例圖-129-事物(things)結構(structural)事物:UML模型中的名詞模型的靜態部分用于描述概念元素或物理元素常見的結構事物類、接口用例、協作構件、工件、節點事物(續)行為(behavioral)事物:UML模型中的動詞,表示跨越時間和空間的行為交互、狀態機、活動分組(grouping)事物:用于將模型元素組織在一起包(、框架、模型、子系統…)注釋(annotational)事物:用來描述、說明或標注模型中的任何元素-130--131-關系關系relationships依賴dependency關聯association泛化generalization實現realization圖-132-圖結構圖類圖組合結構圖構件圖部署圖對象圖包圖外廓圖行為圖活動圖交互圖順序圖通信圖時間圖交互概覽圖狀態機圖用例圖-133-通用機制規格說明(Specifications)文本維度的模型描述修飾(Adornments)描述建模元素的細節信息通用劃分(CommonDivisions)建模時對事物的劃分方法擴展機制(ExtensibilityMechanisms)構造型、約束、標記值-134-規格說明(Specifications)UML模型至少具有兩種維度:圖形維度:使用圖和圖標可視化模型文本維度:各種建模元素的規格說明規格說明模型元素的特征和語義的文本描述形成了承載模型的語義背板(semanticbackplane),賦予模型意義,各種圖僅僅是該背板的視圖或者可視化投影deathbydiagram(由于圖形而死亡)修飾(adornments)UML表示法中的每一個元素都有一個基本符號,可以把各種修飾細節添加到這些符號上只有在修飾增強了圖的整體清晰性和可讀性或者突出模型的某些重要特征時,才應該表示那些修飾-135-Window-136-通用劃分類元(classifier)和實例的劃分類元表示一種抽象實例則是這種抽象的一個具體表現例:類/對象、用例/場景、構件/構件實例…接口和實現的分離接口聲明行為的契約(做什么)實現表示對該契約的具體實現細節(如何做)例:接口/子系統、用例/用例實現、操作/方法…通用劃分(續)類型和角色的分離(UML2新增)任何作為其它實體結構的一部分實體(如屬性)都具有兩個方面的特性:從固有類型派生出來的含義在語境中的角色派生出來的含義類型聲明了實體的種類(如對象、屬性、參數)角色描述了實體在語境(如類、構件、協作、組合結構)中的含義-137--138-擴展機制構造型(stereotypes)基于已有的建模元素引入新的建模元素標記值(taggedvalue)擴展UML構造型的特性,可以用來創建構造型的詳述信息約束(constraint)擴展UML構造塊的語義,可以用來增加新的規則或修改現有的規則外廓(profile)提供了一組預定義的構造型、標記值、約束和基類,以用于特定領域的建模-139-示例:擴展機制-140-構造型(stereotypes)構造型(stereotypes,衍型)根據已有的模型元素定義一個新元素建立在UML已定義的模型元素基礎上可以用于所有的UML模型元素,如類、關聯、用例、構件等UML規范提供了一些預定義的構造型-141-構造型的幾種表現形式-142-外廓(Profile)外廓基于UML元素的子集為特定領域定義了UML的一個特定版本,即定義了一組對UML已有模型的擴展和限定機制,以用于某個特定領域這些擴展和限定機制包括:預定義的構造型、標記值、約束和基類建立在普通的UML元素基礎上,并不代表一種新的語言-143-OMG提供的ProfileOMG基于Profile機制擴展UML應用MARTE(UMLProfileforModelingandAnalysisofReal-timeandEmbeddedSystems)UMLTestingProfileUMLProfileforSystemonaChip(SoC)SoaML(ServiceorientedarchitectureModelingLanguage)SysML(OMGSystemsModelingLanguage)EAI(UMLProfileforEnterpriseApplicationIntegration)……-144-外廓圖(ProfileDiagram)UML2.3新增的ProfileDiagram專門用于可視化描述外廓以及構造型、標記值、約束等主要概念Profile:一個包,代表一個外廓Stereotype:定義一種針對元類的擴展Metaclass:可被擴展的元素Extension:構造型和元類之間的關系ProfileApplication:Profile和應用模型之間的關系查看外廓圖元語-145-外廓圖返回外廓圖-146-應用ProfileDiagram-147-架構:4+1視圖ProcessViewDeploymentViewLogicalViewUse-CaseViewImplementationViewEnd-userFunctionalityProgrammers

Softwaremanagement

PerformanceScalabilityThroughput

SystemintegratorsSystemtopology

Delivery,installationcommunicationSystemengineeringAnalysts/DesignersStructure

-148-4+1視圖(續)用例視圖(UseCaseView)End-user:Functionality這些視圖由用例視圖所統一,它描述項目干系人(stakeholder)的需求;所有其他視圖都是從用例視圖派生而來,該視圖把系統的基本需求捕獲為用例并提供構造其他視圖的基礎邏輯視圖(LogicalView)Analysts/Designers:Structure系統功能和詞匯;描述問題域的詞匯,作為類和對象的集合。重點是展示對象和類是如何組成系統、實現所需系統行為的-149-4+1視圖(續)進程視圖(ProcessView)Systemintegrators:Performance,Scalability,Throughput系統性能、可伸縮性和吞吐量;建模在我們系統中的可執行線程和進程作為活動類。其實,它是邏輯視圖面向進程的變體,包含所有相同的制品實現視圖(ImplementationView)Programmers:SoftwareManagement系統組裝和配置管理;對組成基于系統的物理代碼的文件和組件進行建模。它同樣展示出組件之間的依賴,展示一組組件的配置管理以定義系統的版本部署視圖(DeploymentView)Systemengineering:SystemTopology,Delivery,Installation,Communication系統的拓撲結構、分布、移交和安裝;建模把組件物理地部署到一組物理的、可計算節點上,如計算機和外設上。它允許你建模橫跨分布式系統節點上的組件的分布按照開發階段組織模型架構-150--151-第02章可視化建模基礎可視化建模統一建模語言UML2組成結構UML2概念模型應用UML2建模-152-UML2.5中的14種圖UML2.5-圖Diagrams類圖ClassDiagrams對象圖ObjectDiagrams構件圖ComponentDiagrams部署圖DeploymentDiagrams用例圖UseCaseDiagrams順序圖SequenceDiagrams通信圖CommunicationDiagrams狀態機圖StateMachineDiagrams活動圖ActivityDiagrams靜態模型

(系統結構)動態模型

(系統行為)包圖PackageDiagrams組合結構圖CompositeStructureDiagrams時間圖TimingDiagrams交互縱覽圖InteractionOverviewDiagrams外廓圖ProfileDiagrams-153-UML2主要改進(與UML1.x相比)新增(5種)包圖(PackageDiagram)組合結構圖(CompositeStructureDiagram)交互縱覽圖(InteractionOverviewDiagram)時間圖(TimingDiagram)外廓圖(ProfileDiagram,UML2.2新增)改進(3種)順序圖(SequenceDiagram)活動圖(ActivityDiagram)構件圖(ComponentDiagram)改名(2種)通信圖(CommunicationDiagram)狀態機圖(StateMachineDiagram)-154-UML214種圖-結構模型類模型類圖:類、接口以及它們之間的關系包圖:包以及它們之間的依賴關系對象圖:對象以及它們之間的鏈接關系構件模型構件圖:構件以及之間的依賴關系組合結構模型組合結構圖:系統某一部分(組合結構)的內部結構部署模型部署圖:構件在節點上的部署情況外廓模型外廓圖:外廓以及所包含構造型、標記值、約束和基類等-155-UML214種圖-行為模型活動模型活動圖:動作及活動執行的控制流或數據流交互模型順序圖:對象間交互序列的執行順序通信圖:對象間的協作以及交互序列時間圖:對象交互中真實的時間信息交互縱覽圖:多個交互之間的執行順序狀態機模型狀態機圖:對象所經歷的狀態遷移過程用例模型用例圖:以外部用戶視角描述系統能力-156-UML建模工具IBMRationalSuiteRationalRose2003經典的UML建模工具,目前仍有廣泛的應用不支持UML2.0RationalSoftwareArchitectureIBM兼并Rational之后,重新基于Eclipse平臺構建的集成開發平臺,提供從業務建模、需求分析、設計到系統實現的完整環境IBMRationalRhapsodyIBM兼并另一家UML建模工具后重新發布的產品主要用于嵌入式領域建模,涉及軟硬件等各個層次的模型-157-UML建模工具(續)EnterpriseArchitectSybasePowerDesignerMicrosoftVisio數以百計的各類共享/開源工具StarUMLArgoUMLKant&Plato……/Tools/Newindex1.htm-158-RationalSoftwareArchitecture-159-RationalRose2003建模實踐EnterpriseArchitect-160--161-示例:圖書館管理系統某圖書館管理系統是一個基于Web的計算機應用系統讀者可以查詢圖書信息以及借閱信息讀者可以通過系統預約所需的圖書圖書館工作人員利用該系統完成讀者的借書、還書業務圖書館工作人員可以對圖書信息、讀者信息等進行維護對于到期的圖書,系統會自動向讀者發送催還信息管理員會定期進行系統維護……-162-用例圖用例圖(UseCaseDiagram)是被稱為參與者(Actor)的外部用戶所能觀察到的系統功能的模型圖列出系統中的用例和參與者顯示哪個參與者參與了哪個用例的執行核心概念用例:系統中的一個功能單元,可以被描述為參與者與系統之間的一次交互作用參與者、參與者泛化用例與參與者之間的關系:關聯用例之間關系:擴展、包括、泛化推薦使用場合業務建模、需求獲取、定義-163-用例圖元語圖書館管理系統用例圖-164-從用例圖中我們得到了什么信息?

得不到什么信息?-165-“借書”用例文檔UC01:“借書”用例文檔用例名稱:借書用例標識:UC01涉及的參與者:工作人員涉及的用例:無描述:工作人員利用該用例為讀者完成借書過程 前置條件:工作人員必須登錄到當前系統涉眾利益:

讀者:能夠方便的找到并借出所需的圖書 工作人員:能夠快速并準確的完成借書工作-166-“借書”用例文檔(續)基本事件流:工作人員幫助讀者借閱圖書用例起始于讀者帶著所要借的圖書來到借閱前臺;工作人員錄入讀者信息;工作人員逐一錄入所有的圖書信息:*3.1工作人員錄入一本圖書信息;*3.2系統確認該讀者可以借閱當前圖書;工作人員確認本次借閱信息;系統記錄本次借閱情況。后置條件:系統將讀者借閱信息正確地記錄到數據庫中備選事件流2a.讀者身份不合法2b.讀者存在欠費信息,不允許借書3.2a.該讀者不允許借閱當前圖書“借書”用例文檔(續)-167-字段列表:5.借閱信息主要包括:讀者圖書證號、圖書編號、借閱日期(默認為當天日期)、借閱天數以及歸還日期。業務規則3.2系統根據當前讀者的借閱規則來判斷是否可以借閱圖書;而借閱規則取決于讀者的類型(如本科生、研究生、老師等)和圖書的類型(如科技類、文學類、新書等),并可動態配置非功能需求:無設計約束:無部署約束:無未解決的問題2b.讀者存在多少欠費記錄時,才不允許借書?3.2借閱規則的具體配置情況需和用戶進一步討論?-168-活動圖活動圖(ActivityDiagram)通過動作來組織,主要用于描述某一方法、機制或用例的內部行為核心概念狀態、活動、組合活動、對象轉移、分支并發、同步泳道推薦使用場合業務建模、需求、類設計-169-活動圖元語-170-“借書”業務的活動圖-171-靜態結構圖類圖(ClassDiagram)是軟件的藍圖,詳細描述了系統內各個對象的相關的類,以及這些類之間的靜態關系對象圖(ObjectDiagram)表示在某一時刻類的對象靜態結構和行為包圖(PackageDiagram)展現有模型本身分解而成的組織單元(包)以及它們的依賴關系組合結構圖(CompositeStructureDiagram)描述系統中某一部分(組合結構)的內部結構,包括該部分與系統其它部分的交互點-172-靜態結構圖(續)核心概念類圖:類、接口、依賴、關聯、泛化、實現對象圖:對象、鏈接、多重性包圖:包(、框架、層、子系統)、依賴組合結構圖:組合結構、部件、端口、協議推薦使用場合系統靜態結構建模的核心模型業務建模、分析、設計、實現-173-類圖、對象圖、包圖元語組合結構圖元語-174--175-包圖展示系統分層結構-176-類圖展示實體類的靜態關系-177-對象圖展示我當前借書情況-178-組合結構圖展示借書內部結構-179-順序圖順序圖(SequenceDiagram)用于顯示對象間的交互活動關注對象之間消息傳送的時間順序核心概念對象、生命線、執行發生、交互、消息交互幀(InteractionFrame)推薦使用場合用例分析、用例設計-180-順序圖元語-181-“借書”用例實現的順序圖-182-“借書”的順序圖(UML2表示)-183-交互縱覽圖交互縱覽圖(InteractionOverviewDiagram)活動圖和順序圖的混合物直觀地表達一組相關順序圖之間的流轉邏輯核心概念交互幀分支、轉移推薦使用場合用例分析、用例設計-184-交互縱覽圖元語-185-交互縱覽圖組織多個順序圖sdOverview查詢圖書信息ref[沒找到]預約圖書ref借書ref[找到所需圖書][書已借出][該書可借]-186-通信圖通信圖(CommunicationDiagram)UML1.x中稱為協作圖(CollaborationDiagram)表示一組對象間關系以及交互活動核心概念對象、協作角色協作、交互、消息推薦使用場合用例分析、用例設計-187-通信圖元語-188-“借書”用例實現的通信圖-189-時間圖時間圖(TimingDiagram)一種交互圖,展現消息跨越不同對象或角色的實際時間信息具體描述單個或多個對象狀態變化的時間點以及維持特定狀態的時間段順序圖是表示交互的主要手段,可以在順序圖中增加時間約束來表明對象狀態變化的時間點以及維持特定狀態的時間段核心概念時間約束、持續時間約束、生命線狀態、條件、事件時間圖元語-190--191-“打電話”順序圖的時間約束{<=30sec}-192-利用時間圖描述時間約束{<=30sec}sdUser_DialPhoneIdleTonedDialingConnectingCallingtimingrulerLiftDigitDialOKHang………………:SwitchsdUser_DialPhoneIdleTonedDialingConnectingCallingIdle{<=30sec}:Switch………………-193-狀態機圖狀態機圖(StateMachineDiagram)UML1.x為狀態圖(StatechartDiagram)利用狀態和事件描述對象本身的行為主要概念狀態、初態、終態、復合狀態事件、轉移、動作并發推薦使用場合類設計-194-狀態機圖元語-195-“圖書”類的狀態機圖-196-構件圖構件圖(ComponentDiagram)封裝類為構件描述在系統實現環境中的軟件構件和之間的關系主要概念構件、工件、接口(所供接口、所需接口)依賴、實現推薦使用場合系統設計、實現、部署-197-構件圖元語-198-構件圖描述類的實現環境構件圖(UML2新特性)-199-<<component>>Order<<providedinterfaces>>OrderEntryAccountPayable<<requiredinterfaces>>Person<<realizations>>OrderHeaderLineItem<<artifacts>>Order.jarOrderHeaderLineItemOrderEntryPerson-200-部署圖部署圖(DeploymentDiagram)描述系統所需的硬件構件的物理部署主要概念節點、構件、位置連接、依賴推薦使用場合系統設計、實施、部署-201-部署圖元語-202-部署圖描述系統部署情況謝謝!UML2面向對象分析與設計

Object-OrientedAnalysis&DesignwithUML2譚火彬-205-學習路線圖OOUMLOOPDP…

教學案例

…學習路線圖……

……

……

……12345678910第03章業務建模BusinessModeling-207-第03章業務建模分析設計過程簡介業務建模基礎業務用例模型業務對象模型業務建模實踐從業務模型到系統模型-208-第03章業務建模分析設計過程簡介業務建模基礎業務用例模型業務對象模型業務建模實踐從業務模型到系統模型-209-UML是標準的符號1.用UML畫圖很容易擺脫符號煩惱全心面對問題2.UML僅僅是一種表達形式用好UML首先需要掌握OOAD的基本原則和方法,并在一定的軟件開發過程(如統一過程、敏捷過程等)的指導下進行有取舍的運用但知道要畫什么是困難的!UML分析設計過程解析業務建模采用軟件建模方法分析和理解待開發的業務,描述業務流程需求:用例建模采用UML用例技術描述軟件需求需求分析:用例分析采用UML用例分析技術分析軟件需求,建立軟件系統的分析模型-210-UML分析設計過程解析(續)架構設計

在系統的全局范圍內,以分析模型為基礎,設計系統的架構構件設計根據架構

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經權益所有人同意不得將文件中的內容挪作商業或盈利用途。
  • 5. 人人文庫網僅提供信息存儲空間,僅對用戶上傳內容的表現方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
  • 6. 下載文件中如有侵權或不適當內容,請與我們聯系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論