面向對象講義參考_第1頁
面向對象講義參考_第2頁
面向對象講義參考_第3頁
面向對象講義參考_第4頁
面向對象講義參考_第5頁
已閱讀5頁,還剩9頁未讀, 繼續(xù)免費閱讀

下載本文檔

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

文檔簡介

面向對象開發(fā)培訓參考講義一.軟件架構的組織原則:軟件本質:我們的世界是模糊的、連續(xù)的、不精確的,但軟件是精確的、離散的、形式化的,這就注定軟件不能完全描述現實世界。所以我們要知道描述那些部分,忽略那些部分,這就是軟件的本質問題。VRAPS模型(構想,節(jié)奏,預見,協作,簡化)構架:為我們提供了整個系統(tǒng)的清晰的視角,對控制系統(tǒng)的開發(fā)是必要的。軟件系統(tǒng)是一個單一的實體,但從不同視覺展示系統(tǒng)有助于更好的理解設計,這些視角被解釋為系統(tǒng)的模型視圖,視圖合在一起構成了構架架構描述:用況模型視圖,分析模型視圖,設計模型視圖實施模型視圖實現模型視圖測試模型視圖對描述構架不起作用,他只是用來驗證構架基線二.面向對象分析設計開發(fā)面向對象的分析是按照概念(對象)對軟件問題進行分解,而不是像結構化分析哪樣是按照功能對軟件問題進行分解的。系統(tǒng)分析:理解并詳細說明信息系統(tǒng)應該做什么的過程識別出問題域中不同概念并用概念模型將其存檔系統(tǒng)設計:詳細說明信息系統(tǒng)的許多特性在物理上是怎樣實施的過程。面向對象的目標是開發(fā)能夠反映現實世界某個特定片段的軟件(或模型).對象:a?定義為某一事物,即是可以看到、摸到或感覺到的一種實體。在計算機面向對象技術中,對象是系統(tǒng)的基本成分,是具有特殊屬性(數據)和行為方式(方法)的實體.它應有唯一的名稱,有表示對象行為的一組公共與私有操作。=(ID,DS,MS,MI)ID:標識或對象名DS:對象的數據結構MS:操作集MI:對外接口類:一個類描述了屬于該類型的所有對象的性質,包括外部特征和內部實現。共享相似特性和行為的對象的集合。對象是某個類的一個元素。=(ID,INH,DD,OI,ITF)ID:標識或類名INH:類繼承性描述DD:數據結構描述OI:操作集合描述ITF:對外接口類的屬性:抽象:過濾掉對象的一部分特性和操作直到只剩下你所需的操作和屬性,繼承:對象繼承了所屬類的屬性和操作,類同樣也可以繼承其他類的屬性和操作。如何發(fā)現類之間的繼承關系?在初始模型中,在類列表中找出兩個或多個具有相同屬性和操作的類,其中一個類有可能就是其它類的父類,或者可為這些類新建一個父類。子類型有額外的重要的屬性,子類型有額外的重要的關聯子類型以不同于父類型或其它子類型的重要方式被操作,操縱,反應或處理子類型描述的事物與超類型或其它子類型的行為方式不同多態(tài):不同的類中可以有相同名稱的操作且這個操作在每個類中都能以各自不同的方式執(zhí)行,因此必須清楚這些同名操作之間的重要區(qū)別。封裝:當一個對象執(zhí)行自己的操作時,它對外界隱藏操作的細節(jié),持久化框架:是一種可重用的,且通??杀粩U展的類的集合,他可向持久化對象提供服務。如:存儲數據時將對象轉換成記錄,在取回數據時需將記錄轉換成對象。消息傳遞:對象通過相互之間的消息傳遞協同工作關聯:a在物理上或邏輯上是b的一部分a物理上或邏輯上依賴于ba被記錄在b中管理原則:1.需要知道型關聯:需要將概念之間的關系信息記憶一段時間的關聯2.概念比關聯重要3.太多關聯使概念模型混亂4.避免關聯之間的信息冗余以及減少派生關聯聚集接口:是描述類的部分行為的一組操作,他也是一個類提供給另一個類的一組操作獲取需求的基本原則:1.深入淺出以流程為主線獲取需求的重點:1.平均頻度:業(yè)務發(fā)生的頻繁程度(即單位時間內發(fā)生的次數)頻度越高,數據量就越大,對響應時間、易操作性等要求越高,在數據存儲需充分考慮高峰期的頻度:只有掌握此數據,在后面系統(tǒng)測試時,需要模擬高峰期的業(yè)務頻度3.看單據::有那些數據,每頁數據精度,計算生成方法,取值范圍限定單擊內容是進行數據結構設計的最基本依據取值范圍與計算方法是數據完整性檢測的依據4.生成單據或報表的時間(手工):花費時間多,處理方法復雜的地方通常是最關鍵的地方,也是用戶驗收關心的地方,通常也是用戶沒有足夠人力與時間處理才想到用計算機的地方5.單據或報表的來源:單據聯數,每聯用途,送交單位,送交時間6.有那些特殊情況,在某個作業(yè)環(huán)節(jié)出錯時通過何種途徑彌補:分析員可采用窮舉的方法,假定每一個環(huán)節(jié)都出現失誤,逐環(huán)節(jié)詢問用戶的處理方法,防止遺漏7.將來有何變化獲得類的過程:讓分析員使用客戶所采用的術語和用戶交流,可促使客戶說出問題的細節(jié)。在談話過程中應不時停下來作總結,測試一下你對問題的理解,熟悉和使用領域術語,并盡量使談話氣氛保持輕松愉快對不熟悉的領域術語,務必讓對方解釋清除。不必擔心對方覺得你無知,談話的目的是獲得知識,學習領域術語。需經常從前面的回答中辨別新問題,集中注意力聽對方對每個問題的解答,業(yè)務邏輯通常包含在對方對問題的解答中遇到業(yè)務邏輯時要作記錄,還要整理和維護好這些記錄以后可能用到若覺得業(yè)務過程某些部分過于復雜,應當暫時將其擱置,日后單獨討論。每個業(yè)務過程復雜度不宜過高,以容易繪制成模型圖為宜。繪制出模型圖的清晰性要比模型的復雜性更重要。征求被訪者對活動圖的反饋意見,根據對方意見修改活動圖分析類的基本構造型:1.邊界類:用于建立系統(tǒng)與其參與者(用戶和外部系統(tǒng))之間交互的模型,:通常把用戶界面或通信接口變化隔離在一個或多個邊界類中2.實體類:用于長效且持久的信息建模,實體類主要對諸如個體、實際對象或實際事物的某些現象或概念信息及相關行為建模。3.控制類:代表協調、排序、事務處理以及對其它對象的控制,經常用于封裝與某個集體用況有關的控制,也可用于表示復雜的派生和演算識別概念策略:使用概念目錄列表找出概念:物理的或實在的對象規(guī)格說明,設計或事物的描述地點,事務,人的角色,組織,事件,規(guī)則,策略,手冊,書籍根據名詞性短語找出概念:弱點在于自然語言的不準確性,如:班組,工區(qū)概念、屬性區(qū)分:若概念在現實世界不僅僅是一些簡單的數字或文字,那么最好將其作概念處理,而不是作為屬性處理.類潛在的兩組屬性:傳統(tǒng)的將之視為關系表中屬性的屬性:如:姓名,編號是客戶全視之為類屬性的屬性:如:線桿的瓷瓶一個類可以有多個與之關聯的屬性,具有大量數據的類是不良的設計,比較好的設計是類具有50或更少的屬性識別職責:知道型職責:知道自己私有的封裝的數據,知道自己相關聯的對象信息,知道自己派生出來或計算出來的事物做型職責:自己完成某件任務,發(fā)起其它對象執(zhí)行動作,控制和協調其它對象內的活動。面向對象設計要點:為實際工作設計理解要實現的東西需求的重要性在現有任務中應用多個模型用例的重要性用力可大可小,但必須是對一個具體的用戶目標實現的完整描述文檔的重要性證明軟件的設計在實踐中是可行的應用已知的模式類的內聚性:一個類應有且僅有一個職責,否則可能由于多個不同原因引起該類發(fā)生變化充分考慮軟件的可移植性:當使用os的特性,或利用某db專用語言寫了存儲過程,應將這些特性的實現細節(jié)封裝在一個類中建立對象數據辭典:便于內部重用和共享,應建立電子化對象數據辭典,以便對象統(tǒng)一歸類管理12.對接口編程:是面向對象設計的基本原則之一。對于所有完成相同功能的組件,應抽象出一個接口,他們都實現該接口。好的接口設計原則:隱藏實現細節(jié)只提供必要的功能不要對外部代碼施加影響保持接口風格統(tǒng)一在同一層分配和釋放資源在較低層檢測錯誤,在較高層處理錯誤13.類的最高層是抽象類:在許多情況下,提供一個抽象類有利于做特性化擴展,抽象類的層次越高,代碼就越有彈性,越容易適應變化.優(yōu)先使用對象組合,而不是類繼承:有助于保持每個類被封裝,并且具有更多的靈活性增加參數的可讀性盡量減少對變量的直接訪問:對數據的封裝原則應該規(guī)范化,不要把一個類的屬性暴露給其它類,而是應通過訪問方法去保護他們,這有利于避免波紋效應,若某個屬性的名字改變,只需修改它的訪問方法,而不是修改所有相關代碼。面向對象的設計原則:單一職責原則:對于一個類而言,應該僅有一個引起它變化的原因,變化的軸線僅當變化實際發(fā)生時才具有真正的意義,否則應用它是不明智的b.開發(fā)-封閉原則:對于擴展是開放的(我們可以改變模塊的功能)對于更改是封閉的(擴展時,無需改動源碼或二進制代碼)一般而言,無論模塊多么封閉,都會存在一些無法封閉的變化,沒有對于所有情況都貼切的模型設計人員必須對于他設計的模塊應該對哪些變化封閉作出選擇,他們必須先猜測出最有可能發(fā)生的變化種類,然后構造抽象類來隔離那些變化對于應用程序中每個部分都進行抽象不是一個好注意,正確的做法是,開發(fā)人員應該僅僅對程序中呈現出頻繁變化的那些部分作出抽象,拒絕不成熟的抽象和抽象本身一樣重要長方形,正方形是非is—a的,ood中is—a關系是就行為方式而言的liskov替換原則:子類型必須能夠替換掉他們的基類型在重新聲明派生類中的例程時,只能使用相等或者更弱的前置條件來替換原始的前置條件,只能用相等或者更強的后置條件來替換原始的后置條件.(例:傳入%或具體單位值獲得單位統(tǒng)計,只傳單位)依賴倒置原則:高層模塊不應該依賴于底層模塊,二者都應該依賴于抽象抽象不應該依賴于細節(jié),細節(jié)應該依賴于抽象接口隔離原則:不應該強迫客戶依賴于他們不用的方法包的設計原則:內聚性原則重用發(fā)布等價原則不希望用戶發(fā)現包中包含的類中,一些是他需要的,另一些他卻完全不適

共同重用原則:一個包中的所有類應該是共同重用的,如果重用了包中的一個類,那么就要重用包中的所有類共同封閉原則:包中的所有類對于同一類性質的變化應該是共同封閉的,一個變化若對一個包產生影響,則對該包中的所有類產生影響,而對于其它的包不造成任何影響耦合性原則:無環(huán)依賴原則:若依賴關系圖中存在環(huán),就很難確定包創(chuàng)建的順序解除環(huán):使用依賴倒置原則創(chuàng)建新包,將兩包依賴的類放置其中自頂向下設計穩(wěn)定依賴原則:朝著穩(wěn)定的方向進行依賴軟件分層設計:界面層,業(yè)務邏輯層,數據接口層,數據層優(yōu)點:良好的透明和封裝,高內聚,低耦合,易于擴展,維護和重用,開發(fā)人員易于分工,提高開發(fā)效率缺點:效率降低,開發(fā)難度增大面向對象的數據庫設計:一般編程設計有兩種屬性主導型:從歸納數據庫應用的屬性出發(fā),在歸并屬性集合(實體)時,維持屬性間的函數依賴關系實體主導型:先從尋找對數據庫應用有意義的實體出發(fā),然后定義屬性來完善實體一般認為現實世界實體數量在屬性1/10以下時,宜使用實體主導型設計方法面向對象的數據庫設計從對象模型出發(fā),屬于實體主導型設計設計步驟:設計應用系統(tǒng)結構b.選擇便于應用程序與dbms結合的dbms體系結構根據應用程序使用的環(huán)境平臺,選擇適宜的dbms和開發(fā)工具設計數據庫,編寫定義數據庫模式的sql程序編寫用戶接口應用程序,錄入數據注:此順序不是瀑布模型,每一步可以反饋應用對象模型與rdbms模型的映射:a.RDBMS是以二維表為基本管理單元的,對象模型要由二維表及表間關系描述,對象模型向數據庫概念模型的映射就是向數據庫表的變換過程:一個對象類可以映射一個以上的庫表,當類間有一對多的關系時,一a.個類也可對應多個類關系映射:一般映射為一個表單一繼承泛化關系可對超類、子類分別映射表,也可讓子類表擁有父類屬性,也可讓父類表擁有子類表屬性對庫表進行冗余控制調整,使之滿足合理的關系范式三.敏捷軟件開發(fā):參考,慎用,不是最合理的軟件方法個體和交互勝過過程和工具可以工作的軟件勝過面面俱到的文檔客戶合作勝過合同談判響應變化勝過遵循計劃雖然右項也具有價值,但左項具有更大的價值martin文檔第一定律:直到迫切需要并且意義重大時,才編制文檔敏捷軟件開發(fā)原則:我們優(yōu)先要做的就是盡快的、持續(xù)的交付有價值的軟件使客戶滿意初期交付的系統(tǒng)中包含的功能越少,最終交付的系統(tǒng)的質量就越高即使到了開發(fā)后期,也歡迎改變需求,敏捷過程利用變化來為客戶創(chuàng)造競爭優(yōu)勢經常性的交付可以工作的軟件,交付的間隔可以從幾周到幾個月,交付的間隔越短越好在整個開發(fā)期間,業(yè)務人員和開發(fā)人員必須在一起工作圍繞被激勵起來的個人來創(chuàng)建項目,給他們提供所需要的環(huán)境和支持,并且信任他們能夠完成工作在團隊內部,最具有效果且富有效率的傳遞信息的方法,就是面對面的交談能工作的軟件是首要的進度衡量標準敏捷軟件開發(fā)過程提倡可持續(xù)的開發(fā)速度,責任人、開發(fā)者、用戶應該能夠保持一個長期的、恒定的開發(fā)速度(10蓋女人不可能在一個月內生出小孩)不斷的關注優(yōu)秀的技能和好的設計會增強敏捷能力簡單:使未完成的工作最大化的藝術,是根本的最好的構架,需求和設計出自于自組織的團隊每隔一段時間,團隊會在如何才能有效地工作方面進行反省,然后相應地對自己地行為進行調整注意事項:客戶作為團隊成員:當確實無法和客戶工作在一起時,建議尋找能夠在一起工作、愿意并能夠代替真正客戶地人結隊編程:所有地產品代碼都是由結隊的程序員使用一臺電腦共同完成的。結隊成員中的一位控制鍵盤并輸入代碼,另一位觀察輸入的代碼中的錯誤和可以改進的地方。結隊的關系每天至少要改變一次,以便于每個程序員在一天中可以在兩個不同的結隊中工作.集體所有權:結隊編程中的每一對都有拆出任何模塊并對它進行改進的權利持續(xù)集成:程序員每天會多次拆入他們的代碼并進行集成,規(guī)則很簡單(第一個拆入的只要完成拆入即可,所有其它的人負責代碼的合并工作)可持續(xù)的開發(fā)速度:不允許團隊加班工作,在版本發(fā)布前的一個星期是該規(guī)則的唯一例外,若發(fā)布目標就在眼前且一蹴而就,則允許加班開發(fā)的工作空間:密歇根大學研究:在充滿積極討論的屋子里工作,生產率會成倍的提高計劃游戲:本質是劃分業(yè)務人員和開發(fā)人員之間的職責(業(yè)務人員和客戶決定特性的重要性,開發(fā)人員決定實現一個特性所花費的代價)簡單的設計:考慮能夠工作的最簡單的事情你將不需要它:只有在有證據,或者至少有十分明顯的跡像表明現在引入這些基礎結構比繼續(xù)等待更加合算時,團隊才會引入這些基礎結構一次,并且只有一次不允許容忍重復的代碼,無論哪里出現重復的代碼,他們都會消除它們.(例外:性能差別很大時)消除重復最好的方法就是抽象,進一步減少代碼間的耦合重構:是持續(xù)進行的,是我們每隔一個小時或者半個小時就要去做的事情。通過重構,我們可以持續(xù)地保持盡可能干凈、簡單且具有表現力的代碼敏捷開發(fā)人員對待軟件設計地態(tài)度和外科醫(yī)生對待消毒地過程的態(tài)度是一樣的:設計的臭味:a.僵化性:很難對系統(tǒng)進行改動脆弱性:對系統(tǒng)的改動會對系統(tǒng)中和改動地方在概念上無關的很多地方出現問題牢固性:很難解開系統(tǒng)的糾結粘滯性:做正確的事情比做錯誤的事情要困難不必要的復雜性f.晦澀性:不必要的重復

四.UML:每一種UML圖都為你提供一種組成特殊視圖的方式,采用多視點的目標是為了滿足每一類風險承擔人的需要。靜態(tài)模型描述系統(tǒng)的結構特性動態(tài)模型描述系統(tǒng)的行為特性。類提供了系統(tǒng)的部分靜態(tài)視圖,描述的是系統(tǒng)的內部構成。用例提供了系統(tǒng)動態(tài)的行為視圖,說明的是從外部看到的系統(tǒng)。類圖:展示系統(tǒng)或者領域中的實體以及實體之間的關聯關聯:類之間的連接關聯上的約束:關聯上的約束or(或)約束關聯類:關聯有自己的屬性和操作時,關聯實際上是一個類繼承與泛化(UML中稱為泛化):類a具有類b的所有特征,類a不同于類b,則類a繼承類b子類型必須符合以下兩個規(guī)則100%規(guī)則:超類型定義應該100%的可以被應用于子類型。子類型必須100%的符合超類型的屬性和關聯。Is-a規(guī)則:所有子類型集合的成員必須是它們的超類型集合的成員依賴:一個類使用了另一個類,這種關系叫做依賴-端11類5類6-特性1--端11類5類6-特性1-端5{0R}-端*-特性1+操作1+操作1()1 5-端3-端411 -端9端10 1..*AssociationClassl-特性1+操作1()建立設計類圖:通過分析交互圖,識別出所有參與軟件解決方案的類將它們在一個類圖中繪出復制概念模型中的相關概念的屬性到類圖的類中通過分析交互圖來為類圖中的類添加方法為屬性和方法添加類型信息在類圖中添加關聯,以支持必要的類之間的可見性在關聯上添加導航箭頭,來指明屬性可見性的方向添加依賴關系連線,來指明非屬性的可見性一個類的職責:就是該類在所有用況實現中所充當的匯集,將角色集中起來并去掉其中重疊的部分,就可得到該類的所有職責和屬性的規(guī)格說明。用例圖:一種用以顯示不同的用戶角色和這些用戶角色如何使用系統(tǒng)的圖用例分析的一個重要方面,是揭示出組成系統(tǒng)的構件。用例:由系統(tǒng)為使用該系統(tǒng)的用戶完成的一個單一用途或功能從用戶的觀點對系統(tǒng)行為的一個描述。是能夠幫助分析員和用戶確定系統(tǒng)使用情況的UML組件。是系統(tǒng)的一組場景。每個用例圖都有其自身的頁,每個用例中的場景描述通常也至少占一頁:每個用例的背后都隱藏一張順序圖.高層用例:是非常簡潔的,通常是一個過程三兩句話的描述用況名稱:參與者:參與者列表,并注明用況發(fā)起者類型:a.主要,次要,可供選擇的b.基本的,真實的主要:主要的過程;次要:不重要的或不常見的過程;可供選擇:可以處理也可不處理的過程;基本:用一個完整格式表達,但很少涉及用況實現細節(jié);真實:能具體描述用況過程的真實細節(jié),以及具體的輸入輸出技術。描述:擴展用例:是描述一個過程的長篇敘述,可能含幾百句話的描述。用況:參與者:目的:概述:類型:交叉引用:相關的用況或系統(tǒng)功能典型的事件發(fā)生過程:可供選擇的事件發(fā)生過程:文檔中描述的內容:發(fā)起用例的參與者用例的前置條件場景中的步驟場景完成后的后置條件從用例中獲益的參與者。包含用例:《include》早期稱使用(use)用例用例的重用技術擴展用例:《extends》對原用例的擴展技術參與者:系統(tǒng)用戶扮演的一個角色是系統(tǒng)外部的一個實體,它以某種方式參與用況的執(zhí)行過程。種類:人擔當的角色,計算機系統(tǒng),機械或電子設備場景:在用例中活動的一個特定順序;一個用例可能有多個不同的場景.每個序列是由一個人,另一系統(tǒng)、一個硬件設備或某段時間的流逝發(fā)起的。系統(tǒng)邊界:硬件設備或者計算機系統(tǒng)的硬件或軟件邊界一個組織中的部門整個組織定義系統(tǒng)邊界的目的是為了能夠識別出什么在系統(tǒng)之內及什么在系統(tǒng)之外,進

永1**永2永3主角1系統(tǒng)名-端2-端永1**永2永3主角1系統(tǒng)名-端2-端1ds〉〉<<extenses〉〉用況用況名:參與者:目的:概述:類型:交叉引用:典型的事件發(fā)生過程:參與者的動作 系統(tǒng)響應可供選擇的過程用況的使用要依賴于至少部分地理解了系統(tǒng)需求,并用需求規(guī)格說明文檔很好地表達出了這些需求。用況展示和體現出了其描述地過程中的需求情況。用況常見錯誤:把用況當成單獨的步驟、操作或事務。用況是相對較大的由起點到終點的過程的描述。用況模型必須滿足:是否已將所有必需的功能性需求捕獲為用況每個用況的動作序列是否正確、完整、易于理解是否已經確定了一些價值很少或根本沒有價值的用況,若有則應重新考慮這些用況識別用況的步驟:基于參與者的方法識別與系統(tǒng)或組織有關的參與者對每個參與者,識別出他們發(fā)起或參加的執(zhí)行過程基于事件的方法識別出系統(tǒng)必須響應的外部事件把事件與參與者聯系起來識別用況的準則:有價值的結果:每個可成功執(zhí)行的用況都應對參與者提供某些價值。此準則應針對最初的參與者,有助于避免確定太小的用況具體的參與者:通過確定向真正的用戶提供有價值的用況,可以確保用況不會太大用況的優(yōu)點:用況著眼于為用戶增加價值,提供一種捕獲功能需求的系統(tǒng)而且直接的方法用況可驅動整個開發(fā)過程,因為大部分活動如分析、設計、測試都是

從用況開始執(zhí)行的。交互圖:能夠展示出類模型中實例之間的消息交互,UML中定義了兩種交互圖:順序圖,協作圖順序圖強調的是交互的時間順序,按照時間順序布圖協作圖強調的是交互的語境和參與的對象的整體組織。協作圖按照空間組織布圖協作圖:使用圖表或者網格展示了對象之間的交互它是一種用以顯示對象如何被協調在一起以執(zhí)行用例的圖.協作圖消息1消息1類1 ?順序圖:一種用以顯示用例對象之間消息順序的圖,采用一種類似于圍欄的格式展示對象之間的交互。生命線:在順序圖的一個對象下面的豎線,用以顯示這個對象的時間階段.消息:用例內部的對象之間的通信激活:順序圖消息激活:順序圖消息1消息2I"■_消息3狀態(tài)圖:一種用以顯示對象在生命周期和轉換期情況的圖。只是對單個對象建立模型。描述了一個對象所處的可能狀態(tài)以及狀態(tài)之間的轉移并給出了狀態(tài)變化序列的起點和終點。信號:在接收對象的狀態(tài)圖中,能夠觸發(fā)一個狀態(tài)轉移的消息子狀態(tài):狀態(tài)處在單個狀態(tài)之中,稱之為子狀態(tài)。順序子狀態(tài),并發(fā)子狀態(tài)

活動圖::展示出對象執(zhí)行某種

溫馨提示

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

評論

0/150

提交評論