我偶然发现了一个free state machine tool。这似乎是为了以图形方式对嵌入式系统进行编程。通过这样做,作者声称所产生的代码比使用RTOS时更容易维护。这个工具是基于UML的,这是很好知道的,但是有一个陡峭的学习曲线。
我想知道这里一些更有经验的程序员是如何看待这个工具的。
我正在为LM3S5P36微控制器开发一个嵌入式应用程序。TI有一个叫做Code Composer Studio (CCS)的IDE。我还没有进入CCS,但我怀疑它是否有一个很酷的特性,即能够将所需的行为输入到状态机图表中,旋转曲柄,并弹出C或C++代码。然后返回并编辑图表以生成相应的修改后的代码。我用C语言编写过微控制器程序,但对UML几乎一无所知。在过去,我维护了两个文件,一个是微控制器代码,另一个是流程图。每次代码修订都意味着要维护两个独立的文件。
所以我的两难境地是:我发现了这个很酷的图表到代码的一体化文档工具,我很想使用它,但更重要的是,我只想完成我的项目。我是按老方法做呢,还是花几周时间学习UML?
发布于 2011-08-21 08:46:39
您可能还会对Miro Samek的书"Practical UML Statecharts in C/C++“感兴趣。请注意,Miro是Quantum Leaps的创始人和总裁,因此本书与该工具齐头并进。
Miro似乎在状态图开发上投入了大量资金,而不是RTOS开发,他写了这本书,并在这个主题上发表了大量的博客。他在LinkedIn的实时嵌入式工程小组上发起了题为"Is an RTOS really the best way to design embedded systems?“的帖子-那里有很多关于这个主题的意见!
我不确定这两者是否一定是不同的;将单独的RTOS线程实现为状态机通常很有用(而且经常这样做)。他在他的博客"I Hate RTOSes,但他的推理在很大程度上是基于糟糕的应用程序设计而不是实时操作系统技术本身。正如C或C++在不明智的使用时可能是危险的,实时操作系统也是如此。我通常看到的是线程太少,内聚力和紧密耦合都很差,但我相信米罗一想到解决方案是更多的线程就会撕裂他的头发!“
UML2.2指定了14种类型的图,状态机只是其中的一种,因此不需要学习整个UML。在这种情况下使用它是因为它是一个定义良好的模型,具有清晰的语法和语义,适合定义行为细节。状态机图(或状态图)可能是最容易理解的UML行为图,并且在所有UML图中具有最清晰定义的语义。
发布于 2011-08-19 08:24:36
我没有尝试过这个工具,但是如果你得到UML图,那么它对你的项目文档来说总是更好的。使用类图从UML生成代码现在已经很好了,我想其他图也是一样的。
发布于 2011-09-21 18:30:45
在http://www.StateSoft.org上提供了一种可能满足您需求的方法,它使用非常小但功能完整的UML子集-如果您查看状态机图库中的图形化API集,您将在几分钟内直观地了解所需的UML符号子集。为了提高嵌入式系统内存的使用效率,产生了高度优化的表。根据您使用的是C还是C++,您可以选择紧凑表执行器。
https://stackoverflow.com/questions/7116881
复制相似问题