本发明涉及一种软件开发方法，具体为一种用于软件的开发方法，属于数据分析应用技术领域。
背景技术：
在上个世纪60年代中期爆发了众所周知的软件危机。为了克服这一危机，在1968、1969年连续召开的两次著名的nato会议上提出了软件工程这一术语，并在以后不断发展、完善。与此同时，软件研究人员也在不断探索新的软件开发方法。至今已形成了八类软件开发方法。
目前的软件开发方法存在着处理效率慢，电脑易卡顿的缺点。
技术实现要素：
本发明的目的就在于为了解决上述问题而提供一种用于软件的开发方法。
本发明通过以下技术方案来实现上述目的，一种用于软件的开发方法，包括标签数据采集模块，和分析控制模块，pam方法希望能兼顾yourdon方法、jackson方法和自底向上的软件开发方法的优点，而避免它们的缺陷，它的基本思想是：考虑到输入、输出数据结构，指导系统的分解，在系统分析指导下逐步综合，这一方法的具体步骤是：从输入、输出数据结构导出基本处理框；分析这些处理框之间的先后关系；按先后关系逐步综合处理框，直到画出整个系统的pad图，从上述步骤中可以看出，这一方法本质上是综合的自底向上的方法，但在逐步综合之前已进行了有目的的分解，这个目的就是充分考虑系统的输入、输出数据结构，pam方法的另一个优点是使用pad图，这是一种二维树形结构图，是到目前为止最好的详细设计表示方法之一，远远优于ns图和pdl语言。
所述omt的第一步是从问题的陈述入手，构造系统模型，从真实系统导出类的体系，即对象模型包括类的属性，与子类、父类的继承关系，以及类之间的关联，类是具有相似属性和行为的一组具体实例的抽象，父类是若干子类的归纳，因此这是一种自底向上的归纳过程，在自底向上的归纳过程中，为使子类能更合理地继承父类的属性和行为，可能需要自顶向下的修改，从而使整个类体系更加合理，由于这种类体系的构造是从具体到抽象，再从抽象到具体，符合人类的思维规律，因此能更快、更方便地完成任务，这与自顶向下的yourdon方法构成鲜明的对照，在yourdon方法中构造系统模型是最困难的一步，因为自顶向下的“顶”是一个空中楼阁，缺乏坚实的基础，而且功能分解有相当大的任意性，因此需要开发人员有丰富的软件开发经验，而在otm中这一工作可由一般开发人员较快地完成，在对象模型建立后，很容易在这一基础上再导出动态模型和功能模型，这三个模型一起构成要求解的系统模型。
所述系统模型建立后的工作就是分解，与yourdon方法按功能分解不同，在omt中通常按服务(service)来分解，服务是具有共同目标的相关功能的集合，如i/o处理、图形处理等，这一步的分解通常很明确，而这些子系统的进一步分解因有较具体的系统模型为依据，也相对容易，所以omt也具有自顶向下方法的优点，即能有效地控制模块的复杂性，同时避免了yourdon方法中功能分解的困难和不确定性。
所述每个对象类由数据结构(属性)和操作(行为)组成，有关的所有数据结构(包括输入、输出数据结构)都成了软件开发的依据，因此jackson方法和pam中输入、输出数据结构与整个系统之间的鸿沟在omt中不再存在，omt不仅具有jackson方法和pam的优点，而且可以应用于大型系统，更重要的是，在jackson方法和pam方法中，当它们的出发点--输入、输出数据结构(即系统的边界)发生变化时，整个软件必须推倒重来，但在omt中系统边界的改变只是增加或减少一些对象而已，整个系统改动极小。
与现有技术相比，本发明的有益效果是：在omt之前的软件开发方法都是基于功能分解的。尽管软件工程学在可维护方面作出了极大的努力，使软件的可维护性有较大的改进。但从本质上讲，基于功能分解的软件是不易维护的。因为功能一旦有变化都会使开发的软件系统产生较大的变化，甚至推倒重来。更严重的是，在这种软件系统中，修改是困难的。由于种种原因，即使是微小的修改也可能引入新的错误。所以传统开发方法很可能会引起软件成本增长失控、软件质量得不到保证等一系列严重问题。正是omt才使软件的可维护性有了质的改善。omt的基础是目标系统的对象模型，而不是功能的分解。功能是对象的使用，它依赖于应用的细节，并在开发过程中不断变化。由于对象是客观存在的，因此当需求变化时对象的性质要比对象的使用更为稳定，从而使建立在对象结构上的软件系统也更为稳定。更重要的是omt彻底解决了软件的可维护性。在oo语言中，子类不仅可以继承父类的属性和行为，而且也可以重载父类的某个行为(虚函数)。利用这一特点，我们可以方便地进行功能修改：引入某类的一个子类，对要修改的一些行为(即虚函数或虚方法)进行重载，也就是对它们重新定义。由于不再在原来的程序模块中引入修改，所以彻底解决了软件的可修改性，从而也彻底解决了软件的可维护性。oo技术还提高了软件的可靠性和健壮性。
具体实施方式
下面将对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
一种用于软件的开发方法，包括标签数据采集模块，和分析控制模块，pam方法希望能兼顾yourdon方法、jackson方法和自底向上的软件开发方法的优点，而避免它们的缺陷，它的基本思想是：考虑到输入、输出数据结构，指导系统的分解，在系统分析指导下逐步综合，这一方法的具体步骤是：从输入、输出数据结构导出基本处理框；分析这些处理框之间的先后关系；按先后关系逐步综合处理框，直到画出整个系统的pad图，从上述步骤中可以看出，这一方法本质上是综合的自底向上的方法，但在逐步综合之前已进行了有目的的分解，这个目的就是充分考虑系统的输入、输出数据结构，pam方法的另一个优点是使用pad图，这是一种二维树形结构图，是到目前为止最好的详细设计表示方法之一，远远优于ns图和pdl语言。
omt的第一步是从问题的陈述入手，构造系统模型，从真实系统导出类的体系，即对象模型包括类的属性，与子类、父类的继承关系，以及类之间的关联，类是具有相似属性和行为的一组具体实例的抽象，父类是若干子类的归纳，因此这是一种自底向上的归纳过程，在自底向上的归纳过程中，为使子类能更合理地继承父类的属性和行为，可能需要自顶向下的修改，从而使整个类体系更加合理，由于这种类体系的构造是从具体到抽象，再从抽象到具体，符合人类的思维规律，因此能更快、更方便地完成任务，这与自顶向下的yourdon方法构成鲜明的对照，在yourdon方法中构造系统模型是最困难的一步，因为自顶向下的“顶”是一个空中楼阁，缺乏坚实的基础，而且功能分解有相当大的任意性，因此需要开发人员有丰富的软件开发经验，而在otm中这一工作可由一般开发人员较快地完成，在对象模型建立后，很容易在这一基础上再导出动态模型和功能模型，这三个模型一起构成要求解的系统模型。
系统模型建立后的工作就是分解，与yourdon方法按功能分解不同，在omt中通常按服务(service)来分解，服务是具有共同目标的相关功能的集合，如i/o处理、图形处理等，这一步的分解通常很明确，而这些子系统的进一步分解因有较具体的系统模型为依据，也相对容易，所以omt也具有自顶向下方法的优点，即能有效地控制模块的复杂性，同时避免了yourdon方法中功能分解的困难和不确定性。
每个对象类由数据结构(属性)和操作(行为)组成，有关的所有数据结构(包括输入、输出数据结构)都成了软件开发的依据，因此jackson方法和pam中输入、输出数据结构与整个系统之间的鸿沟在omt中不再存在，omt不仅具有jackson方法和pam的优点，而且可以应用于大型系统，更重要的是，在jackson方法和pam方法中，当它们的出发点--输入、输出数据结构(即系统的边界)发生变化时，整个软件必须推倒重来，但在omt中系统边界的改变只是增加或减少一些对象而已，整个系统改动极小。
使用时，在omt之前的软件开发方法都是基于功能分解的。尽管软件工程学在可维护方面作出了极大的努力，使软件的可维护性有较大的改进。但从本质上讲，基于功能分解的软件是不易维护的。因为功能一旦有变化都会使开发的软件系统产生较大的变化，甚至推倒重来。更严重的是，在这种软件系统中，修改是困难的。由于种种原因，即使是微小的修改也可能引入新的错误。所以传统开发方法很可能会引起软件成本增长失控、软件质量得不到保证等一系列严重问题。正是omt才使软件的可维护性有了质的改善。omt的基础是目标系统的对象模型，而不是功能的分解。功能是对象的使用，它依赖于应用的细节，并在开发过程中不断变化。由于对象是客观存在的，因此当需求变化时对象的性质要比对象的使用更为稳定，从而使建立在对象结构上的软件系统也更为稳定。更重要的是omt彻底解决了软件的可维护性。在oo语言中，子类不仅可以继承父类的属性和行为，而且也可以重载父类的某个行为(虚函数)。利用这一特点，我们可以方便地进行功能修改：引入某类的一个子类，对要修改的一些行为(即虚函数或虚方法)进行重载，也就是对它们重新定义。由于不再在原来的程序模块中引入修改，所以彻底解决了软件的可修改性，从而也彻底解决了软件的可维护性。oo技术还提高了软件的可靠性和健壮性。
对于本领域技术人员而言，显然本发明不限于上述示范性实施例的细节，而且在不背离本发明的精神或基本特征的情况下，能够以其他的具体形式实现本发明。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本发明的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化囊括在本发明内。
此外，应当理解，虽然本说明书按照实施方式加以描述，但并非每个实施方式仅包含一个独立的技术方案，说明书的这种叙述方式仅仅是为清楚起见，本领域技术人员应当将说明书作为一个整体，各实施例中的技术方案也可以经适当组合，形成本领域技术人员可以理解的其他实施方式。