2017年1月3日 星期二

SA、SD、PG

本文將會討論這三個職位在我們團隊中各扮演什麼樣的角色

SA-系統分析師(System Analyst)

跟客戶做需求訪談,利用詢問到的需求做產品的設計分析,由於做需求訪談的對象較多是直接操作系統的使用者,所以對於需求的產生是建立在功能使用情境及介面操作上,因為會需要跟專業領域的使用者訪談,也需要對產品的Domain Knowledge有一定程度的認識,所以SA就是將情境說明及介面的操作設計搭配系統的專業領域知識寫出SRS(Software requirements specification),其中產出包括以下幾點:

  • 業務流程圖:整個模組的流程圖
  • 基本資料:功能代號、名稱、概述、需要編號、使用單位、角色
  • 前置作業:使用此功能前須要做的事情,像是要建的資料、要在哪個狀態才可以使用此功能
  • 使用案例說明:情境描述、操作行為、注意事項、功能間的交互關係
  • 使用案例畫面:介面的呈現與設計
  • 欄位定義:介面上每個欄位的名稱、種類(下拉選單、文字、日期…)、資料來源(系統代碼…)、是否必填
SRS為需求導向,做的是軟體的分析,比較著重在邏輯跟順序的設計,也因為SRS跟特定的程式語言其實沒有很大的關係,所以SRS可以用不同的程式語言所實作

SD-系統設計師(System Designer)

SD會依照SA撰寫的SRS去做更細部的規格設計,也就是技術規格,SD通常會是有系統開發經驗的人擔任,必須要了解系統的運作方式及程式語言,把由SRS上得到的使用情境及介面操作寫成程式的實作方式、設計資料的存放方式及測試案例的設計,SD會寫出SDD(Software Design Description),會產出以下幾點:
  • 欄位定義:詳細的欄位定義,像是由那張資料表取得、取得的方式、條件(JoinExists),要實做的控制項(Drop Down ListDate PickerText Box)
  • 細部說明:實作方式,特殊需求
  • 參考檔案:與此功能相似做法的參考,取得資料要使用的UDFSP
  • Service MethodService設計,傳入的參數、命名
  • 單元測試注意事項:單元測試需要注意的地方,測試資料設計,畫面測試情境設計
  • Table Schema設計:DB資料表設計(參數名、型態、預設)
SDD為技術導向,會跟其系統架構及程式語言緊密結合,著重在以某種語言實作出可執行的程式

 

PG-程式設計師(Programer)

PG的職責為撰寫程式碼,拿到SDD後依照上面所述的規格寫程式

參考連結

2017年1月2日 星期一

ASP.NET Web API

本文將建立一個基本的Web API,使用Postman做Demo

Overview

此文章將會建立一個Web API

創建專案

1. File->New->Project…

2. Create ASP.NET Web Application
3. 選擇Empty,勾選Web API
4. Controller資料夾按右鍵->Add->New Item…,新增Web API Controller Class,檔名是ValuesController.cs
點開ValuesController.cs可以看到已經幫我們寫要Web API的框架了,我們現在來看一下路由的設置

可以看到routeTemplate被設置為
"api/{controller}/{id}"
{controller}:要呼叫的controller name(此例子即為Values)
{id}:參數資料

建置專案

按下F5啟動偵錯
會跑出HTTP Error 403.14 - Forbidden的錯誤是因為我們沒有建立頁面,可是Web API的功能還是正常的,現在開啟PostmanHTTP動詞是GET,在URL上輸入http://localhost:{Port Number}/api/values,按下Send

我們可以看由Get Action所傳回來的陣列
如果改為http://localhost:{Port Number}/api/values/5會因為路由機制會導至第一個符合條件,所以會由有id參數的Get所處理
就會看到單一的value

總結

這次已經完成一個簡單的Web API,透過強大的Visual Studio的模板功能,沒有動到程式碼就可以完成一個Web API的框架

參考連結