國考資訊處理工作室(高考二級資訊處理/高考三級資訊處理/調查局三等/關務人員三等/地方特考三等)

第一章 系統分析與設計簡介

1-1 資訊系統(Information System)

一、資訊系統簡介

[資訊系統] 16 | 85,86,88,92(2),93(2),94(2),95,96,97(2),108,109,110

85地三、86高三、88高三、92調三、92檢三、93退三、93電員晉高、94警三、94專檢、95身三、96關簡、97高二、97地三、108關薦/108郵員晉高、109身三、110關薦技

(一)定義

是指可以記載、保存各種活動的資料，然後加以整理、分析、計算，產生有意義、有價值的資訊。這類資訊可以供決策者制定決策與行動時參考。

(二)組成元件

1.硬體(Hardware)：

  資訊系統的實體層面，例如伺服器、工作站、網路、通訊設備、光纖纜線等。

2.軟體(Software)：

(1)系統軟體：例如作業系統、程式語言等。

(2)應用軟體：例如文書處理、試算表、資料庫。

3.資料(Data)：

(1)內部資料：例如交易資料、銷售資料、出貨資料、存貨資料。

(2)外部資料：例如產業資料、商業夥伴提供資料、政府官方資料。

4.程序(Processes)：

(1)指導方針：

處理挑戰的指南。選定一個整體解決方案，處理或克服診斷所發現的障礙。

(2)過程：事物連續變化或進行間所經過的歷程。

(3)步驟：事情進行的程序。

5.人員(Staff)：內部使用者、外部使用者

(1)終端使用者(End user)：組織內部的系統使用者

a.是問題領域的專家，但可能不是資訊科技方面的專家。

b.在系統分析與設計過程，扮演提供使用者需求與企業知識的角色。

c.幫助開發人員將需求與企業知識轉換成電腦系統。

(2)系統分析師(System analyst)：

使用者需求分析，進一步的分析與設計出滿足使用者需求的藍圖，也就是塑模 (Modeling) 的工作。

(3)程式設計師(Programmer)：

依照分析與設計的藍圖，撰寫電腦程式、建立資料庫、測試與安裝系統等。

(4)資料庫管理者(Database Administrator, DBA)：

a.與使用者聯繫：定義外部層次，以及概念層與外部層的對應。

b.定義資料庫概念層次：資料庫設計。

c.定義內部層次：實體資料庫設計。

d.定義安全性與整合性限制：透過概念層定義語言。

e.錯誤管理：資料庫的備份 (backup)、復原 (recovery)。

f.效能監測以及需求變更。

※參考資料：

http://zh.wikipedia.org/wiki/%E6%95%B0%E6%8D%AE%E5%BA%93%E7%AE%A1%E7%90%86%E5%91%98

(5)系統管理者(System managemer)：管理帳戶及帳戶安全的使用者。

※參考資料：

http://mslab.csie.asia.edu.tw/~jackjow/courses/1001_MIS/ppt/01_Introduction.pdf

6.使用者介面(User Interface)：

(1)是介於使用者與硬體而設計彼此之間互動溝通相關軟硬體。

(2)目的在於讓使用者能夠方便有效率地去操作硬體以達成雙向的互動，藉助硬體來完成所需工作。

※參考資料：

https://zh.wikipedia.org/wiki/%E7%94%A8%E6%88%B7%E7%95%8C%E9%9D%A2

(三)資訊系統架構

[資訊系統架構] 5 | 98,103,106,107,110

98關簡、103高三、106外四、107鐵高、110關薦技

1.集中式架構(Centralized Architecture)：

(1)定義：

a.以集中式的大型主機 (mainframe) 來儲存一個資訊系統所有的資料、程式和介面元件供多人使用。

b.使用者透過終端機 (或以 PC 來模擬終端機) 與系統互動。

c.所有真正的處理和工作都在主機上完成。

(2)優點：

   a.系統管理單純，因為所有的資源均由主機作業系統分配與管理。

b.屬於封閉式作業系統，這種作業系統再與其他系統的連接上雖然有極大的問題，但是在資料安全上卻比較容易控制。

(3)缺點：

   a.主機工作負擔較重。

b.主機更替成本高。

c.維護成本重。

d.只能處理文字模式的介面，無法支援圖形使用者介面 (GUI)。

e.缺乏彈性的環境。

(4)使用時機：需要安全性較高的系統，或者小系統可以採用此架構。

  ※參考資料：

http://www.tsnien.idv.tw/DataBase_WebBook/chap2/2-6%20%E8%B3%87%E6%96%99%E5%BA%AB%E7%B3%BB%E7%B5%B1%E6%9E%B6%E6%A7%8B.html

2.檔案伺服器架構(File Server Architecture)：

(1)定義：

a.在區域網路中，由檔案伺服器 (File Server) 負責需求排班與管理、傳送與保存資料。

b.當客戶端 (Client) 向伺服端提出需求時，伺服端會將相關的檔案完整的傳送至客戶端進行處理，然後在客戶端處理資料的運算，等完成之後再將檔案傳回檔案伺服器儲存。

(2)優點：

a.用戶端處理資料可以降低檔案伺服器處理資料的負擔。

b.可以使用圖形使用者介面 (GUI)。

(3)缺點：

a.由於每次伺服器都是傳送資料所在的完整的檔案至客戶端，因此，過大的資料流量易造成系統的瓶頸。

b.所有計算都在用戶端完成，其個人電腦最好都有不錯的運算能力 (所謂的複雜型用戶端)。

c.必須處理複雜的資料鎖定 (data lock) 問題，資料庫整合性必須妥協。

(4)使用時機：與網路上的其他使用者共用檔案

  想要為團隊資料夾分配容量與設定權限，以更好管理各部門的儲存空間使用量，並且可以加密分享連結與設定連結過期日。

  ※參考資料：https://www.synology.com/zh-tw/dsm/solution/business_file_server

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)使用時機：想要將部份工作移到使用者電腦上，分攤主機電腦的負荷。

(6)2-Tier與3-Tier的比較：

※參考資料：

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

7.http://www.tsnien.idv.tw/DataBase_WebBook/chap2/2-6%20%E8%B3%87%E6%96%99%E5%BA%AB%E7%B3%BB%E7%B5%B1%E6%9E%B6%E6%A7%8B.html#2-6-2

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)。

(4)使用時機：

  適合跨國公司或是常出差的人員處理業務，任何作業系統只要能打開瀏覽器的都可以使用。

※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.利於標準化。

2.降低層與層之間的依賴。

3.利於各層邏輯的重用。

4.開發人員可以只要關注整個結構中的其中某一層。

5.具有良好的開放性和可擴充性，方便維護和升級。

6.提高系統的安全性。

(四)缺點

1.有時會導致連動的修改：

  如果在展示層中需要增加一個功能，為保證其設計符合分層式結構，可能需要在相應的商業邏輯層和資料存取層中都增加相應的程式碼。

2.相對於不分層，降低了系統的性能：

  如果不採用分層式結構，很多業務可以直接存取資料庫以獲取資料，如今卻必須通過中間層來完成。

3.增加了開發成本。

(五)使用時機

解決整個應用程式中，各個操作過程中不同階段的程式碼封裝的問題，使程式設計師更加專注的處理某階段的商業邏輯。

※參考資料：

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

4.https://shunnien.github.io/2017/07/29/3-tier-and-mvc-introduction/

※三層式主從架構的可能設計方式：三層式分遠遠分分分

103高三

1.分散式展示(Distributed Presentation)：

2.遠端展示(Remote Presentation)：

3.遠端資料管理(Remote Data Management)：

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.在有限的頻寬如何達到最佳的系統執行效率？

(五)使用時機

想要重用的應用程序的模型。

※參考資料：

1.35603805.pdf

2.https://github.com/MicrosoftDocs/visualstudio-docs.zh-tw/blob/live/docs/data-tools/walkthrough-creating-an-n-tier-data-application.md

※分散式架構(網路/計算)：

※端末-主機(Terminal-Host)：

107鐵高

(一)定義

1.是早期存取資料庫的主要模式，是由一部大型主機負責儲存及處理龐大的資料，使用者則透過終端機與大型主機連線，以存取資料庫的內容。

2.終端機不提供運算處理功能。

3.當終端機的要求增多時，主機端的整體效能就會隨之降低。

※參考資料：

1.ACI009700.pdf

2.http://homepage.ntu.edu.tw/~huangsl/access/1-1-access2003.pdf

3.https://zh.wikipedia.org/wiki/%E7%B5%82%E7%AB%AF

(二)架構

所有資料處理的負荷均在主機端，當終端機的要求增多時，主機端的整體效能就會隨之降低。

※參考資料：ACI009700.pdf

※Client-Server架構與Terminal-Host架構的比較：

※傳統Client-Server架構與Web-Based架構的比較：

※參考資料：江惠宇，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)當使用者人數增加時，主機無法負荷，導致效能降低。

※SOLID原則：系統架構的重要原則

109技高

(一)單一職責原則(Single-responsibility principle, SRP)：

1.定義：

  (1)每個物件，不管是類別、函數，負責的功能都應該只做一件事。

  (2)如果在一個函數內，同時做了兩件以上的事情，當發生錯誤時，就很難快速找出錯誤的原因，也容易間接導至程式碼的可閱讀性降低。

2.舉例：

  如果在訂單管理的類別中有一個新增訂單的方法，在收到訂單之後，會依序處理訂單、取出會員的聯絡資訊，然後再依靠聯絡資訊寄送通知信件給會員。說明如下：

  上述的函式參雜了一堆不相干的邏輯，可能動輒數百行，每一段都處理各種不同的工作，一看就很明顯違反單一職責原則。當訂單處理的商業邏輯、查詢會員資料的邏輯或是通知會員的方式有變更的時候，這個函式都會受到影響，也就是說這個函式同時對多個不同對象負責。這樣的類別或函式就是不穩定的。

(二)開放封閉原則(Open-closed principle, OCP)：

1.當需求有異動時，要如何在不變動現在正常運行的程式碼，可以藉由繼承、相依性注入等方式，增加新的程式碼，以實作新的需求。

2.如果為了新需求，去修改了原本的程式中的某一個函數，可能會造成其他呼叫使用該函數的的功能，出現非預期的錯誤。

(三)里氏替換原則(Liskov substitution principle, LSP)：

當實作繼承了介面 (interface) 或基底類別 (base class) 的子類別，在程式中，只要出現該介面或基底類別的部份，都可以用子類別替換。

(四)介面隔離原則(Interface segregation principle, ISP)：

針對不同需求的用戶，開放其對應需求的介面。可以避免不相關的需求介面異動，造成被強迫一同面對異動的情況。

(五)依賴反向原則(Dependency inversion principle, DIP)：

1.定義：

  當 A 模組在內部使用 B 模組的情況下，稱 A 為高階模組，B 為低階模組。高階模組不應該依賴於低階模組，兩者都應該依賴抽象介面。

2.舉例：

  正常的程式可能會有很多高層模組依賴於底層模組。說明如下：

  在某個 function 或是某個 class 底下直接使用其它的 class。這樣變得非常高耦合，如果把 Mysql 改成 monogoDB，那麼整段程式碼就是直接換掉重寫了，完全違反了 OCP。可以改寫如下：

  可以看到在 Controller 類別只依賴抽象介面 (interface Database)，而 Mysql 類別也同樣依賴相同的抽象介面。就算換成 MonogoDB，只要一樣用 MonogoDB 類別依賴 Database 介面，那麼 Controller 類別就可以不用改寫。

98年關務人員升官等簡任系統分析研究

答：

略

103年高考三級系統專案管理

答：

略

※雲端運算與網格運算的比較：

※參考資料：

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