Subtitles of the Movie

UML defines a number of stereotypes that you can apply to components. Some of these stereotypes are specific to components others are more general but can be usefully applied to components. This movie offers a quick rundown of stereotypes you might want to use with a component in your components diagrams and I'll give the name of each stereotype and then describe what that indicates. So the first one is the application stereotype and this indicates the front end, the user interface, this stereotype might indicate the screens and controllers for graphical user interface or the pages that appear in a user's web browser. The data store stereotype indicates a persistent location for storing data. The document stereotype is pretty self explanatory; this could refer to an electronic or a printed document. The entity stereotype refers to a component that represents some business concept; usually with the entity stereotype don't have their own functionality. Instead they're used for storing and retrieving data. The executable stereotype indicates that the component can be executed on a node and this refers to software components. And by the way I discuss nodes in the section on deployment diagrams. The file stereotype indicates a data file. Infrastructure as a stereotype indicates a technical component inside the system, for example a logger. The library stereotype is another self explanatory one and it refers to a function or an object library. Now the process stereotype is opposed to the entity stereotype as you'll recall the entity stereotype refers to a business concept but doesn't have its own functionality. The process stereotype on the other hand is transaction based and can fulfill functional requests; it's also usually stateful, preserving the current data. The realization stereotype realizes another component because it has no specification of its own the realization stereotype implements a specification component so this gets paired with a specification stereotype in your diagram and specification stereotypes are defined in just a bit. The service stereotype is a stateless component that satisfies functional requests and because its stateless typically does not persist. Source code stereotype another self explanatory one examples would include a java or a C plus plus file. So some kind of source code file. The specification stereotype has interfaces but no implementation; this is the one that gets paired with the realization stereotype. It has no classifiers to realize its interfaces. And for that reason it needs to be paired with the realization component. Subsystem is part of a larger system; the subsystem is self contained and usually bigger then a simple component. For example a subsystem might be a component that contains several other components so the best way to think of the subsystem is it's like an component only bigger, a bigger piece of the system. The table stereotype indicates a table inside a database that holds data. Web service stereotype indicates what it says, a web service. And finally the XML DTD stereotype indicates an XML document type definition which holds syntax rules for an XML document. So there in a nutshell are the various kinds of stereotypes that you can apply to your components. These can be very useful, be sure that you apply them consistently.