As we began to learn about Java technologies at Amway Corp, we were introduced to UML (Unified Modeling Language). We became interested in the modeling aspect of UML to assist in the analysis and design phases of our Java project. So we decided to try our hand at modeling with UML. It began with 2 week-long training classes. 1) Object-Oriented Analysis with UML 2) Object-Oriented Design with UML These classes taught us about application requirements gathering, analysis and design with UML. The classes were taught without the use of any software modeling tools. The work was all done via paper and whiteboards. Really! In the classes, we learned of the many, many UML diagrams that were at our disposal. We also saw how each UML diagram can be used in a variety of ways. After the training, we set out to define a project standard for the use of UML diagrams in the analysis and design phases of our project. Data Model diagrams and Application Architecture diagrams were not part of the standard. For requirements gathering and analysis (which defined the "what", not the "how"), we specified "Business View" use-case diagrams. These were diagrams from the Actors point of view. We found these diagrams especially useful for the GUI portions of the application. We also specified "System View" use-case diagrams. These were diagrams from the System behavior point of view. We found these diagrams especially useful for the Batch Processing portions of the application. We specified a use-case document as well. This document contained the use-case Description, Actors, Scenarios, Pre and Post Conditions, and Data Requirements. For application design, we specified class diagrams. This resulted in some debate about how granular the class diagrams should be. Our UML training class recommended using high-level class diagrams and then more detailed class diagrams. Our software modeling tools vendor advised using class diagrams to generate Java code directly. We did neither. We used class diagrams to design only the "critical" processes and functions of our application. No Java code was generated from a class diagram. Our class diagrams included a class' name, attributes, and operations. These diagrams worked well for illustrating the "static" view of the application. If "dynamic" views of the application were needed, we specified sequence diagrams (for GUI) and activity diagrams (for Batch Processing). These last two diagram types were optional for application design. 10 years later... We created a large set of UML diagrams; mostly use-case and class diagrams. The use-cases became very visible. We reviewed them with our business analysts\users often. We even created a type of use-case called a "mis-use" case. That is, a requirement of "what NOT to do"! You might see a class diagram on someone's office wall today. As usual, there is no ONE right way to do things. This certainly applies to UML. Whatever "works" for you is the right way. The actual diagram you create is not as important as the thinking process that led to it. Application software modeling, with UML, is not for everyone. It remains a "specialized" skill that we use when we need it.