Summary:
Software models, especially design patterns are increasingly important in today's software development. In many standards, tools, and development methods, the concept is introduced. This article describes how to model software modes in UML and combine specific tool Rational XDE, which is detailed, how to apply, how to apply patterns, and point out some related issues.
Part 1: Model UML
1.1 software mode
Software Pattern's concept has been long, and when the software industry draws a model concept from other engineering industries such as construction industry, it is undoubtedly a revolution in the field of software engineering. Result. The classification and description of GOF to design patterns, which makes the concept into micro, and can be mature applications in software development.
The so-called pattern, simple, is a successful solution for a particular, repeated problem. In terms of the problem itself, any field and category can be made. In the fields such as architecture, music, writing, management, etc. existence. In the field of software, the mode is manifested in a conventional document to facilitate record, learning and communication. Experienced programmers can pass their knowledge, pass the pattern, and pass to others. Thus, the pattern can be seen as an avatar, documentation experience and knowledge.
In the past ten years, the software model has a great development, but it is not just an expression of experience, but it is now able to act as a driving force developed. The pattern-driven software development process is not a new thing. However, in today's software development field, a development idea, or process, if there is no strong tool support, it is very rare to extensive applications.
Software mode, on its abstract level, can be divided into three types of architecture, design patterns, and IDiom.
1. Architecture mode: Provide solutions to problems encountered in architecture design. Examples of architecture include: PIPE-FILTER mode, whiteboard mode, MVC mode, ORB mode, etc. The architecture mode is not necessarily object-oriented, and its idea can be used for any development method. Thus, there will be some difficulties when using UML, and some specific proprietary description methods are usually used, such as C2 (Component-Connector). There are fewer comparisons for its tools, and most of them are still in the research phase.
2, design mode: Provide a solution to the specific design of the face-to-objective design, making the designs more scalability and reuse. The usual design pattern refers to the good 23 modes categorized in the GOF book. The design mode is more designed and is divided into three categories, structural, structural, and behavioral types, including bridge mode, factory mode, combination mode, and more. The description of these modes and tool support has been mature. Some Case tools that support design patterns have now appeared, such as TOGETHERJ, RATIONAL XDE, etc. Among them, the support of XDE is the best. This article will discuss the development of XDE in the following article.
3, habitual usage (IDiom): is a mode of use for specific languages. The main problem is that how to use a specific method to resolve the problems encountered during the program code, how to write program code. Usually a language, such as Java, C , etc., there will be corresponding IDioms. The abstraction of this mode is relatively low and involves specific languages, which will not be discussed here. 1.2 UML mode mechanism - collaboration, parameterization collaboration
In the early UML, there is no support for patterns. With the increasing popularity of the model, OMG finally introduces new concepts into new concepts to provide support for pattern modeling (mainly design patterns).
Slightly familiar with UML, you will know very well about Collaboration Diagram, and the collaboration diagram is one of the 9 big views of UML, mainly used to provide dynamic description of the model.
The concept of collaboration is actually not the same as a collaborative map. In an object-oriented model, a particular behavior is implemented by messaging between a set of objects and objects. This model information is represented by collaboration. Collaboration sizes a set of objects in a certain context and the interactions between these objects to achieve specific behavior. It contains two aspects of structure and behavior, similar to the static view, including a collection of objects (more exactly the role) and the relationship between them. Behavioral aspect is a collection of messages, which are exchanged between the objects with a role, which is the so-called interaction. The static aspect of collaboration can be represented by a class diagram, and some static model information actually gives some static model information, and the description of dynamic aspects typically use the sequence diagram or collaborative diagram.
From this perspective, mode is a collaboration. For design patterns, it is substantially described is the structure of the object and the interaction between objects - and uses such collaboration to solve a problem. In UML, mode uses a special collaboration, parameterized collaboration is represented.
In a parameterized collaboration, collaborative participants (such as class, other elements such as relationships) can be a generalized collaboration parameter. These parameters are replaced whenever this collaboration goes into a specific model. In this way, the relationship between parameters in this collaboration is fixed in this model. Although it is designed to design mode, it contains more meaning than collaboration. However, such a way of modeling of parameterized collaboration has been able to describe the semantic information of most of the mode. The mode can also include other descriptions such as background, use guidance, and use consequences, which can be written as a note in a separate text file.
When using UML to model the mode, you can follow the steps:
1. A universal solution is given to a repeated problem and refine it into a mechanism. Because the plan is often only the concept level, there must be a specific implementation to refer to it. And the general meaning is more important, repeated problems, usually have different problems, to find public problems in these different contexts, is not an easy task.
2. In the abstract problem domain, the above mechanism is modeled as a collaboration, that is, a namespace containing its static structure and dynamic interaction, which can be seen as an abstraction, mode is this Abstract product.
3. Find the part of the specific application must be bound to the specific application, modeling it into collaboration parameters. The parameter provides the possibility of expansion and implementation. It is because the complexity of the problem background is required to customize the specific parameters to customize the mode. In fact, the capture and implementation of the pattern is a very complex process, which has exceeded the scope of this article to discuss, and the steps given here are not necessarily applicable to all situations. What is concerned here is how to express a pattern with UML, let's take an example.
1.3 An example below We will test a simple design pattern: command (Command) mode, see how to expose it with UML. And how to apply to a specific model. This is no longer detailed in the specific semantics of the command mode. If you are less familiar, you can refer to the "Design Mode" book for GOF. The command mode has the following structure: Figure 1: Structure class diagram of command mode We look as a collaborative parameter to get the following parameterization collaboration: Figure 2: Command mode corresponds to the parameterization collaboration or We can also use an extra sequential diagram to represent this mode dynamic behavior: Figure 3: Dynamic behavior sequence of command patterns Let's take a look at the application of the model, in a specific model, such as EJB model If the design needs to use command mode to complete a Command's EJB call layer (regarding command mode in EJB, see "EJB Mode Language" book, which is a simplification of simplicity.) According to command mode Semantics, you can bind the template parameters:
Template Parameter Binding Object InvokerContainerRcommandCommand (Automatically Generated) ConcreteCommandConcreteCommand (Automatically Generated) Receiver BeanContextStateState CLIENTREMOTE Table 1: Command Mode to EJB Model Bindings
In UML, the binding of the mode is represented as the dependency of the configuration of << bind>, collaborates from the parameters represented by the binding collaboration pointing mode. The result of the binding can be given on the dependency. As shown below:
Figure 4: One of the bindings of the pattern
You can use UML to indicate specific binding results: in order to generate collaboration, the binding mode is indicated by dashed line ellipse, and the name of the pattern is included in the ellipse; draw a dashed line between the ellipse to each of the collaborations, and in the dotted line The name of the parameter is indicated.
Figure 5: Two two bindings
After the binding, the semantics of the command pattern introduced in the model are obtained:
Figure 6: Binding result
