菜鸟应该如何开始设计一个项目的嵌入式软件架构

前言

CSDN，GIT等各大论坛上很多文章都有讲，如何设计项目的嵌入式软件架构，But门槛实在太高了，需要做需求调研，需求分析，概要设计，详细设计，架构验证，开发-单元测试，集成测试等等，实不相瞒这些没有半年八载的项目经验根本做不出来的，刚好经过这周的嵌入式架构培训，提炼下最近在做项目的嵌入式软件架构的设计经验吧，不喜勿碰，谢谢。

六步走战略

第0步——嵌软需求：功能/接口/质量/硬件约束/方案约束/数据流

技能一：用例图和用例描述

Q:需求如何转换成软件框架
A:画用例图，写用列描述

用例图（Use Case Diagrame）：描述了人们希望如何使用一个系统，将相关用户、用户需要系统提供的服务以及系统需要用户提供的服务更清晰的显示出来，以便使系统用户更容易理解这些元素的用途，也便于开发人员最终实现这些元素。
用例图包括了三方面的内容：1用例，2参与者，3参与者和用例之间的关系。
用例：是对系统的用户需求（主要是功能需求）的描述，用例表达了系统的功能和所提供的服务，描述了活动者与系统交互中的对话。
参与者：参与者是系统外部的一个实体，它以某种方式参与了用例的执行过程，在UML中，通常用名字写在下面的人形图标表示。值得注意的是：参与者不一定是人，也可以是任何的事。
参与者和用例之间的关系：1关联关系，2泛化关系，3包含关系，4扩展关系下面使用亿图软件演示下用例，参与者以及二者之间的关系。
下面这张图网上扣的，是图书馆的用例图(这里画的用例还不完全)：
为什么要画用例图，而不是UML，状态机这些专业的语言用图，其实最重要的一点就是产品想做好就必须站在客户的角度思考问题，在产品需求分析阶段就要开始为上帝考虑，等到设计阶段再来思考用户体验就为时已晚，产品基本也就失败了。

用例描述：用例图仅仅是描述了系统具有的功能，但是并没有描述每一个用例的行为，也就是执行过程。
我们不需要对每一个用例进行分析，而是需要在这些用例中，找出那些关键用例，然后对这些关键用例写出用例描述，因为关键用例才是系统架构的决定因素。

Q：关键用例如何分析？。
A: 抓住功能/接口/质量/硬件约束/方案约束/数据流这几个方面来思考。
功能：产品最关键的因素，以实现的功能来展开用例
接口：硬件接口是实现功能的方式，软件接口决定层间接口的好坏
质量：提高产品竞争里的核心
硬件约束：决定底层驱动的复杂程度
方案约束：高内聚，低耦合的前提
数据流：拿捏代码逻辑的最好方法
下面也是从网络上找的用例描述示例，可以看到并没有统一的格式，需要根据项目的性质进行增减。

Q:假设我们在不断的搜集和分析中，尽可能地列出了所有的需求(功能需求、质量属性、条件约束)，下一步需要做什么呢？需求这么多，该从哪一个需求入手呢？

A:关键需求 = 关键功能 + 关键质量。它确定了架构的大方向。

第1步——粗粒度分层

第2步——中粒度分模块

第3步——细粒度分ISR/周期仸务/事件驱动任务

技能二：分层，分模块，分子系统

Q:如何将需求阶段的用例图和用例描述，转换成代码
A:分层，分模块，分子系统

这里举一个电梯的例子：

分层：这里的分层是指软件代码的层次结构，并不是电梯的楼层哟，请看下图
底层库，驱动，HAL，服务层，功能层，用户层等，我们需要的是在第0步种对用例描述的功能，接口，硬件，约束等进行总结，提炼出我们需要做的驱动，服务和用户接口。
这里安利一种思维是“洋葱皮”分层模式：上层调用下层，下层不能调上层。入口组装func模块，func组装下层模块。如下图所示：

在分层上的体现就是如下图所示：

分模块：一句话按功能划分模块，电梯这个项目有几个功能就划分几个模块，以下对移动功能列出一个模块：
项目的设计过程种，由着诸多的需求。而很多需求都可以进行归类，根据功能需求的方法进行模块的划分。可以让需求在归类上得到明确的划分，而且通过功能需求进行软件的模块划分使得功能分解，任务分配等方面都有较好的分解。不知道大家发现没其实分模块阶段就进行了ISR/周期仸务/事件驱动任务的设计。
如果一个项目大家分析到这里是不是大概觉得自己知道写哪些代码了，接下来就是将模块连接起来，形成软件的骨架。

分子系统：
Q:子系统如何分
A:纵深封装
什么叫纵深封装，意思就是形成跨层子系统，func层模块，封装drv模块，子系统接口公开，接口粒度大，所以松耦合
在分层上的体现就是：
子系统在分层上的体现就是：
到这里设计完每个子系统之后，层层递进，层组成模块，模块细化层，子系统连接模块，模块递进成子系统。

到这里基本软件的框架就能设计出来，具体的模块封装，任务并发，模块接口这些就看个人道行了。

第4步——分析一个功能的协作链：定义task间通信方式/数据流关系

第5步——分析并发情况下协作链：优化task的并发执行/数据流关系

第6步——分析参与多功能的同一模块：优化模块的通用性/灵活性/可扩展

以上3步是大佬总结的bug的3个方向，想要有一个稳定的系统，这3步是必须做的，其实我把他们统称为Bug，简而言之我们就要要有发现Bug的能力。

技能三：Bug工程师，要会找bu g

这里提供几种找Bug的方法：
1：SystemView分析工具：rtthread的systemview分析工具
2：CmBacktrace：ARM Cortex-M 系列 MCU 错误追踪库
3：Pc-lint:静态代码检查工具
生命不止，BUG不止。发现好的bug工具再来补充。

后续步——5、 6循环，不断优化。但若发现架构大缺陷，回溯到1-2-3-4

经过这次的架构培训，我基本上把自己在平常工作中，对应用程序架构设计的这个思考过程描述了一遍。

佛经里说了：凡是回归原点，不懂就不懂，努力学习。懂了也要相信人外有人，放下架子，谦虚，能力提升方可最大化。

这篇文章介绍的设计流程，也是一个套路而已。这个套路在面对一个新领域、新项目时，就像一个脚手架一样，告诉我们这一步该做什么，下一步该做什么，应该使用什么样的工具。

在僵化的运用这个套路之后，你可以继续改造、优化，然后丢掉这个套路，从而形成适合你自己的套路，从此走向思考致富的道路！

GOOD LUCK