1. 誰能給我一份學習軟體工程的心得體會 不少於2000字的 這是我在百度提的第一個問題 希望有人回復！
我是個外行，不過還是可以幫助你的，你在網路首頁輸上學習軟體工程的心得體會，會在網路文庫里出現很多文庫，都是關於心得體會的，希望對您有幫助，
2. 軟體工程中三種面向對象模型的主要功能
1、功能模型(即用例模型à作為輸入)
2、對象模型:對用例模型進行分析,把系統分解成互相協作的分析類,通過類圖/對象圖描述對象/對象的屬性/對象間的關系,是系統的靜態模型
3、動態模型:描述系統的動態行為,通過時序圖/協作圖描述對象的交互,以揭示對象間如何協作來完成每個具體的用例,單個對象的狀態變化/動態行為可以通過狀態圖來表達
3. 軟體工程就如何利用面向對象的軟體開發方法來開發軟體,談自己的心得體會
隨著計算機世界的高速發展，軟體事業的增強，軟體在我們生活中的運用隨處都是，但軟體業也因此興起，但作為IT業內人士則考慮的不是這些問題，而是如何用一個好的軟體開發方法去開發好一個軟體。現在，在眾多的軟體開發方法中，選擇了面向對象的的方法來談談我的個人見解。為什麼要選它呢，因為這種方法在現在是最常用的一種，大多數的開發商都採用了面向對象的方法。
談到面向對象，這方面的文章非常多。但是，明確地給出對象的定義或說明對象的定義的非常少——至少我現在還沒有發現。其初，「面向對象」是專指在程序設計中採用封裝、繼承、抽象等設計方法。可是，這個定義顯然不能再適合現在情況。面向對象的思想已經涉及到軟體開發的各個方面。如，面向對象的分析（OOA，Object Oriented Analysis），面向對象的設計（OOD，Object Oriented Design）、以及我們經常說的面向對象的編程實現（OOP，Object Oriented Programming）。許多有關面向對象的文章都只是講述在面向對象的開發中所需要注意的問題或所採用的比較好的設計方法。看這些文章只有真正懂得什麼是對象，什麼是面向對象，才能最大程度地對自己有所裨益。這一點，恐怕對初學者甚至是從事相關工作多年的人員也會對它們的概念模糊不清。
面向對象是當前計算機界關心的重點，它是90年代軟體開發方法的主流。面向對象的概念和應用已超越了程序設計和軟體開發，擴展到很寬的范圍。如資料庫系統、互動式界面、應用結構、應用平台、分布式系統、網路管理結構、CAD技術、人工智慧等領域。
不論採用哪種方法來開發軟體，分析的過程都是提取系統需求的過程。分析工作主要包括3項內容，這就是理解，表達和驗證。首先，系統分析員通過用戶及領域專家的充分交流，力求完全理解用戶需求和該應用鄰域中的關鍵性的背景知識，並用某種無二義性的方式把這種理解表達成文檔資料。分析過程得出的最重要的文檔資料是軟體需求規格說明（在面向對象分析中，主要由對象模型，動態模型和功能模型組成）。
由於問題復雜，而且人與人之間的交流帶有隨意性和非形式化的特點，上述理解過程通常不能一次就達到理解的效果。因此，還必須進一步驗證軟體需求規格說明的正確性，完整性和有效性，如果發現了問題則進行修正。顯然，需求分析過程是系統分析員與用戶及領域專家反復交流和多次修正的過程。也就是說，理解和驗證的過程通常交替進行，反復迭代，而且往往需要利用原型系統作為輔助工具。
面向對象分析（OOA）的關鍵是識別出問題域內的類與對象，並分析它們相互間的關系，最終建立起問題域的簡潔，精確，可理解的正確模型。在用面向對象觀點建立起的3種模型中，對象模型是最基本，最重要，最核心的。
下面我們來看看面向對象的開發方法。
一 .首相讓我們來了解什麼是面向對象：
(1)對象：對象是人們要進行研究的任何事物，從最簡單的整數到復雜的飛機等均可看作對象，它不僅能表示具體的事物，還能表示抽象的規則、計劃或事件。
(2)對象的狀態和行為。
對象具有狀態，一個對象用數據值來描述它的狀態。
對象還有操作，用於改變對象的狀態，對象及其操作就是對象的行為。
對象實現了數據和操作的結合，使數據和操作封裝於對象的統一體中
(3)類：具有相同或相似性質的對象的抽象就是類。因此，對象的抽象是類，類的具體化就是對象，也可以說類的實例是對象。
類具有屬性，它是對象的狀態的抽象，用數據結構來描述類的屬性。
類具有操作，它是對象的行為的抽象，用操作名和實現該操作的方法來描述。
(4)類的結構：在客觀世界中有若干類，這些類之間有一定的結構關系。通常有兩種主要的結構關系，即一般--具體結構關系，整體--部分結構關系。
①一般——具體結構稱為分類結構，也可以說是「或」關系，或者是「is a」關系。
②整體——部分結構稱為組裝結構，它們之間的關系是一種「與」關系，或者是「has a」關系。
(5)消息和方法:對象之間進行通信的結構叫做消息。在對象的操作中，當一個消息發送給某個對象時，消息包含接收對象去執行某種操作的信息。發送一條消息至少要包括說明接受消息的對象名、發送給該對象的消息名（即對象名、方法名）。一般還要對參數加以說明，參數可以是認識該消息的對象所知道的變數名，或者是所有對象都知道的全局變數名。
二. 下面讓我們來認識一下面向對象的特徵和幾大要素：
(1)對象唯一性。(2)分類性。(3)繼承性。(4)多態性(多形性)
面向對象的要素：(1)抽象。 (2)封裝性（信息隱藏）。(3)共享性
三. 面向對象和基於對象的區別：
很多人沒有區分「面向對象」和「基於對象」兩個不同的概念。面向對象的三大特點（封裝，繼承，多態）卻一不可。通常「基於對象」是使用對象，但是無法利用現有的對象模板產生新的對象類型，繼而產生新的對象，也就是說「基於對象」沒有繼承的特點。而「多態」表示為父類類型的子類對象實例，沒有了繼承的概念也就無從談論「多態」。現在的很多流行技術都是基於對象的，它們使用一些封裝好的對象，調用對象的方法，設置對象的屬性。但是它們無法讓程序員派生新對象類型。他們只能使用現有對象的方法和屬性。所以當你判斷一個新的技術是否是面向對象的時候，通常可以使用後兩個特性來加以判斷。「面向對象」和「基於對象」 都實現了「封裝」的概念，但是面向對象實現了「繼承和多態」，而「基於對象」沒有實現這些，的確很饒口。
從事面向對象編程的人按照分工來說，可以分為「類庫的創建者」和「類庫的使用者」。使用類庫的人並不都是具備了面向對象思想的人，通常知道如何繼承和派生新對象就可以使用類庫了，然而我們的思維並沒有真正的轉過來，使用類庫只是在形式上是面向對象，而實質上只是庫函數的一種擴展。
面向對象是一種思想，是我們考慮事情的方法，通常表現為我們是將問題的解決按照過程方式來解決呢，還是將問題抽象為一個對象來解決它。很多情況下，我們會不知不覺的按照過程方式來解決它，而不是考慮將要解決問題抽象為對象去解決它。有些人打著面向對象的幌子，干著過程編程的勾當。
在對面向對象方法學有了一定的理解後，我們可以知道，面向對象方法學的出發點和根本原則，是盡量可能模擬人類習慣的思維方式，使開發軟體的方法與過程盡可能接近人類認識世界解決問題的方法與過程，也就是使描述問題的問題空間（也稱為問題域）與實現解決的解空間（也稱為求解域）在結構上盡可能一致。
四 .面向對象方法學和傳統方法學較之有了很大的優點：
1.它與人習慣的思維方法一致。
傳統的程序設計技術是面向過程的設計方法，這種方法以計算為中心，把數據和過程作為相互獨立的部分，數據代表問題空間中的客體，程序代碼則用於處理這些數據。而面向對象的方法學是以對象為核心，用這種技術開發出的軟體系統由對象組成的。
2.穩定性好。
傳統的軟體開發方法以計演算法為核心，開發過程基於功能分析和功能分解，所以它很不穩定。而面向對象的方法學是基於構造問題鄰域的對象模型，以對象為中心構造軟體系統，它的基本做法是對象模擬問題鄰域中的實體，以對象間的聯系刻畫實體間的聯系。由於現實世界中的實體是相對穩定的，因此，以對象為中心構造的軟體系統也是比較穩定的。
3.可重用性好。
傳統的軟體重用技術是利用標准函數庫，也就是試圖用標准函數庫中的函數作為「預製件」來建造新的軟體系統，但是，標准函數缺乏必要的「柔性」，不能適應不同應用場合的不同需要，並不時理想的可重用的軟體成分。而在實際開發一個新的軟體系統時，通常多數函數是開發者自己編寫的，甚至絕大多數的函數都是新編的。
面向對象的軟體技術在利用可用的軟體成分構造新的軟體系統時，有很大的靈活性。它有兩種方法可以重復使用一個對象類：一種方法是創建該類的實例，從而直接使用它，另一種方法是從它派生出一個滿足當前需要的新類。它所實現的重用性是自然的和准確的，不像傳統的方法是刻意的。
4.較易開發大型軟體產品。
在開發大型軟體產品時，組織開發人員的方法不恰當往往是出現問題的主要原因。用面向對象方法學時，構成軟體系統的每一個對象就像一個微型程序，有自己的數據，操作，功能和用途，因此，可以把一個大型軟體產品分解成一系列本質上相互獨立的向產品來處理，故它比較容易開發大型軟體。
5.可維護性好。
用傳統的方法和面向過程語言開發出來的軟體很難維護，然而面向對象的方法由於存在下面幾種原因故維護性好。
因素：面向對象的軟體穩定性比較好。
面向對象的軟體比較容易修改。
面向對象的軟體比較容易理解。
面向對象的軟體易於測試和調試。
最後：
目前，面向對象開發方法的研究已日趨成熟，國際上已，有不少面向對象產品出現。我相信這種方法在不斷地完善下不僅現在適用，就算再將來，它也會被相當多的開發商使用的。
4. 軟體工程面向對象分析與建模，類圖中的實體類到底是什麼請給出自己語言的解釋，不要定義
類是對象的模板，把很多個屬性封裝起來
5. 就如何利用面向對象的軟體開發方法來開發軟體心得體會
面向對象技術是軟體技術的一次革命，在軟體開發史上具有里程碑的意義。
隨著OOP（面向對象編程）向OOD（面向對象設計）和OOA（面向對象分析）的發展，最終形成面向對象的軟體開發方法 OMT(LbjectModellingTechnique）。這是一種自底向上和自頂向下相結合的方法，而且它以對象建模為基礎，從而不僅考慮了輸入、 輸出數據結構，實際上也包含了所有對象的數據結構。所以OMT徹底實現了PAM沒有完全實現的目標。不僅如此，OO技術在需求分析、可維護性和可靠性這三 個軟體開發的關鍵環節和質量
指標上有了實質性的突破，徹底地解決了在這些方面存在的嚴重問題，從而宣告了軟體危機末日的來臨。
自底向上的歸納
OMT的第一步是從問題的陳述入手，構造系統模型。從真實系統導出類的體系，即對象模型包括類的屬性，與子類、父類的繼承關系，以及類之間的關 聯。類是具有相似屬性和行為的一組具體實例（客觀對象）的抽象，父類是若乾子類的歸納。因此這是一種自底向上的歸納過程。在自底向上的歸納過程中，為使子 類能更合理地繼承父類的屬性和行為，可能需要自頂向下的修改，從而使整個類體系更加合理。由於這種類體系的構造是從具體到抽象，再從抽象到具體，符合人類 的思維規律，因此能更快、更方便地完成任務。這與自頂向下的Yourdon方法構成鮮明的對照。在Yourdon方法中構造系統模型是最困難的一步，因為 自頂向下的「頂」是一個空中樓閣，缺乏堅實的基礎，而且功能分解有相當大的任意性，因此需要開發人員有豐富的軟體開發經驗。而在ＯＭＴ中這一工作可由一般 開發人員較快地完成。在對象模型建立後，很容易在這一基礎上再導出動態模型和功能模型。這三個模型一起構成要求解的系統模型。
自頂向下的分解
系統模型建立後的工作就是分解。與Yourdon方法按功能分解不同，在OMT中通常按服務（Service）來分解。服務是具有共同目標的相關 功能的集合，如I／O處理、圖形處理等。這一步的分解通常很明確，而這些子系統的進一步分解因有較具體的系統模型為依據，也相對容易。所以OMT也具有自 頂向下方法的優點，即能有效地控制模塊的復雜性，同時避免了Yourdon方法中功能分解的困難和不確定性。
OMT的基礎是對象模型
每個對象類由數據結構（屬性）和操作（行為）組成，有關的所有數據結構（包括輸入、輸出數據結構）都成了軟體開發的依據。因此Jackson方法 和PAM中輸入、輸出數據結構與整個系統之間的鴻溝在OMT中不再存在。OMT不僅具有Jackson方法和PAM的優點，而且可以應用於大型系統。更重 要的是，在Jackson方法和PAM方法中，當它們的出發點——輸入、輸出數據結構（即系統的邊界）發生變化時，整個軟體必須推倒重來。但在OMT中系 統邊界的改變只是增加或減少一些對象而已，整個系統改動極小。
需求分析徹底
需求分析不徹底是軟體失敗的主要原因之一。即使在目前，這一危險依然存在。傳統的軟體開發方法不允許在開發過程中用戶的需求發生變化，從而導致種種問題。正是由於這一原
因，人們提出了原型化方法，推出探索原型、實驗原型和進化原型，積極鼓勵用戶改進需求。在每次改進需求後又形成新的進化原型供用戶試用，直到用戶基本滿意，大大提高了軟體的
成功率。但是它要求軟體開發人員能迅速生成這些原型，這就要求有自動生成代碼的工具的支持。
OMT徹底解決了這一問題。因為需求分析過程已與系統模型的形成過程一致，開發人員與用戶的討論是從用戶熟悉的具體實例（實體）開始的。開發人員必須搞清現實系統才能導出系統模型，這就使用戶與開發人員之間有了共同的語言，避免了傳統需求分析中可能產生的種種問題。
可維護性大大改善
在OMT之前的軟體開發方法都是基於功能分解的。盡管軟體工程學在可維護方面作出了極大的努力，使軟體的可維護性有較大的改進。但從本質上講，基於功能分解的軟體是不易
維護的。因為功能一旦有變化都會使開發的軟體系統產生較大的變化，甚至推倒重來。更嚴重的是，在這種軟體系統中，修改是困難的。由於種種原因，即使是微小的修改也可能引入
新的錯誤。所以傳統開發方法很可能會引起軟體成本增長失控、軟體質量得不到保證等一系列嚴重問題。正是OMT才使軟體的可維護性有了質的改善。
OMT的基礎是目標系統的對象模型，而不是功能的分解。功能是對象的使用，它依賴於應用的細節，並在開發過程中不斷變化。由於對象是客觀存在的，因此當需求變化時對象的性質要比對象的使用更為穩定，從而使建立在對象結構上的軟體系統也更為穩定。
更重要的是OMT徹底解決了軟體的可維護性。在OO語言中，子類不僅可以繼承父類的屬性和行為，而且也可以重載父類的某個行為（虛函數）。利用這 一特點，我們可以方便地進行功能修改：引入某類的一個子類，對要修改的一些行為（即虛函數或虛方法）進行重載，也就是對它們重新定義。由於不再在原來的程 序模塊中引入修改，所以徹底解決了軟體的可修改性，從而也徹底解決了軟體的可維護性。OO技術還提高了軟體的可靠性和健壯性。
6. 學習《軟體工程》心得和體會
軟體工程學習心得
在本學期的軟體工程課程的學習中，我們學習了十一章的內容。第一章軟體與軟體工程的概念，這一章主要講解的是一些概念性和基礎性的內容，例如軟體的概念、特性，軟體危機的主要表現，軟體工程的概念以及軟體生存期、典型生存期模型等等。第二章軟體工程方法與工具，這一章主要對軟體工程方法進行介紹，包括三種方法：傳統方法、面向對象方法、形式化方法。還引出了工具UML。第三章軟體需求獲取與結構化分析方法，本章詳細介紹了需求獲取與需求分析階段的任務以及結構化分析方法，畫分層的數據流圖、E-R圖以及狀態圖式本節的重點。第四章結構化分析方法，這一章重點講解了使用變換型映射方法和事務型映射方法生成初始的模塊結構以及模塊結構的改進。第五章編碼，這一章重點講解了編碼的風格及規范，還告訴我們編碼規范說帶來的好處，並告誡我們將來一點要形成好的編碼風格。第六章軟體測試方法，本章講解了軟體測試相關的概念及重要性，軟體測試與開發各個階段的關系；還介紹了白盒測試技術以及黑河測試技術。第七章統一建模語言UML概述，本章詳細介紹了UML的基本模式、事物、關系及建模時用到的各種圖進行了介紹。第八章面向對象分析，這一章主要講解了面向對象分析的3種模型，包括功能模型、靜態模型和動態模型。第九章軟體體系結構與設計模式，本章對軟體體系結構的基本概念、典型風格等進行了講解。第十章面向對象設計，本章的重點是對面向對象分析時建立的對象模型進行調整和細化。第十一章軟體維護，本章主要介紹軟體維護的任務、軟體維護活動以及軟體維護方法進行了介紹。
要學習軟體工程，學會如何系統的思考，以及養成良好的編碼習慣，想學好軟體工程，就必須知道軟體工程的目標、過程和原則：
軟體工程目標：生產具有正確性、可用性以及開銷合宜的產品。正確性指軟體產品達到預期功能的程度。可用性指軟體基本結構、實現及文檔為用戶可用的程度。開銷合宜是指軟體開發、運行的整個開銷滿足用戶要求的程度。這些目標的實現不論在理論上還是在實踐中均存在很多待解決的問題，它們形成了對過程、過程模型及工程方法選取的約束。
軟體工程過程：生產一個最終能滿足需求且達到工程目標的軟體產品所需要的步驟。軟體工程過程主要包括開發過程、運作過程、維護過程。它們覆蓋了需求、設計、實現、確認以及維護等活動。需求活動包括問題分析和需求分析。問題分析獲取需求定義，又稱軟體需求規約。需求分析生成功能規約。設計活動一般包括概要設計和詳細設計。概要設計建立整個軟體系統結構，包括子系統、模塊以及相關層次的說明、每一模塊的介面定義。詳細設計產生程序員可用的模塊說明，包括每一模塊中數據結構說明及加工描述。實現活動把設計結果轉換為可執行的程序代碼。確認活動貫穿於整個開發過程，實現完成後的確認，保證最終產品滿足用戶的要求。維護活動包括使用過程中的擴充、修改與完善。伴隨以上過程，還有管理過程、支持過程、培訓過程等。
軟體工程的原則是指圍繞工程設計、工程支持以及工程管理在軟體開發過程中必須遵循的原則。
我們學習了詳細設計的方法，其原則是過程描述是否易於理解、復審和維護，進而過程描述能夠自然地轉換成代碼，並保證詳細設計與代碼完全一致。包括程序流程圖、N-S圖、PAD圖、HIPO圖
程序流程圖：程序流程圖又稱之為程序框圖，它是軟體開發者最熟悉的一種演算法表達工具。它獨立於任何一種程序設計語言，比較直觀和清晰地描述過程的控制流程，易於學習掌握。在流程圖中只能使用下述的五種基本控制結構：順序型；選擇型；while型循環；until型循環；多情況型選擇。
N-S圖：一種符合結構化程序設計原則的圖形描述工具，稱為盒圖，又稱為N-S圖。在N-S圖中，為了表示五種基本控制結構，規定了五種圖形構件。順序型；選擇型；WHILE重復型；UNTIL重復型；多分支選擇型。
PAD圖：它是用結構化程序設計思想表現程序邏輯結構的圖形工具。PAD也設置了五種基本控制結構的圖示，並允許遞歸使用。
HIPO圖：HIPO圖是由一組IPO圖加一張HC圖組成。它是美國IBM公司在軟體設計中使用的主要表達工具。
HC圖既是層次圖，用於表示軟體的分層結構。HC圖中的每一個模塊，均可用一張IPO圖來描述。IPO 圖由輸入、處理和輸出三個框組成，需要時還可以增加一個數據文件框，這種圖形的優點，是能夠直觀地顯示輸入—處理—輸出三者之間的聯系。
還有測試方法:按照測試過程是否在實際應用環境中來分，有靜態分析與動態測試。測試方法有分析方法（包括靜態分析法與白盒法）與非分析方法（稱黑盒法）。
靜態分析技術：不執行被測軟體，可對需求分析說明書、軟體設計說明書、源程序做結構檢查、流程分析、符號執行來找出軟體錯誤。
動態測試技術：當把程序作為一個函數，輸入的全體稱為函數的定義域，輸出的全體稱為函數的值域，函數則描述了輸入的定義域與輸出值域的關系。
還學習了其他很多工具、語言、方法等，雖然不是都學得很透徹，但我相信在今後的學習中一定會慢慢的完善的。
軟體工程對於初學者來說，知識基礎較薄弱，對一些應用操作、概念、工具方法等理解起來較為困難，要能從整體概念上較好地理解和把握、學好軟體工程，不是僅僅把幾本專業書籍細致地看幾遍，然後上機練習幾次就可以成功，學習過程中要注意多看多練要注意結合實際，更要多思考，面對錯誤不要一范就問，要嘗試自己去解決。但是還要注意什麼都學，肯定是什麼都學不透的，要集中精力打攻堅戰，學習軟體工程首先要明白自己的學習目標究竟是什麼，根據自己的實際工作出發，有針對性的在相應的學習方向上進行提高，制定出詳細的學習規劃。還要注意與其他科目的相輔相成，就像我們在學習面向對象分析的時候要結合大一學習的面向對象及其方法學這一專業科目進行研究拓展;在學習語言時，要看看與C語言的聯系，多思多想，把從各個科目學到的知識通匯貫通。
在軟體工程的學習中，我了解到了軟體並非是一些代碼這么簡單，在開發軟體的過程中，編寫代碼的工作量其實只佔不到所有工程量的30%，而後期的管理和維護更是佔了60%到80%之多。一個完整的項目規劃須包括，軟體的定義，可行性分析報告，項目開發計劃，軟體需求說明書，概要設計說明書，詳細設計說明書，用戶操作手冊，測試計劃，測試分析報告，開發進度報告，項目開發總結報告，軟體維護手冊，軟體問題報告，軟體修改報告，等多個文檔，每個文檔都要上級驗收審查，而文檔數量眾多，要做好這點真的不是很容易，而恰恰寫好文檔正能保證完成軟體工程其中一個目的的關鍵，既研究如何用最小的開銷做出生存期較長的軟體，再加上各個階段都要進行周密的策劃、詳細的分工部署和人員安排，且各階段要據具體情況不斷的反復才能達成，所以代碼只是開發軟體這個浩大的工程的一個小小的過程。
而編碼的學習中，我更了解到形成自己獨特的規范的編碼風格是非常重要的事。因為這影響到了軟體後期繁重的維護，大家都要閱讀你的程序，如果你寫的程序毫無規范可言，那麼別人怎麼能讀懂你的程序？讀不懂程序，維護又從何談起呢？所以，我們在今後的學習中，一定要注意這方面的培養，在寫程序的過程中，要逐步的在規范的基礎上形成屬於自己的風格，即方便自己的修改，也方便日後他人的閱讀。
在學習中，我們還要注意比較三種方法的優缺點，例如：傳統方法雖然使軟體擺脫了混亂和無序，但其在適應需求變化的方面不夠靈活，而且傳統方法要麼面向行為，要麼面向數據，缺乏兩者的有機結合。而面向對象方法的程序設計和問題求解更符合人們日常自然的思維習慣，適合大型、復雜及交互性比較強的系統。形式化方法則是一中基於形式化數學變換的軟體開發方法，它可將系統的規格說明轉換為可執行的程序。
在今後的學習中要注意多讀書、多思考、多練習、多討論，不斷熟悉書本的基礎，並以此為基礎將其擴散開來，應用於今後的實踐。不斷鍛煉自己，向一名合格的程序設計師邁進。
7. 軟體工程專業學習心得
挺好的 不過剛開始工資待遇一般 慢慢來 可以上軟體英才網 上找找 望你找到好工作