qileilove

          blog已經轉移至github,大家請訪問 http://qaseven.github.io/

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

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

            一、業務分析與需求收集

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

          posted on 2012-06-15 11:03 順其自然EVO 閱讀(286) 評論(0)  編輯  收藏


          只有注冊用戶登錄后才能發表評論。


          網站導航:
           
          <2012年6月>
          272829303112
          3456789
          10111213141516
          17181920212223
          24252627282930
          1234567

          導航

          統計

          常用鏈接

          留言簿(55)

          隨筆分類

          隨筆檔案

          文章分類

          文章檔案

          搜索

          最新評論

          閱讀排行榜

          評論排行榜

          主站蜘蛛池模板: 宜都市| 海南省| 新巴尔虎左旗| 华亭县| 惠来县| 西宁市| 沙河市| 高淳县| 禹州市| 桐乡市| 延川县| 仙桃市| 芒康县| 房山区| 虎林市| 当涂县| 罗甸县| 合作市| 衡水市| 大城县| 正蓝旗| 改则县| 卓尼县| 八宿县| 浦县| 滨州市| 武冈市| 西华县| 鄱阳县| 利辛县| 长白| 白朗县| 横峰县| 锡林浩特市| 江城| 南溪县| SHOW| 长泰县| 安顺市| 昭苏县| 绥芬河市|