软体处理程序与需求分析

軟體處理程序與需求分析

2-1導論Presenter:Away.什麼是軟體?電腦程式及相關文件，如要求，設計模型和使用手冊可以是為某位客戶或一般大眾市場所開發的軟體產品廣義而言：電腦軟體是指一切能夠控制電腦運作的方法與技術狹義而言：用各種程式語言所寫成的程式.什麼是軟體工程?軟體工程是一門著重在生產軟體各方面知識的工程學科。軟體工程簡單的說就是有系統的進行軟體的規劃、分析、設計、程式製作、維護等工作，其目的是運用科學化的方法和技術，

來提高軟體的生產力和軟體的品質。軟體工程所涵括的範圍很廣，主要包括兩方面內容：軟體發展技術和軟體專案管理。

.好的軟體應有那些特性?這些軟體應該提供所需的功能外，而且也應提供使用者可維護性、可靠性和可接受性Maintainability（可維護性）軟體必須演變，以滿足不斷變化的需求;Dependability（可靠性）軟體必須是值得信賴的;Efficiency（效率）軟體不應該浪費系統資源;Usability（可用性）軟體必須設計讓使用者接受.這表示它需是可以理解、實用且與其他系統能相容.軟體工程主要面對的挑戰是什麼?Heterogeneity,deliveryandtrust.Heterogeneity(異質性的挑戰)該使用何種開發技術來建立值得信賴、且可處理一致問題的軟體;Delivery（開發時間的挑戰）如何能夠在不降低系統品質的條件下，縮短開發時間;Trust（信任度的挑戰）如何開發出能讓軟體展示出他值得使用者信任的技術..專業和道德責任PUBLIC軟體工程師應該維護大眾的利益CLIENTANDEMPLOYER軟體工程師應該以讓他的客戶和雇主得到最佳利益為職責，並且維護大眾利益PRODUCT軟體工程師應該確保他的產品和相關的修改能夠儘可能符合最高的專業標準.專業和道德責任JUDGMENT軟體工程師在專業判斷上應該維持正直與中立MANAGEMENT軟體工程師的經理人和主觀應該軟體開發與維護上支持與提倡合乎道德的管理方法PROFESSION軟體工程師應該提昇.何謂軟體工程方法軟體工程方法是開發軟體的一些結構方法，他們的目的是要以合乎成本效益的方式生產出高品質的軟體產品。在1970年代就已經發表了結構式分析與ＪＳＤ等方法，這些方法主要是找出系統的基本功能元件。1980-1990年代，這些功能導向的方法又增加了一些物件導向的功能。現在這些方法已經整合成一個統一個方法，稱為UML（UnifiedModelingLanguage）目前為止，軟體工程方法還在發展中，還沒有一個完全理想的方法出現，而且不同方法有各有不同的適合領域。.軟體開發、塑模與溝通在軟體發展的過程中，因為參與開發過程的成員

眾多，所以，有效的溝通非常重要。舉例來說：客戶與承包商需要反覆溝通，以取得用戶需求廠商與廠商之間需要有效溝通，以達成相互合作而開發團隊內部更必須確保溝通，以保證發展方向

正確等等因此軟體開發能夠順利進行，有效且良好的溝通，是不可或缺的要素。.軟體開發、塑模與溝通但軟體發展與其他的文明建設不同，軟體開發通常不像建築物，具有明確的外觀形貌，也沒有所謂建築藍圖或建築模型以供參考。在大部分狀況下，軟體發展的基本參考，通常只是用戶需求裡的條列式文句。而相同的文句，每個開發人員可能會做出不同的解釋，更因沒有實體或模型可供參考的狀況下，開發軟體很容易造成『瞎子摸象』的後果，不但需要花更多的時間進行溝通，同時也無法保證軟體產出的品質。.軟體開發、塑模與溝通因此，依循其他傳統的文明建設發展軌跡，如建築藍圖或結構模型等成功經驗，軟體工程也朝向此一『建立可討論的模型』目標前進。有可見的藍圖，總比以文字表示的條文容易理解。更進一步，如果有可見的模型，不僅對整體架構有更明確的概念，同時也可確保開發團隊中的每個成員，都有相同且明確的目標，因此可以事半倍，避免無謂虛耗的困擾。因此，在軟體工程中，塑模的重要性不言可喻.物件導向技術具有封裝、繼承和多型特性的物件導向技術，提供系統發展人員在不增加複雜度的情況下擴大系統的方法，最適合用來發展強調再用的軟體系統。.物件導向技術在應用方面具有的特色一、

可經由直接塑模企業物件，讓資訊系統與企業管理完全整合。二、

讓應用系統不受限於執行環境、開發環境、程式語言而能彼此互通。三、

讓發展者可以很容易的再用或修改物件。.軟體生命週期將軟體開發程序加以細分就是所謂的生命週期模型RequirementsEngineeringDesignImplementationTestingMaintenance.軟體開發或演進的一系列活動SoftwarelifecycleDevelopmentcycleDesignImplementationTestingMaintenanceRequirementsElicitationSystemdesignObjectdesignAnalysisRequirementsEngineering.RequirementsEngineeringRequirementselicitationfocusesondescribingthepurposeofthesystem. (Requirementselicitation重點集中於描述系統目的)Requirementsengineering包含RequirementsElicitation與Analysis兩階段。.Design一但知道系統需要達成哪些需求後,設計過程中就必須決定什麼是可以完成需求的最佳系統建構方式在Softwarelifecycle中Design包含SystemDesign與ObjectDesign兩階段。在SystemDesign階段初期，必須先定義出DesignGoal作為SystemDesign完成後系統所需達成的事項。.Implementation將完整的設計轉成程式碼.Testing系統經過測試後,可以確保系統是否可以精確且完整滿足使用者的需求..Maintenance軟體完成之後的維護與改良.什麼是UML？UML是UnifiedModelingLanguage的簡稱，中譯為「統一塑模語言」。屬於物件導向領域裡頭用來將設計概念表現出來的一種符號表現法也就是說，UML是軟體系統發展人員用以建造模型，而這些模型使得工作團隊能夠：將系統具象化(Visualization)、將系統結構及行為規格化(Specification)、建構(Construction)系統、以及記錄(Documentation)發展系統過程中之各項決策。.UML(UnifiedModelingLanguage)什麼是塑模？

作曲家會將其腦袋中的旋律譜成樂曲，建築師會將其設計之建築物畫成藍圖，行銷廣告人員會將其創意製作成簡報；這些樂曲、藍圖及簡報就是模型(Model)，而建構這些模型的過程就稱為塑模(Modeling)。

軟體開發如同音樂譜曲及建築設計，其過程中也必須將需求、分析、設計、實作、佈署等各項工作流程之構想與結果予以呈現，這就是軟體系統之塑模。

.UML八大模型圖來表達的各種不同的觀點1.

使用者觀點(Userview):從某些與系統相關角色的使用者觀點來看，使用者會和那些系統互動，相反的也可看出那些使用者會使用到該系統。使用的圖形有使用案例圖(UseCaseDiagram)。2.

結構觀點(Structuralview):從軟體程式或系統的結構觀點來看。使用的圖形有類別圖(ClasaDiagram)、物件圖。3.

行為觀點(Behaviorview):從軟體程式行為(流程)觀點來看，尤其是針對物件與物件之間的行為。使用的圖形有循序圖(SequenceDiagram)、合作圖(CollaborationDiagram)、狀態圖(StateDiagram)、活動圖(ActivityDiagram)。.UML八大模型圖來表達的各種不同的觀點4.

建置觀點(Implementationview):從建置整個系統的觀點來看，那些軟體元件必須建置在何處。使用的圖形有元件圖(ComponentDiagram)。5.

環境觀點(Environmentview):從整個系統的環境觀點來看，那些硬體和軟體必須佈署在何處。使用的圖形有配置圖(DeploymentDiagram)。.UseCaseDiagram（使用案例圖）在運用UseCaseDiagram時的重要課題，是要認清使用者目標（usegoal）與系統互動（systeminteraction）兩者之間的差異。圖形內中主要描述行為者（Actor）與使用個案（UseCase）的關係。.UseCaseDiagram-Symbol26學生查詢課程介紹演員(Actor)凡事會與系統互動的都可以是演員演員不一定是人使用案例(UseCase)唯一性表示系統所執行的功能連接線(Association)表是某個演員啟動了某個案例系統(System)當開發系統不需要和其他系統互動時省略.UseCaseDiagram–Example定期備份系統27時間備份系統.ClassDiagram（類別圖）Classdiagram是用來描述系統中物件的類型，以及類型間的各種靜態關係。.ClassDiagram-Symbols29學生-學號-姓名+修改資料()-驗證資料()#顯示資料()屬性類別名稱方法.ClassDiagram（Example）老師和課程的關聯30老師課程開設.SequenceDiagram（順序圖）在UML裡面，Scenario指的是一個usecase中的某一個單一實行路徑，也就是在一個usecase中某幾個特殊狀況，結合在一起的情形。而用來描述Scenario的工具即是SequenceDiagram。.SequenceDiagram–ObjectType32<<entity>>:學生<<boundary>>:修改學生資料明細<<control>>:修改