Copyright 1998,1999 Nikolas S. Boyd. Permission is granted to copy this document provided this copyright statement is retained in all copies.

Nik Boyd

Natural Language Analysis for Domain and Usage Models

Introduction

This paper presents initial steps toward codifying linguistic insights and practices that have been applied to problem descriptions, domain analysis and usage requirements. The intent of this work is to help bridge the gap between the natural and informal languages used to describe problems and requirements and the formal modeling languages used during object-oriented analysis and design.

Most object-oriented methodologies only consider nouns and verbs to be relevant during analysis, largely because our fundamental computational model supports only operands and operators. However, consideration of the other word classes can also add significant value to the collection and analysis of problems and requirements. This paper offers an extensive survey of the various word classes and their uses in the context of object-oriented software development.

Considering the import of adjectives, adverbs, prepositions, articles, conjunctions and interjections during analysis enriches the process of object discovery and retains more of the semantic content and metaphoric richness of the source material. Every word in a statement can contribute value to a conceptual model. Therefore, none of the words in a statement should be eliminated arbitrarily or prematurely. Every word should be considered.

These ideas can be applied to and integrated into the requirements collection and analysis processes that precede object-oriented software development. Linguistic analysis of a problem domain and associated solution usage requirements can produce conceptual models. Conceptual models can help to establish commonality among the people involved in the development of information systems - i.e., they can help solution stakeholders and software developers build a shared understanding of a problem and how a software solution will be used.

Background

The modeling languages used for software development tend to be elaborate and complex (e.g., the Unified Modeling Language1 - UML). The primary reason for this is that models constructed with these languages need to include a level of detail sufficient to specify the design of a software system. While simplified versions of these languages may be used during analysis, these langauges tend to focus on solution modeling rather than problem modeling. These kinds of models are appropriate for software developers, but they are not suitable for stakeholders (who are not generally trained in their construction and interpretation).

The languages used to model conceptual structures (e.g., Sowa's Conceptual Graphs2 - CG) focus on the semantics of natural language and tend to be syntactically simple but very formal. Conceptual structures are appropriate for machines and computational linguists. They provide a mechanism for representing knowledge and the semantics of natural language expressions. They provide a level of formality suitable for manipulation by computers - i.e., for natural language processing and natural language understanding systems. While conceptual structures are derived from natural language, they are arcane and unintelligible to lay people (i.e., not suitable for general human consumption and interpretation).

Stakeholders need a modeling language that provides some degree of formality, while remaining very simple and close to natural language. These motivations led to the development of the natural conceptual modeling language (NCML) to support natural conceptual models. Natural conceptual models have both a graphical form and a textual form. Due to space limitations, this paper focuses on the textual form. For an introduction to the graphical form and a complete example of its use, please refer to the related paper available on the Web.3

The linguistic analyses discussed in this paper are based on the traditional word categories found in English grammar.4 Through sentence and word analysis of ordinary informal discussions, we can extract a great deal of information useful to object-oriented software designs. We can rephrase sentences so that they are meaningful on multiple levels and to multiple audiences, including the various kinds of stakeholders and software developers.

Syntactic Normalization and Semantic Exploration

People have twisted minds and formulate complex thoughts. At least, they often express their thoughts with complex sentences. This complexity makes human communication more efficient by reducing or eliminating redundant phrases. Such eloquence is certainly appropriate for ordinary rhetoric. However, to make sentences suitable for modeling, we need to greatly simplify their syntax, often at the expense of some apparent redundancy - e.g., repeatedly naming a subject in several related sentences.

There are several transformations that can be applied to sentences that preserve their overall meaning while producing simple and consistent syntactic formats. Collectively, we can characterize these transformations as syntactic normalization. Simplifying the syntax of sentences makes them less prone to ambiguity. Such simplicity can also help people to share and compare their mental models. Thus, the additional formality supports commonality.

Sometimes a complex sentence cannot be simplified to the desired degree without first exposing the meaning of some of its constituent phrases. In these situations, semantic exploration may provide clues for recovering nouns or verbs from descriptive adjectives and adverbs, and other kinds of phrases.

Normalized sentences are simple declarative sentences, sometimes called kernel sentences or nuclear sentences. The following definition extends that presented by Carasik, et. al.,5 while integrating distinctions identified by Abbott.6 The normal form of clauses have the following characteristics.

Recommendations for determinants include the following:

Use the indefinite articles - a, an (or no article) for most singular nouns to indicate one instance of many (potentially a class).
Use the indefinite pronoun - some (or no determinant) for plural nouns to indicate the existence of many instances (of a collection or class).
Use the (distributive) indefinite pronoun - each to indicate that an instance is a member of a collection (usually a class).
Use the definite article - the only when a sentence subject (or object) refers to a domain singleton - i.e., there is only ever one instance of the referenced object.
Use a proper noun to refer to a singleton, but the class(es) of which the instance is a member should also be identified.

The following table shows some illustrative examples of normalized sentences. Each example is preceded by the number of actants required by the example verb. The verbs listed are typical, including examples of both transitive and intransitive verbs. The initial examples are prototypical - i.e., the verbs only have placeholders for actants (x, y). The remaining examples identify appropriate prepositions, and the actants name thematic semantic roles that are appropriately associated with the example verb.

(1) x begins (2) x emits y
(1) x exists (2) a predator captures a prey
(1) x ends (3) a giver gives a gift to a recipient
(2) x becomes y (4) a sender sends a message to a receiver with a medium

While the rules for normalization are defined in terms of specific word classes - nouns, verbs, prepositions and determinants - the overall character of normalized sentences hinges on restriction of the verb. So, we will examine each word class in detail, but we begin by focusing on the verb.

Verbs

English verbs are inflected for voice, mood, number, tense. The predicate expressed by a verb also has polarity. Each of these aspects of a verb contributes some value and/or information to a conceptual model.

Voice

  

Verbs can be phrased in either the active voice or passive voice. The active voice has greater strength, so it is preferred for use in conceptual models and object-oriented software designs. The passive voice not only weakens a sentence, it also complicates its phrasing and inverts the normal order of subject and object. Compare:

A mouse is eaten by the cat. (passive)
The cat eats a mouse. (active)

Mood

  

Verbs can express an action or state as an actual fact, or the potential for such. The moods include indicative, subjunctive, potential, imperative, infinitive. Some examples:

Strive lest you fail. (subjunctive)
To sympathize is to understand. (infinitive)
The cat may eat a mouse. (potential)
The cat will eat a mouse. (imperative)
The cat eats a mouse. (indicative)

The subjunctive mood rarely appears any more in discourse. An infinitive verb should usually be replaced by its corresponding noun or adjective, or decomposed into independent clauses if it serves as an adverb. The indicative mood is usually used to express a relationship or the action of a subject. The imperative mood and the potential mood can be used to indicate the action of a subject (or the potential for such action), but due to its simplicity, the indicative mood is prefered for conceptual models.

It is interesting to note that many programming languages are considered imperative. These languages usually include reserved words such as if then else, do, goto.

Number

  

English verbs derive their number from the sentence subject. Like nouns, verbs can be either singular or plural. The number of a verb must agree with (and be opposite of) the number of the sentence subject. Compare:

The cats eat the mice. (plural subject + singular verb)
The cat eats a mouse. (singular subject + plural verb)

As the normal number of sentence subjects is singular and the normal mood of verbs is indicative, the normal number of verbs is plural.

Polarity

  

A verb can be expressed with an affirmative or a negative polarity. For example:

A storage building's drum count must not exceed its drum storage limit. (negative)
A storage building's drum storage limit must exceed its drum count. (affirmative)

The normal polarity of verbs is affirmative.

Tense

  

Verbs can express the relative timing of an action or state in the past, present, or future. The rules for normalizing sentences do not dictate the tense of the verb. However, most verbs that express actions and relationships should be expressed in the present tense.

Many requirements specifications adopt the use of future tense to express individual requirements, especially using the auxiliaries will or shall. These auxiliaries can easily be inserted into sentences if needed (e.g., in a proposal or statement of work).

Verbs that indicate an event or a state will often be expressed in the past tense because they indicate an action that occurred to bring about the indicated state. For example:

A predator captures its prey. (action)
An employer employs an employee. (relationship)
A wife married her husband. (event, state)

Dispositions derived from verbs play an important role in object-oriented software designs. Dispositions indicate the states through which an object passes during its lifecycle, and the related verbs (and corresponding nouns) often indicate how an object transitions from state to state - i.e., the events that trigger state changes. For example, the states in the lifecycle of a piece of electronic mail could include the following: created, drafted, addressed, queued, sent, received, stored, trashed, destroyed.

However, merely enumerating object lifecycle states does not convey any information about the transitions between states. The events that trigger transitions between states must also be enumerated in order to complete a lifecycle model. For this reason, we typically model lifecycle states graphically. Consider the following lifecycle model for a chemical storage drum:

dispositions: delivered, tagged, allocated, stored, collected, returned, loaded
transitions: arrival, delivery, identification, rejection, allocation, storage, collection, loading, departure

The analysis of dispositions and transitions can be important even in the case of a relatively stable relationship. For example, with respect to the employment relationship, there are several states preceding and following employment that may be relevant to a full lifecycle model - i.e., consider: applied, interviewed, hired, employed, (retired, discontinued, fired).

Completion

  

A verb relates a subject to some object(s), or it expresses the action of a subject in relation to some object(s). A transitive verb often relates multiple objects to the sentence subject. However, when discussing problems and requirements informally, stakeholders often use incomplete sentences - i.e., they leave important elements out of an expression. Transitive verbs typically have actants that play thematic semantic roles. Identifying the roles associated with an action verb can help a requirements analyst to identify whether any objects are missing from a sentence, and which roles they play into the action expressed by a verb.

  • The subject serves as agent.
  • The direct object serves as patient.
  • Indirect objects serve as recipient, companion, or instrument.

For those transitive verbs with more than two actants, note that the associated prepositions are considered part of the verb (see the normalization examples above - e.g., for sends). Most conceptual modeling languages eliminate these predicative prepositions, retaining only the verb. Retaining the prepositions associated with the verb provides better traceability. For this reason, NCML retains these sentence elements. It is also advantageous for a programming language to retain these linguistic elements (e.g., Smalltalk).

Usage

  

Solution usage requirements tend to emphasize verbs - i.e., they focus on the actions that agents (e.g., users) external to a system can initiate when interacting with the system. Verbs are also often used to describe the responsibilities of objects during object behavior analysis and responsibility-driven design. As indicated previously, the responsibility expressed by a verb may need to be distributed across several objects in a system. Also, if an action verb is very general, it may need to be decomposed into several related actions, each of which can then be assigned to the relevant object. During design, decisions need to be made regarding the senders and receivers of object messages indicated by action verbs in the conceptual models and object-oriented analysis models. Here we clarify some of the design recommendations offered by Saeki, Horai, and Enomoto.7

  • For each kernel sentence, identify which object(s) change state.
  • The object(s) that change state are usually the receiver(s) of object messages.
  • The subject of an intransitive verb may serve as the message receiver.
  • For a transitive verb, when the patient of the action is an attribute noun, the message receiver is the object which owns the attribute.
  • When an action verb changes the state of several objects, the action must be decomposed into a verb appropriate for each target object.
  • Causal relations between actions need additional messages to link antecedent actions to consequent actions (e.g., condition a triggers action b, event x causes action y).

Nominalization

  

Complex action verbs with several actants (e.g., more than three) sometimes need to be modeled as objects. For example, this will often be the case when a system needs to report or keep a persistent record of the action. This may also be the case when modeling the interface of a complex legacy system, especially one that was not designed with an object-oriented approach. Fortunately, the conversion of a verb to a noun (nominalization) is usually straightforward (e.g., see some of the transformations depicted in the section on conceptual equivalence).

Inquiry of Actions

The following table provides a schema for the kinds of verbs frequently found in human discourse and the questions that elicit them. The aspects listed are representative and identify only broad categories.

Question Aspect Example
Why? Reason a cause and its effect(s), i.e.,
an event causes some state(s)
Objective complete an action,
fulfill a relationship,
achieve or maintain a state
|
|
|
|
|
|
|
Question Aspect Example
How? Operation market widgets
Script do X, do Y, do Z
Test determine whether a state exists?

Prepositions

Prepositions are either predicative (when they associate nouns with a verb) or genetive (when they associate nouns).

Predication

  

Predicative prepositions associate nouns with the verb of a sentence, especially sentences with transitive verbs that require more than one object. Each transitive verb requires some number of nouns as arguments. Thus, each verb can be characterized in terms of its valence - the number of positions that need to be filled to complete the verb's predicate.

In his pioneering work on catastrophe theory,8 René Thom developed a theory for the spatial origin of syntactical structures. Thom suggested that the interactions indicated by transitive verbs can be graphed as spatiotemporal processes. Thom proposed that the interaction graphs of these processes belong to one of sixteen archetypal morphologies.

So, each verb may be typed in terms of its valence. However, while completing the verb with its appropriate predicative prepositions will provide a more complete conceptual model, some of the actants associated with the verb may be eliminated in certain contexts - e.g., when they are supplied implicitly by the context in which the statement is embedded.

Possession

  

The genetive (possessive) case often hides a substantive verb that can be revealed through appropriate analysis or inference. The genetive case uses the preposition of or the possessive form 's to indicate ownership, possession, property, containment, or aggregation. Identifying the relationship indicated by the genetive case supports steps toward an object-oriented software design. Identifying the nature of the relationship helps to determine whether to model the elements of the relationship as separate objects or whether the object of the relationship should become an attribute of the subject. The importance of these distinctions has been raised by others.9

Category   Example (genetive => verb)
possession   the hair of the dog => the dog has hair (as a physical attribute)
property   the color of the car => the car body has a color (as a property)
ownership   the library's book => the libray owns a book
containment   drums of chemicals => a drum contains a chemical
aggregation   the bicycle's pedals => the bicycle has pedals (as parts)

Nouns (and Noun Phrases)

Identifying and building useful software objects are the fundamental pursuits of the object-oriented approach to software design. Software objects are often packaged and delivered as reusable libraries and frameworks, or as complete applications and products. But, these larger aggregations are necessarily composed of software objects, which serve as the fundamental units of delivery, reuse and assembly.

So, software objects are also the fundamental organizational units for object-oriented analysis and design. As such, a major portion of the effort expended during analysis focuses on the identification and naming of objects. Nouns and noun phrases serve this purpose in natural languages. Abbott6 identified the following distinctions relative to objects.

Common nouns and mass nouns usually become classes in an object-oriented system design. Context often helps determine whether a noun or noun phrase is being used as a common noun or a mass noun. Proper nouns, direct references and descriptive expressions usually identify object instances. Attributes identify either object instances or their measurable properties. Units of measure quantify the masses identified by mass nouns.

Common Nouns

  

The common nouns that serve as the subjects of normalized sentences are of special interest during object-oriented analysis and design. Especially when a subject appears in many statements about a domain problem or usage requirements, the likelihood that it will be a useful object class increases. When a common noun appears only once or a few times, it's more likely that it identifies an instance of a class. When you suspect that the common noun refers to an instance, try to identify the associated class.

People are often identified or described by the roles they play in relationships, and there are natural associations between the nouns that identify roles and the verbs that identify relationships. For example, the employment relationship has two roles - employer employs employee.

Proper Nouns

  

A proper noun identifies a specific object - e.g., Albert Einstein (a person). For conceptual models, a sentence that contains such a direct instance reference should usually be supplemented by sentence that contains an appropriate common noun.

Albert Einstein taught at Princeton University.
A professor teaches students at a university.

In other words, the expression of a fact should usually be supplemented by an appropriate fact type. The right common noun will depend in part on the verb of the sentence and the semantic role being played by the proper noun.

Direct References

  

A direct reference identifies an existing object. As Abbott6 indicates:

"If a term refers to something that is already known to exist, and the term is simply a way to refer to that known thing, then it is considered a direct reference and is associated with the object."

For example, while "the artist formerly known as Prince" may seem vaguely descriptive, it actually refers to a specific individual, whatever he chooses to call himself. If a direct reference is used as the subject of a sentence, it should be replaced by the indicated subject. If a direct reference seems to be isolated, it may be appropriate to associate it with its class - i.e., avoid naked global references unassociated with any class.

Descriptive Expressions

  

Descriptive expressions identify some potential object instance(s), usually selected from some collection (or less frequently from a class). As Abbott6 notes:

"If a term describes a possible object whose identity (and possibly even whose existence) must be determined by some computation - no matter how simple the computation - then the term is a descriptive expression and is associated with the operator that performs the computation."

The computations needed to select the qualifying instance(s) should be identified as part of a domain model. If the descriptive expression always selects a single individual, it may be turned into the name of an object attribute.

Attributes

  

An attribute identifies a property, characteristic, association, or component. This typically involves some computation, e.g., a function that takes a subject as an argument and returns the desired attribute of that subject as the result.

Mass Nouns

  

A mass noun names a quality, activity, or substance - i.e., a continuous mass. Examples include reliability (a quality), work (an activity), and water (a substance).

Units of Measure

  

Each mass has some unit(s) by which the mass may be measured - i.e., divided into units via measurement. For example, mean time between failures (MTBF) is often used as a measure of reliability, man-hours is sometimes used to measure work, and acre-feet can be used to measure volumes of water.

Measurements

Together, mass nouns, units of measure and measurements form a measurement framework. Measures and measurements (numerical values) partition continuous masses into discrete units. These units can then be operated upon as individuals, similar to the instances of a class. In fact, for this reason, mass nouns are sometimes used as class names in object-oriented designs. For example, Money (wealth) is sometimes modeled as an amount + a currency (dollars, franks, pounds, etc.).

Continuous

Discrete

Many object attributes are expressed in terms of mass nouns and their units of measure. For example, physical objects usually have physical properties such as color, position, length, duration, temperature, speed, etc. Domain models that include representations of physical objects often include and operate on some of the properties associated with the objects.

Inquiry of Subjects

The following table provides a schema for the kinds of nouns frequently found in human discourse and the questions that elicit them. The kinds of roles listed are representative and identify only broad categories. Naturally, each relationship will have specific roles appropriate to the verb that identifies the relationship.

Question Roles Example
Who? Agent messenger
Recipient audience
Companion passenger
Question Things Example
What? Instrument hammer
Object envelope
Material silver
Animal mouse
Quality honesty
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Question Locations Example
Where? Place market
Whence? Source origin
Whither? Destination target
Question Quantities Example
How Far? Distance 100 microns
What Kind? Measure temperature
Dimension meter
How Long? Duration 100 years
When? Time 5:55am EST
June 2, 1956 AD

Adjectives

Adjectives describe or limit nouns as parts of noun phrases. Thus, adjectives can be classified as descriptive or limiting (including adjectives of degree).

Description

  

Few descriptive adjectives are pure. Many more descriptive adjectives are derived from or related to either nouns or verbs, and so retain much of the semantic character of their nominal or predicative roots. A descriptive adjective can indicate:

  • the character or mood of a person
  • a disposition (state) of an object (or person)
  • a quality of an event or an object
  • the shape, size, or location of a place or an object

Pure adjectives are simple words with a unique root - i.e., they are not derived from either a noun nor a verb. However, nouns and verbs can be derived from pure adjectives, and pure adjectives may also be used as nouns or verbs. When pure adjectives are used as nouns or verbs, they retain their essential character as adjectives. Thus, when a pure adjective is used as a verb, it means "to make or become" whatever the adjective means. For example:

still adj motionless, quiet, calm.
still v to make or become motionless or silent.

When a pure adjective is used as a noun, the noun identifies something that has the quality described by the adjective. For example:

sweet adj pleasing to the taste, ...
sweet n something that is sweet to the taste.

Pure adjectives that describe personal characteristics and moods rarely play a role in object-oriented software designs. This likely results from the fact that software designs are oriented toward describing objects and their behaviors. Thus, they tend to focus more on disposition, shape, size, location and less personal qualities such as age and speed. The following table provides a representative sample of some pure adjectives that can be found in English.

Indication   Examples
character   able, bold, brash, chaste, clever, cruel, daft, deft, dumb, feeble, frank, glib, honest, humble, kind, just, lay, loyal, mean, meek, mild, modest, naïve, nasty, nimble, pert, rash, rude, sane, sly, smart, stalwart, suave, thorough, vain, wicked, wise, wry
mood   dour, eager, fierce, fond, gay, giddy, glad, grim, happy, jolly, lewd, mad, mellow, merry, proud, queasy, rapt, sad, shy, smug, stern, sullen, sultry, sure, surly, timid
disposition   bare, bright, clean, clear, cold, damp, dark, dry, early, empty, faint, fair, free, fresh, full, hard, hot, ill, lame, late, lax, light, naked, new, nude, numb, open, pretty, ripe, safe, sick, slack, soft, sore, tame, tardy, tense, tough, warm, well, whole, wet
quality   agile, apt, bad, brisk, cheap, common, crude, dire, eerie, evil, false, fast, fine, foul, gross, harsh, mere, mild, neat, old, pale, plain, poor, prompt, pure, queer, quick, quiet, rank, rare, ready, real, rich, rife, right, savage, shrill, slick, slow, sour, spry, stale, stark, still, strange, strong, swart, sweet, swift, tart, terse, true, ugly, vague, vile, weak, weird, wild, wrong, wrought, young
shape   blunt, coarse, deep, dense, dull, fat, firm, fit, flat, flimsy, frail, lean, level, limp, lithe, long, loose, lush, narrow, raw, rough, round, shabby, shallow, sharp, sheer, short, sleek, slender, slight, slim, smooth, steep, stiff, stout, straight, svelte, tall, taut, thick, thin, tight, wide
size   big, equal, grand, great, large, least, less, little, meager, same, scant, small, vast
location   close, far, high, last, low, main, major, mid, minor, near, next, prior

Limitation

  

Limiting adjectives supply (or indicate the need for) quantitative information about subjects and objects, including number, order, degree, etc. Their presence indicates quantitative areas of a conceptual model that should be explored and specified more concretely during object-oriented analysis - i.e., specific numbers that characterize the limitations of the relationships should be obtained from the domain experts. For example, are the relationships 0..1, 1, 0..n, 1..n, or some other interval? The following table provides a schema for the kinds of limiting adjectives frequently found in human discourse and the questions that elicit them.

Question Quantity Examples
What Portion? Partition 1 / 3
Which? Ordinality 1st, 2nd, 3rd, ...
How Many? Cardinality 1, 2, 3, ...
How Many Times? Iteration 20 times
Multiplication 20 fold
How Much? Degree close - closer - closest, ...
Whether? Affirmation always, every, ...
Negation none, never, ...
Doubt maybe, ...

Degrees

  

Many adjectives have degrees and can be related as positive, comparative, and superlative. Most descriptive adjectives that have degrees can be extended by the suffixes -er and -est to build their comparative and superlative forms. The following list provides some examples. Note that some adjectives of degree do not follow the normal pattern, but require alternate derivations (see "bad" and "good" below).

  • bold - bolder - boldest
  • sad - sadder - saddest
  • cold - colder - coldest
  • bad - worse - worst
  • good - better - best
  • deep - deeper - deepest
  • great - greater - greatest
  • close - closer - closest

The presence of descriptive degrees in a discussion indicates that the described quality may be measurable (i.e., quantifiable). This has important implications for further analysis and the design of related software components. It likely indicates the need to represent a measurable quantity as an attribute (e.g., a variable) in some software component. For example, coldness, depth, and distance (closeness) are all measurable quantities that will likely become variables or constants used for representation and computation within a software system.

Derivation

  

In English, many descriptive adjectives are derived from nouns or verbs, especially those with Latin and Greek roots. Most often, descriptive adjectives derived from nouns and verbs are used in the names of classes and/or their instances, especially when the adjectives describe a disposition, quality, shape, size or location.

The following table provides representative examples of descriptive adjectives that have been derived from nouns and verbs. Note that just as adjectives may be derived from nouns and verbs, the process may be reversed to reveal the nouns and verbs that provide their roots. Thus, descriptive adjectives can serve as a rich source for object and predicate discovery (or recovery).

Indication   from Nouns   from Verbs
character   demon + ic = demonic
journalist + ic = journalistic		   dash + ing = dashing
presume + ous = presumptuous
mood   ire + ate = irate
lust + ful = lustful		   covet + ous = covetous
devote + ed = devoted
disposition   continent + al = continental
idea + al = ideal		   initialize + ed = initialized
vis + ible = visible
quality   hazard + ous = hazardous
myth + ical = mythical		   express + ive = expressive
transfer + able = transferable
shape   circle + ular = circular
ellipse + ical = elliptical		   encircle + ed = encircled
fold + ed = folded
size   giant + ic = gigantic
titan + ic = titanic		   enlarge + ed = enlarged
truncate + ed = truncated
location   clavicle + ular = clavicular
distance + (degree) = distant		   elevate + ed = elevated
previ + ous = previous

Adverbs

Adverbs modify verbs, adjectives and adverbs, or they bind phrases together. Adverbs can be categorized as descriptive, interrogative, demonstrative, conjunctive.

Descriptive

  

Descriptive adverbs can indicate affirmation, negation, doubt, reason, degree, manner, direction, place, location, number, time. Most descriptive adverbs are merely decorated adjectives - e.g., "quickly" is derived from "quick." If you strip off the -ly suffix, the adverb reveals the adjective from which it was derived. Reducing an adverb to its corresponding adjective entails further examination of the related sentence elements that were modified by the adverb. Further reduction and/or interpretation may be needed to reveal the meaning of the phrases involved. Consider this in light of the previous discussions regarding adjectives, nouns, and verbs.

Interrogative

  

Interrogative adverbs include whence, where, whither, when, how, why. However, while such questions may arise during the consideration of problems, they will rarely (if ever) appear as adverbs in problem descriptions, especially as resolving such questions is one of the primary goals of developing a coherent problem description and its corresponding conceptual models.

Demonstrative

  

We can observe similar restrictions for the demonstrative adverbs such as hence, here, hither, then, thence, thither, thus. While they serve a useful purpose as a kind of connective tissue in the body of narrative papers and normal rhetoric, they rarely have a place in problem descriptions and conceptual models.

Conjunctive

  

Conjunctive adverbs may be treated as variants of conjunctions as described in the next section.

Conjunctions

Conjunctions bind phrases and clauses together. Conjunctions can be categorized as coordinate, subordinate, correlative. Coordinate conjunctions connect elements of equal rank - words, phrases, clauses. Subordinate conjunctions connect dependent elements to independent ones. Correlative conjunctions are used in pairs - one complementing the other. Some correlatives are coordinate and some are subordinate. The following table provides a representative organization of the various kinds of conjunctions.

Category Subcategory Examples
coordinate additive also, and, besides, both, likewise, moreover, then
adversative but, however, nevertheless, notwithstanding, still, yet
disjunctive but, either, else, or, neither, nor, other, otherwise
final consequently, for, hence, so, thus, therefore
subordinate reason as, because, for, hence, inasmuch, since, whereas, wherefore
degree as, else, other, otherwise, rather, than
concession although, provided, nevertheless, save, though
condition if, provided, since, unless
manner as, how
place after, before, whence, whereat, wherever
purpose lest, that, so that
time as, before, ere, since, still, till, until, when, whenever
correlative both-and Both boys and girls are going.
either-or Either boys or girls will go.
neither-nor Neither boys nor girls will go.
if-then If you fail, then must try again.

Coordination

Coordinate conjunctions that connect words and phrases should usually be eliminated when building a conceptual model, especially if the phrases combine subjects or verbs. Compounded subjects and verbs need to be separated so that they may be modeled independently.

Compound Subjects
The dog and the cat play with the mouse.
The dog plays with the mouse. The cat plays with the mouse.

Compound Verbs
The cat catches and eats the mouse.
The cat catches the mouse. The cat eats the mouse.

Compounded clauses usually need to be kept together, especially when they express comparative relations - i.e., relations that express conditions.

the building stores type 1 hazardous chemicals and
the building stores type 2 hazardous chemicals

a building's drum storage count equals its drum storage limit and
a neighbor's drum storage count equals its drum storage limit

Subordination and Correlation

Likewise, clauses connected with subordinate and correlative conjunctions should usually be kept together. However, doing so may require the replacement of the conjunction with a suitable verb along with the nominalization of the verbs in the correlated clauses - i.e., naming the condition described by the dependent clause and naming the action described by the independent clause. For example, consider the reformulation of the following rule:

if a chemical storage facility commits a safety violation,
then the EPA closes the chemical storage facility.

A chemical storage facility commits a safety violation = a safety emergency. The EPA closes a chemical storage facility = a facility closure.

A safety emergency triggers a facility closure.

Articles

Articles may indicate cardinality, or they may distinguish between concrete instances and abstractions. For example, the definite article "the" may indicate a specific instance of a class, or it may indicate a singleton - i.e., the only instance of a class. For example, contrast the followng two uses of the definite article.

The Environmental Protection Agency is an instance of a regulatory agency.

The loading bay of a chemical storage depot is the only place where chemical storage drums may be delivered and collected.

The use of the indefinite article "a" always indicates one of (usually) several instances of a class. So, it is always appropriate to ask how many instances of the abstraction exist? The definite article may also be used to reference a previously mentioned abstraction. Consider:

When a cat chases a mouse, the cat will likely capture it.

Such referential uses of the definite article do not reduce the abstractive force of the indefinite article - i.e., using "the" after "a" to reference a subject does not force the subject to be specific.

Interjections

Interjections seldom appear in domain models. However, they do have a place in usage models, especially in the design of human interfaces. Warnings, errors, alerts, and other informative disclosures play a central part in guiding the user toward the correct use of a system. In graphical user interfaces, these messages often appear as dialogs that interrupt the normal processing flows. Some visual dialog styles even include related iconography - e.g., an exclamation mark.

Formulating Problems and Requirements

Problem descriptions express the relationships and actions that exist between the elements of a problem domain. Usage requirements express the objectives and goals of the problem solution users, and the actions they initiate when using a computer system to solve their problems. The narrative description of a problem and the uses of a solution can be analyzed for their concepts and modeled using a conceptual modeling notation.1,2,3 Such formal models can serve as the basis for establishing commonality. They also serve as excellent preparation for object-oriented analysis and software design.

Problem descriptions typically articulate conditions, constraints and rules that pertain to a problem domain. A condition compares or determines the value(s) of some object attribute(s). Conditions may stand alone, but they are also frequently combined with actions and other conditions. A constraint describes a condition that must be maintained - e.g., as an equilibrium. A behavior rule combines a condition with an imperative action. A knowledge rule combines a condition with a declarative assertion.

Element Expresses Example
condition a comparative relation a storage building's drum count exceeds the storage building's licensed drum limit.
constraint a condition that must be maintained a storage building's license limits the storage building's drum count.
behavior rule the action that must be taken when a condition (event) arises a safety emergency triggers a facility closure
knowledge rule the logical implication of a condition that arises an empty depot loading bay allows drum delivery initiation or drum collection initiation

Formulating Objectives and Goals

Requirements specifications may identify the purposes of a system, but they will typically enumerate a broad set of objectives, as well as detailed goals that need to be satisfied by system usage - i.e., as use cases.10 A purpose usually indicates a direction or mission - e.g., with a simple verb. An objective provides more detail, including the desired condition to be achieved and some kind of time frame for achieving it (however, the timing may be vague or indefinite). A goal provides the greatest level of detail, including a very specific description of the target condition and a specific time by which to achieve it. The following table provides a summary of the foregoing ideas.

Element Expresses Example
purpose a direction or mission learn about linguistics
objective a condition and time frame within which to achieve it learn how linguistics impacts software design in one sitting
goal a specific target condition to achieve by a specific time apply the practice of linguistic analysis to your next software development project during the next three months

Requirements specifications often include non-functional requirements, especially expressed as objectives for Quality of Service (QoS). Objectives included in requirements are often expressed as adjectives. Such adjectives characterize the desirable qualities of a software system and the process that produces it. Each of these qualities must be further defined in measurable terms to determine whether a system exhibits the desired quality or to what degree (i.e., as success criteria). A representative sample of desirable qualities organized by their area of focus can be found listed in the companion paper on Quality Inventories.

References

  1. Grady Booch, Ivar Jacobson, James Rumbaugh. The Unified Modeling Language. Rational Software, 1997. For further information, refer to the Rational home page at http://www.rational.com/.
  2. John Sowa. Conceptual Structures: Information Processing in Mind and Machine. Addison-Wesley, 1984.
  3. Nik Boyd. A Natural Conceptual Modeling Language. This paper introduces a new simplified graphical notation for conceptual models and provides an extensive example of its application to a sample problem.
  4. John Opdyke. Harper's English Grammar. Warner Books, Inc., August, 1987.
  5. Robert Carasik, Steve Johnson, Donald Patterson, George Von Glahn. Towards a Domain Description Grammar: An Application of Linguistic Semantics. ACM SIGSOFT Software Engineering Notes 15(5):28-43, Oct. 1990.
  6. Russell Abbott. Program Design by Informal English Descriptions. Communications of the ACM 26(11):882-894, Nov. 1983.
  7. Motoshi Saeki, Hisayuki Horai, Hajime Enomoto. Software Development Process from Natural Language Specification. Proceedings of the 11th International Conference on Software Engineering (ICSE-11), IEEE Computer Society Press, 1989.
  8. René Thom. Structural Stability and Morphogenesis: An Outline of a General Theory of Models. Benjamin-Cummings Publishing, 1975.
  9. Donald Firesmith, Brian Henderson-Sellers. Clarifying Specialized Forms of Association in UML and OML. Report on Object Analysis and Design in the Journal of Object-Oriented Programming, JOOP (11)2:47-50, May 1998.
  10. Alistair Cockburn. Structuring Use Cases with Goals. Humans and Technology, HaT.TR.95.01, 1995. Another variation of this paper appeared in the Journal of Object-Oriented Programming JOOP 10(5), Sept.97, "Goals and Use Cases", pp.35-40. JOOP 10(6), Nov. 97, "Using Goal-based Use Cases", pp.56-62.