2009年1月6日

1 工作内容小结

10月中旬我开始处理XXXX的相关工作，到目前为止，主要完成了如下的工作：

....

(这里的部分我省略了，但是为了文章的完整我还是保留的这个小节)

2 工作编程总结

l 系统架构

对于每个工程，采用了通用的三层的架构，即数据层、业务逻辑层和界面层。在遵循此架构下，在多工程情况下，为了调试方便，在各个工程内部采取三层架构，在业务逻辑层，采用复用用户控件的方式，达到软件代码复用，减少了代码的维护。对于三层都需要使用的部分或者各个工程都需要使用的部分，采用dll类库的方式公用出来。

l 代码重构与OO 应用

在编写XX10-1 软件中，由于编目管理、辅助数据分离和产品生产管理在界面上的功能基本上都相同，所以对于此可以采用OO的设计思想，定义一个共有类(此类完成了比如修改订单状态、克隆订单和订单查看等大部分功能)，然后三个都继承此类完成所有的功能，然后只需要针对不同的订单进行界面上的数据库的数据重新绑定即可，当维护的时候，大部分只需要维护这个基类就可以了。

在编写的过程中，实时的进行代码重构，把一些能够公用的或者重复的内容提取和改写，减少后期代码的维护量。

l 多进程化

采用多进程保证了：

Ø 各个程序之间的效率

Ø 为了使打开多个界面并且这些界面之间并不互相影响，一旦一个界面程序死掉，那么其它的程序可以继续使用。采用多进程可以保证这点。

Ø 保证在图像FTP下载过程中，同时可以进行主程序的其它操作

多进程化主要使用在产品图像下载、编目订单管理界面、辅助数据分离界面和产品生产管理界面等地方。

l 变化和性能驱动

     在软件开发的过程中，软件的变化是比较麻烦的事情，但是软件却又是根据用户的需求经常变化的，对于此，需要在软件设计和实现的过程中，充分考虑到软件变化，故在软件实现和设计过程中，采用变化驱动的方式，充分考虑软件可能的变化情况，并对此做出设计或实现上的预留。

     软件设计、实现复杂度和软件实现时间在考虑软件的变化的情况下是一对矛盾体，为了满足用户的需求，我们通常需要在软件设计、实现复杂度和软件实现时间之间做出取舍。

l 核心代码和公用代码的处理

     对于软件中的核心和公用代码需要详细的考虑和多次测试，确保核心和公用代码没有问题；多个工程中和多个人员共同使用的代码确定一个稳定版本，使用其版本，对于公用代码的需要变化的内容，在后续的版本稳定后才使用。

3 工作方式总结

l 工作日志处理

在开发的过程中，自己慢慢养成了一个习惯，就是对于每天的工作内容都做了记录，每天开发的一些小的工作内容都被我详细的记录下来，并且我把在编写代码过程中的一些想法或者以后需要修改的内容都记录下来备忘，这样不会把一些关于软件的好的想法忘记，并且对于自己的思路也有一个整理。每完成一个任务我就在这个任务后面打钩表示这个任务已经完成。

l 至底而上的编程

在编写软件的过程中，假如我们需要实现如下功能，有一个界面实现从数据库读取数据然后显示的功能，那么我们是先写界面然后写业务逻辑，再写数据库操作还是相反实现？

我个人觉得应该是先写数据库操作、再写业务逻辑，最后写界面，遵从一种至底而上的编程习惯，在编写最底层的时候，边编写边测试，完成对最底层模块的开发，如果当写到最上层，发现需要修改底层的代码时，这时候也会很快捷的修改，而且代码架构不会乱套。

l 边编程边测试

在编程的过程中，自己经常编写一些小模块，但是编写完后，如何验证这些小模块的正确性？难道为了这个小模块编译整个项目，然后在项目中调用执行。。。这样太费时间不说，而且效果也不好。后来引入了一个单元测试工具，利用这个单元测试工具unuit每当一个模块编写完毕后，都利用Nunit来测试这个模块，这个模块测试通过后，可以放心使用，也不会担心由于编译整个项目来测试费时间。

l 用户需求优先级的处理

     期间，跟用户的交互有2-3次，用户提了一些新的需求和改进的建议。根据需求的紧急程度、重要程度、技术难度和解决时间长短将不同的用户需求进行列表清单并分析和记录重要度、解决时间和软件版本，根据此来完善用户需求。

4 其它

l 系统更新软件引入与改进

前段时间无疑中看到其他小组使用了一个软件更新程序，发现这个软件在我们XX10-1系统中也是可以使用，后来使用过程中，对其他小组的编码提出了一些改进建议，后期将会在我们的软件中集成系统新版本更新提示等功能。

    对于一些小组之间的资源可以充分利用起来，达到资源整合。

  2009年1月3日

     在数据采集方式-被动方式下(请参考我另一片博文:监控软件-数据采集方式)，当监控终端采集到数据后，将监控数据提交到监控服务器，监控服务器此时对于监控数据由两种数据显示处理方式：直接方式和数据中转方式。

•  直接方式

     所谓直接方式，是监控终端直接将数据交给监控服务器显示软件显示。

     直接方式直接将数据交给监控服务器显示软件显示，用户能够在显示软件上面及时的进行信息的监控。及时是直接方式的最大优点。但是直接方式也有几个问题：第一，监控终端获取的监控信息量比较大并且监控终端比较多时，监控显示软件的承载力就会比较大；第二，直接方式的数据不能进行保存。第三，通常显示软件在获取监控数据后，需要进行数据处理，特别是监控数据处理多的情况下，显示软件占用系统资源；第四，当监控终端的监控数据没有经过缓冲就直接交给显示软件，容易造成监控数据丢失情况；第五，监控服务器不能实现分布式，监控终端只能将数据上传到指定的一台监控服务器中。

•  数据中转方式

而数据中转方式是指监控终端将数据先交给监控服务器的数据接收软件或者存储软件，然后监控服务器的显示软件从数据接收软件或存储软件获取数据进行显示。下面分别就两种方式的优缺点进行说明：

     数据中转方式的监控数据需要进行一次数据转储才进行显示，所以数据中转方式能够实时的进行监控。数据中转方式由于采用了数据接收软件或存储软件，能够良好的起到数据存储、数据缓冲、数据处理，并且能够实现监控服务器显示软件的分布式部署，并且由于监控显示软件不直接和监控终端交互，所以监控服务器显示软件占用系统资源较少。但是也是由于此，数据需要进行一次中转，数据中转方式只能实时监控。另外，数据中转方式的数据接收软件或存储软件通常会部署在单独的硬件服务器上，所以会造成额外的硬件资源。

下面列表方式说明两种数据显示处理方式的优缺点：

采集方式	优点	缺点
直接方式	l 能够及时的将监控数据上传到监控展示台，使用户能够及时的进行监控，并且能够直接展示某些性能数据	l 监控终端获取的监控信息量比较大并且监控终端比较多时，监控显示软件的承载力就会比较大 l 直接方式的数据不能进行保存 l 通常显示软件在获取监控数据后，需要进行数据处理，特别是监控数据处理多的情况下，显示软件占用系统资源 l 当监控终端的监控数据没有经过缓冲就直接交给显示软件，容易造成监控数据丢失情况 l 监控服务器不能实现分布式，只能设定一台监控服务器
数据中转方式	l 能够实时监控 l 数据存储 l 数据缓冲 l 数据二次处理和再显示 l 监控服务器显示软件的分布式部署 l 监控显示软件不直接和监控终端交互，占用资源少	l 不能及时显示监控数据 l 由于采用了数据接收软件或存储软件，需要额外的硬件设备

1． 什么是内聚？什么是耦合？

　　内聚是从功能角度来度量模块内的联系，一个好的内聚模块应当恰好做一件事。它描述

　　的是模块内的功能联系； 耦合是软件结构中各模块之间相互连接的一种度量，耦合强弱取决

　　于模块间接口的复杂程度、进入或访问一个模块的点以及通过接口的数据。

 耦合性也称块间联系。指软件系统结构中各模块间相互联系紧密程度的一种度量。模块之间联系越紧密，其耦合性就越强，模块的独立性则越差。模块间耦合高低取决于模块间接口的复杂性、调用的方式及传递的信息。

2． 内聚分为哪几类？耦合分为哪几类？

     内聚有如下的种类，它们之间的内聚度由弱到强排列如下：

　　（1） 偶然内聚。模块中的代码无法定义其不同功能的调用。但它使该模块能执行不同

　　的功能，这种模块称为巧合强度模块。

　　（2） 逻辑内聚。这种模块把几种相关的功能组合在一起， 每次被调用时，由传送给模

　　块参数来确定该模块应完成哪一种功能

　　（3） 时间内聚：把需要同时执行的动作组合在一起形成的模块为时间内聚模块。

　　（4） 过程内聚：构件或者操作的组合方式是，允许在调用前面的构件或操作之后，马上调用后面的构件或操作，即使两者之间没有数据进行传递。

　　（5） 通信内聚：指模块内所有处理元素都在同一个数据结构上操作（有时称之为信息内聚），或者指各处理使用相同的输入数据或者产生相同的输出数据。

　　（6） 顺序内聚：指一个模块中各个处理元素都密切相关于同一功能且必须顺序执行，前一功能元素输出就是下一功能元素的输入。

　　（7） 功能内聚：这是最强的内聚，指模块内所有元素共同完成一个功能，缺一不可。

耦合可以分为以下几种，它们之间的耦合度由高到低排列如下：

　　（1） 内容耦合：如果发生下列情形，两个模块之间就发生了内容耦合

• 一个模块直接访问另一个模块的内部数据
• 一个模块不通过正常入口转到另一模块内部；
• 两个模块有一部分程序代码重叠(只可能出现在汇编语言中)；
• 一个模块有多个入口。

　　（2） 公共耦合：若一组模块都访问同一个公共数据环境，则它们之间的耦合就称为公共耦合。公共的数据环境可以是全局数据结构、共享的通信区、内存的公共覆盖区等。

　　（3） 外部耦合：一组模块都访问同一全局简单变量而不是同一全局数据结构，而且不是通过参数表传递该全局变量的信息，则称之为外部耦合。

　　（4） 控制耦合：如果一个模块通过传送开关、标志、名字等控制信息，明显地控制选择另一模块的功能，就是控制耦合

　　（5） 标记耦合：一组模块通过参数表传递记录信息，就是标记耦合。这个记录是某一数据结构的子结构，而不是简单变量。其实传递的是这个数据结构的地址；也就是地址传递。 

　　（6） 数据耦合：指两个模块之间有调用关系,传递的是简单的数据值，一个模块访问另一个模块时，彼此之间是通过简单数据参数 (不是控制参数、公共数据结构或外部变量) 来交换输入、输出信息的,相当于高级语言的值传递。

　　（7） 非直接耦合：两个模块之间没有直接关系，它们之间的联系完全是通过主模块的控制和调用来实现的。

耦合强度，依赖于以下几个因素：
　　（1）一个模块对另一个模块的调用；
　　（2）一个模块向另一个模块传递的数据量；
　　（3）一个模块施加到另一个模块的控制的多少；
　　（4）模块之间接口的复杂程度。

参考资料：

http://baike.baidu.com/view/156245.html

http://www.cnblogs.com/dqshll/articles/1116799.html

http://blog.zol.com.cn/858/article_857495.html

  2008年12月11日

     目前流行的监控数据采集方式通常有两种：主动方式和被动方式。

•      主动方式

     主动方式主要通过监控终端/服务器直接访问被监控对象的方式获取监控信息。此方式由于需要跨越防火墙，对技术的要求比较高，实现起来比较复杂，特别是当监控终端安装了不同的防火墙软件时，实现起来极其困难。并且由于监控服务器需要对多台监控终端进行监控，当监控终端数量比较多的情况下，监控服务器的性能压力就会比较大，甚至有可能导致监控失败，或者是由于某台或某几台监控终端网络延迟导致监控服务器监控延迟。
     主动方式的优点也是很明显的，它不需要在客户端安装任何软件，可以直接进行监控数据的获取，并且不会由于监控终端的增加和减少而进行额外的工作，监控服务器会根据新增或者减少的监控终端自动进行判定。
主动方式目前通常采用实现的方法是通过在客户端开启监控端口的方式使监控服务器能够访问监控终端，此方法的缺陷是必须在监控终端开启监控端口，并且将此监控端口设置为防火墙访问端口，也就是意味这监控服务器端可以操作或者控制监控终端。

•   被动方式 

     另外一种就是被动方式。被动方式采用的是在被监控对象端安装一个终端的方式实现监控信息的获取，然后监控终端将采集到的信息上传到监控服务器，从而实现信息的采集。
      被动方式不需要解决跨越防火墙等相关技术难题，实现起来比较简单。并且由于是监控终端主动提交数据给监控服务器，所以监控服务器的性能比主动方式要高出不少。
     但是被动方式需要在监控终端安装客户端，也就是意味着监控方需要完全控制监控终端才能够进行监控，并且会占用一定的监控终端资源。由于监控终端安装客户端，当某台监控终端死机或者网络延迟，只是导致单个节点的脱网，并不会影响到监控服务器。此外，由于监控终端的变更(增加和减少)而需要进行额外的安装监控终端的操作，当监控终端的数量比较多的情况下，其工作量还是相当巨大的。其次，由于监控终端需要将数据上传到监控服务器，当监控服务器安装了防火墙时，监控终端的访问将会受到限制。故被动方式只需要解决监控服务器的防火墙即可，比主动方式困难降低不少。

下面用图表的方式显示两种采集方式的对比：

采集方式	优点	缺点
主动方式	l 不需要在客户端安装任何软件 l 不会占用客户端的任何资源 l 监控终端的增加和减少，监控服务器自动判定	l 需要跨越防火墙，对技术的要求比较高，实现起来比较复杂，特别当监控终端安装了不同的防火墙软件时，实现起来极其困难 l 当有特别多的监控终端，监控服务器监控性能压力大 l 某台或某几台监控终端网络延迟导致监控服务器监控延迟
被动方式	l 实现比较简单 l 监控服务器性能较好 l 不会由于某台监控终端死机或者网络延迟影响到监控服务器	l 需要控制监控终端,并且在其上安装额外的软件 l 占用一定的监控终端资源 l 在监控终端台数的变化需要额外的工作来进行监控

     由于时间问题，写的不是很全，希望大家谅解~~~