老師軟件工程課件知識點整理

1、什么是研究？問題是什么？假設(shè)前提是什么？（理論基礎(chǔ)）解決問題的方法是什么？（論證過程）結(jié)論是什么？（貢獻及期待）關(guān)于研究的簡單實例東方關(guān)于女人美的觀點：（理論基礎(chǔ)）手如柔荑（t） 、膚如凝脂、領(lǐng)如蝤蠐（qiq） 、齒如瓠（h）犀、螓（qn）首蛾眉、巧笑倩兮、美目盼兮出自詩經(jīng).衛(wèi)風.碩人手指細如嫩荑、皮膚白皙如凝脂、頸脖美麗如蝤蠐潔白圓潤、牙如瓠籽白又齊、寬寬的額頭、彎彎的眉毛 、淺笑盈盈酒窩俏、美目左顧右盼眼波俏論證過程手如柔荑（X）膚如凝脂（？）領(lǐng)如蝤蠐（X）齒如瓠犀（？）螓首（）蛾眉（X）巧笑（ ）倩兮（X）美目盼兮（？）西方關(guān)于美的觀點：（理論基礎(chǔ)）黃金分割定理（Golden Secti

2、on）把一條線段分割為兩部分，使其中一部分與全長之比等于另一部分與這部分之比。 （1/x）=(x/(1-x)其比值是5(1/2)-1/2或二分之根號五減一，取其前三位數(shù)字的近似值是0.618。由于按此比例設(shè)計的造型十分美麗，因此稱為黃金分割。這個數(shù)值的作用不僅僅體現(xiàn)在諸如繪畫、雕塑、音樂、建筑等藝術(shù)領(lǐng)域，而且在管理、工程設(shè)計等方面也有著不可忽視的作用。結(jié)論：在東方文明看來，蒙娜麗莎不美在西方文明看來，蒙娜麗莎美展望：東西方審美觀的差異：進一步研究其他類型的審美觀不一致問題，例如建筑，.再進一步聯(lián)想到：不同社會文明的差異給人類社會發(fā)展帶來的影響研究問題是什么研究要針對問題。問題來源于：社會實踐需

3、要、追蹤科學前沿和熱點嵌入式系統(tǒng)研究的問題：嵌入式系統(tǒng)的可靠性(穩(wěn)定運行的時間)嵌入式系統(tǒng)的性能(運行速度、功耗)嵌入式系統(tǒng)的可演化性(結(jié)構(gòu))嵌入式系統(tǒng)的正確性(行為)嵌入式系統(tǒng)地正確性：系統(tǒng)建模與驗證如何找到研究問題首先，從項目實踐中獲取候選問題列表：實踐中經(jīng)常遇到的問題是什么？實踐中難以解決的問題是什么？實踐中最重要的要解決的問題是什么？其次，通過交流確定候選題目：與導師交流，如果研究領(lǐng)域?qū)熓煜?，很快就可以確定廣泛閱讀最新的文獻，通過閱讀文獻，尤其是會議論文，能夠確定目前這一領(lǐng)域的熱點研究問題是什么與同學交流，包括高年級同學、其他專業(yè)同學、其他學校同學依據(jù)自己的興趣愛好如何確定研究內(nèi)容首

4、先，從收集的文獻中確定一篇合適的文獻作為起點，仔細閱讀，回答：文章研究的問題是什么？其背景是什么？其意義是什么？文章解決問題的理論依據(jù)是什么？文章解決問題的方法是什么？包括論證過程、實驗數(shù)據(jù)、實驗工具文章解決問題得到的有用結(jié)論是什么？應(yīng)用價值和科學價值何在？其次，針對詳細閱讀的論文，仔細思考以下問題：文章中有哪些方面的內(nèi)容值得進一步研究？文章還有哪些問題沒有涉及到？文章的研究方法可以進一步改進嗎？文章的實驗數(shù)據(jù)存在問題嗎？文章的實驗工具可以改善嗎？文章的結(jié)論，尤其是展望值得進一步研究嗎？文章的研究在實際應(yīng)用中還存在哪些問題？文章的結(jié)論可靠嗎？與實際相符嗎？再次，確認前面提到的各種問題：查找相關(guān)

5、文獻學習與論文有關(guān)的基本理論動手驗證論文的實驗進一步思考前面的問題，通過批判性思維反駁，記錄反駁的依據(jù)與同學進行交流討論與導師交流討論RAD模型的不足技術(shù)風險很高的情況不適合采用； （如新軟件要求與已存在的程序有高可互操性時，或系統(tǒng)難以被適當?shù)貏澐譃槿舾晒δ艿惹闆r）需要足夠的人力以創(chuàng)建足夠的RAD小組；開發(fā)者和用戶需要在很短的時間內(nèi)完成系統(tǒng)開發(fā)。漸增模型前述生存期模型，均是一次性地將整個系統(tǒng)交給用戶： 瀑布模型是假設(shè)當線性階段完成之后就能交付一個完善的系統(tǒng)。原型模型主要用來幫助開發(fā)者獲取用戶需求，待需求穩(wěn)定后再開發(fā)最終系統(tǒng)提供給用戶。RAD模型則先將系統(tǒng)主要功能分給若干RAD小組開發(fā)，然后集成

6、起來形成最終系統(tǒng)提交給用戶。業(yè)務(wù)和產(chǎn)品需求的變化，市場競爭和商業(yè)壓力等等 以逐步增加軟件產(chǎn)品的方式構(gòu)造軟件-漸增模型漸增模型的特點可以根據(jù)需要補充人員 ；能夠有計劃地管理技術(shù)風險；能夠減少全新軟件產(chǎn)品對用戶帶來的影響；不需要大的資金支出；用戶能及早使用及早發(fā)現(xiàn)問題；投資回報隨功能漸增而漸增。漸增模型的不足:如果產(chǎn)品整體結(jié)構(gòu)設(shè)計不當，則難以為其增加新的增量； （對設(shè)計水平要求較高）由于采用增量開發(fā)，故難于進行徹底的測試。螺旋模型螺旋模型的特點:既保持了傳統(tǒng)生命周期模型中系統(tǒng)的階段性方法，又將迭代演化的思想吸收到模型中；螺旋模型是風險驅(qū)動的。 （風險分析使得用戶和開發(fā)者能夠更好地理解和對待每一個階

7、段的風險）螺旋模型適合于大型軟件的開發(fā)螺旋模型的不足:要求軟件開發(fā)人員善長風險分析；風險分析會導致項目終止而終止合同，出現(xiàn)違約訴訟；對于小項目，風險分析的成本可能與整個項目的成本相當。敏捷原則最優(yōu)先要做的是通過盡早地、持續(xù)地交付有價值的軟件來使客戶滿意。即使在開發(fā)后期，也歡迎需求改變。敏捷過程利用變化來為客戶創(chuàng)造競爭優(yōu)勢。 經(jīng)常性地交付可以工作的軟件，交付的間隔可以從幾個星期到幾個月，交付的時間間隔越短越好。 在整個項目開發(fā)期間，業(yè)務(wù)人員和開發(fā)人員必須天天在一起工作。 圍繞有積極性的個人構(gòu)建項目團隊。為他們提供所需的環(huán)境和支持，并信任他們能夠完成工作。 在團隊內(nèi)部，最有效果并富有效率的信息傳遞

8、方法是面對面的交流。 可運行的軟件是首要的進度度量標準。 敏捷過程提倡可持續(xù)的開發(fā)速度。責任人、開發(fā)者和用戶應(yīng)該能夠保持一個長期的、穩(wěn)定的開發(fā)速度。 持續(xù)關(guān)注優(yōu)秀的技能和好的設(shè)計，增強敏捷能力。 簡單（是不必做的工作最大化的藝術(shù)）是必要的。 最好的架構(gòu)、需求和設(shè)計出自于自組織的團隊。 每隔一段時間，團隊應(yīng)反省如何才能有效地工作，并相應(yīng)地調(diào)整自身的行為。 極限編程(Extreme Programming，簡稱XP)是由Kent Beck、Ward Cunningham、Ron Jeffries等人通過整理優(yōu)秀團隊的共同之處而提出的敏捷過程。所謂極限，Kent Beck認為是：盡力而為，然后處理其

9、結(jié)果。極限編程專注于編程技術(shù)、清晰溝通和團隊協(xié)作，只需做能夠為客戶創(chuàng)造價值的事情，是一組確保項目開發(fā)成功的規(guī)則，適用于任何規(guī)模的團隊，適合模糊或快速變化的需求。站立式會議大多在9點鐘開始，團隊集中討論當前的工作，對具體問題尋求解決建議。站立會議一般持續(xù)很短的時間，應(yīng)該回答：自昨天開始已經(jīng)做了什么？從現(xiàn)在開始你將做什么？阻礙迭代目標的有什么？有沒有未完成的事情？在需求或技術(shù)等方面是否有與其他人員有關(guān)的決定等。站立式會議的目的是相互交流學習，了解項目的進度。極限編程過程強調(diào)小規(guī)模、頻繁地發(fā)布代碼和測試。一方面，小型發(fā)布有利于盡早為客戶提供業(yè)務(wù)價值，使客戶增加信心。另一方面，客戶可以通過使用小型發(fā)布

10、的軟件系統(tǒng)，能夠獲取更多的其他需求，發(fā)現(xiàn)系統(tǒng)存在的缺陷，通過反饋將更有力地指導項目成功，包括改善進度估算、完善故事、改變故事實現(xiàn)的優(yōu)先級等。在發(fā)布階段，如果需要文檔，則應(yīng)該在當前版本趨于穩(wěn)定時撰寫文檔，主要包括：系統(tǒng)文檔，為理解系統(tǒng)提供一個總覽信息，如系統(tǒng)技術(shù)架構(gòu)、高層次系統(tǒng)需求、關(guān)鍵設(shè)計決策總結(jié)、重要的設(shè)計模型等等；系統(tǒng)操作文檔，描述系統(tǒng)涉及的依賴關(guān)系、與其他系統(tǒng)交互的特性、預(yù)期系統(tǒng)負載等；系統(tǒng)支持文檔，描述解決問題時的參考信息、疑難問題的上報流程、維護團隊的聯(lián)系列表等；用戶文檔，如參考手冊、用戶指南、支持指南及培訓資料等。極限編程實踐:Scrum 過程在敏捷軟件開發(fā)中，Scrum是一種迭代

11、增量式軟件開發(fā)過程，就像橄欖球賽的爭球過程：快速、自組織和有適應(yīng)性。Scrum團隊角色:產(chǎn)品負責人（Product Owner）：定義和維護“產(chǎn)品待辦事項表（Product Backlog）”，負責最大化產(chǎn)品以及Scrum團隊的工作價值，代表利益相關(guān)者的利益。 Scrum主管（Scrum Master）:確保Scrum團隊遵循Scrum理論、實踐和規(guī)則，通過指導和引導，使Scrum團隊更加高效地創(chuàng)建高質(zhì)量的產(chǎn)品。 開發(fā)團隊（Development Team）：負責在每個沖刺（Sprint）結(jié)束，交付潛在可發(fā)布的“已完成”產(chǎn)品增量。只有開發(fā)團隊的成員才能交付產(chǎn)品增量。開發(fā)團隊:團隊的大小足夠小，

12、以保證靈活性，同時應(yīng)能完成有意義的任務(wù)，一般是72人。開發(fā)團隊有以下幾個特點： 員是自組織的，沒有人（即使是Scrum主管都不可以）告訴開發(fā)團隊如何把產(chǎn)品待辦事項表變成潛在可發(fā)布的功能。開發(fā)團隊是跨功能的，團隊作為一個整體擁有創(chuàng)造產(chǎn)品增量所需要的全部技能。Scrum不認可開發(fā)團隊成員的頭銜，無論承擔哪種工作他們都是開發(fā)者。此規(guī)則無一例外。 開發(fā)團隊中的每個成員可以有特長和專注領(lǐng)域，但是責任歸屬于整個開發(fā)團隊。開發(fā)團隊不包含如測試或業(yè)務(wù)分析等負責特定領(lǐng)域的子團隊。Scrum制品:Scrum軟件開發(fā)過程產(chǎn)生的制品除可工作的軟件外，主要有四種：產(chǎn)品待辦事項表、沖刺待辦事項表、沖刺燃盡圖和發(fā)布燃盡圖。

13、產(chǎn)品待辦事項表模版沖刺待辦事項表模版沖刺燃盡圖（Sprint Burndown）Scrum會議由Scrum主管主持。沖刺計劃會 每日站立會 沖刺評審會議 沖刺反思會 與極限編程敏捷軟件開發(fā)過程相比，Scrum過程強調(diào)管理，而極限編程強調(diào)實踐，兩者具有很好的互補性。沖刺計劃會沖刺計劃會是為沖刺做準備的會議，主要確定沖刺要做什么和怎么做，時間大概是幾個小時。在這個會議中，開發(fā)團隊和產(chǎn)品負責人通過共同討論，理解產(chǎn)品負責人需要什么和為什么需要，從而由開發(fā)團隊自己確定本次沖刺應(yīng)該完成的產(chǎn)品待辦事項表中的條目。然后，開發(fā)團隊針對要在本次沖刺中實現(xiàn)的條目進行計劃、分析和設(shè)計，并將每個條目分解成細粒度的任務(wù)，

14、形成沖刺待辦事項表和沖刺目標。每日站立會議要求每個成員都參加，時間不超過15分鐘。會上，所有成員必須回答三個問題：上次站立會議后做了哪些工作？遇到了哪些問題？下次站立會議之前計劃做什么？Scrum主管負責幫助團隊解決遇到的問題。在會后，會有一個或多個并行的會議跟進。跟進會議不要求所有人都參加，主要針對站立會議收集的信息與相關(guān)成員作進一步的溝通，此時Scrum主管一般不參加。沖刺評審會議對功能性的產(chǎn)品增量進行審視和調(diào)整，時間不超過4小時（小時數(shù)等于本次沖刺周期的周數(shù)）。在沖刺評審會中，真實用戶和產(chǎn)品負責人檢驗和使用運行起來的軟件。通過開發(fā)團隊、產(chǎn)品負責人和其他涉眾之間的交流，審視產(chǎn)品的進展，并針

15、對問題進行調(diào)整。沖刺反思會在沖刺評審會之后，針對流程和環(huán)境的審視和調(diào)整。每位成員要求對本次沖刺的情況進行回顧，不僅對工作中存在的問題進行反思，而且也要討論好的工作方式。每位成員要對其他成員的反思進行評價，表達各自的期望。有人統(tǒng)計，在行業(yè)實際使用的所有敏捷軟件開發(fā)過程中，極限編程過程占8%，Scrum過程占49%，極限編程和Scrum結(jié)合過程占22%，其他敏捷軟件開發(fā)過程占21%。精益軟件開發(fā) 特征驅(qū)動軟件開發(fā)基于Petri網(wǎng)的軟件過程建模:C.A.Petri 博士在1962 年首次提出了Petri網(wǎng)的概念。Petri 網(wǎng)是一種用于系統(tǒng)描述和分析的數(shù)學工具。Petri 網(wǎng)通過對實際軟件開發(fā)過程中

16、的開發(fā)活動, 對產(chǎn)品、資源等進行抽象, 從而完成對軟件過程的描述, 并進一步支持軟件過程的標準化和自動化。二元組N=(S,T,F)稱為有向網(wǎng)的充分必要條件是：1. ST=, (二元性)2. ST , (非空)3. FSxT TxS, （x為笛卡爾積）4. dom(F) cod(F) = ST, （不存在孤立元素）其中：dom(F)=x|y: (x,y)F, cod(F)=y|x: (x,y)F分別稱為F的定義域(domain)和值域(codomain)S稱為N的庫所集，通常用圓圈或橢圓表示庫所，描述系統(tǒng)狀態(tài)T稱為N的變遷集，通常用方框或粗杠表示變遷，描述系統(tǒng)事件F稱為N的流關(guān)系，通常用箭頭表示

17、，描述系統(tǒng)狀態(tài)和事件之間的關(guān)系通常在Petri 網(wǎng)的圖形表示中, 用圓圈( O )表示庫所, 矩形( 口) 表示變遷, 黑點() 表示托肯( t o k e n )。Petri網(wǎng)例子一年四季的變化狀態(tài)：春、夏、秋、冬事件：立春、立夏、立秋、立冬Petri網(wǎng)系統(tǒng)Petri網(wǎng)只提供了系統(tǒng)的結(jié)構(gòu)框架，就像演戲的舞臺活動在框架上的是系統(tǒng)中流動的資源假定有向網(wǎng)N=(S,T,F)，記IN0=0,1,2, IN=1,2, 并以表示無窮： = +1= + K:S-IN 稱為N的容量函數(shù)對給定的容量函數(shù)K，M:S-IN0稱為N的一個標記(Marking)的條件是：sS：M(s)K(s)W:F-IN稱為N上的權(quán)函

18、數(shù)，對(x,y) F,W(x,y)=W(x,y)稱為(x,y)上的權(quán)六元組=(S,T,F,K,W,M0)構(gòu)成網(wǎng)系統(tǒng)的條件是： 1）N=(S,T,F)構(gòu)成有向網(wǎng)，稱為的基網(wǎng) 2）K,W和M0 依次為N的容量函數(shù)、權(quán)函數(shù)和初始標識Petri網(wǎng)系統(tǒng)變遷發(fā)生的條件假定N是Petri網(wǎng)系統(tǒng)的基網(wǎng).x=y|(y，x)F稱為x的前集或輸入集x.=z|(x，z)F稱為x的后集或輸出集t是N中的變遷， . t. = . t t.稱為t的外延t在M有發(fā)生權(quán)的條件是：s . t ：M(s)W(s,t)s t . ：M(s)+W(s,t)K(s)t在M有發(fā)生權(quán)記作Mt,也說M授權(quán)t發(fā)生或t在M授權(quán)發(fā)生若Mt，則t在M

19、可以發(fā)生，將標識M改變?yōu)镸,對任何s S，M(s)為：M(s)-W(s,t), 若s . t -t . M(s)+W(s,t), 若s t. - . tM(s)-W(s,t)+W(t,s), 若s t. - . tM(s),若s . t. 簡單有色Petri網(wǎng)的例子哲學家就餐P=Think, Eat, UnusedchopsticksT = TakeChopsticks, PutDownChopsticksA=(Think, TakeChopsticks), (TakeChopsticks, Eat), (Eat, PutDownChopsticks), (PutDownChopsticks,

20、 Think), (Unusedchopsticks, TakeChopsticks), (PutDownChopsticks, Unusedchopsticks) =PH, CSV = p:PHC(p) = PH if pThink, Eat, CS otherwise G(t) = true for all tTE(a) = 1p if a(Think, TakeChopsticks), (TakeChopsticks, Eat), (Eat, PutDownChopsticks), (PutDownChopsticks, Think), chopsticks(p) otherwise I

21、(p) = PH.all() if pThink, CS.all() if pUnusedchopsticks, Oms otherwise對一個有色Petri 網(wǎng)CPN,定義： 1）一個標識(Marking)是一個函數(shù)M,將每一個庫所p映射為標記M(p)C(p)ms的多重集合 2）初始標識M0定義為M0(p)=I(p),對所有pP. 表示空綁定 3）變遷t的變量var(t) V，由t的守衛(wèi)條件中出現(xiàn)的自由變量和與t相連的弧的弧表達式中出現(xiàn)的自由變量組成 4)變遷t的一個綁定是一個函數(shù)b，將每個變量vvar(t)映射到一個值b(v) type(v). 變遷t的所有綁定集記為B(t) 5) 一個

22、綁定元素是一個二元組(t,b),滿足tT, b B(t). CPN模型中所有綁定元素構(gòu)成的集合記為BE 6) 步Y(jié) BEms是一個綁定元素的非空、有限多重集合 例如(Take_Chopsticks,)便是一個有色Petri網(wǎng)變遷Take_Chopsticks的步軟件組織為何要引入CMMI？企業(yè)面臨更多的挑戰(zhàn)與市場競爭新的發(fā)展方向和機會軟件外包服務(wù)，業(yè)務(wù)合作“認證” 要求 市場宣傳、投標資質(zhì)、顧客的壓力 ISO9001，CMMI，信息安全，知識產(chǎn)權(quán)保護顧客滿意度，要求按時交付產(chǎn)品；以較低的成本、開發(fā)出更多功能、更好質(zhì)量的產(chǎn)品企業(yè)能力提升的要求業(yè)務(wù)和規(guī)模和擴展（開發(fā)團隊人員增加）更復雜的產(chǎn)品人員流

23、失（組織的知識資產(chǎn)沒有保留和積累）項目的可預(yù)見性不足很多不成熟的軟件組織面臨的問題項目有可能獲得良好的性能和結(jié)果，但是需求經(jīng)常得不到一致的理解，并且往往是不受控制地進入項目進度和預(yù)算經(jīng)常得不到保障項目的進展無法度量產(chǎn)品的內(nèi)容沒有跟蹤和控制，版本混亂工程活動沒有標準，實施得不一致開發(fā)團隊沒有經(jīng)過培訓，相互間不協(xié)調(diào)缺陷增生項目的成功依賴于技術(shù)骨干CMMI 能力成熟度模型集成 Capability Maturity Model Integration 軟件過程改進方面得到國際認可的標準目的：為軟件組織改進和提高過程能力提供指南內(nèi)容：涵蓋系統(tǒng)工程和軟件工程管理的最佳實踐 - 涉及產(chǎn)品的開發(fā)和維護活動、

24、覆蓋產(chǎn)品從概念提出到交付和維護的整個生存周期。評估組織當前開發(fā)管理狀況的標尺階段型按成熟度等級劃分過程域指導思想：自頂向下、逐步求精、單入口、單出口；基本原則：抽象和功能分解；方法論：系統(tǒng)是由一些功能的相互聯(lián)系、相互作用而形成；結(jié)構(gòu)化方法系列：結(jié)構(gòu)化分析方法、結(jié)構(gòu)化設(shè)計方法和結(jié)構(gòu)化程序設(shè)計方法。 （具體）技術(shù)方法：面向數(shù)據(jù)流圖的方法、IDEF0方法、Jackson方法、LCP（Logical Construction Programs）方法等。結(jié)構(gòu)化方法的特點強調(diào)階段劃分；簡單實用；技術(shù)成熟；應(yīng)用廣泛。特別適合于需求能夠預(yù)先指定的系統(tǒng)的開發(fā)結(jié)構(gòu)化方法的不足不太適應(yīng)規(guī)模大及特別復雜的項目；難于解

25、決軟件重用（復用）問題；難于適應(yīng)需求變化或模糊的問題；軟件維護依然比較復雜。Data Flow Modeling數(shù)據(jù)流建模方法是一種結(jié)構(gòu)化分析方法；自頂向下、逐層分解地定義系統(tǒng)需求；特點是利用數(shù)據(jù)流圖來對用戶需求進行分析；可用于分析任何應(yīng)用系統(tǒng)的需求（why?）。數(shù)據(jù)流(用箭頭表示）；加工（加工一般用一個圓圈或圓角方框來表示 ）；數(shù)據(jù)存儲(一般用開口的矩形框或雙劃線來表示)； 數(shù)據(jù)的源點和終點（一般用正方形或立方體來表示 ）；擴展符號主要有：*、+和 。分層數(shù)據(jù)流圖只用一張數(shù)據(jù)流圖來描述，不僅難于一次畫齊，而且也難于理解。 分層數(shù)據(jù)流圖可以避免一次引入過多的細節(jié)，有利于控制問題的復雜度，從而便

26、于對大型系統(tǒng)描述的實現(xiàn)。 不同的用戶可以只選擇分層數(shù)據(jù)流圖中與本身有關(guān)或感興趣的部分，不必閱讀全圖，從而便于用戶的使用和理解。除頂層圖只有一張不用編號外，每一張分層圖均編號，編號規(guī)則為：分層圖的編號等于相應(yīng)被分解處理的編號；處理的編號=圖的編號+“.”+順序號；頂層圖中處理編號為0，可省略。例子 假設(shè)商場每周需要一張訂貨報表，表中對于每一需要訂貨的商品，要求列出下列數(shù)據(jù)：商品編號、商品名稱、庫存數(shù)量、訂貨數(shù)量、商品單價、供應(yīng)商。商品入庫或出庫稱為庫存更新事務(wù)。系統(tǒng)通過倉庫中的顯示終端由倉庫管理員把事務(wù)報告錄入到訂貨系統(tǒng)中。當某種商品的庫存數(shù)量比設(shè)定的庫存量臨界值小時，表示需要訂貨。采購員根據(jù)每

27、周的訂貨報告進行訂貨。抽象與求精抽象是一種常用的思考和解決問題的方式，即抽取事物的本質(zhì)的共同特性而暫時避開不必要的低層細節(jié)。 方式：過程抽象、數(shù)據(jù)抽象和控制抽象。抽象過程是指具有特定功能的一個命名的指令序列。（如：二維圖形創(chuàng)建 ）抽象數(shù)據(jù)則是描述數(shù)據(jù)對象的一個命名的數(shù)據(jù)集合。（如：“圖畫”數(shù)據(jù)對象 ） 抽象控制包含了一種程序控制機制而無須刻畫其內(nèi)部細節(jié)。（如：操作系統(tǒng)中的“同步信號量”）求精是由N. Wirth最初提出的一種自頂向下設(shè)計策略，其主要思想是：將某個宏觀功能不斷分解，逐步確定過程細節(jié)，直至用程序設(shè)計語言描述的算法實現(xiàn)為止。抽象使得設(shè)計人員能夠避開過早地陷入細節(jié)之中刻畫過程和數(shù)據(jù)。求精能夠幫助設(shè)計人員隨著設(shè)計過程的深入而不斷呈現(xiàn)更低層次