1. Introduction
This chapter presents important, proven process artifacts that allow and support the successful use of model-driven component development in projects.
Most processes and practices can be transferred very easily to the general -- that is, non-architecture-centric -- MDSD. Techniques that only make sense in the architecture-centric case, or require specific interpretation, are also explicitly marked.
It is recommended to nest these best practices in an iterative, flexible development process. MDSD does not conflict with the latter, and is actually a good fit to enhance its benefits. In theory, MDSD can even be combined with the waterfall development process. However, the well-known risks of waterfall methods still exist, which is why we - completely unrelated to MDSD - do not recommend their use.
2. Separation of application and domain architecture development
1. Basic principles
Domain-dependent analysis and domain architecture as a basis for formal models
One of the most important ideas in support of MDSD is that the formal modeling step implies two prerequisites that are not interrelated but can be developed largely in parallel:
- The iterative or regular functional/specialized needs of a specific application must be known;
- A formal language (DSL) for modeling must be defined. Furthermore, for automatic further processing, the language must be bound to the concrete MDSD platform in the form of transformation rules. This is what the term "domain architecture" outlines.
As its name implies, a domain architecture is structured and supports domains. In principle, this domain is independent of individual applications, or in other words, it covers families of software systems.
The activity diagram shown above should not be misunderstood as a waterfall process. It primarily shows a fundamental principle upon which each iteration is based.
Formal modeling is used to connect application-specific concepts to those provided by the domain architecture -- more precisely, to express functionality using a language (DSL) provided by the domain architecture. Transform formal models with generator support and map them to platforms.
2. Domain Architecture Development Thread
To help create the domain architecture, some artifacts and activities are required. The goals of the MDSD architecture development thread are reusable rows as well as quality and efficiency enhancements. From a process point of view, it is a central aspect of MDSD. Therefore, the following diagram first zooms in to show the domain architecture creation activity.
Domain Architecture Creation
The partitions shown in the diagram divide activities into 3 categories: Domain, Transformation, and Platform. In each category, artifacts of the domain architecture (shown in dark green) are produced. Only the ordinary case situation with the most important relevance is shown here because - in our experience - including everything else would make the essential problem impossible to clear from the display. In particular, no iteration loops are shown.
1) Prototyping
When the project is developed, the expected platform usually already exists, such as J2EE or a specific framework. One goal of the MDSD architecture development thread is to merge these artifacts with a semantically rich and domain-specific MDSD platform. Therefore, it always makes sense to first collect relevant experience with the prototype as a proof of concept. In addition, this prototype can also be considered as the first step towards the MDSD platform.
2) Development platform
Platforms form the basis for both generated and non-generated code and are used to keep the transition simple. The generated part of the domain architecture has dependencies on the runtime system components used, but the reverse is not true.
The development of the platform should also proceed iteratively. Applying adult dog techniques in this setting can benefit from it.
Additionally, the boundary between platform and generated code can change in either direction during the evolution of the domain architecture.
3) Create a reference implementation
The reference implementation is only an intermediate result of the MDSD architecture development thread, but it is very important when starting to create the domain architecture.
A reference implementation should not be mistaken for a simple, isolated example from which advice on implementation can be derived if necessary. A reference implementation can be created via prototyping, but that reference implementation will serve a more important goal: in conjunction with the reference model/design, it will mask the application and implementation of the DSL for the term domain. This bipartite reference to the atmosphere exemplifies the migration from model to implementation on each platform. For a new family of software systems, reference implementations are first created manually. Afterwards, derive the transformation from that reference implementation. The generative implementation of the referenced model, perhaps coupled with hand-programmed domain logic, must produce a complete, executable referenced implementation.
The full added value of a reference implementation is only gained through the interaction between the reference implementation and the reference model. The specific functional content of the referenced implementation is essentially irrelevant --- just a matter of domain.
4) Domain Analysis/Design
This activity primarily serves to find the domain's metamodel and appropriate, concrete DSL. Only best practices for constructing DSLs are listed here.
Architecture-centric DSLs are also known as Design Languages. For this design language, UML is often used as its basis. However, there are areas where UML is not usable at all, such as the modeling of GUO layouts, so that another notation may have to be used. Ultimately, concrete syntax always assumes the presence of oranges that are less important than abstract syntax.
According to the DSL concept, the architect must also draw the dividing line between the generated code and the domain logic--and thus gain the developer's degree of freedom.
The definition of an appropriate modeling language is undoubtedly the most important challenge in MDSD.
5) Create a referenced model/design
A referenced model is an instance of a DSL because it expresses domain instances through the methods of the DSL.
The interplay of the reference implementation is very important: the reference model and the reference implementation together instantiate the syntax and semantics of the DSL, and thus concretely describe the concepts of the domain architecture.
6) Archive programming model
The definition of a programming model is only relevant if the domain architecture contains "semantic gaps" representing code frameworks that emerge through model transformations that application developers must supplement in the programming language to allow the creation of runnable s application.
In the context of MDSD, the programming model describes the application developer's view of the domain architecture.
The programming model is very easy to document in the form of tables. The table contains - in addition to the DSL's respective constructs - references to appropriate excerpts of referenced models and referenced implementations.
It turns out that a guide in the form of a walkthrough, which explains to developers how to use the DSL to develop a specific application, is the most appropriate approach. Such guidance should cover DSLs and other aspects of the programming model, including code that needs to be written by hand, or how to operate/integrate generator tools.
7) Derived conversion
This activity formalizes the mapping of DSLs to platform and programming models to the extent that automatic translation can convert a given application model to an implementation or program model.
If the application's domain logic cannot be fully expressed through a DSL, techniques for integrating generated and non-generated code are required.
8) Create a DSL editor
Not all DSLs are UML profiles, as standard tools can be applied, with varying degrees of validity. In very specialized domains, it is very practical and desirable to create specific tools for defining DSL-compliant domain models, thereby further increasing the effectiveness of ergonomics and MDSD approaches. This can be a question of cost-value ratios, which can only be answered for each individual situation.
3. Application development thread
Activity of the application development thread
The very simple, ordinary case without iterative loops is shown here. A cycle can get anywhere from a few days to a few minutes, depending on the intensity of a step.
1) Formal modeling/design
The analysis and architecture threads are involved in this step: functional requirements are now expressed in the domain architecture language (DSL). The reference model acts as a directional guide in this environment. This step requires information feedback and human judgment and therefore cannot be automated.
2) generate
This step can be performed completely mechanized. Compared with the formal model, no information gain will be generated: through the transformation of the domain architecture, it is automatically converted into a form suitable for the MDSD platform.
3) Manual implementation
Domain logic that cannot be expressed in a DSL must be added manually after generation occurs. In our case study, these are entirely within the protected areas of the implementer framework.
Interaction of domain architectures can even occur during implementation. The organization of the project must allow for the necessary feedback loops.
4) Organizational Aspects
Ideally, the separation between application development and domain architecture development is supported not only by a suitable development structure, but also by changing the organizational structure of the team, project, or company.
3. Dual-track iterative development
Now discuss the separation of roles and artifacts between application and domain architecture development. This section describes the synchronization of two threads. There is clearly a correlation from application development to domain architecture development - in the same way as all frameworks used. From a requirements management point of view, this means that the application development team assumes the customer's role in the development of the domain architecture.
Dual-track iterative development
Note that the incremental, iterative process based on synchronized timeboxes does not preclude domain analysis before entering the iterative loop. Instead, a good understanding of the fundamental concepts of the domain is actually required. As long as application development is ongoing, further domain analysis occurs iteratively -- as part of the architectural analysis, which is now delegated to its own project.
4. Target architecture development process
Best practices for the domain architecture development process are only one aspect, other important aspects to consider are as follows:
- How to come up with a reasonable target architecture?
- How to make it "MDSD ready"?
- How to implement it in important projects?
1.3 stages
The development of software architecture, especially the development of usability in MDSD environment, should be divided into three stages. A core kind of artifact is created in each phase - these are briefly described below:
- A detailed description
- iterate.
- automation.
2. Phase 1: Detailed description
Best practices for this phase relate to activities such as prototyping the domain architecture development thread, documenting the programming model, and platform development.
1) Technology-agnostic architecture
2) Programming model
Once a technology-independent architecture is defined and rolled out, developers must implement functionality according to that architecture.
3) Technology Mapping
Software must provide some level of quality of service. It is very high code to implement QOS as part of the project. There may not even be proper technology on the team.
4) Mimic the platform
Based on the programming model, developers now know how to build applications. Beyond that, developers need to be able to run the system locally, at least to run unit tests.
5) Vertical Prototype
Many of the lung function requirements that the architecture needs to achieve depend on the technology platform, which has only recently been selected in the technology map. The mapping mechanism may not even be valid.
3. Phase 2: Iteration
Now with the basic mechanisms in place, it should be ensured that they actually work for the project. Therefore, repeat the steps given above until they remain reasonably stable and usable.
Then, if there are larger project teams, roll out the architecture to the entire team. If you need to start the model-driven development process, proceed to Phase 3.
4. Phase 3: Automation
Best practices at this stage relate to activities such as: domain architecture and thread derived reference implementation/model, derived transformation, and domain analysis/design.
Has a technology-agnostic architecture. There is a need to automate various tasks of the software development process. To enable automation, rules for technology mapping need to be encoded and a DSL-based programming model defined.
Thus, a formal architectural metamodel is defined. The architectural metamodel formally defines the concept of a technology-independent architecture. Ideally, this metamodel could also be used in a transformer/generator with which to automate development.
Formalization is a double-edged sword.
1) Paste code generation
On the implementation side, technology mappings - if sufficiently stable - are generally repetitive and thus tedious and error-prone. Likewise, information already defined in the programming model's artifacts often needs to be flushed in the technology mapping code. Repeated, standardized technology mapping is excellent because it reflects a well thought out architecture. Duplicate implementations tend to lead to errors and failures.
2) DSL-based programming model
The programming model has been defined. However, the programming model is still too complex with many re-implemented domain-specific algorithms. It is difficult for domain experts to use the programming model in their daily work.
3) Model-Based Architecture Validation
Now has all the appropriate artifacts and has rolled out the architecture to a number of developers. You need to make sure you use the programming model as planned. Different people may have different qualifications. Proper use of the programming model is also critical for the architecture to meet its QOS promises.
5. Product Line Engineering
Product Line Engineering (PLE) will deal with the systems analysis of the domain, and the design of the software product line. Its goal is to adequately balance the potential for automation and reuse during software system development. Product Line Engineering is thus seamlessly integrated in the MDSD environment as an analysis method.
In other words, it provides a solid background for all activity in the domain part of the domain architecture development thread.
1. Software system family and product line
The initial definition of a software system family is as follows:
Assemblies are considered to form a family when the common properties of assemblies are studied first, and then the special properties of individual family members are determined.
A product line, on the other hand, consists of a group of functionally related products that share a common target market; its organization is specific to the customer group. Ideally, the product line is realized with the help of a family of software systems.
2. Integration with MDSD process
MDSD can be considered as an implementation technique for product line engineering. Similarly, the product line can be viewed as an analytical method for MDSD. Product line practices can and should be used iteratively and incrementally: PLE should not be seen as a separate prior phase of MDSD, but rather as an incidental approach, even if it is indeed an excellent approach for the early stages of an MDSD project.
3. Methodology
The process of product line engineering consists of three phases.
Phases of Product Line Engineering
1) Domain analysis
The first step in domain analysis is domain scoping. Here the boundaries of the domain are determined.
2) Domain design and implementation
The definition of software structure is an aspect of domain design. First implement the common features of domain products in the form of a platform. Because these common features are the same for all products, there is no need to implement them repeatedly in any way: they form the basis of a common target architecture.
4. Domain Modeling
A domain consists of domain-specific abstractions, concepts, and rules. How to ensure that the defined DSL and thus the modeled applications form the correct subset of the domain?
The metamodel of a DSL must be constrained and must be as close as possible to the domain. Feature models can help in this regard. If appropriate, the metamodel must omit unnecessary or unnecessary properties of the base metamodel -- for example, UML properties. Constraints provide a powerful mechanism in this environment.
A glossary or ontology of the domain can be a useful first step towards implementing a suitable metamodel, which can then be transformed during iterative development.