In the Unified Modeling Language (UML), stereotypes are a mechanism to define common and consistent extensions to the UML notation. An individual stereotype denotes a common use of a modeling element and is demarcated using <<stereotype label>>. For example, in UML use case diagrams it is common to apply stereotypes such as <<include>> and <<extend>> to associations between use cases (see the tip Use Case Modeling Tips for details).
Notice the use of stereotypes throughout the UML sequence diagram presented in Figure 1. For the classifiers, I applied the stereotypes <<actor>>, <<controller>>, and <<UI>> indicating they represent an actor, a controller class, or a user interface (UI) class, respectively. For now, a controller class is a placeholder for one or more classes that would be fleshed out during design to implement the business logic of your system. A common architectural strategy is to layer your system, separating your user interface logic, business logic, system logic, and persistence logic from each other.
Stereotypes are also used for messages. Common practice on UML diagrams is to indicate the creation and destruction of messages with the stereotypes of <<create>> and <<destroy>>, respectively. For example, you can see that the ":SecurityLogon" object is created in this manner. (Actually, this message would likely be sent to the class that would then result in a return value of the created object, so I cheated a bit.) This object later destroys itself in a similar manner, presumably when the window is closed. In the Java programming language and C ++, methods that create objects are called constructors, and in C++, methods that destroy objects are called destructors. (Java code automatically manages memory, whereas C++ doesn't, so the Java language doesn't require destructor methods.)
UML notes are basically free-form text that can be placed on any UML diagram, to provide a header for the diagram, indicating its title and identifier. (As you may have noticed, I give unique identifiers to everything.) Notes are depicted as a piece of paper with the top-right corner folded over. I also used a note to indicate future work that needs to be done, either during analysis or design. In this diagram, the "qualifications()" message likely represents a series of messages sent to the Student object. UML practice is to anchor a note to another model element with a dashed line when appropriate -- with the note attached to the message.
- The Object Primer 2nd Edition by Scott W. Ambler. New York: Cambridge University Press, 2001.
- The Unified Process Inception Phase by Scott W. Ambler and Larry L. Constantine. Gilroy, CA: R&D Books, 2000.
- The Unified Modeling Language Reference Manual by James Rumbaugh, Grady Booch, and Ivar Jacobson. Reading, MA: Addison-Wesley Longman, Inc., 1999.