UML Concepts

    

                                                                                                              -SatyaSwati

Welcome back . Now we'll continue with the discussion on UML concepts

3) The Object Diagram:

Although we design and define classes, in a live application classes are not directly used, but instances or objects of these classes are used for executing the business logic. A pictorial representation of the relationships between these instantiated classes at any point of time (called objects) is called an "Object diagram." It looks very similar to a class diagram, and uses the similar notations to denote relationships.

If an object diagram and a class diagram look so similar, what is an object diagram actually used for? Well, if you looked at a class diagram, you would not get the picture of how these classes interact with each other at runtime, and in the actual system, how the objects created at runtime are related to the classes. An object diagram shows this relation between the instantiated classes and the defined class, and the relation between these objects, in the logical view of the system. These are very useful to explain smaller portions of your system, when your system class diagram is very complex, and also sometimes recursive.

Elements of an Object Diagram:

Because an object diagram shows how specific instances of a class are linked to each other at runtime, at any moment in time it consists of the same elements as a class diagram; in other words, it contains classes and links showing the relationships. However, there is one minor difference. The class diagram shows a class with attributes and methods declared. However, in an object diagram, these attributes and method parameters are allocated values.

A class that defines the flow of the system is called as an active class. This class instance in the object diagram is represented by thick border. In an MVC application architecture, the controller servlet is the action class, and is denoted by a thicker border. Also, multiple instances of the same class, as in a factory pattern, if the attributes of the individual objects are not important, or are not different, these can be represented by a single symbol of overlapping rectangles (see Figure 3.1):

Figure 3.1—the object diagram for a Factory class

A class that performs more than one role, and is self-linked, is represented by a curve starting and ending on itself, as illustrated in Figure 3.2:

Figure 3.2—the object diagram for a self-linked class

Significance:

• A set of objects (instances of classes) and their relationships.

• A static snapshot of a dynamic view of the system.

• Reperesent real or prototypical cases.

4) The Sequence Diagram:

A Sequence diagram depicts the sequence of actions that occur in a system. The invocation of methods in each object, and the order in which the invocation occurs is captured in a Sequence diagram. This makes the Sequence diagram a very useful tool to easily represent the dynamic behaviour of a system. A Sequence diagram is two-dimensional in nature. On the horizontal axis, it shows the life of the object that it represents, while on the vertical axis, it shows the sequence of the creation or invocation of these objects.

Because it uses class name and object name references, the Sequence diagram is very useful in elaborating and detailing the dynamic design and the sequence and origin of invocation of objects. Hence, the Sequence diagram is one of the most widely used dynamic diagrams in UML.

Defining a Sequence diagram:

A sequence diagram is made up of objects and messages. Objects are represented exactly how they have been represented in all UML diagrams—as rectangles with the underlined class name within the rectangle. A skeleton sequence diagram is shown in Figure 8.1. We shall discuss each of these elements in the next section:

Elements of a Sequence diagram

A Sequence diagram consists of the following behavioral elements:

Significance:

• Composed of objects and messages dispatched between them.

• Shows a dynamic view of the system.

• Sequence Diagram exposes time ordering of messages.

• Collaboration Diagram exposes exposes structural organization of messages.

• In some tools (i.e. Rational Rose), these diagrams can be interchanged from the same underlying information.

5) State Diagram:

Until now, we have seen Use Cases, Class diagrams, and Object diagrams. These diagrams give an architectural and high-level view of a system. In a typical software life cycle, the business or functional domain experts define Use Case diagrams. The Class diagrams and Object diagrams are made by senior-level developers, with the help of system architects. Once this has been accomplished, and the system design and architecture is in place, these artifacts are passed on to the developer, who actually codes the system. All the above diagrams are static diagrams, which means that they help in visualizing what the elements of the complete system would be, but do not say anything about the flows any object of the system can have when an event occurs. Structural elements are used to depict static diagrams.

While coding, it is necessary to understand the details of the modes an Object of a Class can go through and its transitions at time intervals with the occurrence of any event or action.

State diagrams (also called State Chart diagrams) are used to help the developer better understand any complex/unusual functionalities or business flows of specialized areas of the system. In short, State diagrams depict the dynamic behavior of the entire system, or a sub-system, or even a single object in a system. This is done with the help of Behavioral elements.

It is important to note that having a State diagram for your system is not a compulsion, but must be defined only on a need basis.

Elements of a State diagram:

A State diagram consists of the following behavioral elements:

Note: Changes in the system that occur, such as a background thread while the main process is running, are called "sub states." Even though it affects the main state, a sub state is not shown as a part of the main state. Hence, it is depicted as contained within the main state flow.

As you saw above, a state is represented by a rectangle with rounded edges. Within a state, its Name, variables, and Activities can be listed

Figure 4.1: the structure of the state element

Creating a State Diagram

Let us consider the scenario of traveling from station A to station B by the subway. Figure 4.2 would be a state diagram for such a scenario. It represents the normal flow. It does not show the sub states for this scenario.

Significance:

• Represents a state machine, composed of states and transitions.

• Addresses the dynamic view of the system.

• Useful for reactive behaviors.

• Important for modeling interfaces, classes, or collaborations