Definitions and approaches to model quality in model-based software development - A review of literature <s> Models and Model-Based Software Development <s> Written by the three pioneers behind the Unified Modeling Language (UML) standard, The Unified Modeling Language Reference Manual provides an excellent real-world guide to working with UML. This title provides expert knowledge on all facets of today's UML standard, helping developers who are encountering UML on the job for the first time to be more productive. The book begins with a history of UML, from structured design methods of the '60s and '70s to the competing object-oriented design standards that were unified in 1997 to create UML. For the novice, the authors illustrate key diagram types such as class, use case, state machine, activity, and implementation. (Of course, learning these basic diagram types is what UML is all about. The authors use an easy-to-understand ticket-booking system for many of their examples.) After a tour of basic document types, The Unified Modeling Language Reference Manual provides an alphabetical listing of more than 350 UML terms. Entries range from a sentence or two to several pages in length. (Class, operation, and use case are just a few of the important terms that are covered.) Though you will certainly need to be acquainted with software engineering principles, this reference will serve the working software developer well. As the authors note, this isn't UML for Dummies, but neither is it an arcane academic treatise. The authors succeed in delivering a readable reference that will answer any UML question, no matter how common or obscure. --Richard Dragan <s> BIB001 </s> Definitions and approaches to model quality in model-based software development - A review of literature <s> Models and Model-Based Software Development <s> Model Driven Software Development (MDD) is a vision of software development where models play a core role as primary development artifacts. Its industrial adoption depends on several factors, including possibilities of increasing productivity and quality by using models. In this paper we present a case study of two companies willing to adopt the principles of MDD. One of the companies is in the process of adopting MDD while the other withdrew from its initial intentions. The results provide insights into the differences in requirements for MDD in these organizations, factors determining the decision upon adoption and the potentially suitable modeling notation for the purpose of each of the companies. The analysis of the results from this case study, supported by the conclusions from a previous case study of a successful MDD adoption, show also which conditions should be fulfilled in order to increase the chances of succeeding in adopting MDD. <s> BIB002 </s> Definitions and approaches to model quality in model-based software development - A review of literature <s> Models and Model-Based Software Development <s> Foreword. Preface . PART 1: BACKGROUND AND MOTIVATION. 1. Introduction. 1.1 Seeking the better level of abstraction. 1.2 Code-driven and model-driven development. 1.3 An example: modeling with a general-purpose language and with a domain-specific language. 1.4 What is DSM? 1.5 When to use DSM? 1.6 Summary. 2. Business value. 2.1 Productivity. 2.2 Quality. 2.3 Leverage expertise. 2.4 The economics of DSM. 2.5 Summary. PART 2: FUNDAMENTALS. 3. DSM defined. 3.1 DSM characteristics. 3.2 Implications of DSM for users. 3.3 Difference to other modeling approaches. 3.4 Tooling for DSM. 3.5 Summary. 4. Architecture of DSM. 4.1 Introduction. 4.2 Language. 4.3 Models. 4.4 Code generator. 4.5 Domain framework and target environment. 4.6 DSM organization and process. 4.7 Summary. PART 3: DSM EXAMPLES. 5. IP telephony and call processing. 5.1 Introduction and objectives. 5.2 Development process. 5.3 Language for modeling call processing services. 5.4 Modeling IP telephony service. 5.5 Generator for XML. 5.6 Framework support. 5.7 Main results. 5.8 Summary. 6. Insurance products. 6.1 Introduction and objectives. 6.2 Development process. 6.3 Language for modeling insurances. 6.4 Modeling insurance products. 6.5 Generator for Java. 6.6 Framework support. 6.7 Main results. 6.8 Summary. 7. Home Automation. 7.1 Introduction and objectives. 7.2 Development process. 7.3 Home automation modeling language. 7.4 Home automation modeling language in use. 7.5 Generator. 7.6 Main results. 7.7 Summary. 8. Mobile phone applications using Python framework. 8.1 Introduction and objectives. 8.2 Development process. 8.3 Language for application modeling. 8.4 Modeling phone applications. 8.5 Generator for Python. 8.6 Framework support. 8.7 Main results. 8.8 Extending the solution to native S60 C++. 8.9 Summary. 9. Digital Wristwatch. 9.1 Introduction and Objectives. 9.2 Development Process. 9.3 Modeling Language. 9.4 Models. 9.5 Code Generation for Watch Models. 9.6 The Domain Framework. 9.7 Main Results. 9.8 Summary. PART 4: CREATING DSM SOLUTIONS. 10 DSM language definition. 10.1 Introduction and objectives. 10.2 Identifying and defining modeling concepts. 10.3 Formalizing languages with metamodeling. 10.4 Defining language rules. 10.5 Integrating multiple languages. 10.6 Notation for the language. 10.7 Testing the languages. 10.8 Maintaining the languages. 10.9 Summary. 11. Generator definition. 11.1 "Here's one I made earlier". 11.2 Types of generator facilities. 11.3 Generator output patterns. 11.4 Generator structure. 11.5 Process. 11.6 Summary. 12. Domain Framework. 12.1 Removing duplication from generated code. 12.2 Hiding platform details. 12.3 Providing an interface for the generator. 12.4 Summary. 13. DSM definition process. 13.1 Choosing among possible candidate domains. 13.2 Organizing for DSM. 13.3 Proof of concept. 13.4 Defining the DSM solution. 13.5 Pilot project. 13.6 DSM deployment. 13.7 DSM as a continuous process in the real world. 13.8 Summary. 14. Tools for DSM. 14.1 Different approaches to building tool support. 14.2 A Brief History of Tools. 14.3 What is needed in a DSM environment. 14.4 Current tools. 14.5 Summary. 15. DSM in use. 15.1 Model reuse. 15.2 Model sharing and splitting. 15.3 Model versioning. 15.4 Summary. 16. Conclusion. 16.1 No sweat shops--But no Fritz Lang's Metropolis either. 16.2 The onward march of DSM. Appendix A: Metamodeling Language. References. Index. <s> BIB003
Models are representations of a (software) system at an abstract level BIB001 . In this review we use the term "model" as a description or representation of a software system or its environment for a certain purpose, developed using a modelling language and thus conforming to a metamodel. A model may consist of several "diagrams" where each diagram type gives a different view on the described system. For example UML 2.0 has 13 diagram types such as use case diagram, class diagram etc. In MDE, It is common to model a system at different abstraction levels as well; thus having several models of the same system. The role of models varies a lot in software development approaches applied in companies. Fowler has identified three modes of UML use 6 :  UMLAsSketch: the emphasis of sketches is on selective communication rather than complete specification. These sketches should be acceptable by users.  UMLAsBlueprint: blueprints are developed by a designer whose job is to build a detailed design for a programmer to code up and thus UMLAsBlueprint requires correctness and completeness of models to some degree.  UMLAsProgrammingLanguage: semantics is added to UML models to make them executable. Here models should have the quality required for the purpose of execution. Brown has also discussed the spectrum of modelling as presented in BIB002 and depicted in Figure I . The left hand side of the spectrum represents the traditional development without graphical modelling -the code is the main artefact. The right hand side of the spectrum represents the opposite of it, the code playing a secondary role and the development is done solely using models (e.g. utilizing executable modelling techniques). The model-centric approach is an ambitious goal of MDE as it still is based on code while the models are the main artefacts. Most (or all, if possible) of the code is generated from models; the developers, however, are given a possibility to add the code and synchronize it with models. The fact that the code can be altered after it is generated and it can be synchronized is close to the idea of roundtrip engineering, where the code and the model coexist and one is synchronized once the other is updated. Such a usage scenario can be seen as an advanced usage of models which is the extension of the idea of basic modelling. The basic modelling represents a situation when models are used as a documentation and as basic (usually architectural only) sketches of the software to be built. The models and the code coexist but the code is the main artefact which is used in the course of software development. In the code visualization scenario the code is the main artefact; models are generated automatically and are not used to develop software, but to provide means of understanding the code. BIB003 See his blog http://martinfowler.com/bliki/ Figure I . Model-driven software development adoption spectrum, from BIB002 Staron writes that there is no sharp borderline between which of the usage scenarios (except for "code only") can be seen as a realization of MDE BIB002 . In this article we refer to model-based software development for approaches where models play a central role in software development, which covers the right hand side of Figure I . The covered literature covers approaches from basic modelling to full MDE, while most refer to modelling for more than providing sketches as in basic modelling. When moving from the left hand to the right hand side of the spectrum, quality requirements (or goals) for models change and quality of models become more important. For example if models and code coexist, models must be correct and complete (to some degree) and also be easy to modify to keep them in sync with the code. Thus quality goals vary depending on the purpose of models. MDE covers approaches where development is carried out using models; often at different abstraction levels and from multiple views. Although UML is the core language of the MDA initiative, MDE does not rely on UML. In fact it is often impossible to express the details of models required in a MDE approach in UML, which is the reason for extending UML and developing "UML profiles" or even Domain-Specific Modelling Languages (DSML). In this article we therefore cover research on the quality of UML models in addition to research with MDE focus, including UML profiles and DSMLs. In MDE, models are subject of transformation to other models or text such as source code. The OMGs' MDA approach differs between CIM (Computational Independent Model), PIM (Platform independent Model) and PSM (Platform Specific Model) where more abstract models (CIM or PIM) can be transformed to PSM or directly to the implementation. For example, it might not be possible to completely specify an application as a PIM, but at least a large part of the application's static structure and interface design should be captured and then translated into PSM or code  . We emphasize especially that future usage of models such as generating test cases, code (partially or totally) or simulation drive identifying quality goals. In the next section we provide a definition of model quality goals that are important in model-based software development approaches depending on the purpose of models.