DDDDS(Driver Dangerous Deeds Detect System)危险驾驶检测APP。
预期功能：驾驶员将APP打开对准自己的面部，APP可在驾驶员有危险驾驶行为时告警。
目前主要完成了架构设计文档，开发没时间做了。另外吐槽一下halo对md的集成做的不好，我目前不能很好地在网站上展示文档，所以附一个下载链接。DDDDS文档pdf包.zip
# 需求文档
## 功能
DDDDS(Driver Dangerous Deeds Detect System)，中文名为“驾驶员危险行为检测系统”，是一个能运行于Android7及以上系统的APP。其主要功能是通过设备摄像头采集的信息实时检测驾驶员的危险驾驶行为，在检测到后及时提醒驾驶员。危险驾驶行为包括：不系安全带，疲劳驾驶和注意力不集中。其中“注意力不集中”涵盖了清醒状态下驾驶员的大部分危险驾驶行为，比如长时间交谈和打电话。
此APP**特别针对单人长时间连续驾驶情形**，在减少事故发生率上预期有不小的意义。
此APP的利益相关方简单，只有开发者和驾驶员（用户）。
## 质量
### 质量属性及解释
|优先级（递减）|质量需求|说明|
|:---:|:---:|:---|
|1|易用|界面简单直观，少交互，多反馈，自定义程度低|
|2|实时|如检测到危险驾驶行为，提醒需在0.5s内发出|
|3|可用|如因各种原因系统发生故障，短时间内能自我修复|
|4|可靠|系统能够长时间稳定运行（不小于24h）|
|5|可复用|易于集成进其他软件或系统|
|6|轻量|低资源占用|
|7|数据安全|使用用户数据的时候不泄露数据|
|8|可拓展|未来可能添加云模块及其他业务|
***
所有质量属性中，实现**前四个**是开发的主要目标。原因如下。
此APP面向的主要群体是有着长期单人长途驾驶工作的用户。他们可能不熟悉手机的使用，对新软件的理解和学习能力的下限低，所以易用是首要质量需求。其次，如发生危险驾驶行为，如疲劳驾驶，关键时间可能只有几秒中，过去之后再提醒意义就不大了，所以实时性十分重要。然后就是可用和可靠。此APP好像就是一个照看这用户的哨兵，主要作用是在用户比如说不小心睡着的时候进行提醒，那么保证这个“哨兵”不“睡着”就是关键。
现对后四个质量属性进行解释。
此APP的功能太过于少了，所以考虑到现实实践，此APP的发展方向应是一个小组件，能集成进各种大系统中，可复用就很重要。轻量和数据安全很好理解。此文档编写时，计划用户数据不联网上传。但是考虑到未来可以通过用户的个性化数据提升检测精度，数据安全和可拓展性就较为重要。
### 重要属性的质量场景
#### 易用
- 刺激源：驾驶员
- 刺激：理解力低、学习能力低
- 制品：系统
- 环境：正常操作下
- 响应：界面按钮简介、功能明确；界面加载速度快
- 响应度量：Android界面可交互控件的总个数
#### 实时
- 刺激源：驾驶员
- 刺激：做出危险驾驶行为
- 制品：系统
- 环境：正常操作下
- 响应：提醒驾驶员
- 响应度量：检测反馈时间小于0.5s
#### 可用
- 刺激源：系统内部或者用户的操作系统
- 刺激：检测提醒功能失效
- 制品：系统
- 环境：系统故障
- 响应：检测故障原因，尝试自动修复，给出提示
- 响应度量：故障持续时间（从发生故障到给出提示）小于3s，提升信息充足
#### 可靠
- 刺激源：驾驶员
- 刺激：长时间使用
- 制品：系统
- 环境：正常操作下
- 响应：稳定运行时间
- 响应度量：不小于24h，在系统资源不足以支持APP运行24h时给出提示
## 约束条件
- 团队只有一个人
- 时间只有两周左右
- 开发者对开发所需的技术不熟悉
- 用户的学习、操作能力低
# 架构设计文档
## 参考模型
1. 编译器
## 参考构架
1. 分层架构
>应用层(Application Layer)
├── 界面管理（摄像头预览、警报显示）
├── 用户设置（灵敏度调整）
└── 数据记录（本地存储危险事件）
>
>业务逻辑层(Business Logic Layer)
├── 行为分析引擎
├── 警报管理模块
└── 数据预处理管道
>
>AI推理层(AI Inference Layer)
├── 视觉模型管理
├── 模型调度器
└── 计算资源分配
>
>硬件抽象层(Hardware Abstraction Layer)
├── 摄像头控制
├── 传感器数据采集
└── 硬件加速管理
## 框架和设计模式
框架：无。
设计模式：生产者-消费者模式+观察者模式
生产者：以固定帧率从摄像头捕获图像。
消费者：使用AI模型分析生产者生产的图像。
观察者：观察生产者和消费者的状态，做其他工作。
## 架构设计
### 模块分解视角
这个视角用模块，不断将系统分解。
#### 整体架构
架构样式：
为了实时性和可复用、可拓展需求，采用数据流样式中的管道-过滤式样式。对于每一个图像输入，从数据源到数据目的地的过程必须在0.5s内完成，以保证实时性。
监测和修复模块实现可用性需求，使用异常战术。
系统资源监控模块实现可靠性需求，使用回声战术进行检测。
***
#### 数据分析与反馈模块
***
#### 危险驾驶分析模块
***
#### 提醒模块
提醒模块学习了“发布、预定架构”，便于实现可复用和可拓展需求。
### 界面视角
为了实现“易用性”需求，需要设计界面。
在用户使用系统的每一刻，都提供明确的路线和尽量少的选择。
# 架构评审文档
## 成本与收益
完成完整的架构成本高。
收益也高。收益大于成本。
## ATAM评审
### 商业动机
此APP依赖AI模型，在商业上存在限制。
此APP的商业目标是找到一套稳定易用、实时性高的框架。
### 有风险决策和无风险决策
1. 系统检测模块的加入满足了可靠的质量场景，但在低资源占用上有风险。
2. 简洁界面满足了易用的质量场景，但在可扩展上有风险，简单来说就是前端结构过于简单，如果系统变复杂可能难以组织。
3. 管道-过滤式样式的采用满足了实时的质量场景，在所有样式中它是最合适的，无风险。
4. 设计系统监测与修复模块满足了可用的质量场景，但在开发实践中没有足够的经验，有一定风险。
logo标志：
假想图
