軟件工程一般用什么畫圖軟件？軟件工程畫流程圖、數據流圖那些的話，老一點軟件有Rationalrose，新點的話是可以用StarUML也可以真接用網頁版的ProcessOn（CAD啥的是建筑、機械等領域

軟件工程一般用什么畫圖軟件？

軟件工程畫流程圖、數據流圖那些的話，老一點軟件有Rationalrose，新點的話是可以用StarUML也可以真接用網頁版的ProcessOn（CAD啥的是建筑、機械等領域【可以使用】的工業(yè)軟件，和軟件工程做項目管理有太大區(qū)別的行啦？

用例需求分析方法采用的是？

實際用例，英文名稱UseCase，是對系統(tǒng)該如何不對外界請求的描述，是一種按照用戶的使用場景來獲取需求的技術，簡而言之是單獨具體描述需求的流程。它是再朝到了最后的用戶另外領域專家的，不需要由業(yè)務人員與開發(fā)人員相互創(chuàng)造，同樣的又是面向對象語言和正向設計的。

在1986年，IvarJacobson，UML和RUP（統(tǒng)一軟件開發(fā)過程）的不重要貢獻者，提出了用例的概念。所以用例都是UML規(guī)范中的一種標準化的需求表達，RUP是以業(yè)務應用程序來驅動。

宣布的用例估計除開：用例名、總體概述、范圍、級別、主參與者、項目相關人員和利益、前置要件、最大時保證、成功了能保證、觸發(fā)時事件、主最終場景、擴大場景和咨詢信息等等。并并非所有的場景都不需要具體解釋完整的用例信息，相同的側重點不同，可取其中相同部分來分成求完整的方法。

數倉建模全流程？

1、建模流程

當然那就是業(yè)務模型-a8概念模型-a8邏輯模型-r26物理模型的那樣的話一個流程，下面我們請解釋再看看各個模型階段都什么好

業(yè)務建模(需求溝通)

參照業(yè)務部門參與劃分，縷清部門之間的關系，然后將各個部門的具體一點業(yè)務程序化，與業(yè)務部門開會協商好出需求的指標、需要保存年限、維度等等。

總體來講，那是要清楚他們是需要哪些指標包括他們能需要提供哪些數據。

業(yè)務建模的時間最長，而且與公司實際中的業(yè)務環(huán)境密不可分，所以在這里要依據什么求實際生產環(huán)境和業(yè)務需求確認好數據倉庫不使用的工具和平臺。

主要幫忙解決業(yè)務層面的分解和程序化。弄清系統(tǒng)邊界，判斷好主題域

1

1

但，業(yè)務建模階段其實是一次和業(yè)務人員梳理業(yè)務的過程，在這個過程中，不僅僅能幫助我們技術人員更好的理解業(yè)務，一方面，也都能夠突然發(fā)現業(yè)務流程中的一些不合理的環(huán)節(jié)，細加可以改善和改進之處。

概念建模|領域建模(繪圖想好怎么做)

將業(yè)務模型抽象化，分組合并相似的概念，明確化概念，抽像出實體與實體之間的直接聯系，理清楚各組概念之間的聯系。

說白了那就是畫圖，把指標是需要的哪些數據裸芯片到一個實體里，實體與真實之間的關聯等等用ER圖表示出去。

先畫出局部ER圖，之后再綜合考畫出全局ER圖。

主要是對業(yè)務模型通過抽象的概念全面處理，生成領域概念模型

1

1

在損壞數據庫基礎上建立了一個比較壯大完備的模型，因為數據倉庫是對原有數據庫系統(tǒng)中的數據參與集成主板和重組而無法形成的數據整數集，所以數據倉庫的概念模型設計，簡單要對損壞數據庫系統(tǒng)略加結論表述，看在損毀的數據庫系統(tǒng)中“有什么”、“怎么樣才能組織的”和“如何分布的”等，然后就來判斷應當要如何組建數據倉庫系統(tǒng)的概念模型。

數據倉庫的概念模型是面向企業(yè)全局成立的，它為板載顯卡無論是各個再朝應用的數據庫的數據需要提供了統(tǒng)一規(guī)定的概念視圖。

概念模型的設計是在較高的抽象層次上的設計，并且組建概念模型時你不考慮到具體詳細技術條件的限制。

領域概念建模是句子修辭了實體建模法，從紛擾的業(yè)務表象背后按照實體建模法，抽象的概念出實體，事件，只能證明等抽象的實體，從而找出業(yè)務表象后抽象實體間的相互之間的關聯性，能保證了我們數據倉庫數據聽從數據模型所能提升的一致性和關聯性

邏輯建模(表設計)

將概念模型實體化，具體一點判斷概念對應的屬性，事件考慮到事實屬性，維度考慮維度屬性。

總體應該是建表，前面已經畫出了關系圖，這里只需將表里頭有哪些字段考慮到進去就這個可以，如果沒有是事實表就判斷事實字段和業(yè)務主鍵，假如是維度表就考慮維度屬性，SCD策略等等。在這里要考慮數據粒度，如果沒有多個指標都應用一個字段，則取粒度最小的指標。如果不是不確定指標的量度，則取200毫秒另外粒度。

物理建模(建表)

綜合考現實就是現實的大數據平臺、采集工具、etl工具、數倉組件、性能要求、管理具體的要求等多方面因素，設計什么出詳細的項目代碼，能夠完成數倉的壘建。

2、建模的過程

假設我們現在在統(tǒng)合一張訂單表

從多個維度參與統(tǒng)計組合，無法形成多維度數據集，來從多個角度仔細業(yè)務過程的好壞

1

1

中,選擇業(yè)務過程

確認哪些業(yè)務處理流程是數據倉庫應該是覆蓋的，是維度方法的基礎。因此，建模的第一個步驟是具體解釋必須建模的業(yè)務流程。比如，需要了解和結論一個零售店的銷售情況，這樣與該零售店銷售相關的所有業(yè)務流程都是不需要了解的。是為詳細解釋業(yè)務流程，可以簡單啊地使用純文本將相關內容記錄下去，或則不使用“業(yè)務流程建模上標”（BPMN）方法，也是可以使用統(tǒng)一建模語言（UML）或其他類似的方法。

業(yè)務過程就是需要那種業(yè)務場景下再產生的訂單表(劃分到那個業(yè)務線和數據域)

業(yè)務過程就是用戶下單付款的訂單記錄表

你選數據域

申明粒度

粒度應該是最后確認一條有記錄屬於的含義或者是明確化到做何程度(一條記錄代表一個訂單肯定多個訂單，如拼團的時候團長的單)

在中,選擇維度和事實前前提是聲明粒度，只不過每個候選維度或事實要與定義的粒度保持一致。在一個事實所按的所有維度設計中強制什么制度粒度一致性是只要數據倉庫應用性能和易用性的關鍵。

從變量的業(yè)務流程獲取數據時，上古時代粒度是最少級別的粒度。我建議你從原始粒度數據就開始設計，畢竟原始記錄能夠行最簡形矩陣不能預期的用戶網站查詢。匯總后的數據粒度對優(yōu)化查詢性能很有用，但這樣的粒度一般說來不能不滿足對細節(jié)數據的查詢需求。

有所不同的事實可以不有完全不同的粒度，但同樣的事實中最好不要使用中多種完全不同的粒度。維度模型建立起結束之后，另外很有可能而且某些了新的信息，而返回到這步如何修改粒度級別。

確認維度

維度的粒度可以和第二步所聲明的粒度相同。

維度表是事實表的基礎，也那就證明了事實表的數據是從哪里再采集來的。

有名的維度大都名詞，如日期、商店、庫存等。維度表存儲位置了某一維度的所有相關數據，的或，日期維度估計以及年、季度、月、周、日等數據。

去確認事實

這一退能識別數字化的度量，近似事實表的記錄。它是和系統(tǒng)的業(yè)務用戶融洽相關的，是因為用戶正是我按照對事實表的訪問獲取數據倉庫存儲文件的數據。大部分事實表的度量全是數字類型的，可累加，可計算，如成本、數量、金額等。

3、模型設計什么的思路

業(yè)務需求驅動，數據驅動，構造數據倉庫有兩種一是從上向下，一是從下至上。

從上而下

BillInmon先生推崇“由下至上”的，即一個企業(yè)成立僅有的數據中心，就像一個數據的倉庫，其中數據是當經過整合、經清洗、去掉臟數據的、標準的，還能夠可以提供統(tǒng)一的視圖。要建立這樣的數據倉庫，并不從它不需要支持什么哪些應用何練起，只不過是要從整個企業(yè)的環(huán)境從哪里入手，講其中的概念，應該要有什么樣的數據，達成默契概念完成整；

從下至上

RalphKimball先生被推崇“由下”的，他懷疑建設數據倉庫肯定遵循不好算的應用需求，加載需要的數據，不是需要的數據千萬不能加載到數據倉庫中。這種建設周期較長，客戶也能迅速注意到結果。（根據客戶的需求，需求要什么就做什么）

4、模型落下時利用

聽從命名規(guī)范創(chuàng)建戰(zhàn)隊表

的新生成氣體維表和事實表的代碼

接受代碼邏輯測試，不驗證數據加工邏輯的正確性代碼發(fā)布，參加調度并配置相對應的質量監(jiān)控和報警機制