A software development method incorporates a modeling language and a process. UML is a modeling language. Objectory is a process.
There have been many methods that people have used:
The three amigos Booch, Rumbaugh and Jacobson decided to put together the best parts of their work, and add other stuff, to make UML. The 'U' stands for "Unified".
Use UML to model just about any kind of system. The system is modeled with a collection of diagrams. Each diagram represents some aspect of some part of the system. You choose how many diagrams you want to make, and even the level of detail of the diagram. The diagrams are really there to help you talk about your system with others.
You can use tools to help you draw the diagrams, and if the tool is a good one it can generate code from the diagrams.
There are eight kinds of diagrams
| Use Case Diagram | Shows actors and use cases |
| Class Diagram | Shows classes and the (static, structural) relationships between the classes. Can also show instances of classes, called objects. Sometimes people say "object diagram" for a class diagram with objects but no classes. A better term is "static structure diagram", but people like to say "class diagram". |
| State Diagram | Shows the behavior of an object in terms of its state transitions. |
| Activity Diagram | Shows the functional behavior of a system in one or across many use cases. |
| Sequence Diagram | Shows an interaction by laying out objects across the top and running their lifelines down the diagram. The messages they exchange connect points on the lifelines so you can easily "see" the sequence of messages. |
| Collaboration Diagram | Shows an interaction where the layout of objects is arbitrary and the sequence of messages is shown by numbering them. |
| Component Diagram | Shows dependencies among software components (where components can be source code, binaries, executables, whatever). |
| Deployment Diagram | Shows the configuration of (hardware) processing devices (or nodes) and their relationships, and which components run on them. |
Diagrams are made up of graphical constructs which can be
The diagram elements are:
| Model Element |
|
| String | A character sequence |
| Name | A string that uniquely identifies some model element within some scope |
| Label | A string attached to a graphic symbol |
| Keyword | Text enclosed within "«" and "»" to convey some concept. There are many keywords so we don't need zillions of specialized graphical symbols. |
| Expression | A linguistic formula that yields a value |
| Note |
|
A type is like a generic descriptor for a concept and an instance is an item described by a type. Where possible, UML indicates this distinction by underlining the name for instances. Examples:
A package is a grouping of model elements. Since a package is a model element, packages can be nested. Every kind of UML model element and diagram can be grouped into packages.
Predefined stereotypes: «subsystem», «model», «system», «facade», «framework», «top package».
Packages can be shown with dependency and generalization relationships but that means that some of the package contents have that relationship.
Comment
Arbitrary descriptive text within a note symbol. The note symbol is attached to another model element with a dashed line. The comment is not "executable" but should mean something to a reader.
Constraint
Semantic relationship among model elements that must hold for the model to be valid. Shown as a text string in braces
Property
A property is any value attached to a model element. These values are generally non-visual. Some properties are predefined but users can invent their own. Examples
{author="Joe" deadline="1998-11-26" status=draft}
{abstract} same as {abstract=true}
Stereotype
A new class of modeling element introduced at modeling time: a subclass of an existing modeling element with the same form but a specific new intent (a usage distinction). Shown as a keyword (enclosed within "«" and "»") and appears above or to the left of the name of the modeling element being described. Can also appear in a list in which case it describes what follows.
You can invent new icons for stereotypes and collapse the elements (with the usual warning that inventing too many special icons may impede readability and portability).
