软件架构要分层、分模块，具体该怎么做？
一、前言
二、需求调研和需求分析
1． 用例图
2． 用例描述
三、概要设计
1． 针对关键用例，画出鲁棒图
2． 对鲁棒图中的模块进行归类，划分出子系统
四、详细设计
1． 逻辑架构
2． 运行架构
3． 开发架构
五、架构验证
1． 系统框架
2． 技术瓶颈
六、总结
一、前言
在上一篇文章中，我们主要聊了：在嵌入式系统的应用程序架构设计中，应该从哪些方面来进行需求整理和分析。
这篇文章，我们继续聊一下在概要设计、详细设计阶段，我们应该做什么工作？用什么工具或手段来做？输出结果是什么？
按照惯例，为了内容描述的方便，我会用一个物联网网关的设计过程，把所有的内容串接在一起。
二、需求调研和需求分析
1． 用例图
上篇文章说到，在进行需求调研和需求分析的时候，用例图是非常非常好用的一个工具。通过用例图，我们可以把一个系统中需要完成的所有功能，从粗粒度上一目了然的呈现出来。
下面这张图，是网关的用例图（这里画的用例还不完全）：
2． 用例描述
用例图仅仅是描述了系统具有的功能，但是并没有描述每一个用例的行为，也就是执行过程。
在上一篇文章中说到，我们不需要对每一个用例进行分析，而是需要在这些用例中，找出那些关键用例，然后对这些关键用例写出用例描述，因为关键用例才是系统架构的决定因素。
那么又出现一个问题了：如果把所有的用例，按照重要程度进行优先级排序，那么从上到下应该选取多少个、或者说百分之多少的关键用例呢？这个就要看整个系统的复杂度了，30％不嫌少，50％不嫌多，根据你的时间自由把握。
以上图网关中的用例图来说，我认为：添加设备、删除设备、控制设备、规则配置、规则触发这几个用例比较关键，因此，我就针对这几个用例写用例描述。
（1）添加设备用例描述
其中有 2 点注意的地方：
在事件流中，我们是把网关作为一个黑盒进行描述的，因为我们是在进行需求分析，而不是在进行设计，因此，不需要考虑网关内部的执行流程；红色部分都是一个执行主体，这个主体可以是一个人、一个界面、一个设备、一个系统等等；
事件流可以用文字来描述（就像图中这样），也可以画一个序列图来展现这个过程，就像下面这样（这里没有详细描述出更细的执行过程，主要以示意性为主）：
（2） 删除设备用例描述
（3） 控制设备用例描述
分享
图片新闻
最新活动更多
-
11月28日立即报名>>> 2024工程师系列—工业电子技术在线会议
-
11月29日立即预约>> 【上海线下】设计，易如反掌—Creo 11发布巡展
-
11月30日立即试用>> 【有奖试用】爱德克IDEC-九大王牌安全产品
-
即日-12.5立即观看>> 松下新能源中国布局：锂一次电池新品介绍
-
12月19日立即报名>> 【线下会议】OFweek 2024（第九届）物联网产业大会
-
即日-12.26火热报名中>> OFweek2024中国智造CIO在线峰会
发表评论
请输入评论内容...
请输入评论/评论长度6~500个字
暂无评论
暂无评论