第一章 系統分析與設計簡介
1-1 資訊系統
一、資訊系統簡介
[資訊系統] 13 | 85,86,88,92(2),93(2),94(2),95,96,97(2)
85地三、86高三、88高三、92調三、92檢三、93退三、93電員晉高、94警三、94專檢、95身三、96關簡、97高二、97地三
(一)定義
是指可記載、保存各種活動的資料，然後加以整理、分析、計算，產生有意義、有價值的資訊。這類資訊可供決策者制定決策與行動時參考。
(二)組成元件
1.硬體：伺服器、工作站、網路、通訊設備、光纖纜線。
2.軟體：系統軟體、應用軟體。
3.資料：資料→資訊→知識。
4.程序：實際的日常作業。
5.人員：內部使用者、外部使用者。
(三)資訊系統架構
[資訊系統架構] 3 | 98,103,106
98關簡、103高三、106外四
1.集中式架構(Centralized Architecture)：
(1)定義：
a.以集中式的大型主機 (mainframe) 來儲存一個資訊系統所有的資料、程式和介面元件供多人使用。
b.使用者透過終端機 (或以 PC 來模擬終端機) 與系統互動。
c.所有真正的處理和工作都在主機上完成。
(2)優點：
a.系統管理單純，因為所有的資源均由主機作業系統分配與管理。
b.屬於封閉式作業系統，這種作業系統再與其他系統的連接上雖然有極大的問題，但是在資料安全上卻比較容易控制。
(3)缺點：
a.主機工作負擔較重。
b.主機更替成本高。
c.維護成本重。
d.只能處理文字模式的介面，無法支援圖形使用者介面 (GUI)。
e.缺乏彈性的環境。
2.檔案伺服器架構(File Server Architecture)：
(1)定義：
a.在區域網路中，由檔案伺服器 (File Server) 負責需求排班與管理、傳送與保存資料。
b.當客戶端 (Client) 向伺服端提出需求時，伺服端會將相關的檔案完整的傳送至客戶端進行處理，然後在客戶端處理資料的運算，等完成之後再將檔案傳回檔案伺服器儲存。
(2)優點：
a.用戶端處理資料可以降低檔案伺服器處理資料的負擔。
b.可以使用圖形使用者介面 (GUI)。
(3)缺點：
a.由於每次伺服器都是傳送資料所在的完整的檔案至客戶端，因此，過大的資料流量易造成系統的瓶頸。
b.所有計算都在用戶端完成，其個人電腦最好都有不錯的運算能力 (所謂的複雜型用戶端)。
c.必須處理複雜的資料鎖定 (data lock) 問題，資料庫整合性必須妥協。
3.主從式架構(Client/Server Architecture)：客戶端-伺服器架構 / 分散式架構
(1)定義：
a.是一種網路架構，它把客戶端與伺服器區分開來。
b.前端的應用程式 (Client) 扮演者和使用者溝通的角色，強調簡單而且具備親和力的使用界面，以提供使用者進行查詢、修改、列印等輸入或輸出的作業，而後端的伺服器 (Server) 則負責執行前端應用程式所傳來的命令，並將處理的結果回傳給前端的應用程式，直接將結果顯示在使用者的眼前。至於網路系統則構築了前端應用程式與後端伺服處理器之間的互通管道。
c.透過網路連接散置各處的電腦，例如 2-Tier、3-Tier。
d.每一個客戶端軟體都可以向一個伺服器或應用程式伺服器發出請求。
e.有很多不同類型的伺服器，例如文件伺服器、遊戲伺服器等。
f.例如在維基百科閱讀文章時，電腦和網頁瀏覽器就被當做一個客戶端，同時，組成維基百科的電腦、資料庫和應用程式就被當做伺服器。當網頁瀏覽器向維基百科請求一個指定的文章時，維基百科伺服器從維基百科的資料庫中找出所有該文章需要的訊息，結合成一個網頁，再發送回瀏覽器。
(2)主從式架構(Client/Server architecture)：主從式架構的組成要件
a.一個主從式架構主要由客戶端 (Client)、伺服器端 (Server) 與網路 (Network) 三個部分組成。
b.用戶端(Client)：客戶端(Client) / 前端(front-end)
一般的個人電腦加上網路卡。透過一特定介面 (API) 與 Server 溝通，以向 Server 端提出請求，並且執行 DBMS 上的應用程式，並以適當的方式呈現出來。
c.伺服器端(Server)：伺服器(Server) / 亦稱為後端(back-end)
DBMS 本身。依 Client 端需求提供服務給使用者的應用程式。負責運算、存放共同的資料以及應付客戶端需求的主機。
d.應用程式可以分為展現 (Presentation)、處理 (Processing)、與資料管理 (Data Management) 等部份，再分別由客戶端或伺服器端來完成。
e.客戶端透過網路提出要求，而伺服器端則透過網路回應此要求。
f.使用者介面程式和應用程式可以在用戶端執行。等到需要存取 DBMS 時，程式會建立一個到伺服端 DBMS 的連結，建立好之後，用戶端程式便可以和 DBMS 溝通。例如 ODBC 提供一種能讓用戶端程式呼叫 DBMS 的應用程式介面 (API)，條件是用戶端和伺服端都要同時安裝需要的軟體。
g.網路環境：即連接客戶端及伺服器的線路及軟體。
[2-Tier]
Client 端直接與 Server 端相連來存取資料，沒有透過代理程式。
[3-Tier]
Client 端透過 Application Layer 與 Database Server 端相連來存取資料。
(3)主從式架構的優點：
a.可以達到軟體專業分工的目標，電腦作業將不受時空的影響限制，各項作業採用功能模組的分配、設計、開發、建置具備更大的彈性與便利。
b.所有的工作採用分散處理的方式，將人機介面處理完全交由客戶端 (Client) 的個人電腦或工作站負責，而主機或伺服器 (Server) 將只負責資料庫方面的資料處理工作，大幅降低主機或伺服器的工作量。
c.在主從式架構下的系統與傳統迷你及大型電腦相比，規模將大幅縮小，成本也將大幅降低，傳統迷你及大型電腦不論硬體、軟體、週邊設備都相當昂貴，同時系統又具封閉性，不容易替換產品。
d.由於 UNIX、Windows、網路等相關技術的問世，以及電腦硬體成本的大量生產導致價格大幅滑落後，採用主從架構使得電腦應用系統趨於普及，進而增加企業競爭力。
e.採集中控管，易於存取及管理。
f.簡單且與現有的系統相容性高。
g.適用於大規模的網路。
(4)主從式架構的缺點：
a.當程式需要修改或新增功能時，需分別進行修改，花費的時間及成本大，且系統較為複雜。
b.資料的安全性也有所影響，因為可能有部份資料是儲存在客戶端。
c.伺服器端的設備需求較高。
d.伺服器端的作業系統較複雜，管理人員必須接受訓練，才能妥善管理。
(5)2-Tier與3-Tier的比較：
|
比較 |
優點 |
缺點 |
|
2-Tier |
可藉由 Client 本身的運算能力分擔 Server 處理資料的負荷 |
1.針對不同的 Server 系統，需設計不同 Client 端介面 2.Client 越多，connection 越多， Server 負擔也越重 |
|
3-Tier |
可用中間的應用程式伺服器整合後端不同 Server，Client 只需面對單一的 agent 介面 |
規模不斷擴大後，中間端將成為此架構的瓶頸 |
※參考資料：
1.http://blog.cwke.org/2010/11/client-server-and-web-based.html
2.http://lips.lis.ntu.edu.tw/ycchuang/study/othersubject/datawarehouse/ClientServ.htm
3.https://tw.knowledge.yahoo.com/question/question?qid=1509102409574
4.http://www.gaya.org.tw/journal/m32/32-main4.htm
5.http://zh.wikipedia.org/wiki/%E4%B8%BB%E5%BE%9E%E5%BC%8F%E6%9E%B6%E6%A7%8B
6.http://www.ascc.sinica.edu.tw/iascc/nl/84/1109/03.html
4.Web-based架構(Web-based Architecture)：網際網路(Intemet-based)架構
(1)定義：
透過網路傳輸形成數位化虛擬世界，使用者僅需透過瀏覽器 (Browser) 便可存取所需資訊。
(2)優點：
a.跨平台：任何作業系統只要能打開瀏覽器的都可以使用。
b.節省IT人員的時間以及維護成本：
不需要公司的 IT 人員維護每一台 PC 上面的軟體。
c.使用介面學習容易。
d.資料集中管理。
e.任何地點、任何時間都可以輕鬆操作：適合跨國公司或是常出差的人員。
(3)缺點：
a.受限於 Browser 的功能，無法作太多控制及變化 (如 HTML 弄個 BOM Tree)。
b.開發人員要學的工具及語言不少，至少 Browser Script (如 JavaScript 或 VBScript)、HTML (用 Front page 或 Dreamweaver 編寫) 及動態網頁語言 (如 ASP、JSP、PHP)。
※Web Server：
專門只處理 HTTP request 與 response，當收到 HTTP request 之後，需要商業邏輯 (business logic) 的部分就從 Application Server 取，最後把 result 轉為HTTP response。
※參考資料：
http://james687.logdown.com/posts/2014/06/07/web-server-application-server
※Application Server：
接受 Web Server 的 request，執行完商業邏輯 (business logic) 之後，把 result 回給 Web Server (過程中可能需要到資料庫存取資料)。
※參考資料：
http://james687.logdown.com/posts/2014/06/07/web-server-application-server
※三層式架構(Three-tier architecture)：
106外四
(一)定義
1.三層式架構與傳統兩層式架構最大的差異處，為將商業邏輯 (business logic) 單獨分離出來，以減輕放置於用戶端或伺服器端電腦的負擔。
2.三層是指展示層 (Presentation Tier)、商業邏輯層 (Business Logic Tier)、和資料層 (Data Tier)。
3.將應用程式代理者 (Application agent) 置於 Client 與 Server 中間，存放商業邏輯 (Business logic)，以處理 Client 與 Server 間往來的業務。
4.可以整合後端不同的 Server，以統一的方式呈現內部的資料。
(二)架構
1.展示層(Presentation Tier)：
(1)個別用戶端的電腦上安裝了具備圖形化操作介面 (GUI) 的程式，而這些程式可以透過特定格式的表單，供使用者輸入適當的資訊，和將結果顯示出來，以便與伺服器進行互動。例如瀏覽器或其他用戶端應用程式。
(2)近年各種網頁服務應用日益盛行，使得單一伺服器已漸無法負擔熱門網站快速成長的網路流量。為了快速提供對用戶的服務，網頁伺服器通常採用負載平衡技術來縮短對用戶端的回應時間或是降低伺服器的負荷。
(3)網站受到攻擊事件時有所聞，未做好防禦就可能資料外洩或是系統癱瘓無法提供服務，要如何面對攻擊也成為系統管理人員重要責任。
2.商業邏輯層(Business Logic Tier)：
(1)負責運算邏輯的處理程式於伺服器電腦上執行，其功能是接受來自用戶端的請求，並且決定何種資訊可以被傳送至用戶端。
(2)做為使用者介面與資料庫的橋樑，負責商業法則 (Business Rules)、與業務有關的資料處理、網站伺服器 (Web Server) 等工作，譬如使用 IIS 的網站伺服器，得撰寫 ASP 程式，並透過 DCOM 與 MTS (Microsoft Transaction Server) 的元件相溝通，再透過 ODBC 或 OLE DB 等機制與各種資料庫相連結。
(3)應用伺服器隨時可能因某個硬體元件故障造成停機。
3.資料層(Data Tier)：
(1)包含了儲存大量資料的資料庫，以及用來管理維護這些資料的軟體。
(2)負責資料庫或訊息的處理 [如使用 SQL Server 資料庫的預儲程序 (stored procedures)，或使用 MSMQ 做訊息的處理等]。
(3)資料服務層負責提供資料給商業邏輯層，再傳送至使用者介面層，所以用戶端無法直接存取資料庫的內容，必須透過運算邏輯層的連接，因而提高了系統的安全性。
(4)資料庫伺服器硬體故障或是當機等天災人禍而無法提供服務。
※參考資料：
1.http://www.borg.com.tw/Eip/books/doc/run9811.htm
2.http://www.ee.nuu.edu.tw/board/cnews.php?id=47
3.http://webcache.googleusercontent.com/search?q=cache:QWwAiRLLx-0J:www.ceci.org.tw/book/52/ch52_2.htm+&cd=12&hl=zh-TW&ct=clnk&gl=tw
※三層式主從架構的可能設計方式：三層式分遠遠分分分
103高三
1.分散式展示(Distributed Presentation)：
|
功能 |
客戶端 |
伺服端 |
|
資料管理 |
無 |
所有資料管理 |
|
資料分析 |
無 |
所有資料分析 |
|
資料展示 |
客戶端將伺服端展示的資料重新格式化展示 |
伺服端展示資料後傳送給客戶端 |
2.遠端展示(Remote Presentation)：
|
功能 |
客戶端 |
伺服端 |
|
資料管理 |
無 |
所有資料管理 |
|
資料分析 |
無 |
所有資料分析 |
|
資料展示 |
在伺服端分析後的資料格式化後傳送給客戶端展示 |
無 |
3.遠端資料管理(Remote Data Management)：
|
功能 |
客戶端 |
伺服端 |
|
資料管理 |
無 |
所有資料管理 |
|
資料分析 |
從伺服端分析接收原始資料 (raw data) 並且分析 |
無 |
|
資料展示 |
所有資料展示 |
無 |
4.分散式功能(Distributed Function)：
|
功能 |
客戶端 |
伺服端 |
|
資料管理 |
無 |
所有資料管理 |
|
資料分析 |
從伺服端選取資料並且由客戶端分析 |
從伺服端選取資料並且分析，然後傳送給客戶端 |
|
資料展示 |
所有資料展示都經過伺服端及客戶端的分析 |
無 |
5.分散式資料庫(Distributed Database)：
|
功能 |
客戶端 |
伺服端 |
|
資料管理 |
本地資料管理 |
在伺服端的資料分享管理 |
|
資料分析 |
從客戶端及伺服端接收資料並且分析 |
無 |
|
資料展示 |
所有資料展示 |
無 |
6.分散式處理(Distributed Processing)：
|
功能 |
客戶端 |
伺服端 |
|
資料管理 |
本地資料管理 |
在伺服端的資料分享管理 |
|
資料分析 |
從客戶端及伺服端接收資料並且分析 |
資料從伺服端接收並且分析，然後傳送給客戶端做更深入分析及展示 |
|
資料展示 |
所有資料展示 |
無 |
※參考資料：系統設計與應用系統架構.ppt
※多層式架構(N-Tier architecture, Multi-Tier architecture)：
(一)定義
1.多層應用程式架構提供了開發人員可以創建靈活且可重用的應用程序的模型。
2.通過將應用程式分隔成 n 層，開發人員可以選擇修改或添加特定層，而不是重做整個應用程式。
3.在使用者與儲存資料間可以進一步分割成幾個更細的元件，其中的 n 可能是4或5。一般而言，業務邏輯層還會分割成好幾層。
(二)架構
1.把中間層劃分為多個商業邏輯層，把一個商業邏輯層當做一層，多個商業邏輯層就 n 層。這些層有些時候需要互相協調合作。
2.例如銷售時，須檢查庫存及維護庫存，接著要產生物流的送貨，這些商業邏輯層不只可以獨立的運作，也可以與其他的商業邏輯層協同運作，形成多層架構。
(三)優點：
1.較小的前端程式(Thin Client)：
前端只需要使用者介面的程式或網頁瀏覽器，容易安裝與管理。
2.零前端程式管理：
運用在 Web 環境中，前端只需要網頁瀏覽器，可以達到零前端程式管理。
3.邏輯封裝：
整個系統可按使用者介面、企業邏輯、資料管理分層實作，系統運作時分層負責，達到邏輯封裝的效果。
4.延展性(Scalability)佳：
不管何時何地，只要可連上網際網路，便可突破時空限制，隨時上線作業；中間層的應用伺服器也可以視負載情況擴充。
5.具備軟體元件重複使用性(reusability)：
企業邏輯通常以軟體元件的形式存放在應用伺服器上，具備重複使用性。
6.軟體元件版本的一致性佳：
企業邏輯的軟體元件集中放置在應用伺服器，版本的一致性獲得較佳的控制。
7.控管性、安全性佳：
網頁伺服器、應用伺服器及資料庫伺服器通常會由資訊中心統一管理，較一般散置的主從式架構系統獲得較佳的管控。
(四)缺點
1.專業技術的學習曲線過長。
2.網路的品質影響系統穩定性。
3.如何確保系統隨時正常運作？
4.在有限的頻寬如何達到最佳的系統執行效率？
※參考資料：35603805.pdf
※分散式架構(網路/計算)：
※傳統Client-Server架構與Web-Based架構的比較：
|
|
傳統Client/Server架構 |
Web-Based系統架構 |
|
系統開發 |
需花時間於瀏覽畫面的設計 |
瀏覽軟體 (Browser) 可以解決 UI 的顯示功能，不需花時間於此方面的設計 |
|
系統擴充平台 |
針對不同的平台需有不同的設計，必須修改程式碼以符合需求 |
Web Browser可解決跨平台問題，只要是 Web Browser 可支援的網路連結設定，擴充平台不需額外的設計 |
|
系統安裝 |
需有完整的安裝程序與操作說明，每次系統更動即需進行安裝 |
Web Browser 易於取得並安裝於個人電腦上，且可依喜好選擇不同的瀏覽器，第一次裝好瀏覽器後，以後系統任何更動均與個人電腦無關 |
|
系統維護 |
Server 面對不同平台的Client 必須需有不同的專業工程師維護 |
只需維護一套系統 |
|
升級與版本更新 |
系統升級時需同時更新用戶端及主機端軟體且必須考慮系統相容性的問題 |
系統升級只需異動主機端軟體，不需更新用戶端且無軟體相容性問題 |
|
系統展現格式 |
可顯示文字、圖形、動畫、聲音、影像。但為達到多媒體功能，軟體開發需投注大量人力於聲音影像的專業領域 |
可顯示文字、圖形、動畫、聲音、影像。所以檔案解譯功能均由 Web Browser處理，開發人員不需花時間於與應用系統無直接關係的聲音影像等專業領域 |
|
系統整合能力 |
不同的 Client-Server 架構採用不同的分工策略與溝通方式，前台使用介面開發工具的差異及與資料庫連結方式的不同協定將造成整合的困難 |
前台的使用者介面為統一的瀏覽器(Browser)，整合時不需耗費其他人力；Web Server 與 DB Server 間的連結為一般網路協定，為共通標準，亦不造成困難 |
※參考資料：江惠宇，1997
※比較傳統系統開發環境和 Web 式系統開發環境的差異與優缺點
106關薦
(一)傳統與網路為基礎的軟體開發策略
1.身為系統分析師，必須考慮系統要在以 Web 為核心的架構下，或是在傳統的環境中開發。
2.在以 Internet 為基礎的系統中，網頁會成為應用系統的一部分，而不只是一個通訊頻道。系統分析師需要新的開發工具與解決方案，才能處理新的系統。例如已經學過兩個以 Web 為基礎的開發環境，分別是 IBM 的 WebSphere 和Microsoft 的 .NET。
3.雖然網路式系統是主要的趨勢，但許多公司還是仰仗傳統的系統，可能的原因之一是舊有系統不容易被取代；也可能是不需要網路元件，來滿足他們的需求。
4.與傳統環境比較起來，在網路式環境中組建應用系統，可能會提供比較大的效益，有時候也會產生比較高的風險。
※參考資料：第6章 開發策略(網頁版).ppt
(二)傳統系統開發環境
1.系統設計受到相容性課題的影響，包括現有的硬體及軟體平台和舊有系統需求的影響。
2.系統被設計在區域或廣域的公司網路上執行。
3.系統經常利用 Internet 連結和資源，但是網頁功能被視為功能的補強而不是設計的核心要素。
4.開發過程通常依循三種主要路徑之中的一種：
公司內自行開發、購買套裝軟體必要時做一些修改，或利用外部的顧問。
5.擴充能力 (指系統能夠處理未來業務量及交易量的能力) 會受到通訊及網路限制的影響。
6.許多應用系統需要相當的桌上型電腦運算能力及資源。
7.安全問題通常比網路 (web) 為基礎的系統單純。
※參考資料：第6章 開發策略(網頁版).ppt
(三)Web式系統開發環境
1.系統是在一個以 Internet 為基礎的架構之下開發並交付，例如 .NET 或 WebSphere。
2.這種開發方式視網站為平台，而不只是通訊頻道。
3.以 Web 為基礎的系統規模可輕易擴充，並且可以在不同的硬體環境下執行。
4.大型公司傾向部署以網路 (web) 為基礎的系統，作為全體企業的軟體解決方案，例如顧客關係管理、訂單處理、以及原物料管理。
5.以Web為基礎的軟體視應用軟體為較不依賴於桌上型電腦運算能力及資源的一種服務。
6.當公司以服務而非產品的方式取得以 Web 為基礎的軟體時，他們能將內部自行開發的工作降到最低，而藉由支付約定的費用，讓廠商負責安裝、調整、並維護該系統。
7.以 Web 為基礎的軟體通常需要增加一個通訊層，稱為中介軟體 (middleware #)，以便與現有的軟體及舊有系統溝通。
※參考資料：第6章 開發策略(網頁版).ppt
※分散式處理系統和集中式處理系統的比較：
98關簡
(一)分散式處理系統
1.定義：
分散式系統中的各個處理器之間並不共享記憶體或時脈 (clock)，每個處理器都有其各自的記憶體，處理器要交換訊息，是藉由通訊線路來完成的。例如自動櫃員機、鐵路售票系統。
2.優點：
(1)資料平行處理速度快，效率佳。
(2)減少主機的負荷，也比較不容易因為使用者增加而效率變慢。
(3)達到資訊分享的目的，並且減少溝通成本，所以適合分權式組織型態。
(4)整合各種資料庫及異質電腦系統 (即不同廠牌、不同硬體)。
3.缺點：資料分散在不同地方，容易造成資料不一致的現象。
(二)集中式處理系統
1.定義：
資料庫系統與應用程式同時集中於同一台主機上執行，並且以此主機擔任所有資料的「計算處理」與「使用者介面處理」。例如沒有網路的環境或只有一台主機。
2.優點：
(1)安全性高：資料保密性高。
(2)容易操作：運作模式比較單純。
(3)容易管理：可以完全控制電腦上的所有資源。
(4)完整性與一致性：可以確保資料完整性與一致性。
3.缺點：
(1)資料庫系統不易與組織一起成長 (亦即中大型公司無法適用)。
(2)當使用者人數增加時，主機無法負荷，導致效能降低。
98年關務人員升官等簡任系統分析研究
|
四、在資訊系統的架構中，有分散式處理系統 (Distributed System) 和集中式處理系統 (Centralized System)，請舉例說明之；並說明其優缺點。（25分） |
答：
略
103年高考三級系統專案管理
|
三、請說明三層式主從架構 (Three-Tiered Client/Server)，並分析三層式主從架構的可能設計方式。（15分） |
答：
略
※雲端運算與網格運算的比較：
|
|
雲端運算 |
網格運算 |
|
原理 |
1.源自平行運算的技術，不脫離網格運算的概念，但是雲端運算更專注在資料的處理 2.將一個電腦運算工作 (Task) 分成許多程序 (Process)，透過分佈於網際網路中的伺服器群組 (雲端主機) 處理分析後，再將結果傳回給使用者端 |
1.通過利用大量異質電腦 (通常為桌面Desktop) 的未用資源 (CPU 資源和磁碟儲存空間)，將其變成一個虛擬的計算機叢集，為解決大規模的計算問題提供了一個架構 2.焦點放在支持跨網域運算的能力，運用平行運算，著重企業之間或跨企業的資源充分運用，共同解決困難的運算任務 |
|
彼此關係 |
可以算是網格技術的一個子集合 |
涵蓋雲端技術，能處理更複雜的問題 |
|
實作方式 |
組合大量的 x86 個人電腦提供服務 |
組合大量的異質電腦提供複雜運算 |
|
供應者 |
Google、Yahoo |
學術機構 |
|
任務 |
比較偏大眾應用，適合執行單次資料處理量較小的任務 |
重點放在需要複雜運算的「單一任務」，例如基因定序、核爆模擬等 |
|
使用技術 |
虛擬化技術 |
專屬的通訊協定和資料格式 |
|
標準化 |
無，各家採用的技術架構不同 |
有標準化的協定和信任機制 |
|
硬體規格 |
使用大量規格相同的 x86 個人電腦等級伺服器，來執行雲端運算的程式，所以不需要處理異質性的問題，可以簡化平行運算的系統架構，更容易協調伺服器之間的資訊傳遞，讓分散式處理的整體效能更好 |
要讓任何伺服器 (異質性機器) 都能加入到一個運算網格中，以提供龐大的運算量，必須解決不同伺服器、作業系統、甚至是程式編譯器版本差異等問題 |
|
開放原始碼 |
部份 Open Source，例如 Hadoop 架構 |
Open Source |
|
網域限制 |
企業內部網域 |
跨企業網域 |
※參考資料：
1.http://evan52041.blogspot.tw/2011/03/vs.html
2.http://www.runpc.com.tw/content/cloud_content.aspx?id=105867
3.http://sls.weco.net/blog/bryan0314/14-jan-2009/12497
※良好的雲端運算架構方式，必須具備以下三項特點：
1.彈性擴充：
當運算規模增加，雲端要可以彈性變大，只要加上新的節點就可以了。
2.負載平衡：
讓伺服器之間的負載盡量平衡，免得某些伺服器太過繁忙，某些卻太過閒置。
3.資料安全：資料重複 (redundancy) 存放在不同位置，確保資料安全。
※參考資料：http://www.nhu.edu.tw/~society/e-j/86/13.htm
※企業使用雲端運算的優點：
1.經過驗證的網路服務整合。
2.世界級的服務傳遞。
3.不需安裝任何硬體和軟體。
4.部署時速度更快，風險更低。
5.適合應用程式開發，支援深入自訂項目。
6.加強商業使用者的能力。
7.自動升級不影響 IT 資源。
※參考資料：http://www.nhu.edu.tw/~society/e-j/86/13.htm
102年法務部調查局調查人員三等系統分析與設計
|
一、請列出雲端運算 (Cloud Computing) 的三種服務提供模式。（6分）政府機構資訊部門若計劃導入雲端運算以更進一步提升現有資訊系統之服務效能，請依據此三種服務提供模式，說明導入此三種模式時的評估分析重點。（24分） |
答：
(一)
雲端運算三種不同的支援層級：雲端運算三種服務型式(SaaS、PaaS、IaaS)
|
使用者 |
層級 |
主要供應商與產品 |
|
|
一般使用者 |
客戶端(Client) |
Browser |
PC、Notebook、Netbook、Smartphone |
|
一般使用者 |
軟體即服務(SaaS Model) |
GoogleApps、Microsoft Online、SalesForce.com、RSS |
|
|
系統開發者 |
平台即服務(PaaS Model) |
Microsoft Azure Service Platform、Google App Engine、Amazon Web Service |
|
|
系統管理者 |
基礎設施即服務(IaaS Model) |
Amazon EC2、Amazon S3 |
|
1.客戶端(Client)：只要有 Browser 便可隨時隨地的上網取得雲端運算服務。
2.軟體即服務(Software as a Service, SaaS)：
使用者可透過 Internet 取得自己所需要的應用軟體。例如 Salesforce.com、Google APP (Gmail、GoogleDoc、GoogleTalk、Calender)。
3.平台即服務(Platform as a Service, PaaS)：線上作業系統
使用者可以在平台上方便的開發、安裝、組合與執行各種應用資訊系統。例如 Amazon 的 Amazon Web Service (AWS)。
4.基礎設施即服務(Infrastructure as a Service, IaaS)：線上商務旅館
提供者在線上提供各種的伺服器、資料儲存設備、CPU運算能力、網路連線設備等，讓沒有能力採購與管理這些設備的使用者可以「用多付少的方式」來使用。例如 Amazon EC2 (Elastic Computer Cloud) 與 Amazon 的 S3 (Simple Storage Service)。
(二)
1.建置私有雲是否真的會比較安全？
許多企業考量到公有雲採用的是多租戶的資源分享方式，擔心自己的資料會因此遭受不當使用或外洩，所以只考慮完全採取私有雲的方式，在企業內部建立起專屬的雲端服務。基本上，所有資料完全由企業自行監督管理，存放在自己的伺服器上，的確比外包的服務讓人值得信任，而且在事件處理回應上面，內部的速度也可能會比外包服務來得快很多。但是，請千萬不要忽略了，即使所有資訊躲在企業的防火牆之後，許多的雲端問題包括像是應用程式安全、作業系統安全、硬體設施管理維護、服務可用性等，也都在考驗既有的 IT 團隊是否擁有足夠的能力，因應眾多使用者不同的安全需求。
2.是否具有安全可見度與風險意識？
對公有雲服務來說，為了讓企業能夠清楚掌握所使用的服務內容與耗費成本，提供清楚可見的報表服務是必要的一環，但除了透過報表來了解計價費用之外，企業是否也能夠清楚掌握所選用的雲端服務安全風險呢？目前，許多雲端服務供應商也提供了API，讓使用者可以自行設計配置和利用更多的擴充功能，尤其是在存取行為記錄和系統監控方面，企業需要評估是否有能力管控可能面對的資安風險。
3.敏感性資料是否能夠安全地儲存？
在雲端服務中，如何確保敏感性資料的安全，是個讓人頭痛的問題，雖然資料加密可以有效強化資料的機密性，但大多數企業的問題在於需要了解有哪些資料必須加密？應該如何進行加密？在選擇雲端服務供應商時，了解業者採取何種加密方式也是一開始要評估的重要項目，如果使用的是共同的金鑰，並且還將資料和金鑰存放在一起，那麼這種安全機制就顯得過於簡單而且具有潛在風險。另外，即使在虛擬化的環境之中，如果惡意程式已有能力監控虛擬主機，那麼也就同樣有能力可以取得存放其中的金鑰，進而危害到儲存的資料安全。如果可能的話，與其完全採用雲端服務供應商的加密機制，企業採用自行加密的方式並妥善保管金鑰，再將資料存放至公有雲的服務之中，相對而言會是比較好的作法。
4.應用程式是否可能存在安全漏洞？
如果企業要將舊有的應用程式轉移部署到雲端之中，若是本身含有安全漏洞，到了雲端之後可能會更容易受到利用，而且將面臨更多新式的攻擊。
5.是否具有強健的身分驗證與授權？
對雲端服務而言，企業需要考量的是這些服務到了雲端之後，其安全強度是否仍然足夠，如果不足的話，就需要加入更多的安全控制，像是採取雙因素驗證、BYOD 考量等。
※參考資料：
http://www.informationsecurity.com.tw/article/article_detail.aspx?aid=7778
106年鐵路特考高員三級資訊系統與分析
|
三、貴機關目前正準備導入系統，有人建議是否應該採用市面上軟體即服務(Software as a Service，SaaS) 的系統： (一)請問軟體即服務 (SaaS) 是什麼意思？（10分） (二)請問軟體即服務 (SaaS) 與雲端化的關係並分析機關為什麼會偏好使用 SaaS 模式？（10分） |
答：
(一)軟體即服務
1.使用者可透過 Internet 取得自己所需要的應用軟體，企業在不需要安裝任何軟硬體的情況下，就可以連線使用並且透過瀏覽器進行資料存取。
2.軟體的環境設定與後續產出的資料，都會存放在服務提供者端，而不是使用者端 (有資料安全問題)。使用者除了必須負擔每個月的授權費以外，其他包括軟體開發、維護以及伺服器等硬體設備的成本，都是由 SaaS 應用服務提供者來承擔。
3.例如 Salesforce.com、Google APP (Gmail、GoogleDoc、GoogleTalk、Calender[日曆])、中華電信的 CRM 客戶關係管理 (透過月租方式使用 CRM 的銷售、行銷、服務三大完整模組功能)。
※參考資料：
1.http://www.ithome.com.tw/node/38211
2.https://zh.wikipedia.org/wiki/%E8%BD%AF%E4%BB%B6%E5%8D%B3%E6%9C%8D%E5%8A%A1
3.http://www.ithome.com.tw/node/79862
4.http://hicloudmall.hinet.net/app_mart/controller?action=amp_product&Apps_PK=100155
(二)請問軟體即服務與雲端化的關係並分析機關為什麼會偏好使用SaaS模式？
1.軟體即服務與雲端化的關係：
雲端集中式代管軟體及其相關的資料，軟體僅需透過網際網路，而不須透過安裝即可使用。用戶通常使用網頁瀏覽器來存取軟體即服務。
※參考資料：
https://zh.wikipedia.org/wiki/%E8%BD%AF%E4%BB%B6%E5%8D%B3%E6%9C%8D%E5%8A%A1
2.機關為什麼會偏好使用SaaS模式？
(1)開發成本低：
如果採用 SaaS 解決方案，其成本很有可能只有自行實施、部署、運行、管理及支持這類解決方案所需成本的一小部分。
(2)專注於自身領域：
選擇 SaaS 能使部署非常快捷，節省搭建基礎環節的費用，並且能夠處理好一般的業務流程，企業就可以專注於自身領域，從而創造真正的差異優勢。
(3)重複使用：
在價格方面可以提供非常顯著的規模經濟，因為大多數SaaS提供商可以非常輕鬆地利用其在特定行業領域「重複使用」。
(4)彈性定價：靈活的定價模式，符合企業的發展模式。
※參考資料：https://read01.com/4A0yAG.html
※MVC模式(Model-View-Controller)：
[MVC(Model-View-Controller)] 2 | 102,104
102調三、104關簡
(一)定義
1.是軟體工程中的一種軟體架構模式，把軟體系統分為模型 (Model)、檢視 (View) 和控制器 (Controller) 三個基本部分。
2.目的是實作一種動態的程式設計，使後續對程式的修改和擴充功能簡化，並且可能使程式某一部分重複利用。
(二)架構
<圖15>pic15
1.模型(Model)：
(1)由應用程式資料、商業邏輯、程式功能組成。
(2)主要負責應用程式中的商業邏輯 (Business Logic)，它用來描述應用程式功能性的演算法以及資料庫與使用者介面之間資料的交換。
(3)封裝了應用程式中對資料的存取並提供可重複使用的函式庫，例如資料庫存取的抽象化、郵件的遞送、資料的驗證與稽核。
(4)當 Model 狀態改變時，會通知 View。
(5)回應 View 對 Model 的狀態詢問。
(6)回應 Controller 對 Model 的狀態改變 (更新模型)。
2.檢視(View)：
(1)是使用者存取 Model 的窗口。
(2)可以使用 HTML/CSS/Javascript 技術蒐集與使用者互動資料的網頁。
(3)從 Model 狀態詢問後得到資料，並且以圖型或表格方式輸出資料。
(4)當使用者對 View 做出一些事時，則告訴 Controller 做了什麼，並且由它負責處理。
3.控制器(Controller)：
(1)蒐集使用者對 View 所輸入的資料，並且決定由哪支程式進行資料處理。
(2)接收 Model 所回傳的資料，並且在解析後傳遞給 View 作呈現。
(3)所有程式的例外處理以及流程控制。
(4)可以送出命令要求 Model 改變狀態 (更新模型)。
(5)可以送出命令要求 View 改變呈現方式。
(三)優點
1.多個View能共享一個Model：
(1)同一個 Web 應用程式會提供多種使用者介面，例如使用者希望能夠通過瀏覽器來收發電子信件，還希望通過手機來存取電子信箱，這樣就要求 Web 網站同時能提供 Internet 介面和 WAP 介面。
(2)在 MVC 設計模式中，Model 接受使用者查詢並回應其所需資料，View 負責格式化資料並把它們呈現給使用者，業務邏輯和表示層分離，同一個 Model 可以被不同的 View 重用，所以大大提高了代碼的可重用性。
2.三個模組相互獨立：
(1)Controller 是高度獨立內聚的物件，與 Model 和 View 保持相對獨立，所以可以方便的改變應用程式的資料層和業務規則。
(2)例如把資料庫從 MySQL移植到 Oracle，或者把 RDBMS資料來源改變成 LDAP資料來源，只需改變 Model 即可。
(3)一旦正確地實作了控制器，不管資料來自資料庫還是 LDAP 伺服器，View 都會正確地顯示它們。
(4)由於 MVC 模式的三個模組相互獨立，改變其中一個不會影響其他兩個，所以依據這種設計思想能構造良好的少互擾性的構件。
3.提高了應用程式的靈活性和可配置性：
可以根據使用者的需求選擇適當的 Model 進行處理，然後選擇適當的 View 將處理結果顯示給使用者。
4.低耦合性及高內聚性：
通過 MVC 的框架將一個系統分成表現層、業務邏輯層、資料訪問層，比如只需要改變視圖層而不需要重新編譯模型和控制器代碼，同時一個應用的業務流程或者業務規則的改變只需要改變模型層而不需要去修改檢視層和控制器層的程式碼。
5.高重用性：
可以通過不同的 View 訪問到模型的資料，只需要在控制器層對資料格式做處理，而不需要修改模型層的程式碼。
6.可維護性：分離出業務層、檢視層、資料層，使得代碼更容易維護
7.項目工程化管理：由於不同的層各司其職，有利於工程化、工具化管理程式碼。
(四)缺點
1.內部原理複雜：
由於它沒有明確的定義，所以完全理解 MVC 模式並不是很容易。需要精心的計劃，由於內部原理比較複雜，所以需要花費一些時間去思考。
2.偵錯困難：
(1)開發一個 MVC 模式架構的工程，將不得不花費相當可觀的時間去考慮如何將 MVC 模式運用到應用程式中，同時由於 Model 和 View 要嚴格的分離，這樣也給偵錯應用程式帶來了一定的困難。
(2)每個構件在使用之前都需要經過徹底的測試。
(3)將一個應用程式分成了三個部份，意味著同一個工程將包含比以前更多的檔案。
3.設計MVC框架增加額外的工作量：
過去 MVC 模式並不適合小型甚至中等規模的應用程式，這樣會帶來額外的工作量，增加應用的複雜性。但現在多數軟體設計框架，能直接快速提供 MVC 骨架，供中小型應用程式開發，此問題不再存在。
4.執行速度慢：
由於 MVC 架構多半需要載入不少函式、定義，因此即使只是顯示一句 “Hello World” 都需要讀取多個檔案才能完成。
5.降低了系統的性能：
由於 View 不能直接訪問資料庫，需要控制器這個中間層，所產生的性能問題是不言而喻的。
6.有可能出現串聯層級的修改：
因為這種修改是自上而下的，有可能某塊業務只需要新增一個 View，而這個新增就會因為 MVC 模式的限制而去增加業務邏輯層和資料訪問層的代碼。
※參考資料：
1.http://zh.wikipedia.org/wiki/MVC#.E4.BC.98.E7.82.B9
2.http://lliweerffreewill.blogspot.tw/2009/02/mvc.html
3.http://blog.xuite.net/kamory0931/fightdreamer/47210402-MVC+%E6%A8%A1%E5%BC%8F(%E9%9A%A8%E8%A8%98)
4.http://projectmanagementdud.blogspot.tw/2013/03/model-view-controller-mvc-simply.html
5.http://blog.waws.idv.tw/?p=57
6.https://www.douban.com/note/582379437/
留言列表
國考資訊處理解答 (7)
