【課程背景】
好像總是沒有足夠的時間來完成建模、分析和設(shè)計工作,總是過早地進(jìn)入到編碼階段。沒有分析設(shè)計工作給編碼質(zhì)量帶來巨大的隱患。要提高代碼的質(zhì)量,必須遵循軟件工程的基本規(guī)律。
ICONIX是面向?qū)ο蟮木喌拈_發(fā)過程的方法論。研究的是如何使用較少的投入完成從需求到編碼的過渡。
本課程綜合并精簡了面向?qū)ο蟮姆治鲈O(shè)計過程,形成了從需求到編碼較小的工程活動集合,即能保證編碼的質(zhì)量,又能保證開發(fā)效率,確保開發(fā)過程中的每個活動都具備不可或缺的價值,而不是在做無用功。
本課程講解了如何把用例分析、領(lǐng)域模型、健壯性分析、動態(tài)模型、靜態(tài)模型等面向?qū)ο蟮姆治鲈O(shè)計活動合理的組織起來,并對每個工程活動如何執(zhí)行、何時執(zhí)行、執(zhí)行的程度與結(jié)果都給出了明確的要求。
【培訓(xùn)特色】
1.案例貫穿始終。使用實際的項目,把需求建模、分析、設(shè)計完整做一遍,通過案例講解每個步驟的做法。
2.經(jīng)驗分享。在每個工程活動中,總結(jié)常犯的錯誤及其解決方案。
3.現(xiàn)學(xué)現(xiàn)用。在隨堂練習(xí)中鞏固課程的效果。
【目標(biāo)收益】
通過ICONIX過程把建模、分析、設(shè)計技術(shù)貫穿起來,把需求順滑的過渡到設(shè)計,再有設(shè)計過渡到編碼,每次過渡都是無縫鏈接,確保開發(fā)過程的質(zhì)量。
? 如何建立系統(tǒng)模型?
? 如何把面向?qū)ο蟮哪P团cMVC建立關(guān)系?
? 如何分配類的職責(zé)?
? 如何建立靜態(tài)模型?
? 哪些動態(tài)模型是有價值的?
【培訓(xùn)對象】
需求分析師、軟件設(shè)計師、軟件工程師、項目經(jīng)理等
【課程大綱】
主題 |
內(nèi)容 |
第一部分 ICONIX過程概述 |
討論:代碼為啥改來改去? 如何使用最少的投入完成從需求到編碼的過度 較小UML建模技術(shù)—ICONIX思想 構(gòu)造系統(tǒng)時的重要問題 誰是系統(tǒng)的用戶(參與者),他們想完成何種工作? 何為“現(xiàn)實世界”(問題域)對象,它們之間存在何種聯(lián)系? 每個用例需要何種對象? 在每次用例交互,對象是如何協(xié)作的? 如何處理實時控制問題? 在具體細(xì)節(jié)上,實際上準(zhǔn)備如何建立該系統(tǒng)? ICONIX OOA&OOD框架 ICONIX過程—4個階段 |
第二部分 面向?qū)ο蠓治?/span> |
繪制高層類圖 領(lǐng)域建模 領(lǐng)域的概念 領(lǐng)域建模的目的 領(lǐng)域建模的產(chǎn)出 域類的較佳來源 領(lǐng)域建模的活動: 識別類 建立歸納關(guān)系 建立類間關(guān)聯(lián) 開發(fā)關(guān)聯(lián)類 繪制高層類圖 領(lǐng)域建模訓(xùn)練 領(lǐng)域建模綜述 領(lǐng)域建模10個典型的錯誤 ? 10.立刻給關(guān)聯(lián)指定多重度(multiplicity),確保每個關(guān)聯(lián)都有明確的多重度 ? 9.對名詞和動詞做過度的分析,而背離初衷 ? 8.不對用例和時序圖進(jìn)行研究,就將操作分配給類 ? 7.在確保已滿足用戶需求之前,對代碼進(jìn)行優(yōu)化以提高重用性 ? 6.對于每個“部分(part-of)”關(guān)聯(lián),就使用聚集還是組合(composition)而爭論不休 ? 5.未對問題空間進(jìn)行建模之前,就假定一種具體的實現(xiàn)策略 ? 4.將類命名為難以理解的名稱,而不是直觀的名稱 ? 3.直接進(jìn)行實現(xiàn)結(jié)構(gòu),如友元關(guān)系和參數(shù)化類 ? 2.在域類和關(guān)系型數(shù)據(jù)庫表之間建立1對1的映射 ? 1.對早的執(zhí)行“模式化”,將導(dǎo)致根據(jù)同用戶問題毫無關(guān)系的模式創(chuàng)建解決方案 用例建模 用例的基本概念 用例建模的目的 用例建模的產(chǎn)出 分析層用例 設(shè)計層用例 用例之間的關(guān)系 歸納關(guān)系 包含關(guān)系 擴(kuò)展關(guān)系 用例圖 用例描述 練習(xí):用例建模 原型 原型概述 原型法工作流程 原型法的優(yōu)缺點 關(guān)于原型系統(tǒng)的基本原則 ? 區(qū)分兩種原型系統(tǒng): 拋棄型原型 演化型原型 ? 原型化難以理解的需求 ? 盡快將拋棄型原型交付給客戶,不必考慮質(zhì)量 ? 必須注意精選正要開發(fā)的原型系統(tǒng)所包含的特性,使其能真正達(dá)到預(yù)期的目的 ? 決不把拋棄型原型系統(tǒng)發(fā)展成為系統(tǒng) ? 利用原型減少軟件開發(fā)的風(fēng)險 與原型有關(guān)的度量數(shù)據(jù) 需求評審 需求評審10條典型的錯誤
|
第三部分 面向?qū)ο蟪醪皆O(shè)計 |
面向?qū)ο蟪醪皆O(shè)計概述 建立需求與設(shè)計之間的橋梁 健壯性分析 健壯性分析的目的 健壯性分析的產(chǎn)出 健壯性分析的流程 ? 1,檢查用例的正常性 ? 2,檢查用例的完整性 ? 3,對象確認(rèn) ? 4,初步設(shè)計:對象分類 ? 5,執(zhí)行健壯性分析 ? 6,更新域(靜態(tài))模型 對象分類 ? 邊界對象 ? 實體對象 ? 控制對象 健壯性圖的規(guī)則 ? 動作者只能與邊界對象交談 ? 邊界對象只能與控制體和動作者交談 ? 實體對象只能與控制體進(jìn)行交談 ? 控制體即能跟控制對象交談,也能跟邊界對象交談,不能跟動作者交談 案例:健壯性分析 練習(xí):健壯性分析 健壯性分析與靜態(tài)模型的反饋循環(huán) 初步設(shè)計評審
|
第四部分 面向?qū)ο笤敿?xì)設(shè)計 |
面向?qū)ο笤敿?xì)設(shè)計概述 面向?qū)ο笤敿?xì)設(shè)計 詳細(xì)設(shè)計的目的 詳細(xì)設(shè)計的產(chǎn)出 詳細(xì)設(shè)計的流程 動態(tài)模型 時序圖 狀態(tài)圖 活動圖 協(xié)作圖 動態(tài)模型注意點 ? 過度使用這些圖會導(dǎo)致分析崩潰 ? 不要為具有兩種狀態(tài)的對象繪制狀態(tài)圖 ? 協(xié)作圖在實時、分布式系統(tǒng)中是實用的 ? 要避免分析崩潰就要知道需要建立那些模型 ? 不要為建模而建模 10個繪制時序圖的要點 ? 10.需要為每個用例繪制一張順序圖。 ? 9.順序圖應(yīng)該匹配于相關(guān)用例的敘述流。 ? 8. 為每一個完整的用例繪制一張唯一的時序圖,只有管理唯一的順序圖非常困難的時候,才把圖分開。 ? 7.對象間的消息調(diào)用類上的操作。 ? 6.如果在開始繪制順序圖時陷入困境,很可能是因為沒有正確編寫用例或沒有完成健壯性分析。 ? 5.通過研究系統(tǒng)的動態(tài)行為,了解包含在靜態(tài)模型中的類需要哪些屬性與操作 ? 4.牢記順序圖時制定行為分配的工具。 ? 3.當(dāng)在詳細(xì)層上研究系統(tǒng)用法時,其實是在給問題域?qū)ο筇砑咏鉀Q方案空間對象。 ? 2.把基礎(chǔ)結(jié)構(gòu)、框架和幫助者對象納入設(shè)計,設(shè)計模式通常是有幫助的,這是OOD真正發(fā)生的地方 ? 1.在順序圖空白處寫下最初的需求層文本,這提供了可視化需求跟蹤 關(guān)鍵設(shè)計評審 |
第五部分 面向?qū)ο蠓治鲈O(shè)計總結(jié) |
10種導(dǎo)致用例分析崩潰的做法 ? 10.在靜態(tài)模型中的每個關(guān)聯(lián)末尾放置基數(shù)指示器。 ? 9.為每個功能需求編寫一個用例。 ? 8.為每張順序圖繪制一張協(xié)作圖。 ? 7.每張協(xié)作圖上包含整個腳本,不側(cè)重關(guān)鍵事務(wù)。 ? 6.為靜態(tài)模型中的每個類繪制狀態(tài)圖。 ? 5.在協(xié)作圖上花費幾小時處理消息信號。 ? 4.為整個系統(tǒng)繪制一張巨大的多層級的狀態(tài)圖。 ? 3.通過順序圖直接從需求層用例跳到詳細(xì)設(shè)計。 ? 2.在需求模型結(jié)束之前,做了大量的詳細(xì)設(shè)計工作,在需求結(jié)束后,重復(fù)幾次設(shè)計。 ? 1.創(chuàng)建了數(shù)以百計的狀態(tài)圖,每張狀態(tài)圖包含兩種狀態(tài)。 |
- 上一篇:COSMIC估算分析師認(rèn)證培訓(xùn)
- 下一篇:代碼評審技術(shù)