Unified Modeling Language (UML)

The Unified Modeling Language (UML) is a language for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non-software systems.
The goal of UML is to provide a standard notation that can be used by all object-oriented methods and to select and integrate the best elements of precursor notations. For example, UML includes the use case diagrams introduced by OOSE and uses many features of the OMT class diagrams. UML also includes new concepts that were not present in other major methods at the time, such as extension mechanisms and a constraint language. UML has been designed for a broad range of applications.

Hence, it provides constructs for a broad range of systems and activities (e.g., distributed systems, analysis, system design, deployment). A model is an abstraction of the real thing. When you model a system, you abstract away any detail that are irrelevant or potentially confusing. Your model is simplycation of the real system, so it allow the design and viability of a system to be understood, evaluated, and critized quicker than if you had to dig through the actual system itself. Even better, with a formal modeling language, the language is abstract yet just as precise as a programming language. This precision allows a language to be machine readable, so it can be interpreted, executed, and transformed between systems. UML focusses on two aspects of object oriented models, structure and behavior (see Figure uml.01):

Figure uml.01 UML Diagram Model

UML Structure Diagrams

The UML's structural diagrams exist to visualize, specify, construct, and document the static aspects of a system. You can think of the static aspects of a system as representing its relatively stable skeleton and scaffolding. Just as the static aspects of a house encompass the existence and placement of such things as walls, doors, windows, pipes, wires, and vents, so too do the static aspects of a software system encompass the existence and placement of such things as classes, interfaces, collaborations, components, and nodes.
The UML's structural diagrams are roughly organized around the major groups of things you'll find when modeling a system.
1. Class Diagram,
2. Component Diagram,
3. Object Diagram,
4. Profile Diagam,
5. Composite Structure Diagram,
6. Deployment Diagram,
7. Package Diagram

UML Behavior Diagrams

The UML's behavioral diagrams are used to visualize, specify, construct, and document the dynamic aspects of a system. You can think of the dynamic aspects of a system as representing its changing parts. Just as the dynamic aspects of a house encompass airflow and traffic through the rooms of a house, so too do the dynamic aspects of a software system encompass such things as the flow of messages over time and the physical movement of components across a network.
The UML's behavioral diagrams are roughly organized around the major ways you can model the dynamics of a system.
1. Activity Diagram,
2. Use case Diagram,
3. Interaction Diagram,
4. State Machine Diagram,
5. Sequence Diagram,
6. Communication Diagram,
7. Interaction Overview Diagram,
8. Timing Diagram

Every diagram you create will most likely be one of these nine or occasionally of another kind, defined for your project or organization. Every diagram must have a name that's unique in its context so that you can refer to a specific diagram and distinguish one from another. For anything but the most trivial system, you'll want to organize your diagrams into packages.
You can project any combination of elements in the UML in the same diagram. For example, you might show both classes and objects in the same diagram (a common thing to do), or you might even show both classes and components in the same diagram (legal, but less common). Although there's nothing that prevents you from placing wildly disparate kinds of modeling elements in the same diagram, it's more common for you to have roughly the same kinds of things in one diagram. In fact, the UML's defined diagrams are named after the element you'll most often place in each. For example, if you want to visualize a set of classes and their relationships, you'll use a class diagram. Similarly, if you want to visualize a set of components, you'll use a component diagram.

Unified Modeling Language (UML)

UML Structure Diagrams

UML Behavior Diagrams

www.CodeNirvana.in