軟體工程的邏輯重構

㈠ 領導讓寫個邏輯出來給軟體工程師看

工程師的邏輯就是你需要什麼樣的數據，需要的流程每一步數據是怎麼樣變化的？把這種東西能夠表示出來就可以了，如果專業一點，就用產品經理用的軟體axure。這個是做交互見面的，工程師看到就明白了。

㈡ 軟體工程的題求解答~！

只知道這些：
1.B
2.A
7.A

㈢ 軟體工程中有無邏輯圖的概念對某種演算法的具體流程描述應該叫什麼

邏輯是總體思路 流程圖是具體操作步驟

㈣ 重構的概念是什麼

指對軟體代碼做任何更動以增加可讀性或者簡化結構而不影響輸出結果。

軟體重構需要藉助工具完成，重構工具能夠修改代碼同時修改所有引用該代碼的地方。在極限編程的方法學中，重構需要單元測試來支持。

在軟體工程學里，重構代碼一詞通常是指在不改變代碼的外部行為情況下而修改源代碼，有時非正式地稱為「清理干凈」。

在極限編程或其他敏捷方法學中，重構常常是軟體開發循環的一部分：開發者輪流增加新的測試和功能，並重構代碼來增進內部的清晰性和一致性。自動化的單元測試保證了重構不至於讓代碼停止工作。

(4)軟體工程的邏輯重構擴展閱讀：

重構面對業界調適接受方面的挑戰。首先，對重構長遠的影響需要更深入研究追蹤。又，重構存於資料庫輪廓（database schema）的商業邏輯層幾乎是不可能或者非常困難的。最後，對介面造成影響的重構可能造成程序開發上的困境，除非程序員有對所有用戶界面的訪問權。

例如，程序員若改變某實體中的方法名稱，他要麼必須對整個專案里頭所有鏈接到舊名的參考都加以編輯，要麼屈服於繼續維護使用舊名的殘株殘瓦介面。而該舊名的介面於內部調用該方法的新名。

㈤ 網上都說學軟體工程需要很強的數學邏輯思維能力，是指的什麼

一看就是不懂軟體工程和數學的胡扯的!!
軟體工程需要的數學比 計算機其他的都低,
軟體工程主攻編程, 做界面, 網頁什麼的, 邏輯需求不高!!

㈥ 軟體工程的結構化方法是什麼

結構化分析方法(Structured Method)是強調開發方法的結構合理性以及所開發軟體的結構合理性的軟體開發方法。結構是指系統內各個組成要素之間的相互聯系、相互作用的框架。結構化開發方法提出了一組提高軟體結構合理性的准則，如分解與抽象、模塊獨立性、信息隱蔽等。針對軟體生存周期各個不同的階段，它有結構化分析(SA)、結構化設計(SD)和結構化程序設計(SP)等方法。

結構化分析方法給出一組幫助系統分析人員產生功能規約的原理與技術。它一般利用圖形表達用戶需求，使用的手段主要有數據流圖、數據字典、結構化語言、判定表以及判定樹等。

結構化分析的步驟如下：①分析當前的情況，做出反映當前物理模型的DFD；②推導出等價的邏輯模型的DFD；③設計新的邏輯系統，生成數據字典和基元描述；④建立人機介面，提出可供選擇的目標系統物理模型的DFD；⑤確定各種方案的成本和風險等級，據此對各種方案進行分析；⑥選擇一種方案；⑦建立完整的需求規約。

結構化設計方法給出一組幫助設計人員在模塊層次上區分設計質量的原理與技術。它通常與結構化分析方法銜接起來使用，以數據流圖為基礎得到軟體的模塊結構。SD方法尤其適用於變換型結構和事務型結構的目標系統。在設計過程中，它從整個程序的結構出發，利用模塊結構圖表述程序模塊之間的關系。結構化設計的步驟如下：①評審和細化數據流圖；②確定數據流圖的類型；③把數據流圖映射到軟體模塊結構，設計出模塊結構的上層；④基於數據流圖逐步分解高層模塊，設計中下層模塊；⑤對模塊結構進行優化，得到更為合理的軟體結構；⑥描述模塊介面。

㈦ 軟體工程有哪些原則

1、量兩次，切一次(Measure twice and cut once)

如果你只能從這篇文章中學到一個原則且最重要的一個，那麼就是這個。 開發人員，架構師和經理人經常因為個人情緒、以及其他問題而難以集中注意力。

就工程師來說，這個原則意味著選擇正確的解決方案，選擇正確的方法來解決問題，選擇正確的工具來解決問題，對建立的解決方案必須充滿信心。

選擇這里意味著投入一些思考，找到必要的資源，組建合適的團隊，思考設計，思考方法，設定任務，控制結果，並為此承擔責任。 這就是「活在當下」。 我認為我自己還沒有準備好用正確的詞彙來描述它。

2、不要重復自己(Don't Repeat Yourself)

這是一個相當簡單但非常有用的原則，它說在不同的地方重復同樣的事情是非常糟糕的。 首先，它涉及到進一步支持和修改代碼的必要性。 如果某個代碼片段在程序中的幾個地方被復制，那麼很有可能出現兩種災難性的情況:

當對源代碼進行哪怕是很小的改動時，您需要在幾個地方更改相同的代碼。 這需要額外的時間、精力和注意力，而這件事件通常也非常不容易。

第一項緊隨第二項。 團隊中的其他開發人員可能會意外地錯過其中一個更改(只合並了控制系統中的分支) ，並將面對應用程序中隨後出現的一系列錯誤。 這些 bug 可能會讓您感到沮喪，因為您已經聽說這樣的 bug 似乎已經被修復了。

在這方面，有一個建議ーー如果在清單中發現任何代碼超過兩次，則應以單獨的方式來處置。 這是通用做法。 事實上，即使再次遇到重復的bug，您也應該考慮創建一個單獨的方法。

3、奧卡姆剃刀(Occam』s Razor)

這是一個非常普遍的想法，它來自於哲學編程。 這個原則得名於奧克姆的英國修道士威廉。 這一原則表明: 」沒有必要，不得增加實體」。

在工程學中，這一原則被解釋為: 沒有必要創建不必要的實體。 因此，首先考慮添加另一個方法 / 類 / 工具 / 流程等的好處不見得總是一個好主意。 畢竟，如果您添加了另一個方法 / 類 / 工具 / 流程等等，除了增加復雜性之外，您沒有得到任何其他好處，那還有什麼意義呢？

4、保持足夠簡單(Keep It Simple Stupid )

這是一個與上面非常類似的原則，但它的含義略有不同。 這個原則要求代碼必須盡可能簡單，不能有復雜的結構，否則會使代碼的調試和維護復雜化。

此外，對於另一個程序員來說，理解代碼的邏輯將會更加困難，這反過來也將需要額外的時間和精力。 這就是為什麼您應該始終嘗試使用簡單的構造來盡可能多地解決問題，而不需要使用大量的分支、深層嵌套和過度重載的類結構。

通過這樣做，你將使自己和同事的生活更加輕松，因為復雜性會產生錯誤。 記住 Peter Hintiens 說過的話: 「簡單永遠比功能好」。

5、你不會需要它（You Aren』t Gonna Need It ）

這是許多程序員都會遇到的問題。 從項目一開始就希望立即實現所有必要的(有時甚至是不必要的)功能。 也就是說，當開發人員從一開始就將所有可能的方法添加到類中並實現它們時，甚至可能在未來永遠不會使用它們。

因此，根據這個建議，首先，只實現您需要的東西，然後，如果必要的話，再擴展相應功能。 這樣，您就可以節省調試代碼的工作量、時間以及精力，而實際上這些代碼卻並不需要。

㈧ 軟體工程導論 什麼是需求分析在需求分析階段,建立目標系統的邏輯模型的具體做法

所謂"需求分析"，是指對要解決的問題進行詳細的分析，弄清楚問題的要求，包括需要輸入什麼數據，要得到什麼結果，最後應輸出什麼。可以說，在軟體工程當中的「需求分析」就是確定要計算機「做什麼」。
具體做法:首先確定目標系統與當前系統的邏輯差別；然後將變化部分看作是新的處理步驟，對功能圖及對象圖進行調整；最後由外及里對變化的部分進行分析，推斷其結構，獲得目標系統的邏輯模型。通常用數據流圖、數據字典和主要的處理演算法描述這個邏輯模型