面向對象需求分析方法

㈠ 面向對象需求分析中的典型活動有哪些

你好，非常高興為你解答：

面向對象軟體開發的方法有：a，面向對象分析（OOA）b,面向對象設計(OOD）c,面向對象實現（00I）d，面向對象測試（OOT）,e，面向對象維護（OOM）這幾個主要大步驟。下邊我們就從面向對象的角度來學習UML的相關圖。這里介紹面向對象分析階段的用例圖和活動圖。

面向對象分析階段，我們要明確系統的職責，范圍和邊界；確定軟體的功能和性能；構建需求模型（用例模型）。
希望可以幫助到你！

㈡ 面向對象軟體工程（至少3種）中的OOA和面向數據流（至少3種）中的需求分析，要使用哪些需求分析方法可以達

OOA與數據流分析：
在客戶與程序員溝通上並不會有本質上的差異，因為兩者都不是客戶所熟悉的東西，客戶最熟悉的就是他的業務流程及流程中的具體操作。找出對象關系或是數據處理上的先後步驟是軟體開發人員應該做的事。客戶的業務流與數據流有相似，但肯定不一樣，如果你認真分析就會發現兩者的不同。
需求模型上兩者各有優缺點，OOA可以更好的在軟體設計的下一階段復用前一階段的成果，也可以讓開發出來的軟體有更強的適用性與復用性，利於進一步的軟體維護與修改，但前提是OOA的設計與分析一定要到位。數據流相對更為直觀，且在小型軟體項目中可以更快速有效的建立整個需求，與底層資料庫的設計也比較容易保持一致。
適用的場景，OOA適用於大型軟體，並且最好是那種需要不斷的更新維護，不斷的發展深化的軟體項目。數據流分析則比較適合於小型項目，一次性的買賣，不利於軟體的擴充與維護。

㈢ 什麼是面向對象的需求分析方法

它首先用結構化分析（SA）對軟體進行需求分析，然後用結構化設計（SD）方法進行總體設計，最後是結構化編程（SP）。它給出了兩類典型的軟體結構（變換型和事務型）使軟體開發的成功率大大提高。

三種基本的結構形式就是順序、選擇和重復。三種數據結構可以進行組合，形成復雜的結構體系。這一方法從目標系統的輸入、輸出數據結構入手，導出程序框架結構，再補充其它細節，就可得到完整的程序結構圖。這一方法對輸入、輸出數據結構明確的中小型系統特別有效，如商業應用中的文件表格處理。該方法也可與其它方法結合，用於模塊的詳細設計。

㈣ 需求分析的主要方法是

目前，軟體需求的分析與設計方法較多，一些大同小異，而有的則基本思路相差很大。從開發過程及特點出發，軟體開發一般採用軟體生存周期的開發方法，有時採用開發原型以幫助了解用戶需求。在軟體分析與設計時，自上而下由全局出發全面規劃分析，然後逐步設計實現。
從系統分析出發，可將需求分析方法大致分為功能分解方法、結構化分析方法、信息建模法和面向對象的分析方法。
(1)功能分解方法。
將新系統作為多功能模塊的組合。各功能義可分解為若乾子功能及介面，子功能再繼續分解。便可得到系統的雛形，即功能分解——功能、子功能、功能介面。
(2)結構化分析方法。
結構化分析方法是一種從問題空間到某種表示的映射方法，是結構化方法中重要且被普遍接受的表示系統，由數據流圖和數據詞典構成並表示。此分析法又稱為數據流法。其基本策略是跟蹤數據流，即研究問題域中數據流動方式及在各個環節上所進行的處理，從而發現數據流和加工。結構化分析可定義為數據流、數據處理或加工、數據存儲、端點、處理說明和數據字典。
(3)信息建模方法。
它從數據角度對現實世界建立模型。大型軟體較復雜；很難直接對其分析和設計，常藉助模型。模型是開發中常用工具，系統包括數據處理、事務管理和決策支持。實質上，也可看成由一系列有序模型構成，其有序模型通常為功能模型、信息模型、數據模型、控制模型和決策模型。有序是指這些模型是分別在系統的不同開發階段及開發層次一同建立的。建立系統常用的基本工具是E—R圖。經過改進後稱為信息建模法，後來又發展為語義數據建模方法，並引入了許多面向對象的特點。
信息建模可定義為實體或對象、屬性、關系、父類型/子類型和關聯對象。此方法的核心概念是實體和關系，基本工具是E-R圖，其基本要素由實體、屬性和聯系構成。該方法的基本策略是從現實中找出實體，然後再用屬性進行描述。
(4)面向對象的分析方法。
面向對象的分析方法的關鍵是識別問題域內的對象，分析它們之間的關系，並建立三類模型，即對象模型、動態模型和功能模型。面向對象主要考慮類或對象、結構與連接、繼承和封裝、消息通信，只表示面向對象的分析中幾項最重要特徵。類的對象是對問題域中事物的完整映射，包括事物的數據特徵(即屬性)和行為特徵(即服務)

㈤ 需求分析有哪兩種主要分析方法

從系統分析出發，可將需求分析方法大致分為功能分解方法、結構化分析方法、信息建模法和面向對象的分析方法。
(1)功能分解方法。
將新系統作為多功能模塊的組合。各功能義可分解為若乾子功能及介面，子功能再繼續分解。便可得到系統的雛形，即功能分解——功能、子功能、功能介面。
(2)結構化分析方法。
結構化分析方法是一種從問題空間到某種表示的映射方法，是結構化方法中重要且被普遍接受的表示系統，由數據流圖和數據詞典構成並表示。此分析法又稱為數據流法。其基本策略是跟蹤數據流，即研究問題域中數據流動方式及在各個環節上所進行的處理，從而發現數據流和加工。結構化分析可定義為數據流、數據處理或加工、數據存儲、端點、處理說明和數據字典。
(3)信息建模方法。
它從數據角度對現實世界建立模型。大型軟體較復雜；很難直接對其分析和設計，常藉助模型。模型是開發中常用工具，系統包括數據處理、事務管理和決策支持。實質上，也可看成由一系列有序模型構成，其有序模型通常為功能模型、信息模型、數據模型、控制模型和決策模型。有序是指這些模型是分別在系統的不同開發階段及開發層次一同建立的。建立系統常用的基本工具是E—R圖。經過改進後稱為信息建模法，後來又發展為語義數據建模方法，並引入了許多面向對象的特點。
信息建模可定義為實體或對象、屬性、關系、父類型/子類型和關聯對象。此方法的核心概念是實體和關系，基本工具是E-R圖，其基本要素由實體、屬性和聯系構成。該方法的基本策略是從現實中找出實體，然後再用屬性進行描述。

㈥ 面向對象的需求分析中要建立什麼模型

一、總述
面向對象分析的輸入是用戶的功能需求，輸出是簡單的、理性化的分析模型，此階段的工作更多側重於如何理解軟體的功能需求；
面向對象設計的輸入是面向對象分析的結果，蔬菜水果最終的、細化後的設計模型，此階段的工作更多側重於如何得到一個合適的、完整的解決方案。
二、主要區別
(1)
在側重點上，面向對象分析側重於理解問題，描述軟體要做什麼，而面向對象設計側重於理解解決方案，描述軟體要如何做。
(2)
面向對象分析一般只考慮理想餓設計，不關心技術和實現層面的細節，而面向對象設計需要得到更具體、更詳盡，更接近於真實的代碼的設計方案。
(3)
在設計結果的描方式上，面向對象分析階段側重於描述對象的行為，而面向對象設計階段側重於描述對象的屬性和方法。
(4)
面向對象分析只關注功能性需求，而面向對象設計既關注功能性需求，也關注非功能性需求。
(5)
面向對象分析產生的系統模型通常規模較小，而面向對象設計產生的系統模型規模較大，內容也比較詳盡、完整。
三、分析設計工具(rationalrose
+
uml)
1、需求分析階段
常藉助於「用例圖」、「順序圖」對功能模型進行建模；
用例描述，一般包括：用例名稱，系統范圍，用戶目標，前置條件，執行過程，擴展情況，後置條件。
順序圖著眼於整個系統。
2、面向對象分析階段（包含需求分析階段的用例建模）
常藉助於「類圖、對象圖」，「順序圖、協作圖」，「狀態圖」進行靜態模型建模和動態模型建模。
這里的類圖主要指通過用例分析得到的實體類、控制類和邊界類。
順序圖也著眼於各個分析類對象間的協作。
3、面向對象設計階段
常藉助於「類圖」，「順序圖、協作圖」，「狀態圖」來細化各個類以及對象間的協作、關系的可見性；
這里的類圖，要具體到屬性、方法，類之間的關系依賴（繼承、組合、聚合）
這里的順序圖要具體到各個類的實例之間的消息傳遞、函數調用。
面向對象設計階段常藉助一些設計模式達到軟體的可擴展行，應對軟體的可預測到的變化。

㈦ 面向對象分析方法的步驟和特點

使用MVC進行項目開發已經有一段時間了，在這段時間里感觸最深的就是自己對宏觀性面向對象分析方法的缺乏。面向對象分析是當今流行的系統分析方法之一，下面就談談在做項目的過程中我的一些小經驗。

在面對簡單系統時程序員可以很順利的提出問題的解決方案，並且一般情況下都是可行的。這是由於問題域關系簡單，所涉及到的內部構造、聯系比較容易解釋。而對於當前越來越復雜的系統，其問題域也就顯示的越來越復雜，而且內部的關系也不是很容易解釋，有些大的系統常常超出了人的解決問題的能力。在這種情況下，以往的面對過程的解決方法已經不能滿足日益增長的復雜系統分析的需要，在這種情況下，面向對象的分析方法就顯得尤為總要了。

在面向對象設計領域中，在橫向上把問題域分為數個不同的、低耦合、高內聚的問題域，而在縱向上又繼續分解各個不同的小的問題域，最後分解為葉節點問題域，從而解決問題。在面對對象分析方法中，用數個對象間的消息傳遞來完成整個問題。

下面看一看復雜系統的5個屬性：

1． 雜性經常是以層次的形式表現出來，復雜系統是由相互關聯的子系統組成，而這些子系統又是由他們各自的子系統構成，並由此類推到最底層的基本構件。

2． 對系統中最基本的構件的選擇是任意的，而且在很大程度上取決於系統觀察者的判斷力。

3． 一般而言，各構件內的連接總是要強於構件間的連接。在從構件的低頻動態中分離出高頻動態時，這一屬性是相當有用的。這是因為高頻動態涉及到各部件的內部結構，而低頻動態涉及到構件間的交互。

4． 層次系統通常都是由僅僅少數不同的子系統通過不同的排列組合方式組成。

5． 我們發現正運行的復雜系統總是由以前運行的簡單系統演化而來……任何胡亂湊合設計出來的復雜系統都不可能正常運轉，也不可能被修補好。我們必須由運行中的簡單系統開始。

對於第一點，正像我上面所說的那樣，系統是層次結構的。能夠給一個復雜的系統進行正確的層次分析，才能夠保證對系統的正確估計，包括可行性、可維護性、可擴展性……等等。而且對於日後對該系統進行維護(maintenance)、演化(evolution)、維持(preservation)都能夠很好的支持。

對於其中的第二點，強調了觀察者的判斷力，其實我認為其中也包括觀察者的身份角度。對於一個系統而言，觀察者並不是只進行分析設計的工程師，編碼階段的程序員，還應該包括用戶等所有這些同該系統有關的人員。作為不同的人員，對於系統就有不同的觀察點、觀察角度、身份等特殊因素。因此在不同身份的人（指參與者）甚至同一身份的人眼中說觀察到的系統特性都是不盡相同的。在大學里大家都接觸過透明性的概念，這就是不同觀察者所觀察角度不同的直觀反應。對於用戶來說，基本上底層的操作、演算法、通訊對於他們來說都是透明的，他們根本不用理會（其實也不知道）內部用了什麼。而對於一個負責某模塊的程序員來說就不會考慮其他模塊的實現，對於他們來說其他模塊是透明的，他們只需要負責管理好提供的模塊介面就OK了。

對於第三點，講的就是面對對象分析設計的方向，在面對對象分析設計系統時，被分解的各個模塊一定要做到高內聚、低耦合。有良好高內聚、低耦合系統常常會很容易維護，一個地方改動通常不需要牽扯到大的改動，維護行強。而且對於像VC程序這種更要求效率的程序來說，高內聚、低耦合也可以提高程序的運行期效率，應為對象內部的調用一般情況下會相比模塊間的調用佔用更少的執行時間，這樣將高頻動態封裝在一個對象內部就會一定程度上提高程序運行期執行效率。

第四點則說明了面向對象程序設計對程序設計可復用性的優點。在這點中所「層次系統由僅僅少數不同的子系統構成」那麼多數子系統在不同的復雜系統中都是能夠重復使用的。比如說建築一棟大廈和建築橋梁，雖然兩者都是復雜的系統，但是對於其結構中就會有很多相似甚至相同之處，沒有必要建築好大廈回頭建築橋梁的時候又要重新設計每一快磚瓦。

第五點提醒我們在系統設計時，盡量使用以往能夠正常運行的子系統來重新構件新的系統。這一點不僅說明第四點中的復用性，而且也說明了一個我們常常要犯的錯誤。就是將並沒有通過嚴格測試的子系統，匆忙的加入到大系統中，這樣做不利於對系統的基層，常常引入了其他錯誤，使得系統頻頻崩潰，最嚴重會導致系統的重新分析。

這是我對面向對象的一點心得體會，雖然我們大家在平時工作中所面對的問題、問題域不同，使用的開發工具不同，但是面向對象是一種思維方式，有利於分析、解決問題的一種方法，並不和任何語言掛鉤（當然語言對於面向對象特性的支持程度有所不同）。所以希望各位同事能夠盡量使用科學的方法分析解決問題，形成一種設計模式，以供大家互相交流。

軟體設計是一種藝術，也是一門工程學。

㈧ 軟體需求的分析方法

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

㈨ 需求分析常用方法

行為事件分析

行為事件分析是根據運營關鍵指標對用戶特定事件進行分析。通過追蹤或記錄用戶行為事件，可以快速的了解到事件的趨勢走向和用戶的完成情況。

以用戶投標的行為事件為例，出借人在完成投標過程中，所進行的注冊、認證、開戶、充值、投資等行為，都可以定義為事件，也是完成投標成功的一個完整事件。
確定投標行為事件後，我們可以根據事件屬性細分維度：用戶來源、性別、出生年月、注冊時間、綁卡時間、首次充值時間、首次投資時間、標的ID，標名、期限、利率、還款方式等。然後從中找出符合指標的規律，並制定針對性的措施。

用戶留存分析

用戶留存分析是一種用來分析用戶參與情況與活躍程度的模型。通過留存量和留存率，可以了解用戶的留存和流失狀況。比如用次日留存、周留存、月留存等指標來衡量產品的人氣或粘度。以渠道訪問的用戶留存為例，我們對APP端有過訪問行為的渠道用戶進行留存分析。用戶留存一般符合40-20-10法則，即新用戶的次日留存應該大於40%，周留存大於20%，月留存大於10%才符合業務標准。我們做用戶留存分析主要驗證是否達到既定的運營目標，進而影響下一步的產品決策。

漏斗模型分析

漏斗模型分析是用戶在使用產品過程中，描述各個階段中關鍵環節的用戶轉化和流失率情況。比如在日常活動運營中，通過確定各個環節的流失率，分析用戶怎麼流失、為什麼流失、在哪裡流失。找到需要改進的環節，要重點關注，並採取有效的措施來提升整體轉化率。

邀請人將活動專題頁分享給好友，之後進行的注冊、認證、開戶、充值到投資，用漏斗模型分析一些關鍵節點的轉化率。其中用戶注冊轉化率為68%，實名認證轉化率為45%，綁卡開戶轉化率為29%，線上充值轉化率為17%，投資標的轉化率為8%。
漏斗模型分析可以驗證整個流程的設計是否合理。經過對比發現，訪問到注冊的轉化率為68%，遠低於預期的80%。這次運營策略是用戶必須先注冊才能領取新手福利。之後採取A/B測試的方式，優化為先領取新手福利再誘導用戶注冊。經過數據對比分析，注冊轉化率提升了20%。因此，通過對各環節相關轉化率的比較，可以發現運營活動中哪些環節的轉化率沒有達到預期指標，從而發現問題所在，並找到優化方向。

行為路徑分析

行為路徑分析就是分析用戶在產品使用過程中的訪問路徑。通過對行為路徑的數據分析，可以發現用戶最常用的功能和使用路徑。並從頁面的多維度分析，追蹤用戶轉化路徑，提升產品用戶體驗。

不管是產品冷啟動，還是日常活動營銷，做行為路徑分析首先要梳理用戶行為軌跡。用戶行為軌跡包括認知、熟悉、試用、使用到忠誠等。軌跡背後反映的是用戶特徵，這些特徵對產品運營有重要的參考價值。我們可以記錄用戶從注冊、認證、開戶、充值到投資的行為軌跡。通過分析用戶的這些行為軌跡數據，來驗證訪問路徑是否和預期指標的一致。