A method for displaying, searching, and referencing software object types using domain specific terminology.
Original Publication Date: 2009-Mar-12
Included in the Prior Art Database: 2009-Mar-12
This article describes a process directed to the problem of allowing each user to call the software objects/resource by their particular domain specific terminology, and creating relationships between resources.
A method for displaying
A method for displayingA method for displaying ,
domain specific terminology
domain specific terminologydomain specific terminology .
In software development many vocabularies are used to identify software resources. A single resource could have many synonyms. In addition, when globalization is taken into consideration, a single name could be translated into many different languages.
For example: test and test case can mean the same thing to different groups of people. In addition, the word 'test' alone, can be translated into many languages.
In creating an ALM solution, there is a need to establish and manage relationships between resource types. For example, a test case verifies a requirement. There is a relationship between the two that needs to be established and maintained. On the surface this sounds simple, however, the existence of multiple vocabularies, and a varied granularity within those vocabularies (e.g. a requirement could be a feature, a use case, a nonfunctional requirement), makes the ability to define such a system next to impossible. Many attempts have been made to create a common object model for Application Lifecycle Management. However, these attempts are doomed to failure due to the lack of agreement on resource names.
This process treats domain specific nomenclature of a software object model system using the same techniques that are applied to a software product to translate that product into a foreign language. The process identifies each object type of the software model by a unique id. The display name of this object type is treated as a separate label that is maintained in a persistent store, the preferred store being a representation of a translation format file, such as the .xlf standard translation format file, although any other store of the relationship between the unique id and the domain name is envisioned by this application, such as database tables and key value pairs. The process allows the user to decide their specific nomenclature for the object types. This domain specific nomenclature is captured by the system and placed into the persistent store, e.g .xlf files. These transformations are then applied to the software product by the user to customize the terminology of the object types in the product. This differs from standard translation systems in that the customer supplies the terminology, not the product vendor, and each translation is to a specific technology domain, not just a national language. However, since preferred embodiment is a standard translation format being used, the system can leverage any of the st...