版權說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權,請進行舉報或認領
文檔簡介
軟件開發(fā)環(huán)境(huánjìng)主講人:邵堃共一百三十四頁軟件開發(fā)環(huán)境(huánjìng)講授內(nèi)容:
軟件開發(fā)環(huán)境重點教授面向軟件開發(fā)過程(guòchéng)的各類軟件開發(fā)工具和使用方法。
講述重點:1.了解軟件工程中方法,工具和過程之間的基本概念,及其相互關系(講述為主);2.了解當前的主要軟件開發(fā)方法,結構化開發(fā)、面向對象開發(fā)、面向方面開發(fā)和面向組件的開發(fā)等(學生自己查找資料,然后做報告);共一百三十四頁軟件開發(fā)環(huán)境(huánjìng)講授內(nèi)容:
3.了解(liǎojiě)針對這些開發(fā)方法的主要工具軟件(學生自己查找資料,然后做報告),重點介紹面向對象開發(fā)方法UML,及其開發(fā)工具RationalRose(講述為主)。軟件開發(fā)工具、軟件測試工具和軟件開發(fā)過程項目管理工具;共一百三十四頁軟件開發(fā)環(huán)境(huánjìng)的背景軟件工程化的背景(bèijǐng);軟件規(guī)?;谋尘?;軟件產(chǎn)業(yè)化的背景;共一百三十四頁軟件開發(fā)環(huán)境(huánjìng)的定義軟件開發(fā)環(huán)境(SoftwareDevelopmentEnvironment)是指在基本硬件和宿至軟件的基礎上,為支持系統(tǒng)軟件和應用軟件的工程化開發(fā)和維護而使用的一組軟件,簡稱SDE。它由軟件工具和環(huán)境集成(jíchénɡ)機制構成,前者用以支持軟件開發(fā)的相關過程、活動和任務,后者為工具集成(jíchénɡ)和軟件的開發(fā)、維護及治理提供統(tǒng)一的支持。
共一百三十四頁軟件開發(fā)環(huán)境(huánjìng)中各類元素之間的關系SoftwareEngineeringa“quality”focusprocessmodelmethodstools注:軟件工程的三個基本要素:方法、工具和過程 過程:規(guī)定了完成各項任務的過程; 方法:完成軟件開發(fā)的各項任務的技術(jìshù)方法; 工具:軟件工程的支撐環(huán)境;
共一百三十四頁軟件開發(fā)環(huán)境的分類-按開發(fā)(kāifā)模型和開發(fā)(kāifā)方法分支持瀑布(pùbù)模型、演化模型、螺旋模型、噴泉模型以及結構化方法、信息模型方法、面向對象方法等不同模型及方法的軟件開發(fā)環(huán)境。
共一百三十四頁軟件開發(fā)環(huán)境的分類-按功能及結構(jiégòu)特點分類有單體型、協(xié)同(xiétóng)型、分散型和并發(fā)型等多種類型的軟件開發(fā)環(huán)境。
共一百三十四頁軟件開發(fā)環(huán)境(huánjìng)的分類-按開發(fā)階段分類前端開發(fā)環(huán)境(huánjìng)(支持系統(tǒng)規(guī)劃、分析、設計等階段的活動);后端開發(fā)環(huán)境(支持編程、測試等階段的活動);軟件維護環(huán)境;逆向工程環(huán)境;
此類環(huán)境往往可通過對功能較全的環(huán)境進行剪裁而得到。共一百三十四頁軟件開發(fā)環(huán)境的分類(fēnlèi)-按應用范圍分類
有通用型和專用型軟件開發(fā)環(huán)境。其中(qízhōng)專用型軟件開發(fā)環(huán)境與應用領域有關;
共一百三十四頁軟件開發(fā)環(huán)境(huánjìng)的構造
軟件開發(fā)環(huán)境由工具集和集成(jíchénɡ)機制兩部分構成,工具集和集成(jíchénɡ)機制間的關系如同“插件”和“插槽”間的關系。
共一百三十四頁工具集軟件開發(fā)環(huán)境中的工具可包括:
支持特定過程模型和開發(fā)方法的工具,如支持瀑布(pùbù)模型及數(shù)據(jù)流方法的分析工具、設計工具、編碼工具、測試工具、維護工具,支持面向對象方法的OOA工具、OOD工具和OOP工具等;
獨立于模型和方法的工具,如界面輔助生成工具和文檔出版工具;
亦可包括管理類工具和針對特定領域的應用類工具。
共一百三十四頁集成(jíchénɡ)機制
對工具的集成及用戶軟件的開發(fā)、維護及管理提供統(tǒng)一的支持。按功能(gōngnéng)可劃分為環(huán)境信息庫、過程控制及消息服務器、環(huán)境用戶界面三個部分。共一百三十四頁環(huán)境(huánjìng)信息庫是軟件開發(fā)環(huán)境的核心,用以儲存與系統(tǒng)開發(fā)有關的信息并支持(zhīchí)信息的交流與共享。庫中儲存兩類信息,一類是開發(fā)過程中產(chǎn)生的有關被開發(fā)系統(tǒng)的信息,如分析文檔、設計文檔、測試報告等;另一類是環(huán)境提供的支持(zhīchí)信息,如文檔模板、系統(tǒng)配置、過程模型、可復用構件等。共一百三十四頁過程(guòchéng)控制和消息服務器是實現(xiàn)過程集成及控制集成的基礎。過程集成是按照具體軟件開發(fā)過程的要求進行工具(gōngjù)的選擇與組合,控制集成并行工具(gōngjù)之間的通信和協(xié)同工作。共一百三十四頁環(huán)境(huánjìng)用戶界面包括環(huán)境總界面和由它實行統(tǒng)一控制的各環(huán)境部件及工具的界面。統(tǒng)一的、具有一致視感(Look&Feel)的用戶界面是軟件開發(fā)環(huán)境的重要(zhòngyào)特征,是充分發(fā)揮環(huán)境的優(yōu)越性、高效地使用工具并減輕用戶的學習負擔的保證。共一百三十四頁完善(wánshàn)的軟件開發(fā)環(huán)境通常具有如下:(1)軟件開發(fā)的一致性及完整性維護;
(2)配置管理及版本控制;
(3)數(shù)據(jù)的多種表示形式及其在不同形式之間自動轉換(zhuǎnhuàn);
(4)信息的自動檢索及更新;
(5)項目控制和管理;
(6)對方法學的支持;共一百三十四頁軟件開發(fā)環(huán)境(huánjìng)與軟件開發(fā)方法軟件開發(fā)方法(SoftwareDevelopmentMethod)是指軟件開發(fā)過程所遵循的辦法和步驟。軟件開發(fā)活動的目的是有效地得到一些工作產(chǎn)物,也就是一個(yīɡè)運行的系統(tǒng)及其支持文檔,并且滿足有關的質量要求。軟件開發(fā)是一種非常復雜的腦力勞動,所以經(jīng)常更多討論的是軟件開發(fā)方法學,指的是規(guī)則、方法和工具的集成,既支持開發(fā),也支持以后的演變過程(交付運行后,系統(tǒng)還會變化,或是為了改錯,或是為了功能的增減)。共一百三十四頁典型(diǎnxíng)的軟件開發(fā)和系統(tǒng)演化的活動分析、設計、實現(xiàn)、確認(測試驗收)、演化(yǎnhuà)(維護)共一百三十四頁①覆蓋開發(fā)全過程,并且便于在各階段間的過渡;②便于在開發(fā)各階段中有關人員之間的通信;③支持有效的解決問題的技術;④支持系統(tǒng)設計和開發(fā)的各種不同(bùtónɡ)途徑;⑤在開發(fā)過程中支持軟件正確性的校驗和驗證;軟件開發(fā)方法(fāngfǎ)應該考慮的一般因素共一百三十四頁軟件開發(fā)方法(fāngfǎ)應該考慮的一般因素⑥便于在系統(tǒng)需求中列入設計、實際和性能的約束;⑦支持(zhīchí)設計師和其他技術人員的智力勞動;⑧在系統(tǒng)的整個生存周期都支持它的演化;⑨受自動化工具的支持。此外,在開發(fā)的所有階段,有關的軟件產(chǎn)物都應該是可見和可控的;軟件開發(fā)方法應該可教學、可轉移,還應該是開放的,即可以容納新的技術、治理方法和新工具,并且與已有的標準相適應可稱為應用型軟件開發(fā)環(huán)境。共一百三十四頁主要(zhǔyào)的面向對象軟件工程方法CRC卡UML共一百三十四頁CRC卡一種(yīzhǒnɡ)簡單的面向對象建模方法CRC(Class-Responsibility-Collaborator)卡建模是一種簡單且有效(yǒuxiào)的面向對象的分析技術。它由三部分組成:
1.類(Class)
2.職責(Responsibility)
3.協(xié)作(Collaborator)共一百三十四頁CRC卡的類一個類代表許多(xǔduō)類似的對象。而對象是系統(tǒng)模型化中關注的事物。他們可以是一個人、地方、事情、或任何對系統(tǒng)有重要性的概念。類名一般列在CRC卡的頂部。
共一百三十四頁CRC卡的職責(zhízé)職責是類需要知道或做的任何事物。這些職責是類自身(zìshēn)所知的知識,或類在執(zhí)行時所需的知識。共一百三十四頁CRC卡的協(xié)作(xiézuò)協(xié)作是指為獲取消息,或協(xié)助執(zhí)行活動(huódòng)的其他類。在特定情形下,與指定的類按一個設想共同完成一個(或許多)步驟。協(xié)作的類順著CRC卡的右邊排列。
共一百三十四頁CRC模型(móxíng)CRC模型(móxíng)是CRC卡的集合,它代表一個應用域或問題域的全部或一部分。共一百三十四頁CRC范例(fànlì)CRC模型是最普遍(pǔbiàn)的用戶。圖中展示了一個航運/存貨控制系統(tǒng)的CRC模型例子,展示的CRC卡將被放在一張書桌或工作桌上。注意卡的放置:相互協(xié)作的卡是彼此接近的,無關系的卡不能放在附近。共一百三十四頁CRC卡的構建(ɡòujiàn)步驟一1、CRC模型組一起加入(模型組包括相關的客戶領域人員、設計者、記錄員、系統(tǒng)分析員等)。
2、安排模型房間。
3、進行集體自由(zìyóu)討論
內(nèi)容根據(jù)此CRC模型的系統(tǒng)目標進行,如系統(tǒng)是為誰開發(fā)的?那些商業(yè)業(yè)務需要這個系統(tǒng)的何種支持?工作時需要什么信息?……總之盡量按能達到系統(tǒng)要求實現(xiàn)的目標進行,包括進行活動時對資源、條件、活動及人員的要求。
共一百三十四頁CRC卡構建(ɡòujiàn)步驟二4、講解(jiǎngjiě)CRC模型技術(完成集體討論后,設計者將描述CRC模型過程。通常需要花費十至十五分鐘,該過程包括創(chuàng)造幾個CRC卡范例,范例參考上圖)。
5、重復地執(zhí)行CRC模型步驟。
6、執(zhí)行用例情景試驗
用戶情景試驗是一個任務過程模式,其中用戶們將積極地參與以保證需求是準確的?;镜乃枷胧且唤M商業(yè)領域專家(也就是客戶方),設計者,系統(tǒng)分析員一步步通過一系列的用例證實CRC模能準確地反映出用戶的需求。共一百三十四頁CRC模型(móxíng)的優(yōu)點CRC模型就是一種溝通方式,客戶方與開發(fā)方如何通過這種有效的、易實現(xiàn)、易操作的方式建立一個能描述準確的、雙方達成共識(ɡònɡshí)的系統(tǒng)需求。CRC建模因為用戶積極參與到模型的定義中,他們對工作的滿意度就會增加,并與開發(fā)者們并肩創(chuàng)造這個CRC模型,通過這個一連串的模型卡,雙方對待建的系統(tǒng)需求目標達成共識。共一百三十四頁CRC卡的缺點(quēdiǎn)CRC模型只是一個面向對象應用的用戶需求定義的一部分。你也應該考慮到用例,原型,和正式的需求文檔。是否要使用(shǐyòng)CRC建模,就根據(jù)項目、企業(yè)、客戶自身存在和所需的條件而定了
共一百三十四頁面向對象的軟件過程(guòchéng)-噴泉模型需求(xūqiú)階段面向對象分析階段面向對象設計階段編碼階段集成和測試階段運行狀態(tài)進一步開發(fā)維護期噴泉模型的生命周期與結構化方法的生命周期是一致的,但噴泉模型的各個階段是迭代和無縫的。共一百三十四頁面向對象的軟件(ruǎnjiàn)過程-RUPRUP的二維開發(fā)(kāifā)模型橫軸是過程展開的生命周期特征,體現(xiàn)開發(fā)過程的動態(tài)結構,用來描述它的術語主要包括周期(Cycle)、階段(Phase)、迭代(Iteration)和里程碑(Milestone);
縱軸以內(nèi)容來組織為自然的邏輯活動,體現(xiàn)開發(fā)過程的靜態(tài)結構,用來描述它的術語主要包括活動(Activity)、產(chǎn)物(Artifact)、工作者(Worker)和工作流(Workflow)。共一百三十四頁RUP的各個(gègè)階段和里程碑-橫向RUP中的軟件生命周期在時間(shíjiān)上被分解為四個順序的階段
初始階段(Inception)
(生命周期目標里程碑)
前景文檔:對核心項目要求、關鍵性質、主要限制的一般性的前景說明;初始的用例模型(完成10%-20%);初始的項目術語表;初始的商業(yè)用例,包括商業(yè)環(huán)境、驗收規(guī)范以及成本預測;初始的風險評估;項目規(guī)劃,其中明確階段和迭代;商業(yè)模型,根據(jù)需要可選;一個或多個原型;細化階段(Elaboration)(生命周期結構里程碑)
構造階段(Construction)(初始運行能力)交付階段(Transition)(產(chǎn)品發(fā)布里程碑)
用例模型(至少完成80%):識別出了所有的用例和角色,以及大多數(shù)用例的描述;調(diào)整一些增加的需求,包括非功能性需求以及任何與特定用例無關的需求;
軟件體系結構描述;可執(zhí)行的體系結構原型;修訂后的風險表和商業(yè)用例;整個項目的開發(fā)計劃,包括粗略項目規(guī)劃,顯示迭代過程以及相應的評估準則;更新的開發(fā)用例,指定要使用的過程;初步的用戶手冊(可選);
在特定平臺上集成的軟件產(chǎn)品;用戶手冊;
對當前版本的描述;beta測試確認新系統(tǒng)達到用戶的預期;與被取代的舊系統(tǒng)并行操作;功能性數(shù)據(jù)庫的轉換;用戶和維護人員培訓;
向市場、分銷商和銷售人員進行新產(chǎn)品的展示;共一百三十四頁RUP的核心(héxīn)工作流-縱向
描述如何為新的目標組織開發(fā)一個構想,并基于這個構想在商業(yè)用例模型和商業(yè)對象(duìxiàng)模型中定義組織的過程,角色和責任。
描述系統(tǒng)應該做什么,并使開發(fā)人員和用戶就這一描述達成共識。為了達到該目標,要對需要的功能和約束進行提取、組織、文檔化;最重要的是理解系統(tǒng)所解決問題的定義和范圍。
設計活動以體系結構設計為中心,體系結構由若干結構視圖來表達,結構視圖是整個設計的抽象和簡化。分析設計的結果是一個設計模型和一個可選的分析模型。
目的包括以層次化的子系統(tǒng)形式定義代碼的組織結構;以組件的形式(源文件、二進制文件、可執(zhí)行文件)實現(xiàn)類和對象;將開發(fā)出的組件作為單元進行測試以及集成由單個開發(fā)者(或小組)所產(chǎn)生的結果,使其成為可執(zhí)行的系統(tǒng)。
目的是驗證對象間的交互作用,驗證軟件中所有組件的正確集成,檢驗所有的需求已被正確的實現(xiàn),識別并確認缺陷在軟件部署之前被提出并處理。RUP提出了迭代的方法,意味著在整個項目中進行測試,從而盡可能早地發(fā)現(xiàn)缺陷,從根本上降低了修改缺陷的成本。
目的是成功的生成版本并將軟件分發(fā)給最終用戶。部署工作流描述了那些與確保軟件產(chǎn)品對最終用戶具有可用性相關的活動,包括:軟件打包、生成軟件本身以外的產(chǎn)品、安裝軟件、為用戶提供幫助。在有些情況下,還可能包括計劃和進行beta測試版、移植現(xiàn)有的軟件和數(shù)據(jù)以及正式驗收。
描繪了如何在多個成員組成的項目中控制大量的產(chǎn)物。配置和變更管理工作流提供了準則來管理演化系統(tǒng)中的多個變體,跟蹤軟件創(chuàng)建過程中的版本。同時也闡述了對產(chǎn)品修改原因、時間、人員保持審計記錄。
平衡各種可能產(chǎn)生沖突的目標,管理風險,克服各種約束并成功交付使用戶滿意的產(chǎn)品。
目的是向軟件開發(fā)組織提供軟件開發(fā)環(huán)境,包括過程和工具。共一百三十四頁UML語言(yǔyán)JimRumbaughGradyBoochIvarJacobson共一百三十四頁UML的簡介(jiǎnjiè)UML(UnifiedModelingLanguage)是一種構建軟件系統(tǒng)和文檔的通用可視化建模語言。UML能與所有的開發(fā)方法一同使用,可用于軟件開發(fā)的整個生命周期。UML能表達系統(tǒng)的靜態(tài)(jìngtài)結構和動態(tài)信息,并能管理復雜的系統(tǒng)模型,便于軟件團隊之間的合作開發(fā)。UML不是編程語言,但支持UML語言的工具可以提供從UML到各種編程語言的代碼生成,也可以提供從現(xiàn)有程序逆向構建UML模型。UML并不是萬能的,它是一種離散的建模語言,對于特定的領域,比如:GUI、VLSI電路設計或基于規(guī)則的人工智能,用特定的語言和工具可能更合適。共一百三十四頁最重要目標:UML是所有建模人員可以使用的通用建模語言。它包含主流建模方法的概念,從而可以替代現(xiàn)有的軟件分析和設計方法,比如:OMT,Booch,OOSE等。UML不是完整的開發(fā)方法,它不包括逐步的開發(fā)流程,但它提供所有必要的概念,具備足夠的表達能力。UML的另一個目標是:能盡量簡潔地表達系統(tǒng)(xìtǒng)的模型。UML的目標(mùbiāo)共一百三十四頁UML概念可以劃分為以下范圍(fànwéi):系統(tǒng)需求靜態(tài)結構動態(tài)行為交互行為物理實現(xiàn)各種圖之間的關系模型組織擴展機制UML的主要(zhǔyào)概念共一百三十四頁用例視圖(UseCasesView)從外部用戶的角度來描述系統(tǒng)的行為,它將系統(tǒng)功能劃分為對用戶有意義的事務,這些事務被稱為用例,用戶被稱為執(zhí)行者,用例視圖也就是描述活動者在各個用例中的參與情況,它指導(zhǐdǎo)所有的行為視圖。系統(tǒng)(xìtǒng)需求共一百三十四頁靜態(tài)視圖(StaticView),一個模型必須首先定義各種事物的內(nèi)部特征(tèzhēng)和相互之間的關系,應用概念建模成類,類描述事物的屬性和以及在這些屬性上的操作。類之間可以存在不同的關系,比如泛化(繼承)、關聯(lián)和依賴等,靜態(tài)視圖表示成類圖,靜態(tài)視圖在某一時刻的快照稱為對象圖。靜態(tài)(jìngtài)結構共一百三十四頁狀態(tài)機視圖(StateMachineView),通過對每個類的對象的生命周期進行建模,描述了對象時間上的動態(tài)行為。狀態(tài)機是由狀態(tài)和遷移組成的圖,狀態(tài)機通常附屬于類,描述類實例對接受事件的響應。活動視圖(ActivityView)是利用狀態(tài)機對運算和工作(gōngzuò)流進行建模的特殊形式?;顒訄D的狀態(tài)代表了運算執(zhí)行的狀態(tài),而非一般對象的狀態(tài),活動圖和流程圖很相似,不過它支持并發(fā)。動態(tài)(dòngtài)行為共一百三十四頁交互視圖(InteractionView),對象通過交互來實現(xiàn)行為(xíngwéi),交互視圖通過協(xié)作來進行建模,協(xié)作具有結構和行為兩個方面,結構包含為行為方面而定義的一系列角色和關系,行為方面是綁定于角色的對象間的一系列交換的消息,這些消息在協(xié)作中稱為交互,消息序列可用兩種圖來表示:順序圖(重點在消息的時間順序)和協(xié)作圖(重點在交換消息的對象間的關系)。交互(jiāohù)行為共一百三十四頁物理視圖(PhysicalView),許多系統(tǒng)模型獨立于最終的實現(xiàn),在實現(xiàn)方面,必須充分考慮系統(tǒng)的重用性和性能。UML有兩種視圖來表示系統(tǒng)的實現(xiàn):實現(xiàn)視圖和部署視圖,實現(xiàn)視圖將可重用的系統(tǒng)片段打包成組件(zǔjiàn),部署視圖描述系統(tǒng)運行時資源的物理分布,這些資源稱為結點。物理(wùlǐ)實現(xiàn)共一百三十四頁靜態(tài)視圖(類圖,對象圖),物理視圖(實現(xiàn)視圖,部署視圖)是描述系統(tǒng)的靜態(tài)結構。用例圖是描述系統(tǒng)的外部視圖?;顒訄D描述系統(tǒng)的外部/內(nèi)部視圖。交互視圖(順序圖,協(xié)作圖)描述系統(tǒng)的內(nèi)部視圖。狀態(tài)圖描述單個類的動態(tài)(dòngtài)行為。各種(ɡèzhǒnɡ)圖之間的關系共一百三十四頁模型管理視圖(ModelManagementView),任何大系統(tǒng)必須劃分為較小的單元,以使人們能在某一時刻只接觸有限(yǒuxiàn)的信息,不影響團隊間的并行工作。模型是利用包(Package)和包的依賴來進行管理的。包是UML模型中通用的層次組織結構,包上的依賴總結了包內(nèi)容的依賴關系。模型(móxíng)組織共一百三十四頁擴展機制(ExtensionMechanisms),UML能滿足絕大部分系統(tǒng)建模的需要,但任何語言都不是(bùshi)萬能的,它必須考慮一定的擴展機制,UML的擴展機制包括約束、標簽值和原型。這些擴展機制可以用來為特定領域剪裁UML的配置,這樣帶來一些好處:根據(jù)自身需要來使用建模語言。擴展(kuòzhǎn)機制共一百三十四頁一個模型必須首先(shǒuxiān)定義各種事物的內(nèi)部特征和相互之間的關系,下面介紹一些基本的模型元素:分類(fēnlèi):類(Class)接口(Interface)子系統(tǒng)(SubSystem)執(zhí)行者(Actor)用例(UseCases)組件(Component)結點(Node)注釋(Comment)關系:關聯(lián)(Association)泛化(Generalization)依賴(Dependency)實現(xiàn)(Realization)約束(Constraint)靜態(tài)視圖:類圖對象圖靜態(tài)建模共一百三十四頁類是具有相同屬性、操作和關系的對象集合的總稱。通常在UML中類被畫成矩形,包括三個部分:名稱、屬性和操作。名稱:每個類都必須有一個名字,用來區(qū)分其它的類。類名(lèimínɡ)是一個字符串,稱為簡單名字。路徑名字是在類名(lèimínɡ)前加包含類的包名為前綴。例如Wall、java::awt::Wall都是合法的類名。屬性:類可以有任意多個屬性,也可以沒有屬性。在類圖中屬性只要寫上名字就可以了,也可以在屬性名后跟上類型甚至缺省取值。
操作:操作是類的任意一個實例對象都可以調(diào)用的,并可能影響該對象行為的實現(xiàn)。
靜態(tài)(jìngtài)建模-類共一百三十四頁類名(lèimínɡ)屬性(shǔxìng)操作共一百三十四頁接口是未給出實現(xiàn)的對象行為的描述(miáoshù),接口包含操作,但沒有屬性,一個或多個類可以實現(xiàn)接口,每個類實現(xiàn)接口的操作。StringisEqual(String):BooleanHash():Integer…HashableComparable接口(jiēkǒu)標記靜態(tài)建模-接口共一百三十四頁任何大系統(tǒng)都必須劃分為較小的單元,以便人們在某一時刻可以和有限的信息工作,使團隊的工作不相互影響。包可以包含各種模型(móxíng)元素和其它的包,包之間還可能存在一定的依賴。<<subsystem>>Finances<<subsystem>>Credits<<subsystem>>Accounts<<subsystem>>BankInterface靜態(tài)(jìngtài)建模-子系統(tǒng)(包)共一百三十四頁執(zhí)行者是與系統(tǒng)、子系統(tǒng)或類交互的外部人員(rényuán),進程或事務。在運行時,具體人員(rényuán)會充當系統(tǒng)的多個執(zhí)行者,不同用戶可能會成為一個執(zhí)行者。StudentProfessorBillingSystemRegistrar靜態(tài)(jìngtài)建模-執(zhí)行者共一百三十四頁用例是系統(tǒng)提供的外部可感知的功能單元,用例的目的是定義清晰的系統(tǒng)行為,但不解釋系統(tǒng)的內(nèi)部結構。用例可以與執(zhí)行者關聯(lián),也可以參與(cānyù)其他的多種關系,比如擴展、泛化和包含等。用戶的動態(tài)部分用交互視圖來描述,比如順序圖、協(xié)作圖。用例用橢圓來表示,用例名標在橢圓下方,用實線與同自身通信的用戶相連。MaintainCurriculum靜態(tài)(jìngtài)建模-用例共一百三十四頁Registrar--maintainthecurriculumProfessor--requestrosterStudent--maintainscheduleBillingSystem--receivebillinginformationfromregistrationMaintainScheduleMaintainCurriculumRequestCourseRoster靜態(tài)(jìngtài)建模-用例共一百三十四頁用例圖描述執(zhí)行者在各個用例中的參與(cānyù)情況。StudentRegistrarProfessorMaintainScheduleMaintainCurriculumRequestCourseRosterBillingSystem靜態(tài)(jìngtài)建模-用例圖共一百三十四頁組件是可重用的系統(tǒng)片段,具有良好定義接口的物理實現(xiàn)單元。每個組件包含了系統(tǒng)設計中某些類的實現(xiàn)。組件設計的原則:良好的組件不直接依賴于其它組件,而是依賴于其它組件所支持的接口。這樣的好處是系統(tǒng)中的組件可以被支持相同接口的組件所取代(qǔdài)。一個組件可能是源代碼、可執(zhí)行程序或動態(tài)庫。Student靜態(tài)(jìngtài)建模-組件共一百三十四頁結點代表系統(tǒng)運行時的物理對象,結點通常擁有運算能力,它可以容納對象和組件(zǔjiàn)實例。RegistrationDatabaseLibraryDormMainBuilding靜態(tài)(jìngtài)建模-結點共一百三十四頁注釋用于解釋設計的思路,便于理解。一個好的模型應該(yīnggāi)有詳盡的注釋。RepresentsanincorporatedentityCompany…注釋(zhùshì)靜態(tài)建模-注釋共一百三十四頁關聯(lián)描述了系統(tǒng)中對象和其它實例之間的離散(lísàn)的連接,關聯(lián)是有序的,它允許重復,關聯(lián)的實例是鏈。關聯(lián)至對象的連接點稱為關聯(lián)端點,很多信息被附在關聯(lián)端點上,它擁有角色名、重數(shù)(多少個類的實例可以關聯(lián)于另一個類的實例),可見性等。關聯(lián)有自己的名稱,可以擁有自己的屬性,這時關聯(lián)本身也是類,稱為關聯(lián)類。靜態(tài)(jìngtài)建模關系-關聯(lián)共一百三十四頁ManagesJobbossworkeremployeeemployer1..***0..1CompanyPersonJobSalary角色(juésè)名重數(shù)(zhònɡshù)關聯(lián)名稱關聯(lián)類二元關聯(lián)自關聯(lián)共一百三十四頁聚集(jùjí)(Aggregation)用來表達整體-部分關系的關聯(lián)。組合(Composition)是一種聚集,是關聯(lián)更強的形式。PolygonPoint13..*pointsContainsPolygonWindowSlider12ScrollbarHeader1Title11Panel1Body聚集(jùjí)組合靜態(tài)建模關系-聚合和組合共一百三十四頁泛化是一般化和具體化之間的一種關系。繼承就是一種泛化關系,更一般化的描述稱為雙親,雙親的雙親稱為祖先,更具體化的描述稱為孩子,在類的范疇(fànchóu),雙親對應超類,孩子對應子類。TreeOakElmBirch孩子(háizi)雙親PersonStudentGraduate祖先靜態(tài)建模關系-泛化共一百三十四頁多重繼承:一個孩子可以從多個雙親繼承屬性和方法。多重繼承可能存在沖突,因為(yīnwèi)被繼承的雙親可能存在相同的類聲明,這時,最好顯式解決沖突問題。AssistantTeacherStudent靜態(tài)(jìngtài)建模關系-多重繼承共一百三十四頁依賴指明兩個或兩個以上(yǐshàng)模型元素之間的關系。依賴有很多種類,比如:實現(xiàn)(realize)、使用、(usage)、實例化(instantiate)、調(diào)用(call),派生(derive)、訪問(access)、引入(import)、友元(friend)等等。<<subsystem>>ApplicationServer<<subsystem>>DataBase<<usage>>依賴(yīlài)類型靜態(tài)建模關系-依賴共一百三十四頁實現(xiàn)是依賴的一種,但由于它具有特殊意義,所以將它獨立講述。實現(xiàn)是連接(liánjiē)說明和實現(xiàn)之間的關系。StringisEqual(String):BooleanHash():Integer…Comparable<<interface>>ComparableisEqual(String):BooleanHash():Integer…實現(xiàn)(shíxiàn)特殊的實現(xiàn)標記靜態(tài)建模關系-實現(xiàn)共一百三十四頁約束用來(yònɡlái)表示各種限制,如關聯(lián)路徑上的限制,和屬性特征檢測(存在、所有)。PersonCommitteeMember-of約束(yuēshù)Chair-of{subset}靜態(tài)建模關系-約束共一百三十四頁靜態(tài)視圖是UML的基礎,靜態(tài)視圖表示(biǎoshì)為類圖,主要是描述類和類之間的關系。繼承(jìchéng)關聯(lián)PersonHouseresidence0..*owner0..*Financial
Institutionclientcreditor0..*0..*Mortgageprincipalrateterm關聯(lián)類{ordered}0..*1BankTrust
Company靜態(tài)建模-類圖共一百三十四頁對象(duìxiàng)圖是系統(tǒng)在某一時刻的快照。Smith:Personcottage:Househome:Housefirst:Mortgagesecond:MortgageRoyalBank:Bank鏈靜態(tài)(jìngtài)建模-對象圖共一百三十四頁狀態(tài)機圖用例圖活動(huódòng)圖順序圖協(xié)作圖動態(tài)(dòngtài)建模共一百三十四頁狀態(tài)機圖是對單個類的對象的生命周期進行建模,描述了對象時間上的動態(tài)行為,每個對象被認為是事件驅動的孤立實體。狀態(tài)機圖是由狀態(tài)和躍遷組成的圖,通常狀態(tài)機附屬于類,描述類實例對接受(jiēshòu)事件的響應。事件表達對象間的調(diào)用、顯式信號、值的改變或時間的推移。調(diào)用事件、變更事件、信號事件、時間事件狀態(tài)描述對象生命周期的一段時間,可以是等待其它事件時所處的時間,或是執(zhí)行某一活動時所處的時間,狀態(tài)分為簡單狀態(tài)和復合狀態(tài)。動態(tài)(dòngtài)建模-狀態(tài)機圖共一百三十四頁躍遷定義對象對某一事件發(fā)生的反應,通常,遷移具有觸發(fā)事件、躍遷條件、動作和目標狀態(tài)。躍遷的種類有外部躍遷和內(nèi)部躍遷。外部躍遷是最普通的躍遷,會發(fā)生狀態(tài)改變;內(nèi)部躍遷不發(fā)生狀態(tài)改變。躍遷有兩個隱式動作:進入動作和退出動作。無論何時進入和退出時都要執(zhí)行,這方便(fāngbiàn)進入時進行初始化工作,退出時進行資源的釋放工作。動態(tài)(dòngtài)建模-狀態(tài)機圖共一百三十四頁createdreadyHandle
EventInitialize
ObjectTerminate
ObjectWaitfor
Eventstart/^master.ready()poll/^master.ack()stop/初始狀態(tài)結束(jiéshù)狀態(tài)狀態(tài)機狀態(tài)(zhuàngtài)觸發(fā)事件動作表達式躍遷共一百三十四頁用例圖描述各個執(zhí)行者在各個用例中的參與情況,描述系統(tǒng)為用戶所感知的外部視圖。用例圖的功能:捕獲系統(tǒng)用戶需求描述系統(tǒng)邊界指明系統(tǒng)外部行為(xíngwéi)指導系統(tǒng)開發(fā)者的功能開發(fā)系統(tǒng)建模的起點,指導所有的類圖和交互圖的設計產(chǎn)生測試用例,用戶文檔估計項目大小和進度。動態(tài)(dòngtài)建模-用例圖共一百三十四頁CustomerSalesmanSupplierSupervisorSaleManagementSupply執(zhí)行者用例系統(tǒng)(xìtǒng)邊界共一百三十四頁活動圖是用狀態(tài)機對工作流進行建模的特殊形式,它和流程圖很類似,不過它支持并發(fā)控制?;顒訄D一般不描述所有的運算細節(jié),它顯示活動的流,但不顯示執(zhí)行活動的對象?;顒訄D處于系統(tǒng)的外部和內(nèi)部視圖之間,所以它可以作為設計的起點,為了完成設計,每個活動必須擴展成一個和多個操作,每個操作被指派給特定的對象來實現(xiàn)。將商業(yè)組織控制的活動劃分在一起,這類劃分可以通過分隔的區(qū)域來表達,由于它們的外觀,每個區(qū)域稱為(chēnɡwéi)泳道(swimlane)。動態(tài)(dòngtài)建模-活動圖共一百三十四頁CustomerSalesStockroomRequestServicePayTakeOrderFillOrderDeliverOrderCollectOrder泳道(yǒnɡdào)共一百三十四頁帶有對象(duìxiàng)流的活動圖CustomerSalesStockroomRequestServicePayTakeOrderFillOrderDeliverOrderCollectOrder泳道(yǒnɡdào)Order[Placed]Order[Entered]Order[Filled]Order[Delivered]對象共一百三十四頁對象行為是通過交互來實現(xiàn)的,交互是對象間為完成某一目的而進行的一系列消息交換。消息是對象間的單向(dānxiànɡ)通信,從發(fā)送者到接受者的攜帶信息的控制流。消息可能帶有值參。消息序列可用兩種圖表示:順序圖(重點在消息的時間順序)和協(xié)作圖(重點在交換消息的對象間的關系)。對協(xié)作圖來說,時間順序可以從順序號獲得。動態(tài)(dòngtài)建模-交互視圖共一百三十四頁順序圖用二維表來表示交互,縱向是時間軸,橫向是參與的角色以及(yǐjí)它們交換的消息。角色的生命周期表現(xiàn)為生命線,一條垂直的線,在激活的時間段里是雙線,在狀態(tài)保持的時間里是虛線。消息表示為從一條生命線出發(fā)到另一條生命線的有向線,從上而下,表示消息的時間順序。動態(tài)(dòngtài)建模-順序圖共一百三十四頁CallerOperatorCallee時間軸callacknumbercallacktalktransfer順序(shùnxù)圖生命線激活(jīhuó)狀態(tài)保持角色共一百三十四頁協(xié)作圖包含分類角色和關聯(lián)角色,當它實例化時,對象被綁定到分類角色,鏈被綁定到關聯(lián)角色.關聯(lián)角色還可能被各種暫時性的鏈來充當,如過程參數(shù)(cānshù)和局部過程變量,鏈可以指定暫時性的原型:<<parameter>>、<<local>>或自身調(diào)用<<self>>。協(xié)作圖對實現(xiàn)協(xié)作的對象和鏈進行建模,而忽略其他對象。動態(tài)(dòngtài)建模-協(xié)作圖共一百三十四頁StudentRegistrationFormRegistrationManager1:fillininfo2:submit3:add(smith,math)math4:add(smith)共一百三十四頁通常在一個協(xié)作圖中每個對象(duìxiàng)分配一個符號,然而有時不同狀態(tài)的對象(duìxiàng)需要顯式指出,流將同一個對象的不同狀態(tài)版本關系在一起,使用<<become>>原型。流的<<copy>>原型不太常用。:Controller:Directory[closed]:Directory[open]1:expand()2:sort()1.1<<become>>流共一百三十四頁物理架構-實現(xiàn)(shíxiàn)視圖實現(xiàn)視圖描述可重用的系統(tǒng)組件(zǔjiàn)以及組件(zǔjiàn)之間的依賴。CourseCourseOfferingStudentProfessorCourse.dllPeople.dllCourseUserRegister.exeBilling.exeBillingSystem共一百三十四頁部署視圖描述系統(tǒng)資源在運行時的物理分布(fēnbù),系統(tǒng)資源成為結點。RegistrationDatabaseLibraryDormMainBuilding物理架構-部署(bùshǔ)視圖共一百三十四頁UML是一種建模語言而不是方法,這是因為UML中沒有過程的概念,而過程正是方法的一個重要組成部分。UML本身獨立于過程,這意味著用戶在使用UML進行建模時,可以選用任何適合的過程。一般采用(cǎiyòng)的建模過程有:噴泉模型、迭代遞增開發(fā)模型。UML建模過程(guòchéng)共一百三十四頁UML建模過程-瀑布(pùbù)開發(fā)模型需求階段面向對象分析階段面向對象設計階段編碼階段集成和測試階段運行狀態(tài)進一步開發(fā)維護期共一百三十四頁設計編碼測試更多需求與分析迭代(diédài)遞增開發(fā)模型最初需求(xūqiú)與分析產(chǎn)品維護請求共一百三十四頁[1]需求最初需求規(guī)格說明應當由代表系統(tǒng)最終用戶的人員提供,內(nèi)容包括系統(tǒng)基本功能需求和對計算機系統(tǒng)的要求。[2]分析分析的任務是找出系統(tǒng)的所有需求并加以描述,同時建立模型,以定義系統(tǒng)中的關鍵領域類,應由系統(tǒng)用戶和開發(fā)人員合作完成。分析的第一步是定義用例,以描述所開發(fā)系統(tǒng)的外部功能需求。用例分析包括閱讀和分析需求說明,此時需要(xūyào)與系統(tǒng)的潛在用戶進行討論。迭代(diédài)遞增開發(fā)模型共一百三十四頁[3]設計設計階段的任務是通過綜合考慮所有的技術限制,以擴展和細化分析階段的模型。設計階段可以分為兩個部分:結構設計是高層設計,其任務是定義包(子系統(tǒng)),包括包間的依賴性和主要通信機制。我們希望(xīwàng)得到盡可能簡單和清晰的結構,各部分之間的依賴盡可能的少,并盡可能的減少雙向的依賴關系。第二部分是詳細設計,細化包的內(nèi)容,使編程人員得到所有類的一個足夠清晰的描述。共一百三十四頁結構設計一個設計良好的系統(tǒng)結構是系統(tǒng)可擴充和可變更的基礎。包實際上是一些類的集合。類圖中包括有助于用戶從技術邏輯中分離(fēnlí)出應用邏輯(領域類),從而減少它們之間的依賴性。詳細設計詳細設計的目的是通過創(chuàng)建新的類圖、狀態(tài)圖和動態(tài)圖(順序圖、協(xié)作圖和活動圖),描述新的技術類,并擴展和細化分析階段的對象類。共一百三十四頁[4]實現(xiàn)構造或實現(xiàn)階段是對類進行編程的過程??梢?kěyǐ)選擇某種面向對象對象編程語言(如Java)作為實現(xiàn)系統(tǒng)的軟件環(huán)境。Java很容易實現(xiàn)從邏輯視圖到代碼部件的映射,因為類到Java代碼文件之間是一一映射關系。在實現(xiàn)階段中,可以選取各種圖的說明來輔助編程,比如:類圖,狀態(tài)圖和動態(tài)圖等。共一百三十四頁[5]測試和配置完成系統(tǒng)編碼后,需要對系統(tǒng)進行測試,它通常包括:單元測試、集成測試、系統(tǒng)測試和驗收測試。
在單元測試中使用類圖和類的規(guī)格說明,對單獨的類或一組類進行測試;在集成測試中,使用組件圖和合作圖,對各組件的合作情況進行測試;在系統(tǒng)測試中,使用用例圖,以檢驗所開發(fā)的系統(tǒng)是否滿足例圖所描述的需求(xūqiú)。系統(tǒng)的配置是實際地交付系統(tǒng),包括文檔和組成模型等。共一百三十四頁ROSE是美國Rational公司的面向對象建模工具,利用這個工具,我們可以建立用UML描述的軟件系統(tǒng)的模型,而且可以自動生成和維護C++、Java、VB、Oracle等語言和系統(tǒng)的代碼。ROSE的界面分為三個部分——Browser窗口、Diagram窗口和Document窗口。Browser窗口用來瀏覽、創(chuàng)建、刪除(shānchú)和修改模型中的模型元素;Diagram窗口用來顯示和創(chuàng)作模型的各種圖;而Document窗口則是用來顯示和書寫各個模型元素的文檔注釋。Rose的使用(shǐyòng)共一百三十四頁Browser窗口(chuāngkǒu)Diagram窗口(chuāngkǒu)Document窗口Specification對話框工具欄工具箱共一百三十四頁Browser窗口(chuāngkǒu)有四個視圖:UseCaseLogicalComponentDeployment共一百三十四頁在UseCase視圖(shìtú)的圖的類型有:用例圖、順序圖、協(xié)作圖和活動圖。共一百三十四頁在Logical視圖(shìtú)中的類型有:類圖和狀態(tài)圖。共一百三十四頁在Component視圖(shìtú)的圖的類型有:組件圖。共一百三十四頁在Deployment視圖的圖的類型(lèixíng)有:部署圖。共一百三十四頁用例圖共一百三十四頁順序(shùnxù)圖共一百三十四頁協(xié)作(xiézuò)圖共一百三十四頁活動(huódòng)圖共一百三十四頁類圖共一百三十四頁狀態(tài)圖共一百三十四頁組件(zǔjiàn)圖共一百三十四頁部署(bùshǔ)圖共一百三十四頁很多教科書上的第一個程序就是(jiùshì)Helloworld,一個在屏幕上簡單地打印出“Helloworld!”語句的例子。在java中一個在瀏覽器中顯示“HelloWorld!”的Applet的代碼如下:
importjava.awt.Graphics;classHelloWorldextendsjava.applet.Applet{ publicvoidpaint(Graphicsg){g.drawString("HelloWorld!",10,10); }}實例(shílì)一-HelloWorld共一百三十四頁用例圖HelloWorld共一百三十四頁HelloWorld類HelloWorldPaint()g.drawString("HelloWorld!",10,10)
注釋(zhùshì)共一百三十四頁類圖HelloWorldPaint()AppletGraphics
繼承(jìchéng)使用(shǐyòng)依賴共一百三十四頁順序(shùnxù)圖:Thread:Toolkit:ComponentPeertarget:HelloWorldruncallbackLoophandleExposepaint共一百三十四頁執(zhí)行者讀者(dúzhě)圖書館員管理員用例圖書館管理實例(shílì)二-圖書館系統(tǒng)用例圖共一百三十四頁讀者(dúzhě)用例圖共一百三十四頁圖書館員用例圖共一百三十四頁管理員用例圖共一百三十四頁下載網(wǎng)站(wǎnɡzhàn):/down/soft/100.htmUML技術網(wǎng)站:/別人(biérén)的ROSE建模演示共一百三十四頁軟件開發(fā)環(huán)境中的一些(yīxiē)工具軟件建模工具:1.UML建模工具:ROSE;2.UML2.x建模工具TrufunPlato2008;3.開源(kāiyuán)UML建模工具StarUMLv5.0.24.UML設計測試工具5.數(shù)據(jù)庫建模工具:PowerDesigner共一百三十四頁軟件開發(fā)環(huán)境(huánjìng)中的一些工具軟件測試工具:1.AutoRunner自動化軟件測試工具,是一種黑盒測試工具,對.NET類型的應用軟件進行功能測試,支持標準Windows應用程序測試和.NET應用程序測試。對B/S系統(tǒng)進行功能測試,支持各種B/S應用(yìngyòng)和網(wǎng)站。共一百三十四頁2.WinRunner:Mercury公司,用于功能性測試;
Winrunner最主要的功能是自動重復執(zhí)行某一固定的測試過程,它以腳本的形式記錄下手工測試的一系列操作,在環(huán)境相同的情況下重放,檢查其在相同的環(huán)境中有無異常的現(xiàn)象或與實際結果不符的地方??梢詼p少由于人為因素造成結果錯誤,同時也可以節(jié)省測試人員大量測試時間和精力來做別的事情。功能模塊主要包括:GUImap、檢查點、TSL腳本編程、批量測試、數(shù)據(jù)驅動(qūdònɡ)等幾部分軟件開發(fā)環(huán)境(huánjìng)中測試工具共一百三十四頁3.LoadRunner:Mercury公司,性能與負載壓力;
LoadRunner?是一種預測系統(tǒng)行為和性能的工業(yè)標準級負載測試工具。通過以模擬上千萬用戶實施并發(fā)負載及實時性能監(jiān)測的方式來確認和查找問題,LoadRunner能夠對整個企業(yè)架構進行測試。通過使用LoadRunner,企業(yè)能最大限度地縮短測試時間,優(yōu)化性能和加速應用系統(tǒng)的發(fā)布周期。LoadRunner是一種適用于各種體系架構的自動負載測試工具,它能預測系統(tǒng)行為并優(yōu)化系統(tǒng)性能。LoadRunner的測試對象是整個企業(yè)的系統(tǒng),它通過模擬實際用戶的操作行為和實行實時性能監(jiān)測,來幫助您更快的查找和發(fā)現(xiàn)問題。此外,還能支持廣范的協(xié)議和技術(jìshù),為您的特殊環(huán)境提供特殊的解決方案。軟件開發(fā)環(huán)境(huánjìng)中測試工具共一百三十四頁4.QuickTestPro:Mercury公司,功能測試和回歸測試;
QTP是一個B/S系統(tǒng)的自動化功能測試的利器,軟件程序測試工具。Mercury的自動化功能測試軟件QuickTestProfessional,可以覆蓋絕大多數(shù)的軟件開發(fā)技術,簡單高效,并具備測試用例可重用的特點。MercuryQuickTestPro是一款先進(xiānjìn)的自動化測試解決方案,用于創(chuàng)建功能和回歸測試。它自動捕獲、驗證和重放用戶的交互行為。MercuryQuickTestPro為每一個重要軟件應用和環(huán)境提供功能和回歸測試自動化的行業(yè)最佳解決方案。軟件開發(fā)環(huán)境(huánjìng)中測試工具共一百三十四頁5.TestDirector:Mercury公司,測試管理;基于WEB的測試管理工具,他能夠讓你系統(tǒng)地控制整個測試過程,并創(chuàng)建整個測試工作流的框架和基礎,使整個測試管理過程變得更為簡單(jiǎndān)和有組織。他能夠幫助你維護一個測試工程數(shù)據(jù)庫,并且能夠覆蓋你的應用程序功能性的各個方面。T
溫馨提示
- 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
- 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權益歸上傳用戶所有。
- 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
- 4. 未經(jīng)權益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
- 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
- 6. 下載文件中如有侵權或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
- 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。
最新文檔
- 快樂寒假年切勿忘安全 課件2025-2026學年上學期安全教育系列主題班會之寒假安全
- 養(yǎng)老院員工培訓與考核制度
- 養(yǎng)老院工作人員請假及調(diào)休制度
- 企業(yè)員工培訓與職業(yè)素養(yǎng)提升制度
- 企業(yè)市場調(diào)研與分析制度
- 2026河南建筑職業(yè)技術學院招聘30人參考題庫附答案
- 交通宣傳教育普及制度
- 2026湖北省定向對外經(jīng)濟貿(mào)易大學選調(diào)生招錄參考題庫附答案
- 2026湖南現(xiàn)代環(huán)境科技股份有限公司部分崗位招聘3人考試備考題庫附答案
- 2026福建省面向中央財經(jīng)大學選調(diào)生選拔工作參考題庫附答案
- 《TICW26-202366kV到500kV電纜線路交叉互聯(lián)及接地用電纜》
- 消防噴淋改造協(xié)議書范本
- 《燙金工藝技術要點》課件
- 兩人工地合作協(xié)議書范文范本
- 2024年新人教版四年級數(shù)學上冊《第6單元第7課時 商的變化規(guī)律》教學課件
- 《護理學基礎》-15-標本采集
- HG∕T 3792-2014 交聯(lián)型氟樹脂涂料
- 型鋼斜拋撐支護方案
- 英文繪本故事Brown.Bear.Brown.Bear.What.Do.You.See
- 高一下學期期中語文試題匯編:寫作
- (高清版)JTGT 3371-01-2022 公路沉管隧道設計規(guī)范
評論
0/150
提交評論