软件架构要分层、分模块,具体该怎么做?

道哥分享
关注

一、前言

二、需求调研和需求分析

1. 用例图

2. 用例描述

三、概要设计

1. 针对关键用例,画出鲁棒图

2. 对鲁棒图中的模块进行归类,划分出子系统

四、详细设计

1. 逻辑架构

2. 运行架构

3. 开发架构

五、架构验证

1. 系统框架

2. 技术瓶颈

六、总结

一、前言

在上一篇文章中,我们主要聊了:在嵌入式系统的应用程序架构设计中,应该从哪些方面来进行需求整理和分析。

这篇文章,我们继续聊一下在概要设计、详细设计阶段,我们应该做什么工作?用什么工具或手段来做?输出结果是什么?

按照惯例,为了内容描述的方便,我会用一个物联网网关的设计过程,把所有的内容串接在一起。

二、需求调研和需求分析

1. 用例图

上篇文章说到,在进行需求调研和需求分析的时候,用例图是非常非常好用的一个工具。通过用例图,我们可以把一个系统中需要完成的所有功能,从粗粒度上一目了然的呈现出来。

下面这张图,是网关的用例图(这里画的用例还不完全):

2. 用例描述

用例图仅仅是描述了系统具有的功能,但是并没有描述每一个用例的行为,也就是执行过程。

在上一篇文章中说到,我们不需要对每一个用例进行分析,而是需要在这些用例中,找出那些关键用例,然后对这些关键用例写出用例描述,因为关键用例才是系统架构的决定因素。

那么又出现一个问题了:如果把所有的用例,按照重要程度进行优先级排序,那么从上到下应该选取多少个、或者说百分之多少的关键用例呢?这个就要看整个系统的复杂度了,30%不嫌少,50%不嫌多,根据你的时间自由把握。

以上图网关中的用例图来说,我认为:添加设备、删除设备、控制设备、规则配置、规则触发这几个用例比较关键,因此,我就针对这几个用例写用例描述。

(1)添加设备用例描述

其中有 2 点注意的地方:

在事件流中,我们是把网关作为一个黑盒进行描述的,因为我们是在进行需求分析,而不是在进行设计,因此,不需要考虑网关内部的执行流程;红色部分都是一个执行主体,这个主体可以是一个人、一个界面、一个设备、一个系统等等;

事件流可以用文字来描述(就像图中这样),也可以画一个序列图来展现这个过程,就像下面这样(这里没有详细描述出更细的执行过程,主要以示意性为主):

(2) 删除设备用例描述

(3) 控制设备用例描述

声明: 本文由入驻OFweek维科号的作者撰写,观点仅代表作者本人,不代表OFweek立场。如有侵权或其他问题,请联系举报。
侵权投诉

下载OFweek,一手掌握高科技全行业资讯

还不是OFweek会员,马上注册
打开app,查看更多精彩资讯 >
  • 长按识别二维码
  • 进入OFweek阅读全文
长按图片进行保存