nxjbill001

谈起封装技术，我想大家并不陌生，从二进制到汇编，再到c语言和其它面向过程的语言，都是从简单易用的角度进行了封装，已经屏蔽了相当多的细节了，不光是不同的硬件，以及硬件的操作指令及其二进制结构。封装意味着开发者面对的一个个的功能块 ，一种逻辑上操作，并不真正面对具体的机器的指令形式，这确实给我们带来好处，我们不用懂很多的计算原理就可以控制计算机了。

　　语言的封装让我们简化了操作，那么操作系统的封装让我们简化了控制。我要多个任务执行那么我就调用一个库函数，或是几条语句，我要同步我就发信号量，一切变得那么简单，再也不用汇编或是机器指令去调用这一切。我们说封装好啊，操作计算机，简单的语句就可以了。

        封装还演生了库函数，动态库等重用技术，很多操作或是计算都变得简单了。

　　由c语言进入到C++等面向对象的语言算是软件开发的一场革命，严格来说面向对象技术其实是一种面向现实世界的逻辑抽象和模型的提取，对于编译器来说只是增加了一些规则和约束，比如对像及其类的成员函数如何编译等。如果说面向过程语言的封装主要是侧重于算法的封装，那么面向过程就是侧重于现实模型的封装和关系建立。

　　比较好的封装如stl，或是mfc，确实到了快速开发的角度。但是还不够能够更加精细化模块化，对于一个大型的系统来说，模块分化，各自有一定的独立性，可以分配单独开发无论从模型抽象和实现上组合上都是最完美的。

　　封装是我们追求的目标，如何更简单化更方便使用更模块化，封装技术进入到操作系统对封装的支持。比如组件技术，支持组件的创建支持，组件的线程模式支持等。

　　组件模块化设计是我们追求的目标，那么如何在一个更为开放的应用中可以去调用其它程序的功能呢，控件和容器出现。

　　封装技术再多也是围绕软件工程开发而演生，服务于软件工程，服务于特定的操作系统，将后来软件开发工程可能工作越来越轻松，各种种样的库各种各样的封装，在引诱着我们，像鸦片一样，我在封装糊里糊途的写程序或是遇到开发时设计简单的结构软件重用度小，不对自己的技术进行封装思考，中国的软件可能再也发展不起来了。永远在别人的封装中写代码。

　　对于那些坚持用汇编或是c的开发者，我只能说你们是好样的，不屈服在某些封装技术下，具有牛的不怕苦不怕累的精神。

　 对于那些使用新封装技术的，我表示好样的，快速开发，省时省力，希望你们不要沉迷于这些封装技术，将这些技术的一些思路方法应用的软件中去。

　　对于那些在软件开发中运行这些封装技术原理来实施软件工程的，我说这样我们的软件开发将会上一个大的台阶。

　　对于对封装原理有透彻理解，进行封装库给别的开发者使用的，我敬佩你，中国的软件希望在这里。

需求分析，好比是决定要做什么事，并且圈一块地，就是所谓的需求范围吧。
设计，好比是盖房子时设计图纸，决定做成什么样子。
实现，好比是实现去一砖砖的去彻房子，就是具体的按规划去做。
测试，相当于去验收房子吧。

从这几比喻来看，我们的软件工程开发，前期工程分析设计的工作还是相当重要，希望同行们，不要沉浸在代码几边的工作中。围绕需求，设计进行工作。

   项目在分析、设计、实现、组装后，就进入测试环节，测试作为检测我们设计的软件是否满足设计的功能需求，及其性能需求及其隐性需求起着重大的作用，作为最后成形的产品，可能在一些功能或是设计上存在缺陷，或是对于用户的需求歪曲的设计，都可以在测试环节找出来，予以修正。
   
   因此从这个角度上看，我们应该是重视软件测试，软件测试是提高软件质量的一个重要手段。据国外一些开发公司的统计，一般是设计：实现：测试人员投入的比例是1:3:3，可见对于测试的重视程度。

   那么测试也应该有测试的工作方法，首先要制作测试计划，选好测试模型，制定好的测试用例，然后进行评审。我觉得测试用例设计很重要，测试用例，要覆盖软件的功能，操作的一般情情况，特殊情况，爆力等特殊操作，设计用例还要能兼顾到新的bug等。总之好的测试用例，使我们能更快的发现软件的软肋，减少重复性的工作，减少软件中遗露的缺陷。

   测试用例设计也是一个经验的积累过程，一个优秀的测试工程师，必能找出一些通用的缺陷，即有些测试用例也是可重用的。

   有了测试用例，我们就过可以按这些用例去，去一个个的检验我们的软件产品。找出其中的缺陷，然后交给开发组进行修正，再跟踪测试。

   我们在提交测试后，一般会根据上轮测试，修正一些bug或是逻辑错误，产生一些新版本，然后再提交新的版本测试，那么在中间这一轮轮的测试中，是否每次都要进行覆盖测试呢，我个人觉得，如果前一两轮测试得较认真，那可以在有新版本的测试程序后，可以丢掉原版本的程序，在新版本的程序进行测试，测试的优先级别是先测bug是否修复，然后测上个版本没测的用例，直到全部测试完或是有一个新的版本出现，再丢弃用新的版本测试。

   经过多轮测试修复好，最后再进行全方位的覆盖测试，我想软件这时的功能质量都应该是比较有保证的。

   整个测试过程，均以需求基本要求，以测试用例为测试的指导。

     在分析评审完用户需求后，需要去需求进行分配，识别出用例和角色，并且对用例进行分析，得出业务流，和数据流及其数据逻辑结构，并且对相似或是同类的用例进行划分，划分出一个个的系统。为后期组件建模层次划分提供依据。

 

    在完成需求分配后，我们会根据用例的子系统来划分模块，形成组件，并且根据定义好子系统之间的接口及其方法。

 

    在完成需求分配和模块分配后，及其接口方法定义后，我们就进入下一环节，子系统设计，识别出子系统的角色和及其类对象的方法及其属性，类及其对象之间的关系。

 

    在这些工作都完成评审后，就可以开始编码工作了。

 

    对于一些隐性的未有挖掘出来的需求，可以经过分析后，将这些需求分配到某个子系统中去，从而不会影响整个系统的需求分配及其设计。

 

    上面是我在日常开发设计中遇到的一些问题和工作中的处理方法。

 

    感觉有时工作是前期的工作还没有做完评审，进入下一步，造成诸多的需求没有挖掘或是需求分配不合理或是需求分配没有覆盖用户的需求，造成对后面的子系统设计实现的重构，较为严重的影响开发计划。