Software Architecture in Context of MDSD

• MDSD perspective on the topic of software architecture leads us to the term target architecture
that contains the platform architecture.
• MDSD domain architecture is also software architecture. It defines the whole of the meta-
model, DSL, and platform, as well as transformations.
• Software architecture is describes the most important platform components, their interactions,
as well as their non-functional characteristics, which is it platform architecture.
• Software architecture also plays a role in MDSD transformations, because it actually defines the
software architecture of the generated code, it is call Transformation architecture.
• Software architecture is tool architecture.

What is Sound Architecture?

The Architecture must support the functional requirements, non-functional requirements, simpler,
easier to understand and practicable, well document that includes a brief and concise documentation of
all the points is called Sound Architecture.

How do you arrive any Sound Architecture?

Through Architectural Patterns and Styles, like this example:

A proven way of obtaining a good architecture is the use of a tried and tested architectural pattern or
style as basis of one’s own architecture.

Building Blocks for Software Architecture

Framework are anything that can be adapted or extended via systematic extension or configuration.
Frameworks are DSLs. MDSD platforms can be very well implemented with the help of frameworks.
Typical examples of frameworks are J2EE and .NET.

Middleware can be seen as a kind of framework. It is specific to a technical domain such as distributed
systems, messaging, or transactions. Well-known examples are CORBA, DCOM, MQSeries, and CICS.

Components is a self-contained piece of software with clearly-defined interfaces and explicitly declared
context dependencies.
 Software Factories
The term Software Factories has been coined by Microsoft and is described extensively in

Jack Greenfield and Keith Short’s book of the same name [GS04]. In a nutshell, a Software

Factory is an IDE specifically configured for the efficient development of a specific kind of application, such
as applications in a specific domain. The configured IDE makes the use of domain-specific models, DSLs,
frameworks, and patterns as simple as possible. The concept of Software Factories is thus the
industrialization of software development ‘from craftsmanship to manufacturing’. Software Factories are
described by some people as ‘doing product lines the Microsoft way’ – for some detail about product-line
engineering, see Section 13.5.

While the product line aspect of that statement is certainly true, Microsoft is working on making sure the
approach is not considered to be a Microsoft-only concept. For example, the respective workshop at
the OOPSLA 2005 conference [SFW05] ensured that people from outside Microsoft were on the program
committee. However, the public perception is still that it is very much Microsoft-centric.

Since the concept of Software Factories looks at the complete product-line engineering process, it is much
wider in scope than ‘just’ Model-Driven Software Development, although DSLs, modeling. And
transformations are an important ingredient. We will therefore look first at the overall approach, then at
its DSL-specific aspects.

The Software Factory Schema

The cornerstone of the whole concept is arguably the Software Factory Schema. This defines the
viewpoints that are useful and necessary for building a system of the respective kind. For example, an
enterprise system might encompass the following viewpoints:

• Presentation, including form layout and workflow

• Component structure and business data model
• Persistence mapping
• Deployment viewpoint

For each of these viewpoints, the schema identifies core artifacts, as well as the most efficient way of
producing them. Such ways could include manual programming, using patterns in specific ways, using
frameworks that are extended or configured, as well as designing and subsequently using DSLs and
then generating various artifacts such as code or configuration files.

The viewpoints can depend on each other and thus form a directed graph – in other words, the
deployment viewpoint depends on the component structure: you cannot deploy what you haven’t
defined.

The schema is therefore a conceptual framework or ‘recipe’ for separating the concerns in the
respective application domain, based on abstraction level or its position in the architectural or
development process. The schema also identifies the commonalities as well as the differences
among the applications in the domain addressed by the schema.
 The Software Factory Template
The schema is basically a structured document. However, to be able to configure the development
environment for the respective kind of applications– and such tool configuration is the ultimate goal of
Software Factories – we must make all this ‘tool usable’. This configuration for the IDE is called a
Software Factory Template. It can be loaded into your IDE (usually Visual Studio) to configure the IDE
for developing the respective kind of application. Thus, for example it:

• Provides the necessary frameworks or libraries.

• Contributes certain kinds of projects whose structure is suitable for the factory.
• Delivers build scripts.
• Extends the IDE with new DSL editors and transformations.

We also need to have the necessary tools to build some of these artifacts in the first place. While
building frameworks requires nothing specific from an IDE, this is different for DSLs. Tools for defining
meta-models, concrete syntax, and transformations are required