Any process needs participants. In modeling UML, we refer to these participants as roles or actors depending upon whether we are describing the participants (roles) or modeling them (actors). In this case we are using actors to account for departments as well as individuals. Our primary actor is the developer representing the different roles in software development. Secondary actors include the infrastructure that represents the roles needed to deploy the software and business analysts representing the requirements and the users.
There are three steps in the deployment diagramming process:
- Pre-Stage: determining the initial hardware requirements for deployment.
- Staging: adding the different software components to the deployment diagram.
- Production: associating the hardware requirements with the actual hardware.
Each of these three steps occurs during different times in the project. Each step can be iterated throughout the software development lifecycle. If there is a change in a previous iteration, the diagramming should be restarted.
In the rest of this article I will show you how our friends at Richmen Inc. from part one used deployment diagrams with their trade entry application. There were two parts to this project: trade entry and using market quotes.
The pre-stage step is used to determine the overall hardware needs for the project, as determined by the third-party software used, special technologies, or other architectural constraints. The developers will meet with infrastructure and business analysts to determine the initial requirements. This stage may iterate through multiple proof-of-concepts (POC) used to test out critical architectural pieces of the project and determine the needs of any third-party software used.
|Figure 2. Pre-Stage Step: The pre-stage deployment diagram for Richmen Inc. shows two servers and one client. I also showed the components encapsulated within the nodes, which is an alternative method in UML.|
This first step is used during the project to determine resource allocation, budget allotment, and by the infrastructure to schedule the purchasing and configuration of hardware for the project. This can be iterated throughout the project but if this part is changed then both the staging and production stages will need to be updated to reflect this.
In the case of Richmen Inc., mentioned in the previous articles, there was a legacy component that was used for entering trades. This component was written in VB 6.0 by the "SuperTradeEntry Company" and used SQL Server v. 7.0. Another component was used for quotes. One of the leading vendors of quotes, QuoteMaster, Inc., has a product that automates the download and maintenance of live equity quotes used in the previous article.
Not every component is displayed in Richman Inc's deployment diagram. The two components TradeEntry and FastQuote represent vendor software. In this example, each will only be one component but there may be cases in which, initially, only one component is displayed that represents a whole vendor subsystem. In other cases, a vendor component will be added to as further iterations uncover expanded vendor details. Notice that the attributes on each server and the client represent the requirements of the software for this project. They do not represent the actual server configuration that might be used for other projects as well.
The example already has some value. The infrastructure has some upfront information that can be used for planning the new deployment. This is also useful for the business when explaining about POCs for vendor software and to give them some perspective on the true scope of a project.