順序圖數據存儲_怎麼編寫用戶業務需求分析

1. uml 順序圖中如何找控制類如酒店管理員要對酒店添加數據（房間數和房型）

一般來說，一個用例對應一個控制類
添加數據的順序圖，從左向右假設是
對象 —— 邊界類 —— 控制類 —— 實例類
管理員數據輸入界面對數據的處理存入資料庫記錄

管理在系統界面輸入要添加的數據，確定後，控制類對數據進行檢查等處理，當數據無誤後，存入數據形成實例對象。

控制類，在用例中，出去實體類，邊界類，很簡單就是控制類了唄

2. 怎麼編寫用戶業務需求分析

需求分析
格式
1 引言
1.1 編寫目的
【說明】目標：對用戶的需求進行收集、整理與分析，弄清楚系統究竟要「干什麼」及「由誰干」，並用合乎規范的文字及圖表予以描述。不需要說明「怎麼干」，因為那是設計階段的事情。有關文字與圖表應盡量讓用戶便於理解。
預期讀者：用戶方的相關業務人員、雙方的開發人員和系統維護人員。
作用：實現開發方與用戶方的雙向溝通，是把業務需求計算機化的關鍵步驟。
為下一階段的概要設計工作提供依據。當用戶的需求發生變更時，應添寫補充說明；如變動過大可形成新版本。
軟體需求說明（Software Requirements Specification）的主要作用為：
 為用戶方與開發方建立共同協議奠定基礎。
 提高開發效率、強化進度控制。
 為項目的的評測與驗收提供依據。
 便於移植。
 作為系統不斷提高的基礎。
1.2 編寫背景
1.2.1 系統名稱及版本號
【說明】形如「網銀三期***系統V3.0.0」。其中，版本號的格式為「XX.XX.XX」，X為阿拉伯數字，左「0」可省略。

1.2.2 使用者
【說明】適應對象和范圍。主要指預期讀者，也供有關領導審閱。

1.2.3 與其它系統的關系
【說明】在用戶現有的及預期的整個應用系統中，給本系統准確定位。用示意圖及相應的文字予以說明。

2 用戶的基本情況
2.1 系統建設背景
【說明】項目背景與依據、現有基礎、項目規模、預期目標等。可繁可簡，格式自定。

2.2 組織機構與職能
【說明】用層次示意圖及相應文字表示(如果需要開發的系統與部門沒有直接依賴關系此節可省略,本章隨後的小節數將順次減1)，

加註：組織機構的層次數、數目、各個機構的職能簡述。

2.3 用戶特點
【說明】所在行業特徵、操作人員與系統維護人員的數量、學歷與水平、數據量大小、使用頻度等。
2.4 用戶業務分析
【說明】在本部分，希望系統分析人員能夠對用戶業務現狀進行分析、對用戶對本系統的未來發展方向作出一定的預測等。以便設計人員對業務及其發展有所了解，增強系統設計的前瞻性。
2.5 計算機應用現狀
【說明】可繁可簡，格式自定。
3 業務需求
3.1 項目概述
【說明】
第一、指明項目的開發意圖、應用目標（總目標、分期目標）、作用范圍、預期效益等。
第二、指明在輸入信息轉變為輸出信息的過程中，為了滿足用戶的業務需求，應用軟體必須完成的基本功能(採用自然語言敘述)。但此時不要求對基本功能進行分解。
第三、如果本系統與其他系統相關聯，則應確定本系統的基本功能邊界（可採用圖示+文字說明的形式，用藍色標示出本系統的功能，用綠色標示出相關系統的功能）。
3.2 約束條件
3.2.1 費用約束
【說明】預計投資金額概算、其中軟硬體費用的比例、資金分期到位計劃。

3.2.2 進度約束
【說明】預計完成日期、分步實施期限。

3.2.3 其它約束
【說明】場地面積限制、通信設施基礎、其它干擾因素。
注意：任何計算機系統都不是包羅萬象的；用戶自身的能力也是有限的。輕諾必寡信。故應特別指出：由於哪些條件的約束，本系統不能滿足哪些業務需求與系統需求。
本章主要介紹項目的總體業務功能,要求站在客戶的角度把握系統需求.
3.3 性能需求
【說明】依據ISO9000標准及我們的理解，下面列出了軟體的6組性能，共涵蓋21個子特性。這些性能/子特性的相對重要性並不是等同的。編寫時，可以基於具體項目的實際需求，對下述標題或內容進行取捨/側重。事實上不可能做到面面俱到，往往要作出某些折中。
本節說明系統在性能方面的預期目標，不要求提供實現上述目標的具體實施方案。

3.3.1 功能性
【說明】指與軟體實現的各項功能及其指定性質有關的一組屬性。這些功能都是滿足規定需求和潛在需求所必需的。它包括5個子特性：
適用性：與指定業務所需各項功能的實現及其適合程度有關的一些軟體屬性。
准確性：與保證正確（或符合要求的）結果（或效果）有關的一些軟體屬性。
互操作性：與軟體同一些指定系統交互作用能力有關的一些軟體屬性。
復合性：使軟體遵守相關的標准、約定/法律或類似規定有關的一些軟體屬性。
保密安全性：與針對蓄意（或無意）而非法存取程序和數據的預防能力有關的一些軟體屬性。這里主要指的是保護軟體的要素，旨在防止各種非法訪問、修改、破壞、泄密及感染計算機病毒等。
3.3.2 可靠性
【說明】指在規定的條件和期限內，與軟體保持其性能水平有關的一組軟體屬性。
成熟性：與軟體故障引起的失誤頻率有關的一些軟體屬性。
容錯性：在軟體故障發生或其規定界面被破壞的情況下，與軟體仍能保持規定性能水平的能力有關的一些軟體屬性。
可恢復性：在失效的情況下、在限定的期限和強度范圍內，與軟體重建性能水平並恢復直接受影響的數據的能力有關的一些軟體屬性。
3.3.3 易使用性
【說明】指與規定用戶（或潛在用戶）使用軟體所需的努力程度、對這種使用所做的評估有關的一組軟體屬性。它包括3個子特性：
易理解性：與用戶為理解其邏輯概念及適用范圍需做的努力有關的一些軟體屬性。
易學習性：與用戶學習其應用（例如操作控制、輸入、輸出）需做的努力有關的一些軟體屬性。
易操作性：與用戶操作及運行控制需做的努力有關的一些軟體屬性。

3.3.4 高效性
【說明】指在特定的運行環境中，描寫軟體性能水平與所用的資源量之間關系的一組軟體屬性。它包括兩個子特性：
時間特性：在完成軟體功能時，與響應時間、處理時間、吞吐率有關的一些軟體屬性。
資源特性：在完成軟體功能時，與所用資源量及佔用時間有關的一些軟體屬性。

3.3.5 可維護性
【說明】與對軟體進行指定的修改所需的工作量有關的一組軟體屬性。它包括4個子特性：
易分析性：與診斷故障、確定失敗原因、在需要修改的部位進行標識等所做努力有關的一些軟體屬性。
易修改性：與實施修改、排除故障、環境改變所做努力有關的一些軟體屬性。
穩定性：與修改的意外影響帶來的風險有關的一些軟體屬性。
易測試性：與對經過修改的軟體進行檢驗/確認做努力有關的一些軟體屬性。
3.3.6 可移植性
【說明】指軟體從一個環境轉移的另一個環境時，與其適應能力有關的一組軟體屬性。它包括4個子特性：
適應性：除已有手段外，無須採用其它措施或手段，軟體便應能適應指定的環境。與這種能力有關的一些軟體屬性稱為適應性。
易安裝性：在指定環境內，與安裝軟體所需努力有關的一些軟體屬性。
一致性：軟體從一個環境轉移的另一個環境時，應符合一定的標准和約定。與這種符合程度有關的一些軟體屬性，稱為一致性。
易替換性：有時會出現這種需求：在某個其它軟體的運行環境下，要用本軟體來置換那個軟體。與這種可能性及所需努力有關的一些軟體屬性。

4 用戶需求
【說明】本章下面介紹的是一般規模軟體系統的書寫格式。在書寫過程中可能要以業務名稱劃分小節(例如:5.1 代收電話費)。每個業務小節包含兩個部分：第一部分是對此業務中角色和功能的定義；第二部分是此業務的圖形分析方法。
在本章開始未分節的部分，應當繪制一個總體結構圖，依據這個總體結構圖進行一個總體描述，使得閱讀者對下面分節描述的各個功能形成一個整體印象。這個總體結構圖不一定是指在ROSE工具中繪制的用例總圖，而是根據需要可以選擇包括「用例總圖」、「適當級別的數據流圖」、「IDFF圖」、「數據流程圖」或其他專業圖形分析圖示等。
每個小節中的第二部分採用rational公司的rose2000作為工具繪制用例（use case）圖和順序（sequence）圖。在這里採用rose工具是作為繪圖分析工具使用，對需求的描述和分析並不代表我們的設計採用UML標准和面向對象的設計，具體分析人員應當根據實際的用戶需求描述繪制順序圖，而並不著重考慮對象的分析限制。
需求變更的處理原則：獲得批準的需求變更，需要在《需求分析》中有所體現。增加的需求，需直接從本章尾部順序添加，相應的小節編號也需要依次增加。例如：本章小節為5.1—5.5，增加的需求小節編號則為5.6。刪除的需求，不需要將相應需求直接從《需求分析》中刪除，而只需在相應需求小節上註明刪除，並標出《需求變更單》編號。修改的需求，可在相應的需求小節直接修改。所有對《需求分析》內容的修改必須在修改歷史中留有記錄。
4.1 業務名稱1
4.1.1 角色/功能定義
【說明】根據會議紀要、小組討論，確定系統中的角色（角色可以為外部系統或系統用戶），和功能，並給出相應的定義或解釋。

4.1.2 圖形分析
【說明】本節主要描述相應業務的用例圖和順序圖的內容
統一建模語言（UML）是一個通用的可視化建模語言，用於對軟體進行描述、可視化處理、構造和建立軟體系統製品的文檔。它記錄了對必須構造的系統的決定和理解，可用於對系統的理解、設計、瀏覽、配置、維護和信息控制。UML適用於各種軟體開發方法、軟體生命周期的各個階段、各種應用領域以及各種開發工具，是一種總結了以往建模技術的經驗並吸收當今優秀成果的標准建模方法。
在本需求模板中我們選取的是UML視圖來輔助進行圖形需求分析，選用Rational公司的ROSE工具完成。在需求分析過程需要完成結構分類中的用例分析，繪制用例圖；對用例的動態行為進行交互分析，描述執行系統功能的各個角色之間相互傳遞消息的順序關系，繪制順序圖。
在這里請作者將製作的用例圖和順序圖拷貝到本文檔中。
基本成分：用例（use case）、用例視圖（use case view）、角色（role、actor）、順序圖（sequence diagram）、協作圖（collaboration diagram）。
模板和命名：為更好地使用ROSE圖形分析工具，我們設定一個基本的分析模板，文件名為lansoftmdl.mdl。該文檔涉及項目開發的需求、概設和詳設3個階段，在需求階段主要完成模板中用例視圖（use case view）規定完成的部分。在項目中使用該模板後生成的mdl文件納入文檔的配置管理，具體命名參照SEMP體系的命名規定。修改歷史記入文檔開始部分的「mdl文檔修改歷史表」中。

【ROSE使用要求】
1、要求使用ROSE工具時必須完成模板和使用要求中規定完成的內容，在完成基本內容的基礎上，可以根據需要增加部分內容。
2、在公司沒有購買確定版本的ROSE以前，使用的ROSE版本應在項目開始前在項目組規定好，並由配置管理員負責配置。
3、在用例視圖（use case view）中建立一個名稱為main的主用例圖（use case diagram），具體內容應當包括所有用例圖的全部內容，具體應用時還可以根據情況建立多個用例圖（use case diagram）。
4、在用例視圖中請採用中文對所有的角色（actor\role）進行命名。其中角色必須在雙擊該對象圖後，詳細填寫該角色的描述（documentation）和該角色代表的角色數量（detail-multiplic）。
5、在用例視圖中請採用中文對所有的用例（use case）進行命名。命名中在一般的中文概括前應增加代表本節編號的部分，如「1.用戶認證」，順序編號。其中用例必須在雙擊該對象圖後，詳細填寫該用例的描述（documentation）。
6、在每個用例下必須組織建立相應的順序圖（sequence diagram），對於一個用例可以包含多個順序圖（sequence diagram），各個順序圖（sequence diagram）的命名需在一般的中文概括前增加代表本節編號的部分，如「1.1用戶認證」，順序編號，其中第一個1代表所屬的用例，第二個1代表順序圖（sequence diagram）的編號。產生順序圖的數量根據說明需求的具體要求設定。其中順序圖中的各個對象消息（object message）必須在雙擊該對象圖後，詳細填寫該對象消息（object message）的描述（documentation）。
4.1.3 數據存儲需求
【說明】根據會議紀要、小組討論，對於在需求調研中有關的數據實體對象或數據實體信息，應當根據需要提出可能數據類型和數據長度以及單位量綱的記錄或建議。

5 運行環境
【說明】本章只提出運行環境的邏輯結構，物理結構將在《概要設計說明書》中給出。
容許提出幾種可選方案。

5.1 硬體平台
【說明】指出本應用軟體適用的主機/伺服器與終端/工作站的技術指標、基本配置、介面特點、特殊約定等。
應盡可能地說明上述設備在各級用戶機構預計的分布狀態。
5.2 網路平台
【說明】選型標准、網路類型、基本部件、介面情況、對綜合布線的要求、限制條件等。應畫出網路（廣域網、區域網）的拓撲結構圖，說明後者對前者的接入方式。

5.3 軟體平台
【說明】操作系統的名稱、生產廠家、版本號等。
資料庫的名稱、生產廠家、版本號等。
資料庫設計工具的名稱、生產廠家、版本號等。
網路通信協議的名稱、生產廠家、版本號等。
前端開發工具的名稱、生產廠家、版本號等。
測試開發工具的名稱、生產廠家、版本號等。
現場運行時需要的工具軟體的名稱、生產廠家、版本號等。
配置管理工具軟體的名稱、生產廠家、版本號等。
6 附錄
【說明】列出基礎素材中的文件、報表、單據等的樣張，再附上必要的注釋。
如果條件成熟，可以把數據字典（data dictionary）作為附件列於後。
6.1 電子文檔編寫方式與使用工具
【說明】編寫要求、工具名、版本號、操作系統平台。使用多種工具時，應分別說明。形如：
Microsoft Word 97 for Windows 95/98
Power Designer 6.0 for Windows 95/98
Rational Rose 98 for Wintel
Visio或Power Point 97 for Windows 95/98

6.2 定義說明與符號
【說明】包括對專用術語及縮略語的解釋、所用到的圖（如use case、sequence圖）之圖符的表示與解釋等。

6.3 參考資料
【說明】格式：作者，[版本號，]資料來源，日期 [，起止頁號] 。其中，《質量保證計劃》是必選的參考資料。

6.4 有關表格清單
【說明】列出用戶提供的素材，加上我們積累的有關文件，作為系統分析的基礎。在這里除系統內部沒有用戶參與的需求分析工作外，必須包括一個以上的用戶訪談紀要、用戶確認簽名文件以及用戶訪談計劃等文件的列表。在列表中的文件應當作為附件與需求文檔共同納入配置管理

3. 面向對象中的用例圖與結構化方法中的數據流圖dfd有何異同

用於需求建模的方法有很多種，最常用的包括數據流圖（DFD）、實體關系圖（ERD）和用例圖（Use Case）三種方式。DFD作為結構化系統分析與設計的主要方法，已經得到了廣泛的應用，DFD尤其適用於MIS系統的表述。DFD使用四種基本元素來描述系統的行為，過程、實體、數據流和數據存儲。DFD方法直觀易懂，使用者可以方便地得到系統的邏輯模型和物理模型，但是從DFD圖中無法判斷活動的時序關系。圖2描述的是某個項目的DFD示意圖。
ERD方法用於描述系統實體間的對應關系，需求分析階段使用ERD描述系統中實體的邏輯關系，在設計階段則使用ERD描述物理表之間的關系。需求分析階段使用ERD來描述現實世界中的對象。ERD只關注系統中數據間的關系，而缺乏對系統功能的描述。如果將ERD與DFD兩種方法相結合，則可以更准確地描述系統的需求。
在面向對象分析的方法中通常使用Use Case來獲取軟體的需求。Use Case通過描述「系統」和「活動者」之間的交互來描述系統的行為。通過分解系統目標，Use Case描述活動者為了實現這些目標而執行的所有步驟。Use Case方法最主要的優點，在於它是用戶導向的，用戶可以根據自己所對應的Use Case來不斷細化自己的需求。此外，使用Use Case還可以方便地得到系統功能的測試用例。
傳統方法：（過程+實體）
把系統看作一個過程的集合體。
過程與數據實體交互。過程接受輸入並產生輸出。

OO方法：（對象+消息）
把系統看成是一個相互影響的對象集。
對象之間通過發送和響應消息進行交互。

從過程到OO不是簡單地一個升級。
傳統方法強調「過程模型+實體模型」。
OO方法強調「對象模型+對象交互」。
不可能將傳統方法的思維應用於OO方法中。

傳統方法用「數據流圖+數據字典」來描述系統需求。
數據流圖包括外部實體、過程、數據流和數據存儲等DFD部件。
數據字典則是對DFD部件的定義，包括過程描述、數據流定義、數據元素定義和數據存儲定義。

OO方法用5種圖來定義系統需求：類圖+用例圖+協作圖+順序圖+狀態圖。
這些圖相互聯系，有時並不是這些圖都要用到。

4. FSD是什麼意思呀

FSD是一個多義詞，所代表的意思分別是：

1、FSD指的是設計文檔的英文縮寫：

FSD的全稱是Functional Specifications Document，功能詳細說明，定義產品功能需求的全部細節。FSD一般通過一張張的截屏和一條條功能點來定義產品規格。這是一份可以直接讓工程師創建產品的文檔。

2、FSD指的是滿刻度偏轉的英文縮寫：

FSD採用最大量程試觸法選擇合適的量程。試觸時，閉合開關，用線頭接觸電流表的最大量程的接線柱並迅速移開，觀察指針偏轉的范圍，如果超過最大量程，就應換用更大量程的電流表，否則該電流表將被燒壞。

3、FSD指的是系統驅動的英文縮寫：

FSD的全稱是File System Driver，指的是文件系統驅動程序，分為本地FSD和遠程FSD。

4、FSD指的是女性性功能障礙的英文縮寫：

女性性功能障礙是指女性性反應周期一個或幾個環節發生障礙，或出現與性交有關的疼痛。女性性功能障礙的診斷主要依靠臨床判斷。

(4)順序圖數據存儲擴展閱讀：

遠程FSD允許用戶通過網路訪問遠程計算機上的數據。由兩部分組成，客戶端FSD和伺服器端FSD。客戶端FSD首先接收來自應用程序的I/O請求，並轉換為網路文件系統協議命令，然後通過網路發送給伺服器端FSD。

Windows文件系統的有關操作都是通過FSD完成的，比如顯示文件I/O是應用程序通過I/O介面函數如CreateFile，ReadFile，WriteFile等來訪問文件。高速緩存延遲寫，此線程定期對高速緩存中已被修改的頁面進行寫操作。

5. 如何進行管理信息系統需求調研分析

進行管理信息系統需求分析:
1、明確系統管理目標;
2、確定信息系統總體結構;
3、明確系統的模塊構架;
4、明確系統實施方案.

6. 軟體設計師考試考點分析與真題詳解的目錄

比特培訓-24期(2017年上)-軟體設計師培訓課件，免費下載

鏈接:https://pan..com/s/1ewtz01HsJL16rSVRzm3-7A

提取碼:2ocw

7. 如何使用powerdesigner創建順序圖活動圖用例圖域模型資料庫模型

創建用例圖，打開PD,操作如下：
文件---建立新模型（New Model）---分類（Categories）---商務（Business）---用例圖定義（Use Case Definition），然後通過面板上的小人符號、用例符號處理即可。如果要調整線型，工具----顯示參數選擇----格式Format----Use Case Association 定義線型為最後一種S型即可由曲線變成直線。
創建活動圖、組件、順序圖：分類（Categoriess）----應用程序（Application），利用模型面板來畫即可：UML Activity Diagram、UML Component Diagram、UML Sequence Diagram。

創建資料庫模型，製作ER圖：分類（Categoriess）----信息（Information），點擊第一個圖例創建Conceptual Data，畫出Entity實體和關系Relationship。

注意：要理解CDM/PDM/OOM/BPM 分別指的含義，可以相互轉換。
CDM：概念數據模型
PDM：物理數據模型
OOM：面向對象模型
BPM：企業流程模型
如果要做軟體開發，請多用OOM。
當然，也可以用CDM/PDM，通過菜單「工具」可以互相生成不同的模型。
具體請查找PowerDesigner 15 使用手冊，有問題QQ幫你。320207501

順序圖數據存儲

與順序圖數據存儲相關的內容