 Hello and welcome to the session on Unified Modeling Language. In this video, we learn how to draw class diagram and object diagram for a software system to be designed. At the end of this session, students will be able to understand building blocks of UML, analyze things, relationships and diagrams in UML, and draw class diagram and object diagram of UML representing designs to be used for software development. You have already learnt about OMT i.e. Object Modeling Technique in earlier videos. Now pause the video for a while and try to answer this question. What could be another approach to model a system apart from OMT? Here is the answer. It is the Unified Modeling Language i.e. UML. The contents we are going to cover are building blocks of UML, class diagram and object diagram. To start with, these are three important blocks in UML namely things, relationships and diagrams. Things are the abstractions that are first class citizens in a model. Relationships tie these things together and diagrams group interesting collections of things. There are four kinds of things in the UML namely structural things, behavioral things, grouping things and annotational things. Starting with the structural things. Structural things are the nouns of UML models. These are the mostly static parts of a model representing elements that are either conceptual or physical. In all, there are seven kinds of structural things. First, a class is a description of a set of objects that share the same attributes, operations, relationships and semantics. A class implements one or more interfaces. Graphically, a class is rendered as a rectangle, usually including its name, attributes and operations as shown in figure with three different compartments. Second, interface is a collection of operations that specify a service of a class or component. It describes the externally visible behavior of that element which might represent the complete behavior of a class or component or only a part of that behavior. Graphically, an interface is rendered as a circle together with its name. An interface rarely stands alone. Rather, it is typically attached to a class or component that realizes the interface as shown in figure two. Third, a collaboration defines an interaction which represents the implementation of patterns that make up a system. Graphically, a collaboration is rendered as an ellipse with dashed lines, usually including only its name as in figure three. Next, a use case is a description of a set of sequence of actions that a system performs that yields an observable result of value to a particular actor. Graphically, a use case is rendered as an ellipse with solid lines, usually including only its name as shown in figure four. Next, an active class is a class whose objects own one or more processes or threads and therefore can initiate control activity. It is just like a class except that its objects represent elements whose behavior is concurrently with other elements. Graphically, an active class is rendered just like a class but with heavy lines usually including its name, attributes and operations as shown in figure five. The next, a component is a physical and replaceable part of a system that conforms to and provides the realization of a set of interfaces. Graphically, a component is rendered as a rectangle with tabs usually including only its name as in figure six. The next, a node is a physical element that exists at runtime and represents a computational resource. A set of components may reside on a node and may also migrate from node to node. Graphically, a node is rendered as a cube usually including only its name as in figure seven. Behavioral things are the dynamic parts of UML models. These are the verbs of a model representing behavior over time and space. In all, there are two primary kinds of behavioral things. Number one, a message is rendered as a directed line almost always including the name of its operation as shown in figure eight. Second, a state is rendered as a rounded rectangle usually including its name and its substates if any as shown in figure nine. Grouping things are the organizational parts of UML models. These are the boxes into which a model can be decomposed. In all, there is one primary kind of grouping thing namely packages. A package is a general purpose mechanism for organizing elements into groups. Structural things, behavioral things and even other grouping things may be placed in a package. Graphically, a package is rendered as a tabbed folder usually including only its name and sometimes its contents as shown in figure ten. Annotational things are the explanatory parts of UML models. There is one primary kind of annotational thing called a node. A node is simply a symbol for rendering constraints and comments attached to an element or a collection of elements. Graphically, a node is rendered as a rectangle with a dog eared corner together with a textual or graphical comment as shown in figure eleven. There are four kinds of relationships in the UML namely dependency, association, generalization and realization. A dependency is a semantic relationship between two things in which a change to one thing which is the independent thing may affect the semantics of the other thing, the dependent thing. Graphically, a dependency is rendered as a dashed line possibly directed and occasionally including a label as shown in figure twelve. An association is a structural relationship that describes a set of links, a link being a connection among objects. Aggregation is a special kind of association representing a structural relationship between a whole and its parts. Graphically, an association is rendered as a solid line possibly directed occasionally including a label and often containing other adornments such as multiplicity and roll names as shown in figure thirteen. A generalization is a specialization-generalization relationship in which objects of the specialized element that is the child are substitutable for objects of the generalized element, the parent. In this way, the child shares the structure and the behavior of the parent. Graphically, a generalization relationship is rendered as a solid line with a hollow arrowhead pointing to the parent as shown in figure fourteen. A realization is a semantic relationship between classifiers wherein one classifier specifies a contract that another classifier guarantees to carry out. We will encounter realization relationships in two places between interfaces and the classes or components that realize them and between use cases and the classes or components that realize them. Graphically, a realization relationship is rendered as a cross between a generalization and a dependency relationship as shown in figure fifteen. Next, a diagram is a graphical presentation of a set of elements most often rendered as a connected graph of vertices, those are things and arcs which are relationships. The UML includes nine such diagrams namely class diagram, object diagram, use case diagram, sequence diagram, collaboration diagram, state chart diagram, activity diagram, component diagram and deployment diagram. A class diagram shows a set of classes, interfaces and collaborations and their relationships. These diagrams are the most common diagrams found in modeling object oriented systems. Here is an example of a class diagram. As we can see, there is a class named as company which is generalized into department and office. Each class can be seen with three different compartments, first with its name, second with its attributes and third with its operations. Department is next connected to person, person is associated to contact information and personal record and office has a headquarter. The different list of attributes and operations can also be seen in this class diagram. Next is the object diagram. An object diagram shows a set of objects and their relationships. These diagrams address the static design view or static process view of a system as do class diagrams but from the perspective of real or prototypical cases. Here is an example of an object diagram which is drawn for the same class diagram shown earlier. We have instantiated each of the classes namely company, department, person and contact information. As you can see, C is a variable instantiated for company, D1 and D2 as well as D3 are the departments with names corresponding to sales, R&D, US sales respectively. Person instantiated into name is equal to Erin employee ID 4362 and title equal to VP of sales. So we can see how the attributes are given values in every object. Here is a time for think and reflect. Pause the video for a while and try to answer this question. A class is divided into which of these compartments and the answer is all of dimension. Because as we have seen in the example class diagram, each class is represented as a rectangle which has three different compartments. First for its name, second for the list of attributes and the third for the list of operations. Thank you.