1. Models
1.1. Objects
1.1.1. Attributes (state)
1.1.1.1. An object's state depends on the object's current condition or activity
1.1.1.2. An object may be in a "validating" state.
1.1.1.2.1. When an object is in a validating state, it performs an activity without waiting for an outside event to trigger a transition.
1.1.1.2.2. The result of that activity determines the object's subsequent state.
1.1.2. Methods (behavior)
1.2. Messages
2. About this map
2.1. Content authored by Randy Miller
2.2. Published in 2003 as "Practical UML: A Hands-On Introduction for Developers" by the Ebarcadero Developer Network
2.3. If you appreciate the content, please purchase the UML modeling tools from Embarcadero Technologies: Delphi, JBuilder, and RAD Studio, for all your UML modeling needs.
2.4. See also
3. Alternative Approaches
3.1. Some have contrasted a strict use of UML with the so-called "Agile" development methodology.
3.2. Some agile practitioners, incorporate some UML, such as sequence diagrams, into their design methods. cite needed.
4. A completely specified application will consist of nine types of UML Modeling Diagrams: (Ultra-Competent Officers Sell Customers Some All-Consuming Desire)
4.1. Use Case Diagrams
4.1.1. A use-case diagram is a collection of actors, use-cases, and the communications between them.
4.1.1.1. Actors
4.1.1.1.1. Actors are people or other users of the system
4.1.1.1.2. In a use-case diagram, actors are represented by stick figures.
4.1.1.2. A use case is a summary of scenarios for a single task or goal
4.1.1.2.1. A scenario is an example of what happens when someone uses the system.
4.1.1.2.2. In a UML use-case diagram, a use-case is depicted as an oval.
4.1.1.3. The connection between an actor and a use case is called a "communication association" or just a communication.
4.1.2. A UML use-case diagram describes what the system does from perspective of outside observer
4.1.3. The emphasis in a UML use-case diagram is on what the system does, rather than how it does it.
4.1.4. Helpfulness
4.1.4.1. UML use-case diagrams are helpful in determining features (a.k.a. requirements) of an application.
4.1.4.2. UML use-case diagrams are helpful for communicating with Clients
4.1.4.3. UML use-case diagrams are helpful for generating Test Cases
4.1.5. A UML use-case diagram describes relationships and dependencies between a group of "use cases" and the actors participating in the process.
4.1.6. rules
4.1.6.1. Each use case is related to at least one actor.
4.1.6.2. Each use case has one initiating actor.
4.1.6.3. Each use case leads to a relevant result, i.e. a result with business value.
4.2. Class Diagrams: Classes and the Relationships Between Them
4.2.1. A UML class diagram gives an overview of the system by indicating all its classes and the relations between them.
4.2.2. UML Class diagrams are static, not dynamic.
4.2.3. A UML class diagram displays what interacts, but not what happens when that interaction occurs.
4.2.4. In UML, a class diagram consists of representations of classes, associations, and multiplicities
4.2.4.1. Drawing Classes in UML
4.2.4.1.1. In UML, classes are notated as a rectangle divided into three vertically-stacked segments.
4.2.4.1.2. In UML, the names of abstract classes are in italics.
4.2.4.2. In UML, relationships among classes are displayed as connecting links.
4.2.4.2.1. In UML, the ends of the connecting link may be notated with a role name
4.2.4.2.2. In UML, a navigation arrow on the connecting link indicates a direction in which the link can be traversed or queried.
4.2.4.2.3. In UML, relationships can be either associations or generalizations
4.2.4.3. A relationship is said to have a "multiplicity,"
4.2.4.3.1. A multiplicity is a number that indicates the number of instances on one end of the relationship that can be related to one instance on the other end of the link.
4.2.4.3.2. A multiplicity can be a single number or a range.
4.2.5. In complex class diagrams, classes are grouped into packages
4.2.5.1. All the elements in a UML package are logically related.
4.2.5.2. In UML, a package is represented as a rectangle with a square on the leftmost side of the rectangle's top edge.
4.2.5.3. In UML, a package in drawn with its name in the rectangle
4.2.5.4. In UML, one package is said to depend on another package if changes in the other package could possibly force changes in the one.
4.3. Object Diagrams
4.3.1. A UML object diagram is similar to a class diagram, except that an object diagram displays instances instead of classes.
4.3.2. In UML, the name of an instance and the name of the class, separated by a colon and underlined appears in the rectangle.
4.3.3. UML permits the omission of an instance or class name if the meaning is clear from the diagram.
4.3.4. Utility of UML object diagrams
4.3.4.1. UML object diagrams are useful for explaining small pieces with complicated relationships
4.3.4.2. UML object diagrams are especially good for explaining recursive relationships
4.4. Sequence Diagrams
4.4.1. A sequence diagram shows how objects collaborate
4.4.2. A sequence diagram details how operations are carried out.
4.4.2.1. A UML sequence diagram shows objects and a sequence of message calls they make to other objects.
4.4.2.1.1. Sequence Diagrams show the message exchange (i.e. method call) between several Objects in a specific time-delimited situation.
4.4.2.1.2. Sequence Diagrams put special emphasis in the order and the times in which the messages to the objects are sent.
4.4.2.2. A sequence diagram shows what messages are sent, and when.
4.4.2.2.1. Like a collaboration diagram, a UML sequence diagram is an interaction diagram
4.4.2.2.2. Sequence diagrams are dynamic, as opposed to class and object diagrams which are static.
4.4.2.2.3. A UML sequence diagram differs from a collaboration diagram is that it focules on the times at which messages are sent, rather than on the object roles.
4.4.2.3. Sequence diagrams clearly show the time flow of method or function calls between modules
4.4.2.4. sequence diagrams help with complex call stacks just as data model diagrams help with complex database schema
4.4.3. How to draw
4.4.3.1. Sequence diagrams are organized according to time
4.4.3.1.1. In a UML sequence diagram, lower on the page indicates later in time.
4.4.3.1.2. In a UML sequence diagram, objects involved in an operation are shown from left to right in the order in which they take part in a message sequence.
4.4.3.2. In a UML sequence diagram, dotted vertical lines called "lifelines" represent the time that an object exists.
4.4.3.2.1. A lifeline is drawn with an activation bar.
4.4.3.2.2. The activation bar represents the duration of the execution of a message.
4.4.3.3. In a UML sequence diagram, rightward-facing arrows represent message calls.
4.4.3.3.1. The arrow leads away from the object that sends the message.
4.4.3.3.2. The arrow points toward the top of he activation bar of the message receiver
4.4.3.3.3. Conditions appear in square brackets
4.4.3.3.4. Iterations are indicated with asterisks.
4.5. Collaboration Diagrams
4.5.1. Comparison of UML collaboration diagrams with UML sequence diagrams.
4.5.1.1. UML collaboration diagrams convey the same information as sequence diagrams.
4.5.1.2. Like UML sequence diagrams, UML collaboration diagrams are also interaction diagrams.
4.5.1.3. Collaboration diagrams differ from sequence diagrams in that they focus on object roles instead of the times that messages are sent.
4.5.2. How to draw a UML collaboration diagram:
4.5.2.1. In a UML collaboration diagram, object roles are drawn as rectangles labeled with the class names, object names, or both separated by a colon.
4.5.2.2. In a UML collaboration model, the links connecting the object roles are messages.
4.5.2.3. Each message in a collaboration diagram has a sequence number.
4.5.2.3.1. The top-level message is sequence number 1.
4.5.2.3.2. Messages sent during the same call are at the same level.
4.5.2.3.3. Messages at the same level have sequence numbers that start with the same prefix and a dot.
4.5.3. UML collaboration diagrams show objects and their relationships, with emphasis on the objects that participate in the message exchange.
4.6. State Diagrams
4.6.1. UML statechart diagrams or "state" diagrams show the possible states of objects.
4.6.1.1. UML statechart diagrams show events and transitions that causes changes in an object's state.
4.6.1.2. Unlike an activity diagram, which shows the flow of activities involved in a single process, a UML statechart diagram, shows either an object undergoing a process, or a process as an object.
4.6.2. How to draw a UML statechart diagram
4.6.2.1. In UML, a state is drawn as a rectangle with ronded corners.
4.6.2.2. In UML, transitions are arrows connecting one state to another.
4.6.2.2.1. "Events or conditions" that trigger the transition are written next to the arrows.
4.6.2.2.2. The name of the action that occurs as a result of an "event or condition" is written preceded by a slash.
4.6.2.3. Initial and final states are "dummy" states, represented by small black circles.
4.6.3. All objects have an enumerated set of states.
4.6.3.1. Every object is always in one of its finite set of states.
4.6.3.2. An object's state changes is reaction to one of a finite set of stimili.
4.6.3.3. There are two special states in every object's state set: "start" and "end." The "start" state can never be entered after it is initially left, and the end state is always the final state.
4.6.3.4. The names of states usually end in "ing," or may be "stopped" or "ready."
4.6.3.4.1. listening for connection
4.6.3.4.2. validating login data
4.6.3.4.3. getting password
4.7. Activity Diagrams
4.7.1. A UML activity diagram shows how activities involved in a single process are dependent on one another.
4.7.1.1. Unlike a statechart diagram, which shows either an object undergoing a process or a process as an object, a UML activity diagram shows the flow of activities involved in a single process.
4.7.1.2. A UML activity diagram is little more than a glorified flowchart.
4.7.2. Drawing a UML activity diagram
4.7.2.1. In a UML activity diagram, activities are drawn as rounded rectangles.
4.7.2.2. emerging from each activity rectangle is a single transition that leads to the next activity.
4.7.2.2.1. A single transition may branch into two or more exclusive transitions.
4.7.2.2.2. A transition may fork into one or more parallel activities.
4.7.2.3. UML Activity Diagrams are divided into "swim lanes."
4.7.2.4. Swimlanes determine which object is responsible for which activity
4.7.3. One Activity is one state in the system with internal activity and, at least, one outgoing transition.
4.7.3.1. Activities can also have more than one outgoing transition if they have different conditions.
4.7.3.2. Activities can form hierarchies
4.7.3.2.1. An Activity can be composed of several “detail” Activities.
4.7.3.2.2. Where an Activity is composed of several “detail” Activities, the incoming and outgoing transitions should match the incoming and outgoing transitions of the detail diagram
4.8. Component Diagrams
4.8.1. A UML component diagram is a physical analog of a class diagram.
4.8.2. A component is a code module.
4.8.3. A UML component diagram shows high-level programming components.
4.9. Deployment Diagrams
4.9.1. A UML deployment diagram show the physical configuration of hardware and software.
4.9.2. The physical hardware is made up of "nodes."
4.9.3. Each component code module belongs on a node.
4.9.4. A UML deployment diagram shows instances of the components and their relationships