Discuss the common modeling techniques in UML

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. For users, most abstractions are not that hard to identify because, typically, they are drawn from the things that users already use to describe their system. Techniques such as CRC cards and use case-based analysis are excellent ways to help users find these abstractions. For implementers, these abstractions are typically just the things in the technology that are parts of the solution.

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. 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 2 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. o model nonsoftware 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.