Usage Modeling: Introduction to usage Modeling

In Aspect-Oriented Modeling, model-driven development (MDD) is used to simplify aspect-oriented development. This method of Aspect-Oriented Modeling involves using Aspect-Oriented keywords to comment out UML aspect-oriented model units for access to cross-sectional relationships. The Aspect-Oriented code of the special target environment is generated from UML to target transformation. The following sections of the article introduce the object-oriented design for the MDD architecture to use IBM Rational Software Architect (hereinafter referred to as software architect) the aspectj and Java development teams provide a new method for software development. This architecture allows users to easily encapsulate their own aspectj-based mechanisms for multiple cross-cutting relationships in their applications. These cross-cutting relationships can be introduced to an application during design and modeling.

Introduction

Aspect-oriented technology is an important supplement to object-oriented programming, which is used to access cross-cutting links but does not destroy objects. Currently, more and more application-oriented tools are supported, the most representative example is the aspectj development tools (ajdt) Eclipse project, which provides tools that support aspectj. Therefore, the benefits of aspect orientation are also deeply understood. However, to be able to use this technology, developers still need to learn a new programming syntax and method.

The model-driven development (MDD) method is used for aspect-oriented modeling to solve this problem. Modelers/developers can apply Aspect-Oriented Technologies to UML models (typical class diagrams) and generate corresponding aspectj while converting UML to Java. The Modeler/developer does not need to understand any aspect-oriented technology, but only needs to develop which aspect should be applied to this model.

Model-driven development

UML provides designers and developers with a way to visualize the interaction process between the object-oriented system and them. Modeling tools such as IBM Rational Rose and software architect provide a wide range of modeling environments.

Simply put, model-driven development is to use abstract models for software development. Application software and system models are created at different abstraction levels and automatically or manually drive model evolution at the lower Abstraction Level (figure 1 ). This software development model is considered as a first-class component of the development process. They are like the source code in software development activities.

Figure 1. Typical Models in application software development projects

This model provides a mechanism to focus on the relationship between specific parts of the application software without relying on other relationships. For example, a data model is always related to persistent data (object state) and its structure. It has nothing to do with the dynamic behavior of the user interface, or even the transaction logic behavior. Select different types of models for the development process to match specific tasks and actions. Therefore, all work is generally focused only on the areas where tasks are assigned. This not only enables developers to become experts, but also defines a method for separating artifacts and developing processes.

For example, a reserved use case for a transaction application can provide a text description (readable) about this use case ). This description can be understood by members of the team who are not experts in this field. Analysts can describe the system using objects that present application behavior. In the model, use program tables and class tables that contain detailed specifications and controller classes that retain entities (for Object Management) to record them as documents. The design model driven by the analysis model can use multiple interface entities of EJB to implement classes, deployment descriptors, and specific artifacts necessary for implementation design to implement entities.

At the abstraction level of the design model, the differences between the source code are very small, so that the ready-made code generator (conversion) can convert the model to the source code and configuration file, as shown in figure 2. It can even generate (when a specific design pattern has been applied) behavior (method entity) in some scenarios ).

Figure 2. Convert the model to code

Aspect-oriented technology

Cross-cutting relationships are shared and displayed across different levels or subsystems. For example, common links include:

• Logs
• Security
• Durability
• Cache
• Error Handling
• Consistency check

Traditional methods to access the cross-sectional relationship include inserting an API or framework and introducing it through IDE and other types of automatic operations during development. This may lead to codes that are hard to maintain and lead to developers' attention shifting from the core transaction functionality of the object to the integration of the link.

Aspects provides a non-invasive solution for accessing the cross-sectional relationship. After the object is developedSpecific relationshipBehavior is introduced to the system. After the objects are compiled, their functions have been combined and organized into the Running code. Only the Object Transaction code that is not used by the link is left.

You can use multiple methods to orchestrate object behavior. For example, Figure 3 shows the UML behavior of some object methods. We focus on the Code and behavior of objects rather than any cross-cutting relationships. These relationships are executed on other objects or in the main control process.

Figure 3. control flow of a typical object Method

Before the object method is accessed (figure 4) or later (figure 5), the aspect functions can be embedded into all processes. Can also be placed in the object MethodSurroundingYou can choose to bypass or activate the target method (figure 6 ).

Figure 4. behavior that is activated before a method

Figure 5. Activation behavior after a method

Figure 6. behavior around a method

Introducing the system architecture mechanism without being exposed to the transaction logic code in the IDE, It is very effective to use the Aspect-Oriented technology. You can apply one aspect to a specific information package, class, or method. There are two things to use in an application:

• Aspects of Development
• Criteria for defining the crosstab point, position, and call code

Leave the development of such functions to the best professionals who are the project designers and technical leaders. These developers have rich experience and technology in Aspect-Oriented technology. Here, we still need to complete a task to link Aspect-Oriented Technologies with specific points in the application.ThisThe task should be completed by the remaining programmers. The biggest difficulty here is the need for some Aspect-Oriented Knowledge and some aspectj syntax. In the MDD project, we need to use Aspect-Oriented Technologies.

The Aspect-Oriented technology used for the MDD framework makes it easy for designers to encapsulate an aspect-based architecture mechanism, therefore, common developers-some of whom have little or no aspect-oriented technical skills-can also use the Aspect-Oriented technology during application development.

Aspect-oriented technology and model-driven development

MDD is used for software development.MethodologyThe aspect is to deliver functionality for software applicationsMethod. The two complement each other. However, in the past, they never thought of them together. The disguised technology used for the MDD framework combines the two to solve how to make it easier for large development teams to take advantage of the Aspect-Oriented advantages in the use of mdd. The key issue here is that developers who want to use aspect-oriented applications need to understand how to write Aspect-Oriented code that combines the aspect with the ongoing system part.

The architect uses UML to implement system modeling. Typical modeling is performed at the analysis and design level. At the design level, the software designer has a clear attitude towards coding the desired artifacts, where the architect regards the access cross-cutting relationship as a means of non-functional access.

However, in order to record the use of the cross-cutting relationships in the object model, designers often need to create lengthy documents to illustrate the architectural considerations. Then, developers need to understand the considerations of these architectures, or use Aspect-Oriented Technologies-assuming they have fully mastered these technologies-or they are more likely to use a more traditional method, such as the APIs and frameworks that have just been mentioned.

The integration of Aspect-Oriented Technologies and MDD solves these two problems. This article introduces this mechanism, which can be introduced into development work-using standard text modeling symbols-without understanding how they are created or the minimum technical requirements required for this technology.

The most important thing is that developers (not clear about the Aspect-Oriented technology details) can also mark the aspect-oriented model units that have been developed before. Any aspect required when these model units are implemented (or converted to code)Bonding codeIt is automatically created and combined with pre-determined aspects. Figure 7 shows the annotation process for several operations in a class. This class is an implementation of an operation, and only specific operations can be created. In this example, the getcatalog () Operation Model element is annotated with <log>, while the getcatalogs () Operation Model element is annotated with <cache>.

Figure 7. comment out the model using the aspect keyword

Figure 8. Generate aspectj code

The basic steps include writing aspect-based code by a designer or an expert in aspect-oriented development, which is referenced in different places of the application. For example, a designer can create a reusable cache that can be used in applications when performance requires something like a simple cache. It is almost impossible to know where this mechanism will be used before any major design occurs. However, based on past experience, you may guess where the mechanism will be used.

Software designers can develop such a mechanism based on Aspect-Oriented Technologies, and the application of Aspect-Oriented Technologies to the MDD framework package is also an asset that can be reused. These orientation aspects have almost been completed, but several definitions of them (indicating the units defined in the target application) are very abstract. This is important because -- before the target application is generated -- these aspect-based architecture mechanisms have been established and tested -- just waiting for final cross-cutting, let the specific aspects used in the target application. This cross-section definition is only known after the application starts to define it.

These abstract orientations are encapsulated and can be installed and used on the developer's workstation. Where they can be applied to specific, discrete locations of the applications under development. Developers do not need to understand Aspect-Oriented Technologies and select model units (packages, classes, or operations) this aspect-oriented technology is also applied by marking these elements with the installed Aspect-Oriented UML. In the subsequent code generation and conversion process, we will introduce the pre-development aspects in the project-or include their libraries, in addition, the abstract aspect will be slightly extended and arranged in the target application.

The biggest advantage of using an aspect-oriented approach is that you can implement any number of architecture mechanisms and access different relationships in the target application. You can start with any specific application.BeforeFor development. They can be developed and stored in the resource library and can be downloaded and used in future development projects. Other advantages are that non-aspect-oriented developers can use the Aspect-Oriented technology in the general MDD processing process under the correct guidance. No additional technology is required-you do not need to know the target and use special aspects.

Which have been completed

This article introduces the Aspect-Oriented technology that can be used for the MDD architecture for software impact ect. This is a simple architecture for packaging and Developing Architecture mechanisms and code based on aspectj. This architecture can be used for applications under development without having to master any important technologies related to it when the development team applies Aspect-Oriented to real projects. It can develop and establish a resource library on the external mechanism, and selectively install and apply it to specific parts of the application in the development process. It allows software designers and field-oriented experts to share their experiences and technologies with large teams, allowing the development team to focus all its energy on designing and implementing application transactions and the functionality of the domain.

References

Learning

• For more information, see the original article on the developerworks global site.
• For more information about the OMG standards of reusable asset specification and Version 2.2, read the instructions.
• Visit the SOA and Web Services area of the developerworks Chinese website to expand your knowledge.
• Visit IBM pattern solutions and learn what IBM has done in terms of model and resource reuse.
• It is consistent with the developerworks technical activities and webcast.
• IBM Rational Software Architect product page: You can find technical documents, guidance articles, education, downloads, and product information about Rational Software Architect.
• Read the developerworks article,Develop Aspect-Oriented Java applications with eclipse and ajdtIntroduces the development environment of aspectj.
• Read the developerworks tutorial,Developing and deploying aspects in a model-driven development environment: Part 1: how to package an aspect for MDDTo create a library based on aspectj.
• Read the developerworks tutorial,Developing and deploying aspects in a model-driven development environment: Part 2: how to package and customize an aspect for MDDDescribes in detail how to encapsulate, develop, and use the aspectj library in Rational Software Architect.

Obtain products and technologies

• Download Aspect-Oriented Technologies for the MDD plug-in program of Rational Software Architect. This plug-in can be obtained from the RAS library and is in the scope of "design. You can directly access the RAS library from the Rational Software Architect tool. For more information, visit the pattern solutions page and browse the content under "installing Ras asset.
• IBM alphawork provides the implementation of Ras, called reusable asset specification repository for workgroups, which can be downloaded directly from alphaWorks.
• Download the free trial version of Rational Software Architect v6.0.
• Use IBM trial software to create your next application, which can be downloaded directly from developerworks.

Discussion

• EIS website IBM enterprise integration solutions Strategic Service Oriented Architecture, dedicated to demand solutions.
• Join developerworks blogs and join the community on developerworks.
• Rational Software impact ect, data impact ect, software modeler, application developer and Web Developer Forum: view issues related to Rational Software impact CT in the Forum.

 

Source: http://www.uml.org.cn/oobject/201002021.asp