2. 程式人生 > >系統分析與設計第四次作業

系統分析與設計第四次作業

阿新 • • 發佈：2019-01-11

一.用例建模

  • a.閱讀 Asg_RH 文件，繪製用例圖。 按 Task1 要求，請使用工具 UMLet，截圖格式務必是 png 並控制尺寸

Lesson6_EX1

  • b.選擇你熟悉的定旅館線上服務系統（或移動 APP），如繪製用例圖。並滿足以下要求：
    • 對比 Asg_RH 用例圖，請用色彩標註出創新用例或子用例
    • 儘可能識別外部系統，並用色彩標註新的外部系統和服務

選擇的定賓館線上服務系統為去哪兒網，繪製的用例圖如下所示：

Lesson6_EX2

  • c. 對比兩個時代、不同地區產品的用例圖，總結在專案早期，發現創新的思路與方法
  1. 各種事物變化很快，專案的設計要緊跟科技發展的潮流
  2. 要把握顧客的心理,適應顧客心理活動規律
  • d. 請使用 SCRUM 方法，在（任務b）用例圖基礎上，編制某定旅館開發的需求 （backlog）
    1. 首先需要確定旅館開發的Product Backlog（按優先順序排列的一個產品需求列表），這個是由Product Owner 負責
    2. Scrum Team根據Product Backlog列表，做工作量的預估和安排
    3. 有了Product Backlog列表，我們需要通過 Sprint Planning Meeting（Sprint計劃會議） 來從中挑選出一個Story作為本次迭代完成的目標，這個目標的時間週期是1~4個星期，然後把這個Story進行細化，形成一個Sprint Backlog
    4. Sprint Backlog是由Scrum Team去完成的，每個成員根據Sprint Backlog再細化成更小的任務（細到每個任務的工作量在2天內能完成）
    5. 在Scrum Team完成計劃會議上選出的Sprint Backlog過程中，需要進行 Daily Scrum Meeting（每日站立會議），每次會議控制在15分鐘左右，每個人都必須發言，並且要向所有成員當面彙報你昨天完成了什麼，並且向所有成員承諾你今天要完成什麼，同時遇到不能解決的問題也可以提出，每個人回答完成後，要走到黑板前更新自己的 Sprint burn down（Sprint燃盡圖）
    6. 做到每日整合，也就是每天都要有一個可以成功編譯、並且可以演示的版本；很多人可能還沒有用過自動化的每日整合，其實TFS就有這個功能，它可以支援每次有成員進行簽入操作的時候，在伺服器上自動獲取最新版本，然後在伺服器中編譯，如果通過則馬上再執行單元測試程式碼，如果也全部通過，則將該版本釋出，這時一次正式的簽入操作才儲存到TFS中，中間有任何失敗，都會用郵件通知專案管理人員
    7. 當一個Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，這時，我們要進行 Srpint Review Meeting（演示會議），也稱為評審會議，產品負責人和客戶都要參加（最好本公司老闆也參加），每一個Scrum Team的成員都要向他們演示自己完成的軟體產品（這個會議非常重要，一定不能取消）
    8. 最後就是 Sprint Retrospective Meeting（回顧會議），也稱為總結會議，以輪流發言方式進行，每個人都要發言，總結並討論改進的地方，放入下一輪Sprint的產品需求中

    二.業務建模

    • a. 在（任務b）基礎上，用活動圖建模找酒店用例。簡述利用流程圖發現子用例的方法
        利用流程圖發現子用例方法：沿著流程圖的開始狀態，選擇流程圖中任意一個的分支點到流程圖的結束狀態，就是一個子用例，比如下圖中，從開始狀態開始一直到Room Available這個分支點，選擇yes，並且最終到達結束狀態，這就是一個子用例

    Lesson6_EX3
    • b. 選擇你身邊的銀行 ATM，用活動圖描繪取款業務流程

    Lesson6_EX4

    • c. 查詢淘寶退貨業務官方文件，使用多泳道圖，表達客戶、淘寶網、淘寶商家服務系統、商家等使用者和系統協同完成退貨業務的過程。分析客戶要完成退貨業務，在淘寶網上需要實現哪些系統用例

    Lesson6_EX5

    三.用例文字編寫

    • 在大作業基礎上，分析三種用例文字的優點和缺點
      • 優點：
    1. 簡潔、直觀,系統互動行為很清晰地表達出來。
    2. 規範、易理解。
    3. 需求與設計分離。因為用例文字是站在系統外的視角描述系統需求的，所以並沒有介入到系統內部實現細節，這就讓需求和設計工作分離開來，條理清晰
    • 缺點:
    1. 不能表達非功能需求。用例文字是描述使用者功能需求的工具，對於可靠性、效能等非功能需求無能為力
    2. 對不懂UML的客戶或程式設計師來說難以理解。對UML支持者來說，用例文字可能是規範的、清晰的、簡單的、易理解的，但對並未掌握UML建模技術的人來說理解那些橢圓並非易事，再說還有一系列如同虛擬碼似的事件流
    3. 粗粒度。用例文字不涉及設計實現細節，只是一個功能劃分，粒度非常粗，很多細節無從描述，需要用其他工具進行輔助說明

    相關推薦

    系統分析與設計第四次作業

    一.用例建模 a.閱讀 Asg_RH 文件，繪製用例圖。 按 Task1 要求，請使用工具 UMLet，截圖格式務必是 png 並控制尺寸 b.選擇你熟悉的定旅館線上服務系統（或移動 A

    系統分析與設計第八次作業

    一.描述軟體架構與框架之間的區別與聯絡軟體架構：軟體架構是一個系統的草圖。軟體架構描述的物件是直接構成系統的抽象元件。各個元件之間的連線則明確和相對細緻地描述元件之間的通訊。在實現階段，這些抽象元件被細

    系統分析與設計第六次作業--狀態建模

    1）使用 UML State Model 建模物件： 參考 Asg_RH 文件， 對 Reservation/Order 物件建模。 建模要求： 參考練習不能提供足夠資訊幫助你對訂單物件建模，請參考

    系統分析與設計-第九次作業

    系統分析與設計-Lesson16 使用 ECB 實現 make reservation 用例的詳細設計（包含用例簡介，順序圖，類圖） 邏輯設計類圖對映到實際專案框架的包圖。用樹形結構表述實

    系統分析與設計第九次作業

    一、使用 ECB 實現 make reservation 用例的詳細設計（包含用例簡介，順序圖，類圖） 1.用例簡介 2.順序圖 3.類圖 4.將邏輯設計類圖對映到實際專案框架的包圖。用樹形結構表述實現的包和類。

    演算法分析與設計第五次作業（leetcode 中 Majority Element 題解）

    心得體會 這個題目有兩個版本Majority Element，和Majority Element II，解題的方法比較巧妙，有點想不到的感覺，並且證明過程也很有趣，所以就記錄下來（具體詳情見正文題解）。 題解正文 題目描述 問題分析 題目要求majority

    演算法分析與設計第八次作業（leetcode中Sum of Distances in Tree題解）

    Sum of Distances in Tree 題解 題目描述 題目分析 題目意思很清楚：題目給出一個擁有最小邊數的連通圖，也就是一共n個頂點，n-1個邊的連通圖，這種圖的性質是從任意頂點出發進行遍歷都能夠得到一棵樹。要求我們求出每個點到其他點的距離之和，即

    演算法分析與設計第十次作業之Remove Duplicate Letters題解

    題解正文 題目描述 問題分析 題目意思是，給定一個只包含小寫字母的字串，我們要刪除其中所有的重複字元，然後從這些刪除方法所得結果中選擇字典序最小的字串作為本題的答案 解題思路 下面的解題過程中我們都是從左往右選擇字元新增到答案字串中 所謂去重，那麼要保證每

    Java程序設計第四次作業內容

    ase 定義 cnblogs 設計 分支 鍵盤 12個 nth 情況 第六題：使用判斷語句，根據數字，輸出對應的中文是星期幾？ 直接使用一個if語句的情況 int weekDay=3; if(weekDay==1){ 　　sop("今天是星期一"); } if(weekDa

    演算法分析與設計第十四次作業（leetcode中Cherry Pickup題解）

    題解正文 題目描述 問題分析 此題給出一個n乘n矩陣，矩陣中值可以是0/1/-1。 要求我們找出從（0，0）出發，到（n-1，n-1），然後回到（0，0）的路徑，要求往程只能向右向下，而返程只能向左向上走，並且路徑沒有經過值為-1的位置。 然後求出符合上述要求的路徑中，所經

    系統分析與設計第二次作業

    滿足 無法 mage 兩個 div 比較 ons erl 用戶 1、簡答題 簡述瀑布模型、增量模型、螺旋模型（含原型方法）的優缺點。 waterfall model 瀑布模型 ： 優勢： 為項目提供了按階段劃分的檢查點。 當前一階段完成後，您只需要去關註後續階段。 可在叠

    面向對象設計與構造第四次總結作業

    同學 調度 設計原則 完整 自然語言 看到了 itl src 對數 1 測試與正確性論證的比較 　　測試和論證都是驗證程序正確性的方法。 　　測試是在一組測試用例上執行一個程序，並將實際結果與期望結果進行比較以揭示錯誤的存在，但不會精確地揭示錯誤所在之處。如

    WordCount 記第一次系統分析與設計課程個人項目作業

    win idea utf pub 做到 out 測試報告 第一個 buffer 作業成果 作業源碼-java-gitee. 作業要求 根據WordCount的需求描述，先編程實現，再編寫單元測試，最後撰寫博客。 WordCount需求分析 WordCount的需求可以概括為

    現在軟件工程第四次作業-學習四象限且利用四象限分析項目產品

    系統分析與設計——作業3

    uml border table log str mage 網上 body src 1、用例建模 a.閱讀 Asg_RH 文檔，繪制用例圖。 按 Task1 要求，請使用工具 UMLet，截圖格式務必是 png 並控制尺寸 b.選擇你熟悉的定旅館在線服務系統（或移動

    系統分析與設計——作業5

    閱讀 nbsp 圖片 模型 png .com AS 數據 領域建模 1、 領域建模 a. 閱讀 Asg_RH 文檔，按用例構建領域模型。 領域模型： b. 數據庫建模(E-R 模型) （1）系統的 E-R 模型（數據邏輯模型）: （2）導出 Mysql 物理數據庫

    2017-2018-2 20179223《密碼與安全新技術》第四次作業

    大數 des 發展 alt work 安全性 key 認證 sign 課程：《密碼與安全新技術》 班級：1792班 姓名：劉霄 學號：20179223 上課老師：謝四江 上課日期：2018年4月26日 必修/選修：必修 學習總結 本次課程由管理系劉飈老師為我們講解有關——分

    系統分析與設計——作業7

    img png sys info 分享圖片 oar 領域模型 狀態 分析 我選擇的是https://github.com/Owl-Movies-Ticket-System/Dashboard/blob/gh-pages/XX1-Forest%E5%BA%94%E7%94%A

    系統分析與設計——作業8

    開發者 模式 解決方案 技術 繪制 三層 作業 相關 架構 一.描述軟件架構與框架之間的區別與聯系 （1）軟件架構與框架的區別： 架構是把系統分解為一些部件，描述這些部件的職責及它們之間的協作行為；架構模式是特定領域常見問題的解決方案。 而框架是具體語言和技術相關的，是特定

    系統分析與設計——作業9

    數量 是否 要求 需要 訂單 nbsp 進行 預訂 星級 1. （1）用例簡介 a.選擇酒店：用戶確定需要預定的酒店，用戶得知這個酒店的途徑有：直接搜索得到和查看排序後結果（排序項有價格、喜好、星級等等）進行選擇。 b.選擇時間：用戶選擇入住時間和離開時間。 c.細化具體要