Definitions and approaches to model quality in model-based software development - A review of literature <s> Examples and the Impact on Model Quality <s> Component-based development promises to revolutionize the way in which software is developed and maintained. However, contemporary component technologies, such as COM+/.NET, EJB/J2EE and CORBA, only support components in the final, implementation-oriented stages of development, leaving the earlier stages of analysis and design to be organized in largely traditional, non-component oriented ways. This book describes the KobrA method, which supports a model-driven, UML-based representation of components, and a product line approach to their development and evolution. This enables the benefits of component-based development to be realized throughout the software life-cycle, and allows the reusability of components to be significantly enhanced. <s> BIB001 </s> Definitions and approaches to model quality in model-based software development - A review of literature <s> Examples and the Impact on Model Quality <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> BIB002
There have been several attempts to adapt existing development processes to MDE by adding artefacts, activities and roles. Firstly, Gavras et al. have identified phases and activities of a model-driven based development trajectory process that include phases related to MDE artefacts and tasks [P9] . These phases precede the core development phase and include choosing technologies and developing needed artefacts (such as metamodels, modelling language, transformations, validation rules and tools), as depicted in Figure IV . These artefacts are then deployed for use in the project execution phase, as depicted in Figure  V . The project execution phase has an activity related to validation of models. The paper presents an outline of an example study that has been carried out where the roles and products of each activity are defined in accordance with the Software Process Engineering Metamodel (SPEM), which is an OMG specification to describe software development processes 9 . Figure IV. Preliminary preparation phase in an MDE-based project as defined in [P9] 9 http://www.omg.org/technology/documents/formal/spem.htm Figure V . Project execution activities as defined in [P9] In the same spirit as Gavras et al., Staron et al. have identified activities in a MDE based development process [P34] . The defined process is iterative and involves normal tasks of software development such as requirements elicitation, development, test and deployment; but with additional MDE activities. For example based on the requirements, the team elicits requirements specific for the PIM and PSM transformations which in turn form the basis for UML profiles definition. There are seven phases in the MDE development process as shown in Figure VI . The process is developed within an industrial case study. The above two papers touch on an obviously important topic as having control of the quality of the MDE tooling is necessary to have control of the quality of systems being developed using the tools. Staron et al. emphasize defining transformations prior to profiles: The model-driven software development process is focused on transformations-thus it is transformations that are identified during the requirements elicitation phase. As profiles are used as a means of making the transformations automated by providing storage for additional information, they are not considered at this phase. Thus their process add identifying transformations and defining profiles to the Gavras et al. process while it lacks defining a traceability strategy. There are also approaches that include metrics and tool support for evaluating the progress and the quality of development artefacts. Firstly, Lange et al. have identified tasks of model-centric software engineering (meaning that UML models are used for more than describing the system) and the information that is required to fulfil these tasks [P21] . Examples of tasks are program understanding or completeness evaluation. A task may consist of a number of questions about UML models. They propose to visualize the information required to support fulfilling the tasks and have developed a tool to support their approach on UML models; i.e., the MetricViewEvolution tool. The authors write that feedback from industrial case studies and a light-weight user experiment has been positive. The advantage of this tool over other tools that collect metrics from UML models is relating these metrics to performing tasks in a model-centric development process. Secondly, Berenbach proposes collecting metrics to evaluate completeness of activities, in his approach related to requirement modelling [P4] . The author proposes a model-centric requirement process which covers steps for developing, reviewing and analysing requirement models, including a set of project and quality metrics. Berenbach writes that quality requirements are defined in a way that they could be programmatically verified. For example completeness of requirement models are defined as:  Every leaf use case (a use case with no included, extending or inheriting use cases) is concrete, with a special stereotype. The stereotypes of functional and non-functional requirements were used, and the stereotypes were given special icons for ease of visual inspection.  The leaf use cases become the high level requirements that are subject to a formal review. The model is also subject to a review, primarily to check for completeness and defects. Quality metrics are defined towards requirement models and measured frequently, giving the possibility to give insight into the project progress. Examples are "the number of objects on diagrams" or "concrete use cases not defined". It seems clear that having a high quality requirements process is important, and having ways of saying "how good" the requirements are is thus a clear advantage. In traditional development, it is quite common to perform code review, so in the model-based development process, model reviews should be natural as proposed in [P15] [P22] [P26] . Other quality assurance techniques such as collecting metrics by tools and analyzing them should be part of a modelling process as well. Although we do not intend to cover these techniques, we have referred to them whenever they are mentioned in the studies. Some papers have also provided guidelines or conventions regarding the modelling process. Examples are:  Berenbach recommends the following [P3] : The early modelling effort should cover the entire breadth of the domain. Identify "out of scope" use cases as early as possible. To support this, all the actors in the model should be shown on the "context" diagram. Discover business objects and their services through use case definition with sequence diagrams. Elicit requirements and processes by starting at interfaces and modelling inward.  Mitchell warns against assuming that all domain modelling must happen in the first phase, and all design in later phases [P25] . I.e., an iterative approach is recommended; as also by Ambler [P1]. Ambler has developed the Agile Modelling (AM) 10 approach which is a collection of practices to be used in modelling and documentation of software systems, as depicted in Figure VII . Models in AM are sketches developed for communication and not generation and the focus of Ambler is on UML models. The interesting aspect is however the focus of AM on change and agility in modelling which is often ignored by other modelling processes. Many of the practices apply for a model-based software development approach, such as:  Apply the right artefact(s). Each artefact has its own specific applications (related to confinement).  Create simple content; the implication is that you should not add additional aspects to your models unless they are justifiable (related to confinement).  Single source information; you should also model a concept once and once only, storing the information in the best place possible (to avoid inconsistency). We found several examples of conventions proposed for UML models. Some would be relevant independent of the modelling language. Examples are:  In the book "The elements of UML 2.0 style", Ambler describes a collection of conventions for creating effective UML diagrams [P1]. The book contains some general guidelines applicable to any type of UML diagrams, guidelines for common UML modelling elements such as notes and stereotypes, and guidelines for specific UML diagrams.  In the book "Verification and validation for quality of UML 2.0 models", Unhelkar provides guidelines for modelling and checklists to check UML diagrams for syntax, semantic and aesthetic issues [P38] .  Berenbach presents a set of heuristics for creating "complete" UML analysis and design models, which may further be analyzed by tools [P3] . The proposed conventions cover model organization in general, use case definitions, analysis models, business object models, and design models, and affect most of the quality goals. Several large models at Siemens were evaluated using the DesignAdvisor tool which checks models for some of the proposed conventions, while other conventions may be checked by inspections.  The KobrA method makes components the focus of the entire software development process by adopting a product-line strategy for their creation, maintenance, and deployment BIB001 . In KobrA, each component is described by a suite of UML diagrams as if it were an independent system in its own right. Choi and Bunse write that the use of UML diagrams and the recursive nature of KobrA introduce two consistency issues in general; static consistency and behavioural consistency. Static consistency mainly refers to structural and naming/type consistency among specifications describing different aspects of a component. A total of 59 rules are proposed to improve static consistency which can be ensured either by manual inspection or by mechanical syntactic name checking. However, KobrA does not include behaviour consistency rules. Choi and Bunse have therefore proposed some rules and propose to check them using the model checker SPIN [P5] .  In a white paper by Mitchell, the author discusses some principles for creating high quality models based on their experience [P25] . The focus is mainly on cross-checking between architectural models and other models (use case descriptions, object models, and behaviour models such as state diagrams). The conventions cover several quality goals such as comprehensibility (regarding organization of a model, e.g.; divide a system into technical domains and subject domains) and completeness (e.g.; make sure these concepts are modelled in software, from systems analysis models, through design, and into code). Some of the conventions are related to improving the process of modelling and were discussed in Section 5.1.  Eichelberger criticises UML for the lack of aesthetic principles, and UML tools for ignoring aesthetic principles [P7] [P8] . The author proposes a set of aesthetic criteria for UML class diagrams and discusses the relation between these criteria, HCI (Human Computer Interaction) and design aspects of object-oriented software. Some aesthetic problems indicate design problems, for example "a class with a high number of outgoing relations indicate that the class depends on too many other classes" or "many classes at the borders of a package and few classes in the centre imply coupling problems". Many of the proposed conventions may be enforced by tools, but the problem today is that most modelling tools enforce syntactical and aesthetic constraints very weakly and semantic constraints are not enforced at all [P17] . For error detection, one may use tools such as DesignAdvisor or perform inspections. Several aspects of model quality are improved by using a DSML or UML profile as discussed below (since profiles are also a first step towards DSML, we will use the DSML expression to cover both):  Comprehensibility by tools is improved by adding semantics to an informal language which facilitates analysis and generation. Stereotypes can also add additional properties -informationto the stereotyped element [P34] .  Using a language close to the domain improves comprehensibility by humans, especially by nontechnical domain experts. The solution domain gets closer to the problem domain which also improves maintainability of models. Profiles or DSM introduce simplicity to the design [P39] and narrow the communicative gap between engineering and business.  Constraints can be added to models to define restrictions on the usage of base modelling elements and thus improve correctness of the models [P34] . These constraints may be defined in OCL when using UML. Note that a DSML is defined formally supported by some tool BIB002 . Therefore the advantages of being formal are achieved, in addition to better comprehensibility and confinement (suitable for the domain). The impact on changeability may be positive or negative as discussed below. Ryndina et al. write that there are two approaches for solving the horizontal consistency problem between two diagrams [P31] . One is to determine the overlap between two given diagrams where consistency conditions can be defined and checked. The problem with this approach is that the two diagrams are defined in two modelling languages and consistency conditions should be defined across language boundaries. The second approach is to generate one diagram from the other. With this approach, consistency conditions are defined between diagrams expressed in the same language. Figure X shows the two approaches applied on business process and object life cycle diagrams. The latter approach is beneficial according to the writers, as defining consistency conditions and interpreting inconsistencies between two diagrams in the same language is easier than across language boundaries. A prototype tool can verify that consistency conditions are held. Haesen and Snoeck have proposed to use the observer pattern to achieve consistency between different views in conceptual models: as the user changes a specification in one view, all other views are informed about the modification [P11] . For example the command of adding an object type creates the object type and the default finite state machine for that object type. As a result, the developer will initially receive a ready-made default finite state machine in which (s)he can add, modify or delete states and transitions to model the behaviour. This is an example of achieving consistency by construction using their terminology.