Pattern-driven design and development in xde (I)

　 Abstract:

The software model, especially the design model, is becoming more and more important in today's software development. Many standards, tools, and development methods have introduced the concept of patterns. This article introduces how to model the software mode in UML, and introduces in detail how to define and apply the mode in combination with the specific tool rational xde, and pointed out some related problems.

　　Part 1: UML representation of a pattern

　1.1 Software Model

The concept of software pattern has been around for a long time. When the Software Industry drew the concept of pattern from other engineering industries such as the construction industry and evolved it into a software pattern, undoubtedly, it is the result of a revolution in the field of software engineering. The classification and description of the design pattern by gof makes the concept of pattern more specific and can be used in software development.

In simple terms, the so-called mode is a successful solution for a specific, recurring problem. As far as the problem itself is concerned, it can be applied to any field or category. There are patterns in fields such as architecture, music, writing, and management. In the software field, the pattern is presented as an agreed document for record, learning, and communication. Experienced programmers can pass on their knowledge to others through a more formal model. Therefore, the pattern can be seen as a concrete, documented experience and knowledge.

In the past ten years, the software model has been greatly developed. It is not only an expression of experience, but can now be used as a driving force for program development. Pattern-driven software development is no longer a new thing. However, in today's software development field, a development idea or process is hard to be widely used without powerful tool support.

The software model has three levels of Abstraction: Architecture Model, design model, and idiom.

1. Architecture Model: provides solutions to the problems encountered in the architecture design. Examples of architecture include pipe-filter mode, whiteboard mode, MVC mode, and ORB mode. The architecture model is not necessarily object-oriented. Its idea can be used by any development method. Therefore, it may be difficult to describe using UML, and some specific proprietary Descriptive methods, such as C2 (component-connector), are usually used. Most of its tools are currently under research.

2. Design Mode: provides solutions to the problems in the specific object-oriented design, so that the design results are more scalable and reusable. Generally speaking, the design pattern refers to 23 well-classified patterns in the book gof. The design model is more designed and used. It can be divided into three types: Construction, structural, and behavioral, including bridging, factory, and combination. The descriptions and tool support for these modes are mature. Now we have some CASE tools that support design patterns, such as togetherj and rational xde. The xde mode provides the best support. This article will discuss pattern development in xde in later articles.

3. Habit usage (idiom): It is a usage mode for a specific language. The main problem involved is how to use a specific method to solve the problems encountered during programming and how to better compile program code. Generally, a language, such as Java and C ++, has corresponding idiom. This mode has a low abstraction level and involves specific languages. We will not discuss it too much here.

　　1.2 UML pattern mechanism-collaboration and parametric collaboration

In the early UML, the mode was not supported. With the increasing popularity of models, OMG has finally introduced new concepts in the new version of UML to provide support for Model Modeling (mainly design patterns.

People who are a little familiar with UML will have a good understanding of collaboration digrams. A collaboration diagram is one of the nine Views of UML and is mainly used to provide a dynamic description of the model.

The concept of collaboration is not the same as that of cooperative plotting. In an object-oriented model, a specific behavior is implemented by message transmission between a group of objects and objects. This model information is represented by collaboration. Collaboration describes the interaction between a group of objects in a certain context and those objects used to implement specific behaviors. It contains two aspects: structure and behavior. The structure is similar to the static view, and contains the relationship between a set of objects (more specifically, roles. Behavior is a set of messages. These messages are transmitted and exchanged between objects with a certain role, that is, interaction ). The static aspects of collaboration can be represented by class diagrams. The collaboration diagram actually provides some static model information, while the dynamic description usually uses the sequence diagram (sequence digoal) or a collaboration diagram.

From this perspective, the mode is a kind of collaboration. For the design pattern, it essentially describes the object structure and interaction between objects-and applies such a collaboration to solve a problem. In UML, the pattern uses a special collaboration, represented by parameterized collaboration.

In a parameterized collaboration, a collaborative participant (such as a class or other elements such as a link) can be a generalized collaboration parameter. Each time you apply this collaboration to a specific model, use specific model elements to replace these parameters. In this way, the relationship between parameters in this collaboration is fixed in this model. Although the design pattern contains more meanings than collaboration. However, such a parametric Collaborative Modeling method can already describe most of the semantic information of the model. The mode can also include other descriptions such as the background, user guide, and consequences of use, which can be written as comments in a separate text file.

When using UML to model a pattern, follow these steps:

1. provide a common solution to a recurring problem and refine it into a mechanism. Because the solution is usually only conceptual and can be called as a pattern only when specific implementations are required. The general meaning is more important. repeated problems usually have different backgrounds. In these different backgrounds, we need to find public problem domains, it is not easy.

2. in the abstract problem domain, the above mechanism is modeled as a collaboration, that is, a namespace that includes its static structure and dynamic interaction. This can be seen as an abstraction, patterns are the product of this abstraction.

3. Find out the part that must be bound to a specific application in the pattern and model it as a collaboration parameter. Parameters provide the possibility of scaling the mode and implementing it. Because of the complexity and difference of the problem background, we need specific parameters to customize the mode.

In fact, capturing and implementing patterns is a very complicated process, which is beyond the scope of this article. The steps provided here are not necessarily applicable to all situations. Here we are concerned about how to use UML to express the content of a pattern. Here is an example.

　1.3 example

Next we will test a simple design mode: Command mode to see how to express it in UML. And how to apply it to a specific model. The specific semantics of the command mode is not detailed here. If you are not familiar with it, you can refer to gof's design mode.

The command mode has the following structure:

Figure 1: structure chart of the command mode
We regard each part as a collaboration parameter and obtain a parameterized collaboration as follows:

Figure 2: parameterized collaboration corresponding to the command mode

Alternatively, we can use an extra Sequence Chart to represent the dynamic behavior of this pattern:

Figure 3: Command mode dynamic behavior sequence diagram

Let's take a look at the application of the mode. In a specific model, for example, the EJB model, we assume that the command mode is required to complete the EJB call layer of a command (about the command mode in EJB, for details, see the book "EJB mode language", which simplifies the process .) According to the syntax of the command mode, you can bind template parameters as follows:

Template parameters	Bound object
Invoker	Containerr
Command	Command (automatically generated)
Concretecommand	Concretecommand (automatically generated)
Receiver Bean	Context
State	State (automatically generated)
Client	Remote

Table 1: binding the command mode to the EJB Model
In UML, the binding of a mode is a dependency with the constructor <bind>, and the parameter-based collaboration represented by the mode is directed to the binding collaboration. You can provide the binding result on the dependency. As shown in:

Figure 4: binding mode

You can use UML to express the binding result: In order to generate cooperation, the binding mode is represented by a dotted-line elliptic, which contains the pattern name; draw a dotted line between the ellipse and each class involved in collaboration, and name the parameter on the dotted line.

Figure 5 bind Mode 2

After binding, the syntax of the command mode introduced in the model gets the following result:

Figure 6: binding result

　　1.4 Follow-up topics on Collaboration

Collaboration illustrates how many participants interact with each other. These participants are not limited to classes or interfaces. It can be a class meta or chain. In fact, participants in collaboration are not classes or interfaces, but a new modeling element called a collaboration role. A collaborative role represents a slot in an object structure, indicating the behavior of elements in a specific context. It does not represent the actual object or chain, but the position where the object or chain is replaced when the collaboration is instantiated. In this sense, a collaboration role is equivalent to a parameter in a function.

A class element also has specific types, such as classes, interfaces, or subsystems. Just as the parameter value provided to a function call must meet the parameter type, the type of the class element needs to be satisfied in the application mode. For example, you cannot bind a class meta-Role of an interface type to a class. From a traditional class or interface to a cooperative role in collaboration, it is a change in modeling ideology. The role word also reflects this concept. It can be used as an analogy with a role in a movie. Anyone who holds the role's requirements (such as gender, age, acting skills, etc.) can play the role. A role is not a specific object, but an object. At this point, it is similar to the interface concept in Java, but more abstract.

Collaboration roles include class meta-roles and associated roles. In xde, the role concept has been expanded, not just being labeled as a class element or association, it can represent any valid UML model element. Such as attributes, methods, and even views. In this way, the expression capability of the model is greatly enhanced, and the model can have richer semantics.

In the subsequent series, we will use the latest xde tool of rational to model and use models. Xde is the latest integrated ide integrating modeling and coding. It represents the future development direction of IDE to a large extent. It provides a powerful mode mechanism, it can transform the modeling capability of the model in UML into an effective tool to improve software productivity. Let's see you again in the next series.