Modeling Enterprise-Class Java applications and their deployments

Summary

Today, UML has been used to model software systems for years. However, I rarely see detailed discussions or examples of modeling and technology for modern software systems. For example, modeling applications and their deployment requires the development of various prototype systems and the need to use an organized approach to design the scope and layout of the diagram to make it work. Modeling is particularly important in complex environments, not only for software engineers who write code, but also for software configuration management teams and production services teams that are responsible for properly configuring and deploying software systems. This article demonstrates several methods for modeling modern software that can be used to communicate architectural details accurately and concisely.

Brief introduction

Not long ago, useful enterprise applications were built from a handful of entity beans, more session beans, and some jsps. The EJB is packaged in a jar file, and the JSP is simply stored in the Web server's classpath. If there is anything else in the software industry that you can be commended for, it is that the software grows exponentially in terms of size, functionality, and complexity. The size of the software has grown to the extent that every part of each enterprise application is stored in a compressed-format war and ear file. The complexity of software systems requires efficient modeling to help manage design and interrelationships. Software functionality is now at a level where you need to define a complete new paradigm-a service-to manage it.

Software complexity must be managed because it has a large impact on the enterprise. This management can take the form of planning and communication at the same time. You can now use UML to help you plan your software's architecture, design, and deployment. It can also be used to send these plans to various departments in the enterprise that must create, install, and maintain enterprise software.

If you were modeling your code, UML 1 x would have been pretty good. When modeling the packaging and deployment of a software system, it seems to be inadequate. With the advent of UML 2.0, UML has greatly enhanced the capability of modeling core software systems. However, the real bright spot for UML 2.0 is when modeling software packaging and deployment.

The purpose of this paper is to demonstrate several effective methods for modeling modern software systems that can be used to accurately and concisely convey the details of architecture, design, and deployment to the relevant responsible departments in the enterprise. I have not stated that this is the only way to model modern software. UML is quite rich in modeling languages. However, this article will help you if you are unsure how to use uml.2.0 for quick modeling, especially for the BEA WebLogic platform modeling.

Modeling challenges-less is more

I prefer a more agile modeling approach. Modeling a software system does not benefit the company directly, but the executable software can benefit from it. However, modeling is an effective communication tool that enables the entire organization to agree on how to build, deploy, and manipulate software.

In the modeling of software, in fact, less is more. The code increases over time, and the model is static, a snapshot of the design idea at some point. Therefore, it is not much use to model every detail of a software system. The details of the software system are changing organically. The best approach is to model the core parts of the software. These models can often play a role in a long time.

Modeling the Code

I'll start with a code-specific model and then move on to the software package and deployment diagram. In the process, I think you can well understand what level of detail is right for your business. It's important to keep asking yourself, "Is this diagram going to help you understand the design?" ”。

First, let's take a look at what I call the "over-modeling" modeling approach. Figure 1 shows a UML diagram of an entity bean that uses a bean-managed persistence. In this diagram, you can see 3 main interfaces and their root interfaces, as well as implementation classes.

Figure 1. To over-modeling an EJB

At first glance, there seems to be a lot of content in the picture. In fact, this model is only more detailed, in fact, little content. The diagram actually shows the basic structure of an entity bean. An engineer who knows a little bit about EJB knowledge will find that the diagram is actually very simple. If you provide a complete design document full of such "worthless things," engineers will soon get bored and refuse to accept this "useless" design document.