Information Technology Reference
In-Depth Information
Once the relationships between classes is understood, the next process is to
detail the behavior the classes will exhibit and how they will interact in order to
complete the system. This entails determining how the classes communicate and
send messages along the timeline of the system process being developed. This is
derived from the responsibilities of the classes previously identified. Determining
what class the message goes to is a simple matter of following the associations set
up in the previous step.
Throughout the use case analysis so far, attributes of the classes and objects
may have been discovered that are necessary for the classes to complete their
tasks. These could be in the form of data variables or functions. Some of these
attributes can be derived from the previous steps, while others are general
assumptions from common knowledge (e.g. all operational modern-day computers
have an operating system, a processor, and input/output devices).
The final step is to identify components that provide a solution to the problem
domain. This would include databases to hold the data, security, exception han-
dling, and communication between processes or programs.
6.7 Issues in Object-Oriented Analysis
Even with careful identification of sources of information and careful character-
ization of requirements information, there will still be many problems. It is dif-
ficult to provide a clean set of requirements. Software engineers must make sure
that they are addressing the problem and not adding useless enhancements to it.
Software Engineers must continuously think whether the solution to the problem is
important and necessary, or else it's an enhancement. Common problems with
requirement information are (Berard
1993
):
• Omissions: We refer to the process of focusing on the essential (or important)
details of an item or situation while ignoring the inessential. Very often, the
initial set of user-supplied information is incomplete. This means that, during
the course of analysis, the software engineer will be expected to locate and/or
generate new requirements information. This new information is, of course,
subject to the approval of the client.
• Contradictions: Contradictions may be the result of incomplete information,
imprecise specification methods, a misunderstanding or a lack of a consistency
check on the requirements. If the user alone cannot resolve the contradictions,
the software engineer will be required to propose a resolution to each problem.
• Ambiguities: Ambiguities are often due to lack of precision in the specification
method and incompletely defined ideas.
• Duplications: Replication of information in the same format. Software engineer
must be careful in removing these.
• Inaccuracies: Most commonly inaccuracies are due assumptions. These inac-
curacies must be brought to the client's attention and resolved.
