版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認領(lǐng)
文檔簡介
1、楊教授大學(xué)堂 精心創(chuàng)作的優(yōu)秀程序員 職業(yè)提升必讀系列資料1.1 跟我學(xué)統(tǒng)一建模語言UML應(yīng)用UML實現(xiàn)面向?qū)ο蟮男枨蠓治雠c建模的入門示例1.1.1 面向?qū)ο蟮男枨蠓治雠c建模1、面向?qū)ο蟮慕y(tǒng)一建模(1)什么是建模建模就是建立模型,當然模型可以是多種不同的形態(tài)比如實體、圖形等形式,建模是人類對客觀世界和抽象事物之間聯(lián)系的具體描述。(2)什么是軟件系統(tǒng)建模1) 軟件系統(tǒng)的建模則是通過將用戶的業(yè)務(wù)需求映射為軟件系統(tǒng)項目的最終實現(xiàn)的程序代碼,并保證編程實現(xiàn)的程序代碼能夠滿足用戶的應(yīng)用需求;2) 此外,程序代碼還能方便地回溯軟件系統(tǒng)需求的過程,這個過程稱為軟件系統(tǒng)建模將現(xiàn)實應(yīng)用問題表述成為軟件方面的問題,
2、并最終加以解決的過程。(3)為什么要對軟件系統(tǒng)進行建模建立高樓大廈和建立狗窩的區(qū)別是在建設(shè)狗窩之前不需要進行設(shè)計方面的工作過程,而建立高樓大廈時則必須要在建筑施工之前進行充分的需求分析和詳細的建筑設(shè)計、評估等過程。因此,為了能夠生產(chǎn)出合格的軟件系統(tǒng),也就同樣需要有一套關(guān)于軟件系統(tǒng)的體系結(jié)構(gòu)、實現(xiàn)過程、程序代碼結(jié)構(gòu)和所使用的各種工具、各種規(guī)范的說明和圖示的“說明資料”或者“參考文檔”,而這些“說明資料”或者“參考文檔”則是對軟件系統(tǒng)建模后的成果。1) 通過對軟件系統(tǒng)進行建模可以更好地幫助軟件系統(tǒng)的開發(fā)人員理解正在開發(fā)的軟件系統(tǒng),同時也能夠表達軟件系統(tǒng)的開發(fā)人員所渴望的軟件系統(tǒng)結(jié)構(gòu)和功能行為、業(yè)務(wù)
3、流程、展示和控制軟件系統(tǒng)體系結(jié)構(gòu),最終達到降低軟件系統(tǒng)開發(fā)的風險之目的,保證目標軟件系統(tǒng)能夠按時、按質(zhì)和在計劃的成本內(nèi)順利地完成。2) 通過對軟件系統(tǒng)進行建模還可以實現(xiàn)把復(fù)雜的軟件系統(tǒng)簡單化,因為人類在工程實踐中應(yīng)用模型的主要作用就是使復(fù)雜的問題信息關(guān)聯(lián)能夠簡單易懂。3) 通過對軟件系統(tǒng)進行建模還能夠讓軟件系統(tǒng)的開發(fā)人員容易洞察復(fù)雜堆砌而成的原始數(shù)據(jù)背后所隱藏的規(guī)律,并能有效地使軟件系統(tǒng)的開發(fā)人員能夠更清晰地理解軟件系統(tǒng)的需求。4) 軟件系統(tǒng)的分析和設(shè)計模型能夠幫助軟件系統(tǒng)的開發(fā)人員按照實際情況或按照設(shè)計人員既定的目標對軟件系統(tǒng)進行可視化的設(shè)計和構(gòu)造編程實現(xiàn)。5) 軟件系統(tǒng)的分析和設(shè)計模型同樣
4、也允許軟件系統(tǒng)的開發(fā)人員詳細地說明軟件系統(tǒng)的結(jié)構(gòu)和功能行為。此外,模型還能夠給出一個構(gòu)造軟件系統(tǒng)的模板,從而可以對設(shè)計人員的決策和實現(xiàn)方案進行文檔化。(4)對軟件系統(tǒng)進行建模的核心點1) 明確這個應(yīng)用的數(shù)據(jù)以及對數(shù)據(jù)進行如何的處理;2) 建模的結(jié)果是要產(chǎn)生出相關(guān)的文檔或者說明書。2、傳統(tǒng)的結(jié)構(gòu)化模型設(shè)計方法(1)應(yīng)用傳統(tǒng)的結(jié)構(gòu)化模型的分析及設(shè)計方法(Structured systems analysis and design method,簡稱SSADM)對軟件系統(tǒng)所建立出的模型由于不能反應(yīng)軟件系統(tǒng)實現(xiàn)的源程序代碼,建立模型與程序設(shè)計實現(xiàn)在環(huán)節(jié)上相互脫離,所建立出的模型與實現(xiàn)軟件系統(tǒng)的功能程序
5、代碼之間幾乎沒什么關(guān)系。(2)開發(fā)人員根據(jù)所建立出的軟件系統(tǒng)模型并不能生成對應(yīng)的功能實現(xiàn)的程序代碼;反之,再根據(jù)程序代碼更不能生成對應(yīng)的軟件系統(tǒng)模型。所以不能保證軟件系統(tǒng)的產(chǎn)品質(zhì)量,更不易于軟件系統(tǒng)的后期維護和升級完善,因為軟件模型和軟件實現(xiàn)的程序代碼之間沒有什么關(guān)聯(lián)的約束力。也沒有檢測軟件模型的質(zhì)量高低的相關(guān)標準。 (3)之所以會出現(xiàn)這樣的“鴻溝”,主要的原因是由于傳統(tǒng)的軟件開發(fā)是從算法的角度進行軟件系統(tǒng)的建模。3、基于面向?qū)ο蟮腢ML軟件系統(tǒng)建模 面向?qū)ο蟮能浖到y(tǒng)建模方法是把軟件系統(tǒng)看作是相互協(xié)作的對象集,而這些對象是對結(jié)構(gòu)和行為的封裝,屬于某個特定的類;而這些類具有某種層次化的結(jié)構(gòu)關(guān)系
6、,軟件系統(tǒng)的所有功能是通過這些對象之間相互發(fā)送消息從而實現(xiàn)功能交互而獲得相關(guān)的功能。由于面向?qū)ο笾С殖橄蟆⒎庋b和繼承等機制,從而使得應(yīng)用面向?qū)ο蠓椒ㄋ鶎崿F(xiàn)的軟件系統(tǒng)建模結(jié)果可以實現(xiàn)模塊化、層次分類、可重用和可擴展。4、基于面向?qū)ο蟮腢ML建模類型(1)軟件系統(tǒng)的靜態(tài)建模靜態(tài)建模機制包括用例圖(Use Case Diagram)、類圖(Class Diagram)、對象圖(Object Diagram)、包(Package)、組件圖(Component Diagram)和配置圖(Deployment Diagram)。(2)軟件系統(tǒng)的動態(tài)建模動態(tài)建模機制包括狀態(tài)圖(State Diagram)、
7、時序圖(Sequence Diagram)、協(xié)作圖(Collaboration Diagram)和活動圖(Activity Diagram)。5、何時需要對軟件系統(tǒng)進行建模盡管在軟件應(yīng)用系統(tǒng)開發(fā)的任何階段開展對應(yīng)的建模工作都是有意義的,但無可否認的是,在軟件系統(tǒng)的設(shè)計最初階段,軟件系統(tǒng)的開發(fā)人員應(yīng)將精力主要用于處理有關(guān)軟件應(yīng)用系統(tǒng)的用途、為實現(xiàn)軟件系統(tǒng)的既定功能應(yīng)決定要采用何種的編程環(huán)境,而不是考慮實現(xiàn)程序的細節(jié)(如在屏幕上的什么位置放置按鈕等)方面的問題先設(shè)計、后實現(xiàn)。在軟件系統(tǒng)項目開發(fā)的中期階段,對待開發(fā)的軟件系統(tǒng)引入建模相關(guān)的工作,也是非常有意義的。支持UML的Ratioal Rose分
8、析、設(shè)計工具既支持正向建模(根據(jù)模型導(dǎo)出對應(yīng)的程序代碼),同時也支持反向建模(根據(jù)程序代碼反推測出對應(yīng)的設(shè)計模型)。Ratioal Rose工具幫助軟件系統(tǒng)的開發(fā)人員通過建立出相關(guān)的模型,從而使得開發(fā)人員能夠更好地把握軟件系統(tǒng)實現(xiàn)程序開發(fā)的方向,準確完成在軟件系統(tǒng)需求分析階段中所要求的各項任務(wù)(功能性和非功能性需求)。1.1.2 軟件系統(tǒng)需求分析1、什么是軟件系統(tǒng)需求分析(1)軟件系統(tǒng)需求分析是一個翻譯軟件系統(tǒng)的需求(功能性和非功能性)和深入理解問題的過程(2)軟件系統(tǒng)需求分析的目標是要理解相關(guān)的問題并開發(fā)出一個簡要描述方案的可視化模型,不考慮軟件系統(tǒng)最終具體的實施技術(shù)環(huán)境,即解決軟件系統(tǒng)“要
9、做什么”的問題。2、軟件系統(tǒng)需求分析工作的重點(1)主要是將用戶的業(yè)務(wù)功能性的需求翻譯為軟件工程中的相關(guān)概念,或者用軟件工程相關(guān)的概念來詮譯問題所要求的功能;(2)工作的核心是捕獲問題的行為,在屏蔽實施細節(jié)的基礎(chǔ)上得到構(gòu)成方案的粗略對象模型。3、軟件系統(tǒng)需求分析工作的重要性(1)通過對用戶的需求(功能性和非功能性)進行分析,可以產(chǎn)生出能體現(xiàn)整個軟件系統(tǒng)靈魂的文檔,并且能夠?qū)⒖蛻舻男枨髲木唧w到抽象的一個過程(2)最終產(chǎn)生并能夠制定出編碼人員可實施的軟件系統(tǒng)規(guī)范和標準。4、軟件系統(tǒng)需求分析工作的要點開發(fā)的軟件系統(tǒng)項目應(yīng)該是以客戶的需求為中心,而不應(yīng)該為實現(xiàn)的技術(shù)而遷就或者改變軟件系統(tǒng)既定的需求,特
10、別是非功能性需求。5、軟件系統(tǒng)需求分析階段的工作主要分為業(yè)務(wù)需求和應(yīng)用軟件系統(tǒng)功能需求兩部分(1)分析業(yè)務(wù)需求(以網(wǎng)上銀行為例加以說明)業(yè)務(wù)需求描述的是企業(yè)愿景級的需求比如,對于網(wǎng)上銀行系統(tǒng)業(yè)務(wù),從大的方面來說是基本相同的。作為網(wǎng)上銀行系統(tǒng),為了保證核心平臺的通用性和實用性,在需求分析階段首先全面剖析了銀行系統(tǒng)業(yè)務(wù)過程,從業(yè)務(wù)操作的角度分析每個過程的輸入、輸出和處理細節(jié)。其次,面向業(yè)務(wù)處理過程,提取規(guī)范的業(yè)務(wù)流程建議;面向業(yè)務(wù)處理辦法,研究最新金融政策文件并結(jié)合各地的實際情況,提取業(yè)務(wù)處理過程的每個算法、參數(shù)等等。最后,將所有問題整理出來,向用戶相關(guān)部門進行咨詢和確認,然后再加工整理,形成網(wǎng)上
11、銀行系統(tǒng)業(yè)務(wù)需求分析報告。(2)分析軟件系統(tǒng)功能需求(以網(wǎng)上銀行為例加以說明)對于網(wǎng)上銀行系統(tǒng)平臺應(yīng)用軟件功能需求的分析,本著提高工作效率和方便用戶使用的原則提取應(yīng)用軟件的功能。網(wǎng)上銀行系統(tǒng)的功能劃分充分考慮到了銀行經(jīng)辦機構(gòu)現(xiàn)行的管理體制、機構(gòu)設(shè)置、操作人員配備、系統(tǒng)管理人員素質(zhì)等方面的因素,并對其未來可能的發(fā)展變化進行了研究。對網(wǎng)上銀行系統(tǒng)的需求分析階段除了要總結(jié)和吸收軟件系統(tǒng)開發(fā)企業(yè)以前遇到的問題和相關(guān)經(jīng)驗之外,還要參考國家和地方的最新金融政策文件、業(yè)務(wù)說明書籍等資料。(3)該階段的輸入和輸出(以網(wǎng)上銀行為例加以說明)軟件系統(tǒng)需求分析階段輸入的規(guī)范指導(dǎo)文件包括銀行金融業(yè)務(wù)流程規(guī)范。最后輸出
12、的結(jié)果有網(wǎng)上銀行系統(tǒng)業(yè)務(wù)流程分析、網(wǎng)上銀行系統(tǒng)需求分析報告、需求分析階段風險分析報告、需求分析軟件問題報告、需求分析階段總結(jié)報告等相關(guān)的說明書。1.1.3 利用統(tǒng)一建模語言UML進行軟件系統(tǒng)的建模1、利用UML實現(xiàn)系統(tǒng)分析和設(shè)計的基本過程(1)3個基本過程從應(yīng)用的角度來看,當采用面向?qū)ο蠓椒ā⑾嚓P(guān)技術(shù)和實現(xiàn)工具設(shè)計軟件系統(tǒng)時,首先是描述軟件系統(tǒng)的需求從而獲得軟件系統(tǒng)的主要功能;其次是根據(jù)需求建立出軟件系統(tǒng)的靜態(tài)模型,以構(gòu)造軟件系統(tǒng)的結(jié)構(gòu);最后則是描述軟件系統(tǒng)的動態(tài)行為,從而獲得軟件系統(tǒng)中的各個對象之間的交互關(guān)系。(2)靜態(tài)建模機制其中在第1步和第2步中所建立的模型都是靜態(tài)的,包括用例圖、類圖、
13、包圖、對象圖、組件圖和配置圖等5個UML的圖形。所有這些圖形都是依據(jù)標準建模語言UML的靜態(tài)建模機制而產(chǎn)生的結(jié)果。(3)動態(tài)建模機制其中第3步中所建立的UML模型或者可以執(zhí)行、或者表示執(zhí)行時的時序狀態(tài)或交互關(guān)系,它包括狀態(tài)圖、活動圖、時序圖和合作圖等4個UML圖形,所有這些圖形都是依據(jù)標準建模語言UML的動態(tài)建模機制而產(chǎn)生的結(jié)果。因此,標準建模語言UML主要可以歸納為靜態(tài)建模機制和動態(tài)建模機制兩個方面;它是一個通用的標準建模語言,可以對任何具有靜態(tài)結(jié)構(gòu)和動態(tài)行為的系統(tǒng)(不只限于軟件系統(tǒng))進行建模。2、UML適用于系統(tǒng)開發(fā)過程中從需求規(guī)格描述到系統(tǒng)完成后測試的不同階段。(1)在需求分析階段在此階
14、段的主要任務(wù)是:建立用戶需求和功能模塊,確定軟件系統(tǒng)中的參與者和用例;同時可以用用例來捕獲用戶的功能性需求。1) 通過用例建模,描述對軟件系統(tǒng)感興趣的外部角色及其對軟件系統(tǒng)(用例)的功能要求;2) 通過用時序圖可以實現(xiàn)按時間的先后順序,從上到下分析軟件系統(tǒng)中的用例,確定用例的處理流程;3) 通過協(xié)作圖可以確定對象之間的關(guān)系及處理過程的分析流程。(2)分析階段主要關(guān)心問題域中的主要概念(如抽象、類和對象等)和機制,軟件系統(tǒng)開發(fā)人員需要識別這些類以及它們相互間的關(guān)系,并用UML的類圖進行描述。為實現(xiàn)用例,各個類之間需要協(xié)作,而這可以用UML的動態(tài)模型中的協(xié)作圖來描述。(3)在設(shè)計階段只對問題域的對
15、象(現(xiàn)實世界的概念)建模,而不考慮定義軟件系統(tǒng)中技術(shù)實現(xiàn)細節(jié)的類(如處理用戶接口、數(shù)據(jù)庫、通訊和并行性等問題的類),這些技術(shù)細節(jié)將在設(shè)計階段引入。因此,設(shè)計階段為軟件系統(tǒng)的構(gòu)造實現(xiàn)階段提供更詳細的規(guī)格說明。(4)編程(構(gòu)造)是一個獨立的階段其任務(wù)是用面向?qū)ο缶幊陶Z言(目前極大部分編程語言都屬于面向?qū)ο缶幊陶Z言)將來自設(shè)計階段的類轉(zhuǎn)換成實際的程序代碼。在用UML建立分析和設(shè)計模型時,應(yīng)盡量避免考慮把模型轉(zhuǎn)換成某種特定的編程語言。因為在早期階段,所建立出的模型僅僅是理解和分析軟件系統(tǒng)結(jié)構(gòu)的工具,如果過早地考慮編碼的實現(xiàn)細節(jié)問題十分不利于建立簡單正確的模型。此階段所需要應(yīng)用的UML的圖如下:1)類圖
16、-顯示系統(tǒng)中類與類之間的交互2)組件框圖:表示系統(tǒng)中的組件及相互依賴性(5)UML模型還可作為測試階段的依據(jù)高質(zhì)量的軟件系統(tǒng)通常需要經(jīng)過單元測試、集成測試、系統(tǒng)測試和驗收測試等不同的測試驗證環(huán)節(jié),不同的測試小組使用不同類型的UML圖作為自身測試的依據(jù);1) 單元測試使用類圖和類規(guī)格說明;2) 集成測試使用部件圖和協(xié)作圖;3) 軟件系統(tǒng)測試使用用例圖來驗證軟件系統(tǒng)的功能行為;4) 驗收測試由用戶進行,以驗證軟件系統(tǒng)測試的結(jié)果是否滿足在軟件系統(tǒng)需求分析階段確定的既定需求。所用到的UML圖為部署圖顯示網(wǎng)絡(luò)中的物理布局和各種組件的位置。3、軟件系統(tǒng)設(shè)計階段的主要任務(wù)和相關(guān)的UML圖(1)概要設(shè)計階段1
17、)主要的任務(wù)軟件系統(tǒng)的設(shè)計人員通過分析所建立出的用例圖,得到相關(guān)的類;然后再分析這些類的屬性、操作(方法)和它們之間的關(guān)系,從而為后續(xù)的類圖設(shè)計提供基礎(chǔ)信息。2)所用到的UML圖l 類圖-顯示軟件系統(tǒng)中類與類之間的關(guān)系、單個程序類的結(jié)構(gòu)等方面的信息;l 包圖-具有一些共性的類(也還包括接口)組合在一起的圖,體現(xiàn)了軟件系統(tǒng)的模塊組成。(2)詳細設(shè)計階段1)主要的任務(wù)細化軟件系統(tǒng)用例圖中的各個用例之間的關(guān)系,單個用例的實現(xiàn)流程及業(yè)務(wù)流,從而確定出各個類之間的交互信息、流程關(guān)系及狀態(tài)切換。2)所用到的UML的圖l 類圖-顯示軟件系統(tǒng)中類與類之間的關(guān)系;l 活動圖顯示軟件系統(tǒng)中類與類之間的交互關(guān)系;l
18、 時序圖顯示軟件系統(tǒng)中某個用例的業(yè)務(wù)實現(xiàn)過程;l 狀態(tài)圖-顯示一個對象從生成到刪除的生命周期。4、理解統(tǒng)一建模中“統(tǒng)一”的含義(1)軟件系統(tǒng)開發(fā)的整個生命周期(包括業(yè)務(wù)建模、用例建模、應(yīng)用建模、數(shù)據(jù)建模)都可以用可視化建模技術(shù)統(tǒng)一起來。(2)在傳統(tǒng)的軟件系統(tǒng)開發(fā)技術(shù)中,這些階段是由不同的技術(shù)完成的,如軟件系統(tǒng)的業(yè)務(wù)模型是由IDEF(ICAM DEFinition method的縮寫, 是美國空軍在70年代末80年代初在結(jié)構(gòu)化分析和設(shè)計方法基礎(chǔ)上發(fā)展的一套軟件系統(tǒng)分析和設(shè)計方法)相關(guān)的語言來描述,而軟件系統(tǒng)的分析設(shè)計模型則由數(shù)據(jù)流圖來表示,軟件系統(tǒng)所應(yīng)用的數(shù)據(jù)庫表結(jié)構(gòu)和數(shù)據(jù)庫表之間的關(guān)系是用ER
19、(對象關(guān)系圖) 來定義等等。這無形中增加了軟件系統(tǒng)開發(fā)人員的學(xué)習負擔和提高了開發(fā)成本。(3)在可視化建模技術(shù)中,軟件系統(tǒng)所有的這些開發(fā)活動及相關(guān)的工作都可以由同一種語言(即UML)來描述和定義,這樣可以大大增強開發(fā)團隊中人員的溝通,提高開發(fā)效率和軟件系統(tǒng)最終的質(zhì)量。5、如何利用UML進行軟件系統(tǒng)的需求分析及建模(1)為什么要建模1)必須對軟件系統(tǒng)進行簡化和抽象目前的企業(yè)級的軟件系統(tǒng)也是一種非常復(fù)雜的系統(tǒng),它的最終表現(xiàn)形式為可運行的目標代碼。但是最終的軟件代碼一般是非常復(fù)雜的,會包含太多的細節(jié)信息和應(yīng)用了復(fù)雜的實現(xiàn)技術(shù),直接閱讀程序代碼很難對軟件系統(tǒng)有一個全面的了解和把控。因此,軟件系統(tǒng)的開發(fā)人
20、員需要有一個中間過程來得到這些結(jié)果,同時也需要對軟件系統(tǒng)進行簡化和抽象關(guān)注核心問題,也就有必要進行軟件系統(tǒng)的設(shè)計過程。2)通過構(gòu)建軟件系統(tǒng)模型以對軟件系統(tǒng)進行全面的分析和設(shè)計利用統(tǒng)一建模語言UML 來對軟件系統(tǒng)結(jié)構(gòu)進行全面的分析、理解和設(shè)計,也就是構(gòu)建軟件系統(tǒng)模型的過程,這就是所謂的可視化建模(Visual Modeling)。目前,在軟件工程領(lǐng)域,可視化建模技術(shù)已經(jīng)成為一種成熟并且標準的軟件系統(tǒng)開發(fā)技術(shù)規(guī)范。(2)什么是模型1)模型是對現(xiàn)實世界的簡化和抽象現(xiàn)實世界中的系統(tǒng)是紛繁復(fù)雜的,人們直接去認識現(xiàn)實世界并且解決其中的問題是非常困難的,而且也不利于溝通和傳播。所以人們往往會構(gòu)造一個模型來對
21、現(xiàn)實世界中的復(fù)雜系統(tǒng)進行簡化和抽象。通過這種簡化和抽象來幫助相關(guān)的設(shè)計人員加深對于系統(tǒng)的認知和理解,在進行簡化和抽象時,重點關(guān)注或者抓住的內(nèi)容應(yīng)該是問題的本質(zhì),而過濾掉很多其他非本質(zhì)的因素,從而幫助設(shè)計人員簡化問題的復(fù)雜性,有利于問題的解決。2)各行各業(yè)都使用模型來輔助設(shè)計模型在現(xiàn)實世界中大量存在,無論是研制飛機還是制造汽車,設(shè)計師們都會利用模型來研究目標課題的某一個側(cè)面或者某一方面,如汽車的風阻系數(shù)、飛機機身的空氣動力布局等等。在研發(fā)過程的大部分階段中,設(shè)計師都不會去構(gòu)造一個真實的系統(tǒng)來進行研究,因為構(gòu)造一個真實的系統(tǒng)的成本太高了(或甚至是不可能的),同時問題本身沒有得到足夠的簡化,很難找到
22、對問題的正確答案或者解決方法。3)模型是溝通的手段人們平時所見的各種工程模型有的是一種概念上的模型,如數(shù)學(xué)模型;有的是對實際系統(tǒng)外觀的一個縮小,如輪船、飛機模型和建筑模型等;還有的是對設(shè)計思想的一種展示,如建筑物的設(shè)計圖紙、機械設(shè)計圖等等。無論是哪一種模型,它的另外一個主要目的都是幫助人們進行思想上的溝通和技術(shù)上的交流。應(yīng)用數(shù)學(xué)模型能夠使別人了解你的邏輯思路,飛機等實體模型能夠向觀眾展示飛機的外觀,設(shè)計圖紙將設(shè)計師的設(shè)計思想傳遞給生產(chǎn)制造工人。4)模型可以精確地描述系統(tǒng)語言和文字是人們進行溝通的主要手段,但語言和文字往往有二義性存在,較難保證人們的理解完全一致,而且不同國家或者民族有自己不同的
23、語言,不容易溝通交流。所以在工程技術(shù)中,各行各業(yè)更多地是使用各種各樣的模型來進行思想和技術(shù)等方面的溝通,模型可以精確地描述系統(tǒng),同時能夠保證在整個系統(tǒng)開發(fā)的過程中的語義一致性。6、可視化建模技術(shù)的主要優(yōu)點(1)能夠有效地管理系統(tǒng)的復(fù)雜度模型通過過濾掉非本質(zhì)的細節(jié)信息,成為描述復(fù)雜的問題或結(jié)構(gòu)的本質(zhì)的抽象(abstraction),從而可以使得問題更容易被理解。因為在對象模型中。軟件系統(tǒng)的開發(fā)人員只需要描述對象所實現(xiàn)的功能,而封裝了操作實現(xiàn)的細節(jié)。與軟件代碼相比,對象模型描述的也是同一個系統(tǒng),但它展示的是軟件系統(tǒng)結(jié)構(gòu)中最關(guān)鍵的元素以及它們之間的關(guān)系,所有的編碼細節(jié)都已經(jīng)被忽略掉了,從而有利于開發(fā)人員把握理解整個軟件系統(tǒng)。(2)增強團隊的溝通對象模型同時也作為軟件系統(tǒng)設(shè)計的藍圖,記錄了軟件系統(tǒng)開發(fā)人員的設(shè)計思想。對于軟件系統(tǒng)的設(shè)計者而言,對象模型提供了一個工具以幫助開發(fā)人員整理設(shè)計思路,整個設(shè)計過程都可以被記錄下來并保存到相關(guān)的設(shè)計文檔中;同時,也可以避免開發(fā)者在整個軟件系統(tǒng)的架構(gòu)明確之前就陷入編碼的實現(xiàn)細節(jié)之中,因為開發(fā)人員對于模型的調(diào)整修改相對于程序代碼的修改要簡單得多,有利于提高軟件系統(tǒng)的開發(fā)效率。另一方面,對象模型也使得設(shè)計的結(jié)果很容易被其他人所理解,設(shè)計者的設(shè)計意圖可以被完整的傳遞而不發(fā)生信息的失真??梢暬2捎玫氖菢藴实慕y(tǒng)一建模語言UML,所有的開發(fā)人員都應(yīng)該采用
溫馨提示
- 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
- 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
- 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
- 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
- 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
- 6. 下載文件中如有侵權(quán)或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
- 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。
最新文檔
- 2025年度物聯(lián)網(wǎng)解決方案代理授權(quán)銷售合同范本4篇
- 2024銅門制安工程招投標合同
- 2025年度校園文化節(jié)影視展贊助合同3篇
- 2025年歷史建筑圍墻修繕施工合同4篇
- 2025年度廚房設(shè)備翻新與性能提升合同3篇
- 2025年度智能大廈腳手架設(shè)計與施工一體化合同4篇
- 2025年cfg樁基施工綠色施工技術(shù)交流與合作合同3篇
- 2024銷售委托合同范本
- 2025年度出租車駕駛員權(quán)益保障合同3篇
- 2025年度新型冷鏈物流承包運輸合同4篇
- 非誠不找小品臺詞
- 2024年3月江蘇省考公務(wù)員面試題(B類)及參考答案
- 患者信息保密法律法規(guī)解讀
- 老年人護理風險防控PPT
- 充電樁采購安裝投標方案(技術(shù)方案)
- 醫(yī)院科室考勤表
- 鍍膜員工述職報告
- 春節(jié)期間化工企業(yè)安全生產(chǎn)注意安全生產(chǎn)
- 保險行業(yè)加強清廉文化建設(shè)
- Hive數(shù)據(jù)倉庫技術(shù)與應(yīng)用
- 數(shù)字的秘密生活:最有趣的50個數(shù)學(xué)故事
評論
0/150
提交評論