ACTORS, shown as 'stick people', that interact with the USE CASES (ovals). The methods of interaction are not shown. The links between USE CASES is shown and they make up a SYSTEM with a SYSTEM BOUNDARY, i.e. the programmer/system designer works with what's inside the boundary (but needs to know who will interact with it).
Can be USE CASES that EXTEND existing ones and there can be INCLUDES as well. Includes are USE CASES that follow on from previous cases. It is a STATIC diagram.
Show the CLASSES and ASSOCIATIONS that exist between each other. In other words the relationship between CASES. Format includes lozenges/diamonds at the end of the link that is dominant e.g. professor has a student. An infilled lozenge show heightened dominance e.g. car owns a gearbox - it has to have one. The link also shows whether there is a many to one/many to many relationship using the notation 1, 1..* or 0, 0..*, n, n..* (0 means that X could have a Y but not essential - ..* means or more). It is a STATIC diagram.
The parallel, dashed line show the persistence/existence of an object in the system (the lifeline). This diagram is DYNAMIC (shows time). The horizontal lines show the messages passing between objects and the hollow boxes represent the PROCESS sending/receiving the message. The objects are INSTANCES of specific CLASSES.
These diagrams combine the information from USE CASE, CLASS and SEQUENCE diagrams. They show the interaction between the CLASSES in terms of messages. Difference between OBJECT and CLASS - Object is a specific Instantiation of a class e.g. Ford_Ka (Object) of car (Class). The messages are numbered in order of communication (DYNAMIC diagram).
Sequence diagram - shows order more clearly
Communication - shows what interacts with what more clearly.
Diagram shows the transitions between states (methods/behaviours). States are shown in rounded ovals that can have a horizontal line with the activities that occur in that state underneath the state's name. The diagram starts with a filled circle and ends with a circumpunct (See Dan Brown - The Lost Symbol!). The arrows show the direction of the transitions and the format is that they are labelled with [event/method] , e.g [received bill payment/mark bill paid].
Uses diamonds to show forking.
Very similar to State Diagram except that the action/method is in the oval box and the state is on the transition line. This is basically our classic 'Flow Diagram'.
Similar notation except that the hollow diamond shows branching/merging and a thick horizontal line is placed where the flow forks and after flow is re-joined.
Very similar to a class diagram, but shows specific objects and the actual values of data/attributes and methods/behaviours. These are useful for modelling parts of a system in close up.
(Not in the specification) shows the physical map of all the parts of a system with all the instances of the use of each node.