歡迎來到演算法、軟體和硬體三位一體的未來世界論文書籍站
Middleware 意思的問題，透過圖書和論文來找解法和答案更準確安心。 我們找到下列懶人包和總整理
Middleware 意思的問題，我們搜遍了碩博士論文和台灣出版的書籍，推薦邱毅凌寫的 嵌入式系統開發之道：菜鳥成長日誌與專案經理的私房菜 可以從中找到所需的評價。
國立成功大學 資訊工程學系 鄭憲宗所指導 黃奕崴的 大數據串流平台上降低感測資料傳輸的方法 （2016），提出Middleware 意思關鍵因素是什麼，來自於大數據、動態傳輸、資料壓縮技術、In-memory Computing、Spark Streaming。
而第二篇論文國立政治大學 資訊管理研究所 周宣光所指導 郭鎮武的 數位時代博物館經營模式探討－國立故宮博物院個案研究 （2011），提出因為有 無線射頻識別、U化資訊應用、博物館、Ｕ化博物館、故宮博物院的重點而找出了 Middleware 意思的解答。
嵌入式系統開發之道：菜鳥成長日誌與專案經理的私房菜
為了解決Middleware 意思 的問題，作者邱毅凌 這樣論述：
老鳥流淚！新手必看！史上最平易近人的嵌入式專案開發書籍獻給正在這個業界努力求生存，以及將要踏入這個領域的勇士們！ ■以幽默逗趣的職場對話，點出嵌入式系統開發的精髓。 ■脫離傳統介紹嵌入式系統原理和設計理論，直接切入實戰現場。 ■透過完整的專案架構，循序引導正確的嵌入式系統開發觀念。 ■用正統派的專案管理知識，貫穿電子產品開發生命週期，指引工程人員職涯發展再上層樓。 這是一本專為系統開發人員撰寫，以能快速理解何謂「嵌入式系統」的書，作者以自身擁有的豐富經驗與見聞，不藏私地分享在嵌入式領域真正有用的觀念。 本書最大的特色是以一個完整的嵌入式系統開發流程為架構，透過一位菜鳥工
程師與專案經理的詼諧對話，故事性的帶出系統觀念及開發要素，實際瞭解要成為一位稱職的嵌入式系統工程師，於實務工作上所必須具備的各項知識及技能。是一本能讓你少走冤枉路，學習如何輕鬆的駕馭並有效率完成開發專案的實用指南。 新版特色 ■重新改寫專案架構，更貼近開發人員的實務核心。 ■基於嵌入式系統開發專案的特性，深入說明專案管理的觀念與工具。 ■完全揭露專案進度追蹤實務，透過工具可更有效率的執行專案，避免專案進入無限輪迴。 ■透過新增多個實際案例的探討，加重力道闡述系統架構設計的方法與重要性。 ■全面性收錄目前嵌入式系統開發領域中，從業人員不可不知的所有面相，包含以下幾個嵌入式系統
書籍的創舉： ．闡述硬體抽象層（HAL）對嵌入式系統團隊之重要性，並詳實說明其開發實務。 ．完整揭露實現NAND Flash系統的流程與不可忽略的重點技術。 ．剖析開發Turnkey Solution與一般嵌入式系統專案的異同與注意事項。 ．深入探討IC設計公司之嵌入式系統團隊（System Application；SA）的管理。 作者簡介 邱毅凌 成功大學工程科學研究所計算機組碩士，畢業論文為分散式物件導向作業系統的實作，從此與系統底層結下不解之緣。畢業後進入資策會，開發了生平第二個作業系統，並任專案經理，開始電子產品開發專案管理的工作。 之後赴大陸深圳的網京科技公司帶領研
發團隊，技術主軸為資訊家電（IA），2001年任職台北的Canon研發中心，期間除了負責系統開發與研發人員管理之外，並主導台灣、大陸、日本、美國、韓國等研發單位的共同開發專案。 2007年，加入國內某上市IC設計公司，擔任SA團隊的部門經理，順利導入專案管理與軟體工程的研發流程，並改善品質系統與開發效率。 專長：作業系統實務、嵌入式系統開發與專案管理 著作：《現代嵌入式系統開發專案實務》 第01章 系統．嵌入．硬體 第02章 嵌入式專案管理 第03章 嵌入式系統開發專案生命週期：專案啟動與規劃 第04章 嵌入式系統開發專案生命週期：設計、執行與結案 第05章 實作你的第一個嵌入式
系統 第06章 實作嵌入式系統平台 第07章 建構良好的嵌入式系統開發環境 第08章 上電之後：Boot Loader 第09章 驅動程式 第10章 設計硬體抽象層 第11章 菜鳥當自強：軟體工程師硬起來 第12章 做好記憶體管理 第13章 記憶體管理(II)：NAND Flash概論 第14章 模擬器 第15章 專案進度追蹤實務 第16章 SoC設計公司中嵌入式系統團隊的管理 第17章 系統整合 第18章 Testing、Debugging與Tuning 第19章 結案前的煎熬 附錄A 未執行專案管理的專案 附錄B Callback Function 附錄C 用C來實作物件導向的概念
附錄D 電子產品設計的最終依據：用戶體驗 作者序 《現代嵌入式系統開發專案實務》自2007年6月上市至今已有三年多的時間了，期間收到相當多的反饋、鼓勵、建議與指教，最令人開心的，則是能夠對想進入嵌入式系統開發領域的朋友提供諮詢，他們透過這本書找到了筆者，讓筆者有機會分享自己在這個領域的經歷與體驗，讓迷惘的朋友可以得到指引。本書強調的是『正念』（正確的觀念），亦即嵌入式系統開發與專案管理的觀念，不會因產品不同而有太大的差異，但筆者仍認為本書必須與時俱進，除了內容更豐富完整之外，還加入了筆者這些年來產業觀察與實際執行電子產品開發專案的心得，還延請更專業的出版團隊進行編製，使得這本書的品質
更加精良。 邱毅凌 6-07 SDK 菜鳥：「有個問題一直困擾著我。所謂的SDK（Software Development Kit）應該是以開發系統為主的大公司，如Microsoft、Apple、Google，提供給產品開發商，讓他們可專注於諸如Windows、iPhone、Android應用程式開發的套件。而本公司主要是接電子產品開發案，面對的客戶通常就是出錢與出嘴巴，比較積極的客戶會介入我們的品質檢測流程，我的意思是說，客戶並不直接參與開發工作，我們也不需要提供開發套件給客戶。既然如此，為什麼我們在做系統架構設計與工作分組時，還要特別組成SDK team，負責所有與嵌入式系統平台相關的工
作？」PM：「記不記得我對所有專案成員都有一個要求：永遠要把上一層的團隊當作客戶。從系統架構圖來看，system team是driver team的客戶、middleware team是system team的客戶，而AP team則是所有軟體研發團隊的客戶，若再往後延伸，工廠是硬體、軟體團隊的客戶等等。唯有用這樣的觀念做事，團隊間才能權責分明，而系統中各部份的規格才有辦法真正符合外部客戶的需求。但據我觀察，一般研發團隊的文化恰恰相反，他們認為越底層才是越有技術的，既然底層團隊以技術掛帥，一不小心就會變成閉門造車，完全不認真考慮上層的真正需求。而上層團隊往往也只能逆來順受，用不合適的系統介面，
勉強地按照客戶的規格開發應用程式，工作效率與產品品質難免因此而大打折扣。無論底層或上層團隊，對公司來說一樣重要，我要表達的是『越接近真正客戶的團隊，他們的意見越應該被重視』。我一直設法跟公司高層與專案成員灌輸這樣的觀念。消費性電子產品的開發一定是top-down的，一切都必須由終端市場或使用者需求啟動，亦即所有的研發目標都必須對準end user，所以硬體上最重要的是機構外觀與製造成本，軟體上則是應用程式，然而很多公司都本末倒置了！」菜鳥：「每次我問A，你都不正面回答，往往答案都直接跳到X、Y、Z去。恕弟子駑鈍，我的問題是：為什麼嵌入式系統開發團隊必須維護自己的SDK？你卻回答要把上層當作客戶
、開發產品應該是top-down。是不是有點太離題了？」6-7-1 為何嵌入式系統開發團隊必須維護自己的SDK？PM：「我不至於那麼跳tone吧！你仔細想想，既然微軟必須提供SDK給開發Windows應用程式的客戶，為什麼我們的系統團隊不必為應用程式團隊準備SDK？在討論下去之前，你先說說我們的SDK裡面包含什麼套件，有什麼用途？」菜鳥：「SDK的目的其實就是建立我們（即本章）一直討論的嵌入式系統平台，提供應用程式開發人員『舒適』的開發環境與足夠的系統功能。根據我們的定義，SDK（或說嵌入式系統平台）應該包含：■ 開發環境：tool-chain + IDE + debug tool。■ 系統功
能：為所有系統與硬體功能定義明確的API，並將其implementation包裝為函式庫（Library）。若有必要，可提供少數系統模組的原始碼，供上層工程人員作客製化之用。■ API文件與SDK使用手冊。■模擬器環境（Simulator或Emulator）：圖6-25就是iPhone OS SDK提供的模擬器環境，當沒有硬體環境時，也可以進行應用程式的開發。■ 硬體環境：EV-board（評估板）、EV-board使用手冊、線路圖。■ 其他工具：系統更新工具、系統效能統計工具（Profile Tool、BenchmarkTools）、Resource（text & image）轉換工具等。圖
6-25：iPhone OS SDK提供的iPad模擬器（Emualtor）SDK包含了必要的開發工具與範例程式，讓工程師能夠馬上進行應用程式的開發，不必理會程式編譯、image build、下載、除錯等細節。此外，系統與硬體功能應已經過嚴謹的抽象化，工程師只要關注自己要開發的部份，系統功能都可以當成是黑盒子。」PM：「依據SDK的定義，你再思考一下，包裝SDK會需要多少額外的effort？以及SDK可以為我們這樣的嵌入式系統開發團隊帶來什麼優勢？」菜鳥：「按照以上的列表來看，全都是本來就必須要做的事，只是找個專職單位負責將其包裝SDK Package，讓其他工程師可專注於應用程式的開發，以滿
足客戶的真正需求。有些單位會認為包裝SDK Package需要更多的時間人力資源，我想是因為訂定不出API的原因吧！若在設計階段，系統架構中並未嚴格規範driver/system/middleware/AP之間只能透過API溝通，則工程師在實作時，上下層間難免交互參考，造成系統與應用程式模組間的耦合度過高，此時才想要包裝出所謂的SDK當然是困難重重。
大數據串流平台上降低感測資料傳輸的方法
為了解決Middleware 意思 的問題，作者黃奕崴 這樣論述：
隨著感測技術的進步，對於許多感測器應用於各種環境下而產生的巨量資料，如何善用這些巨量資料成為新的商業模式。如何在短時間內可以處理更多資料，甚至是達到即時性分析應用。從過去的分散式運算架構MapReduce，在一些情況下如:機器學習或多層次的迭代運算已經不符合Real-time的需求。主要是MapReduce 缺少一個重要的要素 “有效的資源共享”。為了解決這類的問題，記憶體內運算(In-memory Computing IMC)的概念被提出來。IMC就如字面上的意思，將中間運算的結果都存在記憶體內，而不再是頻繁地存取硬碟，解決了磁碟I/O的效能瓶頸。近期經典的應用就是Apache Spark
。Apache Spark 是開放原始碼的叢集運算框架，它在資料量越大時，能夠比MapReduce快上幾十倍。然而它仍然無法解決一個瓶頸 “頻寬”。感測資料從各個節點傳入，感測器會受限於資源如: 記憶體，能源、頻寬….等等。根據觀察，這些感測資料因為空間相依性或時間相依性而有一些相似的序列。因此，壓縮資料技術將會是個不錯的解決方案，利用較小的資料量來代表較大的資料量。藉此，來解決感測器資源上的限制，同時提高Spark 的資料使用率。本研究提出了降低感測資料的傳輸方法來優化IMC平行化串流運算平台Spark Streaming。利用前處理來提高資料的相似度，讓壓縮技術能夠取代更長的樣式。另一方面
，將壓縮與動態傳輸結合在一起，來達到即時性兼顧高壓縮率的效果。因此，降低感測器所要消耗的能量，延長感測器的壽命。同時，在同個頻寬下，可以傳輸更多資料進而提升了運算平台的處理能力。
數位時代博物館經營模式探討－國立故宮博物院個案研究
為了解決Middleware 意思 的問題，作者郭鎮武 這樣論述：
國立故宮博物院（以下簡稱故宮）文物典藏是中國藝術與工藝中的菁華，也是歷史研究的重寶。故宮在Ｕ-Taiwan計畫下，期望透過建置故宮U化（提供行動載具、無線射頻、無線感知網路等）的基礎建設、數位內容及使用介面等關鍵資通訊技術，建置隨手可得網絡服務系統，配合故宮文物ID感知上網應用，普及故宮相關加值產品之電子標籤應用，健全故宮U化產品與服務的安全與信賴機制，推動故宮感知網路設備與應用服務產業，並發展博物館U化關鍵技術，促進U化故宮數位內容及加值產品之生活應用普及率，藉以協助強化博物館運用資訊科技之競爭力。未來打造U化故宮優質示範園區，使故宮精美的文物以U化技術貼近人群，走向世界，向國內外人士展現
台灣的博物館在U化科技與應用的成就。「Ubiquitous」象徵一個概念，意思是「神無所不在」。在資訊科技時代，這個字代表藉由各種資訊產品與網路，可以實現資訊無所不在的理想世界。配合u-Taiwan計畫，我國的U化建設主要是以無線感知、RFID為主的技術來進行。RFID 運用於博物館館務作業，不但可節省人力、時間，還可以將資料做妥善的應用，增加擴大博物館的服務範圍層面。本研究就應用 RFID 全方略導入博物館經營模式，建議基本上可分為下列五項：門禁管理、自動導覽、典藏管理、盤點管理及出版發行管理。研究指出 RFID 應用於博物館的魅力在於協助導覽、增進學習效果、加速盤點作業與安全管理上，皆充分
的展現出其優異之特性。因之，博物館業界，當應善加運用 RFID技術，並融合資訊科技，設計出適合博物館各自的經營模式與功能需求，以嶄新且多面向的展示，呈現予觀眾。