Search This Blog

Wednesday, February 23, 2011

The UML Class Diagram: Part 1

So, what is a class diagram? Imagine you were given a task of drawing a family tree. The steps you would take would be:
  • Identify the main members of the family
  • Determine how they are related to each other
  • Identify the characteristics of each family member
  • Find relations among family members
  • Decide the inheritance of personal traits and characters
A class diagram is similar to a family tree. A class diagram consists of a group of classes and interfaces reflecting important entities of the business domain of the system being modeled, and the relationships between these classes and interfaces. The classes and interfaces in the diagram represent the members of a family tree and the relationships between the classes are analogous to relationships between members in a family tree. Interestingly, classes in a class diagram are interconnected in a hierarchical fashion, like a set of parent classes (the grand patriarch or matriarch of the family, as the case may be) and related child classes under the parent classes.
Similarly, a software application is comprised of classes and a diagram depicting the relationship between each of these classes would be the class diagram.
By definition, a class diagram is a diagram showing a collection of classes and interfaces, along with the collaborations and relationships among classes and interfaces.
A class diagram is a pictorial representation of the detailed system design. Design experts who understand the rules of modeling and designing systems design the system's class diagrams. A thing to remember is that a class diagram is a static view of a system. The structure of a system is represented using class diagrams. Class diagrams are referenced time and again by the developers while implementing the system.
Now you now know what a class diagram is. But, how does a class diagram relate to the use case diagrams that you read about in the earlier article? When you designed the use cases, you must have realized that the use cases talk about "what are the requirements" of a system. The aim of designing classes is to convert this "what" to a "how" for each requirement. Each use case is further analyzed and broken up into atomic components that form the basis for the classes that need to be designed.
However, besides use cases, the artifacts of a project, such as stakeholder requests, (signed off) requirement documents, functional specifications, and a glossary of terms for the project serve as other important inputs to the discovery of classes.
We will now see what the components of a class diagram are, and how to create a class diagram.

No comments:

Post a Comment