Class Diagrams

Class Diagrams:

Terms and Concepts:

                      A class is a description of a set of objects that share the same attributes, operations, relationships and semantics. Graphically, a class is rendered as a rectangle.

Class diagram commonly contains the following things.

·                     Classes,

·                     Interfaces,

·                     Collaboration,

·                     Dependency, Generalization and Association, Relationships.

Class diagrams may also contain packages or subsystems both of which are used to group elements of your model into layer chunks.

Class diagrams are used in one of 3 ways.

·                     Modeling the Vocabulary of a System.

·                     Modeling the Distribution of Responsibilities in a System.

·                     Modeling Non-software Things.

Common Modeling Techniques

            You'll use classes most commonly to model abstractions that are drawn from the problem, you are trying to solve or from the technology you are using to implement a solution to that problem. Each of these abstractions is a part of the vocabulary of your system, meaning that, together, they represent the things that are important to users and to implementers.

Modeling Non-software Things

    To model the vocabulary of a system,

·                     Identify those things that users or implementers use to describe the problem or solution.

·                     Use CRC cards and use case-based analysis to help find these abstractions.

·                     For each abstraction, identify a set of responsibilities. Make sure that each class is crisply defined and that there is a good balance of responsibilities among all your classes.

·                     Provide the attributes and operations that are needed to carry out these responsibilities for each class.

Modeling the Distribution of Responsibilities in a System

      To model the distribution of responsibilities in a system,

·                     Identify a set of classes that work together closely to carry out some behavior.

·                     Identify a set of responsibilities for each of these classes.Look at this set of classes as a whole, split classes that have too many responsibilities into smaller abstractions, collapse tiny classes that have trivial responsibilities into larger ones, and reallocate responsibilities so that each abstraction reasonably stands on its own.

·                     Consider the ways in which those classes collaborate with one another, and redistribute their responsibilities accordingly so that no class within a collaboration does too much or too little.

Modeling Non-software Things

       To model non-software things,

·                     Model the thing you are abstracting as a class.

·                     If you want to distinguish these things from the UML's defined building blocks, create a new building block by using stereotypes to specify these new semantics and to give   a distinctive visual cue.

·                     If the thing you are modeling is some kind of hardware that itself contains

            software, consider modeling it as a kind of node, as well, so that you can further     expand on its   structure.