Object-Oriented Analysis and Design 34711
This rather simple ATM example shows only a fanciful set of interactions, but nailing
down the specifics of these interactions can be a powerful tool in understanding both the
problem domain and the requirements of your new system.
Creating Packages
Because you generate many use cases for any problem of significant complexity, the
UML enables you to group your use cases in packages.
A packageis like a directory or a folder—it is a collection of modeling objects (classes,
actors, and so forth). To manage the complexity of use cases, you can create packages
aggregated by whatever characteristics make sense for your problem. Thus, you can
aggregate your use cases by account type (everything affecting checking or savings), by
credit or debit, by customer type, or by whatever characteristics make sense to you.
More important, a single use case can appear in different packages, allowing you great
flexibility.
Application Analysis ......................................................................................
In addition to creating use cases, the requirements document must capture your cus-
tomer’s assumptions, and any constraints or requirements concerning hardware and oper-
ating systems, security, performance, and so forth. These requirements are your
particularcustomer’s prerequisites—those things that you would normally determine
during design and implementation but that your client has decided for you.
The application requirements (sometimes called “technical requirements”) are often dri-
ven by the need to interface with existing systems. In this case, understanding what the
existing systems do and how they work is an essential component of your analysis.
Ideally, you analyze the problem, design the solution, and then decide which platform
and operating system best fits your design. That scenario is as ideal as it is rare. More
often, the client has a standing investment in a particular operating system or hardware
platform. The client’s business plan depends on your software running on the existing
system, and you must capture these requirements early and design accordingly.
Systems Analysis ............................................................................................
Some software is written to stand alone, interacting only with the end user. Often, how-
ever, you will be called on to interface to an existing system. Systems analysisis the
process of collecting all the details of the systems with which you will interact. Will your
new system be a server, providing services to the existing system, or will it be a client?
Will you be able to negotiate an interface between the systems, or must you adapt to an
existing standard? Will the other system be stable, or must you continually hit a moving
target?