基於簽名真偽識別專案的需求分析和概念模型

2022-07-11 05:00:14 字數 3356 閱讀 7905

參考文獻:從需求分析到軟體設計.pptx

本人所參與的工程實踐專案為基於深度學習,對中文手寫簽名進行特徵提取,分析該簽名是否為本人所簽名。本專案偏向研究型,展示系統較工程類工程實踐稍顯簡略,下面對專案進行相應的需求分析與概念原型等分析。

在寫本專案的需求分析之前,我們需要知道需求分析的定義是什麼,即什麼是需求分析。在孟老師的課件上可以找到如下定義:需求就是對使用者期望的軟體行為的表述;而獲取需求就是需求分析師通過關注使用者的期望和需要,從而獲得使用者期望的軟體行為,然後對其進行表述的工作;最後需求分析是在獲取需求的基礎上進一步對軟體涉及的物件或實體的狀態、特徵和行為進行準確描述或建模的工作。

了解了定義之後,接著就可以進行本課題的需求分析。當前,手寫簽名作為乙個法律性的生物特徵,已經被廣泛用於身份的真實性和有效性的證明,平日裡合同、證書、協議和單據等文書都會使用到簽名。然而目前對於手寫簽名的檢測,大都採用人為鑑別的方式,這種檢測方式準確率不高且效率低下。而且手寫簽名作為乙個後天性的生物行為特徵,穩定性較差,即便同乙個人連續寫出的簽名也不會完全相同,甚至有較大差異,並且簽名也較容易被模仿。而本課題主要是針對這些問題,設計了基於深度神經網路技術的離線手寫簽名鑑別系統,以達到快速鑑別真偽簽名的同時,能夠非常準確地鑑別出隨機偽造的簽名,比較準確的檢測出高水平偽造簽名的目的。

同樣,在進行用例建模前,需要了解什麼是用例。課件中給出的定義如下:用例(use case)的核心概念中首先它是乙個業務過程(business process),經過邏輯整理抽象出來的乙個業務過程,這是用例的實質。而在待開發軟體所處的業務領域內完成特定業務任務(business task)的一系列活動就是業務過程。

用例還包含幾個基本要素:

1、乙個用例應該由業務領域內的某個參與者(actor)所觸發。

2、用例必須能為特定的參與者完成乙個特定的業務任務。

3、乙個用例必須終止於某個特定參與者,也就是特定參與者明確地或者隱含地得到了業務任務完成的結果。

在準確理解用例概念的基礎上,我們可以進一步將用例劃分為三個抽象層級:

1、抽象用例(abstract use case):只要用乙個幹什麼、做什麼或完成什麼業務任務的動名詞短語,就可以非常精簡地指明乙個用例;

2、高層用例(high level use case):需要給用例的範圍劃定乙個邊界,也就是用例在什麼時候什麼地方開始,以及在什麼時候什麼地方結束;

3、擴充套件用例(expanded use case):需要將參與者和待開發軟體系統為了完成用例所規定的業務任務的互動過程一步一步詳細地描述出來,一般我們使用乙個兩列的**將參與者和待開發軟體系統之間從用例開始到用例結束的所有互動步驟都列舉出來。

將用例劃分為三個抽象層級後,我們就可以知道用例建模的四個基本步驟。

第一步,從需求表述中找出用例,往往是動名詞短語表示的抽象用例;

第二步,描述用例開始和結束的狀態,用tucbw和tucew表示的高層用例;

第三步,對用例按照子系統或不同的方面進行分類,描述用例與用例、用例與參與者之間的上下文關係,並畫出用例圖;

第四步,進一步逐一分析用例與參與者的詳細互動過程,完成乙個兩列的**將參與者和待開發軟體系統之間從用例開始到用例結束的所有互動步驟都列舉出來擴充套件用例。(其中第一步到第三步是計畫階段,第四步是增量實現階段。)

有了這些預備知識以後,那麼本專案的用例圖也就能夠完成了。

使用者用例圖

管理員用例圖

業務領域建模是開發團隊用於獲取業務領域知識的過程。因為軟體工程師往往需要工作在不同的業務領域或者不同專案中,他們需要業務領域知識來開發軟體系統。軟體工程師往往來自不同的專業背景,這可能會影響他們對業務領域的認知。因此業務領域建模有助於開發團隊獲取業務領域知識形成統一的業務認知。

而開發團隊獲取業務領域知識的過程一般如下所示:

第一步,收集應用業務領域的資訊。聚焦在功能需求層面,也考慮其他型別的需求和資料;

第二步,頭腦風暴。列出重要的應用業務領域概念,給出這些概念的屬性,以及這些概念之間的關係;

第三步,給這些應用業務領域概念分類。分別列出哪些是類、哪些屬性和屬性值、以及列出類之間的繼承關係、聚合關係和關聯關係。

第四步,將結果用 uml 類圖畫出來。

本專案的各類屬性為如下所示:

使用者類:

屬性:使用者名稱,賬號,密碼,郵箱

管理員類:

屬性:使用者名稱,賬號,密碼,郵箱

方法:管理使用者資訊、模型管理

屬性:檔名稱、檔案格式

方法:上傳

模型類:

屬性:模型版本

方法:呼叫、更換版本

其中使用者類和管理員類是關聯關係,使用者類和檔案類也是關聯關係,管理員類和模型類是關聯關係,而檔案類和模型類為聚合關係。

而本專案的uml圖如下所示:

資料模型如下所示

管理員:

欄位字段描述

型別name

使用者名稱string

id賬戶

intpassword

密碼string

email

郵箱string

使用者:

欄位字段描述

型別name

使用者名稱string

id賬戶

intpassword

密碼string

email

郵箱string

欄位字段描述

型別image_name

名稱string

image

格式image

模型:

欄位字段描述

型別model_version

模型版本

float

概念是人對能代表某種事物或發展過程的特點及意義所形成的思維結論,而概念原型是一種虛擬的、理想化的軟體產品形式,就像程式=演算法+資料結構一樣,概念原型=用例+資料模型

而本課題的工作流程可以概括如下:

1)使用者通過系統首頁進行賬號註冊,註冊成功後使用賬戶密碼登陸系統。然後根據需求選擇相應功能,按照提示輸入簽名,得到對應功能模型生成的回答。

b)管理員通過介面更換模型版本,管理使用者資訊。

因為我的工程實踐偏向於演算法的研究,所以業務上較其他人的工程類工程實踐要顯得簡單一些,但是通過這一次作業,對從需求分析到軟體設計的基本建模方法有了一次較為完整的體會,為之後的軟體工程開發打下了良好的基礎。

軟體專案的需求分析

需求分析 在具體的研究需求分析之前,我們先了解一下軟體工程這個概念。軟體工程分為三個層次,過程層 方法層 工具層。在最基礎的過程層,最重要的就是一組被稱為關鍵過程區域 kpas 的框架 kpa的概念在討論cmm的書中有詳細的概念說明 關鍵過程區域構成了軟體專案的管理控制的基礎,並且確立了上下文各區域...

關於人工智慧 人臉識別專案的改造

昨天瀏覽了部落格關於模板的寫法,相關的文章很多都有撰寫,這裡就鏈結一遍 設計模式 這裡的例子也是根據tomcat的service方法來做修整,如裡面的template方法的service 這個演算法邏輯就把一系列需要子類繼承實現的鉤子方法使用統一的命名doxx來規範,最後統一這些鉤子方法到模板的se...

基於Imx6ull的車牌識別專案

前言 這個專案是自己用來練手學linux的專案,跟著訊為電子出的教程做的乙個車牌識別專案。硬體用的野火的開發板 野火的五寸觸控螢幕 免驅的攝像頭,系統用的野火的debian系統,上位機是用qt寫的。drawn by 67373upup 在ubuntu下配置環境 1.1 編譯openssl cd op...