天天看點

面向對象的軟體分析設計過程備忘面向對象的軟體分析設計過程備忘

  一、業務分析與需求收集

  1、重點梳理主業務流程,逐漸完善分支流程。整理和發現業務流程中的涉衆以及他們的業務目标和系統目标,顯式目标以及隐式目标;

  2、整理涉衆們在系統中所承擔的角色以及各自的職責;

  3、在流程的運轉過程中,發現和查找業務實體、他們之間的關系以及關鍵實體的生命周期(由誰在什麼場景下建立、中間狀态的變化以緻最後的消亡);

  4、在流程的運轉過程中,有哪些業務規則以及各種隐式的規則;

  5、不斷的提問和驗證流程的正确性和完整性(即使是邊界以外的流程也不要放過,最少要做到心中有數)。是否有遺漏的涉衆?是否有遺漏的職責或者行為?是否有遺漏的實體?是否有遺漏或者未被發現的實體關系?實體的生命周期是否完整?收集的需求或者資訊能否支撐整個流程的運轉,需求與需求是否有互相沖突之處?是否有履行同樣職責的人或者物(需要合并或者抽象)?多退少補!

  6、劃分業務邊界與系統邊界,哪些是需要由系統來完成的職責,哪些是由别的系統或者人工完成的職責。

  7、可借助uml的元件圖或者時序圖、活動圖、狀态圖來完成high level層面的流程整理和業務模組化。

  二、概要設計(用例驅動功能需求,認真對待非功能性需求)

  1、整理系統用例以及他們的參與者與系統邊界。系統用例與服務最為密切,通常會演變為最後的服務接口。可借助uml用例圖來完成用例模組化。

  用例的特征:

  用例的粒度:

  在概念模組化階段:粒度以能描述一個完整的事件流為宜;

  在系統模組化階段:粒度以能描述操作者與計算機的一次完整互動為宜;

  用例不是功能,用例是參與者對系統的期望以及目标,功能則是達成這個目标的步驟而已。

  2、用活動圖或者時序圖描繪重點用例及其場景。

  設計目标:為了完成該用例,需要由哪些角色介入協作完成,他們各自的職責是什麼?隻關注做什麼,目前階段不需要關注怎麼做(不同階段不同視圖所關注的問題是不一樣的。不分階段不分視圖的天馬行空式的混沌思維,不是科學的分析方法,隻會把問題複雜化)。

  3、完成目前用例有哪些規則,以及需要建立哪些實體,之後需要明确實體與實體之間的關系(關聯?聚合?一對一?一對多?)。

  4、隻需要針對核心和關鍵的用例模組化,循環疊代。

  5、劃分高層職責、确立彼此之間的互動方式及其主要互動資料。

三、詳細設計(在概要設計的基礎上演進與精化,隻需要針對核心和關鍵的用例模組化)

  1、根據之前的用例設計,定義服務接口并确定接口參數與傳回值。

  2、根據概要設計過程中的活動圖和時序圖,将完成相應職責的角色或者對象設計為相應職責的類或者接口,并将關鍵步驟定義為該類或接口的方法,并确定方法參數與傳回值,可借助uml類圖來完成接口、類的模組化。

  3、分析模型的變化點,對于清晰明确的變化點,建立抽象模型以适應變化并設計已知實作。對于相對模糊不清的變化點,建立抽象模型,隔離變化,将問題集中到一個局部的點,可在之後變化點明朗化之後重構(隻影響某個局部的點)。概要設計階段我們思考“做什麼?”,目前階段我們需要思考“怎麼做?”,或者是技術選型,或者是架構模式,需要做出決策。

  4、認真思考類或者接口中的每一個屬性、方法以及方法參數。精煉、精煉、再精煉!

  取一個好名字;

  方法的設計應當具備原子性與職責單一性,方法參數清單也應當盡量精煉,越是簡單的方法越容易被組合與重用。

  隻暴露需要暴露的服務與接口方法,不多暴露一個不需要暴露的服務與接口方法。沒暴露的方法可以随意重構與擴充,方法一旦暴露出去,就需要一直維護并保持其相容性。

  5、不要考慮實體的儲存形式,我們需要思考的是設計一個類,該類當中應該有哪些屬性與方法,以及每個屬性的适用場景與業務含義。

  任何形式的資料都應該能轉換為oo設計中的類對象。可存儲可配置的場景也應該可以通過api來實作,java是程式語言,任何形式的資料表現形式,最後還是通過相應的類及其方法調用來完成相應的職責。

  6、隻需要針對核心和關鍵的用例模組化,循環疊代。

  7、劃分高層職責、确立彼此之間的互動方式,建立高層接口以及通訊方式,确定通訊協定以及封包格式。

  注意:

  a、實體模組化時,需要認真思考實體的每一個屬性,明确其使用場景與業務含義。同一個人在不同的場景下可能扮演不同的角色,角色的不同決定了其屬性也不同。jack在家是父親的角色,他同時也是一個教師,是以“課程”是教師的屬性而不是父親的屬性,即使他們都屬于jack這個次元。請參考dci的設計理論。

  b、實體模組化時,即使需求方沒有提出有關需求,但仍需要維護某些關系。實體與實體關系是在某個業務場景下客觀存在的,如果因為需求方暫時沒有提出相關需求,而放棄或者丢失客觀存在的實體關系,一旦今後提出相關需求,可能會帶來相當大的重構代價。

====================================分割線================================

最新内容請見作者的github頁:http://qaseven.github.io/