UML basics: The class diagram

The paper 2 talks about the basics of UML (Unified Modeling Language). Before I start summarizing about the paper, I would like to explain the concept of modeling and why it is so important in the software industry. When I started reading this article I was thinking to myself, Why do we use modeling? Why was some language like UML developed? Certainly not to create more job opportunities or to make use of the bench warmers :D.
It certainly must have had some advantages that the software industry has readily accepted and used it since long time.
The goal of a model is to create a meaningful abstraction of real world. Such an abstraction should be simpler than the real world but should accurately reflect the real world so that the model can be used to predict the behavior of the things in the real world. Also, defining a model makes it easier to break up a complex application or a huge system into simple, discrete pieces that can be studied individually. We can focus more easily on the smaller parts of a system and then understand the "big picture". The 2 basic reasons modeling can be thought of as
1. Readability: Modeling brings clarity which is in fact the first step in building or enhancing a system.
2. Reusability: which is a byproduct of readability in the sense that once we understand the system, the model helps in identifying the similarities or redundancy, be they in terms of functionality, features or in terms of the structure itself.

Another question that comes to mind is, Why UML is preferred option used for modeling? The answer is very simple as everyone must have thought, "standardization".

Now that we have accepted the fact that we really need to know UML, cleared mental block about reading this paper, lets talk about it :)

The purpose of the paper is to help readers understand the notation elements, their syntax and their meaning in UML and be able to read diagrams and create their own diagrams using proper notation elements.

In UML 2 there are basically 2 categories of diagrams. The categories and their purpose is as follows:
1. Structure Diagrams: To show the static structure of the system being modeled. The include the class, component, and or object diagrams.
2. Behavior Diagrams: To show dynamic behavior between the objects in the system, including things like their methods, collaborations and activities. Example behavior diagrams are activity, use case, and sequence diagrams.

This paper mainly focuses on class diagram which is a subset of structure diagrams. The purpose of class diagrams is to show the types (class,interface,data type, component) being modeled within the system. These types have a specific name "classifiers".
The basic UML representation of a class is as belows
Inheritance: The inheritance concept in OOP can be pictorially represented using following 2 ways:
A solid line with a closed unfilled arrow/triangle pointing from a child class to the parent class represents a model of inheritance.

Association: This models the relationships between certain objects. There are five types
1. Bi-directional: Two classes are related and both know about the relationship (like marriage of 2 classes)
2. Uni-directional: Two classes are related, only one knows that the relationship exists. This is like one way affair between two classes ;)
3. Association Class: Includes another class which includes valuable info about the relationship. Represented by a dotted line intersecting association solid line between primary classes.
4. Aggregation: Models "whole to its parts" relationship.
(a) Basic- One class is a part of another class. Child class can outlive its parent. Car and Wheel eg.
(b) Composition -Child class's instance life cycle is dependent on the parent class's instance life cycle. Company and Dept. example from the paper explains this.
5. Reflexive Association: Class associated with itself

Packages: When modeling a huge system, packages help manage all the classes. Package enables modelers to organize the model's classifier into namespaces (eg. like folders in a filing systems. I think this example says it all, no need to say anything more)

Visibility
There are notations to model the visibility of the attributes and operations in the class diagram. The table from the paper summarizes those 4 notations + for public, # for protected, - for Private, ~ for package.

Instances
Models example instances of a class. For example, suppose there is a class Animal and we create an instance called Tiger, this can be modeled as Tiger : Animal. However showing this example instance is not useful if the relationships/associations are not modeled.

Roles
It is very similar to the instance notation. It models the class's role.

Internal Structure
It allows you to show how a class or a classifier is internally composed.

Summary: Benefits of Class Diagrams
1) Shows static structure of classifiers in a system
2) Diagram provides basic notation for other structure diagrams prescribed by UML
3) Helpful for developers and other team members too.
4) Business Analysts can use class diagrams to model systems from business perspective.

I think that's about it!
If you guys are reading up to this line, Wish you all the best for the test!