Lesson 1

It is tempting and in fact common for analysts to use only the class diagram. After all, the class diagram is the only diagram used to generate code. The other diagrams are just tools to help understand the classes. Right?
Answer: No, this is not correct.
The problem with this thinking is that the class diagram has a very limited perspective of the problem domain. The class diagram shows only the static structure of the classes and their relationships to one another. The class diagram does not show how the objects will behave when the system is in use. The class diagram is like a blueprint for a building. You can see what materials are used, where they are located, and the individual specifications or potential of each component. For example, you can see the capacity of the power circuits, the size of the water heater, and the heating capacity of the furnace. But you cannot see what happens when a door is left open on a cold day. You cannot see the change in water temperature after four consecutive showers when everyone gets ready in the morning. To see the behavior of the resources, you need models that describe how the resources will be used. In these other models, you can see the interactions between classes, the creation and disposal of resources, and the patterns of collaborations for each behavior.

Class diagrams are the most popular UML diagrams used by the object oriented community. It describes the objects in a system and their relationships. Class diagram consists of attributes and functions.
A single class diagram describes a specific aspect of the system and the collection of class diagrams represents the whole system. Basically the class diagram represents the static view of a system.
Class diagrams are the only UML diagrams which can be mapped directly with object oriented languages. So it is widely used by the developer community.

The other UML diagrams model facts as objects and these objects either conform to the rules set forth in the Class diagram, or they reveal the need for corrections to the rules. The rules in the Class diagram are used to generate code. The code generates objects, while the application is running, that behave according to the rules defined by the Class diagram. Systems may be fairly complex and may require more than one Class diagram. It is very common to break a subject area down into a set of smaller Class diagrams. Smaller diagrams are easier to work with and easier to verify, but no matter how many diagrams you use for the system, each class has only one definition.

A class represents the same concept no matter where or how often it appears in the diagrams. In a modeling tool, this is accomplished by using a repository. A repository is a shared dictionary, usually built into the modeling tool, of all of the information defined during the modeling process. The first time you add a class to a diagram, a definition is placed into the repository by the tool. Each subsequent time that the class is referenced on a new diagram, the new reference is associated with the existing definition. Consequently, a change made to a class on one diagram is also made to the class definition in the repository, and is reflected in all diagrams that include that class.
Defining all of these rules sounds quite complicated. In truth, the notations of the Class diagram provide a surprisingly simple yet powerful means to specify everything needed to generate code. With rigor and the proper software support, the Class diagram can even become fully executable. This means that the model can be tested by executing scenarios and can even generate the complete application in a variety of implementation environments.

Most of us manage our money by keeping a checking account. As we use the account, we keep a record of the transactions in the register. But how do we confirm that our records are accurate? We compare them against another record of the same transactions, a record that is maintained in a different place and in a different form than our own record.

• Compare and Contrast two Views Comparing and contrasting the two views make it possible to recognize discrepancies more easily. Once a discrepancy is found, it can be diagnosed and corrected. In addition, quite often the contrast itself will help reveal the cause of the discrepancy. The correctness of the register contents cannot be verified using only the register. The same is true of diagrams. One diagram by itself is very difficult to verify. But when different diagrams of the same problem are used together, then the process of comparing and contrasting the diagrams reveals potential problems.

This module covers a few ways to compare the different diagrams and provides some typical questions to pursue when you identify discrepancies. In this module you will learn:

1. The importance of using different views to find discrepancies and opportunities for enhancement
2. How to test scenarios
3. How to test classes
4. How to test interfaces
5. How to recognize the patterns for reconciliation