問題: 組合語言編寫程式、高階語言的結構化程式設計和物件導向程式設計之間的比較？
物件導向方法與面向過程方法的比較分析
物件導向的概念（省略）
物件導向軟體過程的一般特性:
1．物件導向的軟體過程
軟體過程模型的比較
噴泉模型:
噴泉模型的生命週期與面向過程的生命週期是一致的，但噴泉模型的各個階段是迭代和無縫的。
rup過程模型:
軟體過程是指實施於軟體開發和維護中的階段、方法、技術、實踐及相關產物(計畫、文件、模型、**、測試用例和手冊等)的集合。行之有效的軟體過程可以提高開發軟體組織的生產效率、提高軟體質量、降低成本並減少風險。目前市場上領先的軟體過程主要有rup(rational unified process;rational 統一過程)、open process和oosp(object-oriented software process;物件導向軟體過程)。
、rumbaugh和jacobson，同時它又是物件導向開發的行業標準語言——標準建模語言(uml)的創立者。rup是由objectory過程演化而來，其初始版本為5.0，先後經歷了5.
1、5.11、5.5等版本直到最新的rational unified process2000版本。
rup的二維開發模型
傳統的軟體開發模型瀑布式開發模型是乙個單維的模型，開發工作劃分為多個連續的階段。在乙個時間段內，只能作某乙個階段的工作比如，分析、設計或者實現
rup可以用二維座標來描述。橫軸通過時間組織，是過程展開的生命週期特徵，體現開發過程的動態結構，用來描述它的術語主要包括週期(cycle)、階段(phase)、迭代(iteration)和里程碑(milestone)；縱軸以內容來組織為自然的邏輯活動，體現開發過程的靜態結構，用來描述它的術語主要包括活動(activity)、產物(artifact)、工作者(worker)和工作流(workflow)。入下圖:
rup的二維開發模型
從圖中的陰影部分表示的工作流可以看出，不同的工作流在不同的時間段內工作量的不同。值得注意的是，幾乎所有的工作流，在所有的時間段內均有工作量，只是工作程度不同而已。這與wate***ll process(瀑布式開發模型)有明顯的不同。
開發過程中的各個階段和里程碑
rup中的軟體生命週期在時間上被分解為四個順序的階段，分別是：初始階段(inception)、細化階段(elaboration)、構造階段(construction)和交付階段(transition)。每個階段結束於乙個主要的里程碑(major milestones)；每個階段本質上是兩個里程碑之間的時間跨度。
在每個階段的結尾執行一次評估以確定這個階段的目標是否已經滿足。如果評估結果令人滿意的話，可以允許專案進入下乙個階段。
1.初始階段
初始階段的目標是為系統建立商業案例並確定專案的邊界。為了達到該目的必須識別所有與系統互動的外部實體，在較高層次上定義互動的特性。本階段具有非常重要的意義，在這個階段中所關注的是整個專案進行中的業務和需求方面的主要風險。
對於建立在原有系統基礎上的開發專案來講，初始階段可能很短。
初始階段結束時是第乙個重要的里程碑：生命週期目標(lifecycle objective)里程碑。生命週期目標里程碑評價專案基本的生存能力。
初始階段的主要成果是：
前景文件：對核心專案要求、關鍵性質、主要限制的一般性的前景說明；
初始的用例模型（完成10％－20％）
初始的專案術語表
初始的商業用例，包括商業環境、驗收規範以及成本**
初始的風險評估
專案規劃，其中明確階段和迭代
商業模型，根據需要可選
乙個或多個原型
初始階段結束時是第乙個里程碑：生命週期目標里程碑。對初始階段進行評估的準則是：
風險承擔人對專案範圍定義和成本/進度估計達成共識
需求由主要的用例無二義地表達出來
成本/進度估計、優先順序、風險和開發過程的可信度
開發出來的體系結構原型的深度和廣度
實際支出與計畫支出的比較
2.細化階段
細化階段的目標是分析問題領域，建立健全的體系結構基礎，編制專案計畫，淘汰專案中最高風險的元素。為了達到該目的，必須在理解整個系統的基礎上，對體系結構作出決策，包括其範圍、主要功能和諸如效能等非功能需求。同時為專案建立支援環境，包括建立開發案例，建立模板、準則並準備工具。
細化階段的成果是：
用例模型（至少完成80％）：識別出了所有的用例和角色，以及大多數用例的描述
一些增加的需求，包括非功能性需求以及任何與特定用例無關的需求
軟體體系結構描述
可執行的體系結構原型
修訂後的風險表和商業用例
整個專案的開發計畫，包括粗略專案規劃，顯示迭代過程以及相應的評估準則
更新的開發用例，指定要使用的過程
初步的使用者手冊（可選）
細化階段結束時第二個重要的里程碑：生命週期結構(lifecycle architecture)里程碑。生命週期結構里程碑為系統的結構建立了管理基準並使專案小組能夠在構建階段中進行衡量。
此刻，要檢驗詳細的系統目標和範圍、結構的選擇以及主要風險的解決方案。
細化階段的評估準則包括對以下問題的回答：
產品的前景是否穩定？
體系結構是否穩定？
可執行的演示是否強調了主要的風險元素，並且已經解決？
構造階段的規劃是否已經足夠詳細和準確，是否有可信的評估支援？
如果用當前的規劃來開發整個系統，並且使用當前的體系結構的話，是否所有的風險承擔人對當前的前景都達成一致？
是否實際的資源支出與計畫的支出都是可接受的？
如果專案不能通過這個里程碑，則將取消或重新考慮。
3.構造階段
在構建階段，所有剩餘的構件和應用程式功能被開發並集成為產品，所有的功能被詳細測試。從某種意義上說，構建階段是乙個製造過程，其重點放在管理資源及控制運作以優化成本、進度和質量。
構造階段的產品是乙個可以立即提交給終端使用者使用的產品，它至少應該包括：
在特定平台上整合的軟體產品
使用者手冊
對當前版本的描述
構造階段結束是第三個里程碑：初始執行能力。此時要決定軟體、節點和使用者是否已經準備好執行，並且專案沒有出現任何高風險問題。這個版本通常叫做beta版。
構造階段的評估準則包括對以下問題的回答：
這個產品版本是否足夠穩定和成熟，可以在使用者群中發布嗎？
是否所有的風險承擔人都已經準備好向使用者提交？
實際的資源支出和計畫的支出的比值是否仍然可接受？
如果專案沒有達到這個里程碑，必須推遲發布。
4.交付階段
交付階段的目的是把軟體產品交付給使用者群。一旦產品提交給終端使用者，通常會產生新的要求，如繼續開發新版本，修正一些問題，或者完成某些被推遲的功能部件。當基線足夠成熟，能夠向終端使用者領域發布時，就進入了交付階段。
這通常需要系統的一些可以使用的子集已經達到一定的質量要求，並且有使用者文件，從而使交付產生積極的效果。包括：
beta測試確認新系統達到使用者的預期
與被取代的舊系統並行操作
功能性資料庫的轉換
使用者和維護人員培訓
向市場、分銷商和銷售人員進行新產品的展示。
交付階段側重向使用者提交軟體的活動，這個階段包括幾個典型的迭代，如beta版本，通用版本以及對使用者的反饋作出響應等，都需要可觀的精力。但是，在生命週期的這一點上，使用者反饋可能主要限於產品調整、配置、安裝和可用性問題上。交付階段的主要目標包括：
使使用者可以自我幫助
使風險承擔人合作，使展開基線完整，並與前景評估準則一致
交付階段的終點是第四個重要的專案里程碑：產品發布里程碑。在這個點上，要確定是否已經達到目標，能否開始另乙個開發周期。交付階段主要的評估準則包括對以下問題的回答：
使用者是否滿意？
是否能夠接受實際的和計畫的資源支出的比？
rup的核心工作流
rup中有9個核心工作流，分為6個核心過程工作流(core process workflows)和3個核心支援工作流(core supporting workflows)。儘管6個核心過程工作流可能使人想起傳統瀑布模型中的幾個階段，但應注意迭代過程中的階段是完全不同的，這些工作流在整個生命週期中一次又一次被訪問。9個核心工作流在專案中輪流被使用，在每一次迭代中以不同的重點和強度重複。
UML與物件導向方法學
2007 2008學年第2學期 專業班級 姓名學號 開課系室 考試日期 一 填空題 每空1分，共27分 1 uml中關係包括4種，分別是 和2和用於對物件導向系統的物理方面建模進行描述的2種圖形。3是描述在某一時刻，系統中一組物件以及它們之間關係的圖形。4 部署圖中的節點可以分為2種型別和 5 物件...
傳統方法學與物件導向區別
姓名 戴育兵 學號 g1030510 年級 大二 班級 net 2 班 摘要 傳統的軟體工程方法學曾經給軟體產業帶來巨大進步，部分地緩解了軟體危機，使用這種方法學開發的許多中 小規模軟體專案都獲得了成功。但是，人們也注意到當把這種方法學應用於大型軟體產品的開發時，似乎很少取得成功。在20世紀60年代...
第三講尼采
尼采其人 尼采 friedrich wilhelmnietzsche,1844 1890 是對西方哲學由近代向現當代轉型發生過重大影響的德國哲學家。他出生於乙個鄉村牧師家庭。早年在一所貴族子弟學校上學，熱衷於希臘文化，對詩和 感興趣，後來進波恩和萊比錫大學學習語言和神學。1869 1879年任瑞士巴...