目錄

part1.基礎知識區
求求你了好歹看完基礎區吧

1.軟件生存期模型

2.需求工程

3.UML

part2.細分進階區

4.需求獲取
a. 愿景
b. 涉眾

5.業務建模
a. 業務單元

X.常識

軟件生存期模型模型

其基本定義

• 軟件開發的一種過程性框架
• 在生存期模型中定義$過程$非常重要
• 在軟件生產過程$不存在絕對正確$的過程形式,不同的軟件開發項目應當采用不同的軟件開發過程。
• 軟件生存期模型的特點：
  • 描述了開發的主要階段
  • 定義了每一個階段要完成的主要過程和活動。
  • 規范了每一個階段的輸入和輸出（可驗證的）

主要的四個有瀑布模型，V模型，原型模型，增量式模型。
需要特別掌握的是瀑布式模型。

• 需求分析
  • 設計
    • 編碼與單元測試
    • 集成測試與系統測試
      • 運行與維護

可以清晰地看到這5層的層層遞進關系。也能明確的發現這種模式的缺點：
$不夠靈活$ 和 $直到最后才能看到完整的軟件實體$。
其中，不夠靈活體現在這一步一步的，如果底層的需求錯了，就需要整個打斷重來。而關于第二點，你看到單元測試可能覺得不對。這大約就是數塊木板+幾根鋼板+幾個螺絲釘組成一張床的事兒吧。
所以，該模型只適合，需求十分明確，并且解決方案也很明確的項目。
不然就得打斷，回退，甚至是重來，這是所有項目開發都不希望看見的。

同樣的，你也能看到一些特點。

• $定義清晰$

• $每一步驟結束都有一個里程碑來標志$
  * 里程碑定義了一組文檔集合

• $只有文檔被大家認可后下階段才能啟動$

• $活動都有輸入和輸出，階段之間的接口定義清晰$

• $可以定義開發者的不同角色$
  * 在真實的項目團隊中,有需求分析師、架構師、程序員、測試員等。

嗯我是抄的PPT。其中第二第三應當是強調內部的階段性，第四表示連接程度，第五倒是從策劃角度來看了。

回目錄

需求工程

考試也許不會問你什么是需求（目前就有兩種以上的定義）
但是可能會問你什么是需求工程。

一種獲取、組織并記錄系統需求的系統化方案，以及一個使客戶與項目團隊對不斷變更的系統需求達成并保持一致的過程。

那很顯然的。一個項目的需求顯然就應該有3層。分別來自1.甲方發現需求并向他人要求者 2.禿頭開發 3.韭菜用戶
正經點。
1.業務需求（甲方）
*反應組織、機構或客戶對系統、產品的高層次的目標要求。
*范圍文件（）
2.用戶需求
*用戶使用產品必須完成的任務。
*用例描述（餅說明書）
3.功能需求
*定義開發人員必須實現的軟件功能（與業務需求的1對應）
*軟件需求規格說明SRS

這張圖很好的說明了我們程序員到底要迎合多少需求才能完成我們的軟件
但有些時候，我們的甲方并不知道為什么這個程序有那么多他沒有要求的（非功能性需求）
甚至有的時候程序本身也不知道。
程序大約是知道為什么有這么個約束條件的。

該圖中所有的方框性目標都是需求文檔的范圍
這張圖也許幫助我們了解了他的層次，但是，我們仍需要了解，其內容應當包括什么。

對于SRS軟件需求規格說明書。

該項說明書應當包含概述（包括特點，約束，目的，背景等），對整體項目的說明（以上為餅）。 數據描述，需求說明：功能說明與性能說明。運行環境規定，限制（deadline等）（以上為開發者視角）等。 用戶大約是不會拿到這個文檔的。 //參考百度百科

對于項目視圖與范圍文檔。

1.描述業務需求，簡述該項業務被提出的原因（市場方面），以及計算該項業務可能的利潤 2.項目視圖的解決方案。 該項表述對該業務需求的解決方案。（還未觸及代碼層，還是正常人能夠看得到的層次。） 但是，該項的假設和環境依賴是需要開發去思考的。（假設的意思大約就是說假設怎么做吧） 3.范圍和局限性。范圍其實就是目標客戶是誰。局限性是該項目不能做什么。 （局限性舉例，不能要求一個安保系統順便完成員工上下班打卡）。 4.業務環境。包括客戶概貌和項目優先級。看上去就像是這個環境內部的層次和對外的接口一樣。客戶概貌，包括各類客戶對該項目的觀感，收益等。項目優先級則是內部優先級的設置 5.產品成功的因素。鬼扯，天辯。

詳情可$參考道客88$的文檔，寫的很細，自己百度吧

對于用例文檔。（你寫過）

可直接參考老師發的作業，里面有個叫用例模板.doc的東西。那個就是最后的成品。
這是三方都能拿到的東西。

需求的質量特性：

• 需求說明的特征(也即需求文檔的要求)
  • 完整性
  • 正確性
  • 可行性
  • 必要性
  • 區分優先級
  • 無二義性
  • 可驗證性

$也就是：講完全，合需求，能完成，不多于，有先后，沒語病，能驗證。$

$這里對可驗證性作出說明：$
$指任意一項需求的實現都可以被觀測到。不能用主觀臆斷的方式來確定一項需求的實現。$

$需求的正確性的參考，來源于用戶提出的需求，這就是為什么正確性指向了"合需求"。$

• 規格說明的要求
  • 完整性
  • 一致性
  • 可修改性
  • 可跟蹤性

回目錄

uml

UML(Unified Modeling Language)統一建模語言，一種基于面向對象的可視化的通用建模語言。
模型->一個系統的完整的抽象(人能看懂，計算機還是看不懂）

希望小伙伴能夠聯想到數據庫的某些概念

UML包括多種圖，來完成建模。(標紅的部分是有超鏈接的)

• $用例圖$
• $類圖$
• 對象圖
• $狀態圖$
• $順序圖（序列圖/時序圖）$
• 交互圖
• $活動圖$
• 構件圖
• 配置圖

用例圖

由$Jocobson$提出,廣受IT界歡迎。
用于描述系統的$功能需求$,主要由$執行者（Actor）$、$用例（UseCase）$、$執行者和用例的關系$和$用例與用例的關系組成$。

執行者（Actor）

執行者（Actor）作為用例的啟動者，雖然在UML圖中用人形來表示，但現實生活中并不一定是人，也可以是某個外界系統。
$比方說對于路由器中傳輸數據的用例,它的執行者就是終端或者其他路由器。$
$但是對于重新設定路由器，他的執行者就應當是人$

用例（Use case)

用例是$系統$執行的一系列動作，在用例圖中用橢圓來表示它。本質上，一個用例是用戶與系統之間的一次交互作用。

• 用例捕獲某些用戶可見的需求，實現一個具體的用戶目標。
• 用例由執行者激活，并將結果值反饋給執行者。
• 用例必須具有功能上的完整描述。

所以，用例是直接和用戶相關的那一個小圓，內部的活動不是用例。
$即：用例是一個非void類型的函數（或方法），且用戶擁有包含該函數的JDK。$

不過這個JDK長這個樣子。

執行者與用例的關系

實際上已經在用例當中講到，用例與用戶之間是關聯關系，又稱通信關系。[1]

用例間的關系

• 1.泛化
  泛化表示用例之間的一般與特殊關系。
  在用例圖中，被空心三角形+實線指向的目標是父類。
  $我傾向于認為泛化關系是一種接口，或者說是擁有一個父類。$

  $泛化是一種關系，不是一個動詞。請不要想著誰是誰的泛化。$

  $用戶之間也是存在泛化關系的,該知識來源百度，尚未向老師證明$

• 2.使用
  表示一個用例使用另一個用例。
  在用例圖中，使用虛線+實心箭頭+“<<include>>”表示該關系。
  被指向者是源用例可以使用的用例。

• 3.擴展
  通過向被擴展的用例添加動作來擴展用例。
  在用例圖中，使用虛線+實心箭頭+“<<extends>>”表示拓展關系。
  被指向者表示是源用例可以做的下一個用例。

$這三個關系本身都是可以多對多的。公司董事可以是投資方也可以是員工。$

$總覺得這個寫的不好，歡迎提出更改建議$

建立用例的步驟

確定誰會$直接$使用該系統，即執行者（Actor）。

• 誰使用系統的主要功能（主執行者）？
• 誰需要從系統獲得對日常工作的支持和服務？
• 需要誰維護管理系統的日常運行（副執行者）？
• 公司的那個部門使用系統？
• 系統需要與其他那些系統交互？
• 誰需要使用系統產生的結果（值）？

確定每一個執行者所期望的功能，并把這些功能命名為用例。

• 與系統實現有關的主要問題是什么？
• 系統需要那些輸入/輸出？這些輸入/輸出從何而來？到哪里去？
• 執行者需要系統提供哪些功能？
• 執行者是否需要對系統中的信息進行讀、創建、修改、刪除、或存儲（RCUDS->read，create，update，delete，save）

繪制出用例圖，明確執行者與用例，用例與用例之間的關系。

對每一個用例進行描述。可以使用狀態圖、活動圖，也可以用文本型的用例文檔。

優化用例圖。如解決用例間重復與沖突問題，對復雜的用例圖可劃分出不同的層次。

$感覺不是很重要，為了方便記憶$
$從運維，正常使用，服務提供者三方面出發$
$思考他們需要什么，或者需要他們做什么，而得到初步的用例圖$
$然后描述每一個用例，最后做一次優化$

類圖//能畫就畫畫吧

類圖（Class Diagram）包含了一組類以及他們之間的關系，是一種靜態圖。
類就是屬性+方法的集合體。類比java即可。
這里類的關系包括關聯（association）、聚集（aggregation）、泛化（generalization）、依賴（dependency）。

關聯（Association）

該關系表示兩個類或多個類之間的對應關系。用java的視野來看，就是一方的類的屬性中含有對方的類的引用。
在類圖中，使用Ax———>yB表示關聯，說明A擁有B的引用。
這里的x，y表示個數，表示這一端的一個實例可以擁有多少個另一端實例。
xy可以在1，2，“n…m”，*這幾種格式中轉換。
“n…m”這種格式表示可以擁有[n,m]個實例。*表示任意個，包括0。

聚集（aggregation）

聚集表示整體和部分的關系，分共享聚集和組合聚集。

共享聚集使用A1———◇*B表示，表示A由B組成，但是就算沒有A，B也能夠存在。

組合聚集使用A1———◆*B表示，也表示A由B組成，但是如果沒有了A，B不能夠存在。
$無論是那種聚集，都是一對多的$

依賴（dependency）

表示兩個或多個類之間的調用關系。
用A—>B表示A依賴B。也就是A會去使用B的一部分。可能是A的屬性中有B的一部分，也可能是A的方法中把B當做了對象，也可以是調用了B類中的靜態方法。

泛化（generation）

與用例圖中的泛化相同，都表示其擁有共同父類。

建立類圖的步驟

研究分析問題領域，確定系統的需求

發現問題領域中的對象和對象類，明確它們的含義和責任，以確定屬性和操作。

發現類之間的靜態關系。著重分析找出類之間的一般和特殊關系，部分與整體關系，研究類的繼承性和多態性，把類之間的靜態聯系用關聯、泛化、聚合、依賴等關系表達出來

設計類與關系。調整和精化已得到的類和類之間的關系，解決諸如命名沖突、功能重復等問題。

繪制類圖并編制相應的說明。

$相比起用例圖，類圖更加側重于開發視角。$

狀態圖//建議畫一下

狀態圖（State Diagram）用于描述一個特定對象的所有可能的狀態及其硬氣狀態轉移的事件。
狀態 所有對象都具有狀態，狀態是對象執行了一系列活動的結果。當某個事件發生后，對象的狀態將發生變化。狀態圖中定義的狀態有：

• 初態–狀態圖的起始點。一個狀態圖必須有且只有一個初態。
• 終態–狀態圖的終點。一個狀態圖一般有多個終態
• 中間狀態–可包括兩個區域：名字域與活動域。
• 復合狀態–可以進一步細化的狀態稱作復合狀態。

狀態遷移-- A————>B,中間這個箭頭，表示狀態遷移。
在狀態圖中，該箭頭多附加一個事件在上面，表示該事件造成了狀態的遷移。如果沒有標明，則表示在源狀態執行完了內部活動后自動觸發了狀態轉移。

雖然在狀態圖中沒有表示，（至少我沒寫過）但是狀態圖是自帶幾個活動的。
entry/exit活動表示進入/離開該狀態必須要做的事情。
do活動知名在該狀態可以做的事情。（不包括entry和exit）

建立狀態圖的步驟

選擇初始狀態和終結狀態。

發現對象的各種狀態。注意應當仔細找出對問題有意義的對象狀態屬性，這些屬性具有少量的值，且該屬性的值的轉換受限制。狀態屬性值的組合，結合行為有關的事件和動作，就可以確定具有特定的行為特征的狀態。

確定狀態可能發生的轉移。注意一個狀態可能轉移到哪些樁體，對象的哪些行為可引起狀態的轉移并找出出發狀態轉移的時間。

把必要的動作加到狀態或轉移上。

分析狀態的并發和同步情況。

繪制狀態圖。

活動圖

活動圖（Activity Diagram）的應用非常廣泛，他既可以用來描述操作的行為，也可以描述用例和對象內部的工作過程，并可用于表示并行過程。
活動圖是由狀態圖變化而來的，他們各自用于不同的目的。活動圖描述了系統中$各種活動的執行的順序$。刻畫一個方法中所要進行的各項活動的執行流程。
而狀態圖表示個體的狀態的變遷。

活動圖的模型元素有：活動、轉移、對象流、泳道等。

活動

在活動圖中用圓角方框表示，也是構成活動圖的核心元素，是具有內部動作的狀態，由隱含的事件觸發活動的轉移。
在解釋活動時，需要從相應的角度出發來解釋。在解釋概念時，活動表示要完成的任務；在說明實現時，活動則是類中的方法。

轉移

即各活動之間的關系，描述由于隱含事件引起的活動變遷。使用———>表示
可以標注執行轉移的條件，不標注則為順序執行。

分支與合并。
分支，即一個活動轉移出了兩個活動。
合并，即兩個活動轉移向了同一個活動。

泳道

泳道進一步描述完成活動的對象，并聚合一組活動。也是一種分組機制。

在該圖中，泳道就是三個方框，置于其上的則是泳道的對象。
$在starUMI工具中，建議先生成泳道以防出現未知的bug$

對象流

活動圖中可以出現一個臨時的對象（泳道本身也是一個對象，只是在其內部還有方法序列），該對象可以作為活動的輸入與輸出。并且還有一個分支與一個合并。

在該圖中，獲取訂單時獲取了一個對象，并將該對象傳給了操作者讓其開始填寫訂單活動。操作者填寫完訂單后將對象傳給了銷售讓其交付訂單。
—　—＞用于指向對象流和從對象流指出，表示該對象的產生和傳輸方向。

建立活動圖的步驟

找出負責實現工作流的業務對象。這些對象可以是現實業務領域中的實體，也可以是一種抽象的概念或事物。為每一個重要的業務對象建立一條泳道。

確定工作流的初始狀態和終結狀態，明確工作流程的邊界。

從初始狀態開始，找出隨時間而發生的活動，把他們表示成活動狀態。

對于復雜的動作或多次重復出現的一組動作，可以把他們組成一個活動狀態，并且用另外一個活動圖來展開表示。

給出連接活動的轉移。首先處理順序活動流，然后處理條件分支。最后處理分叉和接合。

在活動圖中給出與工作流程有關的重要對象，并用虛箭線把他們與活動狀態相連接。

順序圖

順序圖(Sequence Diagram)用來描述對象之間動態的交互行為,著重體現對象間消息傳遞的時間順序。
順序圖存在兩個軸:水平軸表示一組對象,垂直軸表示時間。
順序圖中的對象用一個帶有垂直虛線的矩形框表示, 并標有對象名和類名。垂直虛線是對象的生命線,用于表示在某段時間內對象是存在的。
對象間的通信通過在對象的生命線之間消息來表示，消息的箭頭類型指明消息的類型。

對象

對象用矩形框圖表示，它們代表參與交互的對象。
"name: ClassName"來標記

生命線

生命線表示對象存在的時間，在順序圖中生命線表示從對象圖標向下延伸的一條虛線。生命線從對象創建時開始到對象消亡時終止，對象存在的時間有多長，說明對象的生命線的虛線就有多長。

激活

激活是過程的執行的時間，包括它等待嵌套過程執行的時間。當一個對象在激活期時，該對象處于激活狀態，能夠響應或發送消息，執行動作或活動。當一個對象不在激活期時，該對象處于休眠狀態，什么事都不做，但它仍然存在，等待新的消息來激活它。

消息

在面向對象技術中，對象間的交互是通過對象間消息的傳遞來完成的。在UML的所有動態圖（活動圖、狀態圖、順序圖和協作圖）中，消息作為對象間的一種通信方式來表示。

• 簡單消息(Simple Message)：表示簡單的控制流。用于描述控制如何在對象間進行傳遞，而不考慮通信的細節。
• 同步消息(Synchronous Message)：表示調用的控制流。操作的調用是一種典型的同步消息。調用者發出消息后必須等待消息返回，只有當處理消息的操作執行完畢后，調用者才可繼續執行自己的操作。
• 異步消息(Asynchronous Message)：表示異步控制流。當調用者發出消息后不用等待消息的返回即可繼續執行自己的操作。異步消息主要用于描述實時系統中的并發行為。
• 返回消息(Return Message)：將一個簡單消息和一個同步消息合并成一個消息，即操作調用一旦完成就立即返回。

建立順序圖的步驟

確定交互的上下文。

找出參與交互的對象類角色，把他們橫向排列在順序圖的頂部，最重要的對象安置在最左邊，交互密切的對象盡可能相鄰。在交互中創建的對象在垂直方向應安置在其被創建的時間點處。

對每一個對象設置一條垂直的向下的生命線。

從初始化交互的信息開始，自頂向下在對象的生命線之間安置信息。注意用箭頭的形式區別同步消息和異步消息。給出消息標簽的內容。

在生命線上繪出對象的激活期。

根據消息之間的關系，確定循環結構及循環參數和出口條件。

包圖//PPT就倆張咱也不懂,也不是特別重要的部分

表示包之間的關系的圖。一個包可能是一個用例，或者一個系統。參考java的包。
主要是依賴關系（數據庫第6章關系的依賴），包圖中—>，箭頭指向即被決定者。

回目錄

恭喜你看到這里啦！距離60分就差一點點了加油啊！

需求獲取

愿景

定義：向往的前景，愿景是為整個軟件開發的組織服務，對于軟件項目，愿景通常也是由關鍵性客戶或公司的重要管理者提出。軟件項目的愿景來源于不只一個人。
同一個項目在不同的角度來觀察，這個項目的意義是不一樣的。（包括用戶，開發，客戶）。
那么在這里必須確定權重，也就是誰最重要，誰是最有權力的涉眾，必須滿足的來源。即：老大。（一般屬于客戶，也一般不會在系統中看到老大存在）
在“老大”看來：為什么要開發這個項目。就成為了愿景，這份愿景就是整個項目的核心價值目標。
要完成一個價值目標，就應該有多份指標來確定項目的完成度。這里的指標，也就是度量指標，它不應當是某樣事物本身（比如建立什么系統，擁有什么功能，這種看上去像目標的）。他應當是減少什么時間，提高效率，一切能夠被計算出效果的東西。（筆試情況下請認準“加速”，“提質”，“有無”等字眼，這些對標度量指標）
$實際情況下，度量指標是被量化的，也就是可以被計算，也不是加速，提質這種還是略顯空的字眼$

$愿景來源于老大，且必須有度量指標（愿景的兩個要點）$

涉眾

客戶：最大的涉眾
用戶：越是一線用戶，往往排位越低。資本往往不會在意韭菜的想法
用戶甚至不是涉眾的必須項。有些系統開發出來是為其他系統服務的。

涉眾存在的意義：項目是為了完成某個目的而存在的，但是完成目的的方式是多樣的。但是業務需求（涉眾利益）是穩定，不易變的。
沒人在意你用printf還是println完成輸出

回目錄

業務建模

目的：描述顯示，幫助發現軟件需求。
UML用兩種模型描述顯示：業務用例模型和業務對象模型。

業務單元

在講這個概念之前，我們要先講業務實體——也就是這個業務的直接指向。而業務單元則稍稍細一些——指向我們需要修改的對象。就比方說看病，看的肯定是人（業務實體），但具體要看的實際上是你的病變器官（業務單元）。$自己的理解$
可能太生動了,我們用另一個例子。當一個公司打算做貫標工作時，需要開發系統來管理文檔。那么此時的業務單元就是貫標工作小組（不知道啥是貫標的請移駕百度），業務實體就是整個公司。
業務單元是一個組織或者是人群，不一定是整個目標。

業務執行者

在$業務之外$和業務交互的人或組織。

<span id="Business_worker>業務工人

在業務之內承擔服務的人。

業務實體

$待補充,我會問老師業務實體和業務單元的區別的！！！$

業務用例

業務用例，也就是我們的用例圖中的重點，用例。兩者其實是一樣的，其本質仍是：用戶與系統之間的一次交互。也是將用戶所需的信息輸出返還。
所以依著這個本質，系統內部的活動不是業務用例。
在描述時，用業務語言而不是技術語言。
同時，在描述時，使用動賓結構，且使用清晰地表達。
$不要使用服務,數據等較為籠統的說法。$
$先確定這是一個業務！使用籠統的說法可能會導致這變成一個功能。$

$用例的粒度,我還不知道是什么。大致上就是講一個用例的細分程度？$
$過細的用例容易被視為是CRUD（創造，讀取，更新，刪除），過粗又趨向功能$
當然，也可以使用.用例圖.活動圖.順序圖方式來描述用例的地位和實現。
$用例是系統做的事情，除非是智能化，這個系統是不能處理數據的$

業務對象模型

業務對象模型（領域模型）是描述業務用例實現的對象模型。它是對業務角色和業務實體之間應該如何聯系和協作以執行業務的一種抽象，注重業務中承擔的角色及其當前職責。
官話講完，說人話。業務對象模型就是從各個角色出發來觀看一個業務是怎么創生又是經過了誰的手做了什么事。
再簡單一點，誰對什么東西做了什么事。
比如我今天去找銀行辦銀行卡。顯然這在用例圖（業務用例模型）中就是一個人后面拉條先再畫個圓里邊寫個辦理銀行卡。
那在業務對象模型呢。那就有這么幾個對象：申請者，前臺，申請單，銀行卡。好了我想你已經能get我的點了。誰還沒辦過銀行卡啊？

一些常識收錄

經過我校高層管理人員的不懈努力，已經和百度在網絡技術(北京)有限公司達成戰略合作，以后凡是本校學生，將可以使用
www.baidu.com在上面搜索任何問題，無需詢問同學各種學術問題，將極大程度的提高學生自己的獲取知識的能力。
爽
本篇文章已更新至：基礎知識，需求獲取。
目前正在更新：需求分析。
還剩：未知。

本文檔中，$紅字，表示一般的重點項$
$紫色，表示對某些人物的尊敬$
$藍色，是我個人認為的難點$
$綠色，表示一些自己添加的注釋$
帶刪除的字樣一般表示玩樂性質的注釋

$需求分析是一切軟件開發的基礎$
$也是軟件開發過程中“最關鍵性的和最易出問題的地方$

本門課程最核心的理論需求能用一個圖簡單的反應出來

最為困難的概念性工作便是編寫出詳細技術需求

探索系統需求就是探索涉眾利益的平衡點。

$寫在最后，給我自己,如果圖片顯示不出來了一定要記得把路徑寫對啊！！！$
$寫在最后，給我自己,記得去問老師業務實體和業務單元的區別啊！！！$
$寫在最后，給我自己,記得去問老師用例的粒度是什么啊！！！$
回目錄

。

本文檔中，$紅字，表示一般的重點項$
$紫色，表示對某些人物的尊敬$
$藍色，是我個人認為的難點$
$綠色，表示一些自己添加的注釋$
帶刪除的字樣一般表示玩樂性質的注釋

$需求分析是一切軟件開發的基礎$
$也是軟件開發過程中“最關鍵性的和最易出問題的地方$

本門課程最核心的理論需求能用一個圖簡單的反應出來

最為困難的概念性工作便是編寫出詳細技術需求

探索系統需求就是探索涉眾利益的平衡點。

$寫在最后，給我自己,如果圖片顯示不出來了一定要記得把路徑寫對啊！！！$
$寫在最后，給我自己,記得去問老師業務實體和業務單元的區別啊！！！$
$寫在最后，給我自己,記得去問老師用例的粒度是什么啊！！！$
回目錄

總結

以上是生活随笔為你收集整理的软件工程复习总结的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。