手把手教你怎样去实现一个嵌入式软件架构的设计

1118 嵌入式嵌入式软件架构

问答对人有帮助，内容完整，我也想知道答案 0 手把手教你怎样去实现一个嵌入式软件架构的设计？有哪些步骤及其要求呢？ 0
2021-12-24 06:54:50　　评论淘帖0 邀请回答您可以邀请以下用户，快速回答问题 × ChristineGu 该类别下有 16 个回答。邀请回答 HengDu 该类别下有 16 个回答。邀请回答 heks 该类别下有 16 个回答。邀请回答 dfasda 该类别下有 15 个回答。邀请回答 nhonglan 该类别下有 15 个回答。邀请回答 yonglanzhang 该类别下有 15 个回答。邀请回答杀狼000 该类别下有 14 个回答。邀请回答 wenminglang 该类别下有 14 个回答。邀请回答 C880U 该类别下有 14 个回答。邀请回答 jhdfvs 该类别下有 14 个回答。邀请回答 chm5 该类别下有 14 个回答。邀请回答 muwersddg 该类别下有 14 个回答。邀请回答 hrtuoyu 该类别下有 13 个回答。邀请回答 hfgdzc 该类别下有 13 个回答。邀请回答 thyysbk 该类别下有 13 个回答。邀请回答凡人wlj 该类别下有 13 个回答。邀请回答 kszdj113 该类别下有 13 个回答。邀请回答飞雪9366 该类别下有 13 个回答。邀请回答 billbian 该类别下有 13 个回答。邀请回答 a732538 该类别下有 13 个回答。邀请回答举报马刺牛逼相关推荐 • 手把手教你如何去安装Keil C51软件？ 1449 • 手把手教你怎样从ST官网获取标准外设库以及官方例程 1649 • 手把手教你学习STM32 1819 • 手把手教你学FPGA设计与应用 1751 • 手把手教你怎样去编译NodeMCU固件呢 1192 • 手把手教你如何去开发一种51单片机？有哪些步骤 1199 • 谁有手把手教你dsp28335案例 5929 • 手把手教你如何复制PCB线路板 5587 • 手把手教你学arm-stm32高级篇 8233 • 手把手教你学电源电路的PCB排版 22288 1个回答

答案对人有帮助，有参考价值 0 六步走战略第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分析工具 2：CmBacktrace 3：Pc-lint 生命不止，BUG不止。发现好的bug工具再来补充。后续步——5、 6循环，不断优化。但若发现架构大缺陷，回溯到1-2-3-4 经过这次的架构培训，我基本上把自己在平常工作中，对应用程序架构设计的这个思考过程描述了一遍。佛经里说了：凡是回归原点，不懂就不懂，努力学习。懂了也要相信人外有人，放下架子，谦虚，能力提升方可最大化。这篇文章介绍的设计流程，也是一个套路而已。这个套路在面对一个新领域、新项目时，就像一个脚手架一样，告诉我们这一步该做什么，下一步该做什么，应该使用什么样的工具。在僵化的运用这个套路之后，你可以继续改造、优化，然后丢掉这个套路，从而形成适合你自己的套路，从此走向思考致富的道路！

2021-12-24 15:38:53 评论举报刘建国