论文多通道设备控制与采集程序.docx
- 文档编号:4710886
- 上传时间:2022-12-07
- 格式:DOCX
- 页数:28
- 大小:157.26KB
论文多通道设备控制与采集程序.docx
《论文多通道设备控制与采集程序.docx》由会员分享,可在线阅读,更多相关《论文多通道设备控制与采集程序.docx(28页珍藏版)》请在冰豆网上搜索。
论文多通道设备控制与采集程序
本科毕业设计论文
题目:
多通道设备控制与采集程序
系别:
计算机系
专业:
计算机科学与技术
班级:
学号:
学生姓名:
指导老师:
摘要
针对嵌入式设备的控制与数据采集过程,用户很难直接对设备进行操控并且操作过程十分繁杂,所以我设计的目的是在计算机上以图形化界面模拟仪表面板,控制设备的工作过程。
不仅能够减轻用户工作负担,更能够提高工作效率,使得用户对于嵌入式设备的操控变得更加的简单,直观。
论文参考了大量的文献探讨了系统的设计思想、开发的关键技术,并具体介绍了包括视图菜单、设置菜单、文件菜单、多通道的设置与操控等多个功能模块的实现。
系统的开发基于MVC架构思想和和ASP.NET技术,使用visualstudio2005中的C#来进行开发工作。
主要是在计算机上做出控制设备的程序的采集过程中,采用序列化/反序列化技术存取采集的数据,将控制信息构建成控制模型。
为用户提供直观的、方便的、个性化的控制界面。
关键词:
控制,数据采集,MVC,ASP.NET技术
目录
摘要
翻译
目录
第1章绪论
1.1
1.2开发背景
1.3本文研究的内容和目标
第2章技术介绍
2.1MVC
2.2序列化与反序列化
第3章需求分析
3.1可行性分析
3.2需求分析
3.3用例及用例图
3.4性能需求分析
第4章概要设计
4.1
第5章系统功能的实践与设计
5.1
结论
致谢
参考文献
第1章绪论
第2章技术介绍
2.1MVC
MVC模式是"Model-View-Controller"的缩写,中文翻译为"模式-视图-控制器"。
MVC应用程序总是由这三个部分组成。
Event(事件)导致Controller改变Model或View,或者同时改变两者。
只要Controller改变了Models的数据或者属性,所有依赖的View都会自动更新。
类似的,只要Controller改变了View,View会从潜在的Model中获取数据来刷新自己。
MVC模式最早是smalltalk语言研究团提出的,应用于用户交互应用程序中。
smalltalk语言和java语言有很多相似性,都是面向对象语言,很自然的SUN在petstore(宠物店)事例应用程序中就推荐MVC模式作为开发Web应用的架构模式。
MVC模式是一种架构模式,其实需要其他模式协作完成。
在J2EE模式目录中,通常采用servicetoworker模式实现,而servicetoworker模式可由集中控制器模式,派遣器模式和PageHelper模式组成。
而Struts只实现了MVC的View和Controller两个部分,Model部分需要开发者自己来实现,Struts提供了抽象类Action使开发者能将Model应用于Struts框架中。
MVC模式是一个复杂的架构模式,其实现也显得非常复杂。
但是,我们已经总结出了很多可靠的设计模式,多种设计模式结合在一起,使MVC模式的实现变得相对简单易行。
Views可以看作一棵树,显然可以用CompositePattern来实现。
Views和Models之间的关系可以用ObserverPattern体现。
Controller控制Views的显示,可以用StrategyPattern实现。
Model通常是一个调停者,可采用MediatorPattern来实现。
现在让我们来了解一下MVC三个部分在J2EE架构中处于什么位置,这样有助于我们理解MVC模式的实现。
MVC与J2EE架构的对应关系是:
View处于WebTier或者说是ClientTier,通常是JSP/Servlet,即页面显示部分。
Controller也处于WebTier,通常用Servlet来实现,即页面显示的逻辑部分实现。
Model处于MiddleTier,通常用服务端的javaBean或者EJB实现,即业务逻辑部分的实现。
2.1.1MVC设计思想
MVC英文即Model-View-Controller,即把一个应用的输入、处理、输出流程按照Model、View、Controller的方式进行分离,这样一个应用被分成三个层——模型层、视图层、控制层。
视图(View)代表用户交互界面,对于Web应用来说,可以概括为HTML界面,但有可能为XHTML、XML和Applet。
随着应用的复杂性和规模性,界面的处理也变得具有挑战性。
一个应用可能有很多不同的视图,MVC设计模式对于视图的处理仅限于视图上数据的采集和处理,以及用户的请求,而不包括在视图上的业务流程的处理。
业务流程的处理交予模型(Model)处理。
比如一个订单的视图只接受来自模型的数据并显示给用户,以及将用户界面的输入数据和请求传递给控制和模型。
模型(Model):
就是业务流程/状态的处理以及业务规则的制定。
业务流程的处理过程对其它层来说是黑箱操作,模型接受视图请求的数据,并返回最终的处理结果。
业务模型的设计可以说是MVC最主要的核心。
目前流行的EJB模型就是一个典型的应用例子,它从应用技术实现的角度对模型做了进一步的划分,以便充分利用现有的组件,但它不能作为应用设计模型的框架。
它仅仅告诉你按这种模型设计就可以利用某些技术组件,从而减少了技术上的困难。
对一个开发者来说,就可以专注于业务模型的设计。
MVC设计模式告诉我们,把应用的模型按一定的规则抽取出来,抽取的层次很重要,这也是判断开发人员是否优秀的设计依据。
抽象与具体不能隔得太远,也不能太近。
MVC并没有提供模型的设计方法,而只告诉你应该组织管理这些模型,以便于模型的重构和提高重用性。
我们可以用对象编程来做比喻,MVC定义了一个顶级类,告诉它的子类你只能做这些,但没法限制你能做这些。
这点对编程的开发人员非常重要。
业务模型还有一个很重要的模型那就是数据模型。
数据模型主要指实体对象的数据保存(持续化)。
比如将一张订单保存到数据库,从数据库获取订单。
我们可
以将这个模型单独列出,所有有关数据库的操作只限制在该模型中。
控制(Controller)可以理解为从用户接收请求,将模型与视图匹配在一起,共同完成用户的请求。
划分控制层的作用也很明显,它清楚地告诉你,它就是一个分发器,选择什么样的模型,选择什么样的视图,可以完成什么样的用户请求。
控制层并不做任何的数据处理。
例如,用户点击一个连接,控制层接受请求后,并不处理业务信息,它只把用户的信息传递给模型,告诉模型做什么,选择符合要求的视图返回给用户。
因此,一个模型可能对应多个视图,一个视图可能对应多个模型。
模型、视图与控制器的分离,使得一个模型可以具有多个显示视图。
如果用户通过某个视图的控制器改变了模型的数据,所有其它依赖于这些数据的视图都应反映到这些变化。
因此,无论何时发生了何种数据变化,控制器都会将变化通知所有的视图,导致显示的更新。
这实际上是一种模型的变化-传播机制。
模型、视图、控制器三者之间的关系和各自的主要功能,如图1所示。
2.1.2MVC设计模式的实现
ASP.NET提供了一个很好的实现这种经典设计模式的类似环境。
开发者通过在ASPX页面中开发用户接口来实现视图;控制器的功能在逻辑功能代码(.cs)中实现;模型通常对应应用系统的业务部分。
在ASP.NET中实现这种设计而提供的一个多层系统,较经典的ASP结构实现的系统来说有明显的优点。
将用户显示(视图)从动作(控制器)中分离出来,提高了代码的重用性。
将数据(模型)从对其操作的动作(控制器)分离出来可以让你设计一个与后台存储数据无关的系统。
就MVC结构的本质而言,它是一种解决耦合系统问题的方法。
2.1.3视图
视图是模型的表示,它提供用户交互界面。
使用多个包含单显示页面的用户部件,复杂的Web页面可以展示来自多个数据源的内容,并且网页人员,美工能独自参与这些Web页面的开发和维护。
在ASP.NET下,视图的实现很简单。
可以像开发WINDOWS界面一样直接在集成开发环境下通过拖动控件来完成页面开发本。
本文中介绍每一个页面都采用复合视图的形式即:
一个页面由多个子视图(用户部件)组成;子视图可以是最简单HTML控件、服务器控件或多个控件嵌套构而成的Web自定义控件。
页面都由模板定义,模板定义了页面的布局,用户部件的标签和数目,用户指定一个模板,平台根据这些信息自动创建页面。
针对静态的模板内容,如页面上的站点导航,菜单,友好链接,这些使用缺省的模板内容配置;针对动态的模板内容(主要是业务内容),由于用户的请求不同,只能使用后期绑定,并且针对用户的不同,用户部件的显示内容进行过滤。
使用由用户部件根据模板配置组成的组合页面,它增强了可重用性,并原型化了站点的布局。
视图部分大致处理流程如下:
首先,页面模板定义了页面的布局;页面配置文件定义视图标签的具体内容(用户部件);然后,由页面布局策略类初始化并加载页面;每个用户部件根据它自己的配置进行初始化,加载校验器并设置参数,以及事件的委托等;用户提交后,通过了表示层的校验,用户部件把数据自动提交给业务实体即模型。
这一部分主要定义了WEB页面基类PageBase;页面布局策略类PageLayout,完成页面布局,用于加载用户部件到页面;用户部件基类UserControlBase即用户部件框架,用于动态加载检验部件,以及实现用户部件的个性化。
为了实现WEB应用的灵活性,视图部分也用到了许多配置文件例如:
置文件有模板配置、页面配置、路径配置、验证配置等。
2.1.4控制器
为了能够控制和协调每个用户跨越多个请求的处理,控制机制应该以集中的方式进行管理。
因此,为了达到集中管理的目的引入了控制器。
应用程序的控制器集中从客户端接收请求(典型情况下是一个运行浏览器的用户),决定执行什么商业逻辑功能,然后将产生下一步用户界面的责任委派给一个适当的视图组件。
用控制器提供一个控制和处理请求的集中入口点,它负责接收、截取并处理用户请求;并将请求委托给分发者类,根据当前状态和业务操作的结果决定向客户呈现的视图。
在这一部分主要定义了HttpReqDispatcher(分发者类)、HttpCapture(请求捕获者类)、Controller(控制器类)等,它们相互配合来完成控制器的功能。
请求捕获者类捕获HTTP请求并转发给控制器类。
控制器类是系统中处理所有请求的最初入口点。
控制器完成一些必要的处理后把请求委托给分发者类;分发者类分发者负责视图的管理和导航,它管理将选择哪个视图提供给用户,并提供给分发资源控制。
在这一部分分别采用了分发者、策略、工厂方法、适配器等设计模式。
为了使请求捕获者类自动捕获用户请求并进行处理,ASP.NET提供低级别的请求/响应API,使开发人员能够使用.NET框架类为传入的HTTP请求提供服务。
为此,必须创作支持System.Web.IHTTPHandler接口和实现ProcessRequest()方法的类即:
请求捕获者类,并在web.config的<httphandlers>节中添加类。
ASP.NET收到的每个传入HTTP请求最终由实现IHTTPHandler的类的特定实例来处理。
IHttpHandlerFactory提供了处理IHttpHandler实例URL请求的实际解析的结构。
HTTP处理程序和工厂在ASP.NET配置中声明为web.config文件的一部分。
ASP.NET定义了一个<httphandlers>配置节,在其中可以添加和移除处理程序和工厂。
子目录继承HttpHandlerFactory和HttpHandler的设置。
HTTP处理程序和工厂是ASP.NET页框架的主体。
工厂将每个请求分配给一个处理程序,后者处理该请求。
例如,在全局machine.config文件中,ASP.NET将所有对ASPx文件的请求映射到HttpCapture类:
<httphandlers>
...
...
</httphandlers>
2.1.5模型
MVC系统中的模型从概念上可以分为两类――系统的内部状态和改变系统状态的动作。
模型是你所有的商业逻辑代码片段所在。
本文为模型提供了业务实体对象和业务处理对象:
所有的业务处理对象都是从ProcessBase类派生的子类。
业务处理对象封装了具体的处理逻辑,调用业务逻辑模型,并且把响应提交到合适的视图组件以产生响应。
业务实体对象可以通过定义属性描述客户端表单数据。
所有业务实体对象都EntityBase派生子类对象,业务处理对象可以直接对它进行读写,而不再需要和request、response对象进行数据交互。
通过业务实体对象实现了对视图和模型之间交互的支持。
实现时把"做什么"(业务处理)和"如何做"(业务实体)分离。
这样可以实现业务逻辑的重用。
由于各个应用的具体业务是不同的,这里不再列举其具体代码实例。
2.1.6MVC设计模式的扩展
通过在ASP.NET中的MVC模式编写的,具有极其良好的可扩展性。
它可以轻松实现以下功能:
1现一个模型的多个视图;
2采用多个控制器;
3当模型改变时,所有视图将自动刷新;
4所有的控制器将相互独立工作。
这就是MVC模式的好处,只需在以前的程序上稍作修改或增加新的类,即可轻松增加许多程序功能。
以前开发的许多类可以重用,而程序结构根本不再需要改变,各类之间相互独立,便于团体开发,提高开发效率。
下面讨论如何实现一个模型、两个视图和一个控制器的程序。
其中模型类及视图类根本不需要改变,与前面的完全一样,这就是面向对象编程的好处。
对于控制器中的类,只需要增加另一个视图,并与模型发生关联即可。
同样也可以实现其它形式的MVC例如:
一个模型、两个视图和两个控制器。
从上面可以看出,通过MVC模式实现的应用程序具有极其良好的可扩展性,是ASP.NET面向对象编程的未来方向。
2.1.7MVC的优点
大部分用过程语言比如ASP、PHP开发出来的Web应用,初始的开发模板就是混合层的数据编程。
例如,直接向数据库发送请求并用HTML显示,开发速度往往比较快,但由于数据页面的分离不是很直接,因而很难体现出业务模型的样子或者模型的重用性。
产品设计弹性力度很小,很难满足用户的变化性需求。
MVC要求对应用分层,虽然要花费额外的工作,但产品的结构清晰,产品的应用通过模型可以得到更好地体现。
首先,最重要的是应该有多个视图对应一个模型的能力。
在目前用户需求的快速变化下,可能有多种方式访问应用的要求。
例如,订单模型可能有本系统的订单,也有网上订单,或者其他系统的订单,但对于订单的处理都是一样,也就是说订单的处理是一致的。
按MVC设计模式,一个订单模型以及多个视图即可解决问题。
这样减少了代码的复制,即减少了代码的维护量,一旦模型发生改变,也易于维护。
其次,由于模型返回的数据不带任何显示格式,因而这些模型也可直接应用于接口的使用。
再次,由于一个应用被分离为三层,因此有时改变其中的一层就能满足应用的改变。
一个应用的业务流程或者业务规则的改变只需改动MVC的模型层。
控制层的概念也很有效,由于它把不同的模型和不同的视图组合在一起完成不同的请求,因此,控制层可以说是包含了用户请求权限的概念。
最后,它还有利于软件工程化管理。
由于不同的层各司其职,每一层不同的应用具有某些相同的特征,有利于通过工程化、工具化产生管理程序代码。
2.1.8MVC的不足
MVC的不足体现在以下几个方面:
1增加了系统结构和实现的复杂性。
对于简单的界面,严格遵循MVC,使模型、视图与控制器分离,会增加结构的复杂性,并可能产生过多的更新操作,降低运行效率。
2视图与控制器间的过于紧密的连接。
视图与控制器是相互分离,但确实联系紧密的部件,视图没有控制器的存在,其应用是很有限的,反之亦然,这样就妨碍了他们的独立重用。
3视图对模型数据的低效率访问。
依据模型操作接口的不同,视图可能需要多次调用才能获得足够的显示数据。
对未变化数据的不必要的频繁访问,也将损害操作性能。
4目前,一般高级的界面工具或构造器不支持MVC模式。
改造这些工具以适应MVC需要和建立分离的部件的代价是很高的,从而造成使用MVC的困难。
2.2序列化与反序列化
序列化就是将我们程序中的对象通过字节流写入存储媒体或网络流中。
反序列化就是把已存入的媒体或接收的网络流中的内容转换成程序运行中的对象。
这两个过程结合起来,可以轻松地存储和传输数据。
使用序列化场景:
1在用户登录后,对界面作一些个性化设置(如:
背景色、布局、字体等),为了使用户关闭网页后能够保留设置,以便在下次登录时再加载上次的设置。
我们可以将用户的设置信息保存在一个对象中,然后把该对象序列化保存在表的某个字段中,在加载网页的时候取出字段中的信息,并反序列化生成设置对象,应用到用户界面上。
2对用户的一些不用作查询的信息(如:
住址、Email、家庭成员、工作经历等)序列化后保存在一个表的字段中,在需求发生变化时(如增加用户新的信息),不用动态增加字段。
在需要使用的时候,取出字段中的的信息反序列化成对象就可以了。
3在点对点两人聊天系统中,一个用户输入的内容(如:
彩色文字、图片等)后显示输入时的内容和样式,另一个用户界面中也应当显示同样的内容和样式。
这时我们可以把用户输入的内容(如:
彩色文字、图片等)封装为一个对象,然后序列化到二进制网络流中去,在另一端,取出二进制流并反序列化成对象,然后显示在界面上。
.NETFramework提供两种序列化技术:
二进制序列化:
System.Runtime.Serialization.Formatters.Binary;
XML序列化:
System.Runtime.Serialization.Formatters.Soap;须要加载(引用)对应的DLL文件。
二进制序列化的保真度非常强,可以把私有成员变量序列化到流中去。
XML序列化只可以把公有成员变量序列化到流中去,私有成员变量无法被序列化,但如果私有成员变量有对应的公有属性的话,那私有成员变量照样可以被序列化。
要使某个类的对象可以被序列化,必须要在类的前面加上[Serializable]属性,否则会产生异常。
如果要对子类进行序列化,那必须要保证其父类也具有[Serializable]属性。
如果有类中有一个成员变量是个对象,那也要保证该成员对象的类具有[Serializable]属性,否则也会抛出异常。
序列化的应用:
1.永久性保存对象,保存对象的字节序列到本地文件中;
2.通过序列化对象在网络中传递对象;
3.通过序列化在进程间传递对象。
序列化(serialization)
将对象的状态信息转换为可以存储或传输的窗体的过程。
在序列化期间,对象将其当前状态写入到临时或持久性存储区。
以后,可以通过从存储区中读取或反序列化对象的状态,重新创建该对象。
序列化使其他代码可以查看或修改那些不序列化便无法访问的对象实例数据。
确切地说,代码执行序列化需要特殊的权限:
即指定了SerializationFormatter标志的SecurityPermission。
在默认策略下,通过Internet下载的代码或Intranet代码不会授予该权限;只有本地计算机上的代码才被授予该权限。
通常,对象实例的所有字段都会被序列化,这意味着数据会被表示为实例的序列化数据。
这样,能够解释该格式的代码有可能能够确定这些数据的值,而不依赖于该成员的可访问性。
类似地,反序列化从序列化的表示形式中提取数据,并直接设置对象状态,这也与可访问性规则无关。
对于任何可能包含重要的安全性数据的对象,如果可能,应该使该对象不可序列化。
如果它必须为可序列化的,请尝试生成特定字段来保存不可序列化的重要数据。
如果无法实现这一点,则应注意该数据会被公开给任何拥有序列化权限的代码,并确保不让任何恶意代码获得该权限。
序列化
序列化是将对象状态转换为可保持或传输的格式的过程。
与序列化相对的是反序列化,它将流转换为对象。
这两个过程结合起来,可以轻松地存储和传输数据。
序列化的目的:
1、以某种存储形式使自定义对象持久化;
2、将对象从一个地方传递到另一个地方。
.NETFramework提供两种序列化技术:
1二进制序列化保持类型保真度,这对于在应用程序的不同调用之间保留对象的状态很有用。
例如,通过将对象序列化到剪贴板,可在不同的应用程序之间共享对象。
您可以将对象序列化到流、磁盘、内存和网络等等。
远程处理使用序列化“通过值”在计算机或应用程序域之间传递对象。
2XML序列化仅序列化公共属性和字段,且不保持类型保真度。
当您要提供或使用数据而不限制使用该数据的应用程序时,这一点是很有用的。
由于XML是一个开放式标准,因此,对于通过Web共享数据而言,这是一个很好的选择。
SOAP同样是一个开放式标准,这使它也成为一个颇具吸引力的选择。
第3章需求分析
3.1可行性分析
3.1.1背景说明
随着工业化的实现,信息化的到来,我们开始进入知识经济的新时代。
创新是这个时代的源动力。
文化的创新、观念的创新、科技的创新、体制的创新改变着我们的今天,并将改造我们的明天。
新旧文化、新旧思想的撞击、竞争,不同学科、不同技术的交叉、渗透,必将迸发出新的精神火花,产生新的发现、发明和物质力量。
嵌入式技术就是在这样的规律和环境中诞生和发展的。
科技创新带给社会与人类的利益远远超过它的危险。
机器人的发展史已经证明了这一点。
嵌入式的应用领域不断扩大,从工业走向农业、服务业;从产业走进医院、家庭;从陆地潜入水下、飞往空间......。
然而对于嵌入式得大中下型设备来说,人们要是想直接通过硬件设施或者从设备本身上对其进行直接的控制或是数据采集,必定会是一件相当复杂和繁琐的操作过程。
根据设备的安装地点和其他各种因素来讲,也不是很容易实现的。
故针对这种现状,我们便根据客户的需求开发了这套多通道设备控制与采集程序应用软件。
让客户不需要再直接接触大中小型设备,就可以在办公室里通过计算机设备,便能轻松方便的对嵌入式设备进行操控和数据采集等一系列操作。
3.1.2可行性分析
该系统要利用MVC模式进行开发,所以技术难点主要有两个。
其一是如何利用MVC手段去耦合M-V即模型与视图,其二是如何防止外部设备的变化引起视图比较大的变化。
由于MVC架构的模型是自包含的,并且与控制器和视图相分离,所以很容易改变应用程序的数据层和业务规则。
一旦正确的实现了模型,不管数据来自数据库或是LDAP服务器,视图将会正确的显示它们。
由于运用MVC的应用程序的三个部件是相互独立,改变其中一个不会影响其它两个,所以依据这种设计思想能构造良好的松耦合的构件。
这就可以解决上述两个难点。
所以利用MVC架构的思想来完成该系统的开发是可行的。
通过使用C#.NET技术利用MVC三层构架思想创建一个模型,并在模型中利用序列化/反序列化技术完成文件的打开,保存。
系统设置中的时间范围、同步设置、输出设置和硬件设置的功能。
在使用这些功能时提供可以给予比较完美的支持,反应准确迅速。
可以准确的实现反序列化的打开及序列化的保存。
设置时通过各个不同的设置可以控制界面通道的功能正常准确实现,并保证数据的完整和正确。
该程序系统主要是用来大型设备的多通道数据的采集和保存。
3.2需求分析:
本课题研究嵌入式设备的控制与数据采集过程,主要任务在计算机上做出控制设备的程序的图形化界面,在主窗体的视图中以全波方式为例,在计算机上以图形化界面模拟仪表面板,控制设备的工作过程对数据进行序列化/反序列化存取。
利用MVC架构思想,使用visualstudio2005中的C#
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 论文 通道 设备 控制 采集 程序