Abstract
The UML (Unified Modeling Language) has become a standard in design of object oriented computer systems (Schach, 2004). UML provides for the use of stereotypes to extend the utility of its base capabilities. In the design and construction of business systems, the use of stereotypes is particularly useful stereotypes, and this article defines and illustrates these.
TopUml Stereotypes
“Stereotypes are the core extension mechanism of UML (Lee & Tepfenhart, 2002). If you find that you need a modeling construct that isn’t in the UML but it is similar to something that is, you treat your construct as a stereotype” (Fowler & Kendall, 2000). The stereotype is a semantic added to an existing model element, and diagrammatically it consists of the stereotype name inside of guillemots (a.k.a. chevrons) within the selected model element (Schach, 2005). The guillemot looks like a double angle bracket (<< … >>), but it is a single character in extended font libraries (Brown, 2002). Each UML model can have zero or many stereotypes; and each stereotype can define a set of tagged values, constraints, and possibly a special icon or color (Arlow & Neustadt, 2005). The UML defines about 40 of these stereotypes, such as “<<becomes>>”, “<<include>>”, and “<<signal>” (Scott, 2001). However, these 40 standard stereotypes are not particularly useful in business models and do not add the meaning necessary for automatic code generation in a UML CASE tool.
One common general use of the stereotype is for a metaclass. A metaclass is a class whose instances are classes, and these are typically used in systems in which one needs to declare classes at run time (Eriksson & Penker, 1998). A similar general use is for powertypes. A powertype is an object type (class) whose instances are subtypes of another object type. Figure 1 shows an example of the use of stereotypes for powertypes (Martin & Odell, 1998). Another type of usage is in the “binding” of parameterized (template) classes historically in C++ and now in the latest version of Java (Oestereich, 1999).
TopUser-Defined Stereotypes For Business Systems
In the design of business systems we have found some stereotypes that were occasionally useful, and two stereotypes that are extremely useful. When defining stereotypes it is useful to describe (Eriksson & Penker, 1998):
- 1.
On which (UML) element the user-defined stereotype should be based
- 2.
The new semantics the stereotype adds or refines
- 3.
One or more examples of how to implement the user-defined stereotype
An issue is where such definition takes place both within UML and in the UML software tool. If a modeling tool does not provide such built-in support (and most do not), many modelers put a note in the model or a reference to external documentation (Arlow & Neustadt, 2005).
One common use of stereotypes in business systems is for interfaces as found in Java or CORBA; this is shown in Figure 2. An interface typically has public functionality but not data (unless holding data for global constants). The class model element has been modified with the “<<interface>>” notation (Oestereich, 1999). This is commonly used for UML CASE products that do not have separate interface symbols or where these symbols do not allow data (i.e., global constants).
Key Terms in this Chapter
Polymorphism: The ability of object oriented programs to have multiple implementations of the same method name in different classes in an inheritance tree. Derived classes can override the functionality defined in their base class.
Interface: The specification for a method (“what” a method does); how that function is called from another program. Interfaces are provided in source form as opposed to implementations, which are secure. This allows one to use a method without regard for “how” that method is coded. It also allows multiple implementations of the same interface.
Activity Diagram: A UML diagram showing operations and triggers between operations; a diagram which shows system dynamics via cause and effect relationships. An Activity Diagram is a state diagram in which most of the states are action states and most of the transitions are triggered by the completion of these action states.
Operation: A process related notion in UML; operations cause state changes in objects.
Implementation: The code placed inside of methods. For some languages this code is pre-compiled or interpreted.
Relationship: A connection concept between object types. There are several types of relationships, including aggregation, composition, association, and inheritance (generalization/specialization).
Structural Model: An UML model describing static structure (relationships and properties).
Packages: Similar to a library, but just containing classes.
Reuse: Reuse (software) is a process where a technology asset (such as a function or class) is designed and developed following specific standards, and with the intent of being used again.
Function: A programming construct where code that does a particular task is segregated from the main body of a program; the function may be sent arguments and may return arguments to the body of the program.
UML: Unified Modeling Language.
Patterns: A software library for a common business scenario. A framework may be a design framework (possibly expressed in UML) or an implementation framework (possibly in C++, Java, or PHP).
Class: A program construct representing a type of thing (abstract data type) that includes a definition of both form (information or data) and functionality (methods); the implementation of the design concept of “object type.”
Composition: A new class in an objected programming language that is composed of other classes.
Encapsulation: The ability to insulate data in a class so that both data security and integrity are improved.
Method: A function defined inside of a class; a processing specification for an operation.
Framework: A software foundation that specifies how a software system is to be built. It includes standards at all levels both internal construction and external appearance and behavior.
Stereotype: The core extension mechanism of UML.
Inheritance: A feature of object oriented languages that allows a new class to be derived from another class (a more general class); derived classes (more specific classes) inherit the form and functionality of their base class.
Case: Computer-aided software engineering.