最近又開始做專案，一直對軟體構建流程中的需求分析與設計沒有很明確的節奏，這次想根據我們團隊的開發節奏邊做邊整理，希望固化這些東西不用每次都思考，
不能說是最優，但起碼能夠給一些沒有固定打法的同學一些建議。
相信會有很多人在拿到原型之後會不知所措，不知道怎麼看原型，不知道怎麼抽取核心業務，不知道根據核心業務怎麼抽取類，
前面的一篇部落格可以給你一些思路：根據產品原型如何抽取主流程
以前一直沒有找到主流程的意義，現在終於知道，它的確可以指導我們看原型而且不會偏離主業務。
這第一步就是：我們根據主流程的流向和節點可以找出對應的頁面。
根據主流程找到頁面之後，從左到右從前到後乙個名詞都不放過，
把你所有認為可以作為備選的全部列出來。
走到這一步你會發現，你的名詞列表會很多，別著急做一下操作可以幫助你簡化你的名詞列表。
在做專案中我們難免會做超出我們認知範圍內的領域知識，找產品和客戶搞清楚這些名詞的含義這一點很重要，
因為一旦這個名詞作為類之後，可以幫助我們確定這個類的職責。
如果兩個名詞在概念上比較相似，但是表面詞語不太一樣的可以將這兩個詞歸為一類，
刪除多餘的名詞。
有一些名詞都是可以分到乙個組中去的，比如：程式設計師，人事，cto,都是公司的員工，
所以可以分到員工組中。
根據流程圖，找到對應的頁面，乙個乙個頁面去驗證：
流程裡的所有名詞是不是都有對應的類（或者類裡的屬性），
如果沒有的話，就說明不符合，如果都覆蓋了，就說明滿足。
注意：乙個系統不會有太多的名詞，名詞越精簡越有利於你理解系統。
你可以根據你的名詞列表建立對應的類圖，這個時候不用體現屬性。
給每乙個類確定乙個職責，因為只有明確這個類的職責定義清楚，你才可以確定哪些屬性應該放到哪個物件上。
乙個系統中的類不可能獨立存在而和其他的類沒有任何關係，那這個類可以考慮刪掉了，
我們需要梳理清楚某個類都和其他的類有什麼關係。
確定類的關係，可以參考另外一篇部落格:我對uml類圖關係的理解
根據類的職責結合原型中的資訊，將屬於這個類的屬性放到這個類上。
注意：在類圖上新增屬性的時候，只存放屬於自己的屬性，所依賴的物件可以通過關係去體現。
比如：學校和學生是乙個單獨的類，學生裡要有乙個學校的屬性那這個屬性要不要在類圖上體現，
建議是通過關聯關係或者依賴關係的圖形表示。
根據產品原型如何抽取主流程
今天向我們大神和團隊小夥伴請教了這個問題，分享給大家，也是在摸索後面有新的體會和感悟會持續更新。流程是有幾個要素 1.有開始 2.有結束 3.有節點 其中包括動作節點以及判斷節點等 4.有流向 諸如 這就是乙個簡單的流程圖。換句話說就是如何從原型找到這個產品的入口。有兩種方式獲取 1.在產品講解原型...
元件主流程
元件例項化期間 1.生成子元件 包括不變的子元件和變化的子元件。後者的例項可以在其它時機動態生成 2.設定預設屬性 3.新增系統級事件 4.新增自定義事件 5.為元件本身以及固定子元件附著渲染器 由元件外部呼叫 enterframe週期 6.渲染 由元件外部的渲染管理器呼叫 6.1.將子元件 不變的...
Linux程序切換主流程
linux切換並沒有使用x86cpu的切換方法，linux切換的實質就是cr3切換 記憶體空間切換，在switch mm函式中 暫存器切換 包括eip，esp等，均在switch to函式中 這裡我們講述下switch to主流程 1.在switch mm函式中將new task pgd設定到cr3...