3. Describe uml diagrams.

UML describes 13 official diagram types .

Activity – procedural and parallel behavior

Class – class, features and relationships

Communication – interaction between objects ; emphasis on links.

Component – Structure and connections of components

Composite structure – Runtime decomposition of a class

Deployment – Deployment of artifacts to nodes

Interaction Overview – Mix of sequence and activity diagram

Object – Examples configurations of instances

Package – Compile- time hierarchic structure

Sequence – Interaction between objects emphasis on sequence

State machine- How events change an object over its life

Timing – Interaction between objects , emphasis on timing

Use case – How users interact with a system

4. How to fit the uml into development process?

When they look at graphical modeling languages, people usually think of them in the context of a waterfall process. A waterfall process usually has documents that act as the handoffs between analysis, design, and coding phases. Graphical models can often form a major part of these documents.

The activity of requirements analysis involves trying to figure out what the users and customers of a software effort want the system to do. A number of UML techniques can come in handy here:

· Use cases, which describe how people interact with the system.

· A class diagram drawn from the conceptual perspective, which can be a good way of building up a rigorous vocabulary of the domain.

An activity diagram, which can show the work flow of the organization, showing how software and human activities interact. An activity diagram can show the context for use cases and also the details of how a complicated use case works.

· A state diagram, which can be useful if a concept has an interesting life cycle, with various states and events that change that state.

When we are doing design, we can get more technical with our diagrams. We can use more notation and be more precise about our notation. Some useful techniques are

· Class diagrams from a software perspective. These show the classes in the software and how they interrelate.

· Sequence diagrams for common scenarios. A valuable approach is to pick the most important and interesting scenarios from the use cases and use CRC cards or sequence diagrams to figure out what happens in the software.

· Package diagrams to show the large-scale organization of the software.

· State diagrams for classes with complex life histories.

· Deployment diagrams to show the physical layout of the software.

Many of these same techniques can be used to document software once it's been written. This may help people find their way around the software if they have to work on it and are not familiar with the code. With a waterfall life cycle, we would do these diagrams and activities as part of the phases. The end-of-phase documents usually include the appropriate UML diagrams for that activity. A waterfall style usually implies that the UML is used as a blueprint. In an iterative style, the UML diagrams can be used in either a blueprint or a sketch style. With a blueprint, the analysis diagrams will usually be built in the iteration prior to the one that builds the functionality. Each iteration modifies the existing body of documents, highlighting the changes in the new iteration. Blueprint designs are usually done early in the iteration and may be done in pieces for different bits of functionality that are targeted for the iteration.