There exists a need for a comprehensive tool allowing to represent, as close as possible, reality and logic in classes.
With prior art systems, the organization of an object-oriented architecture is highly dependent upon the programmers expertise level. With currently available tools, it is difficult to create objects/classes of a chosen domain. Furthermore, none of the currently available classification systems allow structured creation and naming of all the classes necessary to a given application.
Other difficulties associated with currently available systems include: the difficulty in uniquely naming classes since existing software does not provide any nomenclature rules that makes it easy for a programmer not familiar with the architecture of a system to follow. As a system is being developed and grows in complexity, it becomes harder to maintain a certain consistency in naming of different classes.
Another drawback associated with prior art systems is the difficulty in separately representing a class and its activities. It is common practice therefore to create different classes to represent the same reality, e.g. client, supplier, etc.
It is also difficult to represent the cardinality of a set of objects/classes, since multiplicity is a property that can only be used to characterize links between classes.
Furthermore, with current tools, classes need to be assembled into packages in order to build an architecture. While some current systems provide tools for class creation, these are poorly adapted to describe logical associations between classes.
There are further difficulties in defining packages expressing a dynamic view of an application by associating different classes expressed in a static view.
There are also difficulties in coherently naming packages, as well as certain components such as interfaces and databases.
There are therefore numerous difficulties in imparting knowledge regarding the classes and their associations to other programmers.
USPTO Backgrounds
USPTO Backgrounds