需求分析中的用例圖,流程圖,系統結構圖中有些圖形比較難畫。有沒有的小巧的工具可以作這些工作

2021-04-02 08:25:25 字數 4945 閱讀 7333

1樓:匿名使用者

word中的繪圖中就有這些圖的。

在:檢視-------工具欄---------繪圖---------自選圖形

按照上面操作即可哦

2樓:匿名使用者

microsoft office visio 專業用於這類問題的軟體

我們應當怎樣做需求分析:功能角色分析與用例圖

3樓:匿名使用者

在我們進行一系列需求調研工作的同時,我們的需求分析工作也開始啟動了。需求調研與需求分析工作應當是相輔相伴共同進行的。每次參加完需求調研回到公司,我們就應當對需求調研的成果進行一次需求分析。

當下一次開始進行需求調研時,我們應當首先將上次需求分析的結果與客戶進行確認,同時對需求分析中提出的疑問交給客戶予以解答。這就是一個需求捕獲->需求整理->需求驗證->再需求捕獲的過程。

但是,當我們經過一番忙碌,將需求中的第一手資料從調研現場捕獲回來以後,我們應當怎樣進行分析呢?不少團隊對此都比較迷茫,沒有一個統一和有效的方法,往往採用想到**做到**的方式。一些問題想到了就做了,沒有想到則忽略掉了。

實際上,需求分析不應當是太公釣魚,而應當是拉網排查。任何一個疏忽都可能對專案研發帶來風險。因此,我們應當採用一套成熟而完整的分析方法,穩步而有序地完成這部分工作。

不同型別的軟體專案其分析方法可能存在差異,但一般來說,資訊化管理類軟體專案通常從這幾個方面著手分析:功能角色分析、業務流程分析與業務領域分析。

需求分析不是一項一蹴而就就可以完成的工作,它需要一個長期的過程,而這個過程是一個由粗到細的過程,它體現了人類認識事物的客觀規律。在需求分析的初期,我們對需求的認識往往是整體的、巨集觀的,隨著分析工作的逐漸深入,一步步細化。按照這個思路,我們對需求的分析,首先應當從功能角色分析開始。

所謂功能角色分析,就是從一個外部使用者的視角分析整個軟體系統能夠提供的功能,以及這些功能到底是提供給哪些角色使用。

對一個系統進行功能和角色方面的梳理和分析,可以採用的比較主流的方法之一就是繪製用例圖。用例圖是uml的4+1檢視中的一種,準確地說就是那個「+1」。用例圖是貫穿整個物件導向分析/設計(ooa/d)的核心檢視,它描述的是系統到底為使用者提供了哪些功能,以及到底是哪些使用者在使用這些功能,是溝通使用者與技術人員的橋樑。

運用用例檢視對業務需求進行分析、抽象、整理、提煉,進而形成抽象模型的過程稱之為用例建模,而這個模型就是用例模型。

一般地,在一個用例圖中通常有三種元素:參與者(actor)、用例(use case)與系統邊界(boundary)。用例描述的是系統為使用者提供的功能,也就是系統能為使用者做什麼,通常被繪製成一個橢圓;參與者,我認為稱為角色更加合適,也就是系統為哪些型別的使用者提供服務,他們都各自承擔哪些不同的職責,通常被繪製成一個小人兒;最後是系統邊界,也就是系統是對現實世界哪個範圍的內容進行的模擬,它涉及到軟體設計的工作範圍與工作量,通常被繪製成一個方框。

但是,通常情況下系統邊界只是一個概念而不用真正繪製出來,因為被繪製成用例的必然是系統內部的功能,被繪製成參與者的必然是系統外部事物。從這個意義上講,用例圖中的參與者不僅包括人,還包括那些外部系統和自動觸發器。根據這樣一個思路,我以往常常將外部系統和自動觸發器繪製成一個小人,這常常令客戶感到困惑。

隨後我改變了思路,將外部系統和自動觸發器繪製成另一種表達形式——類元符號表示法,並在構造型上標註為actor。

上圖是一個考核系統中一個子模組的用例圖。圖中的用例就是這個系統提供給使用者的各項功能。注意,這裡僅僅是在羅列功能而不表示它們之間諸如流程呼叫等相互關係,這是一些初學者常常犯的毛病。

參與者與用例通過實線關聯起來,代表的是一種使用關係。箭頭代表的是一種導航,即動作施與的方向。在這個用例圖中,普通使用者執行查詢操作,查詢系統提供的「預警監控單項查詢」、「預警監控彙總查詢」等查詢報表;每日自動觸發器觸發自動考核功能,自動考核功能從「稅收徵管系統」這樣一個外部系統中採集資料。

在繪製用例圖時一個值得思考的細節是,用例是怎樣通過分析獲得的。這個問題,在一些客戶對資訊化管理比較有經驗的專案中不存在問題,因為在客戶提供給我們的需求文件中就清晰地劃分出了一項一項的功能。這些功能可能會在日後的需求分析工作中有所調整,但它從整體上形成了一個雛形,成為我們進行用例分析進而形成用例的依據。

有人說,我們繪製的用例圖拿給客戶看不懂。這樣一個清晰明瞭的用例圖,輔之以我們對圖形的描述,客戶怎麼會看不懂呢?關鍵問題在於,我們沒有將用例圖的精髓弄明白,再加上出現一些常見問題,使得用例圖畫得不倫不類,客戶當然就看不明白了。

現在我們看看用例繪製都有些什麼常見問題。

1. 沒有正確理解用例圖的視角。前面我反覆強調了,用例圖的視角是使用者,也就是說,站在使用者的角度來觀察的我們需要設計的系統。

從這個視角,使用者看到的系統是什麼呢?當然是一項一項的功能,這些功能是客戶能夠理解的、具體的、對客戶存在價值的功能。從這個意義上說,那些技術性的功能不應當出現在這裡,或者應當描述為使用者可以理解的文字,比如「自動考核」。

而那些應當繪製的用例,在取名時也應當站在使用者角度去取名。舉個簡單的例子,一個員工檔案資訊系統,以往我們總愛將用例取名為「新增員工資訊」、「更新員工資訊」、「刪除員工資訊」,這就是典型的技術人員編寫的用例。「新增員工資訊」對於使用者來講應當是做什麼呢——填寫新員工資料;「更新員工資訊」對於使用者來講又是做什麼呢——更改員工資料;「刪除員工資訊」又是什麼呢——員工登出。

不論是「填寫新員工資料」、「更改員工資料」,還是「員工登出」,對於客戶都是日常工作中需要完成的操作,將用例命名為這些名字必然為使用者所理解。同時,每一個用例對於使用者來說應當是有價值的,也就是說,使用者使用這個功能是要完成一項操作,或獲得什麼資訊。比如上圖的「自動考核」會產生一批考核結果,執行「預警監控單項查詢」可以獲得預警監控結果資料。

2. 圖形繪製雜亂無章。一個系統,特別是一個大型系統,提供給使用者的功能是繁雜的。

如果你想將所有的功能,不管粗的細的,都試圖繪製在一個用例圖中,幾乎沒人看得懂。我們之所以將分析設計圖形化,是因為圖形能給人形象立體的感官,使人立即就明白了其中的意思,但前提是,這個圖形是主題清晰的、形象生動的。因此,我們繪製用例圖要學會拆分,由粗到細地一個一個繪製。

先整體的繪製,再劃分成各個模組一個一個詳細繪製,再進一步細化。所以,描述一個系統應當有許許多多的用例圖。

3. 用例是一個場景。在現實世界中,我們常常面對的是一個個長而複雜的操作流程,但在軟體世界裡,我們要將它們拆分成一個個的用例,怎樣拆分?

一個用例必須有一個場景,也就是時間相近、地點單一的一系列操作,並且這些操作最終應當有一個明確的結果。

如上所示這個用例圖,「申辯申請」就是過錯責任人填寫了一張申辯申請單,最終的結果是將申辯申請單提交給考核管理員;「申辯受理」就是考核管理員接收了過錯責任人的申辯申請單並予以受理,當然另一個結果是對其不予受理,該申請單被退回給過錯責任人。每個用例都有確定的場景,明確的目的和結果。

功能角色分析是對系統巨集觀的、整體的需求分析,它用簡短的圖形繪製出了一個系統的整體輪廓。但僅僅進行功能角色分析是遠遠不夠的,我們還需要在它的基礎上做更加詳盡的分析。

我在進行文件管理系統的設計與開發,我現在進行到需求分析階段,如果用uml的話,應該畫些什麼圖?謝謝

4樓:匿名使用者

簡單地瞭解一下uml設計中有的圖例及基本作用。首先對uml中的各個圖的功用做一個簡單介紹:   1、用例圖   描述角色以及角色與用例之間的連線關係。

說明的是誰要使用系統,以及他們使用該系統可以做些什麼。一個用例圖包含了多個模型元素,如系統、參與者和用例,並且顯示了這些元素之間的各種關係,如泛化、關聯和依賴。

2、類圖   類圖是描述系統中的類,以及各個類之間的關係的靜態檢視。能夠讓我們在正確編寫**以前對系統有一個全面的認識。類圖是一種模型型別,確切的說,是一種靜態模型型別。

  3、物件圖   與類圖極為相似,它是類圖的例項,物件圖顯示類的多個物件例項,而不是實際的類。它描述的不是類之間的關係,而是物件之間的關係。

4、活**   描述用例要求所要進行的活動,以及活動間的約束關係,有利於識別並行活動。能夠演示出系統中哪些地方存在功能,以及這些功能和系統中其他元件的功能如何共同滿足前面使用用例圖建模的商務需求。

5、狀態圖   描述類的物件所有可能的狀態,以及事件發生時狀態的轉移條件。可以捕獲物件、子系統和系統的生命週期。他們可以告知一個物件可以擁有的狀態,並且事件(如訊息的接收、時間的流逝、錯誤、條件變為真等)會怎麼隨著時間的推移來影響這些狀態。

一個狀態圖應該連線到所有具有清晰的可標識狀態和複雜行為的類;該圖可以確定類的行為,以及該行為如何根據當前的狀態變化,也可以展示哪些事件將會改變類的物件的狀態。狀態圖是對類圖的補充。   6、序列圖 (順序圖)   序列圖是用來顯示你的參與者如何以一系列順序的步驟與系統的物件互動的模型。

順序圖可以用來展示物件之間是如何進行互動的。順序圖將顯示的重點放在訊息序列上,即強調訊息是如何在物件之間被髮送和接收的。

7、協作圖   和序列圖相似,顯示物件間的動態合作關係。可以看成是類圖和順序圖的交集,協作圖建模物件或者角色,以及它們彼此之間是如何通訊的。如果強調時間和順序,則使用序列圖;如果強調上下級關係,則選擇協作圖;這兩種圖合稱為互動圖。

8、構件圖 (元件圖)   描述**構件的物理結構以及各種構建之間的依賴關係。用來建模軟體的元件及其相互之間的關係,這些圖由構件標記符和構件之間的關係構成。在元件圖中,構件時軟體單個組成部分,它可以是一個檔案,產品、可執行檔案和指令碼等。

9、部署圖 (配置圖)   是用來建模系統的物理部署。例如計算機和裝置,以及它們之間是如何連線的。部署圖的使用者是開發人員、系統集**員和測試人員。

  一:這九種模型圖各有側重,   1:用例圖側重描述使用者需求,   2:

類圖側重描述系統具體實現;   二:描述的方面都不相同,   1:類圖描述的是系統的結構,   2:

序列圖描述的是系統的行為;   三:抽象的層次也不同,   1:構件圖描述系統的模組結構,抽象層次較高,   2:

類圖是描述具體模組的結構,抽象層次一般,   3:物件圖描述了具體的模組實現,抽象層次較低。   在有的文獻書籍中,將這九種模型圖分為三大類:

  結構分類、動態行為和模型管理:   1:結構分類包括用例圖、類圖、物件圖、構件圖和部署圖,   2:

動態行為包括狀態圖、活**、順序圖和協作圖,   3:模型管理則包含類圖。

為什麼Visio畫軟體的流程圖在中列印漢字顯示為空白

你visio裡面的文bai字是不是用 文du本工具 就是那個zhi a 插入的dao 在visio裡畫好內流程圖,直接 容複製 貼上到word裡,是沒有問題的,但是如果你在word裡面又編輯過這個圖,比如在word裡選中這張圖,右鍵選 visio物件 開啟 然後做過什麼改動的話,列印出來文字就會是小...

中中的流程圖怎麼複製到另啊,word中文件中的流程圖怎麼複製到另一個文件啊?

用shift 上下箭頭進行選擇,再用ctrl c鍵進行復制,到另一word文件用ctrl v鍵進行貼上。點複製,然後開啟另一個文件,點貼上就ok了,試一下 用滑鼠框選流程圖所有的文字 圖形 含線條 方框等 等附件,右鍵 複製 或ctrl c 貼上到另一個word文件中 或ctrl v word中文件...

用畫的流程圖怎麼複製到另中,用WORD畫的流程圖怎麼複製到另一個word文件中

可以用。ctrl加a,截圖下來,再貼上到新的word文件中。方法一 1 按ctrl a組合鍵,進行全選 2 按ctrl c組合鍵,進行復制 若單擊開始 複製按鈕 3 開啟另一個word文件,將游標定位在目標處 4 按ctrl v組合鍵,進行貼上即可。方法二 1 開啟另一個word文件,將游標定位在目...