軟體總體分析

㈠ 軟體需求的分析方法

軟體需求分析方法大體分為如下四類：結構化方法、面向對象方法、面向控制方法和面向數據方法。限於篇幅，將主要從結構化方法和面向對象方法以及RUP三個方面進行簡要的探討。 面向對象（Object Oriented, OO）的方法把分析建立在系統對象以及對象間交互的基礎之上，使得我們能以3個最基本的方法框架——對象及其屬性、分類結構和集合結構來定義和溝通需求。面向對象的問題分析模型從3個側面進行描述，即對象模型(對象的靜態結構)、動態模型(對象相互作用的順序)和功能模型(數據變換及功能依存關系)。需求工程的抽象原則、層次原則和分割原則同樣適用於面向對象方法，即對象抽象與功能抽象原則是一樣的，也是從高級到低級、從邏輯到物理，逐級細分．每一級抽象都重復對象建模(對象識別)一動態建模(事件識別)一功能建模(操作識別)的過程，直到每一個對象實例在物理(程序編碼)上全部實現為止。
面向對象需求分析(OORA)利用一些基本概念來建立相應模型，以表達目標系統的不同側面。盡管不同的方法所採用的具體模型不盡相同，但都無外乎用如下五個基本模型來描述軟體需求：
整體—部分模型：該模型描述對象(類)是如何由簡單的對象（類）構成的。將一個復雜對象(類)描述成一個由交互作用的若干對象(類)構成的結構的能力是OO途徑的突出優點。該模型亦稱聚合模型。
分類模型：分類模型描述類之間的繼承關系。與聚合關系不同，它說明的是一個類可以繼承另一個或另一些類的成分，以實現類中成分的復用。
類—對象模型：分析過程必須描述屬於每個類的對象所具有的行為，這種行為描述的詳細程度可以根據具體情況而定。既可以只說明行為的輸入、輸出和功能，也可以採用比較形式的途徑來精確地描述其輸入、輸出及其相應的類型甚至使用偽碼或小說明的形式來詳細刻畫。
對象交互模型：一個面向對象的系統模型必須描述其中對象的交互方法。如前所述，對象交互是通過消息傳遞來實現的。事實人對象交互也可看作是對象行為之間的引用關系。因此，對象交互模型就要刻畫對象之間的消息流。對應於不同的詳細程度，有不同的消息流描述分析，分析人員應根據具體館況而選擇。一般地，一個詳細的對象交互模型能夠說明對象之間的消息及其流向，並且同時說明該消息將激活的對象及行為。一個不太詳細的對象交互模型可以只說明對象之間有消息，並指明其流向即可。還有一種狀況就是介於此兩者之間。
狀態模型：在狀態模型中，把一個對象看作是一個有限狀態機，由一個狀態到另一狀態的轉變稱作狀態轉換。狀態模型將對象的行為描述成其不同狀態之間的通路。它也可以刻畫動態系統中對象的創建和廢除，並稱由對象的創建到對象的廢除狀態之間的退路為對象的生存期。
狀態模型既可以用狀態轉換因的圖形化手段，又可用決策表或稱決策矩陣的形式來表。 RUP（Rational Unified Process）是Rational公司開發和維護的過程產品。RUP是工程化的軟體開發過程，它提供了在開發機構中分派任務和責任的紀律化方法。RUP不僅僅是一個簡單的過程，而是一個通用的過程框架，可用於各種不同類型的軟體系統、各種不同的應用領域、各種不同類型的組織、各種不同的功能級別以及各種不同的項目規模。RUP的突出特點可以由以下三個關鍵詞來體現——用例驅動、以構架為中心、迭代和增量的。這些是RUP所特有的，也是同等重要的。構架提供了一種結構來指導迭代過程中的工作，而用例則確定了目標井驅動每次迭代的工作。
進行需求分析的基礎是要獲得用戶的需要，為了完成這一工作，必須建立業務模型，通過描述業務規則、業務邏輯，明確業務過程並對其進行規范、優化。對於一個系統，在建立業務模型時，應從3個方面來描述其特性：功能、行為、數據，對應於這些特性。 基於上述分析可知，結構化分析方法與面向對象分析方法的區別主要體現在兩個方面：
* 將系統分解成於系統的方式不同。前者將系統描述成一組交互作用的處理，後者則描述成一組交互作用的對象。
* 子系統之間的交互關系的描述方式不一樣。前者加工之間的交互是通過不太精確的數據流來表示的，而後者對象之間通過消息傳遞交互關系。
因此，面向對象軟體需求分析的結果能更好地刻畫現實世界，處理復雜問題，對象比過程更具有穩定性，便於維護與復用。

㈡ 軟體總體設計以什麼為基礎

總體設計階段必須以需求分析的結果（數據流圖＋數據字典）為基礎進行設計，以得到系統的框架。

總體設計的基本目的就是回答「概括地說，系統應該如何實現」這個問題，因此，總體設計又稱為概要設計或初步設計。

總體設計階段的另一項重要任務是設計軟體的結構，也就是要確定系統中每個程序是由哪些模塊組成的，以及這些模塊相互間的關系。

在總體設計階段分析員應該考慮各種可能的實現方案，並且力求從中選出最佳方案。

需求分析階段得出的數據流圖是總體設計的極好的出發點。

設想供選擇的方案的一種常用的方法是，設想把數據流圖中的處理分組的各種可能的方法，拋棄在技術上行不通的分組方法（例如，組內不同處理的執行時間不相容），餘下的分組方法代表可能的實現策略，並且可以啟示供選擇的物理系統。

㈢ 如何進行項目的硬體分析和軟體分析

本文結合自己的經驗，從實踐的角度，對項目軟體的分析工作從7個方面進行了闡述，並指出一些容易失誤的做法。希望能對從事分析工作的同仁有所參考。
這一點對於獲取真正的用戶要求非常重要。通常，客戶方會組織專工以上層次的人或在單位小有名氣的計算機能手來和開發方分析人員配合，共同整理需求。
應該對客戶方配合人員進行分類，層次化，使之和分析的各階段相對應。
分析的初期，即總體分析階段，需要得到整體意義上的輪廓需求，此時，應與客戶方總工以上層次的人員進行交流，這一層次的人，對未來的系統會有完整的描繪，可以劃分出子系統，及其之間的關系，這也是高級管理層對系統的期望。可以以此作為綱領性的文檔指導進一步的分析，並約束後續的分析過程，避免需求范圍漫無邊際的擴大；
專業系統分析階段，通常，客戶單位都會有專業分工，彼此之間既相互獨立，又會在某些點上發生聯系。此階段應與客戶方專工層次的人員進行深入的討論。這一層次的人，對自己的專業相當熟悉，對專業內的需求會非常到位，大都年富力強，有相當的閱歷和理解能力，甚至自己都可以繪制業務流圖，總結業務功能點。對他們應充分鼓勵，盡量調動其積極性；

系統關聯分析階段，在各專業系統得到充分分析的基礎上，緊接著就要理清它們之間的關系，這是提升需求檔次的關鍵階段，也是高級領導層和專工都關心的階段。通常，客戶單位都會有一些零散的軟體，如財務軟體，部頒軟體等，這些專業軟體都發揮著重要的作用，但都是些信息孤島，客戶會很自然的希望能把這些信息融合到整個系統中來，為更多的人所共享。同時，也希望數據能夠在各專業系統間順暢的流動，從而減少重復勞動，提高工作效率。此階段應把總工層和專工層召集到一起，共同理清系統間的介面。

經過這三個階段，對需求的描述將比較准確和完整。

㈣ 軟體工程裡面總體設計的原則是什麼

系統總體結構設計是要根據系統分析的要求和組主的實際情況來對新系統的總體結構形式和可利用的阻援進行大致的設計，是宏觀上的規劃。在總體設計階段應該將系統的物理元素劃分出來——程序、文件、資料庫、人工過程和文檔

㈤ 軟體的需求分析怎麼寫啊

軟體需求分析免費下載

鏈接:https://pan..com/s/1qNBwqvbRS5ziBSIeanLQAQ

需求分析也稱為軟體需求分析、系統需求分析或需求分析工程等，是開發人員經過深入細致的調研和分析，准確理解用戶和項目的功能、性能、可靠性等具體要求，將用戶非形式的需求表述轉化為完整的需求定義，從而確定系統必須做什麼的過程。

㈥ PROE軟體總體說明

ro/ENGINEER Foundation XE
Pro/CONCEPT 概念設計
Pro/ENGINEER 高級裝配
Pro/ENGINEER 互動式曲面設計II
Pro/ENGINEER Advance Render 高級渲染
Pro/ENGINEER Reverse Engineering 逆向工程

Pro/ENGINEER Mechanism Dynamics 機構動力學
Pro/ENGINEER Mechanica 結構和熱傳導分析
Pro/ENGINEER Fatigue Advisor 疲勞分析模塊
Pro/ENGINEER Behavioral Modeling 行為建模
Pro/ENGINEER Plastic Advisor 塑料顧問

Pro/ENGINEER Interface for CATIA II with ATB
Pro/ENGINEER Interface for CATIA V5 with ATB
Pro/ENGINEER Interface for I-DEAS
Pro/ENGINEER Interface for Unigraphics with ATB

Pro/ENGINEER Routed Systems Designer 布線系統設計工具
Pro/ENGINEER Piping Design 管道設計
Pro/ENGINEER Cabling Design 電纜敷設設計

Pro/ENGINEER Tool Design 模具型芯和型腔設計
Pro/ENGINEER Expert Moldbase 模架設計
Pro/ENGINEER Complete Mold Design 完整模具設計包
Pro/ENGINEER Prismatic and Multi-surface Milling 稜柱和多曲面銑削
Pro/ENGINEER Proction Machining 生產加工
Pro/ENGINEER Complete Machining 完整加工
Pro/ENGINEER Expert Framework 框架結構設計專家
Pro/ENGINEER Progressive Die 級進模設計
Pro/ENGINEER NC Sheetmetal 鈑金加工

Pro/TOOLKIT Customization API （二次開發）
GRANITE Interoperability Kernel （軟體內核）
Pro/INTRALINK 工作組數據管理

㈦ 軟體總體設計過程中需要遵守哪些基本原理

定義
軟體工程一直以來都缺乏一個統一的定義，很多學者、組織機構都分別給出了自己的定義：

Boehm：運用現代科學技術知識來設計並構造計算機程序及為開發、運行和維護這些程序所必需的相關文件資料。

IEEE：軟體工程是開發、運行、維護和修復軟體的系統方法。

Fritz Bauer：建立並使用完善的工程化原則，以較經濟的手段獲得能在實際機器上有效運行的可靠軟體的一系列方法。
目前比較認可的一種定義認為：軟體工程是研究和應用如何以系統性的、規范化的、可定量的過程化方法去開發和維護軟體，以及如何把經過時間考驗而證明正確的管理技術和當前能夠得到的最好的技術方法結合起來。

軟體工程學的內容
軟體工程學的主要內容是軟體開發技術和軟體工程管理．
軟體開發技術包含軟體工程方法學、軟體工具和軟體開發環境；軟體工程管理學包含軟體工程經濟學和軟體管理學。

軟體工程基本原理
著名軟體工程專家B.Boehm綜合有關專家和學者的意見並總結了多年來開發軟體的經驗，於1983年在一篇論文中提出了軟體工程的七條基本原理。
（1）用分階段的生存周期計劃進行嚴格的管理。
（2）堅持進行階段評審。
（3）實行嚴格的產品控制。
（4）採用現代程序設計技術。
（5）軟體工程結果應能清楚地審查。
（6）開發小組的人員應該少而精。
（7）承認不斷改進軟體工程實踐的必要性。
B.Boehm指出，遵循前六條基本原理，能夠實現軟體的工程化生產；按照第七條原理，不僅要積極主動地採納新的軟體技術，而且要注意不斷總結經驗。
軟體工程(SoftWare Engineering)的框架可概括為：目標、過程和原則。
(1)軟體工程目標：生產具有正確性、可用性以及開銷合宜的產品。正確性指軟體產品達到預期功能的程度。可用性指軟體基本結構、實現及文檔為用戶可用的程度。開銷合宜是指軟體開發、運行的整個開銷滿足用戶要求的程度。這些目標的實現不論在理論上還是在實踐中均存在很多待解決的問題，它們形成了對過程、過程模型及工程方法選取的約束。
(2)軟體工程過程：生產一個最終能滿足需求且達到工程目標的軟體產品所需要的步驟。軟體工程過程主要包括開發過程、運作過程、維護過程。它們覆蓋了需求、設計、實現、確認以及維護等活動。需求活動包括問題分析和需求分析。問題分析獲取需求定義，又稱軟體需求規約。需求分析生成功能規約。設計活動一般包括概要設計和詳細設計。概要設計建立整個軟體系統結構，包括子系統、模塊以及相關層次的說明、每一模塊的介面定義。詳細設計產生程序員可用的模塊說明，包括每一模塊中數據結構說明及加工描述。實現活動把設計結果轉換為可執行的程序代碼。確認活動貫穿於整個開發過程，實現完成後的確認，保證最終產品滿足用戶的要求。維護活動包括使用過程中的擴充、修改與完善。伴隨以上過程，還有管理過程、支持過程、培訓過程等。
(3)軟體工程的原則是指圍繞工程設計、工程支持以及工程管理在軟體開發過程中必須遵循的原則。

軟體工程必須遵循什麼原則
圍繞工程設計、工程支持以及工程管理已提出了以下四條基本原則：

(1)選取適宜的開發模型

該原則與系統設計有關。在系統設計中，軟體需求、硬體需求以及其它因素間是相互制約和影響的，經常需要權衡。因此，必需認識需求定義的易變性，採用適當的開發模型，保證軟體產品滿足用戶的要求。

(2)採用合適的設計方法

在軟體設計中，通常需要考慮軟體的模塊化、抽象與信息隱蔽、局部化、一致性以及適應性等特徵。合適的設計方法有助於這些特徵的實現，以達到軟體工程的目標。

(3)提供高質量的工程支撐

工欲善其事，必先利其器。在軟體工程中，軟體工具與環境對軟體過程的支持頗為重要。軟體工程項目的質量與開銷直接取決於對軟體工程所提供的支撐質量和效用。

(4)重視軟體工程的管理

軟體工程的管理直接影響可用資源的有效利用，生產滿足目標的軟體產品以及提高軟體組織的生產能力等問題。因此，僅當軟體過程予以有效管理時，才能實現有效的軟體工程。

軟體工程是指導計算機軟體開發和維護的工程學科。

採用工程的概念、原理、 技術和方法來開發與維護軟體，把經過時間考驗而證明正確的管理技術和當前能夠 得到的最好的技術方法結合起來，這就是軟體工程。

軟體工程強調使用生存周期方法學和各種結構分析及結構設計技術。它們是在七十年代為了對付應用軟體日益增長的復雜程度、漫長的開發周期以及用戶對軟體產品經常不滿意的狀況而發展起來的。人類解決復雜問題時普遍採用的一個策略就是「各個擊破」，也就是對問題進行分解然後再分別解決各個子問題的策略。軟體工程採用的生存周期方法學就是從時間角度對軟體開發和維護的復雜問題進行分解，把軟體生存的漫長周期依次劃分為若干個階段，每個階段有相對獨立的任務，然後逐步完成每個階段的任務。採用軟體工程方法論開發軟體的時候，從對任務的抽象邏輯分析開始，一個階段一個階段地進行開發。前一個階段任務的完成是開始進行後一個階段工作的前提和基礎，而後一階段任務的完成通常是使前一階段提出的解法更進一步具體化，加進了更多的物理細節。每一個階段的開始和結束都有嚴格標准，對於任何兩個相鄰的階段而言，前一階段的結束標准就是後一階段的開始標准。在每一個階段結束之前都必須進行正式嚴格的技術審查和管理復審，從技術和管理兩方面對這個階段的開發成果進行檢查，通過之後這個階段才算結束；如果檢查通不過，則必須進行必要的返工，並且返工後還要再經過審查。審查的一條主要標准就是每個階段都應該交出「最新式的」（即和所開發的軟體完全一致的）高質量的文檔資料，從而保證在軟體開發工程結束時有一個完整准確的軟體配置交付使用。文檔是通信的工具，它們清楚准確地說明了到這個時候為止，關於該項工程已經知道了什麼，同時確立了下一步工作的基礎。此外，文檔也起備忘錄的作用，如果文檔不完整，那麼一定是某些工作忘記做了，在進入生存周期的下一階段之前，必須補足這些遺漏的細節。在完成生存周期每個階段的任務時，應該採用適合該階段任務特點的系統化的技術方法──結構分析或結構設計技術。

把軟體生存周期劃分成若干個階段，每個階段的任務相對獨立，而且比較簡單，便於不同人員分工協作，從而降低了整個軟體開發工程的困難程度；在軟體生存周期的每個階段都採用科學的管理技術和良好的技術方法，而且在每個階段結束之前都從技術和管理兩個角度進行嚴格的審查，合格之後才開始下一階段的工作，這就使軟體開發工程的全過程以一種有條不紊的方式進行，保證了軟體的質量，特別是提高了軟體的可維護性。總之，採用軟體工程方法論可以大大提高軟體開發的成功率，軟體開發的生產率也能明顯提高。

目前劃分軟體生存周期階段的方法有許多種，軟體規模、種類、開發方式、開發環境以及開發時使用的方法論都影響軟體生存周期階段的劃分。在劃分軟體生存周期的階段時應該遵循的一條基本原則就是使各階段的任務彼此間盡可能相對獨立，同一階段各項任務的性質盡可能相同，從而降低每個階段任務的復雜程度，簡化不同階段之間的聯系，有利於軟體開發工程的組織管理。一般說來，軟體生存周期由軟體定義、軟體開發和軟體維護三個時期組成，每個時期又進一步劃分成若干個階段。下面的論述主要針對應用軟體，對系統軟體也基本適用。

軟體定義時期的任務是確定軟體開發工程必須完成的總目標；確定工程的可行性，導出實現工程目標應該採用的策略及系統必須完成的功能；估計完成該項工程需要的資源和成本，並且制定工程進度表。這個時期的工作通常又稱為系統分析，由系統分析員負責完成。軟體定義時期通常進一步劃分成三個階段，即問題定義、可行性研究和需求分析。

開發時期具體設計和實現在前一個時期定義的軟體，它通常由下述四個階段組成：總體設計，詳細設計，編碼和單元測試，綜合測試。

維護時期的主要任務是使軟體持久地滿足用戶的需要。具體地說，當軟體在使用過程中發現錯誤時應該加以改正；當環境改變時應該修改軟體以適應新的環境；當用戶有新要求時應該及時改進軟體滿足用戶的新需要。通常對維護時期不再進一步劃分階段，但是每一次維護活動本質上都是一次壓縮和簡化了的定義和開發過程。

㈧ 如何進行軟體系統分析

實體類通常指系統中需要持久化的類，代表系統中的核心概念。 軟體系統分析目前用的較多的方法就是魯棒（Robust）分析，也就是健壯性分析。 首先根據用例的描述設計系統的邊界類、實體類，和控制類。 一、邊界類 邊界類描述系統與角色的介面，通常是圖形用戶界面，通信協議、列印機介面、感測器和終端。最常見的就是窗體。那窗體中的各種控制項算不算呢？不算，窗體本身是最合適的邊界類，而其中的控制項就太細小了。 二、控制類 控制類表示系統的動態行為，處理主要的任務和控制流。簡單的說控制類指的就是業務邏輯，他通常獨立於實體類和邊界類，穩定性較好。 如果業務流程比較復雜，則需要單獨設計控制類。 通常一個控制類只和一個角色進行交互，這是基於最小化變更對系統的影響來考慮的。 三、實體類 四、關系限制 不同的類之間關系的建模有些是必要的，有些則是需要避免的。 邊界類－＞實體類允許：因為邊界對象可能需要在這個邊界對象的各個操作之間對某些實體對象進行跟蹤。 邊界類＜-＞控制類避免：因為關系是短時間存在的，所以沒必要建模。 邊界類＜-＞邊界類允許 控制類＜-＞控制類避免：因為關系是短時間存在的，所以沒必要建模。 控制類-＞實體類允許 實體類＜-＞實體類允許 實體類-＞邊界類不允許 實體類-＞控制類不允許 實體類對象的生存期一般都很長；而控制類對象和邊界類對象的生存期則很短。正是由於這些類的生存期相差如此之大，所以在這些類之間建立關聯關系是不可取的。 五、類設計的原則 １、不同的類之間如果存在相似的職責，考慮重用現有類，如果沒有有重用可能的類，才考慮建立新的類。 ２、如果一個類的兩個職責之間互不相關，考慮將這個類分成兩個。並更新相應的協作關系。 ３、如果一個類只有一項職責，那麼需要重新考慮該類存在的必要性.

㈨ 軟體系統的總體結構

鑽孔設計與軌跡動態監控CAD軟體系統主要包括鑽孔設計和鑽孔軌跡動態監控兩大模塊。鑽孔設計模塊包括鑽孔結構設計、初級定向鑽孔設計與受控定向鑽孔軌跡設計、鑽探工程綜合圖的繪制、鑽孔設計書及鑽孔地質柱狀圖的自動生成等子模塊;鑽孔軌跡動態監控模塊包括鑽孔軌跡在地下空間的精確定位、鑽孔軌跡自然彎曲規律分析、鑽孔設計軌跡與實際軌跡的對比及根據鑽孔實際軌跡偏差跟蹤設計鑽孔糾斜或造斜的軌跡控制參數等子模塊。軟體系統的總體結構見圖8-3,設有9個應用功能模塊和1個資料庫模塊。為進一步增強鑽孔軌跡直觀顯示效果,軟體系統還設置有鑽孔軌跡三維動態演示。

為方便野外工作人員使用,軟體功能模塊採用外部彼此獨立、內部緊密聯系的總體結構方式,系統各模塊功能目標明確,操作步驟採用文字空格游標和功能鍵提示方式。各功能模塊均設計有數據錄入界面,並可以將錄入的數據保存在統一的資料庫文件中便於相互調用。

圖8-3 多功能定向鑽探軟體系統總體結構圖