使用業務序列圖原因：
一、活動圖只關注人，序列圖把人當作系統。活動圖描述流程時，往往會忽略了非人工系統的責任。
二、活動圖表示動作，序列圖強迫思考動作背后的目的。序列圖不但表達非人工系統的責任，也揭示出某個崗位對外暴露的責任，序列圖可以在業務建模和系統建模的過程中始終貫徹“對象協作以完成用例“的思想。
三、活動圖更“靈活”，序列圖更不“靈活”。“很容易畫”的活動圖容易掩蓋開發人員對業務流程認識不足或者業務流程本身存在缺陷的事實。序列圖強迫開發人員通過alt、loop等結構化控制片段描述業務流程的方式去思考，通過故事來思考待開發系統的位置。
?
python讀書筆記。業務序列圖要點：
一、消息代表責任分配而不是數據流動。在序列圖中，焦點是對象之間的責任和寫作，數據流是作為消息的輸入輸出參數存在的。建模人員不但要看到數據的流動，還要找出背后的責任。消息代表對他人提供的服務，如果沒有指定目的可以用“處理...”來命名，消息名稱中不需要帶“請求”二字，箭頭已表明請求的意義。
二、聚焦于系統之間的協作。業務建模研究的焦點是組織，所以業務序列圖上對象的最小單位是人肉或非人肉系統。建模的基本原則是抽象級別的一致，勿需細化到每一步操作。
三、只畫核心域相關的系統。一個智能系統要不要成為序列圖上出現的業務實體，要根據“它是否核心域內的系統”來判斷。
四、把時間看作特殊的業務實體。這樣便可以映射到系統用例的時間執行者。注意，時間是外系統，世上只有一個時間系統，定時器是其他系統用來和時間大交道的邊界類，定時器會有無數個。
?
《教學機智》讀書筆記摘抄、a.繪制現狀業務序列圖：現狀好比拿著攝像機去拍攝，會拍到什么？把拍到的場景如實繪制成業務序列圖。根據不同的業務用例，會有多個業務序列圖。
應避免的錯誤：
一、把“現狀”誤解為“純手工”。業務流程中有人工系統也有非人工的系統，新系統的需求需要通過研究業務現狀，再結合愿景推導得出。
二、以待開發系統為中心拼湊流程。業務建模時，攝像機應該一路跟隨著實現業務用例的流程去拍攝，如實反映拍攝的故事，各個系統知識流程中的一個零件。業務建模就是要從業務流程中待到代開發系統的位置，證明該系統對實現業務用例是有幫助的。
b.繪制業務交互概述圖：將各個業務用例的序列圖串聯起來。
c.改進業務序列圖：挑選一個最值得改進的業務序列，闡明原因，然后空降一個系統，畫出改進后的序列圖，從而得到第一批用例。注意UML建模不是為了“先建模后需求在分析”的順序而使用，而是迅速定位最值得改進點，得到最有價值的用例，先開發。這才是敏捷。
一篇讀書筆記、改進途徑：
一、物流變信息流。為降低流轉成本，盡可能把物流變成信息流，在需要物的時候才將信息變成物。
二、改善信息流程。可以依靠引入一個新的系統來達到在多個信息系統之間實現信息傳遞和協調。
三、封裝領域邏輯。通過將人腦中的領域邏輯提煉封裝到信息系統中，使人腦得到解放。在繪制業務流程時，非常重要的改進點是：一定要注意畫出人腦中的思考邏輯，避免白開水一樣的業務流程。前兩條改進，系統內部封裝邏輯不復雜，效率高，而做到第三條，就可以靠軟件的功能就能賣錢。
四、阿布思考法。
改進思路是：
專門寫讀書筆記的軟件、1.假設有足夠的資源去解決問題，得到一個完美的方案；
2.用手上現有的資源去山寨這個完美方案。例如：中國組織最得力的會議是靠人腦組織的全國人民代表大會，做會議軟件的話可以山寨一二。
?“創新的需求是從觀察和思考的汗水中來，不是把拍腦袋閉門造車的所謂‘頭腦風暴‘當作調研”。
?
2-系統建模：與業務建模不同的是研究對象，業務建模的對研究對象是組織，而系統建模的研究對象是系統。
1.畫出系統用例圖：有了業務建模的鋪墊，系統用例實際上以呼之欲出。
方便做讀書筆記的app？1). 系統用例圖：
a. 確定系統執行者：系統執行者的定義是在所研究系統外，與該系統發生功能性交互的其他系統。有了前面的業務建模，就不需要頭腦風暴了，直接從業務序列圖映射即可得到系統執行者。
理解要點：
一、系統外：系統執行者不是所研究系統的一部分，而是該系統邊界外的一個系統。這里的邊界指的是責任的邊界而非物理的邊界。
二、交互：系統執行者必須和系統有交互，不和系統交互的不算是系統的執行者。系統執行者和重要無關，系統執行者只關注誰和這個系統接口，而正真和重要相關的概念是涉眾。用例必須在它的路徑、步驟、補充約束中考慮這些涉眾的利益。
三、功能性交互：執行者和系統發生的交互是系統的功能需求。
讀書筆記的正確格式、四、系統：系統可以是人肉系統，也可以使一個智能系統，甚至是一個特別的外系統——時間。
?
業務建模映射出系統執行者的方法：與系統交互（存在實的消息線）的人肉系統或其他系統即為系統的執行者。
注意事項：實際工作中，系統執行者和系統用例是一起識別的。
一、不要把執行者和權限管理混淆。用例的主執行者只是表明這個用例是為這一類執行者而做，但不代表系統一定要有權限控制以防止其他的人或電腦系統使用該用例。
b. 系統用例：系統用例的定義是系統能夠為執行者提供的，涉眾可以接受的價值。
數據結構讀書筆記、用例識別要點：做需求的目的不是為了安慰自己或者走過場，而是讓產品更加好賣，不以這個為出發點的需求工作是沒有意義的。即使再難，也只能從涉眾的視角來定義需求，切不可貪圖方便選一個自己熟悉的視角了事。
?
一、系統用例可以看做系統執行者和系統之間買賣的平衡點，期望和承諾的平衡點。系統用例可以把需求提升到思考系統“賣什么”的高度。（搞清自己的“用例”，認清自己的定位。）
二、思考用例的過程就是發現價值的過程。
三、“粒度”的問題。開發人員切勿玩弄“粒度原則”、“分層技巧”，應該把屁股挪到涉眾那邊去，揣摩涉眾的心理，實事求是的寫下來。
對于判斷“用例是否用對”的標準：是否加強了和涉眾的聯系，如果不是，那就用錯了。
程序員筆記、業務建模映射出系統用例的識別方法：在業務序列圖中，從外部指向所研究系統的消息可以映射為該系統的用例。
識別系統用例的注意事項：
一、主執行者和輔執行者：主執行者從執行者指向用例，而輔執行者從用例指向執行者，主執行者發起用例的交互，輔執行者在交互過程中被動參與進來。場景：主執行者要執行用例，需要輔執行者的幫忙。
二、切勿把到輔執行者的箭頭誤解為數據傳送的方向。
三、主輔執行者是針對某個用例來說的，一個系統在這個用例中充當主執行者，也可以在另一個用例中充當輔執行者。一般說來，輔執行者是人肉系統的情況比較少，更多時候是另一個非人智能系統。
四、用例是涉眾愿意“購買”的、對系統的一種“用法”，只要涉眾愿意“購買”，當然是越多越好。
華為工作法讀書筆記、五、需求是不考慮“復用“的，如果在考慮”復用“，要緊惕自己是不是已經轉換到了設計視角來思考問題。
六、針對不同執行者、不同業務流程，系統提供的價值可大可小，無論大小均是用例。
七、用例的命名。用例命名采用"動賓結構"，賓語前可以加定語，把一句話的主語砍掉，剩下的可以做用例的名字。
?
常見錯誤：踏實研究業務流程，做好業務建模，盡量從業務序列圖中映射出系統用例，這樣的系統用例是不會騙人的。
一、把步驟當作用例。Include（包含）關系的目的是為了復用在多個用例中重復出現的步驟集合，形狀往往是多個大用例Include一個小用例。
時間管理讀書筆記？二、CRUD問題。把數據庫的各個表名加上新增、檢索、修改、刪除就得到了用例的名字或者把四種操作合并稱為“XX管理”。
三、玩弄“復用”：用例的執行者不同，背后的涉眾利益也有差別，不能簡單的合并復用為某一個操作。
四、多個主執行者指向同一個用例。如果用例圖已完成，對于這種錯誤的修改，可以通過泛化出抽象的執行者或者分成幾個不同的用例的方法來修改。后一種更常見。
五、玩弄”層次“。切勿偷換"研究對象"，也切勿”把愿景當系統功能“。
六、玩弄”子系統“：用例很多時可以將用例分包，但用例包是在系統的外部對系統功能所做的劃分，而子系統則是根據內部部件的耦合和內聚切割得到。
七：模糊的價值：系統往往無法承諾執行者預期的價值時，則該價值不是執行者的用例。主執行者執行用例時，若是需要輔執行者提供實時的幫助后才能進行，則用例正確，否則用例錯誤。
