Database Reference
In-Depth Information
lead to the specification of the requirements of such systems. Examples include (but are
not confined to) the following:
•
Writing a new compiler
•
Writing a new operating system
•
Writing a new CASE tool, RAD tool, or DBMS
•
Developing certain expert systems
•
Developing a business in a problem domain for which there is no
perfect frame of reference
For these kinds of scenarios, a non-standard approach to information gathering is
required. Brainstorming is particularly useful here. A close to accurate coverage of the
requirements of an original software product may be obtained through brainstorming: a
group of software engineering experts and prospective users come together, and through
several stages of discussion, hammer out the essential requirements of the proposed
software. The requirements are then documented, and through various review processes,
are further refined. A prototype of the system can then be developed and subjected to
further scrutiny.
Even where more conventional approaches have been employed, brainstorming
is still relevant, as it forces the software engineering team to really think about the
requirements identified so far, and ask tough questions to ascertain whether the
requirements have been comprehensively and accurately defined.
Mathematical proofs can also be used to provide useful revelations about the
required computer software. This method is particularly useful in an environment where
formal methods are used for software requirements specification. This approach is often
used in the synthesis of integrated circuits and chips, where there is a high demand for
precision and negligible room for error.
A3.8 Object Identification
We have discussed six different information-gathering strategies. As mentioned in
section A3.1, these strategies are to be used to identify the core requirements of the
software system. As mentioned then, one aspect that we are seeking to define is the set
of information entities (object types). Notice that the term information entity is used
as an alternative to object type. The two terms are not identical, but for most practical
purposes, they are similar. An information entity is a concept, object or thing about which
data is to be stored. An object type is a concept, object or thing about which data is to be
stored, and upon which a set of operations is to be defined.
In object-oriented environments, the term object type is preferred to information
entity. However, as you have seen, in most situations, the software system is likely to
be implemented in a hybrid environment as an object-oriented (OO) user interface
superimposed on a relational database.
Early identification of information entities is critical to successful software
engineering in the OO paradigm. This is so because your software will be defined in terms
of objects and their interactions. For each object type, you want to be able to describe the
data that it will host, and related operations that will act on that data. Approaching the
