DEVELOPMENT OF MBSE/UML MATURITY MODEL

Transcription

1 DEVELOPMENT OF MBSE/UML MATURITY MODEL ÖZLEM DEMIRCI MASTER THESIS 2010 INFORMATICS

2 DEVELOPMENT OF MBSE/UML MATURITY MODEL SUBJECT INFORMATION TECHNOLOGIES AND MANAGEMENT IN INFORMATICS DEVELOPMENT OF MBSE/UML MATURITY MODEL ÖZLEM DEMIRCI This exam work has been carried out at the School of Engineering in Jönköping in the subject area IT and Management in Informatics. The work is the two-year university diploma program of the Master of Science program. The authors take full responsibility for opinions, conclusions and findings presented. Examiner: Vladamir Tarasov Supervisor: Christer Thörn ii

3 Abstract Abstract Model Based Software Engineering (MBSE) is becoming popular in the industry today. Many organizations, also including small and medium scales organizations are adopting modeling approaches. Models are becoming the main artifact of the software development process and they provide organization to test their product and detect problems before the implementation. UML (Unified Modeling Language) is the most common modeling language that is used by organizations during modeling process so that focus is on UML in the organizations. Therefore organizations that are developing software products in the sense of MBSE and using UML as a main modeling language are the interests of this paper. These organizations that are performing modeling approaches are not aware of how advanced or un-advanced they are performing the related modeling approaches during model based software development process. They are unaware of measuring and evaluating their modeling practices. This is because of lack of standards and guidelines regarding model based software development. By considering this unawareness of organizations, various affects that can effect on model based development process are examined like modeling process, quality assurance techniques, personnel competence on modeling practices, training of personnel, design and structure of the UML Models, modeling tools, transformation issues, and syntax and semantic regulations of UML. These are considered as most essential aspects regarding the occurrence in literature. Regarding these aspects, a MBSE/UML Maturity Model is provided where 6 maturity levels regarding the aim of modeling within the organizations and aspects required to be filled out. Therefore this Maturity Model different than traditional software development maturity models consider various aspects at different levels of organization and consider models as the main development artifacts. The practices and tasks required to be performed are based on models and modeling approaches. This MBSE/UML Maturity Model provides both practitioners and researchers to evaluate and measure the proficiency of modeling approaches performed in the organizations. iii

4 Acknowledgments Acknowledgments I would like to thank my supervisor Christer Thörn at Jönköping School of Engineering for helping me to shape the idea behind this thesis work and supporting me every step of the research process. Thank You. iv

5 Key Words Key Words Model Based Software Engineering (MBSE), Model Driven Development (MDD), UML (Unified Modeling Process), Maturity Model v

6 Table of Contents Table of Contents 1. INTRODUCTION Background Problem Description Purpose Research Questions Topic Vocabulary Disposition THEORETICAL BACKGROUND Previous Research Models and Model Based Software Engineering (MBSE) Modeling Languages and UML Types of UML Diagrams UML Profiles OCL (Object Constraint Language) Meta-Model DSL (Domain Specific Language) Maturity Model METHODOLOGY Data Sources vi

7 Table of Contents 3.2 Data Collection Data Analysis Maturity Model Development Method Quality of Science EVALUATION OF MBSE/UML APPROACHES AND DEFINITION OF ASPECTS Quality of UML Diagrams in Modeling Evaluation Criteria for MBSE/UML Maturity Model Essential Aspects for MBSE/UML Maturity Models Indicators for Each Aspect in MBSE/UML Maturity Model Different Levels of Organization for MBSE/UML Maturity Model The General Matrix for MBSE/UML Maturity Model MBSE/UML Maturity Model MBSE/UML Maturity Model Structure and Levels MBSE/UML Maturity Level Dimension Maturity Level 0: No Modeling Maturity Level 1: Basic Modeling Maturity Level 2: Initial MBSE/UML Maturity Level 3: Defined MBSE/UML Maturity Level 4: Integrated MBSE/UML Maturity Level 5: Optimized MBSE/UML vii

8 Table of Contents 6. Assessment of Maturity Levels of MBSE/UML Maturity Model VALIDTY OF MBSE/UML MATURITY MODEL CONCLUSION REFERENCES APPENDIX Appendix 1: MBSE/UML Modeling Process Evaluation Questionnaire Appendix 2: MBSE/UML Quality Assurance Techniques Evaluation Questionnaire Appendix 3: MBSE/UML Personnel Competence Evaluation Questionnaire vol Appendix 4: MBSE/UML Personnel Competence Evaluation Questionnaire vol Appendix 5: MBSE/UML Tools Evaluation Questionnaire Appendix 6: MBSE/UML Design Evaluation Questionnaire Appendix 7: MBSE/UML Syntax and Semantic Evaluation Questionnaire Appendix 8: MBSE/UML Transformation Evaluation Questionnaire viii

9 Table of Figures Table of Figures Figure 1 A sample framework for MBSE/UML Maturity Model... 4 Figure 2 Disposition... 6 Figure 3 MDD Adopting Spectrum, adapted from [1] Figure 4 Krutcher 4+1 view model Figure 5 Sample Creating a New Blog Account Use Case Diagram [11] Figure 6 Sample Activity Diagram [11] Figure 7 Sample Class Diagram for Blog Account Figure 8 Example of UML Profile Figure 9 Sample OCL example for UML Profile colors [39] Figure 10 Followed Data Analysis Steps Figure 11 Maturity Model Development Steps Figure 12 A Sample Declaration of Internal and External Stakeholder Figure 13 A Sample ATM UML Use Case Diagram Figure 14 Effects of Crossing and Bends [22] Figure 15 The Structure of MBSE/UML Maturity Model (adapted from [47] and [48]) Figure 16 MBSE/UML Maturity Model Levels ix

10 INTRODUCTION 1.INTRODUCTION 1.1 Background My method is different. I do not rush into actual work. When I get a new idea, I start at once building it up in my imagination, and make improvements and operate the device in my mind. When I have gone so far as to embody everything in my invention, every possible improvement I can think of, and when I see no fault anywhere, I put into concrete form the final product of my brain said Nikola Tesla. And in software engineering similar method has recently been widely used. Nikola Tesla did not talk about the use of modeling as a process in software development, but the idea can be considered more or less as same. Even though models are been used in the software industry for a long time, the activity of using modeling as a process in software development has recently become widespread since the need to abstract the system and its behaviors have been considered by both researchers and practitioners. Software engineers did not start development by implementation of code phase in software life cycle, including steps like requirement specifications, analysis, design, implementation and maintenance. The aim of these processes is to improve the productivity and to solve possible problems at early stages of development. By applying the principles of Model Based Software Engineering (MBSE) where the models are developed as solutions for particular problems during software development process, these aims can be achieved much easier. For instance, if the modeling is performed in an advanced way it is possible to detect errors early in the development life cycle or to test the software models before the implementation is executed. Modeling can be performed for different applications in software development. Besides the large scale enterprises, both medium and small sized enterprises are also interested in modeling. Due to the wide application of modeling, numerous informal and formal approaches to modeling have been developed, such as Entity Relationship Diagrams (ERD) for modeling data, Specification and Description Language (SDL) for modeling telecommunication systems, formal modeling languages such as Z and B, and the Unified Modeling Language (UML) which is the modeling language most widely used in industry today [1]. Modeling a system is not simple. There are various affects and aspects need to be considered. For instance, modeling a large scale system is complex since it isn t possible to model some of the aspects and elements of such a system because of lack of modeling approaches and a single modeling language. Moreover, based on literature review, it can be stated that there exists no single modeling language that can cover all the needs to model a system. However, UML (Unified Modeling Language) that is proposed by OMG is the most common modeling language used in industry and also an interest of researchers. Modeling language is the core of 1

11 INTRODUCTION using modeling as a process. Therefore the syntax need be well defined and regulated. What we mean by syntax here is the rules, regulations, and notations to describe a modeling language and semantic is the meaning of expressions stated in the language. In addition to these, modeling requires a good quality of design since there exists both technical and untechnical people, so the design of the models should be clear and comprehensible. The modeling process need to be well documented and the participants in this process need to be well trained and skilled. All these issues are considered by the industry but sometimes they do not give that much importance to one or more of these. Since this is a new field, a proper, qualified, and sufficient approach to adopt this new process do not exist. Therefore, in this thesis a maturity model for modeling approaches in organization is presented by indicating the aspects that need to be considered at different levels of abstraction. Moreover, the activities and tasks that needs to be performed in order to use modeling as a process in an advanced way is provided. A focus on UML is provided in this thesis since it is the most common modeling language in the industry. The maturity model provided here includes some levels for the proficiency of the organization using modeling approaches and UML together. The goal of this maturity model is that an organization and also researchers can assess their proficiency level regarding their modeling approaches and can get knowledge what else they need to do in order to perform modeling approaches in an advanced way. 1.2 Problem Description Regarding the popularity of adopting these new approaches and advantages of modeling, organizations are started to implement these modeling practices and activities. They face with lack of standardization on MBSE approaches and lack of standardization on modeling languages that required to be used while adopting modeling approaches, and several other lacks, insufficient issues, and problems. Organizations that adopt these MBSE approaches are aware of how advanced they are performing and what they need to do in order to improve their modeling practices. In other words, they adopt modeling approaches, but do not know how to evaluate and measure themselves with respect to their practices regarding their organizational and modeling goals. This leads to problems and discussions on how they can improve their modeling practices. There exists several studies on Model Driven Development and models such as quality goals that need to be achieved, the lacks of modeling languages utilized in adopting modeling approaches, different and various issues having an impact on modeling process, and other researches related to on this field. All this researches are essential for people and organizations that are involved in adopting modeling approaches. The existing maturity models and/or frameworks are developed for traditional software development processes, so organizations which are dealing with MBSE are aware of how mature they are applying these modeling approaches within their organizations. For instance, CMMI (Capability Maturity 2

12 INTRODUCTION Model Integration) - a maturity model proposed by SEI (Software Engineering Institute) describes process improvement activities required to be performed within the organization. SPICE (Software Process Improvement and Capability Determination) is also supporting continuous process improvement activities required to be performed within the organization. Both are developed for traditional software development process so they are not providing and/or supporting activities and tasks required to be performed in order to improve the proficiency of model based approaches. There is a research going on developing a Model Driven Development (MDD) Maturity Model within the MODELWARE 1 project which is taking CMMI as basis and reference so that only process improvement activities are considered. Moreover CMMI is too complex for many small and medium size organizations. Therefore this maturity model can be perceived as too complex for small and medium size organizations as well. When these factors and problems are taken into consideration, it seems useful to be able to evaluate the proficiency level of organizations modeling approaches utilization with regard to the best practices of the organization and the insufficient practices of the organization. An improvement on model based approaches can be provided. 1.3 Purpose The goal of this master thesis is to develop a maturity model for measuring and evaluating the level of MBSE/UML proficiency in an organization. As discussed in previous section (1.2) MDD is becoming popular in the industry. However, any standards for proficiency in using modeling approaches do not exist. As mentioned previously, there exists several maturity models and each measures and evaluates different aspects at different levels. However, the aspects that they evaluate are specific and mostly only one aspect. Moreover these existing maturity models are developed for traditional software development process so that the tasks and activities that need to be performed differ from MDD where the models became the key artifact of the process. Therefore, this thesis aims to develop a maturity model that evaluates and measures the different aspects of MBSE/UML at different levels of organization like individual, team, etc. Considering that both practitioners and researchers are interested in to evaluate the proficiency level of adopting modeling approaches within the organization, these both parties will be able to benefit from the outcomes of this thesis. The practitioners will be able to examine their modeling practices and the results for their practices so that they will know what they are doing at advanced level, what are the best practices of them, and what they need to do in order to improve. Like CMMI, a different way to improve the development practices and tasks will be shown in this thesis. The researchers will also have benefit from this thesis. 1 MODELWARE is a project co-funded by the European Commission under the Information Society Technologies Sixth Framework Programme ( ). 3

13 INTRODUCTION They will be aware of what practices and tasks an organization should consider while adopting modeling approaches. Researchers will be able to examine the best practices, evaluation methods of proficiency of modeling approaches, and essential aspects that need to be considered during MDD process. The outcomes and results are; A maturity model for MBSE/UML approaches with a description of aspects and levels that are targets for evaluations like shown in Figure 1. Figure 1 A sample framework for MBSE/UML Maturity Model Sets of instruments for how to perform the evaluations (ex: questionnaires, experiments, etc.) A review of existing approaches to maturity in models, evaluations, etc. 1.4 Research Questions Even though the aim of this thesis is to develop a maturity model for evaluating the proficiency usage of modeling approaches, the work was guided by research questions. With these research questions, it is possible to assign and decide the important aspects, practices and tasks that require to be performed during modeling. RQ1: What model quality goals are important in MBSE approaches that use UML as a core modeling language? RQ2: How to evaluate the quality and proficiency in usage of UML and MBSE approaches during a software development process? 4

14 INTRODUCTION The results that emerge from these research questions enable us to develop the criteria for different aspects at different abstraction levels of modeling process in order to evaluate the proficiency of modeling approaches applied in the organizations. 1.5 Topic Vocabulary Many abbreviations are used in this paper so here the most used abbreviations are presented below. MDD= Model Driven Development MBSE= Model Based Software Engineering MDA= Model Driven Architecture MBD= Model Based Development UML= Unified Modeling Language OCL= Object Constraint Language 1.6 Disposition This thesis is divided into 8 chapters which is shown and described briefly in Figure 2 below. A general knowledge is provided about the thesis and related topics like MBSE, UML, and maturity models so that the reader can become familiar with the rest of the paper. The methodology chapter provides the research process of the thesis, how data is collected and what kind of data is collected so that the reader will be able to understand how the research is performed. The rest of the chapters are about the findings from the data sources and analyzing them according to the purpose of the thesis. In chapter 4, the results for the research questions are provided. Moreover how these results are analyzed can be also read in chapter 4. These results constitute the key areas of the topic. A MBSE/UML Maturity Model is provided in chapter 5. The development of that is based on the findings from chapter 4, previous studies, and previous research performed on this field. Then in chapter 6, it is defined how the maturity of organization will be assessed so that the instruments designed for this aim is presented there. Chapter 7 indicates how the MBSE/UML Maturity Model will be validated. Chapter 8 concludes all tasks performed for the thesis. 5

15 INTRODUCTION Figure 2 Disposition 6

16 THEORETICAL BACKGROUND 2.THEORETICAL BACKGROUND 2.1 Previous Research Previous research on this field in the industry is mostly addressing the model quality goals that are required to be considered in order to develop good quality models since models are the main artifacts of the MDD process. For instance, Definitions and approaches to model quality in model-based software development, Parastoo Mohagheghi et al. [1] examines various articles published on quality of models and define 6C model quality goals (correctness, completeness, consistency, etc.) for model quality that is commonly used in the industry. In [22] the authors define model goals regarding UML structure and MBSE principles. They define different model characteristics, different modeling purposes, and relationships among them. Then they provide a UML model quality framework for different phases of software development process. Moreover, in article [9] it is indicated that model quality goals require to be defined properly while adopting MBSE principles. [23], [8], [7], [24], and [5] are other researches that deals with model quality goals. The common thing of these researches is all state that model goals are essential and require to be defined. Moreover they all indicate that UML s semantic structure is lacking when a MDD process is considered. Defining the model quality goals is not adequate. It has to be supported by providing some metrics and measurement techniques so that they can be measure and evaluate if the developed models meet the model quality goals or not. [25], [26], [27], [5], [50], [29], [30], and [31] provide some metrics that can be applicable to measure and evaluate whether the model quality goals are met or not. For instance, Baroni et al. [30] emphasize on defining metrics by using OCL (Object Constraint Language) for UML model quality. Lange [5] defines metrics and rules. He also defines model quality characteristic and modeling purposes. Then he relates them to each model quality characteristics regarding the modeling purposes. His consideration is related to UML model quality which is the same aim as this thesis. Since MBSE is not only developing models for communication, analysis, and prediction but also for transformation and code generation. Therefore, the requirements for developing models as solution and implementation source require additional activities and tasks to be performed. Moreover many researches [1], [5], [7], and [8] indicate that UML s lack of semantic is an issue required to be considered while adopting MBSE principles so the concepts like Meta-Modeling, UML Profiles, OCL, and DSL (Domain Specific Languages) come up. For instance [32], [33], and [34] emphasizes on meta-modeling and [32] provides a simple meta-model developed for modeling the blueprints of a software system. With respect to the research on model quality, some experiment and case studies show that while adopting modeling approaches, defining the model quality goals and measuring them are not the only issues require to be performed. For instance, [35] is a case study that 7

17 THEORETICAL BACKGROUND examines the Motorola s MDD process and encounters some issues like lack of common tools, lack of abstraction, lack of well-defined semantics, lack of integrated and migration tools, lack of team experience on modeling, ill-defined processes, and so on. Moreover it states that Motorola is developing a Modeling Challenge Levels to provide guideline for MDD process adoption. In addition to these, Parastoo Mohagheghi et al. [36] examines two organizations that are adopting MDD and states that because of lack of standards, guidelines, and ill-process definitions, organizations are faced with several problems. The author of [37] also states the issues require to be performed properly like process definition, training of personal, maturity of modeling technology and maturity of model related methods. The common of these case studies and experiment reports is that organizations adopting MDD are unaware of how mature they are performing these activities and tasks. For this issue, there is only little research [2] performed as mentioned previously. 2.2 Models and Model Based Software Engineering (MBSE) It is quite better to know and understand what is model at first. Models are representations of a (software) system at an abstract level [10]. A model tries to capture and present a specific aspect of a system so that only the information related to this aspect is represented. A model can consist of several diagrams in order to represent the part of system clearly. For instance, UML 2.0 proposes 13 different diagrams and each is described for various usages and representation styles (will be discussed in 2.2 Modeling Languages and UML). These various types of diagrams provide modelers and/or designers to develop the models at different abstraction levels by describing different features and representations of the system so that everyone involved in the development process can understand what is required and described, and essentially the roles assigned. The aim of using models differs and there exist many ways of using models so the requirements to describe and develop the models also differ. Models can be used to test the parts of the system before implement it so that the productivity can be improved. Moreover models can be used to provide a clear and coherent communication between stakeholders, clients, programmers, and so on; or the other field that models used is to present the integration and interoperability of distributed systems. In MBSE, they are aimed to perform transformation and achieve code from the models. The Figure 3 below shows the adoption of modeling within the organization by indicating the different aims of it. For instance, if the organization aims to implement the code from the models, the requirements for the code, transformation, and transformation tool that need to be considered and presented in the models. Let us assume that an organization will develop software programmed by C++, so the object-oriented requirements that need to be captured and the models should be developed based on this. Therefore the concepts like inheritance, classes come up and a specific part of 8

18 THEORETICAL BACKGROUND the system requires to be developed regarding this structure. Consequently, there exists different ways, aims, and different domains that models are presented. All these fields that models used indicate us that models have been used in software engineering world for a long time. They mostly have been used at the analysis and design steps of software development life cycle in order to describe the problem and requirements but solutions. Now by the proposition of MDD, the models became main artifact of software development process and they are intended to be developed as solutions. After understanding what is model and for what aims they are mostly used in industry, now it will be clearer to understand what MBSE and MDD are. There exist several names for those concepts. Some states that Model Driven Engineering (MDE) rather than MBSE; and some utilize Model Based Software Development (MBSD) or Model Based Development (MBD) rather than Model Driven Development (MDD). In this paper, we will use MBSE and MDD in order to decrease the complexity of existing terms. In article [11], model based software engineering is defined as performing software engineering on the level of abstraction and the authors simply define MBSE as the functionality of the system is presented by the models where the implementation details are hidden. In article [13], the models are described as a main artifact in the software development and they define MBSE as Model-based software engineering covers software development methods, where models are the main artifacts and some or all other artifacts are derived from the models [13]. The main difference between traditional software development and model based development is that models are the artifacts in the model driven development. The authors in [1] indicates that MDE (Model Driven Engineering) covers approaches where development is carried out using models; often at different abstraction levels and from multiple views; and they also focuses on that the models are the core sources in order to perform transformations. That basically means that models can be used to develop other models or either way to develop the source code. 9

19 THEORETICAL BACKGROUND Figure 3 MDD Adopting Spectrum, adapted from [1] Model Driven Development (MDD) approaches are used in the paradigm of MBSE. In MDD, the complexities of the large software systems are handled by raising the level of abstraction. [14] MDD is defined as a software engineering approach consisting of the application of models and model technologies to raise the level of abstraction at which developers create and evolve software, with the goal of both simplifying (making easier) and formalizing (standardizing, so that automation is possible) the various activities and tasks that comprise the software life cycle. In article [15], the authors are also defining MDD as model based software engineering approaches where the parts of the software development process are executed automatically using model transformations. In this thesis, the common way of using MBSE and MDD approaches is to evaluate the usage, adopting proficiency of these concepts in the industry so that the proficiency is dependent on the different usage principles of these approaches and models regarding different domains and contexts. The criteria, the evaluation methods, and best practices that need to be applied will be discussed later in this thesis. 2.3 Modeling Languages and UML Since modeling is being used in different areas; there exist many modeling languages and standards. Majority of them emphasizes on graphical notation because modeling is considered as a graphic. However, a modeling language can also be textual. In addition to these some of the modeling languages are executable so that a source code can be generated from the models. Therefore, regarding the type and aim of modeling language, the set of rules and structure of them differ. For instance, a graphical modeling language consists of set of diagrams and a set of rules exists to indicate the relationship between diagrams. The modeling approaches require a modeling language as it mentioned previously and modeling language provides standards, a set of rules, and conventions in order to improve the 10

20 THEORETICAL BACKGROUND quality and develop models. At that point, UML which is the de facto Standard for modeling software systems in industry is considered since when adopting modeling standards and guidelines within an organization the first goal is to settle a common notation as Scott W. Ambler stated in his book The Elements of UML style [38]. He states that at that point UML is a good start since it defines a common notation and semantics. Moreover OMG (Object Management Group) 2 states that modeling is the designing of software applications before coding and using a model, those responsible for a software development project's success can assure themselves that business functionality is complete and correct, end-user needs are met, and program design supports requirements for scalability, robustness, security, extendibility, and other characteristics, before implementation in code renders changes difficult and expensive to make. OMG s UML helps to specify, visualize, and document models of software systems, including their structure and design, in a way that meets all of these requirements. The utilization area of UML in the industry is wide. UML models are used at several stages during software engineering, such as the early analysis of the problem domain, documenting the architecture or specifying the detailed design of a system. The abstraction level of the used models varies for the different stages. A UML model serves one or more specific purposes depending on the development stage and the stakeholders who are using the model [5]. Moreover, in the book Learning UML 2.0 [11] authors mention the quotes of Fowler who identifies the usage of models (UML models) in a precise way and states that UML models used in industry are assigned to three different roles which are; UML as Sketch: The models are designed to represent the communication rather than describing the system specifications so that if the organization is using the UML models as a sketch than the models that need to be understood and agreed by all users. The models need to be comprehensible. UML as Blueprint: UML models are designed detailed and provide detailed information for the programmers to develop the code. Therefore the UML models need to be correct and complete. UML as Programming Language: UML models are designed and developed as executable. The focus and the aim is developing models first and then implementing them into the code by using transformation tools

21 THEORETICAL BACKGROUND Types of UML Diagrams The latest version of UML which is UML 2.0 consists of 13 different diagrams and each has different purposes. However, some are related to each other. For instance, the class diagrams are used to show the static design view of a system while sequence diagrams are used to show the interaction between the objects. Russell Miles and Kim Hamilton in their book Learning UML 2.0 [11] mentions the views of UML diagrams on overall and he focuses on the views defined by Philippe Kruchten s 4+1 view model where a model is broken into several views and each view captures specific aspect of the system that is modeled. As shown in Figure 4, the views are logical, process, development, physical, and use case views. Figure 4 Krutcher 4+1 view model The Table 1 below provides basic description about Krutchen s 4+1 view model and example UML diagrams. Table 1 Krutchen s View Model Description View Type Description UML Diagram Logical View System s parts and how they interact each other are described. Class, Object, State Machine, and Interaction Diagrams Process View The steps and/or tasks of the processes are described. Activity Diagrams Development The system s parts organization into modules and components is Package and Component 12

22 THEORETICAL BACKGROUND View described. Diagrams Physical View How the final deployed system is performed regarding to the 3 other views of the model is described. Deployment Diagram Use Case View What the systems should do from the outside perspective is described. Use Case, Description, and Overview Diagrams OMG also identifies different perspective of UML diagrams. They provide 3 different perspectives which are shown and described in Table 2. Table 2 UML s Types of Diagrams by OMG Types of Diagrams Example UML Diagrams Structural Diagrams Class Diagrams Object Diagrams Behavioral Diagrams Use Case Diagrams Sequence diagram Collaboration diagram State-chart diagram Activity diagram Implementation Diagrams Component diagram Deployment diagram 13

23 THEORETICAL BACKGROUND As mentioned previously, even though each diagram is developed for different aims, while modeling a system these diagrams indicate different issues of the system regarding the other developed UML diagrams. For instance, let us assume that a modeler is developing a model which is representing a blog page which allows users to have a blog account in order to post some entries. The Figure 5 simply illustrates the use case diagram of such a system including the actors and what they can perform. This use case diagram can be thought as a tool to provide communication with the client so that the client will be able to comprehend what the software product will do. In MBSE, UML diagrams are also used to provide specific features of the system and/or the software product that will be produced. These specifications will provide developers to comprehend the problem and then how it is required to be solved. When the example of blog page system is considered, the UML activity shown in Figure 6 simply illustrates how the tasks and/or activities of development process will be done. It shows how a decision will be performed when activities are depending on a condition. For instance, in this example it can be considered as when a blog account user intends to add a new entry, there are some limitations to publish his/her entry. It is assumed that if the entry is longer than 1000 words then it exceeds the word size limit or if the entry is empty then it cannot be published either. Figure 5 Sample Creating a New Blog Account Use Case Diagram [11] 14

24 THEORETICAL BACKGROUND Figure 6 Sample Activity Diagram [11] Russell Miles and Kim Hamilton states that in their book Learning UML 2.0 [11] Use cases describe the behavior of your system as a set of concerns. Classes describe the different types of objects that are needed within your system to meet those concerns. [11] Regarding this statement, a sample class diagram of blog account example is shown in Figure UML Profiles Figure 7 Sample Class Diagram for Blog Account It is not necessary to define a new language in order to add some constraints or add new UML elements by the proposition of UML profiles by OMG. This feature allows customizing the UML elements such as adding new elements, defining restrictions or constraints. In [39] authors define UML profiles as set of extensions supporting customizations by using UML s 15

25 THEORETICAL BACKGROUND extension mechanisms. By this feature developers are enabled to develop UML models in particular domains. OMG also defines UML Profiles in Catalog of UML Profile Specifications 3 as A UML profile is a specification that does one or more of the following Table 3 : Table 3 UML Profile Specification by OMG adapted from Catalog of UML Profile Specifications Identifies a subset of the UML meta-model. Specifies well-formedness rules beyond those specified by the identified subset of the UML meta-model. Well-formedness rule is a term used in the normative UML meta-model specification to describe a set of constraints written in UML s Object Constraint Language (OCL) that contributes to the definition of a meta-model element. Specifies standard elements beyond those specified by the identified subset of the UML meta-model. Standard element is a term used in the UML meta-model specification to describe a standard instance of a UML stereotype, tagged value or constraint. Specifies semantics, expressed in natural language, beyond those specified by the identified subset of the UML meta-model. Specifies common model elements, expressed in terms of the profile. There exist already defined UML Profiles such as UML Profile for CORBA for CCM (CORBA Component Model) or UML Profile Scheduling. For instance, defining UML Profile for CORBA is intended to be developed in order to be able to model CORBA interfaces which support expressing the semantics of CORBA in UML tools also being able to perform transformations from the models. However, organizations by themselves are also allowed to define UML Profiles regarding their need. For instance, [39] provides a UML Profile for MultiTEL (Multimedia Telecommunication Services) in which UML Profile provides a standard way for designing and documenting systems and application frameworks. 3 Catalog of UML Profile Specifications by OMG 16

26 THEORETICAL BACKGROUND Another UML Profile example is provided by [39] which is a simple example that aims to add two new elements named weights and colors as shown in Figure 8. Figure 8 Example of UML Profile OCL (Object Constraint Language) OCL is provided by OMG as a modeling specification and OCL is a formal, declarative language that is used to provide expressions to UML models. In another way it can be defined as specification of formal constraints in context of a UML model. OCL provides a set of rules that applicable to UML models. The specifications of constraints are essential since pre- and post-conditions of operations, invariants, derivation rules for attributes and association etc. are expressed by constraints. Moreover the restrictions are defined by constraints. Any kind of UML element can be related with constraints including the UML Profiles that are defined for new elements. The aforementioned example for adding two new elements which are weights and colors, the authors of [39] indicates that only classes and associations can be colored. As a result for this constraint, the following OCL shown in Figure 9 is derived by [39]; 17

27 THEORETICAL BACKGROUND context UML::InfrastructureLibrary::Core:: Constructs::Association inv : self.isstereotyped( Coloured ) implies self.connection->forall (isstereotyped( Coloured ) implies color=self.color) Figure 9 Sample OCL example for UML Profile colors [39] Meta-Model A meta-model is a model describing the model. Meta-models capture the different aspects of the system and make different models to follow the same guideline so that all models describing the system achieve consistency. The authors of Meta-Modeling Semantics of UML[4] states that The UML semantics is described using a meta-model that is presented in terms of three views: the abstract syntax, well-formedness rules, and modeling element semantics. Moreover OMG presents MOF (Meta Object Facility) 4 which is a standard used to define the UML meta-model. It is required to extend the UML meta-model because of its syntax and semantic lacks. Therefore, MOF is used for this issue. Therefore meta-modeling is a technique used to provide descriptive modeling language rules by aligning formal semantics to UML. 2.4 DSL (Domain Specific Language) DSL is a form of computer languages that are dedicated to a particular domain. Martin Fowler 5 describes it as The basic idea of a domain specific language (DSL) is a computer

28 THEORETICAL BACKGROUND language that's targeted to a particular kind of problem, rather than a general purpose language that's aimed at any kind of software problem. If the wide application areas of modeling approaches are considered, it can be achieved that DSLs provide better understanding for different domain problems since each domain has different requirements and features need to be considered. 2.5 Maturity Model A maturity model provides a systematic framework to assess how mature the organizations are developing software products where maturity is defined as developed fully by Oxford Concise Dictionary. Therefore the purpose of a maturity model can be described as identifying the capabilities and approaches of organization that will allow them to manage their different processes like personnel competence, test, software development processes more reliable and successful. There exists several maturity models proposed for different issues related to software development process in software industry. For instance, there are maturity models developed by concerning the software process quality like CMM (Capability Maturity Model), CMMI (Capability Maturity Model Integration) 6, SPICE 7 (Software Process Improvement and Capability Determination), and so on. In software industry, there also exists maturity models developed for assessing the maturity level of project management, test processes, architecture, personnel competence, and so on. All these maturity frameworks have common issues as described by Information Technology and Telecommunications SIG 8 as following; They describe a number of discrete stages, or levels where each level represents a progression of overall maturity of the organization. The CMM, and many other models, are comprised of five levels, from an ad hoc, non-repeatable process (level 1) to an exceedingly mature, robust and tightly structured capability (level 5). They are comprised of a number of capability areas. They explore a set of practices that together collectively define how the overall discipline They tend to be organizationally focused. While not processes or process frameworks, they are prescriptive of the processes that an organization should adopt. In summary, they are developed to assess the maturity level of organizations on specific tasks

29 METHODOLOGY 3.METHODOLOGY A systematic and planned research support finding and getting reliable answers. By keeping the academic work structured and systematic, the readers will be able to understand the whole work easier. Moreover, the reliability of the results will be achieved. 3.1 Data Sources Data sources are the carriers of data (information) [16]. There exist two types of data sources which are secondary data and primary data. Secondary data are information collected by others for purposes that can be different from ours. Primary data are original data collected by us for the research problem at hand [16]. In this thesis, secondary data collection is performed since the sources of primary data like communication, experiments, and observations are not performed because of time limitations. However, secondary data sources provided and supported essential and sufficient data to get the reliable results. MBSE is a new concept in software engineering. Therefore knowledge about its features, characteristics, and how it is performed in the industry were required in order to understand the whole concept. Moreover, since this thesis s focus is on UML diagrams usage in MBSE and UML is known as its complexity because of the multi diagrammatic architecture, UML by its variety of characteristics and usage fields that need to be examined properly. Therefore these two knowledge requirement leaded to perform a research by the process of reviewing literature from previous researches and books published. In order to get these publications, reliable secondary data sources such as databases exist in Jönköping University Library are scanned by some keywords. Therefore many publications like e-books and books, academic articles, course notes, case studies, and experiment reports are scanned. Moreover since UML is proposed by OMG, the OMG web-site was also another secondary data source that examined frequently. Any experiments or interviews are not handled during thesis but existing experiments and case studies that are performed by others were interest of the this thesis in order to get answers for the research questions defined in section 1.4. All these findings are analyzed regarding on mostly research questions so that efficient and sufficient results are achieved. For instance, the model quality goals and evaluation of them supported to determine the best practices at different levels of abstraction. 20

30 METHODOLOGY 3.2 Data Collection Data sources that are performed in this thesis were secondary data. Therefore qualitative methods are performed. In qualitative research, the findings are not arrived at by statistical methods or other procedures of quantification [16]. Even though many researchers believes that quantitative research is more suitable or scientific; there are some says that methods and/or techniques can be more scientific and better, it just depends on what the researchers are looking for and how they will be able to get results for their research questions. Therefore as long as everything is performed in a systematic way, the results will be sufficient and reliable. 3.3 Data Analysis In order to analyze the collected data, content analysis method is applied during this process. Klaus Krippendorff [40] defines content analysis as an empirically grounded method, exploratory in process, predictive or inferential in intent. Also Robert P. Weber [41] states that content analysis is a research method that uses a set of procedures to make valid inferences from text. The most essential step of qualitative content analysis approach is to make categorization. In [42] the author briefly indicates that categories are in the center of analysis and the aspects of text interpretation, following the research questions, are putted into categories, which were carefully founded and revised within the process of analysis [42]. In this thesis, the aim is to be able to define the most essential aspects regarding the MBSE/UML principles within the organization. Therefore, measuring the occurrence of these factors in the literature (conferences, workshops, experience reports, empirical studies, and case studies) will provide to make determination of these aspects to be evaluated within the proposed MBSE/UML Maturity Model. In order to achieve this, the process shown is Figure 10 is followed. 21

31 METHODOLOGY Figure 10 Followed Data Analysis Steps 3.4 Maturity Model Development Method While developing a maturity model, seven guidelines of [51] is considered as basis in order to be able develop a reasonable and usable maturity model. Design science addresses research through the building and evaluation of artifacts designed to meet the identified business need [51]. Design science aims at the improvement of problem-solving capabilities by creating innovative artifacts, such as constructs, models, methods and instantiations [52]. Therefore, developed maturity models require to be considered as innovative artifacts while assessing the proficiency of organizations model based development process. While adopting these guidelines in this thesis, some changes are done since this maturity model development process is supported by some research questions and literature review. The Table 4 below indicates the description of these seven guidelines that are adapted from [51] and descriptions of them in this thesis work. 22

32 METHODOLOGY Figure 11 Maturity Model Development Steps Results from the research questions and literature review conducted some of the steps of this design-science research. As mentioned in previous section, after the determination of aspects, organization levels, and indicators for model based development process. The maturity levels are conducted with respect to the organizations aim on model based development. This process is shown in Figure 11. Table 4 Design-Science Research Guideline (quoted from [51]) Guideline Description in General Description in This Thesis Guideline 1: Design as an Artifact Design-science research must produce a viable artifact in the form of a construct, a model, a method, or an instantiation A maturity model is developed as a viable artifact that provides an assessment of proficiency level of an 23

33 METHODOLOGY [51]. organization on model based development. Guideline 2: Problem Relevance The solutions should be provided for essential and relevant business problems. Essential aspects regarding the model based development are retrieved from literature review by underlying the occurrence of the aspects in literature. Guideline 3: Design Evaluation The utility, quality, and efficacy of a design artifact must be rigorously demonstrated via wellexecuted evaluation methods [51]. The results are required to be carried out with scientific methods. Guideline 4: Research Contributions Relevant contributions require to be performed in the design areas. Existing maturity models relevant with model based development require to be examined. Guideline 5: Research Rigor The selected methods require to be adjusted rigorously. The selected and used methods require being well-defined. Guideline 6: Design as a Search Process Solutions that are proposed should be developed, evaluated, and improved iteratively. Maturity Model requires to be developed step by step. Guideline 7: Communication of Research Design-science research must be presented effectively both to technology-oriented as well as A usability analysis after the development of maturity model requires 24

34 METHODOLOGY management-oriented audiences [51]. to be performed. 3.5 Quality of Science The method used in this thesis research is qualitative. Therefore, the reliability and validity of data collected and analyzed are more difficult than the quantitative research. However, performing a systematic review covers this problem and provides reliable and valid data. As described in previous section, identifying what exactly are we looking for from the answers of research questions makes the research question more structured. Therefore, the results gathered are certain. Then the measuring the occurrence of these data in the literatures ensures the reliability of the data collected since by applying content analysis, sort of quantitative data are collected from the qualitative research and at that point, the influence of case studies and experience reports support that data collected are based on some experiences and real-time issues. 25

35 EVALUATION OF MBSE/UML APPROACHES AND DEFINITION OF ASPECTS 4.EVALUATION OF MBSE/UML APPROACHES AND DEFINITION OF ASPECTS 4.1 Quality of UML Diagrams in Modeling Today s software systems are complex so modeling is considered to be performed more than sketches and blueprints and at that point UML s multi diagram architecture is also causing a complexity problems since some of the diagrams and semantic are not described properly. Therefore it is both complexes to model a large scale system and to use UML in this modeling process. In this thesis, we are looking at both UML and modeling concurrently so that the lacks that will be stated here will be based on using UML as a modeling language in modeling process. This is also interest of many researchers. However, the variety use of modeling approaches such as UML as blueprints, sketches, and programming language leads researchers to examine the UML quality in different modeling approaches. As it is also discussed and mentioned in articles [1], [17], [18], [5], [6], [4], [5] UML has lack of semantics and syntax regarding the transformation of software development artifacts from models. Therefore possible problems and defects arise in the models. For instance, the lack of formal syntax causes not to be able automated verification of design specifications. There exist several industrial experiences and researchers on semi-formal semantic and syntax structure of UML and some provides solutions to decrease the problems that occur because of these lacks. It is not only semi-formal structure of UML leads models to have problems, because of multi diagrammatic architecture of UML many researchers and practitioners state that this architecture structure leads inconsistency between diagrams in model. Moreover the interaction between diagrams also cannot be well described. In article [1], Parastoo Mohagheghi et al. define 6 classes of model quality goals shown in Table 5. 26

36 EVALUATION OF MBSE/UML APPROACHES AND DEFINITION OF ASPECTS Table 5 6C Model Quality Goals Model Quality Goal Description Correctness Including right elements and correct relations between them, and including correct statements about the domain [1] Not violating rules and conventions; for example adhering to language syntax, style rules, naming guidelines or other rules or conventions [1]. Completeness Completeness is defined as having all the necessary information that is relevant and being detailed enough according to the purpose of modeling [1]. Consistency Consistency is defined as no contradictions in the model [1]. Comprehensibility Comprehensibility is defined as being understandable by the intended users; either human users or tools [1]. Confinement Confinement is defined as being in agreement with the purpose of modeling and the type of system; such as including relevant diagrams and being at the right abstraction level. A model is a description from which detail has been removed intentionally [1]. Changeability Changeability is defined as supporting changes or improvements so that models can be changed or evolved rapidly and continuously [1]. 27

37 EVALUATION OF MBSE/UML APPROACHES AND DEFINITION OF ASPECTS In addition to these, the quality of models also depends on aesthetics, the layout of diagrams, the design, the tools used and so on. In this thesis, our aim is to provide a maturity model for evaluating the usage of modeling approaches so that our focus will be on these model quality goals too. These model quality goals will provide aspects that need to be considered during the modeling process and then how to achieve these goals or in which proficiency level an organization is performing these will be examined. 4.2 Evaluation Criteria for MBSE/UML Maturity Model In this section, the results for research question 2 How to evaluate the quality and proficiency in usage of UML and MBSE principles during software development process? is examined by literature review regarding UML new features, standards; and MBSE approaches. The results gathered provide decision making while determining the important aspects that require to be evaluated at different levels of organization. Different aspects are considered at different levels of organization since various aspects not only one have an impact on whole model based development process. Moreover while evaluating the proficiency of organization on modeling, these aspects require to be considered in order to support organizations to make improvements on their modeling practices. In addition to these, since one of the aims of this thesis is to evaluate various aspects at different levels of organization, in this section, brief information for levels of organization and aspects required to be considered for each level provided. Moreover, after determining the aspects and levels of organization; the indicators that will be evaluated and measured separately are considered and provided in this section Essential Aspects for MBSE/UML Maturity Models This evaluation criterion is important since MBSE approaches and UML are being used for different purposes in the industry. Some organizations are only applying these to be able generate code from the models whereas some are just using it to develop sketches. Therefore, the aim of performing MBSE approaches in organization will differ and requirements for this adoption will be different. Just to make this part clearer, a simple example can be provided. For instance, an organization adopts modeling in order to generate code from the models developed and the domain of the system is a defense system which requiring high security and safety. In order to manage this, the models that require to provide some implementation details and the tools that are used should be certified tools. On the other hand, let assume that another organization is only aiming to use MBSE approaches as sketches so they should not provide implementation details in their models; otherwise, their models will not be the ones to 28

38 EVALUATION OF MBSE/UML APPROACHES AND DEFINITION OF ASPECTS cover the organization s purposes so too much unnecessary work and time consuming will occur. During the writing of this thesis, the literature examined provided the necessary and essential aspects require to be estimated while adopting modeling approaches. According to [19], lack of process development definitions, lack of quality assurance activities, and the design of models cause a decrease on organization s improvements on models. In addition to these, based on the case studies performed, they found that the characteristics of the designer (modeler) like skills, motivation, and training has an impact on the quality of the models. Moreover, time pressure is also examined as another effect on quality of models. [43], [44], [45], [37], [4-3], and [19] also mention about importance of well-defined modeling process. For instance, the authors of [44] states that Processes must be generic enough to be shared and capitalized at company or department level, but must be customizable enough to be relevant at project level. Processes describe roles, activities and work products for each involved stakeholder. Moreover in [43] the authors also state that modeling process affects the quality of MBSE so that while evaluating the proficiency of organization on MBSE, the modeling process should be defined properly. The importance of utilizing a defined process in software engineering has been known for several years. However, most tried and tested processes are not tailored for MDE, which does not make any assumptions on the software development process or the design methodology [20]. In [43], [35], and [19] the effects of modeling language, the knowledge and skills of modelers, and the applied quality assurance techniques are also mentioned. For instance, based on [43] the used modeling language should be applicable with domain and should be able to represent the complexity of the system if it is complex. In article [35], team inexperience on modeling, modeling language used, and modeling tools used stated as a challenge while adopting MBSE within the organization. In addition to these, the article [46] focuses on the importance of transformation and examines the Motorola s experience on MDD. It indicates that the automatic generation of code from developed models requires UML profiles or DSL (Domain Specific Language). As mentioned several times in this thesis, UML s lack of semantic and syntax structure is another issue to be estimated. For instance, as indicated in [19], [3], and [14] in order to present and state the UML diagrams precisely a well-defined syntax and semantic is required. By defining these, the consistency and comprehensibility will be achieved. However, it is require to enforce the personnel who develops the models to follow these set of rules. 29

39 EVALUATION OF MBSE/UML APPROACHES AND DEFINITION OF ASPECTS Table 6 Number of Occurrences of Aspects in Literature Essential Aspects Occurrence in Literature Articles, Journals (n=31) Case Studies, Empirical Studies, Experience Reports (n= 21) Modeling Process Quality Assurance Techniques Personnel Competence 7 12 Tools Design 13 9 Syntax and Semantic Transformation In total 52 articles are examined while determining the evaluation aspects for MBSE/UML Maturity Model, the literature consists of two different parts. One is the articles that are research papers developed systematically; the others are the empirical studies like surveys, experience reports, etc. The Table 6 above shows the most occurred aspects regarding the literature review where UML is considered as a main modeling language in MDD process. The aspects stated in the Table 6 are same as the aspects that are determined as evaluation criteria for MBSE/UML Maturity Model. However, it is important to state that during the literature review if they are mentioned about the UML s lack of syntax and semantic, it is related to aspect named syntax and semantic. Or when Meta-Modeling, DSL, and UML Profiles are also categorized into syntax and semantic; and some are related to transformation aspect. This categorization depends on how these concepts are mentioned and discussed. Then these specific aspects like Meta-Models, DSL, and UML Profiles are utilized as indicators for each aspect. Therefore in this thesis, the focus will be on aspects which are modeling process, quality assurance, personnel competence, tools, design, syntax and semantic, and transformation shown in Table 7. 30

40 EVALUATION OF MBSE/UML APPROACHES AND DEFINITION OF ASPECTS Table 7 Definition of Aspects Aspects Modeling Process Definition Modeling Process can be defined as a set of steps that need to be followed during the development process considering the models are the main artifacts. These steps can be like planning, requirement specification, and model design like the ones in traditional software development process but regarding the models. Quality Assurance Techniques These are the techniques or methods that allow organization to measure its development practices and evaluate if the organization goals and model goals are gained or not. Personnel Competence Here personnel competence is considered as motivation of participants, the knowledge and experience of them, skills of them. Moreover if it is necessary, training activities need to be included. Tools Tools are used in modeling approaches and depending on the modeling aim of organization different types of tools are used. For instance, tools for graphical view, tools for automatic code generation. Design In this thesis, the design aspect represents the layout, aesthetics of UML diagrams and models. Moreover it also indicates the different models require to be developed such as requirement model, business model, domain model, and design model. Syntax and Semantic In this thesis, syntax is considered as regulations, notations, and rules used in order to describe a modeling language and semantic is considered as meaning of the expressions stated within the modeling language. Transformation In this thesis, transformation means being able to perform transformations from model to model, model to code, or model to text. 31

41 EVALUATION OF MBSE/UML APPROACHES AND DEFINITION OF ASPECTS Indicators for Each Aspect in MBSE/UML Maturity Model After defining the aspects, it will be clearer to examine how to evaluate these aspects. Based on the literature review performed, many researchers are discussing why these aspects are important to be considered and they only focus on these aspects separately. However, in order to measure and evaluate the proficiency of organization on modeling approaches all these aspects need to be evaluated so that organizations will be able to examine how advanced or un-advanced they are performing modeling approaches. In this thesis, for each aspect some indicators are defined to be evaluated. These indicators are the general titles and they consist of evaluation methods, some checklists, questionnaires, or interviews and so on. These evaluation techniques will be discussed later. Now the focus is on the main indicators that will be evaluated and will be evaluation criteria which are shown in Table 10 below. Modeling Process Because of lack of standardized model based software development process definition, organizations need to give importance to define a modeling process before they start adopting modeling approaches. The traditional software development processes can be considered and based on them; a new process for model based development can be defined regarding the main artifact as models. The defined modeling process should be applicable to the field that modeling will be performed. The standards, regulations need to be defined in order to avoid from inconsistency and controversy that can occur later in the development process. Moreover, the defined model based development process need to consider the modeling goals so that it is required to define the modeling goals and document them. In addition to these, it is important for organization to support and motivate staff to document everything regarding the standards so that the changes and/or regulations can be tracked and ordered properly. Personnel in the model based development process regarding their knowledge, skills, and experiments need to be evaluated since they are the ones who will develop the models and final product. Moreover, personnel should agree on the defined modeling process and feel confident with that. Therefore, it would provide an advantage if the personnel is also involved in defining the model development process. The modeling goals, the modeling process, and skills of personnel are considered but it is also necessary to define quality assurance techniques to be able evaluate the results. This will be examined with the quality assurance technique aspect. However, while defining the modeling process and modeling goals, quality assurance techniques also need to be considered. 32

42 EVALUATION OF MBSE/UML APPROACHES AND DEFINITION OF ASPECTS Model based development processes include many actors like stakeholders and personnel from different departments of organization and with different roles. Stakeholders can be both external and internal as shown in Figure 12. Figure 12 A Sample Declaration of Internal and External Stakeholder Each actor within the development process and organization is responsible of sharing knowledge with others and each has to consider the organization standards, regulations, and goals. For instance, each modeler can be responsible for different models but which are supplementary for others too. Therefore, each modeler should know each other s work and should provide consistency interaction and communication with each other. Let assume that a modeler is responsible for providing a use case diagram to show how the general project will work and this use case is based on the requirements of the external stakeholder who is client in this scenario. Let also assume that this sample scenario simply indicates how an ATM machine works as shown in Figure