以下为《OIS_SW_SystemDesign_Draft_V0.1》的无排版文字预览,完整内容请下载
OIS
系统设计书
当前版本
0.10
密级
CONFIDENTIAL
文档编号
YIDATEC-P***-SDS-0001
总页数
18
正文页数
13
附录页数
1
编制人
何某某
评审人
批准人
编制日期
20/03/25
评审日期
批准日期
修改履历
序号
状态
版本
修改内容
修改位置
修改人
日期
评审人
日期
批准人
日期
1
C
0.10
新建
全文
何某某
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
状态:C—创建文档,A—增加内容,M—修改内容,D—删除内容
目录
1. 文档概述 1
1.1. 目的 1
1.2. 术语表 1
1.3. 关联文档 1
2. 系统体系结构设计 2
2.1. 系统处理流程 2
2.2. 系统结构图 3
2.3. 模块构成表 5
3. 系统运行时结构设计 6
3.1. 任务构成 6
3.2. 任务优先级 6
3.3. 运行时间 6
3.4. 运行控制 6
3.5. 编程框架的使用 6
4. 系统内存分配和管理设计 7
5. 界面设计 8
6. 系统数据结构设计 9
6.1. 系统主要数据逻辑结构设计 9
6.2. 数据结构与程序的关系 9
7. 数据库设计 10
7.1. 概念结构设计 10
7.2. 逻辑结构设计 10
7.3. 物理结构设计 18
7.4. 存储过程设计 18
8. 系统安全性设计 20
8.1. 系统错误处理设计 20
8.2. 其他安全性设计 20
9. 其他设计 21
9.1. 使用第三方软件的考虑 21
9.2. 系统调试的考虑 21
9.3. 可扩展性的考虑 21
9.4. 可维护性的考虑 21
10. 参考 22
文档概述
本文档是针对OIS软件的系统设计书,治疗系统的其它子系统及其硬件不在本设计的范围之内。
目的
系统设计的目的是设计本系统内的软件部件构成和相互关系,以指导概要设计和详细设计等后续阶段的实施。
术语表
本系统所使用的术语如表 1–1 术语表所示。
表 1–1 术语表
缩写、术语
解 释
TCS
治疗控制系统
OIS
肿瘤信息系统
DICOM
医学数字成像和通信
TPS
治疗计划系统
PACS
医疗影像存档与传送系统
关联文档
本系统设计的关联文档如表 1–2 关联文档表所示。
表 1–2 关联文档表
序号
文档名称
1
需求文档
2
会议记录
3
4
5
系统体系结构设计
整体架构以C/S为架构,OIS接受TPS发送过来的患者治疗计划,对其进行解析。将解析的数据存放到OIS的数据库,并且把图像以dcm格式存放到共享目录,在此过程中,操作医师可以查看患者治疗计划的相关数据和图像。同时把接收到患者治疗计划通知TCS,TCS将对患者治疗计划实施标定和验证操作。TCS操作成功后,通知OIS验证结果。OIS再对患者治疗计划的具体治疗日期进行排程。
图2-1 系统结构图
软件整体采用Microsoft体系搭建为主,数据库采用MySQL,服务器操作系统为Windows Server 2008 R2以上,操作机操作系统为Windows 10专业版(64位),开发语言采用C#。
这种体系搭建优点如下:
整体满足系统要求
后期维护成本低,对维护人员的要求也不高
C#(WPF)能方便快捷的搭建美观易用的UI
开发周期相对快捷
系统处理流程
OIS解析来自TPS的患者治疗计划,并且将解析后的数据保存到DB,同时将医疗影像以dcm文件格式存放到共享目录,在此过程中,操作医师可以查看解析后患者相关信息,如果存在医疗影像也能查看所有相关影像。
OIS解析成功后,通知TCS有新的患者治疗计划
TCS得到OIS的通知后,从DB获取解析后的患者治疗数据,根据实际情况实施标定和验证的操作,并将验证结果通知OIS
OIS在得到验证结果后,对其排程(预约治疗时间),并通知TCS排程结果
TCS从DB获取排程为当日的患者数据,对其按照排程进行治疗
系统结构图
● OIS和外部子系统的结构
图2-2 作业范围示意图
TG:线程组(Thread Group),OIS内部拥有一个TG,专门用于和其对应其它系统,TG内有负责接收数据的Task,还有负责处理数据的Task。
● OIS内部设计
OIS的UI采用MVVM架构
图2-3 MVVM架构示意图1
MVVM架构和外部的服务调用通过View Model层来实现。
图2-4 MVVM架构示意图2
MVVM主要优点
低耦合:视图(View)可以独立于Model变化和修改,一个View Model可以绑定到不同的View上,当View变化的时候Model不可以不变,当Model变化的时候View也可以不变。
可重用性:可以把一些视图逻辑放在一个View Model里面,让很多view重用这段视图逻辑。
独立开发:开发人员可以专注于业务逻辑和数据的开发(View Model),设计人员可以专注于页面设计。
可测试:界面素来是比较难于测试的,而现在测试可以针对View Model来写。
● 服务器配置要求
1)OIS 服务器
操作系统: Windows 10 专业版/Windows Server 2008 R2以上(非必要的系统Service全部关闭)
CPU:Intel至强八核处理器
内存:32G
硬盘:固态硬盘512G以上
2)DB服务器
数据库:MySQL 8.0
操作系统: CentOS 8
CPU:Intel至强八核处理器
内存:32G
硬盘:4T以上,支持RAID
注意:推荐采购类似配置的服务器
操作系统推荐都采用Windows Server,具体版本可以根据需求分析调整
主要考虑Server在多线程、大内存以及安全性、稳定性上比普通Windows系统更加具有优势。
对其他的很多Server新功能用不上,所以不追求采用最新版本的Server。
XXXXXDB服务器可以搭建到TCS的DB服务器上,不用单独采购
另:建议一周拓机一次(虽然说服务器已经能做到365天不关机,但是考虑实际运行和内存状况,建议一周重启一次,可利用周末休息时间关机或重启服务器)
模块构成表
No
模块名
功能
备注
1
TCS(UI)
治疗控制系统
2
OIS
肿瘤信息系统
在开源系统基础上定制化
3
DB
数据库
TCS(UI)和OIS用
系统运行时结构设计
任务构成
OIS采用单进程多线程的方式。
主线程主要实现UI的更新,响应用户对UI的操作
子线程主要实现数据接收、发送、DB更新、逻辑处理等操作
任务优先级
根据实际应用情况设置各个线程/Task的优先级,对于处理时间较长的操作,都通过子线程来实现。子线程的优先级会根据业务需要来设置。
运行时间
原则上主线程不能阻塞,不影响用户的操作。
子线程的运行时间根据业务需要而定。对于花费时间的操作,可分步骤的更新UI,不用等到全部执行完后再更新UI。以避免用户感觉不到执行进度,影响体验。
运行控制
根据业务需求控制各个子线程/Task的通信和同步,对于共通变量或内存的访问,线程/Task之间需要采用互斥方式,确保数据变更或获取的唯一性。
编程框架的使用
整体采用MVVM架构,详细请参见第2章某某
系统内存分配和管理设计
.Net架构有内存管理和自动垃圾回收机制。一般不需要程序对分配的内存进行管理。但需要做到以下几点:
1)对托管内存,分配的对象如果对象有Dispose等方法,原则上要求该对象不使用之前必须先调用Dispose方法,然后设置该对象为NULL。
2)对非托管内存,分配后必须通过代码释放内存。
3)避免创建非必要的对象
4)创建对象后及时在代码中释放(通过调用Dispose、Close方法,设置为NULL等)
5) 代码编写时少产生垃圾,比如String + String就会产生大量的垃圾,可以用StringBuffer.Append
界面设计
请参见UI原型设计文档以及UI效果图。
系统数据结构设计
与操作系统相关的数据结构无
后期根据业务需要进行添加
系统主要数据逻辑结构设计
1. 数据库数据类
每张表有一个对应的数据类,类的成员变量名表字段名相同、数据类的成员变量类型和同名表字段类型基本一致
2. 患者计划相关数据类
用于保存解析DICOM文件的数据类,根据OIS的解析需求自定义
3. 自定义相关数据类
根据模块和算法需要,自定义
数据结构与程序的关系
OIS的数据来源主要是TPS的DICOM对象,根据业务需求对DICOM对象解析后,数据存放到相关数据类,并保存到数据库。在解析和处理DICOM对象的过程中,根据需要自定义数据类以方便解析和处理。
图6-1 数据结构与程序示意图
数据库设计
数据库名:OISDB
OISDB数据库主要用于存放OIS解析患者治疗计划后的患者基本信息和治疗的相关数据。
概念结构设计
本文档只是对表的结构做初步的分析和设计,表之间的关联请参考相关DB的EA图
逻辑结构设计
用户表
表名:UserInformation
用于保存用户名、密码和所属组等信息,主要用于登录OIS登录后权限控制
字段名
字段类型
最大长度
是否唯一
是否可以为空
说明
用户名
字符型
32
是
否
主键
密码
字符型
64
否
否
MD5加密后保存
创建日
日期型
-
否
否
记录生成的日期,格式为:YYYY/MM/DD H24:MI:SS
更新日
日期型
-
否
否
记录更新时的日期,格式同创建日,记录生成时,数据同创建日
表7-1:用户表
患者基本信息表
表名:PatientBaseInformation
用于保存患者的基本信息
字段名
字段类型
最大长度
是否唯一
是否可以为空
说明
患者ID
字符型
32
是
否
主键
患者姓名
字符型
32
否
否
出生日期
日期型
-
否
否
性别
字符
1
否
否
M:男,F:女,U:未知
创建日
日期型
-
否
否
记录生成的日期,格式为:YYYY/MM/DD H24:MI:SS
更新日
日期型
-
否
否
记录更新时的日期,格式同创建日,记录生成时,数据同创建日
表7-2:患者基本信息表
治疗计划信息表
表名:TreatmentPlanInformation
用于保存解析的Dicom文件的基本信息
字段名
字段类型
最大长度
是否唯一
是否可以为空
说明
治疗计划ID
字符型
64
是
否
SOP实例UID
治疗计划名
字符型
32
否
否
患者ID
字符型
32
否
否
计划治疗总次数
短整型
-
否
否
来自TPS的本治疗计划需要治疗的次数
增加治疗次数
短整型
-
否
否
本治疗计划手动新添加的治疗次数(根据患者治疗情况,大夫可以手动添加治疗次数)
ISOCenter总数
短整型
-
否
否
计划状态
字符型
1
否
否
N:未开始;C:标定OK;V:模拟验证OK;S:排程OK/等待治疗;D:治疗中;I:治疗中断;F:治疗完成;L:治疗失败
计划有效性
布尔型
-
否
否
True:有效;False:无效
治疗室ID
字符型
255
否
是
根据治疗头信息得到治疗室ID,复数治疗头以;分割
创建日
日期型
-
否
否
记录生成的日期,格式为:YYYY/MM/DD H24:MI:SS
更新日
日期型
-
否
否
记录更新时的日期,格式同创建日,记录生成时,数据同创建日
表7-3:治疗计划信息表
Dicom等中心表
表名:DicomISOCenter
用于保存治疗计划文件的等中心坐标
字段名
字段类型
最大长度
是否唯一
是否可以为空
说明
ISOCID
字符型
32
是
否
主键,格式:ISOC_年月日时分秒毫秒
治疗计划ID
字符型
32
是
否
ISOCenter数
短整型
-
否
否
同DicomID的从1开始递增
ISOCenter数据
字符型
128
否
否
Json格式字符串
总射野数
整型
-
否
否
该ISO Center包含的射野数
创建日
日期型
-
否
否
记录生成的日期,格式为:YYYY/MM/DD H24:MI:SS
更新日
日期型
-
否
否
记录更新时的日期,格式同创建日,记录生成时,数据同创建日
表7-4:Dicom等中心表
射野表
表名:DicomBeam
用于保存射野的具体信息
字段名
字段类型
最大长度
是否唯一
是否可以为空
说明
射野ID
字符型
32
是
否
主键,格式:Beam_年月日时分秒毫秒
治疗计划ID
字符型
32
是
否
ISOCID
字符型
32
否
否
射野名
字符型
24
否
否
总层数
整型
-
否
否
射野扫描模式
字符型
1
否
否
S:点扫描;U:均匀扫描
射野剂量
浮点型
-
否
否
单位:Gy
治疗数据
Json
不限
否
否
治疗数据格式:为Json格式
创建日
日期型
-
否
否
记录生成的日期,格式为:YYYY/MM/DD H24:MI:SS
更新日
日期型
-
否
否
记录更新时的日期,格式同创建日,记录生成时,数据同创建日
表7-5:射野表
治疗计划状态表
表名:TreatmentPlanStatus
用于保存治疗计划的治疗信息
字段名
字段类型
最大长度
是否唯一
是否可以为空
说明
治疗计划ID
字符型
32
是
否
TP_年月日时分秒毫秒
治疗成功数
短整型
-
否
否
初始值:0
治疗失败数
短整型
-
否
否
初始值:0
治疗中断数
短整型
-
否
否
初始值:0
计划状态
字符型
1
否
否
N:未开始;C:标定OK;V:模拟验证OK;S:排程OK/等待治疗;D:治疗中;I:治疗中断;F:治疗完成;L:治疗失败
创建日
日期型
-
否
否
记录生成的日期,格式为:YYYY/MM/DD H24:MI:SS
更新日
日期型
-
否
否
记录更新时的日期,格式同创建日,记录生成时,数据同创建日
表7-6:治疗计划状态表
排程表
表名:TreatmentSchedule
用于安排患者的治疗日程
字段名
字段类型
最大长度
是否唯一
是否可以为空
说明
排程ID
字符型
32
是
否
主键,格式:Sch_年月日时分秒毫秒
治疗计划ID
字符型
32
否
否
计划开始时间
日期型
-
否
否
计划结束时间
日期型
-
否
否
实际开始时间
日期型
-
否
是
实际结束时间
日期型
-
否
是
本次排程执行结果
字符型
1
否
否
N:未开始;I:治疗中断;F:治疗完成;L:治疗失败
创建日
日期型
-
否
否
记录生成的日期,格式为:YYYY/MM/DD H24:MI:SS
更新日
日期型
-
否
否
记录更新时的日期,格式同创建日,记录生成时,数据同创建日
表7-7:排程表
治疗报告表
表名:TreatmentReport
用于保存要输出到PDF的数据
字段名
字段类型
最大长度
是否唯一
是否可以为空
说明
治疗ID
字符型
32
否
否
主键
报告数据
字符型
不限
否
否
Json格式
创建日
日期型
-
否
否
记录生成的日期,格式为:YYYY/MM/DD H24:MI:SS
更新日
日期型
-
否
否
记录更新时的日期,格式同创建日,记录生成时,数据同创建日
表7-8:治疗报告表
TCS在治疗过程中更新数据到该表,OIS根据操作医师要求,可以把该表数据输出为PDF文件。
具体根据操作医师的实际要求,会进行调整。
治疗信息表
表名:TreatmentInformation
用于保存治疗的基本信息,以便治疗报告使用
字段名
字段类型
最大长度
是否唯一
是否可以为空
说明
治疗ID
字符型
32
否
否
主键
患者ID
字符型
32
否
否
治疗计划ID
字符型
32
否
否
当前治疗次数
短整型
-
否
否
治疗日时
日期型
-
否
否
创建日
日期型
-
否
否
记录生成的日期,格式为 内容过长,仅展示头部和尾部部分文字预览,全文请查看图片预览。 出错的调用信息、错误发生的代码位置等
其他安全性设计
数据库搭建在RAID上,以RAID来确保数据的恢复,同时,通过定期数据库备份来实现数据存储的安全。
对共享目录下的医疗影像文件,也通过定期压缩备份的方式,确保文件不会丢失和损坏。
其他设计
使用第三方软件的考虑
数据库: MySQL
DICOM:fo-dicom库或dcm4che库
UI控件:PanuonUI.Silver(以能满足设计师要求的UI风格的三方库,根据需要进行增加)
日志:Log4net
数据库访问中间件:Dapper(轻型的ORM框架,高性能,高某某)
治疗报告相关:
PDF三方库:Spire.pdf
二维码和条形码:Spire.Barcode
以上三方库会再项目实际开发中根据最新状况进行调整
系统调试的考虑
通过设置全局调式参数,根据程序需要,在关键点输出调式信息到Log。
可扩展性的考虑
以模块化搭建为基准,可以根据需求增删模块的方式来扩展或变更功能
可维护性的考虑
通过模块化、共XX的设计,规范的注释生成帮助文档来确保程序的可读性和可维护性
参考
需求说明书/式样
[文章尾部最后500字内容到此结束,中间部分内容请查看底下的图片预览]请点击下方选择您需要的文档下载。
以上为《OIS_SW_SystemDesign_Draft_V0.1》的无排版文字预览,完整内容请下载
OIS_SW_SystemDesign_Draft_V0.1由用户“步伐肆意”分享发布,转载请注明出处