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 UML represents a collection of the best engineering practices that have proven successful in the modeling of large and complex systems.

Primary Artifacts of the UML

What are the primary artifacts of the UML? This can be answered from two different perspectives: the UML definition itself and how it is used to produce project artifacts.

A Brief History of the UML

The UML (Unified Modeling Language) gives us the tools to design and plan software applications. Although it can be extended to address even the most complicated situations, the basics of the UML can be easily learned and utilized.

In the late 1980's and early 1990's, there were many often conflicting modeling nomenclatures. In retrospect, the arguments over these differences were based more on personal preferences than anything else, since each method had its own strengths and weaknesses. Finally, after many disputes, the three most respected men in this field, Ivar Jacobson (OOSE – Object

Oriented Software Engineering), Grady Booch (The Booch Method) and James Rumbaugh (OMT – Object Modeling Technique) decided to stop the debate and instead work together to combine their ideas and develop a standard. The three became known as the "three amigos," and their work became the Unified Modeling Language (UML).

UML Basics

UML models allow us to design and plan the system we will build before we waste any time coding a faulty design. Unfortunately, many people (programmers as well as customers) feel they aren't being "productive" unless they're producing code. However, in the long run, applications that are well-planned and built with a solid design are actually less time consuming to build, more flexible and scalable, and easier to maintain than systems built by trial and error. Imagine building a skyscraper (or even a dog house) without any blueprints… Or what about something relatively simple like having a 25- person dinner party? Planning is essential and something we understand is necessary for most projects. However, somehow this process is often skipped in software development!

Software models are made up of various diagrams that use graphics to represent how the system will function and how the individual pieces of the system fit together and interact with each other. The diagrams are "pictures" of the system that is being designed. The UML doesn't really have a standardized process — the notation that is used for drawing the diagrams is

standard, but the process that is followed to create the diagrams is not actually part of the UML.

Why We Model

Developing a model for an industrial-strength software system prior to its construction or renovation is as essential as having a blueprint for large building. Good models are essential for communication among project teams and to assure architectural soundness. We build models of complex systems because we cannot comprehend any such system in its entirety. As the complexity of systems increase, so does the importance of good modeling techniques. There are many additional factors of a project's success, but having a rigorous modeling language standard is one essential factor.

A modeling language must include:

· Model elements — fundamental modeling concepts and semantics

· Notation — visual rendering of model elements

· Guidelines — idioms of usage within the trade

In the face of increasingly complex systems, visualization and modeling become essential. The UML is a well-defined and widely accepted response to that need. It is the visual modeling language of choice for building object-oriented and component-based systems.

Models are useful for understanding problems, communicating with everyone involved with the project (customers, domain experts, analysts, designers, etc.), modeling enterprises, preparing documentation, and designing programs and databases.

Modeling promotes better understanding of requirements, cleaner designs, and more maintainable systems.

Models are abstractions that portray the essentials of a complex problem or structure by filtering out nonessential details, thus making the problem easier to understand. Abstraction is a fundamental human capability that permits us to deal with complexity. Engineers, artists, and craftsmen have built models for thousands of years to try out designs before executing them. Development of software systems should be no exception.

To build complex systems, the developer must abstract different views of the system, build models using precise notations, verify that the models satisfy the requirements of the system, and gradually add detail to transform the models into an implementation.

We build models of complex systems because we cannot comprehend such systems in their entirety. There are limits to the human capacity to understand complexity. This concept may be seen in the world of architecture. If you want to build a shed in your backyard, you can just start building; if you want to build a new house, you probably need a blueprint; if you are building a skyscraper, you definitely need a blueprint. The same is true in the world of software. Staring at lines of source code or even analyzing forms in Visual Basic does little to provide the programmer with a global view of a development project. Constructing a model allows the designer to focus on the big picture of how a project's components interact, without having to get bogged down in the specific details of each component.

Increasing complexity, resulting from a highly competitive and ever-changing business environment, offers unique challenges to system developers. Models help us organize, visualize, understand, and create complex things. They are used to help us meet the challenges of developing software today and in the future.

Development Project Artifacts

The choice of what models and diagrams one creates has a profound influence upon how a problem is attacked and how a corresponding solution is shaped. Abstraction, the focus on relevant details while ignoring others, is a key to learning and communicating. Because of this:

· Every complex system is best approached through a small set of nearly independent views of a model. No single view is sufficient.

· Every model may be expressed at different levels of fidelity.

· The best models are connected to reality.

In terms of the views of a model, the UML defines the following graphical diagrams:

· Use case diagram

· Class diagram

· Behavior diagrams:

o State chart diagram

o Activity diagram

· Interaction diagrams:

o Sequence diagram

o Collaboration diagram

· Implementation diagrams:

o Component diagram

o Deployment diagram

· Package diagram

Goals of the UML

The primary design goals of the UML are as follows:

· Provide users with a ready-to-use, expressive visual modeling language to develop and exchange meaningful models.

· Furnish extensibility and specialization mechanisms to extend the core concepts.

· Support specifications that are independent of particular programming languages and development processes.

· Provide a formal basis for understanding the modeling language.

· Encourage the growth of the object tools market.

· Support higher-level development concepts such as components, collaborations, frameworks and patterns.

· Integrate Best Practices

BASIC CONSTRUCTS OF UML

Actors

Actors are not part of the system—they represent anyone or anything that must interact with the system. An actor may

· Only input information to the system

· Only receive information from the system

· Input and receive information to and from the system

Typically, these actors are found in the problem statement and by conversations with customers and domain experts. The following questions may be used to help identify the actors for a system:

· Who is interested in a certain requirement?

· Where in the organization is the system used?

· Who will benefit from the use of the system?

· Who will supply the system with this information, use this information, and

· remove this information?

· Who will support and maintain the system?

· Does the system use an external resource?

· Does one person play several different roles?

· Do several people play the same role?

· Does the system interact with a legacy system?

In the UML, an actor is represented as a stickman,

Use Cases

Use cases model a dialogue between an actor and the system. They represent the functionality provided by the system; that is, what capabilities will be provided to an actor by the system. The collection of use cases for a system constitute all the defined ways the system may be used.

The formal definition for a use case is: A use case is a sequence of transactions performed by a system that yields a measurable result of values for a particular actor.

The following questions may be used to help identify the use cases for a system:

• What are the tasks of each actor?
• Will any actor create, store, change, remove, or read information in the system?
• What use case will create, store, change, remove, or read this information?
• Will any actor need to inform the system about sudden, external changes?
• Does any actor need to be informed about certain occurrences in the system?
• What use cases will support and maintain the system?
• Can all functional requirements be performed by the use cases?

In the UML, a use case is represented as an oval

Use Case Relationships

An association relationship may exist between an actor and a use case. This type of association is often referred to as a communicate association since it represents communication between an actor and a use case. An association may be navigable in both directions (actor to use case and use case to actor) or it may be navigable in only one direction (actor to use case or use case to actor). The navigation direction of an association represents who is initiating the communication (i.e., the actor is initiating the communication with the use case, the use case is initiating the communication with the actor). An association is represented as a line connecting the related elements.

Navigation in only one direction is depicted by adding an arrowhead to the association line that denotes the direction.

There are two types of relationships that may exist between use cases: include and extend.

Multiple use cases may share pieces of the same functionality. This functionality is placed in a separate use case rather than documenting it in every use case that needs it.

Include relationships are created between the new use case and any other use case that "uses" its functionality. For example, a Course Registration use case could start with the verification of the user. This functionality can be captured in a User Verification use case, which is then used by other use cases as needed. An include relationship is drawn as a dependency relationship that points from the base use case to the used use case.

An extend relationship is used to show

• Optional behavior
• Behavior that is run only under certain conditions such as triggering an alarm
• Several different flows that may be run based on actor selection

An extend relationship is drawn as a dependency relationship that points from the extension to the base use case.

What is a Class?

A class is a description of a group of objects with common properties (attributes), common behavior (operations), common relationships to other objects, and common semantics. Thus, a class is a template to create objects. Each object is an instance of some class and objects cannot be instances of more than one class. For example, the CourseOffering class may be defined with the following characteristics:

• Attributes—location, time offered
• Operations—retrieve location, retrieve time of day, add a student to the offering

In the UML, classes are represented as compartmentalized rectangles. The top compartment contains the name of the class, the middle compartment contains the structure of the class (attributes), and the bottom compartment contains the behavior of the class (operations).

States

A state is a condition during the life of an object during which it satisfies some condition, performs some action, or waits for an event. The state of an object may be characterized by the value of one or more of the attributes of the class. For example, a CourseOffering object may be open (able to add a student) or closed (maximum number of students already assigned to the CourseOffering object). The state depends upon the number of students assigned to the particular CourseOffering object. Additionally, a state of an object may be characterized by the existence of a link to another object. A professor may be teaching or on sabbatical. This depends upon the existence of a link to a CourseOffering object. Looking at the state of an object can validate the multiplicity chosen for a relationship to another object. That is, if being in a state depends upon the existence of a link to another object, this implies that the multiplicity of the relationship modifying the role of the associated class must include zero (i.e., the relationship is optional). Thus, the states of an object are found by examining the attributes and links defined for the object.

Interfaces

An Interface is a collection of operations that specify a service of a class or a component. An interface describes the externally visible behavior of an element. An interface might represent the complete behavior of a class or component or only a part of that behavior. An interface defines a set of operation specifications but never a set of operation implementations.

Represented graphically as a circle along with its name.

Components

A Component is a physical and replaceable part of a system that conforms to and provides the realization of a set of interfaces. A component typically represents a physical packaging of otherwise logical elements such as classes, interfaces and collaborations. Examples of components could be COM+ components, Java Beans as well as the source code files.

Graphically, a component is represented as a rectangle with tabs, usually including only its name.

Node

A Node is a physical element that exists at runtime and represents a computational resource, generally having at least some memory and, often, processing capability. A set of components may reside on a node and may also migrate from node to node.

Graphically a node is represented as a cube, usually including only its name.

DIAGRAMS IN UML

USE CASE DIAGRAMS

A Use case diagram is a graphical view of some or all of the actors, use cases, and their interactions identified for a system. Each system typically has a Main Use Case diagram, which is a picture of the system boundary (actors) and the major functionality provided by the system (use cases).

Other use case diagrams may be created as needed. Some examples follow:

• A diagram showing all the use cases for a selected actor

• A diagram showing all the use cases being implemented in an iteration

• A diagram showing a use case and all its relationships

They are most valuable on a very large or complex system where the interaction between Use Cases is not straightforward or easily apparent. Use Case Diagrams are also especially useful when you have Use Cases that are "subclassed" from other Use Cases. The Use Case Diagrams give you an easy graphical way to display this inheritance.

CLASS DIAGRAM

Class Diagrams describe the various types of objects that exist in the system and the static relationships that exist between them. Class Diagrams also show the attributes (properties) and the operations (methods) of a class. Class Diagrams allow you to plan how the classes/objects will function and interact. You find the classes by examining the objects in the sequence and collaboration diagrams.

The UML modeling elements found in class diagrams include:

· Classes and their structure and behavior.

· Association, aggregation, dependency, and inheritance relationships.

· Multiplicity and navigation indicators

· Role names.

STATECHART DIAGRAM

State Diagrams describe the behavior of a system. They show all the possible states an object can get into, and also how the object's state changes as a result of events that happen to it. Usually, State Diagrams are drawn to show the lifetime behavior of a single class. The large black dots indicate the starting and ending points of the events. State transition diagrams are drawn for objects that typically have a lot of dynamic behavior.

A state transition may have an action and/or a guard condition associated with it and may also trigger an event. An action is behavior that occurs when the state transition occurs.

An event is a message that is sent to another object in the system. A guard condition is a Boolean expression of attribute values that allows a state transition only if the condition is true. Both actions and guards are behaviors of the object and typically become operations. Often, these operations are private—that is, they are used only by the object itself.

ACTIVITY DIAGRAMS

Similar to a flow chart, Activity Diagrams describe the sequencing of activities. They are actually a variant of the State Diagram. Like State Diagrams, the starting point is indicated with a large black dot. The horizontal black lines indicate where the object may take one of several different paths of action. Activity Diagrams are especially useful for objects which contain a lot of complex logic that you wish to clearly present.

SEQUENCE DIAGRAMS

Interaction Diagrams show how groups of objects collaborate in some behavior. Sequence Diagrams are the most common type of Interaction Diagram, and show an instance of an object and the 'life' of that object. In addition, the interaction between objects is shown.

Sequence diagrams show object interactions arranged in a time sequence.

COLLABORATION DIAGRAMS

Collaboration Diagrams, like Sequence Diagrams, are also interaction diagrams. Within the Collaboration Diagram, the objects are shown as icons. The arrows as well as the numbers (in this case, 1 and 1.1) indicate the order in which events occur. Collaboration Diagrams are good when you want to get a quick overview of the general flow of events and object relations. However, Sequence Diagrams are a better choice when you need to demonstrate the timing and sequencing of events.

COMPONENT DIAGRAMS

Component Diagrams show the various components in a system and their dependencies. The 'component' represents a physical module of code. The components are often the same as the packages, but they can be different, since the components represent the physical packaging of code. The 'dependencies' between the components show how changes in one component can affect the other components.

DEPLOYMENT DIAGRAMS

Deployment Diagrams show the physical relationship among software and hardware components in the system. This diagram is a good place to show how components and objects are routed and how they move around in a distributed system. Deployment Diagrams really show how the Component Diagrams interact. Many times, developers will combine the Component and Deployment Diagrams into a single diagram.

PACKAGE DIAGRAMS

Package Diagrams simply show groups of classes and the dependencies that exist between them. Package Diagrams are similar to Class Diagrams. However, instead of showing the individual classes, they show the related classes grouped together into a unit called a "package." A dependency exists between two packages if any dependency exists between any two classes inside each package. Package Diagrams can be really useful to obtain an overview of a large system. Sometimes, developers also choose to display the individual classes inside the packages.