論文翻譯，用于個人學習和記錄，英文和專業水平不足，很多地方翻譯不出來或者翻譯錯了，如果有人看到了，希望不吝賜教
源檔案是從該網址下載的 https://dl.acm.org
或者

鏈接：https://pan.baidu.com/s/1j2NjTulfHLVu5dvdWKYomA?pwd=p4ka 
提取碼：p4ka 

如果要看我的翻譯的話，建議和英文原版一起看，避免無法理解我的拙劣翻譯
原文的參考標注了但是沒有給出，建議下載英文原版查看
有些陳述句和單詞能力不足，或無法理解其在軟體工程上存在的特殊意義可能會不翻譯或者翻譯錯誤，還是建議和英文原版一起看！（最好就直接啃英文不用看我這個了）

The Modular Structure of Complex Systems

DAVID LORGE PARNAS,PAUL C. CLEMENTS, And DAVID M. WELSS

摘要：這篇論文旨在討論軟體的組織結構，這個通常來說會因為細枝末節而變得復雜晦澀的部分，然而這正是需要糾正完善的，我們展示了一些諸如資訊隱藏和抽象的軟體設計技術可以通過結構化的層次結構檔案補充，我們稱該檔案為模塊向導，這個向導是為了同時幫助設計者和維護者能夠方便簡單的區分他們必須了解和他們無需了解的模塊，這篇論文包含了一個對軟體模塊向導，我們以此說明我們的建議

索引詞——抽象介面，資訊隱藏，軟體的模塊結構，軟體工程

Ⅰ.介紹

五年多前，在Naval Research Laboratory 的一些人對我們提出的一些觀點感到擔憂，我們的觀點認為現今在主要會議上（理論上？）所提倡的軟體工程準則與在許多企業和政府實驗室里的軟體工程實踐存在越來越大的割裂，會議和許多期刊充斥的著許多看起來很棒的想法（ideas），卻僅僅是通過一些簡單到不切實際的碎片（易碎品？）專案或者是沒有在大量細節上完整解決的復雜問題，當我們檢查實際軟體專案和他們的檔案時，幾乎沒有地方使用了上面那些想法，并且似乎沒有成功的產品是在這些會議和期刊中所吹捧的設計原則下誕生的，這些想法只是紙上談兵，

我們可以猜想幾個導致這個割裂的原因：

1. 這些想法，如許多老式（old-style）程式員宣稱的那樣，對真正的困難而言是不切實際的

2. 負責人的管理者是不愿意在未經實踐證明的準則上打賭的，從而產生啟動問題（thus creating a startup problem)

3. 論文中使用的案例與實際從業者碰到的問題相去甚遠，以致無法用作參考

4. 這些想法也許需要細化或者拓展之后才可以作為復雜且存在具體領域資源限制的專案的指導原則

5. 從業者，如某些學者聲稱的那樣，智力上無法勝任給予他們的作業，

以我們對這些想法和從業者的理解，不認為原因1和5是正確的；我們打算從原因2-4上下點功夫，

我們打算用一個無可辯駁地貼合實際的問題，并采用“學術性”的ideas，因此，如果我們成功了

1. 這對負責人的管理者是這些ideas的可行性的一種證明

2. 這可以成為類似問題的一個參考模型

3. 我們可以細化或補充這些ideas直到它們可以在在那些文章中更復雜的系統中起作用，

我們選擇對一個已存在的系統進行復刻，因為這樣我們就能對這兩種分別采用傳統技術和新學術準則的系統進行比較了，選擇的專案是為A-7E飛機設計的飛機操作程式（Operational Flight Program，OFP），當前的程式（傳統）采用了許多骯臟的伎倆（diarty tricks），只能勉強塞入記憶體（barely fits in its memory），并且勉強完成實時性的需求（barelly meets its real-time constraints），因此，我們認為這個程式，即使體量上小于其他很多程式，但仍是對那些ideas的一個好的測驗，因為當前的OFP被認為是同類（ilk）程式中最棒之一，我們認為最后的成功是在這樣的專案上比在一個原本就爛的專案上更具有說服力（we considered the task sufficiently challenging that skeptics would not attribute our success to the poor quality of the program that we are trying to match)

盡管這個專案距離完成還有很長一段，但我們已經在三個目標上有了一些小成果，我們為軟體書寫一個完整且精確的要求規范的能力已經激勵管理者嘗試相同的方式，并且我們的檔案 [9] 已經成為一些專案的參考，我們還發現了一些應當在專案開始前使用的有效的細化，比如說，抽象介面的概念，我們在 [1] 中討論過的，現在已經在 [2] 和 [3] 中被細化和說明了，

這篇論文展示了我們打算使用的對準則的另一種細化，其中最基礎的一個idea就是使用資訊隱藏的準則 [6] 來將專案分解成作業任務或模塊，這個idea是一個絕佳的例子來展示學術軟體工程和實踐中的割裂，盡管這個idea已經被某些學認為是自證的（self-evident）了，但我們認為找到任何體量較大（sizable）的產品中從一而終地使用了，盡管一些作者（author）認為這個idea已經“應該為人所熟悉”（“old hat”）了，我們仍沒法說服那些人用和他們以前用的完全不同的方式來構造軟體（we could not persuade those charged with building real software to do something so radically different from what they had been doing)

當我們嘗試著使用這些idea時，我們發現雖然這相當適用（quite applicable），還是需要增加一些額外的且必要的ideas讓其在含有多個（a dozen or so）模塊的系統中起作用，這篇論文會討論我們遇到的困難和額外增加的ideas，

Ⅱ.背景以及指導原則

A. 三種重要的軟體結構

軟體系統的一個結構化描述展示了程式是如何被劃分的，以及這些部分之間的關系，A-7E 的開發者必須留心三個結構：a）模塊結構，b）使用結構，c）process 結構，本節將對比這三種結構，

a）一個模塊是一個開發者或一個開發團隊的作業任務，每個模塊都包含一群緊密關聯的程式，模塊結構是將程式劃分為模塊的分解以及團隊應對模塊都要能夠了解其他模塊而負責的假設（and the assumptions that the team responsible for each module is allowed to make about the other modules)

b) 使用結構中，個體是程式，比如說，不是模塊而是模塊的一部分；關系是“要求什么東西的存在”，使用結構決定了軟體的可執行子結構（excuteable subsets），

c）process結構是對系統運行時的活動分解為可稱之為processes的個體，Processes不是程式；process與模塊之間也沒有簡單的關系，一些模塊的實作可能包含了一個或多個processes，并且任何process都可能呼叫多個模塊中的程式，

本文的剩余部分將討論模塊結構，

B. 設計準則

我們的模塊結構基于在 [6] 中說明的分解準則——資訊隱藏，在此準則中，可能獨立改動的系統細節應當成為單獨模塊的秘密；僅有的出現在模塊之間的介面的假設，應當是被認為不太可能改動的那些，每個資料結構應僅在一個模塊內使用；這個資料結構也許會被模塊內的若干個程式訪問，但是絕不能被模塊外的程式訪問，任何試圖訪問一個模塊記憶體儲的資料結構的請求應當通過呼叫該模塊的訪問程式來訪問，

應用這個準則并不總是很簡單，這是一個試圖最小化軟體預期成本的嘗試，并且要求設計者預估改動的可能性，這種預估基于過往的經驗，可能還需要應用程式領域的知識，以及對硬體和軟體技術的理解，因為一個設計者大概不會有這所有相關的經驗，我們已經開發了一個正式的審查程式來從那些有著相關經驗的人身上獲取益處，這些程式在 [2] 中描述了，

C. Goals of modular Structure

將模塊分解為模塊的主要目的通過允許模塊被獨立地設計和修改，以此達到減少整體的軟體成本，某塊分解的一些具體的目標如下，

a）每個模塊的結構都應該足夠簡單，讓人能夠完全地理解，

b）修改某個模塊的實作應該基于在不了解其他模塊的實作和不影響別的模塊的行為的前提下，

c）在設計上做出的改動應該合理地基于所需改動發生的可能性，做出不需要改變任何模塊介面的改動是最有可能的；包含了介面修改的改動應是更低可能性的，并且只能是那些小且并沒被廣泛依賴的模塊，只有非常不可能的改動能要求被廣泛依賴的模塊的介面修改，

d）a set of在獨立的模塊中做出各自獨立的改動是可能的，比如說期望介面修改，開發者改變了沒必要溝通的獨立模塊，如果模塊的介面沒有調整，那么無論使用舊還是新版本的模塊，整個系統都能跑起來，

基于上述的多個目標，我們的軟體是由多個小模塊組成的，在先前使用資訊隱藏的嘗試中，我們已經見證了一個有著5-20個模塊的系統，現在我們知道了，我們會有數目過百的模塊，如果說是25個或者更少的模塊數量的話，想要知道某個改動可能影響到的模塊就會很苦難，如果是上百個模塊就另說了，在25個或更少模塊時，仔細的檢查可能可以確保沒有東西被忽視，但是在上百個模塊的時候幾乎是不可能的，我們意識到對資訊隱藏的使用可能適得其反了，因為很多維護者會忽視很多模塊的內部結構，維護者會在很多模塊中搜索直到找到他們需要的那個，在發現我們遺漏了一些主要模塊之前，我們還擔心作業了一段時間，（We also feared working for some time before discovering we had left out some major modules.)

我得出了必須在應用資訊隱藏準則時增加額外規則的結論，并且如果我們打算減少維護復雜軟體系統的成本，我們就需要一個特殊的檔案，我們已經找到了一種處理small lists of模塊的方法以便我們能證明每個list都是完整的，我們需要準備一個軟體工程模塊向導，這個東西能幫助維護者找到被某個改動影響的模塊，或者哪些模塊造成了某個困難，

基于此考量，模塊會被組織成為一個樹結構層次；樹中的每個非葉子節點（nonterminal node）代表著一個由其子孫組成的一個模塊，層次結構已被記錄為一個模塊向導[9]，層次結構和向導旨在達到以下的額外目標，

e）一個軟體工程師應該能在不了解模塊內部實作的情況下理解模塊的職責，

f）一個有著明確關注點的讀者應該能簡單的辨別哪些關聯的模塊而不需要去學習哪些不關聯的模塊，這意思是讀者能在不看他們的組成的前提下區分相關的模塊和不相關的模塊，

g）非葉子節點模塊的在圖示中的分支應該足夠少，這樣設計者才有底氣能說子模塊沒有重疊的職責，并且還確實覆寫了所有的模塊想要達成的職責，在最開始的設計中，這是最有價值的，但在辨別受改動影響的模塊時也能有所裨益

D. 受限制的和隱藏的模塊

我們發現在實際的系統中并不總是能夠確定什么資訊是該屬于某個單獨的模塊，比如說關于硬體的資訊是可以替換的這個是肯定的，但是關于硬體的診斷資訊必須與用于將資訊展示給用戶和硬體維護者的模塊溝通，在硬體改動時，任何使用這個資訊的程式都有可能變動，為了減少軟體改動的成本，對提供這類資訊的模塊的使用應該做出限制，受限制的介面在向導中被標記了“（R）”，通常某些較小模塊的存在本身就是較大模塊的秘密，在一些情況中，我們已經在這個檔案中提及了這樣的模塊來明確某些函式執行的位置，將這些模塊稱為隱藏的模塊，并且在檔案中標記為“（H）”，

E.模塊描述

模塊向導展示了職責是如何分配到主要模塊的，這樣的向導是為了讓讀者能找到實作了系統特定方面的模塊，這個檔案宣告了將特定職責分配個某個模塊的原則，還把模塊編排好讓讀者找到和他目標相關的資訊而不需要查找不關聯的檔案，向導定義了范圍（scope），和獨立設計檔案的內容，

三種描述一個基于資訊隱藏的模塊結構的方法如下：

1. 根據獨立模塊在系統整體運作中扮演的角色，

2. 根據與每個模塊相關的秘密，

3. 根據每個模塊提供的設施（facilities），

模塊向導通過characterizing每個模塊的秘密來描述模塊結構，Where useful, a brief description of role of the module is included. 模塊facilities的細節描述被放到了其他的檔案，稱之為“模塊定義”，比如, [2] ，模塊向導會告訴你哪些模塊需要改動，模塊定義會告訴你如何使用模塊和模塊必須做什么，

對于某些模塊，我們發現區分主要秘密和次要秘密是很有用的，主要秘密指的是針對于軟體設計者的隱藏資訊，而次要秘密則是指設計者在試圖隱藏主要秘密時采用的實作決定，

在模塊向導，我們嘗試盡可能精準的描述分解的規則，但未來技術上的改動使得某些邊界模糊了，在這種情況下，我們會注意模糊的區域，并討論用于解決歧義的額外資訊，

F. 用以說明的例子

為了展現我們的技術如何運作，我們給出A-7OFP模塊向導中一個相當龐大的提煉，我們會在提煉后討論這個東西如何幫助構建和維護，

我們展示的設計是由Naval Research Laboratory（NRL，海軍研究實驗室）生產的A-7E飛行軟體中模塊結構，A-7E飛行軟體是硬實時（hard real-time）程式，用于處理飛行資料和控制飛行員的屏顯，軟體通過一個慣性導航系統計算飛機的位置，并且必須高度精確，當前的操作程式is best understood as 一個大模塊，在實作某個特定的改動要求時很難區分必須要修改的程式的部分，我們的軟體結構就是為了滿足上面提高的需求而設計的，但必須仍滿足所有的準確和實時性的限制，

以下是對NRL版本的軟體的模塊向導的提煉 [7] ，向導的完整備份或者任何其他NRL的報道能通過向寫信給NRL獲取，

Ⅲ. A-7E 模塊結構

A.頂層分解

軟體系統包括以下三個模塊，

A.1 硬體隱藏模塊

硬體隱藏模塊包含了這樣的程式——當硬體的任何部分被相同能力但不同介面的新unit取代時，需要變動的，這個模塊實作了一個虛擬硬體給系統的其他部分使用，該模塊的主要秘密是在檔案 [9] 中篇章1和2里描述的硬體—軟體介面，該模塊的秘密是資料結構和用來實作虛擬硬體的演算法，

A.2 行為隱藏模塊

行為隱藏模塊包含了這樣的程式——當像需求檔案中描述的需求行為的部分 [9,ch.3,4] 發生改動時，需要變動的，該模塊的主要秘密是這些部分的內容，這些程式決定被送往硬體隱藏模塊提供虛擬輸出設備的值，

A.3 軟體決策模塊

軟體決策模塊隱藏了軟體設計決策，包括基于數學理論，物理事實和編程考量如演算法效率以及精確性，該模塊的秘密不在requirements檔案中，這個模塊和其他模塊的區別包括兩點，秘密和介面是由軟體設計者決定的，這些模塊的改動更可能源自改善表現的嘗試，而非外部強加的改動，

關于頂層分解的Notes

上面的定義存在的模糊性源自以下幾點

a）需求定義和軟體設計之間的界限已在寫下需求檔案時被決策部分確定了；比如說武器彈道模型也許被系統分析家挑選好并在需求檔案中指定了，又或者通過宣告準確度需求但不指定演算法而被留給軟體設計師審慎決定，

b）硬體特征和軟體設計之間的界限難以區分，硬體可能構建來取代當前軟體完成的服務；因此，那些模塊可以既可以視作隱藏硬體特征的模塊，也可以視作隱藏軟體設計決策的模塊，

c）硬體上、系統行為上的改動或用戶可能會使得軟體設計決策不那么合適，

d）所有的軟體模塊都包含了軟體設計決策；任何模塊都有可能因為效率和精確度的考慮而做出改動，

這樣的模糊性對我們的目標而言是無法接受的，我們可以通過一個精確的需求檔案如 [9] 來排除模糊性，這個檔案指出了行為、硬體，軟體決策之間的界限，

a）當需求檔案指定了一個演算法，我們不認為演算法的設計屬于軟體設計決策，如果需求檔案只宣告了演算法必須滿足的需求，那么我們認為實作了這個演算法的程式是軟體設計決策模塊的一部分，

b）軟體和硬體之間的介面在軟體需求檔案中指定，硬體特征和軟體設計之間的界限必須基于對未來改動可能性的預測，如果硬體未來實作某個特定設備是相當有可能的，那么實作該設備的軟體模塊就該劃分到硬體隱藏模塊，我們一貫采取保守立場；該設計基于這樣的假設，即劇烈改動的可能性低于改革變動，如果在硬體隱藏模塊方面有些改動，如果有激進的改動試圖取代先前由軟體支撐的服務，一些軟體決策模塊會被移除或者縮減大小，

c）一個模塊只有在需求檔案發生改動的時候仍然有用（盡管可能不再高效）時，才能算軟體決策模塊

d）一個模塊內的秘密不包括軟體需求檔案中寫出的資訊時，才能算在軟體決策范疇中，

B. 第二層分解

B.1 硬體隱藏模塊分解

硬體隱藏模塊包含兩個模塊，

B.1.1 拓展計算器模塊

拓展計算器模塊隱藏了航空電子計算器的硬體—軟體介面，這些是我們認為計算器修改或替換時可能會改動的，

航空電子計算器之間的硬體—軟體介面、硬體中直接實作的能力都是各不相同的，比如說一些航空電子計算器內置了實數的浮點近似值，然而其他的通過 a programmed sequence of fixed-point operations 來實作對實數的近似操作，一些航空電子系統是單處理器；其他的系統是多處理器，拓展計算器提供能在絕大多數航空電子計算器中高效使用的指令集，這個指令集包括了對應用無關的資料型別的操作、序列控制操作、和一般I/O操作，

拓展計算器的主要秘密是：處理器的個數，計算器的指令集，和計算器處理并發操作的上限，

拓展計算器模塊的結構見C.1.1，

B.1.2 設備介面模塊

設備介面隱藏模塊隱藏了那些被認為可能改動的外圍設備的特征，每個設備都有可能被更好的上位替代物所取代，更換的設備在他們的硬體—軟體介面上有著較大的不同，比如說，所有的攻擊角度傳感器會計算飛機上的基準線和周圍氣團的速度之間的角度，但是他們的輸入格式，timing，和資料中的噪點是不同的，

設備介面模塊提供虛擬設備給系統的其余部分，虛擬設備并不一定要和物理設備對應，因為所有提供能力的硬體并不一定在同一個物理unit中，并且，單個物理unit中的一些能力也可能獨立于其他能力而改動；隱藏那些會在不同模塊中獨立改動的特性時很有用的，

設備介面模塊的主要秘密是：卸載需求檔案中的當前設備的特性，和不太可能被上位取代的特性（not likely to be shared by replacement devices)

設備介面模塊的結構見C.1.2，

關于硬體隱藏模塊分解的Notes

硬體部分在設計CPU的人眼中是外部設備，但在某些其他檔案中卻是處理器的一部分，我們對計算器和設備的區分基于當前的硬體以及遵循需求檔案內容，應用于多個設備的資訊被認為是拓展計算器的秘密；而僅關聯單個設備的資訊則是設備介面模塊的秘密，比如有說一個用于在多個設備中溝通的模擬—數字轉換器；這個轉換器被拓展計算器隱藏，盡管它也可以視作一個外部設備，又比如另一個例子，現有為了測驗I/O通道的特定輸出；他們不和某個單獨的設備關聯，這些輸出是拓展計算器的責任，

如果所有的硬體在同時被替換，可能會在計算器和設備之間出現職責的重大轉移，在如A-7E的系統中，這樣的改動并不常見；單獨設備的替換和單獨替換計算器的情況更加常見，我們的設計是基于這種替換模式將繼續保持的預期，

B.2 行為隱藏模塊分解

行為隱藏模塊包含兩個模塊：一個共享服務（SS）模塊和由前者支撐的函式驅動（FD）模塊，

B.2.1 函式驅動模塊

函式驅動模塊包含一套獨立模塊，稱之為函式驅動器；每個函式驅動器是一套緊密關聯的輸出的唯一控制器，當將輸出的值在一起描述比各自描述更加簡單的時候，認為這些輸出就是關聯緊密的，比如說，如果某個輸出是一個角度的sin值，另一個是該角度的cosine值，那么聯合描述將會比兩個分別描述smaller，需要注意的是，函式驅動模塊和硬體隱藏模塊創建的虛擬設備打交道，而不是物理輸出，函式驅動模塊的主要秘密是：決定這些輸出的規則，

函式驅動模塊結構見C.2.1

B.2.2 共享服務模塊

因為所有的函式驅動器在同一架飛機上控制系統，行為的某些方面在多個函式控制器之間可能會重合，我們希望如果行為的某個方面發生了改動，那么這會影響所有共享了該方面的函式，因此，我們確定了一套模塊，每個都隱藏了一個應用了多個輸出的行為的方面，

共享服務模塊結構見C.2.2

關于行為隱藏模塊的Notes

因為檔案的使用者大概是不知道函式行為的哪一方面被共享了，函式驅動模塊的檔案會包含它所使用的共享服務模塊的參考，一個維護者應當總是從向適當的函式驅動模塊查詢開始，他會在合適的時候被導向共享服務模塊，

B.3 軟體決策模塊分解

軟體決策模塊被分為了

1. 應用資料型別模塊，隱藏了某些變數的實作，

2. 物理模型模塊，隱藏了用于模擬物理現象的演算法，

3. 資料banker模塊，隱藏了資料更新政策，

4. 系統生成模塊，隱藏了那些決策——被推遲到系統生成時間的，

5. 軟體公用工具模塊，隱藏了被多個其他模塊中使用的演算法，

B.3.1 應用資料型別模塊

應用資料型別模塊，較之拓展計算器模塊提供的資料型別，做了補充、提供更多資料型別，對航空電子應用有用且不需要依賴計算器實作，這些資料型別是基于拓展計算器提供的資料型別實作的；這些型別的變數在使用時就像這些型別是在拓展計算器內置中的一樣，

應用資料型別模塊的秘密是變數中使用的資料表示和在這些變數上實作操作的程式，這些變數可以不考慮單位地使用，必要時，模塊提供轉換運算子，以指定單位傳遞或接收實際值，

運行時效率的考慮有時要求應用資料型別的實作基于另一個模塊的秘密，在這種情況下，這個資料型別會在應用資料型別模塊的檔案中指出，但是實作會在檔案中描述，且會包含適當的參考，

應用資料型別模塊結構見C.3.1

B.3.2 物理模型模塊

軟體要求若干的預料，數量無法直接測量但是可以通過物理世界中可觀察的模型來計算，物理模型模塊的主要秘密是是物理模型；次要秘密是計算機對這些模型的實作，

物理模型模塊的結構見C.3.2

B.3.3 資料Banker模塊

多數資料由一個模塊生產，然后被另一個模塊“消耗”，通常，消耗者應該收到盡可能最新的值，資料banker模塊更像一個“中間人”，他決定這些資料的新值何時該計算，資料banker從生產者處獲取值；消耗者程式通過資料banker的訪問程式來獲取資料，The producer and consumers of a particular datum can be writter 而不知道資料banker是否存盤值或一個存盤好的值是否已更新，多數情況下，當更新政策改動時，生產者和消耗者都不需要修改，

如果消耗者要求生產者計算出的序列中的某個特定成員，或者他們要求關聯于某個特定時間——比如某個事件發生的時候的值，就不該使用資料banker，

一些能在資料banker中使用的更新政策如下表，兩列分別表示資料banker是否存盤某項的復制和何時計算新值，

在這些或者其他更多的更新政策中的選擇，應當基于消耗者對準確性的需求，消耗者需求值的頻率，消耗者所能等待的最長事件，值變化的頻率，以及生產一個新值的成本，因為這些決定并不基于消耗者和生產者的編碼細節，當生產者和消耗者改動時通常沒必要重寫資料banker模塊，

B.3.4 系統生成模塊

系統生成模塊的主要秘密是：被推遲直到系統生成時間的決策，包括了系統生成引數的值和在可替換的模塊之間的選擇，系統生成模塊的次要秘密是用來生成代碼的機器可執行格式的方法和被推遲的決策的representation，該模塊中的多數程式不運行在車載電腦上；他們運行于一個更強大的電腦上來生成車載系統的代碼，一些程式是我們系統提供的工具；另一些則是專門為這個專案開發的

B.3.5 軟體公用工具模塊

這個模塊的主要秘密是那些實作了相同軟體函式的演算法，比如順澩監視器模塊，和數學routines，比如平方根和對數運算，

C. 第三層分解

注意：處于本文的目的，僅包含描述特別具有說明性的第三級模塊，省略號表示遺漏

C.1 拓展計算器模塊分解

C.1.1.1 資料型別模塊

資料型別模塊實作了變數和實數的操作，時間段（time periods），和bit strings，資料表示和內置于計算器硬體的資料操作指令是該模塊的主要秘密——特別是，數字物件在硬體資料型別方面的表示；bitstring的表示；如何訪問bitstring中的bit；以及如何表示硬體計時器的時間的，該模塊的次要秘密是范圍和需求是如何決定表示的；執行數字運算的程式；執行bitstring操作的程式；以及如何通過一個陣列名字和下標獲取陣列元素的記憶體位置的，

...

C.1.1.4 計算器狀態模塊

計算器狀態模塊持續追蹤拓展計算器當前的狀態，其可能是操作中，關閉，或失敗，并向用戶程式發送相關狀態變化的信號，主要秘密是：硬體檢測和造成狀態變化的方式，在EC已被初始化后，這個模塊將觸發初始化系統其余部分的事件，

...

C.1.1.7 診斷模塊（R）

診斷模塊提供診斷程式來測驗硬體中斷，I/O硬體，以及memory，該模塊的使用被限制了，因為該模塊回傳的資訊會揭示拓展計算器的秘密，比如說，如果航空電子計算器被其他計算器替代了，那么使用這些資訊的程式或許就需要修改，

C.1.1.8 虛擬記憶體模塊（H）

虛擬記憶體模塊提供了一個均勻的可尋址虛擬記憶體給資料， I/O，和序列子模塊，允許他們為了資料或子程式使用虛擬地址，虛擬記憶體模塊的主要秘密是硬體存盤資料的方式和實際記憶體中的指令；不同記憶體區域尋址方式的差異是隱藏的，該模塊的次要秘密是分配實際記憶體到虛擬地址的政策以及將虛擬地址參考轉換為實際指令序列的程式，

...

C.1.2 設備介面模塊分解

下表描述了設備介面子模塊（DIM‘s）和他們的秘密，“如何閱讀...“的短語旨在較自由的被解釋，比如說，它包含了設備相關的更正，篩選，以及其他任何對于由設備輸入決定一個物理值而言是必要的動作，所有的DIM‘s 隱藏了對他們控制的設備的測驗程式，

...

C.2.1 函式驅動器模塊分解

下表描述了函式驅動子模塊和他們的秘密

C.2.2 共享服務模塊分解

共享服務模塊由以下模塊組成

C.2.2.1 模式決定模塊

模式決定模塊決定系統模式（正如在需求檔案中定義的那樣），該模塊在模式切換時，會發出信號，并且會激活當前模塊的身份標識，模式決定模塊的主要秘密是：需求檔案中的模式切換表，

C.2.2.4 系統數值模塊

一個系統數值子模塊會計算一系列的數值，其中一些可能被多個函式驅動器使用，該模塊的秘密是：需求中決定數值如何被計算的規則，需求中的共享規則制定了這一類——1）多個可替換資源中的選擇，2）對其他模塊生產的數值的應用篩選，或者3）對其他地方計算的數值施加的限制，

該模塊可能包含一個僅在一個模塊驅動器中使用的數值，如果用于計算該數值的規則和用來計算其他共享數值的規則一樣的話，

每個系統數值子模塊還負責觸發根據其計算的值定義的信號事件，

...

C.3.1 應用資料型別模塊分解

應用資料型別模塊分為兩個子模塊，

C.3.1.1 系統資料型別模塊

系統資料型別模塊實作了以下被廣泛使用的變數型別：加速度，角度，角速率，字符文字，密度，馬赫數，距離，壓力和速度，這些模塊也可能用來實作一些受范圍限制或特定解釋的型別（比如說，用角度用來表示維度）

C.3.1.2 狀態切換事件模塊

STE模塊實作了有限狀態的的實體的變數，用戶可以等待變數 到/從特定狀態值的轉換，促使轉換并比較值是否相等，

C.3.2 物理模型模塊分解

物理模型模塊包含以下模塊

C.3.2.1 地球模型模塊

地球模型模塊隱藏了地球的模型和它的大氣層，這些模型包括本地重力的模型，地球的曲率，海平面壓力，磁場變化，本地地形，以及地球的自轉，科里奧利力，大氣密度，

C.3.2.2 飛機運動模塊

飛機運動模塊隱藏了飛機的運動，他們用來計算飛機位置，速度和attitude from observable inputs，

C.3.2.3 空間關系模塊

空間關系模塊包含了三維空間的模型，這些模型用于用于協調坐標變換以叫角度和距離計算

C.3.2.4 人為因素模型

人為因素模型是基于飛行員反應時間的模型和感知模擬連續運動的模型，模型決定了顯示幕上標識的更新頻率，

C.3.2.5 武器行為模塊

武器行為模塊包含了用來預測武器釋放后的行為的模型，

Ⅳ. 總結

我們當下得出的任何結論都只是暫時的，因為他們還未被實際的運行所證明，盡管如此，我們已經使用模塊向導許多年了，而且也確實很可靠，它在我們的開發流程中起到了很重要的作用；當開發者和設計者不確定某個模塊的位置時，他們就會求助于模塊向導，許多的討論通過這種方式解決，而且這些討論的最后結論都是相當少，且相當淺的改動，

我們的經驗告訴我們資訊隱藏的使用在復雜系統中是切實可行的，但僅在這種情況下——即設計是從，一個用來指導獨立模塊介面的模塊向導，而開始設計的，當我們嘗試不適用向導作業時，許多問題從破爛的構造中溜走，而且職責的分配最終也會要么落在兩個模塊，要么直接沒有，有了模塊向導，設計上的進一步的進展已經揭示了相當至少的疏漏，新加入團隊的開發者可以迅速掌握專案的結構的脈絡而不需要和老成員溝通很久，我們覺得這可以改善Brooks的格言，"Adding more men then lengthens, not shortens, the schedule" [8]，

我們指導我們用來說明的模塊向導的描述算是戛然而止，向導中提到的多數模塊都劃分成了子模塊，但這些子模塊沒有討論到，我們發現使用為小模塊使用獨立的模塊向導要比拓展某個向導更加的方便，這個模塊向導是所有實作者都必須要閱讀的檔案；其他的則是給特定的人，這個向導長度小于30頁，且 we can afford to let everyone read it，

在寫這個和其他的模塊向導時，我們發覺重要的是專注于描述模塊的秘密而不是模塊的角色，當我們忘記這一點的時候（通常是我們迫于deadline時），最終模塊并不具備清晰的職責然后要調整這些模塊，

模塊向導，像我們的需求檔案，提供了對我們稱之為“通過檔案設計”的方法的好處的清晰說明 [4] ，寫檔案是我們在設計上進步的方法，檔案之后會在未來的設計上指導我們和其他人，

在另一個論文中 [10] ，我們已經討論了這種方式可以增加我們產出的軟體更加可復用的可能性，那個論文使用了相同的例子討論了相當不同的點，

標籤：其他

上一篇：Serverless Kubernetes 再升級 | 全新的網關能力增強

下一篇：機械學習筆記1 -> Solidworks三維產品設計與建模1 | 建模基礎入門