第一篇：軟件工程試驗心得

心得體會

學了一個學期的軟件工程課，終于知道了個軟件工程的大概。學的時候總覺得很抽象，理解起來好像不難，但總是摸不著頭腦一種很茫然的感覺。學習的過程中和一個宿舍的同學一起做了個小型管理系統的開發，覺得還是有點收獲的，對于開設這門課的意義也有所領悟，現在就將我對這門課的體會以及在項目開發過程中遇到的一些問題簡單的歸納一下。希望在以后的學習中不斷的提高吧。

曾經以為程序就是軟件，軟件就是程序?，F在知道了二者的不同之處，這是學習這門課程第一個收獲。事實上在軟件開發的早期階段這也不能說是錯誤的。那個時候開發的軟件都比較簡單。當然可以把軟件理解成程序，直到軟件作坊的出現，使軟件在程序的基礎上加了個說明。以前做過的一些小型的軟件比如加密軟件，也只是在程序旁邊附上一個軟件的說明，看來已經很接近作坊了。不過大的項目沒有接觸過，用軟件工程的方法還是第一次。我想也是程序的不斷復雜化導致了軟件危機的發生，使得人們不得不探索新的解決方法。這個時候軟件工程應運而生了。

掌握軟件工程化的思想，對于負責軟件開發的管理人員（領導）更為重要。曾經看到過這么一句話，“坐在指揮臺上，如果什么也看不見，就不能叫領導。軟件工程將有能力的人團結在一起，然后把他們變成工人，因為工業化的生產是效率最高的。這就是根本所在。沒有軟件工程管理，簡直就是亂來，就好象缺乏宏觀控制的國家一樣，會亂七八糟。

軟件除了程序還要有使用和維護該程序所需要的全部文檔。包括需求文檔、設計文檔、測試文檔、維護文檔以及使用手冊。

軟件開發特別是大型軟件是一項浩大的工程,需要幾個人、十幾個人、幾十個人甚至幾百個人合作開發幾個月、十幾個月甚至幾年。要保證系統的協調性、統一性和連續性,就需要在開發之前制定嚴格、詳細的開發規范。開發規范的制定需要花費一定的時間和精力,但是“磨刀不誤砍柴功”,它相當于把今后開發過程中開發人員都要遇到的問題提前做了一個考慮。有了開發規范,在后續的開發過程中,設計人員就不必每次考慮如何為一個字段命名,編程人員也不必去想某個程序的結構和布局應當 怎樣,測試人員也有了判斷程序對錯的標準。它約束開發人員的行為和設計、編程風格,使不同子系統和模塊的設計、編程人員達成默契,以便形成整個系統的和諧步調和統一風格,也便于今后的系統維護和擴展工作。

第二篇：軟件工程試驗論文

班級：09級計算機本科班姓名：白路明學號：091220141046

軟件工程開發工具case的學習心得

摘要：文章主要前線介紹了什么是計算機輔助軟件工程CASE以及它的分類方式和主流的幾種CASE工具的特點。

關鍵字：（1）CASE的基本定義及作用

（2）CASE工具的標準及種類

（3）主流CASE工具的各自特點

參考文獻：竇萬峰軟件工程試驗教程

徐培炎 PowerDesigner特點、優勢[EB/OL].賽迪網

2006.10

Wendy Boggs, Michael BoggsUML與Rational Rose 2002入門與精通[M].電子工業出版社.2002

徐鋒.實戰OO：為問題域建模.程序員.2004.2

王文玲，金茂忠.UML模型與其應用.計算機工程與應用.1999

Doug Rosenberg, Kendall Scott.UML用例驅動對象建模.北京：清華大學出版社.200

3軟件工程是將計算機科學理論與現代工程方法相結合，著重研究軟件過程模型、設計方法、工程開發技術和工具，指導軟件生產和管理的一門新興的、綜合的應用科學。隨著計算機科學和軟件產業的迅猛發展，軟件工程學已成為一個重要的計算機分支學科，一個異常活躍的研究領域，正在不斷涌現新方法、新技術，蓬蓬勃勃的發展著。軟件工程是計算機專業和軟件工程專業學生必修的一門專業課程，也是工科各專業學生在計算機應用方面的一門重要選修課程。隨著軟件工程理論與技術的發展和多種多樣的輔助軟件開發的case（計算機輔助軟件

工程）工具不斷涌現，既提高了軟件開發效率，同時還大大的節約了開發成本，并且對從事軟件及相關行業的人才和大學生提出了新的更高的要求。

一、CASE的基本定義及作用

計算機輔助軟件工程CASE是通過一組集成化的工具，輔助軟件開發者實現各項活動的全部自動化，是軟件產品在整個生存周期中，開發和維護生產率得到提高，質量的保證。CASE環境、case工具、集成化CASE（I-CASE）等，實際是一切現代化軟件開發環境（SEE）的代名詞。CASE(Computer Aided Software Engineer計算機輔助軟件工程)“用自動化手段對結構化概念和設計方法重新進行組裝”。CASE的實質是為軟件開發人員提供一組優化集成的且能大量節省人力的軟件開發工具，以實現軟件生存期各個環節的自動化并使之成為一個整體。CASE是一套方法和工具，可使用系統開發商規定的應用規則，并由計算機自動生成合適的計算機程序。CASE工具分成“高級”CASE和“低級”CASE.高級CASE工具用來繪制企業模型以及規定應用要求，低級CASE工具用來生成實際的程序代碼。CASE工具和技術可提高系統分析和程序員工作效率。其重要的技術包括應用生成程序、前端開發過程面向圖形的自動化、配置和管理及壽命周期分析工具。

CASE的作用有通過自動檢查提高軟件的質量；使原型的建立成為可行；簡化程序的維護工作；加快軟件的開發過程；鼓勵進化式和遞增式的軟件開發，使軟件部件可重復使用。CASE的基本功能有提供一種機制，是環境中所有工具可以共享軟件工程信息；每一個信息項的改變，可以追蹤到其他相關信息項；對所有軟件工程信息提供版本控制和配置管理；對環境中任何工具，可以進行直接的、非順序的訪問；在標準的分解結構中提供工具和數據的自動支持；是每個工具的用戶，共享人機界面的所有功能；收集能夠改善過程和產品的各項度量指標；支持軟件工程師們之間的通信。

二、CASE工具的標準及種類

CASE 工具分類的標準可分為三種：功能，功能是對軟件進行分類的最常用的標準；支持的過程，根據支持的過程，工具可分為設計工具、編程工具、維護工具等；支持的范圍，根據支持的范圍，可分為窄支持、較寬支持和一般支持工

具。窄支持指支持過程中特定的任務，較寬支持是指支持特定過程階段；一般支持是指支持覆蓋軟件過程的全部階段或大多數階段。1993 年，Fuggetta 根據 CASE 系統對軟件過程的支持范圍，提出 CASE 系統可分為三類：支持單個過程任務的工具。工具可能是通用的，或者也可能歸組到工作臺；工作臺支持某一過程所有活動或某些活動。它們一般以或多或少的集成度組成工具集；環境支持軟件過程所有活動或至少大部分。它們一般包括幾個不同的工作臺，將這些工作臺以某種方式集成起來。

CASE 方法與其他方法相比有如下幾方面的應用特點：解決了從客觀世界對象到軟件系統的直接映射問題，強有力地支持軟件、信息系統開發的全過程；使結構化方法更加實用；自動檢測的方法提高了軟件的質量；使原型化方法和 00 方法付諸于實施；簡化了軟件的管理和維護；加速了系統的開發過程；使開發者從大量的分析設計圖表和程序編寫工作中解放出來；使軟件的各部分能重復使用； 產生出統一的標準化的系統文檔。

CASE 工具種類繁多，適應了不同方面的要求，隨著技術的發展，還有不但推陳出新的趨勢。給軟件人員提供了更多的選擇余地。例如： Enterprise Architect、Poseidon、ArgoUML、ModeIMaker、Gaphor、Visio、object Domain、UMLStudio、Visual Paradigm for UML、Rational Rose、Umbrello TOgether、Low-tech、Jude、ARIS、MagicDraw、CodeLogic、omondo、Micro Gold omnigraffle(Mac OSX only）、Embarcadero Technologies 等等。主流的CASE工具有Visio、Smartdraw、SourceInsigt、Telelogic、ModelMaker、ArgoUML、Rose、vss、cvs、Project、PowerDesigner、WinRunner、LoadRunner、Eclipse。

三、主流CASE工具的各自特點

Rational Rose

目前市面上最流行的UML Case工具,繪制的圖形簡潔美觀它支持Java,J2EE,C++,MCF等語言和框架的建模.在加上他的Rational系列,RUP的方法論,是當之無愧的巨無霸.IBM Rational Rose 是一個完整的可視建模方案，開

發人員、項目經理、工程師和分析人員可以在提交編碼之前對需求和構架進行可視化、理解和改進。利用模型驅動的方法進行軟件開發，可以保證系統的可擴展性、靈活性和可靠性，使您更快更好地創建軟件。其功能包括： 支持對象模型、數據模型和數據存儲模型的創建。映射邏輯和物理模型，從而靈活地將數據庫設計演變為應用程序邏輯。支持數據模型、對象模型和已定義數據語言（DDL）文件／數據庫管理系統（DBMS）之間的雙向工程。變換同步選項（在變換期間對數據模型和對象模型進行同步）。數據模型-對象模型比較向導。支持一次性對整個數據庫進行正向工程。集成了其他 IBM Rational Software Development 生命周期工具。能集成任何兼容 SCC 的版本控制系統，包括 IBM Rational ClearCase 軟件。能夠以 Web 頁面的方式發布模型和報告，以此來提高整個團隊的溝通效率。其最突出特點就是通過使所有的團隊成員獨立開發、協作溝通和交付更好的軟件來統一開發團隊，建立穩定、有彈性、基于構件的系統構架，以可控、可管理、可確認的方式進行開發，從而降低成本，加快面市的速度。一個無縫集成所有領先的 IDE 與最新技術的工具可滿足您的所有技術需要，最大化開發工作的速度和簡便性。

ModelMaker

一個非常強大的軟件工具，其功能與所有強大且具有多面性的產品一樣。但ModelMaker的復雜性卻會讓一個新手望而卻步。

ModelMaker常被認為是一個UML圖形工具或是Delphi Case工具,然而，它比一般的圖形工具和Case工具要快得多，有時，它可為你寫一些人工智能式的代碼。它是可擴展的，支持UML圖，設計模式，逆向生成與分解的雙向代碼管理工具等。

它的核心則為，它支持本地代碼模型，你所有的類及其關聯元素（單元，圖，文檔及事件類型等等）都是模型內部的對象。ModelMaker為活動模型提供了多種視圖，允許你在類列表，元素列表或圖集中進行操作，如果你已有準備，你即可從模型中生成源代碼單元，并可由Delphi來進行編譯，以后生成的單元每次也可重新生成。你可對各種不同的設置進行修改(例如代碼注釋選項，代碼次序，方法使用等等)，并且可為多種需求重新生成單元(調試代碼，自動生成的大量注釋代碼等)。

Enterprise Architect

以目標為導向的軟件系統。它覆蓋了系統開發的整個周期，除了開發類模 型之外，還包括事務進程分析，使用案例需求，動態模型，組件和布局，系統管理，非功能需求，用戶界面設計，測試和維護等。其主要特點包括：為整個團隊提供高級的UML 2.0建模工具；特性豐富系統設計；端到端跟蹤；EA提供使用工具，能夠跟蹤依賴關系、支持大型模型，幫助您管理大型復雜的工程；含有CVS或SCC提供工具，以時間快照為基線，通過比較來跟蹤模型變動，從而實現版本控制；含有類似explorer的項目視窗，為您提供直觀高性能的工作界面。EA還含有一個所見即所得形式的模板編輯器，提供強大的文檔生成和報告工具，能夠生成復雜詳細的報告，報告可以按照公司或客戶要求的格式提供所需信息。EA具備源代碼的前向和反向工程能力，支持多種通用語言；EA還提供變換模板，編輯和開發均非常簡單，支持先進的模型驅動結構體系（MDA）。

Visual Paradigm

是由一家香港公司開發的 UML 工具。功能的強大不次于rose等case工具?？梢院推渌ぞ哒?，包括Eclipse/IBM WebSphere 等并且支持多平臺簡單介紹如下特性：支持UML2.0;支持生成Html,PDF,Writer的報表;可以導入Rose 的UML圖;匯出為XMI;可以生成Java代碼;有.Net的Add-In;支持E-R圖建模;支持ORM;智能化的提示即當你把鼠標移到一個UML圖上時,周圍自動顯示能和此UML圖相關的UML圖可快速地添加。

第三篇：軟件工程心得

學習軟件工程這門課程已經有一個學期了，整一個學期下來，應該說還是有許多值得肯定的地方的，其實在我看來，軟件工程與其說是一門課程，不如說是一門思想。是一個如何去分析和處理問題的過程，應該說其范疇已經遠遠不止局限于該門課程，成為了一個綜合的一個能夠解決問題的思想集合。

在上課的時候我還是很認真地去聽老師所講述的內容的，我覺得他的思想和我一向而來的培養計算機學生綜合素質的理解還是在一定程度上不謀而合了，所謂的需求獲取，那就是一個談判，辯論，交流的過程，已經不是單純的編編程序就能解決的問題了。從我所看到的聽到的來說，我最怕的就是計算機系的學生被別人說成是個帶著厚眼鏡的，只能夠在電腦前編編程序的，在交際場上不知道說什么而一個字都說不出來的人。我覺得這樣的人進入社會之后是沒有什么前途的，起碼他們缺乏了與人溝通交流的能力。而這門課程在一定程度上給了我們這些學生一個機會來鍛煉自己在另一方面的能力，設想一下，一個又有技術又能夠與人交流合作的人所取得的成就自然要比一個單單只會編程序的人要大得多。

其次，這門課程教給了我們在完成一個實際項目時的一般程序及過程，我認為這是一份非常具有實際意義的教學內容。當我們在畢業之后，這是我們實際要運用的一項非常有用的技能，而且不僅僅局限于軟件工程的范疇，我們即使是從事與其它行業，不也是要從需求獲取開始，一直有條有理地到最后成品的出爐嗎？應該說這就是這門課的價值所在。無論是在上課，還是在學生會里面做學生工作，我都深深地感覺到，技術性的工作就好比變魔術，其實原理是非常簡單的，甚至可以說簡單的可笑，但是當你就是做出這么一個簡單的東西出來之后，一些外行們有時候會用崇拜的眼光看著你，覺得你很厲害，很高深莫測。但是制作的過程他們卻不知道，也許知道之后他們只是會啞然失笑，原來這個東西的制作過程是如此的簡單。這個可以說就是技術的魅力了，而作為需求獲取及之后的一系列過程則是類似于魔術揭秘的過程，但是作為這個秘密我們并不需要一揭到底，至于揭的程度如何那就是我們那就是我們學出的程度如何了，我們要讓對方知道我們在做什么？以及如何去做？這些東西需要我們以一定的技巧敘述出來，所起到的作用就是能夠讓對方了解自己的進度，卻又能夠不讓對方來干涉自己的工作過程。因為我們是技術員，對方只是外行，即使對方知道了這個魔術的操作過程，也并不代表他們就能夠向變著魔術的我們來隨便修改這個魔術的變法，況且我們能夠用不同的過程來得出一個同樣的結果，這個過程的得出的主動權如何掌握在我們的手上，就看我們如何以高明的方式來揭開這個魔術的謎底了。

當然了，在純粹的理論上，我覺得開設這樣一門課程是很成功的。但是畢竟現實里有太多的不確定的因素。最重要的因素就是授課的老師和聽課的學生。這兩個可以說是這門課成與敗的決定性的因素。

作為老師方面來說，我覺得給我們上試驗課的老師非常的優秀，作為一名了有十幾年工作經驗的老船長，看問題的確是有他自己獨特的一套方法，我的話對他也是非常崇拜的。但是周日晚上的課程我還是有比較大的意見，首先，作為學生來說，最不希望上課的時間就是周五的晚上和周日的晚上，因為這是個我們進行調整的時候，前者的調整是為了假期的到來，后者的調整是為了準備學習的開始，這個時候的上課一般來說都是學生比較反感的。其次，對于我來說，原來小的時候非常崇拜那些有著高學歷的人才，什么碩士，博士，博士后都是被放在神壇上的人物，覺得他們很厲害，走路都會散發光環。但是在我上了他們這些人的課之后我發覺我真的是很失望。作為一個具有高學歷的人來說，他能夠自己迅速的吸收知識這點的確是令人敬佩，但是他能不能夠把自身所吸收的知識傳授給他的學生，那就是一個未知之數了，雖然的確這是一門枯燥的課程，但是并不代表老師就可以在講臺上講課沒有一點激情，或者說沒有一點能夠讓我們想聽下去的欲望，這個不得不說是一件非常諷刺的事情。子不教，父之過；教不嚴，師之惰。雖然學生們也有一部分的責任，但是把一切責任都推到學生們的身上那也是非常的不公平的。

作為我們學生來說，當然也應該負起比較主要的責任。在大學里有了太多的基礎課程，基礎課程大多都比較枯燥無味，也許在第一個學期里我們還能夠保持著新鮮感，但是在5個學期之后，可以說再有新鮮感就是一件比較困難的事情了，我們都已經開始變得遲鈍了，現在出現了一門新鮮的課程，可能同學們比較難把那樣不好的狀態一下子改變過來。其次的，學生們沒有認識到這門課程的價值。這門課的價值我已經在上面說過了，是不言而喻的。但是并不是每個同學畢業之后都回從事計算機行業，也不是每個同學都知道這門課程的意義已經不僅僅局限于計算機這個范疇，但是他們不知道，無知者無畏也。既然和我沒什么關系，那我就不聽，反正聽了也沒什么用，很多同學報著的就是這么個心態。對于這樣的心態，我表示理解，也表示悲哀。在沒有徹底了解一件事物的本質之前，我們是沒有資格向這件事物隨便的指手畫腳的。最怕的就是在沒有了解之前就把這件事物否定。如果有了這樣先入為主的思想，那就比較沒救了。所以作為我們來說，還是更需要得深入了解下這門課所起到的作用之后再下結論也不遲。只是有一點我還是覺得比較奇怪，現在被人嗤之以鼻的傳銷在當時能夠吸引如此大的一批人，而且那些受害者明知道這件事情是不好的但是還會去做，就是因為“洗腦者”的口才說服了他們，那作為老師來說，如何來說服學生們來上一門正確的課程應該說是要相對的容易很多吧，但是我覺得這樣的過程在我們的大學課程里真的是少之又少啊。今天在這里寫了很多，算是我對軟件工程這門課程的一點點心得體會，也許是正確的，也許在一定的程度上存在著觀點的偏激錯誤，但是起碼這些東西是我覺得存在著的一些問題，但愿軟件工程這門課程能夠開的越來越好，讓更多的學生們能夠從這門課程中受益，在以后社會殘酷的競爭之中存活下來！

第四篇：軟件工程課程心得

軟件工程項目總結

在我們整個軟件工程過程中，我體會到了許多，也學到了許多。

在項目要進行自由分組后，我們的項目小組便誕生了。我們小組由七個成員組成，在相互商量后我們也確定了我們組的項目，是做一個校園 b2c電子商務網站。我們也隨即做了分工，由于我們團隊只有我和另一名成員有類似的項目開發經驗，所以我們便要擔負起更重的任務。最后由于在整個團隊中，對于界面開發這一塊只有我的開發經驗較深，所以我便擔任了主要的界面設計人員。我們的項目也正式開始了。

需求調研和分析對于軟件開發過程至關重要。我們在開發時如果不進行調研和分析，那么對于后來的項目進展將產生致命的后果。我們在項目的開發中便遇到了這樣的問題。老師作為我們的客戶，他對這個校園 b2c電子商務網站的要求便是我們必須了解的，我們也必須以客戶的要求為根本構建我們的這個系統。我們開始自己隨意的計劃整個網站的設計，然后報給老師，老師作為一個客戶并不是全部認同，隨后我們也必須按著客戶的要求更改我們的設計報告。我也明白了，再做一個系統時，必須隨時和客戶保持溝通，隨時了解他們需要什么，他們想要什么功能。如果我們不去和客戶溝通，不去調研客戶的需求，做出來的系統即使在我們看來是一個很好，很完美的產品，但是如果客戶不認同，那么我們所做的一切都是徒勞，還要返工去修改，費時費力。所以在做任何一個項目時，前期的需求調研和需求分析都是必須的，這是在做一個項目的基本，是關系成敗的重要一環。

對于一個項目，它的需求設計也非常重要。在我們的校園 b2c電子商務網站開發的過程中，遇到了一些問題，如客戶提交購買確認后，我們如何確定應該以什么方式將貨物給客戶，還有以什么確定貨物的送達地點，客戶的訂單在哪里處理，訂單以什么方式驚醒處理，在管理員應該實現的功能上反復增刪等，這些問題很多都是由于設計不夠清晰，不夠完善而導致的。出現的這些問題很多都是非常棘手的，我們為了解決這些棘手的問題浪費了大量的時間，我們不得不在工程代碼上改了又改，在數據庫里增表、刪表、加數據、減數據，當然，在文檔里也要做出相應的修改以適應新的功能。還好，我們能及時地發現問題，通過相互

溝通討論，問題也得到了解決。通過總結，我們也意識到，我們大家在做需求分析和進行需求了解時僅僅考慮了一些基本的功能，而至于管理員和客戶之間的聯系，以及具體的一些流程我們都沒有深究，而導致我們到后期花費了大量的時間用于修復之前沒有考慮周全而帶來的問題。如果我們的需求設計能夠比較清晰和完善，那么我們在開發過程中便會很明白的知道我們應該實現什么樣的功能，在數據庫里應該怎樣建表，以什么方式插入數據，從而可以避免反復修改工程的問題，也能避免出現可能毀壞整個工程的問題。整個工程的需求設計對于一個項目的順利進展至關重要。

對于文檔在軟件工程中的作用，我在這次項目開發過程中有了更加深刻的理解。文檔在軟件開發過程中是很有用的，文檔是一項必不可少的東西，但文檔也不能太多，太過繁瑣，如果是那樣就不太好了。首先我們要明確開發過程中為什么要寫這些文檔，文檔的最根本的作用是為了更好的溝通。一個項目或產品可能需要延續很長的時間，開發過程中可能需要很多的環節，可能會遇到很多的問題和很多的解決的方法，這時，我們需要文檔的幫助，我們需要有一個東西來記錄，我們需要有一個共同的聲音。文檔只不過是一個準繩，將開發中的各個樹枝樹葉扶正。如果，這個準繩太多太緊，大樹可能會發育的很高很直，但是就是有些畸形，如果這個準繩太少太松，大樹可能就會變成灌木叢。文檔的多少、繁簡是有度的，絕對不能說越多越好。我覺得，文檔需要說明解決問題的方法而不是解決問題的理論，因為解決問題的理論是在文檔形成中做到的。文檔完整即可，每一份文檔說明一個問題，無需將多個文檔的內容放在一個文檔的里面。除了重要階段形成文檔，其它部分都只是討論或者說是想法。不要讓文檔成為累贅，如果真是這樣，我認為就是該考慮寫這些文檔的必要性的時候了。我們在文檔的時候，一定要明白為什么要寫這些。

在整個項目開發過程中，我們也同時遇到了許多程序接口問題，頁面和功能相結合的問題，數據庫建表的問題，這些問題都是源于我們項目小組成員之間的溝通不足。我深刻認識到，在項目開發時，項目小組中各個成員之間的相互溝通是非常重要的。如果我們要在功能方面作出修改，那么程序人員和頁面人員及數據庫人員就必須相互溝通，共同對整個程序作出相應的修改，這樣才能避免最終整合時出現問題。

在這十個周里，我還對軟件工程有了新的理解。在我以前的理解當中，軟件工程，無非就是一個人或者幾個人或一個團隊集中在一起進行編寫代碼的工作，以實現開發出所用的軟件。但現在我明白了，軟件工程的作用，就是告訴人們怎樣去開發軟件和管理軟件。具體地講，它表現在與軟件開發和管理有關的人員和過程上。所以，軟件工程就不僅僅是單一的編程過程了。它包括了系統分析->建模->概要設計->詳細設計->編碼->測試->維護。編碼可以理解為編程，這個只占總時間的20％左右。編程只是其中的一小部分。

在這次項目里我完成了許多工作，在界面設計上我完成了，首頁、全部的商品頁面、全部的用戶頁面及部分管理員頁面的制作，在后期項目整合過程中修改了功能和界面結合時出現的bug，還有數據庫插入數據及解決數據庫集中整合時出現的問題。這些工作我都順利完成了，雖然并不能算是非常的出色，但也算是盡力了?，F在看到自己辛勞的成果，我感到很欣慰。

當然，在這次項目過程中我也發現了自己的一些問題。如現在的網站開發技術還不夠強，在和小組成員相互溝通上還不夠積極等。我希望以此為契機，在將來的項目開發中能做得更好。

第五篇：軟件工程實驗心得

早在我選擇民政職業技術學院就讀軟件開發與項目管理這門專業的時候，我一直認為軟件開發無非是努力的敲代碼，從敲代碼的過程中去體會各行代碼的意思和用處，在沒學軟件工程時我一直都是努力的敲代碼去學習軟件開發這門專業。在大一的時候我敲代碼的激情很好，但是到大二的時候就出現問題了，我根本就不喜歡敲代碼了，看見代碼就頭疼。所以感覺厭惡這門專業，對學習也不感興趣了。而且，還有一件更頭疼的事是在寫一個簡單的程序時竟然老是出錯，難一點的，復雜一點的程序竟然無從下手。但是去看程序的參考答案時都看得懂，又感覺很容易。學了軟件工程以后，我就感覺我以前的學習方法是錯誤的。以前我只注重于代碼，而不注重理論知識以及編程的思路，程序的架構。以至于在些程序時沒有寫程序的思路，不能形成程序的架構。只想到看腦袋里是否有與此類似的代碼。越想程序越亂，最后腦袋里一片空白。不知道程序從哪個方面下手了。

軟件工程這門課程是做軟件開發的人必學的課程，通過學這門課程，程序員就會注重軟件開發的理論知識，以及做項目開發的思路。學了這門課程后你寫程序就不會去盲目的去套用代碼，而是理清此程序的架構以及思路。程序該從什么時候開始，什么時候結束。在中間需要添加什么樣的功能，以完善該軟件。其實學軟件工程并不難，而且很容易。軟件工程與日常生活聯系起來的話，就是在一天中你該先做什么，后做什么。理解了先做什么，后做什么了以后寫程序就不是那么難了，再復雜的程序也可以分成幾大塊。你理清程序的思路后就可以一步步的解決其中的難題，最終實現軟件的功能。如果沒學軟件工程不知道理清程序的思路的話，做一個大的項目開發，那么多的代碼，沒有一個很好的結構，最終只會導致程序混亂，錯誤百出，知道代碼再多也會素手無策的。

總而言之，作為一個程序員學習軟件工程這門課程是至關必要的，如果沒學習軟件工程，你就不會做項目開發，也不可能開發出一個完善的軟件出來。

軟件工程實驗心得（2）：

曾經看過一本書叫《道法自然》，內容略記得一二，但我最欣賞的是它的書名。軟件設計沒什么太神秘有東西，只要用心體會，其實一切都很自然。軟件的設計之“道”，也不在于設計有多么的華麗、精巧，而在于其樸實、自然，最終達到“以無招勝有招”，進入一個全新的境界。

一、軟件設計理論的層次

以我的拙見，軟件設計領域中的各種概念，可以分為以下幾個層次來進行理解：

1、軟件設計的目的：重用性、擴展性。

這是最高的層次，是應對軟件危機的需要。

2、設計原則：低耦合、高聚合。

各種軟件設計的原則，如依賴倒置原則、單一職則原則、面向接口等，以及各種設計模式，其根本的目的其實只是為了降低耦合這么簡單。因為只有低耦合才能更好的適應變化，更好的重用和擴展。

3、實現方法：運用設計模式封裝變化、降低耦合。

設計模式只是用來“封裝變化、降低耦合”的工具而已。它是面向對象設計時代的產物，其本質就是充分運用面向對象的三個特性，即：封裝、繼承和多態，進行靈活的組合運用。

二、關于耦合1、耦合的粒度

耦合無論如何也是不可避免的。當我們實現接口、繼承父類的時候，就會不可避免的產生耦合。耦合是有不同粒度的，我們解耦到什么粒度為止，我認為應以模塊的重用粒度為準。盡量解除重用模塊或對象之間的耦合。而重用模塊之內的耦合，應屬于聚合的范疇，所以不要盲目的去解耦，否則就陷入了誤區。

2、解耦的原理

怎樣才能解耦呢，或者說為什么各種設計模式能達到解耦的目的呢?我覺得有以下幾個思路：

(1)將具體的東西抽象處理

(2)將分散的東西集中處理

而面向對象中的接口、繼承正為我們提供了這樣的一種機制。通過訪問接口或基類或抽象類，而不是具體的實現類，從而與具體的實現類達到了解耦的目的。我們還可以設計一些控制類，像潤滑劑一樣，協調各實現類之間的訪問，也可以達到耦的目的。

事實上，各種設計模式的基本思想也就是這樣。創建型模式是為了解除創建對象時產生的耦合，實際上是解除對類稱名的依賴，而結構型和行為型是為了解除對象屬性或方法的直接調用。不管什么設計模式，都是將對具體實現類的訪問提升為對接口、基類或用于協調的控制類的訪問。

三、關于接口

這一節更具體，談一談接口，因為使用接口是軟件設計的重要手段，但已經不屬于“道”了~

1、接口與繼承

接口描述的是對象某一個方面行為特征。使用接口與使用繼承關系各有優缺點，使用子類繼承可以繼承父類的功能，體現了重用的精神。而接品更加靈活，因為它解除了子類與父類之間的高度耦合，它體現在靈活擴展的精神。

2、接口與純虛類

理論上接口可以由純虛基類實現類似的功能，那為什么還我們不去掉接口的概念，而直接使用虛類呢?

接口存在的理由就是它更加靈活，關系簡單，易于理解。比如一個類可以實現十幾個甚至幾十個接口，但一般開發工具只支持單繼承(由于多繼承太容易導致混亂和沖突)，如果要繼承十幾層，系統結構想必會無法理解了，我以為這是接口存在的最重要的原因。

如果接口和虛類繼承結合使用，可以產生強大的威力，這也是許多設計模式的“殺手锏”。

以上算是總結一下自己的心得?？隙ㄓ胁簧倨嬷?，請各位指教。