Category: UML Categories

This is a UML class diagram example for the Decorator pattern.

Purpose
Allows for the dynamic wrapping of objects in order to modify their existing responsibilities and behaviors.

Use When
- Object responsibilities and behaviors should be dynamically modifiable.
- Concrete implementations should be decoupled from responsibilities and behaviors.
- Subclassing to achieve modification is impractical or impossible.
- Specific functionality should not reside high in the object hierarchy.
- A lot of little objects surrounding a concrete implementation is acceptable.

This is an Interaction Overview Diagram example.

The Interaction Overview Diagram focuses on the overview of the flow of control of the interactions. It is a variant of the Activity Diagram where the nodes are the interactions or interaction occurrences. The Interaction Overview Diagram describes the interactions where messages and lifelines are hidden. You can link up the "real" diagrams and achieve high degree navigability between diagrams inside the Interaction Overview Diagram.

This is a State Machine Diagram example.

The state / condition notation shows states as a list next to the relevant participant. A state-line is then needed to show what state a participant is in at a given time. Unfortunately, if a participant has many different states, then the amount of space needed to model a participant on the timing diagram will grow quickly.

The general value notation fixes this problem by removing the vertical list of different states. It places a participant's states directly at the point in time when the participant is in that state. Therefore, the state-line is no longer needed, and all of the states for a particular participant can be placed in a single line across the diagram.

This is a Composite Structure Diagram example.

Composite structure diagram is a kind of UML diagram that visualizes the internal structure of a class or collaboration. It is a kind of component diagram mainly used in modeling a system at micro point-of-view.

This is a Package Diagram example for ticket selling system.

A subsystem is another special package. It represents a portion of a system, with a crisp interface that can be implemented as a distinct component. Model management information is usually shown on class diagrams. This example shows the breakdown of the entire theater system into packages and their dependency relationships. The box office subsystem includes the previous examples in this chapter; the full system also includes theater operations and planning subsystems. Each subsystem consists of several packages.

This is a UML class diagram example for car.

A car consists of different structural components, such as the engine, body, suspension, gearbox, etc. Each component in turn contains its own attributes and operations. For example, the engine has its capacity, and it can be started or stopped. We can represent the car with a class diagram. This is a class diagram example that shows a simplified structural model of a car in a class diagram.

In this use case diagram example, actors include the clerk, supervisor, and Ticket Vending Machine. The Ticket Vending Machine is another system that accepts orders from a customer. The customer is not an actor in the box office application because the customer is not directly connected to the application. Use cases include buying tickets through the Ticket Vending Machine or the clerk, buying subscriptions (only through the clerk), and surveying total sales (at the request of the supervisor). Buying tickets and buying subscriptions include a common fragment—that is, making charges to the credit card service. (A complete description of a box office system would involve a number of other use cases, such as exchanging tickets and checking availability.)

Use cases can also be described at various levels of detail. They can be factored and described in terms of other, simpler use cases. A use case is implemented as a collaboration in the interaction view.

This activity diagram example shows an activity diagram for the theater office. This diagram shows the activities involved in planning a show.

1. Arrows show sequential dependencies—for example, shows must be picked before they are scheduled.
2. Heavy bars show forks or joins of control. For example, after the show is scheduled, the theater can begin to publicize it, buy scripts, hire artists, build sets, design lighting, and make costumes, all concurrently. Before rehearsal can begin, however, the scripts must be ordered and the artist must be hired.

A UML activity diagram is helpful in understanding the high-level execution behavior of a system, without getting involved in the internal details of message passing required by a collaboration diagram.

This is a Component Diagram example that shows the components in a web store.

Component diagram shows components, provided and required interfaces, ports, and relationships between them. This type of diagrams is used in Component-Based Development (CBD) to describe systems with Service-Oriented Architecture (SOA).

The following nodes and edges are typically drawn in a component diagram: component, interface, provided interface, required interface, class, port, connector, artifact, component realization, dependency, usage. These major elements are shown on the component diagram here.

A state diagram is a graph whose node are state and whose directed arcs are transition between states which describes sequence caused by event sequences. A state diagram typically models the common behavior of a class

In this state diagram example, the phone line is idle at the start of a call. When the phone is removed from the hook, it emits a dial tone and can accept the dialling of digits. Upon entry a valid number, the phone system tries to connect the call and route to the proper destination. The connection can fail if the number or trunk are busy. If the connection is successful the called phone begins ringing. When put on hook again, the phone line will go back to idle.