The use case diagram (the word "use" is pronounced as a noun in this context, and not as a verb) is one of the UML'S behaviour diagrams. The primary purpose of a use case diagram is to describe the behaviour of a system from the user's point of view. It describes what the system does (i.e. its functionality), not how it does it. For this reason, the creation of use case diagrams often forms part of the requirements gathering process. The elements of a use case diagram include:
The simplicity of the notation used for use case diagrams (see illustration below), together with the fact that they describe interactions between a system and the users of that system from the user's point of view, means that they provide a useful point of reference in discussions between developers and clients. Many of the actors and use cases will be identified during initial interviews with the client, and with the end users of the proposed system. Some will emerge later, during the detailed analysis and requirements gathering process. The use cases that are identified will determine the scope of the system (i.e. the complete range of functionality that the system is expected to provide).
The uses cases are normally accompanied by more detailed documentation that describes the expected behaviour of a use case, the conditions that must be satisfied in order for the expected outcome to be achieved, and the action to be taken in the event that one or more of those conditions cannot be met. This makes use cases useful to developers when identifying specific test cases for testing the system. It also helps them to outline the flow of logic when designing the program. Since use cases describe the system from the user's point of view, they can also suggest features that should be included when designing the user interface and user documentation.
The primary feature of a use case diagram is the use case itself, which represents a particular piece of the system's overall functionality. In fact, the functionality of the entire system, from the user's point of view, can be captured as a set of use cases. Each use case represents a specific set of actions that the system (referred to in the UML Superstructure document in this context as the subject) may be required to carry out, in collaboration with one or more external entities called actors. In its most basic form, a use case is represented as an ellipse, with the name of the use case either underneath it or inside it, as shown below. Alternatively, it may be represented using a standard rectangular classifier icon, with a small ellipse displayed in the top right hand corner. Note that the name of a use case usually consists of a combination of verbs and nouns that describes, in a concise manner, the required functionality. Note also that the order in which the use cases appear in a use case diagram is not significant.
Strictly speaking (according to the UML Superstructure document) the term use case refers to a use case type, whereas an instance of a use case would refer to the actual occurrence of behaviour conforming to one of the scenarios described in the use case description (more about that particular document later). As such, an instance of a use case may be described in one of the UML's interaction diagrams.
A use case is always associated with one or more actors. The execution of a use case is initiated by an actor, and upon completion the use case must return a result to an actor (either the actor that initiated the use case, or another actor). The actor is an external entity, and not part of the system as such. It represents a role played by a person (e.g. a user), another system, or some other external entity. It could even be the passage of an interval of time, or the occurrence of a specific time or date. Note that the same actor may be involved in multiple use cases, and may initiate multiple use cases either at the same time or at different times. An actor is usually represented by a stick figure, especially if the actor represents a human entity (such as a user). Alternatively, the classifier rectangle may be used (typically for non-human actors). A graphic icon may also be used to represent specific types of non-human actor. If a stick figure or graphic icon is used, the name of the actor appears below the icon. If the classifier rectangle is used, the name appears inside the rectangle, with the stereotype «actor» displayed above it.
An association between an actor and a use case indicates either that the actor initiates the use case, or that the actor receives the results of executing a use case, or both. The association is drawn as a solid line. The convention is to place an actor that initiates a use case on the left of the use case, while an actor that receives the results of a use case appears on the right of the use case. The illustration below shows a typical scenario. The Stock Controller actor initiates the Add Stock Item use case. If the use case is executed successfully, details of the new stock item will be added to the inventory database, which is represented by the Inventory Database actor.
Remember that the association represents communication between an actor and a use case (i.e. that the actor participates in the use case), but does not imply the direction in which communication flows. Positioning an actor on the left-hand side of a use case only implies that the actor initiates the use case (i.e. causes it to start executing). Thereafter, communication may flow in either direction. Consider the use case diagram below, which is a simplified representation of a medical practice. The Patient actor initiates the Make Appointment use case (either by telephone or by calling at the surgery in person). The Receptionist actor will check for the first available appointment, and inform the Patient actor of the time and date. If the Patient actor is happy with the appointment offered, they will signify their acceptance. The appointment will then be entered onto the system.
The purpose of an association between an actor and a use case is only to show that the actor participates in the use case. Detailed information concerning the nature of the interactions that occur between a use case and the actors that participate in it will be contained within the use case description. The use case description is a separate document (usually a text document).
If required, multiplicity can be shown at either end of an association. In the diagram below, you can clearly see that an instance of the Withdraw Cash use case may be initiated by one instance, and only one instance, of the Customer actor. Conversely, the Customer actor may initiate zero or one instances of the Withdraw Cash use case. Note that if the multiplicity at the actor end of an association is greater than one, and it is clear from the context that the actor initiates the use case, this would indicate that more than one actor is involved in initiating the use case. The required actions occur either concurrently (i.e. at the same time), or in sequence (each actor carries out the action required from them in turn).
The system boundary may be represented as a rectangle that fully encloses all of the use cases shown on a use case diagram. Showing the system boundary in this way serves to represent graphically the scope of the system (or subsystem) being modelled. The actors appear outside the rectangle to indicate that they are not part of the system. Any external entity that interacts with the system, including another system, is an actor by definition. The name of the system or subsystem is usually shown inside the rectangle at the top, preceded by the stereotype «system» (or «subsystem»).
Sometimes a high-level view of the system may be depicted using just the system rectangle, devoid of use cases but with all of the actors present. This top-level use case diagram is somewhat similar to the context diagram (a top level data flow diagram) used in some systems analysis methodologies. Indeed, its only real purpose is to define the domain of the system in very broad terms, and put it into some kind of context. An example is provided below.
An extended use case is one whose behavior is extended by the behavior of another use case (the extending use case). The extended (or base) use case is a complete use case in its own right, as is the extending use case (although the extending use case will typically be somewhat narrower in scope, and may not be particularly meaningful in isolation). The extending use case does however define a modular set of behavior increments that may be used to extend more than one base use case. The functionality embodied in a use case extension often represents optional behavior that is only called upon when certain conditions are met. The relationship between a base use case and a use case that extends it (see below) is shown using a dashed line connecting the extended use case to the base use case, with an open arrowhead pointing at the base use case. The line is labeled with the «extend» stereotype.
In the above example, the subject is an ATM system in which the Withdraw Cash use case is extended by the Print Receipt use case. At some point in the execution of the Withdraw Cash use case occurrence, the customer will be offered the option of printing a receipt. If the customer selects this option, the Print Receipt use case will execute, after which the Withdraw Cash use case will continue from the point where it left off. The point in the behaviour of a base use case at which it may be extended by the behaviour of another use case is called an extension point. Extension points may be listed in a separate compartment within the use case ellipse or classifier icon under the heading extension points, as shown below.
The UML Superstructure document suggests that the name of an extension point could be accompanied by a brief explanation (or formal definition) of where the extension point occurs within the behaviour of the base use case. The Superstructure document does not, however, offer any suggestions as to how this should be formatted. Indeed, it is rather vague about the definition of the extension point itself, citing the reason that "use cases are typically specified in various idiosyncratic formats". It is probably better to put this kind of information into the use case description (see above), where it can be expressed in terms that are appropriate for the chosen development methodology and programming language. On a somewhat more positive note, the Superstructure document suggests that the name of the extension point, together with the condition that must be met in order for the extended use case to be executed, may be displayed in a note attached to the extend relationship.
To describe this situation from a programmer's point of view (and using a somewhat simplistic analogy), the base use case can be viewed as the main program, while the extended use case can be viewed as a subroutine that is called from the main program if (and only if) the relevant conditional statement in the main program evaluates to true. The conditional statement represents the extension point. Once the subroutine has completed, program execution resumes at the point in the main program immediately following the conditional statement (although note that an extending use case may itself be extended).
If the exact same functionality is duplicated within two or more use cases, it can be factored out to a separate use case. The separate use case can then be included in each base use case that uses the factored out behavior. At first glance, this looks rather like an extension, but the included use case is not optional, since its behavior is required by each base use case that uses it. An included use case is a good indication to a programmer that an opportunity exists for code reuse when developing the software. As with extensions, the behavior of the included us case is executed at a specific location within the behavior of each base use case. The relationship between a base use case and an included use case (see below) is shown using a dashed line connecting the base use case to the included use case, with an open arrowhead pointing at the included use case. The line is labeled with the «include» stereotype.
The included use case will have its own use case description. Note, however, that although the included use case may interact with actors, it will never be directly initiated by an actor. It is only executed when a base use case that includes it is executed. Removing duplicate functionality to a separate use case reduces the amount of documentation required for each of the base use cases that uses the common behaviour, and means that changes to the documentation required for the common behaviour, if required, only need to be made in one place. The use case description for each base use case must indicate the point within its behaviour at which the included use case is executed. In the example below, three use cases (representing three different types of ATM transaction) all include the Validate Card use case.
In order to keep use case diagrams simple, details of the behaviour defined by a use case are documented in a separate document usually referred to as a use case description. Whilst the UML does not specify a format for this document, it is usually (though not necessarily) a simple text document. Every use case should be accompanied by a use case description, whether it is classed as a base use case, an extension, or an included use case. The use case description provides details of the sequence of steps to be carried out in order for the use case to be executed successfully. It specifies the points in this sequence of steps at which any included use cases are executed. It also specifies the extension points at which any applicable extended use cases may be executed, and the conditions that must be true in order for these extended use cases to be applied. The use case description could be expected to include information such as:
The steps required for each of the various possible pathways through a use case (sometimes referred to as scenarios) may be written informally, or as a set of numbered statements. Similarly, the conditions that may trigger the error handling or optional behaviour described in an extended use case may be expressed using natural language or a more formal language such as the Object Constraint Language (OCL). Note that while an included use case contains behaviour that is required in order for the base use case to complete successfully, an extended use case usually represents either optional behaviour that may be executed prior to successful completion of the base use case, or as a response to errors or exceptions occurring during the execution of the base use case. In the latter case, the extended use case may allow the base use case to resume at some point, but may equally well cause the base use case to terminate without completing successfully.
Use cases can be owned either by a package or by a classifier (typically, in the case of a classifier, by a system or subsystem - referred to formally by the UML as the subject). We have already seen examples of use cases owned by a system or subsystem, in which the subject is represented by a rectangle which encloses the use case icons, and which displays the name of the system (or subsystem), together with the appropriate stereotype, at the top of the rectangle. Grouping use cases into packages is a valid option if you have a large number of use cases and want to organise them, as illustrated below.
Note that in the second of the examples shown above (which are similar to those given in the UML Superstructure document), the use case Undertake ATM Transaction generalises the use cases Check Balance, Withdraw Cash and Deposit Cash. Although generalisation of use cases is not specifically discussed in the document, the implication is that a specialised use case may inherit the characteristics of a more general (probably abstract) use case. The same principle could be applied to actors, where one actor generalises a number of more specialised actors. A system administrator, for example, has the same characteristics as a user, but also has a number of additional privileges that allow them to carry out administrative tasks. Arguably, specialisations in use cases could be represented by extensions, but the UML Superstructure does not seem to indicate the circumstances under which either of these two possible approaches should be used.
This article was first published on the TechnologyUK.net website in January 2009.
A profile allows UML to be extended for use with a particular programming platform (such as Microsoft's .NET framework or the Java Enterprise Edition platform), or to model systems intended for use in a particular domain (for example medicine, financial services or specialised engineering fields). A profile extends the UML to allow user-defined stereotypes, metaattributes, and constraints (see below). The vocabulary of the UML may thus be extended with a platform or domain-specific vocabulary that allows more meaningful names to be assigned to model elements. Code generation tools can use profiles to generate code targeted at a specific platform or environment (the precise way in which profiles are implemented depends somewhat on the UML modeling tool used). Here are the abbreviated definitions of the key terms mentioned above:
To understand how profiles work, it is necessary to understand the fundamental nature of the UML, which is that of a metamodel. The word model implies an abstraction of some real world system. The word meta implies some further abstraction of whatever concept we apply it to. The word metadata is often used in the context of a database, for example, and in simple terms means data about the data. A metamodel (as you might deduce) therefore describes the properties of a model. A model is constrained by its metamodel in the same way that a computer program is constrained by the grammar and syntax of the programming language used to write it. Every element of the Unified Modeling Language is defined by a metaclass.
A profile is a special kind of package that contains stereotypes. Each of these stereotypes defines the way in which a standard UML metaclass is to be extended in order to adapt it for use with a specific platform or domain, by providing additional tag definitions and constraints. A stereotype may extend more than one metaclass, and a metaclass may be extended by more than one stereotype, but a stereotype must always be used in conjunction with one of the metaclasses that it extends, and not in isolation. Stereotypes are represented on profile diagrams using class notation, except that the keyword «stereotype» appears above or in front of the name of the model element as shown below.
As stated above, a stereotype extends a UML metaclass and is therefore meaningless if viewed in isolation. In order to show that a stereotype extends a metaclass, the metaclass is also shown on the profile diagram. The diagram below tells us that the «DataType» stereotype extends the Class metaclass. The relationship between the stereotype and the metaclass it extends is indicated by a solid line connecting the stereotype icon to the metaclass icon, with a filled arrowhead pointing towards the metaclass end (this line is referred to in the UML Superstructure document as an extension). Note that the use of the «metaclass» stereotype is optional, but can help to make it a bit more obvious what is intended.
In the notation shown above we are saying that the DataType stereotype may be used to extend the Class metaclass. We might, in certain circumstances, want to stipulate that a particular metaclass must always be extended by a given stereotype. We can show that this is the case by adding the constraint {required} at the stereotype end of the extension. In the example shown below, an instance of the Module stereotype must always be linked to an instance of the Component metaclass.
A stereotype can be associated with a graphical icon. Some standard UML elements are already associated with a graphical icon, the classic example being the "stick man" used on use case diagrams (which are covered elsewhere) to represent instances of the Actor metaclass. If a stereotype defines a graphical icon, the icon may be attached to any model element extended by the stereotype. In fact, the icon can be used to replace the standard rectangular icons for model elements such as classes and components, provided the element in question is only extended by a single stereotype, and it is not deemed necessary to list any properties (i.e. attributes or operations) for the element.
The icon will also replace any existing standard graphical icon. A smaller version of the graphical icon may appear inside the rectangular icon used to represent a model element. The examples below show several ways of applying the Book stereotype to a model element, including two different ways of using the graphical icon.
Because a stereotype is essentially a metaclass, it can have properties which are known as metaattributes (in previous versions of UML these were known as tag definitions). When a stereotype is used to extend a metaclass, the metaattributes may be listed in a separate compartment below the stereotype name.
A stereotype may also generalise or specialise another stereotype, as shown below.
As mentioned above, a stereotype may be applied to more than one element, and multiple stereotypes may be applied to the same element. In the example below, the stereotype Server may be applied to both the Component metaclass and the Device metaclass. The Device metaclass may additionally be extended by the NetworkNode stereotype.
In the diagram below, the Server and NetworkNode stereotypes are applied to the WebServer model element. Note that the names of the applied stereotypes appear above the name of the model element, separated by commas (if the model element also has a keyword, this can be displayed either above or in front of any stereotype names). The attribute values for each of the applied stereotypes can be shown in a comment symbol that is attached to the model element.
As mentioned earlier, a profile is essentially a kind of package, and as you might expect it uses the same notation as a package. The keyword «profile» is used, either above or in front of the package name, to indicate that the package is a profile. Each profile consists of one or more stereotype definitions that extend an existing UML metaclass. In the Network profile illustrated below, the User stereotype extends the Class metaclass, and the NetworkNode stereotype extends the Device metaclass. The NetworkNode stereotype is specialised by the Workstation, Server and Switch/Router stereotypes.
A profile is applied to another package in order to make the stereotypes in the profile available to that package. The illustration below shows the Network, Telecomms and Software profiles being applied to the ITManagement package. The application of a profile is indicated by a dashed line from the package to the profile, with an open arrowhead pointing at the profile. The keyword «apply» is shown near the arrow, at the profile end. As you can see, multiple profiles can be applied to the same package (providing they do not have conflicting constraints). Once a profile has been applied to a package, the stereotypes defined by the profile can be applied by the package to model elements used by the package. If a profile is subsequently removed from a package, the stereotypes defined by the profile are also deleted from the package.
This article was first published on the TechnologyUK.net website in January 2009.
A deployment diagram can be used to model the physical architecture and (in the case of networks or distributed systems) the topology of the software system being developed. It describes the hardware devices (known as nodes), the software components that run on them (known as artifacts), and the communication links between the various nodes and artifacts. In the most trivial case, the "system" may consist of a single executable (.exe) file that runs on a stand-alone computer. The illustration below shows what such a scenario might look like as a deployment diagram. The Organiser.exe artifact represents a single instance of an executable program file, is deployed to the DesktopPC node, which represents a stand-alone desktop computer.
Creating a deployment diagram for a system that consists of a single node is probably somewhat superfluous. If you have a system for which artifacts will be deployed on a number of hardware nodes, however, the deployment diagram can be used as a blueprint for installing your system. It can also be of great help when discussing physical system layout with various stakeholders. Indeed, as mentioned above, deployment diagrams may be used to model both local networks and distributed systems. At the other end of the scale, deployment diagrams can also be used to model the architecture of embedded systems. The deployment diagrams on this page were created using Visual Paradigm for UML Community Edition, which is free for non-commercial use.
An artifact icon is drawn inside a node icon to show that the artifact is deployed on that node. The node itself thus becomes the deployment target for the artifact. Note that the node DesktopPC is labeled with the stereotype «device» (to indicate that this is a hardware node), and the name of the node. A node is represented as a cube, presumably because the use of a three-dimensional shape emphasizes the fact that the node represents some physical object in the real world (i.e. an item of hardware). Note, however, that a node can also be used to represent a software environment that hosts an artifact. Examples of hardware nodes include desktop computers, workstations, servers, disk drives, and embedded hardware such as microcontrollers.
Two alternative methods of showing a deployment are illustrated below. In the first, an artifact is shown as being deployed to a node by placing the artifact outside of the node, and drawing a dependency between the artifact and the node (represented as a dashed line drawn from the artifact to the node, with an open arrowhead pointing at the node). The stereotype «deploy» is used to emphasise the relationship. The second method allows a more compact representation in which the deployed artifacts are simply listed inside the deployment node (this is useful if you have a large number of artifacts deployed on a single node). Note however that this form of representation does not allow any dependencies between artifacts to be shown on the diagram.
Examples of software nodes could include operating systems, web server software such as Apache or Microsoft's Internet Information Server (IIS), or the Java Runtime Environment (JRE). If the node represents a software environment, the stereotype «device» is replaced by the stereotype «execution environment». The execution environment must itself run on a piece of hardware of some kind, so it is common to see a software node nested within a hardware node on a deployment diagram, as shown below. In this case, the execution environment consists of an Apache HTTP server running on a Linux server (a scenario quite commonly encountered in commercial web hosting environments).
The execution environment can also be shown outside of the hardware node, with a composition arrow linking it back to the hardware node (note that the same notations can be used to model a nested hardware node, such as a graphics card or a hard disk drive inside a computer). The relationship between the device Linux Server and the execution environment Apache HTTP Server could be modeled as shown below. Note that the UML specification encourages users to define their own stereotypes for standard execution environments. The examples given in the UML Superstructure document include «OS», «database system», and «J2EE container». These stereotypes could be defined in a profile (see the page on profile diagrams).
The services provided by an execution environment are usually implicit in the stereotype used, but the UML Superstructure document states that an execution environment may optionally have "an explicit interface of system level services that can be called by the deployed services". Examples of how this interface might be expressed are not provided, but the services could perhaps simply be listed in a separate compartment within the execution environment node's icon.
Just as an execution environment (or another hardware node) can be nested within a hardware node, so can one execution environment be nested within another. In the diagram below, for example, the «web server» execution environment is nested within the «OS» execution environment (note that in both of the execution environment nodes, the «execution environment» stereotype has been substituted by an application-specific stereotype).
The relationship between deployment targets and deployed artifacts can be defined at the type level (in which a generic node or artifact may be used to represent one or more instances) or at the instance level (in which case the node or artifact represents a specific instance). The UML Superstructure document suggests underlining the name of nodes and artifacts to indicate an instance, although this is optional, since the context will usually make it obvious what is intended. In the example above, the device node could represent any number of Dell PowerEdge servers, each running the Linux operating system and playing host to Apache web server software. The example below shows a specific instance of Apache running over a specific instance of Linux installed on a specific server called WebServer1.
Clearly then, a deployment diagram could have two or more nodes of the same type. In a commercial web hosting environment, for example, we could have multiple servers of the same type. In order to show that they are different instances, use the notation shown above, in which the type of the node is preceded by the name of the node, with a colon separating them like this:
name : type
Note that the name of a node instance may be omitted from a deployment diagram if its inclusion serves no useful purpose. The deployment diagram below shows a (greatly simplified) view of a web server farm consisting of three servers. In theory, since a node is a specialization of a class, attributes could be assigned to a node, but there is no indication in the UML Superstructure document that this is the case. There is no support for adding them in the UML modeling tools we have tried. If the user wishes to include additional information about a node within the deployment diagram, they could perhaps attach a note.
An artifact is deployed on a node (the deployment target), and is typically the compiled version of a component (i.e. an executable file), but it can also be a script, a library file, a database file, a configuration file, or a text file. In fact it can be any kind of file that forms part of, or is used by, your application. If the artifact represents the physical implementation of a packageable element such as a component, it is said to manifest that element. Since just about any type of UML element is packageable, an artifact can manifest just about any UML element.
An artifact is usually shown as a rectangle, with the «artifact» stereotype and the name of the artifact inside it, and a small document icon in the upper right-hand corner. The artifact may alternatively be depicted as an icon. The example below shows the artifact InventoryCtrl.exe manifesting the component InventoryCtrl. A manifestation relationship is shown using a dependency arrow. This is shown as a dashed line from the artifact to the component (or other packageable element) that it manifests, with an open arrowhead pointing at the component. The stereotype «manifest» is shown in close proximity to the line.
Note that linking artifacts to the packageable elements they manifest and to the deployment targets on which they are deployed can produce a somewhat cluttered deployment diagram. For this reason, manifestations are either shown separately on the deployment diagram, or on a separate diagram. They are commonly shown on component diagrams by listing the artifacts that manifest a component in a separate compartment within the component's rectangle. Note also that the name of the artifact does not necessarily have to be the same as the name of the packageable element that it manifests (although the names are often similar).
In cases where more than one artifact is deployed to a deployment target, or even in cases where artifacts are deployed to different deployment targets, there may be a dependency between one artifact and another (i.e. one artifact relies on services provided by another artifact). This dependency is shown in the normal manner (see below), using a dependency arrow from the artifact that requires the services to the artifact that provides them.
This seems like a good time to mention that a number of standard stereotypes are defined by the UML specification that can be applied to artifacts. Examples include «source» (to represent a file consisting of program source code), «executable» (to represent a compiled program file that can be executed by a computer), and «library» (to represent a file containing library routines that may be called by a program). The diagram below illustrates the use of standard UML stereotypes. Note that the standard stereotypes may be further specialised (using a profile) in order to reflect a particular target platform or application environment.
When an artifact is deployed to a specific hardware node or execution environment it becomes an instance. A stand-alone application may be deployed to a number of different desktop computers in an office, each copy representing an instance of the original artifact. An instance is indicated by underlining the name of the artifact, as shown below. Note that the UML Superstructure document states that the underlining may be omitted if it is obvious from the context of the deployment diagram that the artifact is an instance, although most UML modeling tools underline the names of artifact instances anyway.
Artifacts can also be linked by composition associations. In the example below, the artifact inventory_ctrl.ear contains the artifact inventory_ctrl.jar and the deployment specification application.xml (a deployment specification is a specialised kind of artifact, which we will describe shortly). A composition is shown using a solid line that connects the contained artifact to the container artifact, with a solid diamond shape at the end nearest the containing artifact. For those unfamiliar with Java, the .ear (Enterprise Archive) file format is used to package one or more .jar (Java Archive) files for ease of deployment onto an application server. The archived files will normally include the application.xml file, which is the deployment descriptor (covered below) for an Enterprise application.
Artifacts can also have properties that represent features of the artifact, and operations that can be performed on their instances. The properties of an artifact usually represent some set of configurable options. For that reason they are most often to be found in a deployment specification (see below), the purpose of which is to define the configuration settings for a deployed artifact. You can list the properties of an artifact in a separate compartment below the artifact's name.
Nodes may be connected to other nodes via associations that represent communication paths, indicating that communication may take place between the nodes. A communication path may exist, for example, between a hardware node representing an application server and another hardware node that represents a client workstation. A communication path is drawn as a solid line connecting two nodes. The type of communication being modeled can be shown using an appropriate stereotype. In the example below, the model describes a desktop computer communicating with an intranet server over an Ethernet connection. Note, however, that communication paths can also represent wireless connections. We can use hardware nodes and the communication paths between them to model the topology of a network.
A communication path can also be used to show that communication may take place between execution environment nodes. The stereotype used for a communication path should reflect the type of communication we are interested in modeling. In the example below, the association is stereotyped as a TCP/IP connection. Although the data will obviously be transmitted via some physical transmission medium, such as an Ethernet connection, we are interested here in the communication between two execution environments. In this case, the execution environments happen to be a web browser and a web server, which requires the use of the TCP/IP protocols.
A deployment specification is a special kind of artifact that specifies the parameters to be used by another artifact (usually an executable file or script) at run time, either to determine how the artifact runs, or to configure the artifact's host (i.e. a hardware node or execution environment). The deployment specification is typically deployed to a node along with the artifact whose runtime parameters it describes. The deployment specification is drawn as a rectangle, as shown below, and looks like any other artifact except that the «artifact» stereotype is replaced by the «deployment spec» stereotype. In addition, the rectangle may optionally have an additional compartment in which the deployment specification's properties are listed. The properties are listed using the name : type notation:
In the above example, both the artifact Organiser.exe and the deployment specification Organiser.config are deployed to the execution environment Windows. The deployment specification is connected to the artifact it parameterises using a dependency arrow (a broken line from the deployment specification to the artifact, with an open arrowhead pointing at the artifact). Both the artifact and the deployment specification are nested within the execution environment. The deployment may alternatively be modelled as shown below, with the artifact connected to the execution environment using a deployment arrow. The deployment specification is attached to the deployment arrow via a broken line.
Like an artifact, a deployment specification becomes an instance when deployed to a specific host environment. An instance of a deployment specification is called a deployment descriptor. The name of the deployment specification will be underlined, and the deployment properties will be given specific values, as shown below. In this example, an instance of the Organiser.exe artifact is deployed to a desktop computer running the Windows operating system, and is parameterized by an instance of the deployment specification Organiser.config.
This article was first published on the TechnologyUK.net website in January 2009.
A component is a modular part of a computer software system. It represents a group of related classes and other elements that work together within a self-contained logical structure in order to provide some aspect of the system's functionality. Components can be used in the early stages of system design to establish the overall architecture of the system. In the later stages, they facilitate the allocation of work to development teams. The internal details of a component are encapsulated (hidden from view), and the functionality provided by the component is available only via the interfaces it presents to its environment. A sufficiently well-designed component, with a well-defined set of interfaces, can be re-used in other systems where the same subset of functionality is required. It should be possible to replace an existing component with an updated version, providing the interface definitions remain the same, even though the internal implementation of the new version may be quite different.
Components are effectively another way of looking at structured classifiers of the kind we talk about in the page on composite structure diagrams. They can range in size from relatively small (conceivably a single class) to quite large (a major system component known as a subsystem). A component will often contain a number of classes that work together to realise (implement) the component's functionality, and may even consist of some number of (smaller) components. To illustrate the conceptual difference between a component and a class, consider an inventory control system. While modeling the detail of the system we might create a class called StockItem that holds the part number, description and location of an inventory item. At the other end of the scale, we could create a component called InventoryControl that allows us to create new inventory items on the system, allocate inventory items to sales orders, add new supplies to the inventory record, and make inventory control adjustments.
The basic component icon is drawn as a rectangle, with the name of the component displayed inside it. To avoid confusing this icon with a class icon (which can look very similar) the component stereotype («component») is usually displayed above the component name. The UML 1.4 component icon may optionally be displayed in the top right-hand corner of the rectangle, either instead of or as well as the component stereotype. The three methods of displaying a component are illustrated below for a component called InventoryCtrl.
A component, by definition, is a self-contained autonomous unit. The so-called "black-box" view of a component shows how it looks from the outside, without revealing anything about its internal structure. This is often the only view we need of a component when we are looking at how it fits into the overall system architecture. The functionality of the component can only be accessed via the interfaces it provides. By the same token, if the component must use the services of another component in order to carry out its duties, it will require the component providing those services to provide a suitable interface. We can show the interfaces that a component provides, and those it requires, in three ways. The first uses the ball-and-socket notation illustrated below. Each provided interface is shown as a circle (the ball), connected to the component icon by a solid line, and labelled with the name of the interface. Each required interface is shown as a half-circle (the socket), also connected to the component icon by a solid line and labelled with the name of the interface.
Rather than use ball-and-socket notation, you can show the names of the provided and required interfaces in a separate compartment below the component name, as shown below.
Sometimes it may be necessary to show the signature of a provided or required interface in terms of the operations the interface provides, the arguments that must be passed to those operations, and their return values. If this is the case, the interface can be displayed using classifier rectangles as shown below (note that we have not included operation parameters or return values here to keep the diagram simple). If a component realises (implements) an interface, a dashed line connects the component to the interface icon, with an arrowhead consisting of a hollow triangle pointing to the interface icon. Similarly, if a component requires an interface, a dashed line connects the component to the interface icon, but with an open arrowhead pointing at the interface icon.
Component diagrams such as the one shown below model the architecture of a software system. They are often referred to by developers as wiring diagrams because they show how components are wired together to create an application, and can help software developers and other stakeholders understand how the larger pieces of the system fit together and communicate. For that reason, the components themselves are often shown on component diagrams as black boxes. A component diagram presents a relatively high-level view of the system, and at this level of abstraction we are not usually concerned with the inner workings of a component. The things that are of interest to us are the dependencies between components, or between components and interfaces.
The lines joining components together on the diagram are referred to as connectors, and they indicate that some kind of communication is taking place between the components they connect. Specifically, all of the connectors shown on the above diagram are assembly connectors. An assembly connector uses the ball and socket notation to indicate that one component provides services that are required by another component. Remember that the ball represents a provided interface, while the socket represents a required interface. Note that where two or more components require services provided by the same interface, the connectors can be combined. In the example shown above, the PartsOrder and BuildList components both require the services of the InventoryCtrl component. A similar situation pertains if multiple components provide a particular interface.
Depending on your UML modeling tool, you may or may not be able to represent the dependency relationship between two components on your diagram using the ball-and-socket notation to create an assembly connector. Some tools let you snap the ball and socket symbol together, others require you to insert a dependency arrow between the required and provided interface symbols. You can also simply omit the ball-and-socket notation altogether and just draw a dependency arrow between the components, although using assembly connectors sometimes allows you to show more information about the relationship between the components. The component diagram shown below illustrates the alternative ways of representing the dependency relationship.
It is sometimes useful to be able to see how the interfaces provided by a component are realised. In order to do this we need to be able to look inside the component to see what elements inside the component (usually classes, but sometimes other components) are responsible for realising each provided interface. We call this view a "white box" view. As with the black box view, there are different ways in which we can show the white box view of a component. One way is to add an additional compartment to the component icon and list the classifiers that realise the component's interfaces, as shown below. The compartment is labelled with the realizations stereotype («realizations»).
An additional compartment can also be added to show which artifacts implement the component, as shown below. The artifacts that implement the component are listed beneath the artifact keyword («artifact»). Artifacts are the software elements created by programmers during the actual implementation of the software system. They include data files, executable program files, scripts, and database files. A component (or subsystem) may be implemented by one or more artifacts, which exist on various bits of hardware (network servers, client computers etc.) in the real world. These bits of hardware are referred to as hardware nodes. The disposition of artifacts on hardware nodes is modelled using deployment diagrams (we look at deployment diagrams on another page).
The white box view of a component can also be drawn as a structure diagram in which the internal classifiers (or sub-components) are drawn outside of the component icon. The relationship between the component and its internal classifiers is shown using dependencies (see below). The dependency is shown as a dashed line drawn from the classifier or sub-component to the component. An open arrowhead at the component end points to the component.
The classifiers can also be shown inside the component rectangle, as shown below.
When we model the internal details of a component, we are essentially creating a composite structure diagram in which the internal classifiers are the parts. When you want to show the internal structure of a component (i.e. a white box view), you can link the externally visible provided and required interfaces to the parts that realise or require them via ports. A port represents an interaction point between a component and its environment. It is represented by a small hollow square symbol drawn on the boundary of the component, and may optionally be named. By attaching interfaces to a port, you are indicating that the services provided or required by the component, and defined by the interfaces, are accessed via that port.
A provided interface may be realised by the component itself or by one of the component's public ports, but is more often realised by a classifier within the component. If so, there will be a delegation connector between the port to which the interface is attached, and the classifier that realises the interface. When a request for service arrives at a port on the component, the port delegates the request (via the delegation connector) to whichever internal classifier realises the port's provided interface. The delegation connector is shown as a dashed line from the port to the realising classifier, with an open arrowhead pointing at the classifier, as shown in the example below.
If a component has a required interface, the client for that interface is also likely to be one of the component's internal classifiers. If so, any request for service will be sent via a delegation connector to whichever external port the required interface is attached to, with the arrowhead pointing this time towards the port. The port will forward the request to the required interface. In some cases, a port may have both provided and required interfaces attached to it, and is said to be bi-directional.
Sometimes, the parts making up the composite structure of a component have their own ports and associated interfaces. This is often the case where the parts are themselves components within some larger component. In such cases, the delegation connector is normally shown linking an external port with the part's provided or required interface, rather than linking the port directly with the part itself. A component that contains other components may simply represent a larger part of the overall system. At the highest levels of the system architecture, the term subsystem may be used instead of component, in order to indicate that this is an entity that represents a major part of the functionality of the system.
The diagram below shows a subsystem consisting of a number of components. The «subsystem» stereotype replaces the «component» stereotype. Note the use of assembly connectors (the links with the ball-and-socket notation) to connect components internally, and the use of delegation connectors (the dashed lines with an arrowhead at one end) to link component interfaces with external ports.
A number of additional stereotypes not previously mentioned may also be used with components. The names of these stereotypes are listed below, together with a brief description of their meaning.
This article was first published on the TechnologyUK.net website in January 2009.
Class diagrams can provide us with a lot of generic information about the relationships that exist between classes that work together within complex structures. For example, we can use composition in a class diagram to model the collection of components that make up a self-contained physical entity like a car or a washing machine. Object diagrams, on the other hand, can be used to model specific instances of such a structure. They provide concrete examples of how the structure can be used in order to create a better understanding of the class diagram. Composite structure diagrams go a step further. They allow us to model the interactions that must occur between the internal components of an instance of a structured classifier in order to carry out a specific task.
We should start with some definitions. A classifier describes the structural and behavioural characteristics (i.e. attributes and operations) of a UML element. Examples of classifiers include classes, interfaces, datatypes, subsystems and components. A structured classifier is a classifier whose instantiation results in the creation of a collection of interconnected objects, referred to as its internal structure. The elements that make up this internal structure are known as properties. Properties can be further categorised as parts, which represent specific roles within the internal structure, or connectors. A connector is a link that allows interaction or communication to occur between two or more parts at runtime. Composite structure diagrams are used to model the internal structure of a structured classifier (the containing classifier), and the collaborations that may take place between its parts in order to achieve some common objective.
When an instance of a structured classifier is created, a set of instances corresponding to its properties will also be created (although not necessarily all at the same time). The instance (or instances) created for each property will be an instance of the classifier typing that property. The possibility exists of more than one instance of a property being created, depending on the multiplicity defined for that property for a given instantiation. Note that the method of instantiation used may accept one or more arguments. These arguments can be used to produce variations on the default instantiation. Note also that when an instance of a structured classifier is destroyed, all instances corresponding to parts of that structured classifier are destroyed along with it.
To create a structure diagram, the containing classifier is drawn like a normal class icon (but bigger, of course). The icon will have two compartments. In the first, put the name of the containing classifier. The parts that make up the internal structure go into the second, much larger compartment. We created most of the diagrams on this page using the Astah Community UML modeling tool (version 6.5.1). In this software package, the icon used for the containing classifier is called a "Structured Class" icon. The remaining diagrams (those containing collaborations, which we talk about later) were created using Visual Paradigm for UML 8.3 Community Edition, which is free for non-commercial use. Here is the initial structure diagram for a personal computer system.
The diagram shows that our personal computer has two components - a mainboard represented by a part of type Mainboard, and a processor represented by a part of type Processor. Obviously our model is incomplete at this stage because a personal computer requires several other major components in order to work, but it serves to illustrate the basic features of a simple structure diagram. A part represents one or more instances of a property owned by an instance of the containing classifier. Each part is represented by a rectangle with a solid outline to indicate that the containing classifier exclusively owns that part (a part that is shared with one or more other classifiers is also represented by a rectangle, but the rectangle has a broken outline). The name and type of the part may be shown within the rectangle as follows:
name : classname
The class name and colon may be omitted, which implies that the part is an instance of an unnamed class. In the above example we have omitted part names and shown just the class names (identified as such by the inclusion of a colon to the left of the class name). The multiplicity of each part is shown after the class name inside square brackets (an alternative notation is to place the multiplicity in the top right-hand corner of the rectangle). A generic class diagram for the personal computer system is shown below for comparison purposes.
The class diagram tells us that an instance of Mainboard can be associated with either one or two instances of Processor. This allows for the possibility of the motherboard being able to accommodate two processors. As such it represents an abstract class, because in the real world, a personal computer mainboard is manufactured either to accommodate one processor or more than one processor. The structure diagram is more specific, because it tells us that there is only one instance of Processor in our personal computer system, and that these parts are linked in some way. We know they are linked because they are joined by a connector, which is represented by a solid line that joins the two parts. The connector represents a logical and/or physical connection between instances of the parts that it connects. A more realistic approach to the class diagram is illustrated below.
The class diagram now shows the Mainboard and Processor classes as part of a composition in which the main class is called BasicPC. The diagram tells us that our personal computer system contains one mainboard and one processor, and that within the composition the Mainboard and Processor classes have a one-to-one relationship. Let's develop the composite structure diagram further, to include the rest of the major components required for our personal computer system. Here is a list of the components still required:
We will assume for the moment that the mainboard is of the type that has a sound card and display adapter built in. Here is our updated composite structure diagram:
The composite structure diagram now has all of the major components to be found inside a typical entry-level personal computer, together with the required power, data and control links. Most of the parts have been labelled with both their name and type (the exception is the two memory modules which are not shown separately on the diagram). If you have a working knowledge of how a personal computer is put together, you will not find the diagram too difficult to understand. You will know, for example, that the processor is connected to the mainboard (or motherboard as it is sometimes called) via a socket built into the mainboard. The socket can only accommodate a single physical processor at any one time (which may of course be a multi-core processor, but that is not of concern at the moment).
The computer system has two memory modules, but these have been shown as a single part on the diagram with a multiplicity of two. The memory modules have their own special kind of socket on the motherboard, but because of its elongated shape it is referred to as a slot. Our mainboard has two memory slots, allowing it to accommodate two memory modules. The connector linking the memory modules to the motherboard is shown as having a multiplicity of one at both ends, which implies that there will be two connector instances. The diagram tells us that there will be two instances of MM (the class used to represent a memory module) and two slots.
We have shown the memory slots (and all of the other connection points) using a port (represented by a small square box) that has a multiplicity of two. We will learn more about ports shortly. For the moment, simply be aware that the port to which the memory modules are connected actually represents two separate memory slots, as denoted by its multiplicity. Here is an alternative representation of this arrangement:
The two slots are now represented by two separate ports. The memory modules are also shown separately, and both the ports and the memory module instances are now named. We chose not to use this arrangement on the original diagram in order to reduce clutter (it is in any case safe to assume that the memory modules are identical). Note that the multiplicities can be omitted, since a multiplicity of one would then be assumed for the ports, memory module instances and connector ends (the multiplicity of a connector end determines the number of connectable elements to which it may be connected).
Note that a connector can either be a runtime instance of an association (as used on a class diagram) or can represent a dynamic link of some kind that is set up at runtime to facilitate communication between parts of a structure. A connector could be created, for example, to enable an operation to be invoked or to facilitate the updating of instance variables. If the multiplicity of a connector end is not shown, it is assumed to have the same multiplicity as the part to which that end of the connector is attached. If the connector end is attached to a port on a part in an internal structure, and no multiplicity is shown, its multiplicity is assumed to be that of the port multiplied by that of the part, if any (ports will be discussed shortly).
The type of communication that may take place over a connector may be subject to constraints, including those that apply to the parts they are connected to (these can be shown using the appropriate notation). The name and type of the connector may be shown in the same way as for a part, using the syntax shown below.
name : classname
Note that it is usually unnecessary to name connections unless they must be uniquely identified for clarity. Our composite structure diagram for the personal computer system shows only the type of the connections representing the power connectors and signal cables connecting the power supply unit, mainboard, optical drive and hard disk. The connectors joining the memory modules and processor ports to the mainboard ports are not labelled at all, since they simply represent the physical interface between the processor and its socket, and between the memory modules and their slots.
Note, incidentally, that the number of ports used in our composite structure diagram for the personal computer system reflects the fact that every component in the system is designed to be upgradeable. Each component therefore connects to one or more other component in the system using a well-defined industry standard interface (which makes it very difficult to accidentally connect two incompatible components together). The concept of ports and interfaces is discussed in more detail below.
A port, in the context of a composite structure diagram, is any point that serves as an interface between a structured classifier and its environment, between a structured classifier and its parts, or between the parts within a structured classifier. A port is shown as a small square outline on the boundary of a classifier (i.e. a part, a class, or a composite structure), and represents the externally visible part of any instance thereof. The name, type, and multiplicity of the port may optionally be shown near this symbol. A port drawn on the boundary of a structured classifier is public by default. This means it can be accessed by entities outside the classifier. A port drawn completely inside the boundary is protected by default, and can only be accessed by entities within the classifier. You have already seen the port symbol in use on the composite structure diagram for the personal computer system (see above).
A port is usually associated with one or more interfaces. An interface specifies the kind of interactions that can take place over a port. An interface that specifies the services a classifier provides to its environment is called a provided interface. An interface that specifies the behaviour a classifier requires from its environment is called a required interface. External classifiers may access the functionality provided by a classifier through a given port providing they meet the specified behavioural requirements for that port. As an example, consider a hard disk drive in a personal computer system. The drive unit interacts with its environment via two separate interfaces (see below). One is a required interface that allows it to receive electrical power from the power supply unit. The second is a provided interface that allows it to service data storage and data retrieval requests received via the mainboard.
The page entitled "Class Diagrams" gives an example class diagram in which an interface is represented using a class icon. The interface can indeed be modelled as a class, although it will always be an abstract class and cannot be instantiated. The implementation of the interface is down to a concrete class that must implement the functionality specified by the interface. The defined functionality of an interface is exposed (visible to external entities), and any entity wishing to use the services of a structured class via one of its ports can do so by specifying the name of the interface to use, without having to worry about the details of the internal implementation. The abstract nature of an interface specification implies that it may be implemented by any number of classes. Differences between implementations are unimportant, providing each implementation functions as specified.
In composite structure diagrams a more convenient notation, known as ball and socket notation, is normally used to represent an interface. As you can see from the above example, a provided interface is represented as a ball (an outline circle) and a required interface is represented as a socket (a semi-circle). The Interface symbol is connected by a solid line to the port, which is in turn connected to the internal classifier that realises (i.e. implements the functionality of) the interface. In our example we have included an inset showing the class icon for the HDDCtrl class as it would appear on a class diagram, together with the abstract interface that it realises. A port that provides access to the published functionality of an interface implemented by an internal classifier is known as a service port.
If the classifier owning the port realises the functionality of the port itself (rather than the functionality being realised by one of its internal classifiers), the port is referred to as a behavioural port. If this is the case, the port is linked by a connector to a small state symbol inside the classifier to indicate that it is a behavioural port. By default, ports belonging to composite structures are service ports and not behavioural ports. Behavioural ports are sometimes to be found on simple (as opposed to composite) classifiers. We could conceivably model the HDDCtrl class as shown below. The functionality offered by port p is realised by the class HDDCtrl, which realises the diskAccess interface.
A port may be explicitly typed by showing the name of the port, followed by a colon, followed by the name of the classifier that realises the interface. Alternatively, the ball and socket notation used to denote an interface can be replaced by typing the port using the name of the interface. Examples of both approaches are illustrated below.
A port may also provide multiple interfaces when several distinct but related services may be accessed via the same port. The example below shows each interface represented by a separate interface icon. A single interface may be used to represents all of the interfaces (the name of the port appears near the interface icon and is followed by a colon, followed by a comma separated list of the interfaces associated with the port).
A classifier may also be associated with multiple ports, enabling different types of interactions to occur depending on the port through which messages are received. The classifier may even implement multiple interfaces.
A port may also be connected with multiple internal elements that realise the same interface, as in the example shown below.
A collaboration describes how two or more elements within a structured classifier co-operate at runtime in order to carry out a specific task. A collaboration diagram represents the collaboration as a dashed ellipse, with the name of the collaboration inside it, as shown below. The roles involved in the collaboration may be drawn within a separate compartment inside the ellipse, with the connections between them shown using a solid line. Each role is drawn as a rectangular icon, with the name of the role shown inside the icon. Roles may only be played by elements within the structured classifier that owns the collaboration. Each element playing a role in a collaboration becomes a property of that collaboration. The connections between the roles played by elements must be matched by a corresponding connection between those elements within the structured classifier.
The abstract nature of a collaboration means that it cannot be directly instantiated. In fact, it is possible for a role to be played by more than one element within a structured classifier. It is also possible for a given element to play different roles in different collaborations owned by the structured classifier. Since the purpose of a collaboration diagram is usually to describe some specific aspect of the functionality of a structured class, unnecessary details can be omitted, as can the precise identity or class of participating instances. The functionality offered by a structured classifier to its environment is often defined by the interfaces it presents to that environment. A collaboration can selectively focus on just one of those interfaces, and ignore any internal elements that are not involved in the functionality that it provides.
The association of a collaboration with a structured classifier is called a collaboration occurrence, and indicates that the collaboration represents some aspect of the functionality of that classifier. A collaboration occurrence is shown on a composite structure diagram using a dashed ellipse, as illustrated below. The name of the collaboration follows the name of the occurrence, with the two names being separated by a colon. A dashed line is drawn from the occurrence to a classifier icon, with an arrowhead pointing at the classifier to indicate that the collaboration is used by the classifier. The line is labelled with the keyword «occurrence».
The same notation is used to indicate that the collaboration represents the classifier, except that the keyword used is «represents».
The term collaboration use is used to describe the application of a collaboration to a specific situation, with specific classes or instances playing the various roles. Each role in the collaboration is referred to as a supplier. Each element that plays a role is referred to as a client. A collaboration use binds the client elements within a structured classifier to supplier roles in a collaboration. The relationship created between the roles and the elements that play them is called a role binding. All of the client elements must belong to the same structured classifier, and all of the supplier elements must belong to the same collaboration.
A collaboration use is shown as a dashed ellipse, inside which the name of the collaboration occurrence is followed by the name of the collaboration type, with a colon separating the two. Each client element involved in the collaboration is shown in its own rectangular icon outside the ellipse. The role binding is shown as a dashed line from the ellipse to the client element, labelled at the client end with the name of the supplier element. Multiple occurrences of a given collaboration may apply to a structured classifier, each involving a different set of roles and connectors. By the same token, the same role or connector may be involved in multiple occurrences of a collaboration, or a number of different collaborations. Above, we showed an occurrence of the Sale collaboration as belonging to a structured classifier called Distribution. This is what the Distribution composite structure diagram might look like:
We could create a collaboration use of the Sale collaboration involving the Wholesaler and Retailer properties of Distribution as shown below (you should be able to identify two other scenarios for which a collaboration use could be created).
It is quite acceptable to use one collaboration within the definition of another collaboration. Looking at the Distribution structured classifier, it can be seen that a sale of some kind may occur at three levels. The entire supply chain, from manufacturer to retail customer, can be modelled as a collaboration between all of the entities represented by the Distribution classifier. The wholesaler buys goods direct from the manufacturer and sells them to the retailer, who in turn sells to the retail customer. Buying and selling thus occurs at three levels in the supply chain. We can model this scenario using the SupplyChain collaboration shown below. You can see from the diagram that the Sale collaboration is used three times for the definition of the SupplyChain collaboration. The roles of Buyer and Seller are played by different clients at each level in the supply chain model.
This article was first published on the TechnologyUK.net website in January 2009.
Let's suppose we have been tasked with modeling a college management system for a large municipal college. As well as its various faculties, the college will have a complex support infrastructure. One of the functional areas we are investigating is the Estates department, which among other things is responsible for managing and maintaining college buildings and other facilities. We have identified a number of classes related to the physical infrastructure of the college. These include the classes Office, Classroom and Workshop, which store attributes and operations related to various types of accommodation within the college. The illustration below shows a couple of ways in which we might draw a package to represent the Estates department. Incidentally, the package diagrams on this page were created with the Astah Community UML modeling tool, a free educational edition.
The icon for a package is a tabbed rectangle that looks like the folder icon used in popular computer desktop operating systems. There are at least two ways of drawing package icons, as you can see, depending on the features of your UML modeling tool. In the representation on the left, the contents of the package are not shown, and the name of the package is displayed in the body of the package icon. In the representation on the right, the contents of the package (or a subset thereof) are included within the body of the package icon, and the name of the package is moved into the package icon's tab. Note that the naming convention for packages is the same as that for classes. Names start with an upper-case letter, and if the package name consists of more than one word, each new word also starts with an upper-case character.
Everything inside a package shares the same namespace, and must have a unique name. If a package element is referenced from outside the package, its fully-qualified name should be used. This will consist of the name of the package, followed by a double colon ("::"), followed by the name of the package element. For example, if we wanted to access the Workshop class in the Estates package, we would have to refer to it by its fully-qualified name, which is Estates::Workshop. The visibility of elements inside a package can be specified as either public or private. If an element has public visibility, it can be accessed by UML elements outside the package (providing the fully-qualified name is used to reference it). If the element has private visibility, only UML elements inside the package may access it, but they can do so without having to use the fully qualified name.
We said earlier that packages can contain other packages. As we uncover more information about the functional responsibilities of the Estates department, we find that there is much more going on here than we at first thought. Accommodation is only one area that the Estates department is responsible for. Others include parking for staff and visitors, site security, utilities (lighting, heating, water and sanitary facilities), maintenance, procurement (materials, equipment and services) and health and safety. Once we have gathered all of the required information together, it turns out that we have a significant number of classes for the Estates department that should probably be organised into a number of smaller packages. You can see the revised Estates package below. This is probably as good a time as any to point out that, as the analysis proceeds, your model will inevitably change and grow. This is a natural process that reflects the improvement in your understanding of the system requirements as you accumulate data.
Using package diagrams allows you to create a layered model that reflects the structural or functional hierarchy of the system under investigation (or part thereof). A package may include both sub-packages and classes. If a package contains only sub-packages, it can be referred to as a domain. In the above diagram, the Estates package is a domain because it contains only sub-packages. The relationship between a domain and its sub-packages can optionally be shown as a tree structure, using a line drawn between the domain and its elements with the nested class symbol (a circle with a "plus" sign inscribed within it) at the domain end, as shown below. This might be preferable if you want to show the relationships that exist between the sub-packages.
Each connection between a domain and a sub-class is conceptually similar to the connections used on a class diagram to connect the main class in a composition with its component classes (these connections are drawn using a solid line with a filled diamond shape at the end nearest the main class). Another kind of relationship that can be shown on a package diagram is a dependency. A dependency is indicated by a broken line connecting two packages, with an open arrowhead at the end nearest (and pointing to) the package being depended upon. This allows us to visualise how the various packages that make up a system or sub-system depend upon one another.
According to most interpretations of the UML specification, a dependency is a directed relationship that indicates that one UML element (or set of elements) depends on another UML element (or set of elements) for its specification or implementation. A dependency is sometimes referred to as a client-supplier relationship in which the supplier provides something to the client. In the example provided above, we are interested in showing which other departments within the college the Estates department depends upon in order to be able to function. The IT department will provide IT services (as it will to every department in the college) and the Finance department will allocate funds for the procurement of materials, equipment and services. Senior management will oversee all major decisions, and will determine policy.
Our diagram shows part of the system at a very high level of abstraction, and depicts the Estates package as the client for three supplier packages (SeniorManagement, Finance, and InformationTechnology). Note that we could also show dependencies that work in the opposite direction, since many departments within the college rely on the Estates department for various site services. The IT department will rely on floor plans and other site information held by the Estates department, for example, when it plans the deployment of computer equipment or needs to make changes to network cabling. The type of dependency involved can be specified by the inclusion of one of several standard UML stereotype keywords above the dependency arrow. For example, one of the stereotypes defined for dependency is «usage», which indicates that the supplier is used in some way for the definition or implementation of the client. We have avoided the use of stereotypes here, as they are probably more meaningful at a lower level of abstraction.
There are two special kinds of dependency between packages that you should be aware of. The first is called a package import, and defines a relationship in which one package (the importing package) adds the names of the elements in another package (the imported package) to its own namespace. A dependency is signified as a package import by adding the «import» stereotype keyword above the dashed dependency arrow. In fact by default, an unlabelled dependency between two packages is interpreted as a package import relationship. The package diagram below illustrates the concept.
The Shapes package imports both the 2dShapes package and the 3Dshapes package. Elements within the Shapes package may now access the elements of the other two packages using their unqualified names. Note that, by default, the visibility of imported elements is public (i.e. they can be accessed from outside the importing package). If the visibility of the imported elements is required to be private (making them accessible only to elements within the importing package), then the keyword «access» should replace the keyword «import» on the diagram.
Note that package import creates a potential for name conflicts to arise. In the event of an imported element having the same name as an element that already exists in the importing package, the pre-existing element takes precedence, and the imported element can only be reference from within the importing package using its fully qualified name. Individual elements of a package can also be imported into another package in a similar process called an element import. This works in more or less the same way as a package import, except that instead of one package adding every element of another package to its namespace, only the selected element is added (in order to deal with naming conflicts, an alias can be specified for the imported element). The dependency arrow connects the importing package to the imported element, rather than to its parent package.
The second special kind of dependency that you should be aware of is called a package merge. When one package (the source package) merges another package (the target package), the source package is extended by the elements in the target package. In other words, the characteristics of the target package are added to those of the source package, so that the source package essentially becomes a combination of both packages. This mechanism is useful when elements in both packages have the same name and perform a similar role. The process is much like that of generalisation (the UML term for inheritance) in the sense that a base package may be enhanced by adding the contents of another (related) package in which elements common to both packages have been enhanced in some way, or to which new capabilities (in the shape of new elements) have been added. Package merges can be carried out incrementally in order to tailor a source package for a specific purpose.
If a package merge occurs in which a class in the target package has the same name as a class in the source package, then the imported class will automatically extend (or generalise) the class in the source package. Classes that exist only in the target package are simply added to the source package, and classes that exist only in the source package remain unchanged. If the target package contains sub-packages, these are also added to the source package (if a sub-package in a target package has the same name as a sub-package in the source package, a separate merge process occurs between the sub-packages). In the illustration below, the 3Dshapes package merges the Polyhedra package. It will be extended by acquiring the Dodecahedron, Tetrahedron, Octahedron and Icosahedron classes. The Cube class in the source package (3Dshapes) will be extended (or generalised) by the Cube class in the target package (Polyhedra).
A dependency is signified as a package merge by adding the «merge» stereotype keyword above the dashed dependency arrow. The effect of the merge on package 3Dshapes can be seen below. New classes Dodecahedron, Tetrahedron, Octahedron and Icosahedron are created in 3dShapes that inherit all the characteristics of their counterparts in the Polyhedra package. The existing Cube class in the 3Dshapes package inherits the features of (is generalised by) the Cube class from the Polyhedra package. The target package itself is unaffected by the merge operation.
We mentioned earlier that packages are often used to group together the use cases on use case diagrams in order to illustrate some aspect of the functionality of a software system at a higher level of abstraction. The package diagrams we have looked at on this page have not included examples of packages being used in this way, because we will be covering this topic on the page dealing with use case diagrams.
This article was first published on the TechnologyUK.net website in January 2009.
Object diagrams and class diagrams look very similar, because an object is an instantiation (i.e. a specific instance) of a class. Both class diagrams and object diagrams represent a static, structural view of a system. Object diagrams are not frequently used, but they can sometimes be useful for demonstrating the way in which objects interact in a system "at run time" (i.e. while the system is actually running). The can be used, for example, to show how a small part of the system works when this is not immediately obvious from looking at a class diagram. Put another way, they provide concrete examples that can be used to explain abstract concepts. Whereas a class icon represents all of the instances of a particular class that exist, have existed, or ever will exist in a system, an object icon represents exactly one instance of a class at one particular moment in time. The illustration below shows the difference between how a class icon, and its instantiation as an object, are represented in the UML.
Many UML modeling tools do not provide facilities for the creation of an object diagram as such, but because of the similarities between object diagrams and class diagrams, most UML tools allow objects to be placed on class diagrams in order to facilitate the production of an object diagram. Notice that the icon for an object looks quite similar (it is still represented by a rectangular icon), but there are some differences. The name of the object is underlined to show that it is an object. It is also the convention to add the name of the class of which the object is an instance, following the name of the object and separated from it by a colon. In our example we have "HartleyJR : BankAccount", which indicates an object of type BankAccount with the name "HarleyJR" (note that the names of objects normally start with a lower case character).
The name of the object may be omitted where it is considered to be unimportant, provided the meaning of the diagram is still clear. If it is omitted, the object is said to be an anonymous instance of a class. If no object name is supplied, the name of the class must be present, and must have the colon in front of it to indicate that this is an object (i.e. an instance of a class), and not a class. The attributes defined for the class may also be shown, but the data type is omitted. Instead of the default value, an actual value for the attribute is shown. The format for displaying an attribute is to show the attribute name, followed by an equals sign ("="), followed by the value assigned to the attribute. In our diagram, for example, we have "balance = €576.23".
If the attributes of individual objects are unimportant for the purposes of the object diagram, you can illustrate multiple objects using a single icon, as shown below. The icon shows the details of the first object, with additional objects being implied by the addition of a second rectangle drawn in such a fashion that it appears to be behind the first.
The connection between two objects on an object diagram is called a link. A link is represented by a solid line between two object icons. A label showing the purpose of the link may be added if required. Just as you can think of an object as a single instance of a class, you can think of a link as a single instance of an association between two classes (note that a link can only be shown where the class diagram has a corresponding association). The difference between a link and an association is that a link connects two objects, rather than two classes. The object diagram below tells us that an object named "HartleyJR" of type Customer is linked with both an object named "HartleyJR" of type SavingsAccount and an object named "HartleyJR" of type CurrentAccount.
In order to illustrate a situation in which an object diagram might be used to clarify a situation that a class diagram alone may not adequately explain, consider the class diagram below, which describes a college information system. It might be useful to first examine just what this diagram does tell us about the system, and then consider what it might not tell us.
This diagram tells us the following things:
The class diagram does in fact tell us quite a lot, but there may be questions that haven't been answered. One obvious question here revolves around modules, because it would seem that a module could be a part of a number of courses. Faculties are split into departments, and it is the departments that have responsibility for administering the modules, whereas the courses are administered by the faculties. Does this mean that a module that is administered by a department of one faculty might be included on a course run by another faculty? The implication is that this is indeed possible, but some concrete examples would be nice. Let's look at an object diagram that provides such an example.
The object diagram shown above is designed to highlight the fact that a single course (in this case "Computing and Informatics") is administered by the Faculty of Technology, and includes a number of modules administered by the Computing department (as you might expect, given the title of the course). It also tells us that the course includes modules administered by both the Management department and the Finance department, both of which are in turn administered by the Faculty of Business Studies.
Object diagrams can be used to highlight all kinds of situations that can arise at some moment in the life of an information system, at an arbitrary level of detail (the level of detail shown on an object diagram should only be as much as is necessary to make the point we are trying to make). They are useful for helping stakeholders to understand a class diagram, or for showing a client how part of the system is supposed to work in a given scenario. They are not as a rule used by system designers or programmers to design an application or write program code (class diagrams are far better suited for that purpose).
An object diagram can sometimes be used to test the accuracy of a corresponding class diagram, or to show how an instantiated object relates to its class definition. Although it is not common for classes and objects to appear on the same diagram, sometimes part of a larger class diagram may be abstracted onto a separate diagram, together with an object diagram that provides a concrete example of the relationship between the classes involved.
This article was first published on the TechnologyUK.net website in January 2009.
A class diagram describes the structure of a system (or part of a system) in terms of the classes that exist within the system and the relationships that exist between them. A class is essentially a template from which any number of objects can be derived. It does not exist as an object in its own right, but it defines the properties (or attributes) that an object will have, and the operations that can be performed by the object. The class BankAccount, for example, will define attributes such as accountNo and balance. The operations defined for the BankAccount class could include functions such as returnBalance() or updateBalance(). An object of type BankAccount is an instance of the BankAccount class. Here is an example of the icon used to represent such a class within a class diagram:
The icon is essentially a rectangle, divided into three sections by horizontal lines. The top section contains the name of the class (BankAccount). The middle section contains the class attributes accountNo and balance. Note the minus sign ("-") in front of the name. This indicates that these attributes are private, i.e. they can only be accessed by the operations defined for the class and cannot be "seen" by other parts of the system. The bottom section contains the operations that can be carried out by the class, returnBalance() and updateBalance(). The operations have a plus sign ("+") in front of them showing that they are public, which means that access to them is unrestricted. The notion of classifying UML class attributes and operations as either private or public reflects the way in which class variables and methods in object oriented programming languages are declared. The idea (usually) is to hide the data items that belong to a class, while allowing access to them via the methods defined for that class.
You might like to make a note of the naming conventions used here. If a class, attribute or operation has a name that contains more than one word, there is no space between the words. The name of the class has a capital letter at the start of each word it contains. For attribute and operation names however, the first word should always start with a lower-case letter. The name of an operation is followed by a pair of parentheses. Still on the subject of naming things, the attribute names used should reflect, as far as possible, the nouns used to describe the things they relate to in the real world environment being modelled. The same holds true for the names used for operations, which should reflect the verbs used to describe operations that occur in the real world domain. These nouns and verbs will have emerged naturally during consultations with the client, and incorporating them into the system namespace will aid the client’s understanding of the UML model.
A class diagram usually includes a number of class icons, connected together by lines that indicate the type of relationship that exists between the interconnected classes. They provide a static view of the system, because although they show the relationships between the various classes they provide no information about what actually happens when these classes interact. Because they map so closely to the real world entities that comprise the system, class diagrams are a useful tool for enabling analysts to explain the system to clients. By the same token, they are also useful for enabling clients to discuss the problem domain with analysts. Once completed, they will form a design blueprint that can be used by programmers to create the application’s data structures and program logic. Here is a class diagram that might be used to represent a simple bank system:
The class diagram shown above was created with StarUML, which is a freely available open source UML modeling tool. Note that the class diagram for a system will inevitably be modified as more information is discovered about the classes, their attributes and operations, and the relationships that exist between them. The class diagram we will use in the design stage of a project will probably differ significantly from the class diagram we start out with in the early stages of the analysis process. It will certainly be more detailed, as we refine our knowledge of the system requirements. The class diagram above tells us quite a lot about the system, but some important details are missing. Let's examine each feature of the diagram and see how it might develop as we progress.
The attributes of a class (assuming there are any) are listed in the middle rectangle of the class icon, and represent some item of data that can be recorded about an instance of the class. An instance of the class BankAccount will have a unique account number, and an account balance that will vary over time. These attributes will be represented as data items in our application software, and in the system database. We should at some point therefore specify the data type that is to be used for these attributes. This is a good example of how software designers can communicate their requirements very precisely to programmers. UML allows you to specify the data type for an attribute (e.g. string, integer, floating-point, Boolean etc.), and an initial default value. Below is a modified version of the BankAccount class that demonstrates the principle.
The accountNo attribute is now shown as having the type String, while the balance attribute has the type Float. Both of these types are generic UML data types (other UML data types include the types Integer and Boolean). The accountNo attribute has been assigned the initial string value "00000000", while the balance attribute has been assigned an initial floating point value of zero (0.00). Note that most UML modeling tools will allow you to specify a data type that is specific to a particular object oriented programming language such as C++ or Java. This is useful if you already have a target programming language in mind when designing your application.
An operation is a task that the class can carry out in response to some trigger (usually a request from another part of the system). The operations defined for a class are listed in the bottom rectangle of the class icon, and the name of the operation is always followed by parentheses (brackets). The parentheses in the examples you have seen so far have been left empty, but they often contain the names and data types of one or more variables that will be passed to the operation as parameters (usually referred to by programmers as arguments) by whatever system entity has requested that the operation be carried out. The execution of an operation will usually generate some result that will be passed back to the requesting entity. The name and data type of this return value, if included, appears after the parentheses and is preceded by a colon. The parameter(s) that an operation takes, together with any return value, constitute the operation's signature. Here is the BankAccount class once more, amended to show the signatures for the two operations so far defined for it:
The purpose of the returnBalance() operation of the BankAccount class is simply to return whatever the current balance of the account happens to be. The operation therefore does not need any parameters, but will return a floating point value that represents the balance of the account. The updateBalance() operation, on the other hand, does not need to return a value. It does, however, require an amount by which to increment or decrement the account balance, and this is passed to the operation as a parameter named debit_credit of type Float.
It is worth noting at this point that once you start to add attributes and operations to a class, together with the associated parameter and data type information, the class icon will quickly grow. The effect of adding all of this additional information to a class icon can often be to make class diagrams look somewhat cluttered (bearing in mind, of course, that a class diagram may contain a significant number of class icons). It is perfectly permissible to hide any information that is not of immediate consequence in the interests of preserving clarity. To this end, many UML software tools allow you to hide the contents of the attribute and operation sections of the class icon in a class diagram.
The responsibilities of a class are generally considered to be its attributes and operations (i.e. the data it contains and the actions that it will be perform). Sometimes, in order to eliminate possible ambiguities, these responsibilities may be described in writing in an informal way. Depending on the UML software tool being used, it may or may not be possible to include this information within the class icon. This would typically involve an additional section being added to the class icon below the operations section (of course, if you were drawing the diagrams by hand, no such restrictions would apply). In some UML software tools, it is possible to create a note containing further information about a class that can be attached to the class icon, or connected to it via a dotted line.
The removal of ambiguity can be achieved in a slightly more formal way by using constraints. Constraints are rules that are applied to class elements. In the BankAccount class, for example, the accountNo attribute should always be an eight-digit numeric string. The constraint may be expressed either in natural language (which is easy to understand) or using the Object Constraint Language (OCL), a text-based language used to define rules for UML models and model elements. The constraint consists of a text string that defines the rule (either formally using OCL or informally using free text), enclosed within a pair of curly braces ("{ . . . }"). The rule for our accountNo attribute, for example, would specify that the string value assigned to this attribute for any instance of the BankAccount class must consist of exactly eight characters, and that each character must be a numeric character, i.e. 0, 1, 2, 3, 4, 5, 6, 7, 8 or 9.
A class diagram, as the name suggests, shows all of the classes in a system. Class icons alone, however, only tell part of the story. We can draw lines to connect the various classes together in order to show the relationships that exist between the various classes. These connections, when they appear on class diagrams, are usually referred to as associations. The connecting line may have an arrowhead at one end to indicate which way the association works, and a label that provides a name or brief description of the relationship. If no arrowhead is present, the association is assumed to be bi-directional. Depending on the UML software tool you are using, you may also have the option to place labels at either end of the line that represents the association to describe the role of each class.
Let's consider the relationship between employers and employees. We can represent employers using a class called Employer, and employees using a class called Employee. We can also use an association to model the relationship between these two classes as shown below. We have labelled the association "Is employed by", and the association has an arrowhead pointing at the Employer end (to indicate that the employee is employed by the employer).
We have already seen that each class on a class diagram can be connected to a number of other classes, but so far we have only seen a single association between any two classes. The relationship between classes can be seen differently, however, depending on the role each class plays. The relationship between an employer and an employee is a good example of this, because the employee works for the employer, whereas the employer employs the employee. We can show how the relationship differs, depending on the direction in which we look at it, as shown below.
Although the employer-employee relationship is a fairly trivial example of an association that can be seen from different perspectives (and one that shouldn't really need to be highlighted), it is perfectly acceptable to show two (or more) associations between classes. This is often done in order to draw attention to the fact that the interactions between the two classes may differ, depending on the direction in which they act.
An association between two classes may also be subject to some kind of rule. For example, supposing we are trying to model a timetabling system for a bus company. We might create a class called BusRoute to represent the bus routes operated by the company, and another class called BusStop to represent the locations covered by those routes. A bus route will consist of a list of stops that it must call at, including the stop at which the route starts and the stop at which it terminates. For a given route, the order in which the bus calls at each stop does not vary; it will call at each stop on the list in a specific order. We can show this constraint on the association between BusRoute and BusStop by using the word ordered enclosed within curly braces, as shown below. The constraint is placed near the association line, and close to the BusStop class.
The association between two classes may well have attributes and operations in its own right, which means that it could be represented by a class icon in the same way that other entities in our model are represented. In the UML, there is a special kind of class called an association class that is used to model such an association. The association class has its own icon, which is connected to the association to which it belongs via a dashed line. In the class diagram below, the association between an employer and an employee is represented by an association class called Contract, which has attributes that represent the details of the contract of employment issued by the employer to the employee. An association class can have an association with another class, as shown here. The association class Contract has an association with the HRManager class.
The multiplicity of an association may also be shown on a class diagram. The multiplicity of a relationship essentially tells us whether the relationship between two classes is a one-to-one, one-to-many, or many-to-many relationship. In the case of a one-to-many relationship, the notation used must tell us which end of the association represents the one and which end represents the many. Multiplicity is represented in class diagrams by including the appropriate notation at each end of the association. The table below shows the different types of multiplicities that may be found on an association, and how they are represented.
| Notation | Number of instances |
|---|---|
| 0..1 | zero or one instance |
| 0..* or * | zero or many instances |
| 1 | one instance |
| 1..* | one or many instances |
In the UML notation used here, the asterisk represents the word more (or many) and the two dots represent the word or. Probably the most commonly occurring type of relationship in a well-designed business information system is the one-to-many relationship. For example, an order may have many order items on it, but an order item can only belong to one order. A customer may place many orders, but an order may only relate to one customer. Below is part of the simple bank system class diagram we saw earlier.
The association between the BankAccount and Transaction classes has a one-to-zero-or-more relationship. From the point of view of our system, a transaction can only relate to one account (the account must exist in order for there to be the possibility of a transaction being made). When the bank account is first opened, there will be zero transactions, so at that point in time we have a one-to-zero situation (one bank account, zero transactions). Over time, however, we can expect a number of transactions to be made. Even if the account is closed again immediately after it is opened (unlikely as that might seem), the multiplicity holds true because it allows for zero transactions.
The association between the Customer and BankAccount classes is characterised by a one-to-one-or-more relationship. A bank account can only belong to one customer (we make the assumption here that, for a joint account opened by close relatives or business partners, the parties jointly owning the account will be treated as a single customer entity). A customer, on the other hand, might have several accounts (e.g. current account, savings account, business account, and so on). At the BankAccount end of the association, the multiplicity is going to be one-or-more rather than zero-or-more. This is because, due to the nature of a bank, a customer is not a customer until they have opened some kind of account.
One of the less common types of association is the association a class may have with itself. This type of association is called a reflexive association, and only occurs when a class may have more than one role. The diagram below shows how an Employee class could be related to itself if an instance of this class has a manager role. Bear in mind that the instance of Employee being managed will be a different instance to that which manages it.
Programmers that use an object-oriented language such as C++ or Java will be familiar with the idea of inheritance in the context of classes. In the UML, the word generalisation is used instead of inheritance, but it means more or less the same thing, which is that one class can be a sub-class, or child class, of another class (the parent class). The child class will have a different name, but inherits all of the characteristics of the parent class including its attributes and operations. Child classes tend to be specialisations of their parents and may have additional attributes and operations that the parent class does not have.
Nature provides some good analogies to help us understand generalisation. If we think of Animal as a parent class, we can think of Mammal as a child class. Mammals have all of the characteristics attributable to animals because they are . . . well . . . animals! They have a number of specialised features, however, that define them as mammals. So while all mammals are animals, not all animals are mammals. The class Mammal is therefore a specialisation of the class Animal (which is a generalisation). Both classes have some attributes in common (e.g. species, heterotrophic type etc. (a heterotroph is a living organism that must ingest other organisms or their by-products to sustain life). The Mammal class, however, has an additional set of characteristics that other types of animal do not have, such as the ability of a female to produce milk to feed her young, and the possession of hair (at least in the early stages of life).
A child of one class may be a parent class to another (more specialised) class. The class Dog, for example, is a child of the class Mammal. In the UML, inheritance is shown on a class diagram by a line that connects the child class to its parent class, a bit like an association. At the parent end of the connection, however, you will see an open triangle that points to the parent class. The diagram below illustrates the principle. Note that a number of classes can inherit the characteristics of a single class to form their own unique specialisations.
Although we have not explicitly shown any attributes or operations for any of the classes shown here, you should note for future reference that it is unnecessary to display attributes or operations on a child class that have already been specified for a parent class, because the child class will automatically inherit them. You might recall that we have already seen an example of generalisation in the simple bank system class diagram we looked at earlier. Part of that diagram is reproduced below. You can see from the diagram that the classes CurrentAccount and SavingsAccount are both children of the BankAccount class. A class that is used purely as a generalisation from which to derive other (child) classes, and which is not used to create objects (instances) in its own right, is called an abstract class.
A dependency is a relationship, like an association, but one in which one class depends upon another. You need to be slightly wary here. Think about the class Car for example. It would be natural to think of the Car class being dependent on, say, a class called Wheel. While this is true, the relationship between Car and Wheel would better be described as an aggregation or a composition (these relationships will be described shortly) in which the Wheel class is represented as a component of the Car class. A better example would be the relationship between a car and the fuel it runs on, or the oil that is used to lubricate its engine (you can probably think of other examples), since these things are absolutely necessary for the car to operate but do not constitute part of the car itself. The diagram below illustrates the relationship. Note that the UML indicates a dependency using a dashed line to connect the two classes, with an arrowhead at one end pointing to the class depended upon.
An aggregation is a special kind of relationship that describes the fairly loose coupling of a number of component classes via some main class. Together, these classes form a collection that constitutes a whole. The whole is represented by the main class, while the parts that belong to it are represented by the component classes, which are connected to the main class via a solid line that has an outline diamond shape at the end nearest the main class. The thing to note about aggregation is that the component classes do not necessarily have to belong exclusively to one particular whole. They may also be part of any number of other collections, and may also have a lifecycle that is different from that of the collection as a whole.
A computer system can be seen as an aggregation because it has many components, some of which may be shared. Your home computer system will typically have a base unit consisting of a case containing a motherboard, power supply unit, disk drives, memory, video graphics adapter, sound card and (of course) one or more central processing unit. It will also have peripheral components such as a visual display unit, keyboard, and mouse. In addition you will probably have a printer attached to the system, and maybe other devices such as a scanner, a webcam, or stereo speakers. Some of these components are dedicated solely to a single system, while others could be shared with (or removed and connected to) another computer system. Virtually any computer peripheral that is not inside the main computer casing can be shared with another computer. It is not uncommon for two computers to share a mouse, keyboard and display unit via a KVM unit, for example. In addition, every component of the computer system can be replaced one or more times during the lifecycle of the system. Here is a class diagram that depicts this situation.
A composition is very similar to an aggregation in that it is represented by a main class and a number of component classes that together make up a whole. The component classes are connected to the main class via a solid line that has a diamond shape at the end nearest the main class, but this time the diamond shape is filled. The composition can perhaps be described as a stricter kind of relationship in which the entire collection of component classes belongs to just one main class, and the lifecycles of all component classes are coincident with that of the main class. Consider the example of a house. A house might have a living room, a dining room, a kitchen, a bathroom, and one or more bedrooms. We could model the house as a composition for which the main class would be the House class, and component classes would be used to represent the various room types. The diagram below illustrates the concept. A room cannot belong to more than one house, and the lifecycle of the House class will control the lifecycle of its component classes (if the house is demolished, its rooms will cease to exist).
The question of whether a collection of classes constitute a composition or an aggregation is not always easy to decide. As a very general rule of thumb, if the system being modelled is a self-contained physical entity like a car or a building, a composition is usually chosen. If modeling a collection of components that make up something less tangible, such as a software system, an aggregation might be better. A single field in a database that is used to store information about car parts, for example, might contain the part number of a component that is common to many different models of car. The computer system was modelled as an aggregation even though it represents a physical entity because, unlike a car, every single component can be replaced by an identical or upgraded component. Furthermore, many of the computer system's components may be shared with other computer systems, and some components may be removed altogether without rendering the system unusable.
An interface is something that hides the underlying complexity of something while at the same time allowing you to make use of the facilities that it provides. You do not need to understand the workings of the internal combustion engine or the complexities of motor vehicle electronics, for example, in order to operate a car. You do, however, need an appropriate interface through which to access the services these things provide. In a car, that interface is comprised of the steering wheel, gear stick, control pedals, and the various switches and buttons that control the lights, heater, windows and accessories. The same is true of the electrical appliances in your home or place of work. In fact nearly every modern electrical, electronic or mechanical device you can think of has some type of control interface that enables you to use it without needing a degree in engineering.
In the UML, an interface is a set of operations that one class can carry out on behalf of another class. The interface is often modelled using an icon very similar to a class icon. It has no attributes of its own, but defines a set of operations that can be used by other classes. To identify it as an interface on the class diagram, the stereotype notation is used. This consists of the word "interface" enclosed between guillemets (double angle brackets), which appears above the interface name. In the example shown below, the Database class has an interface called dbAccess.
The relationship between a class and its interface is called a realisation, and is denoted by a broken line with an open triangle at the end nearest the interface, pointing at the interface. The realisation is like a contract between the class and its interface, in which the class undertakes to implement the operations defined by the interface. The interface itself does not constitute a class as such, but is somewhat like an abstract class. It cannot be instantiated, and does not implement the operations that it defines. In our example, the Database class is responsible for implementing the operations defined by the dbAccess interface. When a class implements an operation defined by an interface, the implementation must have the same signature as the declaration provided by the interface (that means that it must accept the same number and types of parameters, and return the same return value type).
You will note from the diagram that any class wishing to interact with another class via its interface will be connected to the interface via a dependency. This takes the form of a dashed line, with an open arrowhead at the interface end, pointing at the interface. The interface separates the operations that a class is expected to implement from the implementation itself. Other classes wishing to avail themselves of those operations do so via the interface rather than through the class that realises the interface (i.e. that implements the operations). The benefit of this approach is that if the concrete implementation of those operations changes, it should not affect the classes that depend on them, since they always access them indirectly via the interface. Note also that all of the operations defined by an interface have public scope, so that any class can use them.
UML 2.0 introduced an alternative way to represent an interface Instead of a rectangular icon, a simple ball-and-socket symbol is used to represent the interface. In this notation, the interface is named but details of the operations it performs are omitted. The connection between the interface and the class that realises it consists of a solid line from the class to the ball part of the symbol, while the class that depends on the interface is connected in similar fashion to the socket part of the symbol. You should use this representation if the class diagram you are producing does not actually need to show the specific operations provided by the interface.
This article was first published on the TechnologyUK.net website in January 2009.
The Unified Modeling Language (UML) is a graphically based specification language for modeling software-intensive systems that has, since the late 1990s, become a de facto standard in the object-oriented software engineering industry. The UML employs a variety of diagrams to model different aspects of a system during the course of its development. The UML began life at the Rational Software Corporation, which itself started out as Rational Machines in Massachusetts in 1981 and was eventually acquired by IBM in 2003. In 1996 Rational tasked three of its software engineers with developing a non-proprietary unified modeling language.
Grady Booch, who had been with the company from the outset, had already developed a widely-used object-oriented modeling method (known as the Booch method) that was ideally suited for object oriented design (OOD). James Rumbaugh, who joined the company in 1994, developed his own very popular Object Modeling Technique (OMT) which was more suited to object-oriented analysis (OOA). In 1995 the third member of the team, Ivar Jacobson, was recruited. Rational had acquired the Swedish software company Objectory AB for whom Jacobson worked, and Jacobson had invented the Object-Oriented Software Engineering (OOSE) method. The three software engineers, nicknamed the Three Amigos, worked in consultation with a number of major players in the software industry. Their efforts culminated in the formation, in 1996, of an international consortium called the UML Partners.
In addition to Rational Software, consortium members included a number of other high-profile companies, including DEC, Hewlett-Packard, Intellicorp, Microsoft, Oracle, and Texas Instruments. Its aim was to produce a complete specification for the UML and submit it in response to a Request for Proposals (RFP) issued by the Object Management Group (OMG) for a standard modeling language. OMG was itself a computer industry consortium, formed in 1989 and dedicated to the creation and maintenance of computer industry standards. A draft specification (UML 1.0) was submitted to OMG in January 1997, but it was a revised specification (UML 1.1) that was adopted by OMG in November of the same year. The standard has since that time undergone a number of amendments and revisions, but remains under the auspices of the Object Management Group. The latest major revision was UML 2.0 which was adopted by the OMG in 2005, and the most recent specification at the time of writing (released in December 2017) is UML 2.5.1.
The UML 2.x specification is broken down into four parts:
The UML is not a development methodology in its own right, although it has given rise to several development methodologies based on it. The best known of these is perhaps IBM's Rational Unified Process (RUP). The UML was designed to be compatible with a significant number of contemporary object-oriented development methodologies. Concepts from many of these methodologies were considered when the UML was being formulated, with the result that it can be applied to a wide range of object-oriented software development projects from small, single-user applications up to enterprise-wide, distributed information systems.
The UML specification is also extensible, and provides two mechanisms (stereotypes and profiles) to enable users to create new diagram types and model templates to suit a specific application area. One possibly negative aspect of such a broad-spectrum and flexible approach is that the UML specification is large and complex. Critics have claimed that, as a consequence, UML is difficult to learn, includes many diagrams that are rarely if ever used, and ignores some widely used diagrammatic modeling techniques such as data flow diagrams and structure diagrams.
More detailed information on the UML standard and related standards can be found at the Object Management Group's website:
The UML is also covered by an international standard, although the current standard relates to version 1.4.2 (the current status of the standard is described as "under review"):
An information system consists of some combination of hardware and software. Its purpose is to provide a solution for some kind of business problem. For most information systems, by far the greatest investment in terms of both time and money goes into the creation of the software element. Due to the highly specialised nature of software engineering, the analysis and design functions necessary for the development of a new information system are carried out by people who are specialists in these areas. These specialists do not usually have prior knowledge of the business area (i.e. the real-world domain) in which the system will be deployed. The client (the person or organisation commissioning the new system), on the other hand, knows their business inside out but does not usually have more than a superficial knowledge of software engineering principles, or the capabilities and limitations of hardware. There is a further dichotomy between the systems analysts, who investigate the problem domain and formulate a solution, and the software developers, who must design and implement that solution.
Given the possibility of misunderstandings occurring, there is an obvious danger that software developers will ultimately produce something that does not live up to user expectations. As software projects become larger and more complex, the probability increases of misunderstandings arising, because more people will be involved in the project, more information will need to be collected and processed, and many more channels of communication will be required. Each additional line of communication increases the potential for error. Anything that can improve communication, and thus reduce the possibility of misunderstandings occurring, must therefore increase the chances of a successful outcome.
Several decades of experience has shown that simply producing greater volumes of paperwork, or documenting everything in excruciating detail, does not usually solve the problem of poor communication. If anything it can compound the problem because the sheer volume and complexity of the documentation often means that some problems go undetected. The documents used by analysts, whilst meaningful to the analysts themselves, are often unintelligible to the client. In fact, they are not always easy to work with even for software designers and programmers. More importantly, if the client does not understand the proposed software solution, they have no way of knowing whether it is going to do what they actually need it to do.
The UML can be used to produce a model of the proposed system in a graphical form that is easily understood by all parties concerned (the project stakeholders). Stakeholders include analysts, software designers, programmers, and the client (this last group includes the individuals responsible for making high-level decisions, the end users that will be operating the system, and the technical staff that will be maintaining and supporting it). The UML will also produce documentation that is compatible with both object-oriented analysis and design methods and the object-oriented programming languages that may be used to implement the software.
The model itself consists largely of a collection of diagrams that represent various aspects of the system. There are a number of different types of diagram, each of which has its own role to play in the development process. The model is a blueprint for a software system in the same way that a set of architectural plans constitutes the blueprint for a building, or a set of engineering drawings becomes the blueprint for a piece of machinery. There are many analogies to be found in traditional branches of engineering. The main difference is that, whereas other engineering disciplines have traditions that go back hundreds or even thousands of years, software engineering is still in its infancy. Ironically, the sheer speed of developments in computer technology has meant that our ability to develop highly advanced information systems has not always been matched by our ability to monitor, document and control the development process. The UML is an attempt to rectify that situation by creating a set of standard diagrams that can be used to describe every aspect of a proposed system.
One of the criticisms of the UML is that there are too many different types of diagram (thirteen in the current version). It is true that some diagram types are rarely if ever used. On the other hand, the number of different diagram types is intended to ensure that all stakeholders can view those aspects of the system in which they have a particular interest, expressed in terms that they can understand. Each type of diagram presents a different view of the system, or part thereof. Different types of diagram may represent different stages of development, and each type of diagram will be of particular interest to a different group of stakeholders. Another way of describing this is to say that different types of diagram represent different levels of abstraction (they show those system features that are of interest to the stakeholder, and hide everything else). One type of diagram might provide a high-level view of the entire system, for example, while another type of diagram might provide a detailed view of a specific system component.
Broadly speaking, the UML model consists of two main categories of diagram. One category includes those diagrams that present a structural view of the system. When we talk about structure (or architecture), we mean things like data objects, the operations that can be performed on them, and the relationships between them. The other category includes diagrams that represent the behaviour of the system. This type of diagram can represent the way in which different parts of the system interact, how the state of various system parameters changes over time, or the sequence in which various types of event may occur.
A model, then, is a collection of interrelated diagrams (possibly accompanied by some written documentation) that describes every aspect of the system, at different levels of abstraction. The model can be modified as development progresses in order to reflect changes required due to the discovery of some previously unforeseen problem, or because the client has amended or added to their list of requirements. It models the structure of the application and the dynamic processes that will occur within it. It models the roles of the various users of the system (the actors), the business processes that the system is designed to support, the activities that must be undertaken in support of those business processes, the data structure, and the system logic. It does all this in a relatively easily-understood format that is highly compatible with an object-oriented programming language.
At the time of writing, the current version of the UML specification is version 2.5.1, which has thirteen different types of diagram. The different types of diagram can be split into two main categories. Six of them represent structural information about the system. Put another way, they can be used to represent different aspects of the system's architecture and deal with things that must be included in the system. The remaining diagrams each describe some aspect of the system's behaviour. Of these, there are four types of diagram that relate specifically to the interactions that occur between the various system components. Because all of these diagrams essentially show different views of the same system, it is not uncommon to find the same elements appearing on different types of UML diagram, but in a different context. Bear in mind also that because the UML is designed to be extensible, you may also come across user-defined elements and diagram types.
The following list shows the standard diagram types and how they are categorised:
This article was first published on the TechnologyUK.net website in January 2009.