對于成功的組織，使企業開發團隊的成員使用相同的聲音進行交流是最基本的：不同的涉眾針對系統的設計和實現有不同的視圖，并且如果他們不使用同一種通用的詞匯表和表達語言，統一團隊的活動是不可能的。
這是統一建模語言（UML）的角色之一，UML是對象管理組織（OMG）的一項標準。UML是一種可視化的詳細的構建并文檔化軟件系統工作產物的圖形化語言。
對于一個建筑項目，你不能僅用藍圖中的單一一頁來呈現，詳細描述，構建和文檔化一個高大建筑。軟件也是如此：為了獲得所有的策略性的系統設計決策，你需要幾個不同的系統體系架構的視圖，每一個視圖針對者團隊中的不同涉眾。見圖1所示，對于下面描述的軟件系統來說，存在著五個非常重要的視圖。
圖1：用例視圖系統的用例視圖是面向指定的最終用戶的，這個視圖獲取了系統需要擁有的功能。這個視圖對測試人員也是同樣重要的。對于測試人員來說用例形成了對每一個個執行版本回歸測試的基礎。
系統的邏輯視圖是分析人員和設計人員最感興趣的，邏輯視圖與實現了來自于第一個視圖的用例的架構上的重要機制一起的描述了系統的問題領域的詞匯表。在這個視圖中，你將找到描述問題領域的應用，數據和業務模型，它邏輯視圖與類，包，子系統和協作一起實現了系統的用例。
系統的過程視圖描述了系統對過程和任務的分解，并且描述了并發元素的通訊和同步。這個視圖對于從事整個系統的性能可測量性的系統集成人員來說是最重要的。系統的實現視圖捕獲了被系統的編程人員產生的工作產物，這個視圖用于建�？蓤绦薪M件和相應的源文件以及形成可執行部分的內容。這個視圖位于項目配置管理實踐的中心，以及描述了那些在每一個迭代中被組裝成為可執行版本的組件。
系統的部署視圖是項目的系統和網絡工程師最關心的視圖，系統和網絡工程師負責系統硬件拓撲以及交付和安裝搭建系統。這個視圖描述了系統的物理網絡配置。
所有的這些視圖都是用UML來表示的。例如，類圖可以被用來顯示邏輯視圖的靜態部分，組件圖可以被應用到組件視圖。每一個視圖的動態元素可以通過使用UML的行為圖中的任何一種來獲取，象交互圖和狀態表圖。此外，通過UML的擴展機制，對語言進行相應的調整以使它可以表達特定領域的需求是可能的。比如，Jim Conallen創建的Web應用擴展就是針對以Web應用系統為中心的UML的擴展應用。通過使用這個藍圖的通用語言，不同的涉眾可以貢獻他在特定領域的專家建議，同時使用UML可以與其他的涉眾進行良好的交流。
使開發團隊使用同一種聲音的價值對于哪些大數據應用來說格外的明顯。無論在哪，數據庫的設計人員都必須與系統分析人員和應用的開發人員一起工作以構建系統。傳統的情況下，系統的數據中心部分使用實體－關系（ER）技術來進行建模。ER方法對開發團體的服務非常的好，但是，開發世界已經發生了顯著的變化，以至ER方法已經能很難作為數據庫設計人員與其他涉眾進行交流的工具，并且它也很難再來表達目前大數據系統的語義。正如Dorsey 和 Hudicka所說的那樣，"有一種強制的需要應用如此靈活的，有活力的并且是面向對象的UML來代替當前業界標準的ER建模"。事實上，這也是被Rational Software開發的UML在數據側面擴展（data profile extension）方面的真正意圖。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
