1. Software architecture in the context of MDSD

The term "software architecture" is very important, but unfortunately its definition is vague.

NOTE: Software architecture describes, at some level of detail, the structure (layering, modularity, etc.) and classification (patterns, conventions, etc.) of a software system.

The topic of software architecture plays a role in various subcontexts of MDSD:

First, a software architecture is used to organize software systems to be generated or created.
An MDSD domain architecture is also a software architecture. It defines the entire metamodel, DSL, platforms and transformations. A domain architecture provides the basis for the products of a family of software systems.
In the context of MDSD, software architecture is related to the platform, where it describes the most important platform components, their interactions, and their non-functional characteristics, which is what is called platform architecture in this context reason.
Software architecture also plays a role in the transformation of MDSD, as it does define the software leg structure of the generated code - as explained earlier.
Finally, a general MDSD tool must conform to a certain architectural standard, which we call the tool architecture.

2. What is a reasonable architecture

The application to be created must have a reasonable architecture. From our point of view, a reasonable architecture should have the following characteristics:

First, the architecture must adequately support the functional requirements of the application for which it was formally created.
Additionally, it must implement the intended non-functional requirements.
An architecture should consist of a set of well-defined components that are as small as possible, so that the architecture becomes simpler, easier to understand, and more practical.
The architecture should allow for an ad-hoc growth/development path for the application.
A sound architecture is also well documented, this includes a concise and concise documentation of all the points listed above, a programming model for how to implement an application based on the architecture and a detailed description of why it is done that way Rationale for creating the architecture and why other possible approaches that were chosen fell short.

In the context of MDSD, there are two other aspects to consider:

First, the architecture must be able to support all products of the software system family.
Architecture concepts must be more clearly defined, otherwise they cannot be automatically generated from the model through transformations.

3. How to obtain a reasonable architecture

In software technology, the architectural blueprints known to work well are very limited. They have been described in various forms, such as patterns or styles.

Using a tried and tested pattern or style as the basis for one's own architecture has proven to be one way to get a good architecture. Here are some examples:

The Concurrent Networked Objects pattern describes decentralized multithreaded systems.
The resource management pattern addresses the architecturally important aspects of resource management.
The server component pattern describes the internal architecture of a component infrastructure, such as EJB, CCM or COM+;
The remoting schema describes the internal architecture of remoting middleware such as CORBA, remoting.net or web services.
Enterprise architecture patterns generally describe the architecture of large enterprise systems.
Enterprise Integration Patterns describe the architecture of EAI systems and messaging middleware.

4. Basic components of software architecture

1. Architecture

Architecture is anything that can be adapted or extended through systematic extension or configuration.

MDS D can assist to a certain extent, since it allows the required features to be specified through an appropriate DSL. Then you can continue to generate various architectures based on the model built by DSL, so architecture and DSL are an ideal pair: with the help of architecture, the MDSD platform can be well realized.

2. Middleware

Middleware can be thought of as an architecture. In most cases, it is specific to a technical domain, such as distributed systems, information, or transactions, and provides the technical basis for a target architecture. Because of its technical focus, middleware can be applied in many functional specialized areas and is often standardized. Well-known examples are CORBA, DCOM, MQSeries, and CICS.

3. Components

Component infrastructure is a particularly powerful and popular type of middleware.

Components thus form the basis of a neatly modular and assembleable system. Many domain architectures define components or assemble prefabricated components to construct applications.

5. Architecture reference model

In practice, a layered model has proven to be the most useful in software architecture. Some form of this structure is found in almost any well-structured software system.

An architectural reference model

Operating systems and programming languages form the basis of every architecture. On this basis, a technical architecture is usually used, which provides basic technical services and is often implemented with middleware.

It is typical to find an architecture based on this layer to provide the basis for functional/specialized domains.

Entities represent those concepts that have an identity and a lifecycle.
The value object represents the debriefing.
Business rules and constraints.
Serve. Basic services defined here cannot be assigned to an entity, such as performing a transaction, or validating the structure of a complex document in an authoring system.

6. Measuring MDSD platform

Within the scope of the reference model, there are already several basic options for reducing the conceptual gap between domains and platforms:

MDSD domains and platforms are located at the technology platform layer of the reference model.
MDSD domains and platforms are at the conceptual level of the target architecture.
The MDSD domain and Pingyao are located at the functional/specialized platform layer of the reference architecture.

1 example

It is recommended to gradually expand the functionality of one's MDSD platform during the course of the project, while maintaining a continuous improvement of the understanding of the domain, which will reduce the scope and complexity of code developers must write custom architecture, the custom architecture must be The resulting live part is handwritten.

The general rule is that general and generalizable code segments must be part of the MDSD platform. Existing architectures are usually tailor-made for integration in the MDSD platform.

2. Architecture integration

The use of complex architectures can be greatly simplified and accelerated by custom DSLs, which is often overlooked by pure architecture theorists. On the other hand, highly configurable generic architectures risk overloading their implementation, making them difficult to maintain and debug. It should be considered in the platform construction of MDSD. An iterative, incremental approach is key to successfully designing MDSD platforms, and developing powerful architectures in large, independent projects that do not directly replicate exercises with real-world application development projects will inevitably lead to times. Conversely, a small architecture combined with code generation provides a solid foundation for iterative development.

7. Consistency of Architecture

A good target architecture can only be advantageous if it is not ignored or surrounded by everyday affairs. When doing large-scale projects, traditional methods are not easy to measure, such as reviews and excessive documentation. MDSD does provide insights into the generated code, especially since the architecturally-oriented aspects of the model description are abandoned in the form of transformation rules.

Now developers can no longer get arbitrary references independently - they can only access those references for which there are accessor operations in the context of the component. These access operations are generated from the model. If the developer wishes to access other interfaces, these interfaces must be included in the model, otherwise unnecessary accessor methods are available in the code, which ensures that a component only has those dependencies explicitly declared in the model. Of course a more comprehensive infrastructure is required: for example, "someone" has to call the init() operation and provide the correct context object, and in a component-based system, that's the job of the container - in this case responsible for Runtime system for component lifecycle.

This approach has the lovely side effect that in modern IDEs, code completion makes it easy to tell which methods appear in the context of a component - so information about legal dependencies can be found directly in the code, making development It is more convenient for the reader to observe the rules of the architecture.

8. MDSD and CBD

Like Service-Oriented Architecture (SOA), Component-Based Development (CBD) is a popular symbol for building complex systems. In our experience in development projects, we find ourselves almost always starting by modeling the component structure of the system we are building. To do this, we start by defining what a component really is -- that is, by defining a metamodel for component-based development. In addition to the domain where the development project resides, these models are similar in other domains of the application -- insurance, e-commerce, wireless astronomy, and so on. Therefore, presenting some of these metamodels here will give the reader a head start when defining his own component architecture.

1.3 aspects

1) Type aspect

Type aspects describe a component's type, interface, and data structure. A component provides many interfaces and references many required interfaces. An interface holds many operations, each with a return type, multiple parameters, and exceptions.

In order to describe the data structure used by the component, starting from the abstract type, both the basic type and the complex type are used. A complex type has many properties with names and types. There are two types of complexity: Data transfer objects are used for the simple work of exchanging data between components. Entities have a unique ID and can be fixed. Entities can reference each other and form more complex data graphs. Each reference must specify whether it is bidirectionally operable or unidirectionally operable only. References also specify the cardinality of the entities at the respective terminals.

2) Combination

This aspect describes component instances and how they are connected. A configuration consists of many component instances, each of which knows its own type. An instance has many wires: a wire is an instance of a component's interface requirements.

Using the Type and Composition aspects, you can define component types and their mutual collaboration. A logical model of the application can be defined. For example, UML should be used to describe both models, generate skeleton classes, and then implement application logic in subclasses. From the perspective of composition, you can generate or configure a container that instantiates instances of components. Here you can run unit tests that verify your application logic.

3) System aspect

The infrastructure of the system is described, and the logical system defined by the previous two aspects is developed on the basis of it.

A system is composed of many nodes, each node has containers. A container can hold many component instances. Note that containers also define their own classes -- this could be something like CCM, J2EE, Eclipse or Spring. Based on this information, the necessary "glue" code can be generated to run components in that container.

Anything from remote communication scaffolding code and configuration to build and packaging scripts can be generated from the node information and connections defined in the composite model.

2. Dependencies between aspects

Dependencies between models are well-constructed. To define several compositions with the same components and interfaces, run the same composition on several infrastructures.

Dependencies between aspect models

3. Emphasis on surface models

The 3 viewpoints described above are a good starting point for modeling and building component-based systems. However, having a model is not enough in most cases. Other aspects of the system must be described with aspect-specific models arranged around these three core aspects.

The following aspects should typically be addressed in a stand-alone aspect model:

Persistence
Authorization and Authentication
Forms, Layouts, Page Flow
Quality of timing, scheduling and other services
Packaging and configuration
Diagnostics and Monitoring

The idea of the facet model is that the information is not superimposed on the three main ideas, but is described by a separate model with an appropriate concrete syntax. Also metamodel dependencies are important: an aspect can depend on a core aspect model, and possibly even another aspect, but a core aspect does not depend on any aspect model.

4. Variants

In every project, the metamodel described above cannot be used exactly in this way. In many cases it is necessary to extend the concept of what constitutes a component. There are therefore many variants of this metamodel. However, judging from experience, these variants are limited

interface may not be required
Often different kinds of components are required, such as domain components, data access components, process components, or business rule components.
Another way to manage dependencies is to label each component with a layer label, such as domain, service, GUI, or facade, and define constraints on how components in these layers interact with each other
The layer structure component is a powerful tool.
A component may have many configuration parameters
One might ask whether components are stateless or stateful, are they thread-safe and what is their lifecycle like.
Using simple synchronous communication is not always sufficient.
In addition to communicating through interfaces, events need to use a static or dynamic publisher/subscriber infrastructure.
Composite models statically connect instances of components.
Finally, it is necessary to provide other means of structuring complex systems.

5. Component implementation

Component implementation is usually done manually, which means that developers add handwritten code to the component skeleton by adding code directly to the generated classes, or better yet, by using other compositional methods such as inheritance or partial classes middle. The main reason is that action languages that support generic expressions for model-level applications are still not widely supported. However, using a common action language to describe the behavior of structured artifacts is only one option. There are other ways of describing application logic, a few of which are outlined below. The common support for all methods is that they use a notation that should be specified for that behavior, rather than providing a general way to model various behaviors in the model.

After establishing regular behavior in the model parameters by setting a small number of well-defined variable points, it can be implemented with generators.
For state-based behavior, a state machine can be used.
For behaviors such as business rules, it is possible to define a DSL that directly expresses these rules and evaluate them using a rules engine.
For domain-specific calculations, such as those prevalent in the insurance domain, provide a specific text representation for the domain that supports mathematical operations.

Since component implementation is about behavior, it is often technically useful to use an interpreter encapsulated within the component. This "interpreter component" is a component like any other.

Nine, SOA, BPM and MDSD

Service-oriented architecture (SOA) and business process management (Business Process Management, BPM) are two topics that are currently being hyped in the IT industry.

1、SOA

In fact, SOA is driven by at least one web service technology, including business process execution language (bpel). From our perspective, SOA is agnostic to a specific technology (WSDL, SOAP, Http), but it consists of some of the best practices in building large scale, scalable and composable system architectures. There are reasons to think of a well-structured component-based architecture with well-defined interfaces and clear component responsibilities as SOA. Components are used to build the basic building blocks for providing and consuming services, and the industry is aware of this and is currently defining a standard for Service Component Architecture (SCA).

Services should be minimally designed and encapsulate functionality that is relevant from a business point of view -- although no one can say what that actually means! Services are generally used by explicitly modeled business processes, but replenishment is not exclusive to it. In the end, like all good IT systems, they are secure, transactional and manageable.

Opinions vary as to whether these characteristics are really so different from current well-constructed business systems. However, in our view, it is clear that models play an important role in the definition and operation of service-oriented systems.

Therefore, the main idea in SOA is to first establish an interface contract. The first thing to specify when developing a system is how the communicating parties actually interact -- it's independent of the communication technology and independent of the implementation platform. More precisely, message formats, interaction patterns, and quality of service contracts are specified at an abstract level.

2、BPM

Like SOA, BPM has no universally accepted definition. But there is a statement among industry pundits that most agree with.

BPM deals with the control of business processes and design, the resulting tasks are the construction, automation and optimization of these artifacts.

Business processes connect us with available information technology and matter.
Process definition and implementation must be flexible so that they can be changed to suit the value creation chain of one's own business.
BPM follows the complete business process lifecycle, which consists of definition, creation, execution, health and optimization.
BPM is not a product and none of the following individual product categories can be said to fully cover BPM: Workflow, Enterprise Application Integration (EAI), Process Activity Monitoring (BAM), Rules Engine, Process Simulation. Ideally, they could be part of a BPM enabled system (BPMS).

An independent MDSD view of BPM is evident: models and transformations have become fundamental concepts of BPM in order to achieve goals.

3. SOA and BPM

There is an intersection between SOA and BPM: on the one hand, it is the modeling and specification of business processes, and on the other hand, it is the respective infrastructure software (middleware). SOA completes the business process modeling with the business process execution language built on the basis of web service technology and coupled with it. BPM uses Achilles tendon abstract language concepts and representations to complete the modeling of business processes. Therefore, starting from a certain point of view, it can be said that SOA is a bottom-up development process, while BPM is a top-down development process. The middleware that SOA puts at the intersection is mainly regarded as an enterprise service bus (ESB), which should be regarded as a logical bus for message, service composition and coordination command, and also gives a business process engine or BPMS.

MDSD/MDA summarizes this section in the context of SOA and BPM:

MDSD/MDA provides standards-based modeling of business processes (that is, the definition of a standardized MOF-based BPM meta-model) and their respective "universal" representations. OMG has set up a corresponding campaign.
MDSD/MDA can provide a rational, complete and architecture-centric MDSD product line that supports all layers of an enterprise architecture (business processes, services/components, entity ,Persistence).
It has been claimed that MDSD enables services -- that is, the redesign of legacy applications for SOA monolithic integration in order to make them useful for BPM -- helpful because models derived from existing applications can be used as those The basis of the application. So this kind of thinking requires a lot of effort, or at least it is worth mentioning.

[Model-Driven Software Design] "Domain Architecture" can use the target architecture of MDSD