No full-text available
To read the full-text of this research,
you can request a copy directly from the authors.
A classification and rationalization of model-based software development
Abstract
The use of model-based software development is increasingly popular due to recent advancements in modeling technology. Numerous approaches exist; this paper seeks to organize and characterize them. In particular, important terminological confusion, challenges, and recurring techniques of model-based software development are identified and rationalized. New perspectives are provided on some fundamental issues, such as the distinctions between model-driven development and architecture-centric development, code generation, and metamodeling. On the basis of this discussion, we opine that architecture-centric development and domain-specific model-driven development are the two most promising branches of model-based software development. Achieving a positive future will require, however, specific advances in software modeling, code generation, and model-code consistency management.
... It is commonly modeled as a configuration of components connected via interfaces, using an architecture description language (ADL) [69]. Architecture-centric software development [114] is a novel application of software architecture to address the increasing complexity and variability of software systems. It emphasizes that software architecture should take the place of source code as the focus of software development and evolution. ...
... Architecture-centric development is an instance of model-based development [114]. Other instances of model-based development include specification-driven development [8,17] and modeldriven development (MDD) [40,58]. ...
... This is primarily because the abstraction gap between software models (e.g., the architecture) and source code can make selection and application of appropriate transformation rules (an essential activity of model transformation) difficult to automate. It is for the same reason that transformational programming [82] is not feasible in complex system development [8,114]. ...
Architecture-centric development addresses the increasing complexity and variability of software systems by focusing on architectural models, which are generally easier to understand and manipulate than source code. It requires a mechanism that can maintain architecture-implementation conformance during architectural development and evolution. The challenge is twofold. There is an abstraction gap between software architecture and implementation, and both may evolve. Existing approaches are deficient in support for both change mapping and product line architecture. This article presents a novel approach named 1.x-way mapping and its extension, 1.x-line mapping to support architecture-implementation mapping in single system development and in product line development, respectively. They specifically address mapping architecture changes to code, maintaining variability conformance between product line architecture and code, and tracing architectural implementation. We built software tools named xMapper and xLineMapper to realize the two approaches, and conducted case studies with two existing open-source systems to evaluate the approaches. The result shows that our approaches are applicable to the implementation of a real software system and are capable of maintaining architecture-implementation conformance during system evolution.
... To define the scope for our study, we use a classification created by Zheng and Taylor [42], who looked into clarifying definitions among model-based software development. They established four general groups: ...
... Usually, these models use the concept of domain specificity expressed in domainspecific languages, facilitating reuse within the similar applications (cf. [42]). Simulink models follow these requirements and are the main focus in our study. ...
Context: The importance of software maintainability is well understood and researched in software engineering, in general. Various metrics exist to evaluate this software quality attribute, predominantly for object-oriented and open-source software. At the same time, there is a lack of a similar understanding and concrete metrics for software maintainability of executable models, which are widely adopted in the industry, pre-dominantly, using Simulink. Objective: We address this shortage by investigating how maintainability is understood and measured for Simulink models. Method: We combine a comprehensive literature study with an extensive industry survey. In the literature re-view, we elicit present metrics and their goals. In a subsequent survey, we investigate how practitioners perceive maintainability when using Simulink models, which aspects they associate it with, and to what extent they agree with the previously elicited metrics. Results: The literature review resulted in a collection of16 metrics currently used in research to assess maintain-ability of executable models. We categorized them and extracted 23 re-occurring base measures to outline the current state-of-the-art of maintainability measurement in the field. In the consecutive survey, we collected 256maintainability aspects, grouped into eleven categories and 77 sub-categories. Lastly, we provide rankings for aspects and measures.
... By the late 1990s, rapidly growing platform complexity outgrew the ability of general-purpose languages to conceal it, and the need was recognized for defining standards in higher levels of abstraction, by applying high-level, precise but abstract modeling languages, and making models the first-order design concern [23,24]. Model-based Engineering (MBE) is a set of instruments and guidelines for bringing the advantages of modeling to software engineering [24], by promoting their usage for software synthesis in addition to their traditional roles as analysis and description tools [25]. Even though they play an important role, models in MBE are not the key artifacts of development [24]. ...
... In conclusion, MDSE is (still) not a cohesive discipline with an established body of theory or time-proven guidelines to ensure the quality of the created language [28], and is still faced with challenges in connection with multi-aspect modeling, comprehensive generation approaches, model-code consistency management and deep modeling [25]. ...
The prevailing system and software model in automation systems engineering is defined by the IEC 61131 norm. It is to date the best way we know how to express low-level logic and manipulate electrical hardware signals. However, the exponential technological growth is continuing to raise the expectations on what automation systems are supposed to be capable of doing. Fulfilling rising requirements and managing the exploding complexity requires a systematic support for high-level descriptions, structuring, and communication, which the original approach was not built to provide. This work proposes the introduction of an abstraction layer, a component-container infrastructure, defined on top of standard system and software models in automation and mirroring the world of cyber–physical systems, where independent components are interconnected to realize the systems’ purpose by using each other’s functionalities. The concept is implemented in the form of a domain-specific modeling language, applying a classical two-level Model-driven Software Engineering (MDSE) approach. By engineering distinct industrial use cases in accordance with the proposed approach, it is shown that the defined abstractions and mechanisms are capable of expressing the nuances of software design in different domains and can enable the streamlining of the automation systems engineering workflow into a virtual plug&produce process.
... Architecture-centric software development is a special instance of model-based development [14,30]. It advocates that the software architecture model [25] that is commonly characterized as a configuration of components connected via interfaces should take the place of source code to be the focus of software development and evolution. ...
... A specific challenge that it faces is full code generation. Software architecture contains principal design decisions of a software system, and generally is not sufficient to generate complete code from [30]. In fact, the strategy is mainly applicable to the product line systems developed using the Model-Driven Architecture (MDA) technology [20] and generally can only support technical platform families (i.e. the difference between the products is the underlying implementation platform only). ...
It is essential to architecture-centric product line development that product line architecture can be used to drive activities specific to product line development, such as product derivation. This requires a mechanism that can automatically derive the architecture and code of a product instance from the customization of product line architecture. In this paper, we analyze the insufficiency of two existing solutions in this area and present an architecture-centric approach that meets the requirement. The approach can support product line differences in platforms and functions, and generate both product line code and product code. It is based on a product line implementation mechanism that combines a code generation and separation pattern with an architecture-based code annotation technique. We have implemented the approach, and finished a preliminary evaluation with a chat application.
... Zheng and Taylor [18] presented an overview of modelbased software development approaches and noted three challenges. The first challenge is multiaspect modeling, or providing models from different viewpoints to develop a full system specification. ...
The Object Management Group introduced the Model-Driven Architecture in 2001. Since then, the research community has embraced model-driven engineering (MDE), but to a lesser extent than practitioners had hoped. A good awareness of practitioners’ challenges, particularly with modeling, is required to ensure the relevance of a research agenda. Therefore, this study conducts a meta-review on the state of practice in using modeling languages for software engineering over the last five years using Kitchenham’s guidelines. This study serves as an orientation within the research field and a basis for further research. It contributes to the literature by focusing on publications discussing the practical use of modeling languages and the benefits and problems perceived by practitioners. The main finding of this review is that practitioners benefit from MDE in the following ways: it is beneficial for several stakeholders; it saves cost; it is easy to use; it improves productivity, quality, and understanding of the system; and it provides support for software development activities. However, practitioners continue to face several serious challenges. The most frequently reported issues are the missing tool functionalities. Many studies have found that adhering to the Physics of Notation principles would improve modeling languages. Other findings include that modeling is mostly used for documentation and requirements elicitation, and UML is the most often used.
... In MBSD, all details of the software system are expressed in models. The final running software system is generated from the models, or the models are executed at run-time [74]. ...
Considering the integration of the individual contributions of this thesis as a holistic framework is essential for judging the feasibility and usability of the GRaViTY framework for the development of secure software systems. Therefore, we evaluate in two case studies whether the GRaViTY framework is suitable to support the development of secure software systems as intended. In this regard, we identified two objectives we focus on. First, we investigate whether the technical integration of GRaViTY allows an application of the GRaViTY approach throughout software development processes. Second, we focus on the perspective of developers and security experts working with GRaViTY. Here, we are interested in the practical usability of GRaViTY when applied to software development. Thereby, we focus more on usability as part of software development than on detailed usability in terms of software ergonomics, e.g., regarding the realized user interface. In the end, we investigate if GRaViTY can be applied to model-driven development. Altogether, we successfully applied GRaViTY as part of the two case studies.
... In MBSD, all details of the software system are expressed in models. The final running software system is generated from the models, or the models are executed at run-time [74]. ...
In the last decades, various concepts have been developed to support the development and maintenance of secure software systems. On the level of programming languages, concepts like Object-Orientation (OO) have been introduced to improve the structuring and reuse in programs. Those concepts have also been reflected in modeling languages like the Unified Modeling Language (UML). On both, various kinds of security and design checks have been introduced to support developers in developing secure software systems. Also, different development processes have been proposed to structure the development and make it projectable. Besides, additional concepts for giving early and constant feedback to developers have been developed to follow these processes successfully. At this point, the most prominent one is continuous integration. While there is an overlap between all of these concepts, these are only partly integrated. We give a short introduction to the enumerated concepts focusing on how the concepts contribute to the development of a secure software system and what are yet unsolved problems.
... In MBSD, all details of the software system are expressed in models. The final running software system is generated from the models, or the models are executed at run-time [74]. ...
For ensuring a software system's security, it is vital to keep up with changing security precautions, attacks, and mitigations. Although model-based development enables addressing security already at design-time, design models are often inconsistent with the implementation or among themselves. An additional burden are variants of software systems. To ensure security in this context, we present an approach based on continuous automated change propagation, allowing security experts to specify security requirements on the most suitable system representation. We automatically check all system representations against these requirements and provide security-preserving refactorings for preserving security compliance. For both, we show the application to variant-rich software systems. To support legacy systems, we allow to reverse-engineer variability-aware UML models and semi-automatically map existing design models to the implementation. Besides evaluations of the individual contributions, we demonstrate the approach in two open-source case studies, the iTrust electronics health records system and the Eclipse Secure Storage.
... Current UML tools and approaches are not sufficient to exploit the fine-grained behavior of the architecture. These tools only produce skeleton code [4], which must then be tailored by programmers for fine-grained and algorithmic code. The modifications of generated code might violate the architecture correctness. ...
... On top of that, our tool automates the processes of creating and maintaining variation points in the PLA. ArchFeature reduces the PLA development cost, and aims to improve the architecturecentric software development [26]. ...
Product line architecture (PLA) captures the architectural commonality and variability among products of a product family. Existing PLA modeling approaches are limited in the sense that (1) it is often difficult to relate a product line feature to its implementation in the PLA, and (2) variation points in the PLA have to be manually developed and maintained. In this paper, we present a novel PLA modeling approach and a toolset called ArchFeature that addresses these two challenges. ArchFeature integrates PLA and feature specification in a single monolithic architecture model. It includes a graphical modeling environment that can (1) automatically capture, maintain, and visualize the feature-PLA relationship, (2) encapsulate variability modeling from the user, and (3) support automatic derivation of architecture instances from the PLA. ArchFeature is an Eclipse plugin integrated in ArchStudio, an Eclipse-based architecture development platform. We assessed its usability and effectiveness in a case study by using it to develop a full-featured architecture model for an open-source software system, Apache Solr.
... platform differences, function differences that can be implemented as framework plug-ins). As the architecture plays an increasingly important role, an emerging requirement is that the changes made in the architecture model can be automatically propagated to the corresponding implementation in source code [30]. In this way, architecture centrality can be enabled. ...
A primary challenge involved in implementing product line architecture is realization of the included variation points (e.g. alternative components, optional interfaces) in source code. Existing architecture implementation techniques are focused on single system development. Software variability implementation techniques such as inheritance and overloading mainly support fine-grained variations at the programming language level. In this paper, we present a novel approach to implementing product line architecture. It combines a code generation and separation pattern with an architecture-based code annotation technique. It can support product line variability in platforms, functions, and implementation mechanisms that are at different degrees of granularity. The goal is to maintain architecture-implementation conformance and increase code reusability.
... Many state-of-the art MDE approaches (see [29] for a classification) consist in using domain-specific code generators for transforming abstract models into executable code. Typically, a code generator is specific for a modeling language and embeds the knowledge of a specific technological platform (e.g. a programming language, a middleware framework, a runtime infrastructure, a simulation environment). ...
A model is an abstract representation of a real system or phenomenon [1]. The idea of a model is to capture important properties of reality and to eglect irrelevant details. The properties that are relevant and that can be neglected depend on the purpose of creating a model. A model can make a particular system or phenomenon easier to understand, quantify, visualize, simulate, or predict.
Loose coupling of system components on all levels of automated production systems enables vital systems-of-systems properties such as simplified composition, variability, testing, reuse, maintenance, and adaptation. All these are crucial aspects needed to realize highly flexible and adaptable production systems. Based on traditional software architecture concepts, we describe in this chapter a use case of how message-based communication and appropriate architectural styles can help to realize these properties. A building block is the capabilities that describe what production participants (machines, robots, humans, logistics) are able to do. Capabilities are applied at all levels in our use case: describing the production process, describing machines, transport logistics, down to capabilities of the various functional units within a machine or robot. Based on this use case, this chapter aims to show how such a system can be designed to achieve loosely coupling and what example technologies and methodologies can be applied on the different levels.
Requirement traceability is used to ensure consistency among the artifacts created during the development and maintenance of software products. An effective traceability approach depends on several factors such as architecture, technical modeling tools, among others. The implementation of traceability in the organizations is still a challenge even many studies have been conducted on the subject. We may point out some reasons for that: difficulties of maintaining updated information about requirements and integrating all generated data from software development life-cycle, besides the lack of commercial tools for implementing methods and techniques for integrated traceability to the development process. Moreover, as requirements evolve, keeping tracking of the changes is also difficult. The aim of this work is to evaluate traceability approaches focusing on software product tra- ceability by a systematic review. We conduct a series of interviews with practitioners to complement the evaluation. Based on this study, we categorize the approaches and we propose a body of kno- wledge (BoK). This BoK intends to assist software engineers to decide how to define implementation of traceability in the development and maintenance of software products. Experts in traceability have evaluated this BoK and we notice that it meets practitioners needs. However, some improvements must be done in the future versions. We hope that the propose BoK helps practitioners to better apply and understanding traceability in both academic and industry areas.
Architectural modeling and behavior analysis are two important concerns in the software development. They are often implemented separately, and specified by their own supporting notations. Architectural modeling helps to guarantee the system design to satisfy the requirement, and behavior analysis can ensure the interaction correctness. To improve the trustworthiness, methods trying to combine architectural modeling and behavior analysis notations together have been proposed, e.g., establishing a one-way mapping relation. However, the one-way relation cannot ensure updating one notation specifications in accordance with the other one, which results in inconsistency problems. In this paper, we present an approach to integrating behavior analysis into architectural modeling, which establishes the interoperability between architectural modeling notation and behavior analysis notation by a bidirectional mapping. The architecture is specified by the modeling language, architecture analysis and design language (AADL), and then mapped to behavior analysis notation, Darwin/FSP (finite state process) through the bidirectional transformation. The bidirectional transformation provides traceability, which makes behavior analysis result provided by a model checker can be traced and reflected back to the original AADL specifications. In this way, the behavior analysis is integrated into architectural modeling. The feasibility of our approach is shown by a control system example.
The role of software architecture has changed. The use of modern software technologies and practices enables turning the focus of system development to the quality aspects of software instead of functional properties. Architecture addresses the quality issues of software and, therefore, it must be developed and documented properly. In particular, there is a need for high level architectural descriptions. The top down nature of software architecture design induces this need. In this report we introduce a quality-driven architecture design and analysis (QADA) method. Quality-driven is about utilizing architectural styles and patterns as a means of designing high-quality architectures. QADA takes a revolutionary approach to the initiation process of a new product line. That is, the development of a complete product-line architecture and a set of components before developing the first product in a new domain. QADA considers architecture on two levels of abstraction: conceptual and concrete. Design produces architectural descriptions at both abstraction levels from three viewpoints: structural, behavior and deployment. The structural viewpoint is concerned with composition of software components, whereas the behavior viewpoint takes the behavioral architecture aspects under consideration. The deployment viewpoint refers to embedding and allocation of software components to various computing environments. Quality of architecture on both levels of abstraction is analyzed in the corresponding analysis phases. Because software architectural design is difficult to discuss merely at an abstract level, the QADA method is tested with a case study of a distributed service platform. The platform embodies a layered service architecture, thereby providing a variety of services for its users. The upper layer of services, i.e. the system services of the platform is mobile, enabling spontaneous networking.
A list of QADA - related publications: http://virtual.vtt.fi/virtual/proj1/projects/qada/index.htm
From the Book:For all but the most trivial software systems, you cannot hope to succeed without paying careful attention to its architecture: the way the system is decomposed into constituent parts and the ways those parts interact with each other. Without an architecture that is appropriate for the problem being solved the project will fail. Even with a superb architecture, if it is not well understood and well communicated—in other words, well documented—the project will fail. Not may fail. Will fail.Accordingly, software architecture is at the center of a frenzy of attention these days. A new book about it seems to pop out monthly. In response to industrial need, universities are adding software architecture to their software engineering curricula. It's now common for "software architect" to be a defined position in organizations, and professional practice groups for software architects are emerging. It has been the subject of major international conferences and workshops. The purveyors of the Unified Modeling Language promote their product by calling it "the standard notation for software architecture" (a claim that may say at least as much about the pervasiveness of architecture as about UML). The Software Engineering Institute maintains a bibliography of journal and conference papers about software architecture and its population is approaching 1000.Rather surprisingly, there is a dearth of practical guidance available that is independent of language or notation for how to capture an architecture. To be sure, piles of books exist about how to use a particular language—again, UML comes to mind—but what an architect really needs is guidancein which architecture is a first-class citizen and language is relegated more appropriately to a supporting role.First, let's agree on some basic context. The field has not anointed a single definition of software architecture, and so there are many, but we'll use this one: A software architecture for a system is the structure or structures of the system, which comprise elements, their externally-visible behavior, and the relationships among them. (Adapted from Bass 98.)Much of this book is about the meaning of elements and relationships, but for now we use this definition to emphasize the plurality of structures that exist in architectures. Each structure is characterized by different kinds of elements and relationships, and each structure provides a view of the architecture that imparts a particular kind of understanding.The architecture serves as the blueprint for both the system and the project developing it. It defines the work assignments that must be carried out by design and implementation teams. The architecture is the primary carrier of system qualities such as performance, modifiability, and security, none of which can be achieved without a unifying architectural vision. Architecture is an artifact for early analysis to make sure that the design approach will yield an acceptable system. And architecture holds the key to post-deployment system understand-ing, maintenance, and mining efforts. In short, architecture is the conceptual glue that holds every phase of the project together for all of its many stakeholders.And documenting the architecture is the crowning step to crafting it. The perfect architecture is useless if it has not been expressed understandably. If you go to the trouble of creating a strong architecture, you must go to the trouble of describing it in enough detail, without ambiguity, and organized so that others can quickly find needed information. Otherwise your effort will have been wasted, because the architecture will be unusable.The goal of this book is to help you decide what information about an architecture is important to capture and to provide guidelines and notations (and examples) for capturing it. We intend this book to be a practitioner- oriented guide to the different kinds of information that constitute an architecture. We wanted to give practical guidance for choosing what information should be documented, and show (with examples in various notations, including but not limited to UML) how to describe that information in writing so that others can use it to carry out their architecture-based work: implementation, analysis, recovery, etc. Therefore, we cover: Uses of software architecture documentation. How one documents depends on how one wishes to use the documentation. We lay out possible end goals for architecture documentation, and provide documentation strategies for each. Architectural views. We hold that documenting software architecture is primarily about documenting the relevant views, and then augmenting this information with relevant information that applies across views. The heart of the book is an introduction to the most relevant architectural views, grouped into three major families (which we call viewtypes) along with practical guidance about how to write them down. Examples are included for each. Packaging th information. Once the views have been understood, there is still the problem of choosing the relevant views, including information not contained in a view, and packaging all of the information as a coherent whole. has been created, We give practical advice for all of these facets.The audience for this book includes the people involved in the production and consumption of architectural documentation, which is to say the community of software developers. We believe strongly in the importance of architecture in building successful systems. But no architecture can achieve this if it is not effectively communicated, and documentation is the key to successful communication. We hope we have provided a useful handbook for practitioners in the field.PC—Austin, TexasFB, LB, DG, JI, RL, RN, JS—Pittsburgh, Pennsylvania
A Domain-Specific Software Architecture (DSSA) t has been defined as: • "an assemblage of software components, special-ized for a particular type of task (domain), generalized for effective use across that domain, composed in a standardized structure (topol-ogy) effective for building successful applica-tions" [Hay94] or, alternately • "a context for patterns of problem elements, solution elements, and situations that define mappings between them [Hid90]. The following small example 2 illustrates these defini-tions as well as provides the reader with some insight into the types of processes and tools needed to support the creation and use of a DSSA.
In large software development organizations, increased complexity of products, shortened development cycles, and heightened expectations of quality have created major challenges at all the stages of the software life cycle. As this issue of the IBM Systems Journal illustrates, there are exciting improvements in the technologies of model-driven development (MDD) to meet many of these challenges. Even though the prevalent software-development practices in the industry are still immature, tools that embody MDD technologies are finally being incorporated in large-scale commercial software development. Assuming MDD pervades the industry over the next several years, there is reason to hope for significant improvements in software quality and time to value, but it is far from a foregone conclusion that MDD will succeed where previous software-engineering approaches have failed.
Research over the past decade has revealed that modeling software architecture at the level of components and connectors is useful in a growing variety of contexts. This has led to the development of a plethora of notations for representing software architectures, each focusing on different aspects of the systems being modeled. In general, these notations have been developed without regard to reuse or extension. This makes the effort in adapting an existing notation to a new purpose commensurate with developing a new notation from scratch. To address this problem, we have developed an approach that allows for the rapid construction of new architecture description languages (ADLs). Our approach is unique because it encapsulates ADL features in modules that are composed to form ADLs. We achieve this by leveraging the extension mechanisms provided by XML and XML schemas. We have defined a set of generic, reusable ADL modules called xADL 2.0, useful as an ADL by itself, but also extensible to support new applications and domains. To support this extensibility, we have developed a set of reflective syntax-based tools that adapt to language changes automatically, as well as several semantically-aware tools that provide support for advanced features of xADL 2.0. We demonstrate the effectiveness, scalability, and flexibility of our approach through a diverse set of experiences. First, our approach has been applied in industrial contexts, modeling software architectures for aircraft software and spacecraft systems. Second, we show how xADL 2.0 can be extended to support the modeling features found in two different representations for modeling product-line architectures. Finally, we show how our infrastructure has been used to support its own development. The technical contribution of our infrastructure is augmented by several research contributions: the first decomposition of an architecture description language into modules, insights about how to develop new language modules and a process for integrating them, and insights about the roles of different kinds of tools in a modular ADL-based infrastructure.
The confluence of component based development, model driven development and software product lines forms an approach to application development based on the concept of software factories. This approach promises greater gains in productivity and predictability than those produced by incremental improvements to the current paradigm of object orientation, which have not kept pace with innovation in platform technology. Software factories promise to make application assembly more cost effective through systematic reuse, enabling the formation of supply chains and opening the door to mass customization.
The term Model-Driven Engineering (MDE) is typically used to describe software development approaches in which abstract models of software systems are created and systematically transformed to concrete implementations. In this paper we give an overview of current research in MDE and discuss some of the major challenges that must be tackled in order to realize the MDE vision of software development. We argue that full realizations of the MDE vision may not be possible in the near to medium-term primarily because of the wicked problems involved. On the other hand, attempting to realize the vision will provide insights that can be used to significantly reduce the gap between evolving software complexity and the technologies used to manage complexity.
One of the challenging problems for software developers is guaranteeing that a system as built is consistent with its architectural design. In this paper, we describe a technique that uses run time observations about an executing system to construct an architectural view of the system. With this technique, we develop mappings that exploit regularities in system implementation and architectural style. These mappings describe how low-level system events can be interpreted as more abstract architectural operations. We describe the current implementation of a tool that uses these mappings, and show that it can highlight inconsistencies between implementation and architecture.
Using models to design complex systems is de rigeur in traditional engineering disciplines. No one would imagine constructing an edifice as complex as a bridge or an automobile without first constructing a variety of specialized system models. Models help us understand a complex problem and its potential solutions through abstraction. Therefore, it seems obvious that software systems, which are often among the most complex engineering systems, can benefit greatly from using models and modeling techniques. However, for historical reasons, models in software engineering are infrequent and, even when used, they often play a secondary role. Yet, as we shall see, the potential benefits of using models are significantly greater in software than in any other engineering discipline. Model-driven development methods were devised to take advantage of this opportunity, and the accompanying technologies have matured to the point where they are generally useful. A key characteristic of these methods is their fundamental reliance on automation and the benefits that it brings. However, as with all new technologies, MDD's success relies on carefully introducing it into the existing technological and social mix. To that end, I cite several pragmatic criteria-all drawn from industrial experience with MDD.
The artifacts constituting a software system often drift apart
over time. We have developed the software reflexion model technique to
help engineers perform various software engineering tasks by exploiting,
rather than removing, the drift between design and implementation. More
specifically, the technique helps an engineer compare artifacts by
summarizing where one artifact (such as a design) is consistent with and
inconsistent with another artifact (such as source). The technique can
be applied to help a software engineer evolve a structural mental model
of a system to the point that it is “good enough” to be used
for reasoning about a task at hand. The software reflexion model
technique has been applied to support a variety of tasks, including
design conformance, change assessment, and an experimental reengineering
of the million-lines-of-code Microsoft Excel product. We provide a
formal characterization of the reflexion model technique, discuss
practical aspects of the approach, relate experiences of applying the
approach and tools, and place the technique into the context of related
work
Software architecture has become a centerpiece subject for software engineers, both researchers and practitioners alike. At the heart of every software system is its software architecture, i.e., "the set of principal design decisions about the system". Architecture permeates all major facets of a software system, for principal design decisions may potentially be made at any time during a system's lifetime, and potentially by any stakeholder. Such decisions encompass structural concerns, such as the system's high-level building blocks -components, connectors, and configurations; the system's deployment; the system's non-functional properties; and the system's evolution patterns, including runtime adaptation. Software architectures found particularly useful for families of systems - product lines - are often codified into architectural patterns, architectural styles, and reusable, parameterized reference architectures. This tutorial affords the participant an extensive treatment of the field of software architecture, its foundation, principles, and elements, including those mentioned above. Additionally, the tutorial introduces the participants to the state-of-the-art as well as the state-of-the-practice in software architecture, and looks at emerging and likely future trends in this field. The discussion is illustrated with numerous real-world examples. One example given prominent treatment is the architecture of the World Wide Web and its underlying architectural style, REpresentational State Transfer (REST).
This paper is about a paradigm shift from the current practice of manually searching for and adapting components and their manual assembly to Generative Programming, which is the automatic selection and assembly of components on demand. First, we argue that the current OO technology does not support reuse and configurability in an effective way. Then we show how a system family approach can aid in defining reusable components. Finally, we describe how automate the assembly of components based on configuration knowledge. We compare this paradigm shift to the introduction of interchangeable parts and automated assembly lines in the automobile industry.
We also illustrate the steps necessary to develop a product line using a simple example of a car product line. We present the feature model of the product line, develop a layered architecture for it, and automate the assembly of the components using a generator. We also discuss some design issues, applicability of the approach, and future development.
Round-trip engineering is a challenging task that will become an important enabler for many Model-Driven Software Development approaches. Model round-trip engineering involves synchronizing models by keeping them consistent, thus enabling the software engineer to freely move between different representations. The vision of model round-trip engineering (MRTE) is only realized to a limited degree in Integrated Development Environments (IDE) nowadays, and it proves to be a very difficult problem to solve in general. In this paper, our goal is to clarify some of the issues in automating MRTE and point out some of the high-level qualities that are desirable for MRTE approaches to possess. Clarifying this domain is an important first step towards being able to automate round-trip engineering of models.
It is essential for software architecture to be consistent with implementation during software development. Existing architecture-implementation mapping approaches are not sufficient due to a variety of reasons, including lack of support for change management and mapping of behavioral architecture specification. A new approach called 1.x-way architecture-implementation mapping is presented in this paper to address these issues. Its contribution includes deep separation of generated and non-generated code, an architecture change model, architecture-based code regeneration, and architecture change notification. The approach is implemented in ArchStudio 4, an Eclipse-based architecture development environment. To evaluate its utility, we refactored the code of ArchStudio, and replayed changes that had been made to ArchStudio in two research projects by redoing them with the developed tool.
From the Book:For many years, the three of us have been developing software using object oriented techniques. We started with object oriented programming languages, like C++, Smalltalk, and Eiffel. Soon we felt the need to describe our software at a higher level of abstraction. Even before the first object oriented analysis and design methods, like Coad/Yourdon and OMT, were published, we used our own invented bubbles and arrows diagrams. This naturally led to questions like "What does this arrow mean?" and "What is the difference between this circle and that rectangle?". We therefore rapidly decided to use the newly emerging methods to design and describe our software. During the years we found that we were spending more time on designing our models, than on writing code. The models helped us to cope with larger and more complex systems. Having a good model of the software available, made the process of writing code easier and in many cases even straightforward.In 1997 some of us got involved in defining the first standard for object oriented modeling called UML. This was a major milestone that stimulated the use of modeling in the software industry. When the OMG launched its initiative on Model Driven Architecture we felt that this was logically the next step to take. People try to get more and more value from their high level models, and the MDA approach supports these efforts.At that moment we realized that all these years we had naturally walked the path towards model driven development. Every bit of wisdom we acquired during our struggle with the systems we had to build, fitted in with this new idea of how to build software. It caused a feeling similar to an AHA-erlebnis: "Yes, this is it," the same feeling we had years before when we first encountered the object-oriented way of thinking, and again when we first read the GOF book on design patterns. We feel that MDA could very well be the next major step forward in the way software is being developed. MDA brings the focus of software development to a higher level of abstraction, thereby raising the level of maturity of the IT industry.We are aware of the fact that the grand vision of MDA, which Richard Soley, the president of the OMG, presents so eloquently, is not yet a reality. However some parts of MDA can already be used today, while others are under development. With this book we want to give you insight in what MDA means and what you can achieve, both today and in the future.Anneke Kleppe, Jos Warmer, and Wim BastSoest, the NetherlandsJanuary 2003
From the Book:PREFACE: PrefaceI've dreamed about writing this book for many years, but it did not turn out as I imagined. XML and Java are recent technologies that did not appear in my dreams. I've been working with program generators and domain engineering for nearly 20 years using primarily C and hand-crafted plain text languages. XML and Java provide a new context for these older technologies and they fit together. It was a joy to retrace the steps I had taken many years ago, and see how much easier and more elegant the trek is using XML and Java.I toyed with the idea of titling the book, "Program Generators for Fun and Profit." Writing a program generator is a lot of fun because instead of just writing a program, you write a program that writes programs. You think about how smart you can make your program generator. Some program generators are called "wizards!" Program generators are also very profitable. They are a critical piece of many software engineering development environments, particularly in the areas of user interfaces, databases, middleware, and language parsers and lexers.Once you've written a couple of program generators, you begin to wonder: Is there a better approach to figuring out what a program generator should do? The answer is yes, but it's been kept a secret. The better approach is called domain engineering, which is a systematic approach that identifies the important elements and requirements in a domain. This information is essential for efficiently building a program generator that meets customer needs.Many computer scientists, including myself, are fascinated with self-referential structures. One such structure isaprogram generator generator. A program generator generator is a program generator that generates program generators. It is a program that writes programs that write programs. Chapter 12 recapitulates some of the work I did at Bell Labs in this area, but this time in a simpler and more elegant style using XML and Java. It is simple enough that anyone can create his or her own program generator generator in a matter of days.
As a complex software system evolves, its implementation tends to diverge from the intended or documented design models. Such undesirable deviation makes the system hard to understand, modify and maintain. This paper presents a hybrid computer-assisted approach for confirming that the implementation of a system maintains its expected design models and rules. Our approach closely integrates logic-based static analysis and dynamic visualization, providing multiple code views and perspectives. We show that the hybrid technique helps determine design-implementation congruence at various levels of abstraction: concrete rules like coding guidelines, architectural models like design patterns or connectors, and subjective design principles like low coupling and high cohesion. The utility of our approach has been demonstrated in the development of /spl mu/Choices, a new multimedia operating system which inherits many design decisions and guidelines learned from experience in the construction and maintenance of its predecessor, Choices.
This paper is about a paradigm shift from the current practice of manually searching for and adapting components and their manual assembly to Generative Programming, which is the automatic selection and assembly of components on demand. First, we argue that the current OO technology does not support reuse and configurability in an effective way. Then we show how a system family approach can aid in defining reusable components. Finally, we describe how automate the assembly of components based on configuration knowledge. We compare this paradigm shift to the introduction of interchangeable parts and automated assembly lines in the automobile industry. We also illustrate the steps necessary to develop a product line using a simple example of a car product line. We present the feature model of the product line, develop a layered architecture for it, and automate the assembly of the components using a generator. We also discuss some design issues, applicability of the approach, and future development.
"[The authors] are pioneers. . . . Few in our industry have their breadth of knowledge and experience." From the Foreword by Dave Thomas, Bedarra Labs
Domain-Specific Modeling (DSM) is the latest approach to software development, promising to greatly increase the speed and ease of software creation. Early adopters of DSM have been enjoying productivity increases of 500-1000% in production for over a decade. This book introduces DSM and offers examples from various fields to illustrate to experienced developers how DSM can improve software development in their teams. Two authorities in the field explain what DSM is, why it works, and how to successfully create and use a DSM solution to improve productivity and quality. Divided into four parts, the book covers: background and motivation; fundamentals; in-depth examples; and creating DSM solutions. There is an emphasis throughout the book on practical guidelines for implementing DSM, including how to identify the necessary language constructs, how to generate full code from models, and how to provide tool support for a new DSM language. The example cases described in the book are available the book's website, www.dsmbook.com, along with an evaluation copy of the MetaEdit+ tool (for Windows, Mac OS X, and Linux), which allows readers to examine and try out the modeling languages and code generators. Domain-Specific Modeling is an essential reference for lead developers, software engineers, architects, methodologists, and technical managers who want to learn how to create a DSM solution and successfully put it into practice.
Done well, separation of concerns can provide many software engineering benefits, including reduced complexity, improved reusability, and simpler evolution. The choice of boundaries for separate concerns depends on both requirements on the system and on the kind(s) of decomposition and composition a given formalism supports. The predominant methodologies and formalisms available, however, support only orthogonal separations of concerns, along single dimensions of composition and decomposition. These characteristics lead to a number of well-known and difficult problems. The paper describes a new paradigm for modeling and implementing software artifacts, one that permits separation of overlapping concerns along multiple dimensions of composition and decomposition. This approach addresses numerous problems throughout the software lifecycle in achieving well-engineered, evolvable, flexible software artifacts and traceability across artifacts
Model-driven approaches move development focus from thirdgeneration programming language code to models, specifically models expressed in the Unified Model Language and its profiles. The objective is to increase productivity and reduce time-to-market by enabling development and using concepts closer to the problem domain at hand, rather than those offered by programming languages. Model-driven development's key challenge is to transform these higher-level models to platform-specific models that tools can use to generate code. UML gives numerous options to developers.(1) A UML model can graphically depict a system's structure and behavior from a certain viewpoint and at a certain level of abstraction. This is desirable, because typically we can better manage a complex system description through multiple models, where each captures a different aspect of the solution. We can use models not only horizontally to describe different system aspects but also vertically, to be refined from higher to lower levels of abstraction. At the lowest level, models use implementation technology concepts. Working with multiple, interrelated models requires significant effort to ensure their overall consistency. In addition to vertical and horizontal model synchronization, we can significantly reduce the burden of other activities, such as reverse engineering, view generation, application of patterns, or refactoring, through automation. Many of these activities are performed as automated processes that take one or more source models as input and produce one or more target models as output, while following a set of transformation rules. We refer to this process as model transformation. Here, we analyze current approaches to model transformation, concentrating on desirable characteristics of a model transformation language that can be used by modeling and design tools to automate tasks, thus significantly improving development productivity and quality.
The key to applying computer-aided software engineering to the maintenance and enhancement of existing systems lies in applying reverse-engineering approaches. However, there is considerable confusion over the terminology used in both technical and marketplace discussions. The authors define and relate six terms: forward engineering, reverse engineering, redocumentation, design recovery, restructuring, and reengineering. The objective is not to create new terms but to rationalize the terms already in use. The resulting definitions apply to the underlying engineering processes, regardless of the degree of automation applied
Automatic programming consists not only of an automatic compiler but also of some means of acquiring the high-level specification to be compiled, some means of determining that it is the intended specification, and some (interactive) means of translating this high-level specification into a lower-level one which can be automatically compiled. The author has been working on this extended automatic programming problem for nearly 15 years, and this paper presents his perspective and approach to this problem and justifies it in terms of his successes and failures. Much of his recent work centers on an operational testbed incorporating usable aspects of this technology. This testbed is being used as a prototyping vehicle and will soon be released to the research community as a framework for development and evolution of Common Lisp systems.
Software architectures shift the focus of developers from
lines-of-code to coarser-grained architectural elements and their
overall interconnection structure. Architecture description languages
(ADLs) have been proposed as modeling notations to support
architecture-based development. There is, however, little consensus in
the research community on what is an ADL, what aspects of an
architecture should be modeled in an ADL, and which of several possible
ADLs is best suited for a particular problem. Furthermore, the
distinction is rarely made between ADLs on one hand and formal
specification, module interconnection, simulation and programming
languages on the other. This paper attempts to provide an answer to
these questions. It motivates and presents a definition and a
classification framework for ADLs. The utility of the definition is
demonstrated by using it to differentiate ADLs from other modeling
notations. The framework is used to classify and compare several
existing ADLs, enabling us, in the process, to identify key properties
of ADLs. The comparison highlights areas where existing ADLs provide
extensive support and those in which they are deficient, suggesting a
research agenda for the future
A method is presented for the stepwise refinement of an abstract
architecture into a relatively correct lower-level architecture that is
intended to implement it. A refinement step involves the application of
a predefined refinement pattern that provides a routine solution to a
standard architectural design problem. A pattern contains an abstract
architecture schema and a more detailed schema intended to implement it.
The two schemas usually contain very different architectural concepts
(from different architectural styles). Once a refinement pattern is
proven correct, instances of it can be used without proof in developing
specific architectures. Individual refinements are compositional,
permitting incremental development and local reasoning. A special
correctness criterion is defined for the domain of software
architecture, as well as an accompanying proof technique. A useful
syntactic form of correct composition is defined. The main points are
illustrated by means of familiar architectures for a compiler. A
prototype implementation of the method has been used successfully in a
real application
Computers now control many critical systems in our lives, from the
brakes on our cars to the avionics control systems on planes. Such
computers wed physical systems to software, tightly integrating the two
and generating complex component interactions unknown in earlier
systems. Thus, it is imperative that we construct software and its
associated physical system so they can evolve together. The paper
discusses one approach that accomplishes this called model-integrated
computing. This works by extending the scope and use of models. It
starts by defining the computational processes that a system must
perform and develops models that become the backbone for the development
of computer-based systems. In this approach, integrated, multiple-view
models capture information relevant to the system under design. The
paper considers the Multigraph Architecture framework for
model-integrated computing developed at Vanderbilt's Measurement and
Computing Systems Laboratory
Done well, separation of concerns can provide many software engineering benefits, including reduced complexity, improved reusability, and simpler evolution. The choice of boundaries for separate concerns depends on both requirements on the system and on the kind(s) of decomposition and composition a given formalism supports. The predominant methodologies and formalisms available, however, support only orthogonal separations of concerns, along single dimensions of composition and decomposition. These characteristics lead to a number of well-known and difficult problems. This paper describes a new paradigm for modeling and implementing software artifacts, one that permits separation of overlapping concerns along multiple dimensions of composition and decomposition. This approach addresses numerous problems throughout the software lifecycle in achieving wellengineered, evolvable, flexible software artifacts and traceability across artifacts. Keywords Hypermodules; hyperslices; software...
Software architecture describes the structure of a system, enabling more effective design, program understanding, and formal analysis. However, existing approaches decouple implementation code from architecture, allowing inconsistencies, causing confusion, violating architectural properties, and inhibiting software evolution. ArchJava is an extension to Java that seamlessly unifies software architecture with implementation, ensuring that the implementation conforms to architectural constraints. A case study applying ArchJava to a circuit-design application suggests that ArchJava can express architectural structure effectively within an implementation, and that it can aid in program understanding and software evolution.
MDA Explained: The Model Driven Architecture: Practice and Promise
- A G Kleppe
- J Warmer
- AG Kleppe