FIGURE 1. All Components

Starting with our primary system, the gradebook application, we can put it on an application server machine for now.

FIGURE 2. Application Server

Instead of identifying what artifacts will go on the application server along with the gradebook application, what artifacts cannot go on the same machine? We know that we are distinctly seperate from the registration system and also from the registration data. The web browser is another artifact that cannot be on the same machine as the gradebook application. The rest could go on the same machine:

FIGURE 3. Application Server with Everything Possible

This is the bottom-up principle, to identify the actual things and then classify them rather than deal first with the classification. This will minimize the number of machines required. If you have a reason to use more machines such as for performance, it is easier to spread out the componets to more machines than try to consolidate them.

Databases are special. They are not simple artifacts but are entire execution environments similar to a machine, called an execution environment node.

FIGURE 4. Execution Environment Node

Because of that the Database Management System (DBMS) is displayed in a similar manner to how we represent a machine. Other execution environments that have to be identified are the Java Virtual Machine (JVM) and other scripting environments that require a major software system in order to operate.

FIGURE 5. Application Server with Everything Possible and a Database

Here is where I hope you notice the problem with the username/password data. It is sitting on our application server. It is used by our gradebook program. We never identified a way to populate this data nor for a way for users to change their password. We do need a means to authenticate our users. If we manage it then we need to go back and expand upon our use cases. Each design technique alone will not provide you all the information you need. We may get to our last design technique and discover something we totally forgot about and have to go back and fix all the diagrams we created to account for it. While that may take a few hours or days to do, it is much preferred to the situation where we have to re-do weeks or months of work.

Talk to the client. In this situation, we will be lucky. There is an authentication server in the department that already maintains usernames and passwords that we can interface to similarly to how we will interface to the registration system.

Our application server will then only contains the gradebook program, gradebook data with database, and web server. The authentication system and data (username/password data) are on its own machine.

Is the username/password data in a database? Does it have to be? We were very sure that the registration system has a database and our gradebook makes use of a database. The best rule of thumb is if you are not sure if you need it -- don't include it. As we iterate over our many diagrams, we will discover that it is easy to put something in and very hard to remove something. If we say that the username/password data is stored in a database then looking back later on we may think that it is in a database for a reason. That is not the case here.

FIGURE 6. Application Server and Authentication Server

It is equally likely that the department has an existing web server that we should use instead of deploying our own. However, in this situation we will be deploying our own web server running on our application server.

The registration system and data are on its own machine:

FIGURE 7. Registration System

The web browser would be on the client machines. In a web-enabled system, the browser may not always be a desktop version of a browser. Does your client envision users who have mobile phones with a web browser or a handheld computer with a web browser? If so and you plan to support them, you should identify them here in the deployment diagram. It is unlikely though not impossible for instructors, teaching assistants, or administrators to use phones or handhelds. It is more likely for students to use such devices. Entering scores could be awkward even if well done on such a small screen but viewing scores is a reasonable activity. We would then have three different machines where a web browser may run: desktop, phone, or handheld.

FIGURE 8. Web Browser Devices

An alternative representation is available given that the web browser is the only deployed artifact on the machines. For that we can just list it without a box without either an icon or a keyword.

Since we are on the topic of alternative representations, we could use a tag to represent the different types of clients. A tag can further explain the characteristics of the machine. Tags may identify a particular type of machine architecture required, amount of memory, or operating system. We can use it to specify the type of machine. This method does not provide any additional information but is simply a different way to represent the different client machines. Since we are trying to hit the major points without overwhelming you with lots of detail, I will stick to our previous form. Just be aware there are alternative ways to describe the same thing.