（建筑工程管理）軟件工程(B)教案

(建筑工程管理)軟件工程(B)教案軟件工程(B)教案課程說明1壹軟件工程概述(理論3學時)1附錄(壹)常用CASE工具介紹4附錄(二)CASE工具的種類及應用特點10附件(三)軟件、軟件危機、軟件工程16附錄(四)軟件工程的七條基本原理20程說明壹軟件工程概述(理論3學時)開發(fā)的發(fā)展歷史分為三個階段：年代—至今)，工程化的生產(chǎn)危機軟件危機(softwarecrisis)指的是于計算機軟件的開發(fā)和維護過程中所遇到的壹系列嚴重問件危機”(softwarecrisis)這個名詞。包含倆方面問題：壹、如何開發(fā)軟件，以滿足不斷增長，日趨復雜的需具體來說，軟件危機主要有以下表現(xiàn)： 發(fā)成本超出預算，實際進度比預定計劃 面是和軟件本身的特點有關(guān)；另壹方面是由軟件開發(fā)和維護的方法不確方法主要表現(xiàn)為忽視軟件開發(fā)前期的需求分析；開發(fā)過程沒有統(tǒng)壹資料不齊全，忽視人和人的交流；忽視測試階段的工作，提工程的作用工業(yè)界巨頭，討論和制定擺脫“軟件危機”的對策。于那次會議上第壹次提出了軟件工程 (softwareengineering)這個概念。到今年(2008)，軟件工程整整走過了40年的歷程。發(fā)大型的復雜軟件系統(tǒng)過程中遇到的問題。之所以稱為軟件工程，是程化的過程。軟件工程的目標就是找到壹種能指導大型復雜的軟件系使用大量人工、時間，涉及到項目管理、人員管理等，因而有許為了理解軟件工程中涉及的問題，能夠先想象其它的大型復雜設施的構(gòu)建(機械行業(yè)和建筑行業(yè)等)。例如，汽車，辦公大樓，水立方等。自然會想到以下幾個問題，這個項目需要的術(shù)等；如何把項目分割成幾個便于管理的模塊？如何保證模塊間的協(xié)何用系統(tǒng)化、規(guī)范化、數(shù)量化等工程原則和方法去進行軟件的開發(fā)和？工程和傳統(tǒng)工程項目的區(qū)別以復用現(xiàn)有的軟件構(gòu)件，因為軟件往往是個性化的；難以對軟件質(zhì)量進行項目設計系統(tǒng)(輔助經(jīng)費預算、項目調(diào)配以及人員分配等)項目管理系統(tǒng)(輔助健康項目的開發(fā)進度)文檔工具(輔助編寫和組織文檔)原型和仿真系統(tǒng)(輔助開發(fā)原型系統(tǒng))界面設計系統(tǒng)(輔助圖形用戶界面的開發(fā))編程系統(tǒng)(輔助編寫程序和調(diào)試程序)Bug系統(tǒng)(輔助測試)附錄(1)常用CASE工具介紹(壹)圖稿繪制：1，visio:這是目前國內(nèi)用得最多的case工具。它提供了日常使用中的絕大多數(shù)框圖的繪畫功能(包括信息領域的各種原理圖，設計圖)，同時提供了部分信息領域的實物圖。visiovisioword對象繪圖工具的朋友肯定會感受到visio于處理框和文字上的流暢，同時于文件管理上，visio東西，可是功能上visio不減從前，各種器件模版有了許多增進。是對不善于自己構(gòu)造圖的人?？墒钦驗楹苋?，所以某個方面上會造畫網(wǎng)絡拓撲結(jié)構(gòu)圖只要有相應的圖素，用什么畫均行；且且于某個目錄組織。smartdraw也是大手筆，有許多visio沒有的方便功能。比如插入表d(二)原碼瀏覽的工具：1，SourceInsigt:不能不說這個東西是個好東東。以工程的方式管理原碼,提供非常適合再工程的瀏覽手段.整個面板分成三個部分.左邊樹提供工程內(nèi)的所有變量,函數(shù),宏定義,右邊提供程序閱讀和編輯,下邊顯示你鼠標于原碼觸及的函數(shù)或者變量定義.最讓人佩服的是igt比，樣子土多了,處處透著Linux的鄉(xiāng)土氣息，不過是干實事的家伙。提供原碼高亮顯示和含關(guān)系分析，提供類的層次關(guān)系，這個東西最大的特點是把原碼始終供到文件的導航。當然不能說它使用很方便，我壹般不用它，可是它3，Dia：(http:///vpuml.php)目前最合適也是最火的軟件了(從這壹年來網(wǎng)站的設計變化a也是java做的，速度仍是很快的。如果不需要使用逆向工程之類的高級功能的話，強烈推 http:///h/sdm/se_tool/rational/rose/rose98.htm1.引言和設計的方法和理論，遠離糾纏不清的源代碼，達到構(gòu)建和設計變得更直1)通過用例模型，業(yè)務/系統(tǒng)分析能夠捕獲到業(yè)務/系統(tǒng)需求。2)設計者/構(gòu)架師所作的設計模型能于不同層次的同壹層內(nèi)清晰表達對象或子系統(tǒng)之間的交3)開發(fā)者能快速地將模型轉(zhuǎn)變?yōu)橐紓€可運行的應用程序，尋找類和方法的子集，以及理解。F和框架的建模.于加上他的Rational系列,RUP的方法論,是當之無愧的巨無架進行可視化、理解和改進。利用模型驅(qū)動的方法進行軟件候，這個構(gòu)架將軟件的其它部分隔離，避免這些部分受到負面和開發(fā)團隊的其他人員聯(lián)系起來，幫助加速開發(fā)過程。使用RationalRose軟件，數(shù)據(jù)庫設。其功能包括：)支持對象模型、數(shù)據(jù)模型和數(shù)據(jù)存儲模型的創(chuàng)建。輯。4)變換同步選項(于變換期間對數(shù)據(jù)模型和對象模型進行同步)。向?qū)?。的團隊成員獨立開發(fā)、協(xié)作溝通和交付更好的軟件來統(tǒng)壹開發(fā)它的核心則為，它支持本地代碼模型，你所有的類及其關(guān)聯(lián)元素(單元，圖，文檔及事件類元素列表或圖集中進行操作，如果你已有準備，你即可從模型中生成源代碼單元，且可由如代碼注釋選項，代碼次序，方法使用等等)，且且可為多種需求重新生成單元(調(diào)試代碼，自動生成的大量注釋代碼等)。于內(nèi)的應用程序。且把它們導入到源代碼中。能夠使用自帶的HelpFileGenerator生成其使用效果圖如下所示：仍可為數(shù)據(jù)倉庫制作結(jié)構(gòu)模型，也能對團隊設計模型進行控制。它可于企業(yè)級建模上它的功能也很強大。很多公司當下于用三個不同的產(chǎn)品，成問題是比如需求改了，數(shù)據(jù)改了，對哪個類有關(guān)系，跟哪個流程有r2.4EnterpriseArchitect除了開發(fā)類模型之外，仍包括事態(tài)模型，組件和布局，系統(tǒng)管理，非功能需求，用戶界面設其主要特點包括：軟件建模方案。該產(chǎn)品不僅特性豐富，而且性價比極高，能夠用2)特性豐富系統(tǒng)設計ML的軟件。除此，它仍包含特性靈活的高品質(zhì)文檔輸出。用戶指南能夠于3)端到端跟蹤EnterpriseArchitect提供了從需求分析、軟件設計壹直到執(zhí)行和部署整個過程的全面可跟explorerEA仍含有壹個所見即所提供強大的文檔生成和方案工具，能夠生成復雜詳細的方案，方案能。5)EA具備源代碼的前向和反向工程能力，支持多種通用語言，包括進行源代碼的進壹步開發(fā)。代碼生成模板仍允許您對生成的源代碼進持，令您的應用程序可視化，從源代碼、Java.jar文件甚至是.Net二進制匯編語言中獲取利用該工具進行建模的界面如下所示2.5MicrosoftVisualVisio目前國內(nèi)用得最多的case工具之壹。它提供了日常使用中的絕大多數(shù)框圖的繪畫功能(包括信息領域的各種原理圖，設計圖)，同時提供了部分信息領域的實物圖。它是最通用的硬表設計軟件。好處是易用性高，特別是對不善于自己構(gòu)造圖的人。可是正他繪圖工具的朋友肯定會感受到visio于處理框和文字上的流暢，同時于文件管理上，visio工具的集成如下圖所示：非商業(yè)用途,于網(wǎng)站上提供了各組件企業(yè)和專業(yè)版本的KeyFile,附件(3)軟件、軟件危機、軟件工程 于1950年代，軟件伴隨著第壹臺電子計算機的問世誕生了。以寫軟件為職業(yè)的人也開始出本世紀中葉軟件產(chǎn)業(yè)從零開始起步，于短短的50年的時間里迅速發(fā)展成為推動人類社會發(fā)批百萬、億萬富翁。隨著信息產(chǎn)業(yè)的發(fā)展，軟件對人類社會性越人類而言是壹個全新的東西，其發(fā)展歷史不過四、五十年。人們硬件通常用來執(zhí)行壹個單壹的程序，而這個程序又是為壹個特定通用硬件成為平常事情的時候，軟件的通用性卻是很有限的。大多個人或機構(gòu)研制的，軟件往往帶有強烈的個人色彩。早期的軟件開化軟件開發(fā)方式，但軟件的數(shù)量急劇膨脹，軟件需求日趨復雜，維護這樣開始了！些被認為是優(yōu)秀的程序常常很難被別人見懂，通篇充滿了程序技巧。當下的程序除了功能正確，性能優(yōu)良之外，仍應該容易見懂、容易使用、容易的軟件的定義是：e能和性能要求執(zhí)行的指令序列；數(shù)據(jù)是是程序能正常操縱信息軟件同傳統(tǒng)的工業(yè)產(chǎn)品相比，有其獨特的特性：1)軟件是壹種邏輯實體，具有抽象性。這個特點使它和其它工程對象有著明顯的差異。人紙上、內(nèi)存、和磁盤、光盤上，但卻無法見到軟件本身的形態(tài)，必須通過2)軟件沒有明顯的制造過程。壹旦研制開發(fā)成功，就能夠大量拷貝同壹內(nèi)容的副本。所以但會為了適應硬件、環(huán)境以及需求的變化而進行修改，而這些修改有不可避免的引入錯誤，棄。4)軟件對硬件和環(huán)境有著不同程度的依賴性。這導致了軟件移植的問題。5)軟件的開發(fā)至今尚未完全擺脫手工作坊式的開發(fā)方式，生產(chǎn)效率低。6)軟件是復雜的，而且以后會更加復雜。軟件是人類有史以來生產(chǎn)的復雜度最高的工業(yè)產(chǎn)的各行各業(yè)、方方面面，軟件開發(fā)常常涉及其它領域的專門知識，這7)軟件的成本相當昂貴。軟件開發(fā)需要投入大量、高強度的腦力勞動，成本非常高，風險8)軟件工作牽涉到很多社會因素。許多軟件的開發(fā)和運行涉及機構(gòu)、體制和管理方式等問心理。這些人的因素，常常成為軟件開發(fā)的困難所于，直接影件危機”(softwarecrisis)這個名詞。包含倆方面問題：壹、如何開發(fā)軟件，以滿足不斷增長，日趨復雜的需具體地說，軟件危機主要有以下表現(xiàn)： 發(fā)成本超出預算，實際進度比預定計劃 面是和軟件本身的特點有關(guān)；另壹方面是由軟件開發(fā)和維護的方法不壹個簡單介紹。軟件開發(fā)和維護的不正確方法主要表現(xiàn)為忽視軟件開析；開發(fā)過程沒有統(tǒng)壹的、規(guī)范的方法論的指導，文檔資料不齊全，忽視人視測試階段的工作，提交用戶的軟件質(zhì)量差；輕視軟件的維護。這些大多數(shù)工業(yè)界巨頭，討論和制定擺脫“軟件危機”的對策。于那次會議上第壹次提出了軟件工程 ngineering于這30年的發(fā)展中，人們針對軟件危機的表現(xiàn)和原因，經(jīng)過不斷的實踐和總結(jié)，越來越認下面我們給出壹個軟件工程的定義，然后簡單討論壹下軟件工程所包括的內(nèi)容：何用系統(tǒng)化、規(guī)范化、數(shù)量化等工程原則和方法去進行軟件的開發(fā)和軟件開發(fā)項目的失敗，且不是由于軟件開發(fā)技術(shù)方面的原因。它們的理造成的。遺憾的是，盡管人們對軟件項目管理重要性的認識有所提方法學和實現(xiàn)方法學上的進步小，至今仍提不出壹附錄(4)軟件工程的七條基本原理格證明它們是壹個完備的集合，可是能夠證明，于此之前已經(jīng)提下面簡要介紹軟件工程的七條原理：上的失敗項目是由于計劃不周而造護的漫長生命周期中，需要完成許多性質(zhì)各異的工作。這條原理意味期分成若干階段，且相應制定出切實可行的計劃，然后嚴格按照計劃里程碑計劃、項目控制計劃、產(chǎn)品控制計劃、驗證計劃、運行維護計束需求?？墒菍嵺`告訴我們，需求的改動往往是不可避免應這種要求。也就是要采用變動控制，又其它各個階段的文檔或代碼隨之相應變動，以保證軟件的發(fā)技術(shù)，到最近的面向?qū)ο蠹夹g(shù)，從第壹、第二代語言，到分認識到：方法大似氣力。采用先進的技術(shù)即能夠提高軟件開發(fā)的不著的邏輯產(chǎn)品。軟件開發(fā)小組的工作進展情況可見性差，難于評價管理，應根據(jù)軟件開發(fā)的總目標及完成期限，盡量明確地規(guī)定開發(fā)小量和開發(fā)效率的重要因素，應該少而精。這壹條基于倆發(fā)人員的效率比低素質(zhì)開發(fā)人員的效率要高幾倍到幾十倍，開發(fā)工作中犯NNNN好地實現(xiàn)軟件的工程化生產(chǎn)?？墒牵鼈冎皇菍ΜF(xiàn)有的經(jīng)必要性作為軟件工程的第七條原理。根據(jù)這條原理，不僅要積極采納要注意不斷總結(jié)經(jīng)驗，收集進度和消耗等數(shù)據(jù)，進行出錯類型和問題能夠用來評估新的軟件技術(shù)的效果，也能夠用來指明必須著重注意的附錄(5)軟件模型設計基礎(1)年,其數(shù)量從不到十種增加到了五十多種,哎，百家爭鳴。于眾多的建模語言中,語言的創(chuàng)造根據(jù)自身應用特點選擇合適的建模語言。90年代中,種獨立于語言的表示符。這種方法用對象模型、動態(tài)模型、功能模型和用例模型,共同完成發(fā)的分析、設計和實現(xiàn)的全過程,軟件引入了外部角色的概念。用例的概念是精確描述需求的重要武器,但用例貫穿于整個開發(fā)過程,包括對系統(tǒng)的測試和驗證。OOSE比較適合支持商業(yè)工程和需求分析。此外,仍有單、易學,適合于面向?qū)ο蠹夹g(shù)的初學者使用,但由于該方法于處理能力方面的局限,目前已概括起來,首先,面對眾多的建模語言,用戶由于沒有能力區(qū)別不同語言之間的差別,因此很難找到壹種比較適合其應用特點的語言;其次,眾多的建模語言實際上各有千秋;第三,雖然不,極大地妨礙了用戶之間的交流。因此于客總結(jié)面向?qū)ο蠹夹g(shù)應用實踐的基礎上,組的新思想、新方法和新技術(shù)。它的作用域不限于支持面向?qū)ο蟮姆治龊驮O計,仍支持從需求面簡述：附錄(6)增量迭代Refactoring不僅僅是壹種編碼的方法。他同時是壹種設計方法。本文從軟件工程學的演變增量迭代自從有軟件工程壹說開始,大大小小出現(xiàn)了許多方法,其中壹些仍常常被我們掛于嘴邊.這些般來說,WaterFall方法把軟件開發(fā)的過程嚴格地分為幾個階段,包括：應當說，WaterFall模型由它自己的很多優(yōu)點。WaterFall強制每壹階段均必須產(chǎn)生所有的產(chǎn)品通過關(guān)聯(lián)的審核后才能開始下壹階段的工作，而這些產(chǎn)品中相當重要件預算用于維護階段。而WaterFall模型強制每壹階段必須有詳細文檔，所以，見起來壹旦需求方案被用戶承認，你就開始起草Specification文檔，它指出了軟件需要做什么東西。Specification文檔通常很長、很詳細、很直白，因此很容易讓人見著生厭。用戶通常均很難完全見懂軟件的Specification文檔，他幾乎不可能判斷你講得是否正確，但通常他流是否能夠完全使用文檔來實現(xiàn)，即使你能夠使用更加高級的面是他們于《TheTreeofLife》壹書中的答案：是的事情。于接受到外部刺激，被重構(gòu)翻譯成內(nèi)部信號，從而引發(fā)內(nèi)部活動。所沖向出口。他身旁的另壹個日本人，正好于睡覺，因此根本沒有接收沒有轉(zhuǎn)化成內(nèi)部信號。壹個不懂日語的人注意到有個人進來大叫，可接收到任何特別的信息。每壹個人從大叫接收到的東西端依賴于他的中，壹個日本人能夠接受到大量信息而非日本人卻不知所云的重要原因是大喊的人和那個于房間里的日本人有壹個共同的經(jīng)驗：日語。軟件需求獲取者、Specification撰寫者和用戶之間往往不可能有這樣的共同經(jīng)驗。夠達到很好的交流也是不可能的。文檔有助于增進理解，可是它不可能達到完整的理解。Waterfall試圖依賴非常詳細的完美。事實上，對文檔的理解且不依賴于文檔的詳細程度。而是依賴于文。如果我和你之間均具有設計模式的背景，那么我說壹句："使用visitor模式"，可能比倆個能壹趨而就。當然，于壹個軟件公司內(nèi)部，長期的合作可能使，譬如，于進行設計的時候，你說："就像上多的設計信息也能夠完全實現(xiàn)。這種長期的合作關(guān)系是很少見的。因此，除非你對該用戶的領域非常解用戶的壹舉壹動。否則，你不可能壹次就完成設計，你對用戶的理下人和人之間，壹個人需要和所實現(xiàn)的目標進行交流。這就是我們所求階段、標書階段、設計階段或是實現(xiàn)階段，問題的解決要依賴于你。理解越深刻，問題的解決就和完美。而這樣的理解是不可能壹次達。Waterfall的另外壹個問題就是用戶于最終產(chǎn)品交付之前不能見到任何用戶的東西。而用戶對提交產(chǎn)品的見法最后既有可能是："IknowthisiswhatIaskedfor，butitisn'treallywhatIwanted。"通過紙上的文檔理解到的東西遠遠不及真正能夠使用的軟件產(chǎn)品那么多。Waterfall對需求和Specification如此的依賴，直接就可能產(chǎn)生且非用戶為了解決這個問題，我們需要使用增量模型。不同于waterfall和快速原型模型，增量模型不試圖壹次性地發(fā)布完全符合用戶需求的軟件。相反，最終的產(chǎn)品被劃分為幾個build，按照壹個壹個build進行。任何壹個階段，用戶均能夠獲得際可操作的軟件。而不是象前面的模型壹般，需要等待幾個月、壹年適應用戶的變化。變化是每壹個成長中的用戶組織固有的特點，改變的要求同時也是軟件開發(fā)的壹部分。這也是我們說"軟件是軟的"所包含的意義。從客戶的財務觀題，。其中的壹個難點就是每壹個新發(fā)布的build必須能夠平滑地集而不會破壞已經(jīng)存于的東西。從這個角度來講，壹個增量模型下的設計可能需要比Waterfall更加復雜的設計。因為Waterfall壹次性地考慮所有問題，它能夠提前見到設計、實現(xiàn)中的所有問題(于他自己的范圍之內(nèi))，既然問題已經(jīng)全部擺出，你就增量模型則不同，于構(gòu)建當前的build時，你不會去考慮以后的build。所以，以后的build可能需要當前build不可預料的支持，它也可能以不可預料close加build也不會破壞原來的系統(tǒng)。同時，它通過各種面向?qū)ο筇赜械臋C制，多態(tài)和繼承，使得系統(tǒng)能夠以增量的方式平滑地集成。可是，是不可能達到這樣的目標。顯然，你需要壹種方法，能夠于壹個模塊外部行為不變的情況下改變內(nèi)部的結(jié)構(gòu)，使得增量能夠順利地進行下去。Refactoring是增l MessDefinedProcessBlackbox箱的輸入輸出不斷進行度量，于此基礎上，結(jié)合經(jīng)驗判斷對黑箱進行調(diào)控，使其不越出設定的邊界，，使項目組工作于混沌的邊沿，充分發(fā)揮人的創(chuàng)造力。如將經(jīng)驗性過程按確定性過程來處理(如瀑布模型)，必將使過程缺乏適應力。1.計劃和體系結(jié)構(gòu)設計(確定性過程)建立系統(tǒng)體系結(jié)構(gòu)(如為已有系