現在rup
如日中天，需求分析是第一步，可以看作是高階系統分析員的必備知識，那麼，如果用物件導向的分析技術來描述需求呢？
在乙個需求分析過程中，主要有專案描述，風險分析，用例圖以及描述，專案建議這幾部分。
其中最重要的，也是最需要學習的就是用例的描述。那麼用例的描述關鍵點在**呢？
確定清晰的系統邊界，就是要確定系統中有什麼？系統外有什麼？通過執行者和用例來確定系統邊界。
那麼，我們第一步就是要找出執行者，執行者是乙個角色，我們可以根據以下幾個問題來思考決定一下：誰在使用系統？誰在維護？誰在啟動
?誰在關閉？誰從這個系統獲得資訊？誰為這個系統提供資訊？是否有自動的事情在預計時間發生？等等方式，來確定執行者。
找出了執行者，那就要確定用例，用例是系統的乙個行為，為執行者產生可以估量的價值結果。
用例的描述一般都是動名詞結構。
需要構建一張表，清楚的以名詞解釋的形式，把用例和執行者進行簡單的定義。
如果用例圖過於大，那就分開，也可以採用包的形式。
其中用例圖的中的箭頭表示是單向還是雙向，要根據交付的資訊看。
如果是外部定時發生的事情，可以把時間也作為執行者。
需求在系統之內，無法被執行者看到，那麼這個需求就不用在用例圖中體現。
歸檔用例就是把用例用文件的方式表示。基本用例主要包括：前置條件（前置條件就是用例開始時候，必須要處在乙個什麼狀態）
後置條件（用例結束，系統處在什麼狀態）事件流。（事件流是一系列的陳述句）。
事件流中包含一些迴圈語句。可以採用
for ,while
迴圈。用例是乙個傳達工具，只有向讀者傳達系統如何工作的時候才有效。
用例要從執行者的觀點來寫。
對於非事件流的需求，可以在用例的特殊需求中描述。
事件流分為兩部分：基本路徑和可選路徑。
一切正常運轉就是基本路徑。
不同於基本路徑而允許選擇不同的事件序列的路徑，就是可選路徑，也可以說各種異常情況的處理也是可選路徑。
可選路徑，最好用不同的段落編號來標示。
什麼是場景？
場景就是一種貫穿用例的特定路徑。
用例的包含
：如果你發現在寫各種用例的時候，要經常
copy
同一部分的內容
，那麼就說明你有了一部分通用的行為，那麼就可以用一種包含關係來抽象這種通用行為。包含用例一定要有被包含用例，這個用例才算完整。
用例的擴充套件
：在不改變原始用例的情況下，增加用例的行為。重要關注的乙個概念是擴充套件點，當到達這個擴充套件點，如果條件為真，就是這個擴充套件條件的前置條件為真的話，這個擴充套件的步驟將被執行。
用例的繼承：
用例的繼承代表乙個用例（子）是另外乙個用例（父）的特殊實現，執行者的繼承意味著乙個執行者（子）可以完成另外乙個執行者（父）的任務。
介面：介面不是執行者和用例的一部分。介面是執行者和用例相互作用的一種描述。
文件中的文字可以簡潔的描述系統，那麼有些文字分支很多的時候，採用圖就是乙個非常好的方式，圖形化用例也是乙個不錯的手段。我們可以用三種圖來細化和具體化用例。
活**：
描述用例的步驟。活**描述滿足用例需求而進行的活動以及活動之間的關係。（有些書把活**定義為狀態圖的子集）
時序圖：
描述執行者和系統的相互作用。時序圖中，每個實體下面有虛線，代表物件生命週期。確認的返回值，是採用虛線箭頭來表示。
在學會寫用例以後，那就有乙個問題，用例寫到什麼程度好呢
? 就是用例細化到什麼程度為好。要回答這個問題，需要考慮三個問題：
誰需要閱讀並審批這個文件？誰需要使用這個文件？我們要這個文件做什麼？
用例可能是給終端使用者和開發者的，或者管理者的，決定多少細節放到用例中是乙個很重要的事情。可以對
同乙個用例做不同細節程度的版本，交給不同的人看
，要注意維護這種對應關聯關係。
用例文件模板：
包括系統簡介，風險因素，系統級用例（乙個或者多個反映系統中所有用例和執行者的圖，沒必要包含用例之間的關係，例如包含，擴充套件和泛化），體系結構，子用例，非功能性的需求包括可用性，系統，安全，永續性，冗餘性，效能，規模，標準化等。
可以通過活**來描述和表現用例之間的關係和流程。
劃分大型系統：
如果是做乙個大系統，那麼把大系統劃分為小系統就是乙個非常重要的事情！先選出系統中最重要的部分。主要的體系架構有如下幾種：
一、mvc
結構，一層用來顯示，一層用來控制，一層用來資料儲存。例如
jsp,struct
就是這種架構。
二、管道和過濾器體系結構
。主要思想就是乙個部分輸入資料，處理資料，然後輸出，下乙個部分接收，處理，依次類推，例如
freeradius
，jradius
就是這種架構。
三、物件導向的體系結構模式
。系統是根據資料來定義，並且和各種功能相聯絡。可以使用用例驗證體系結構，每乙個子系統應該有：
---單一的功能性
---強聚合性
---它的各個部分彼此之間具有很強的相互關係
----
松耦合性
---其工作的完成不太依賴於其他子系統
----
與其他子系統最少的通訊
----
子系統之間不進行大量的通訊
。介面中的操作來自時序圖。將每個子系統看作乙個整體的系統，每個系統都有執行者和用例。不斷的把大系統分為各種小系統，當系統足夠小的時候，無需更多的劃分就有足夠的細節來實現。
主題摘要：主題摘要就是指我們在用例中使用或處理的東西。是建立系統的基本元素，是描述域的一種方式。
簡單的尋找主題摘要的方法是：查詢用到的實體或資料。通過時序圖來繪製場景，可以把系統物件換成主題摘要，把子系統也換成系統摘要，這樣，傳送給子系統的訊息就改為傳送給主題摘要和執行者的資訊，並且最重要的是要確定主題摘要的行為，確定主題摘要以及他們的行為，就為類的設計打下了基礎。
通過時序圖，我們發現主題摘要，也就可以找出摘要必須作出相應得訊息，然後把訊息對應到用例的參與類中，參與類檢視就是告訴我們要開發哪些類。
用例試圖顯示了系統中的工作流程，是黑盒測試和使用者指南的基礎。
子系統檢視顯示了構成該系統的子系統，是系統重用和維護的基礎。
用例檢視是展示了系統的外觀，只系統檢視是顯示了構成該系統的子系統，乙個是從客戶角度，乙個是從開發角度。
通常是在第一次迭代處理風險最高的，第二次迭代處理次之風險。
1、執行者加權
執行者型別
描述因子
簡單程式介面1普通
互動和協議驅動介面2複雜
（圖形介面32、
用例加權：
用例型別
描述因子
簡單最多
3個事務，最多
5個分析類5普通
4-7個事務，
5-10
個分析類
10複雜多於7
個事務，多於
10個分析類
15事務的概念在這裡是乙個路徑，包括可選路徑，是一組原子操作。
用例的加權總數和執行者的加權總數相加，就得到了未經調整的用例點
(uucp)
3、
技術因子加權：計算專案技術的複雜性，可以利用技術複雜性因子。從0到
5確定每乙個因子的等級。
0等級意味著這個因子與專案不相關，
5代表它是最重要的。
然後用因子去乘每個因子的權重，然後相加。
因子編號
因子描述
權重t1
分布式系統2t2
響應性或吞吐能力1t3
終端使用者效率1t4
複雜的內部處理1t5
**必須可以重用1t6
易於安裝
0.5t7
易於使用
0.5t8
可移植性2t9
易於更改
1t10併發1
t11包括特殊的安全性
1t12
為第三方提供直接訪問
1t13
需要特殊的使用者培訓設施
1tcf=0.6+(0.01*tfactor)tfctor=
所有（權重
*等級）相加之和。
4、小組的環境因子和權重.從
0到
5確定每乙個因子的等級。
0等級意味著這個因子與專案不相關，
5代表它是最重要的。
因子編號
因子描述
權重f1
熟悉
rup
1.5
f2
使用經驗
0.5 f3
物件導向經驗
1 f4
領導分析能力
0.5 f5
動力
1 f6
穩定的需求
2 f7
兼職人員
-1 f8
有難度的程式語言
-1
ef=1.4+(-0.01*efactor )efactor=
所有（權重
*等級）相加之和
最後計算用例點（
ucp）
ucp=uucp * tcf * ef
然後進行專案估算，看看
f1—f6
有幾個低於3，
f7—f8
有幾個高於
3，然後把這兩個數加起來等於
n n
的範圍ucp
工時n<=2
每個
ucp 20
個工時3<=n<=4
每個
ucp28
個工時n>5
調整專案
工時=n* ucp
那麼，採用這種方法，就估算出來了工時
.
用例分析技術小記 1
用例被用來描繪乙個系統外在可見的需求情況，常被用在專案的需求分析階段，對專案的測試計畫和使用者指南也有用處。他們被用來建立和驗證被提議的設計，並確保該設計滿足所有的需求。用例也被用來在建立專案計畫時決定在每乙個版本中應該加入什麼內容。在專案中常有的乙個問題就是，已經進入了開發階段了確還要對某些東西進...
流技術小結
按照資料流的方向分，分為輸入流和輸出流 按照處理資料的單位來分，分為位元組流和字元流 按照功能來分，分為節點流和處理流 inputstream 位元組輸入流，實現類 fileinputstream outputstream 位元組輸出流，實現類 fileoutputstream file file ...
C 反射技術小結
要用c 反射技術的話，首先得引入system.reflection 命名空間，這個命名空間裡的類，具有動態引導程式集 型別，動態呼叫方法 設定和取得屬性和字段的值 可以獲取型別和方法的資訊的功能。要想對乙個型別例項的屬性或字段進行動態賦值或取值，首先得得到這個例項或型別的type,微軟已經為我們提供...