需求分析和概念原型（自动病灶检测系统）

 

一、工程实践简介

 

 此篇博客为针对我的工程实践项目：基于深度学习的通用病灶检测的需求分析和概念原型。

 

①计算机辅助检测/诊断(CADe/CADx)在医学图像处理领域一直是非常繁荣和成功的研究领域，卷积神经网络（CNN）基于深学习算法显著优于传统的统计学习方法与手工图像特征结合执行。 但是，这些性能提升通常是以需要大量带标签的训练数据为代价的。

与一般的计算机视觉任务不同，医学图像分析当前缺乏大规模的带注释的图像数据集，这主要是因为传统的通过搜索从普通用户收集图像标签的方法不能应用于医学图像领域， 医学图像注释需要广泛的临床专业知识。

 

②现有的检测算法通常针对一种特定的病变类型，如皮肤病变、肺结节，肝病变，硬化性病变和结肠息肉等。虽然一些常见的病变类型受到很多关注，但大多数程序却忽略了大量不常见的病变类型。此外，一次研究一种病变类型与放射科医生通常用于阅读医学图像和汇编放射报告的方法不同。

在实践中，可以观察到多种发现，并且经常相互关联。例如，转移可以扩散到区域淋巴结或其他身体部位。通过获取并保持相关临床结果的整体图像，放射科医生将能够做出更准确的诊断。然而，开发通用或多类别算法框架仍然具有挑战性，我们要做的就是开发一个通用病灶识别系统，能够以无缝方式检测多种病变类型。

 

 二、用例建模

 

 自动识别系统的研发具有重要的意义，智能系统能在人为参与较少的领域诸如医疗影像分析和医疗大数据的处理方面有着巨大的潜力，医疗器械生成的数据直接交给人工智能进行高速精准的分析，快速的帮助医生处理大量的简单重复性的工作，做出合理的诊断或是提供合理的治疗方案，有效的提高医疗的效率。让医生从简单的重复工作中解放出来，发挥他们真正的智慧和能力。有报告指出，医疗机构采用人工智能系统后，医疗设施分配合理，患者也能合理分流，提高了全院的效率。

病变检测对于放射科医师来说是一项耗时的任务，但却是诊断的关键部分，该检测器可以作为放射科医师或其他专业CADe系统的初始筛查工具。此次设计的通用病灶检测系统旨在帮助医生更快更方便的对患者的CT图像进行自动化标注，通过深度学习的方法先对CT进行预标注然后推送给医生确认。

 

 

2.1用例建模

 

什么是用例：

用例（Use Case）的核心概念中首先它是一个业务过程（business process），经过逻辑整理抽象出来的一个业务过程，这是用例的实质。什么是业务过程？在待开发软件所处的业务领域内完成特定业务任务（business task）的一系列活动就是业务过程。

 

用例的几个基本要素：

• A use case is initiated by (or begins with) an actor. 一个用例应该由业务领域内的某个参与者（Actor）所触发。

• A use case must accomplish a business task (for the actor).用例必须能为特定的参与者完成一个特定的业务任务。

• A use case must end with an actor. 一个用例必须终止于某个特定参与者，也就是特定参与者明确地或者隐含地得到了业务任务完成的结果。

 

用例是应用程序开发中的一个关键技术，主要用来捕获系统的高层次（High Level）用户功能性需求。是软件工程或系统工程中对系统如何反应外界请求的描述，是一种通过用户的使用场景来获取需求的技术。每个用例提供了一个或多个场景，该场景说明了系统是如何和最终用户或其它系统互动，也就是谁可以用系统做什么，从而获得一个明确的业务目标。

 

用例由以下元素组成：

• 名称
• 简单描述
• 事件流
• 关系
• 活动图和状态图
  
• Use Case 图
• 特殊需求

 

2.2高层用例（用例在什么时候什么地方开始，以及在什么时候什么地方结束）

 

1.用户登录

TUCBW Actor输入用户名密码登陆

TUCEW 用户登录成功或失败

 

2.查看浏览记录

TUCBW Actor点击查看浏览记录

TUCEW 返回所有医生看过的CT片记录

 

3.查看未标注

TUCBW Actor点击查看未标注CT

TUCEW 返回CT室发来但还未标注的CT

 

4.查看已标注

TUCBW Actor点击查看已标注CT

TUCEW 返回已标注还未确认的CT

 

 2.3用例图

 

 

 

三、业务领域建模

 

3.1什么是业务领域建模

 

业务领域建模是开发团队用于获取业务领域知识的过程。因为软件工程师往往需要工作在不同的业务领域或者不同项目中，他们需要业务领域知识来开发软件系统。软件工程师往往来自不同的专业背景，这可能会影响他们对业务领域的认知。因此业务领域建模有助于开发团队获取业务领域知识形成统一的业务认知。

开发团队获取业务领域知识的过程一般包括收集业务领域相关信息、执行团队头脑风暴、对业务领域相关的知识概念进行分类，最后用UML类图将业务领域知识图形化展示。

 

 总之：

• 第一步，收集应用业务领域的信息。聚焦在功能需求层面，也考虑其他类型的需求和资料；

• 第二步，头脑风暴。列出重要的应用业务领域概念，给出这些概念的属性，以及这些概念之间的关系；

• 第三步，给这些应用业务领域概念分类。分别列出哪些是类、哪些属性和属性值、以及列出类之间的继承关系、聚合关系和关联关系。

• 第四步，将结果用 UML 类图画出来。

 

 

3.2数据模型

 

User

列名	数据类型	是否可为NULL	唯一	数据长度	注释
id	string	N	Y	256	用户ID
username	string	N	Y	20	用户名
password	string	N	N	256	密码
phone_number	string	N	N	24	电话号
email	string	Y	N	256	邮箱

 

 

 

 

 

 

 

 

 

CT

列名	数据类型	是否可为NULL	唯一	数据长度	注释
patient_ID	string	N	Y	256	患者ID
patient_name	string	N	N	256	患者姓名
type_of_illness	string	N	N	256	患病类型
departments	string	N	N	256	所属科室
taged	string	N	N	4	是否标注

 

 

 

 

 

 

 

 

 

Bounding box

列名	数据类型	是否可为NULL	唯一	数据长度	注释
Left_top_coordinate	string	N	N	128	左上坐标
Right_bottom_coordinate	string	N	N	128	右下坐标
label	string	N	N	256	标签
amount	int	N	N	256	BoundingBox数量

 

 

 

 

 

 

 

 

3.3 类图

 

 

四、概念原型

 

• 概念是人对能代表某种事物或发展过程的特点及意义所形成的思维结论。
• 概念原型是一种虚拟的、理想化的软件产品形式。

 

 

 

 

 

 

本次项目的概念原型主要是做为放射科医师或其他专业CADe系统的初始筛查工具。此次设计的通用病灶检测系统旨在帮助医生更快更方便的对患者的CT图像进行自动化标注，通过深度学习的方法先对CT进行预标注然后推送给放射科医生确认。放射科医生可以对标注的Boundingbox进行删除增加和调整等操作。

五、总结

本次作业要求我们对自己的工程实践项目进行需求分析和用例图建模和概念原型总结，虽然之前也有过软工的课程，但是还没有像这样把自己真正要做的东西总结一步一步的写出来过。这次要做的工程实践不仅包括了深度学习目标检测的部分还要做出通用病灶检测系统，通过这次博客的编写过程也让自己更清楚了整个项目的流程和自己要做的东西，对项目有了更深的认识，收获很多。