RUP模型
理解
如果認(rèn)為這個(gè)解釋難以理解，可以這樣想：
我們開發(fā)一個(gè)產(chǎn)品，如果不太復(fù)雜，會采用
瀑布模型，簡單的說就是先定義需求，然后構(gòu)建框架，然后寫代碼，然后測試，最后發(fā)布一個(gè)產(chǎn)品。
這樣，幾個(gè)月過去了，直到最后一天發(fā)布時(shí)，大家才能見到一個(gè)產(chǎn)品。
這樣的方式有明顯的缺點(diǎn)，假如我們對用戶的需求判斷的不是很準(zhǔn)確時(shí)——這是很常見的問題，一點(diǎn)也不少見——你工作了幾個(gè)月甚至是幾年，當(dāng)你把產(chǎn)品拿給客戶看時(shí)，客戶往往會大吃一驚，這就是我要的東西嗎？
方法
迭代的方式就有所不同，假如這個(gè)產(chǎn)品要求6個(gè)月交貨，我在第一個(gè)月就會拿出一個(gè)產(chǎn)品來，當(dāng)然，這個(gè)產(chǎn)品會很不完善，會有很多功能還沒有添加進(jìn)去，bug很多，還不穩(wěn)定，但客戶看了以后，會提出更詳細(xì)的修改意見，這樣，你就知道自己距離客戶的需求有多遠(yuǎn)，我回家以后，再花一個(gè)月，在上個(gè)月所作的
需求分析、框架設(shè)計(jì)、代碼、測試等等的基礎(chǔ)上，進(jìn)一步改進(jìn)，又拿出一個(gè)更完善的產(chǎn)品來，給客戶看，讓他們提意見。
就這樣，我的產(chǎn)品在功能上、質(zhì)量上都能夠逐漸逼近客戶的要求，不會出現(xiàn)我花了大量心血后，直到最后發(fā)布之時(shí)才發(fā)現(xiàn)根本不是客戶要的東西的情況。
優(yōu)勢
這樣的方法很不錯(cuò)，但他也有自己的缺陷，那就是周期長、成本很高。在應(yīng)付大項(xiàng)目、高風(fēng)險(xiǎn)項(xiàng)目——就比如是航天飛機(jī)的控制系統(tǒng)時(shí)，迭代的成本比項(xiàng)目失敗的風(fēng)險(xiǎn)成本低得多，用這種方式明顯有優(yōu)勢。
如果你是給自己的單位開發(fā)一個(gè)小MIS，自己也比較清楚需求，工期上也不過花上個(gè)把月的時(shí)間，用迭代就有點(diǎn)殺雞用了牛刀，那還是
瀑布模型更管用，即使是做得不對，頂多再花一個(gè)月重來，沒什么了不起。
基本算法
有些國外的教材，如《C++ Primer》第四版的中文版，會把iterative翻譯成迭代。
在java中Iterative 僅用于遍歷集合，本身并不提供盛裝對象的能力。如果需要?jiǎng)?chuàng)建Iterative對象，則必須有一個(gè)被迭代的集合。沒有集合的Iterative仿佛無本之木，沒有存在的價(jià)值。
iterative是反復(fù)的意思，所以，有時(shí)候，迭代也會指循環(huán)執(zhí)行，反復(fù)執(zhí)行的意思。
利用迭代算法解決問題，需要做好以下三個(gè)方面的工作：
確定變量
在可以用迭代算法解決的問題中，至少存在一個(gè)直接或間接地不斷由舊值遞推出新值的變量，這個(gè)變量就是迭代變量。
本站僅提供存儲服務(wù)，所有內(nèi)容均由用戶發(fā)布，如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容，請
點(diǎn)擊舉報(bào)。
