UML Weekend Crash Course™ - To Parent Directory

40
Friday Evening
An Inventory Control System
Now to the nitty-gritty part you’ve been waiting for! As a hands-on opportunity to explore
the diagramming techniques, you’ll work on modeling the inventory control system.
Although you won’t be able to build a complete model, you’ll have ample opportunity to try
the UML modeling notation in a reasonably realistic setting.
The goal of this course is to build at least one of each type of diagram to model the
inventory control system. This should provide a representative sampling of how each type of
diagram may be applied to understand and to solve a problem.
Beginning with user requirements and progressing through the logical modeling of
classes and objects and their interactions, you will move on to process modeling, and finally
implementation modeling. In each session, I explain the use of each diagram and the notation
used to express the model fully.
Identifying requirements
There is a wealth of material in bookstores on gathering and documenting requirements.
The variety is a reflection of the diversity of applications under development. Some of the
techniques can be large and sophisticated. But because this book is intended as a crash
course, I don’t want you to get diverted from the focus, which is applying the UML modeling
language to describe systems. So I take a simplified approach.
One approach to gathering requirements is to look for them by examining the problem
statement and the supporting documents and interviews from different perspectives. Using
these different perspectives also helps to validate the requirements by giving you the
opportunity to compare and contrast what you find from three overlapping sources:
Users: Users have expectations for the use of the system.
Resources: Resources are represented as information that is created, used, and
deleted by the system to support the system behavior.
Functionality: Functionality refers to the behavior supported by the system.
While you’re researching the problem from each unique perspective, be on the lookout
for the four different types of requirements discussed earlier.
Users
Someone or something (another system or device) is going to communicate with your system.
You need to know why and what they expect from their communication with the system.
Consequently, the questions you ask should focus on the users’ responsibilities that
make them dependent upon the system or that make them an essential source of information
for the system.
As you read through these questions, try to imagine the answers you may receive from
the actors in the case study. You’ll need that information to build the diagrams in the
remaining chapters.