Labview项目框架(一)概述

零、文章初衷

          本系列文章针对中小项目，介绍基于labview的软件架构搭建方法，希望可以帮助到同行的朋友。

          本人是自动化专业出身，因此本文主要是在自动化行业的应用，但是软件架构行业通用，也希望得到同行的朋友指正。

一、项目需求

          做项目最重要是项目需求。在行业里见到很多刚入行的朋友，一进到公司就急着看程序，急着畅游在充满创意的软件海洋中。这点固然是错的，所谓程序未动，需求先行。就算是看别人的程序，也需要知道这个项目在做什么，带着项目需求去找功能块对成长更有帮助。本文会先假设一个不存在的需求，来展开分享。

二、软件层面

          假设我们现在要设计一个窗口应用程序。

   针对窗口应用程序来说，一般是以下这4个步骤：

1、初始化：①界面初始化；②参数初始化

2、手动功能：①手动界面；②单元测试；③功能测试；④保存功能

3、自动功能：①自动界面；②功能逻辑拼接；②错误处理；

4、释放资源：①关闭界面；

三、拓展性

          一个程序在项目完成的基础下，尽量要考虑其可拓展性。

          就是尽量不要将功能写死，写固定。

          客户说了针对两个产品，不能只写两个产品，要考虑到产线的柔性化换型。

          那么问题来了，假如两个产品都实现大部分同样的功能，而小部分定制化怎么办。

          这里就要强调重用性了，假如写了一个vi是面向过程，代码的重写量的大幅增加了。

          比如说写一个串口扫码功能，过程是打开串口->读写串口->关闭串口，如果有多个串口的话，拉多几个扫码.vi，也能解决这部分问题。

          但是另一个问题随之而来，串口中途断开的话，要实现重连，里面有循环的话，怎么办？将扫码.vi改为可重入副本也能解决这部分问题。

          但是如果换了一个牌子的扫码器呢？尽管用的是串口，但是发送的字符不一样，难道把原有的扫码.vi复制一部分的代码过来修改吗？不然，这里可以用labview的面向对象编程lvoop。在本系列文章的后半部分会讲解。

四、后语

          可以看出前三点没有太多纯理论的东西，都是建立于自动化项目中的一系列应用。这系列文章就是基于项目应用的，希望能从另一个视觉来解读labview框架。