4. Business language

strict warning: Only variables should be passed by reference in /home/enterpri/public_html/modules/book/book.module on line 560.

All object-oriented methodologies call for identifying business objects from the problem domain.  They generally give a few guidelines, such as finding nouns in the requirements statement(s):   “Lists of key nouns, gathered from representative documentation and/or use cases, become  potential classes.”   “The objects can be found as naturally occurring entities in the application domain.  An object becomes typically a noun which exists in the domain.”    “Begin by listing candidate object classes found in the written description of the problem.  Don’t be too selective; write down every class that comes to mind.  Classes often correspond to nouns.”   “As a first approximation one can scrutinize the requirements document, if there is one, and consider the nouns, or better yet, the noun phrases.”   “As you read, consider the nouns in the written mate-rial; these words will often give you a clue about potential Objects in the system.”   “Roughly speaking nouns are candidate objects, and verbs are candidate operations.” 

Some methods go a step farther by introducing several methods of classification, and recognizing that abstraction is a process of discovery in analysis and invention in design.  Object oriented practitioners have used a number of techniques for finding and classifying objects, such as classical categorization, behavior analysis, domain analysis, use-case analysis, class responsibility collaboration cards, informal English description, and structured analysis.

Business language analysis starts from where these other methods leave off, by focusing attention on how to make the most of the rich language resources that are available within any business environment.  These resources, if studied carefully, will provide guidance as to exactly what information system support needs to be provided.