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

文章目录

• • 前言
  • 六步走战略
  • • 第0步——嵌软需求：功能/接口/质量/硬件约束/方案约束/数据流
  • 技能一：用例图和用例描述
  • • 第1步——粗粒度分层
    • 第2步——中粒度分模块
    • 第3步——细粒度分ISR/周期仸务/事件驱动任务
  • 技能二：分层，分模块，分子系统
  • • 第4步——分析一个功能的协作链：定义task间通信方式/数据流关系
    • 第5步——分析并发情况下协作链：优化task的并发执行/数据流关系
    • 第6步——分析参与多功能的同一模块：优化模块的通用性/灵活性/可扩展
  • 技能三：Bug工程师，要会找bu?g

前言

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

六步走战略

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

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

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

用例图（Use Case Diagrame）：描述了人们希望如何使用一个系统，将相关用户、用户需要系统提供的服务以及系统需要用户提供的服务更清晰的显示出来，以便使系统用户更容易理解这些元素的用途，也便于开发人员最终实现这些元素。
用例图包括了三方面的内容：1用例，2参与者，3参与者和用例之间的关系。
用例：是对系统的用户需求（主要是功能需求）的描述，用例表达了系统的功能和所提供的服务，描述了活动者与系统交互中的对话。
参与者：参与者是系统外部的一个实体，它以某种方式参与了用例的执行过程，在UML中，通常用名字写在下面的人形图标表示。值得注意的是：参与者不一定是人，也可以是任何的事。
参与者和用例之间的关系：1关联关系，2泛化关系，3包含关系，4扩展关系下面使用亿图软件演示下用例，参与者以及二者之间的关系。
下面这张图 上扣的，是图书馆的用例图(这里画的用例还不完全)：

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

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

第1步——粗粒度分层

第2步——中粒度分模块

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

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

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

这里举一个电梯的例子：

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

第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