This chapter is from the book
This chapter is from the book
This chapter is from the book
11.5 Overlay Platform Specifics on Top
At the end of the day, the system you are building must execute on some target platform. You must incorporate some user interfaces. If you need to offer high processing capacity, you must distribute the processing across processing nodes. Distribution is platform-specific. You must provide persistent storage for information managed by your system. You might need to integrate with a legacy system. Thus, you see that platform specifics occur throughout the realization of a use case whether this is an application use case or an infrastructure use case.
11.5.1 Choosing the Platform
The platform specifics for a system are based on the deployment structure and process structure chosen by the architect. In this case, we assume that the architect has chosen a J2EE-based solution. Figure 11-3 depicts the deployment structure for the Hotel Management System. It is annotated with the architect's choice of communication mechanisms, implementation languages, and technologies.
)
"
Figure 11-3 Deployment structure for Hotel Management System design model.
Figure 11-3 depicts actors so you can readily see how the deployment structure relates to the use-case model. The customer accesses the system through a phone or his own PC. The customer PC interacts with the application server over a wide area network over HTTP. The application server accesses that database to retrieve records, update records, and so on. Access to the application server is through Remote Method Invocation (RMI). Hotel counter staff and hotel management access the system through their PCs. Staff PCs uses Java Swing, which is a GUI framework for Java. For those nodes that use Java as a programming language, AspectJ is used as the composition technology.
Zooming into each deployment structure, you find active elements (i.e., processes and threads) executing. This is depicted in Figure 11-4, which shows the customer PC running a browser, whereas the staff PC runs a thick client. The application server runs a Web container and an EJB container. The staff PC communicates using HTTP with the Web container, which in turn communicates with the EJB using RMI. The thick client communicates with the EJB container directly. The EJB container communicates with the relational database using Java Database Connectivity (JDBC).
)
"
Figure 11-4 Process structure for Hotel Management System design model.
11.5.2 Keeping Platform Specifics Separate
Even with a chosen deployment and process structure, there are still many platform-specific implementation technologies to be chosen. You most definitely do not want to be tied down to a particular execution platform or even to a particular vendor. Platform-specific technologies evolve, and a new and better version becomes available regularly. It would be disastrous if you had to modify the design just to keep up with the changes in these technologies. Thus, you would like to keep platform specifics separate.
If you strip away the platform specifics from the design of a use case, what remains is a minimal use-case design. This minimal use-case design has the following characteristics:
- It is executable and is implemented in a default programming language such as Java.
- It is activated through a program interface. A separate program triggers the minimal use case. In this way, all concerns on user interface, presentation of information, and data input mechanisms is kept out of the minimal use-case design.
- Concerns about distribution, interprocess communication, and platform-specific messaging are kept separate from it. So, the minimal use case design appears to run on a single node, a single process, and a single thread, when in fact it is running on the chosen platform described earlier.
- Every piece of information it needs is assumed to be in memory. In this way, all persistency concerns are not present in the minimal design. Likewise, each action from the actor instance is an atomic action.
Everything else (user interface, distribution, etc.) is considered platform-specific and is designed separately and overlaid on top of this minimal use-case design.
Figure 11-5 shows a use-case design slice decomposed into the minimal use-case design slice plus several platform-specific slices for the use case. There is a platform-specific slice to modularize the user interface design for the use case, another platform-specific slice to modularize the distribution of the use case, and yet another to handle platform-specific persistency. There could be potentially other platform-specific slices, depending on what kinds of platform specifics you want to overlay on top of the minimal use-case design slice.
)
"
Figure 11-5 Use-case design slice with platform specifics kept separate.
The benefits of separating the platform-specific parts from the minimal use-case design are many. First, the minimal use-case design is significantly simpler. Anyone who knows the designated programming language can develop it without knowing all the platform specifics. The minimal use case design is easy to design and develop, and you can produce an executable quickly. It is also much easier to test because it does not require any platform-specific test environment.