Model-driven Development of Evolving Secure Software Systems Sven Peldszus University of Koblenz-Landau Koblenz, Germany speldszus@uni-koblenz.de Abstract—Software systems are continuously entering more To tackle these challenges, we started to develop the and more parts of our lives and have to deal with a higher GRaViTY framework [6]. This framework allows us to au- amount of sensitive data than ever before. At the same time, these tomatically create and maintain trace links between different software systems get more complex and have to be maintained over long periods. One approach to deal with the issues arising artifacts, such as UML models, Java source code, and program from these trends is model-driven software development (MDD). models for analyses, created during the development of a sys- Much research has been done on automating MDD approaches tem. Starting from early design-time models until the creation and integrating the different artifacts used. However, there are and maintenance of the code, this framework is intended still plenty of issues that have to be solved. In this work, we dis- cuss the three main challenges we discovered at the development 1) to maintain trace links between these artifacts, of our MDD approach GRAViTY. GRaViTY supports developers 2) keep all artifacts up to date if one artifact is changed, in the model-driven development and maintenance, and evolution 3) to specify security requirements on the most suitable of long-living secure software systems. Thereby, GRaViTY itself representation of a system, and leverages multiple MDD approaches. 4) to continuously check all system representations for se- Index Terms—model-driven development, software engineer- ing, evolution, maintenance, security curity violations. For solving this challenge, we mainly utilize bidirectional graph transformation approaches. In this work, we are giving I. I NTRODUCTION an overview of our solutions and discuss the three main challenges we faced: Modern software systems tend to be used on a long- term basis in environments prone to changes, are highly 1) Transformation between models with different granularity interconnected, are continuously extended with new features, 2) Incremental updates of abstract syntax trees (AST) and often process security-critical data [1], [2], [3]. These 3) Maintaining networks of transformations trends complicate to keep up with the ever-changing security In what follows, we introduce the relevant background on precautions, attacks, and mitigations, which is vital for pre- our assumptions about MDD as well as on security checks in serving a system’s security. Model-driven development (MDD) Sec. II. Afterward, in Sec. III, we give a brief overview of the enables us to address security issues in the early phases of the GRaViTY framework. In Sec. IV we discuss challenges we software design already, such as in UML models defined at faced, and present our solutions and challenges that have to design time [1]. Unfortunately, the specification of a system’s be overcome. How others dealt with the same challenges, is security assumptions and documentation is often inconsistent discussed in Sec. V. Finally, we conclude in Sec. VI. with its implementation [4]. The continuous changes in the security assumptions and the design of software systems – for II. BACKGROUND instance, due to structural decay [5] – have to be reflected in In this work, we present an approach for supporting devel- both the system models (e.g., UML models) and the system’s opers in the model-driven software development (MDD) of implementation (including program models used, e.g., for secure software systems. For explaining our approach and the static analysis or verification). challenges, that we identified during its implementation, in this The tracing between the different artifacts available for section, we introduce the underlying understanding of MDD deciding which change is necessary at which location in the and which artifacts we use as well as the different security system and on which of the many artifacts, has currently checks which are combined by our approach for enforcing the to be performed manually by developers. The effort for the development of a secure system. creation of such mappings after the fact is still high even if this process is guided by tool support, e.g., for the creation of A. Model-driven Software Development mappings between models and code [4]. For this reason, we In this work, we are building upon the concept of model- have to maintain mappings between different artifacts used driven software development (MDD) [7]. MDD allows devel- in the different phases of development from the very early opers to specify the system and its properties on a higher beginning and to automate them as much as possible. level of abstraction than the source code level [8]. Thereby, Copyright © 2020 for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0). Code OfficeVisitControl DiagnosisControl data UML UML UML + data: OfficeVisit [1] + data: Diagnosis [1] Domain Design Implementation «critical» Model Model Model + openNotesDialog() User + openHealthMetricDialog() + password: String [1] Fig. 1: Artifacts used in Model-driven Software Development + chooseHealthMetricRecord() + openPrescriptionDialog() + firstName: String [1] Control + lastName: String [1] + choosePrescriptios() +/ name: FullName [1] + openLaboratoryProcedure() + streetAddress1: String [1] <> + chooseLaboratoryProcedure() {secrecy={homeAddress : Address}} + finishModification() + city: String [1] + openPatientInstructionDialog() + state: String [1] Person + choosePatientInstruction() +/ name: FullName [1] + zip: String [1] + openDiagnoseDialog() +/ homeAddress: Address [1] + homeAddress: Address [1] + chooseProceduresDialog() LogInControl Patient Doctor + chooseImmunizationsDialog() + patients treats + openReferralDialog() + data: User [1] + allergies: String [*] * + specialities: String [*] + home() * + doctors + openHospitalDialog() + login() Patient Examination 1 + patient 1 + patient 1 + doctor * + doctors + openAppointmentDialog() + resetPasswort() * + examinations + billing() + chooseUser() + examinations * 1 + examination + diagnosis 1 Fig. 3: Excerpt of a Design Model for iTrust based on [3] Diagnosis + diagnosis + diagnoses * * platform, e.g., a login control, a control for documenting an Fig. 2: Excerpt of a Hospital Domain Model based on [11] office visit or for entering a diagnosis, as well as a more detailed data structure than in the domain model. The different controls specify essential actions that can developers should specify all additional properties, like se- be performed, e.g., the option to reset the password in the curity assumptions, only once on the most suitable level of login window. For a login of a user, the system needs the abstraction. While MDD can cover many kinds of models we user information to identify and legitimate the user. For this focus on UML models [9]. purpose, the LogInControl accesses the data available in In GRaViTY, the single models are iteratively refined until the User-object given to it. we reach a concrete implementation of the system. Fig. 1 shows the refinement hierarchy of the model kinds currently The data used by the system is detailed in this model. For considered by us from the most abstract model at the left to example, the classes User and Patient can be seen as the final implementation at the right. All in all, we consider more concrete instances of the classes Person and Patient UML models with three different levels of granularity. from the domain model in Fig. 2. On the Person class, a) Domain Model: The most abstract model is a domain for example, it is explicitly specified that the homeAddress model, specifying general properties of the domain, that the attribute, already known from the domain model, is derived software to develop is placed in [10]. Domain models are from other attributes. used in the earliest phases of software development to capture While models with different abstractions are often created general properties about a system’s domain. Often, domain separately, we encourage developers to model the information models are specified using UML class diagrams. of refinement explicitly by the use of inheritance relations Fig. 2 shows an excerpt of a domain model for hospitals. between elements. For example, there should be an explicit In hospitals, two kinds of people play a central role, patients inheritance relationship between the User in the design model and doctors who treat the patients. Both have a name and and the Person in the domain model. homeAddress. For patients, usually, a list of allergies c) Implementation Model: Precise functionality is speci- is stored and for doctors a list of their specialties. A fied in an implementation model. The implementation model is doctor can examine a patient in an Examination and create usually the first platform-dependent model and contains infor- Diagnose in such examinations. mation about the deployment or languages used to implement When we implement a software system for a hospital, e.g., the system. The implementation model can directly be exe- like iTrust [12] for online management of patient data, we cuted, used for code generation, implemented manually, or a have to support the concepts captured in the domain model. combination of all. In our approach, we support a combination b) Design Model: After the specification of the domain of the code generation and manual implementation. model, the domain elements realized in the software are Fig. 4 shows an excerpt of an implementation model show- concretized in design models. Those design models specify the ing how the iTrust platform could be developed in a hospital. design of the system and how the functionality is distributed The model is based on our experience in modeling the hospital among the system. Thereby, the foundation of an easily main- system of a partner in the VisiOn EU project together with tainable system is set by the appropriate use of well-known them but does not show a real system [14]. design patterns [13]. This is also the first point where we have Inside of the hospital, two servers are operated, one running to start to continuously use design and security analyses to iTrust and one running a database as well as an authentication ensure the system’s maintainability and security. service. Doctors are accessing the iTrust system from the Fig. 3 shows an excerpt of a design model for iTrust, based hospital’s local network. Patients can get access to their data on a UML model reverse-engineered by Bürger at al. [3]. In from the outside but have to authenticate themselves at the this model, different controls are specified for using the iTrust authentication service provided by the hospital. UML UMLsec Hospital Domain Model iTrustServer Design Model Java «deploy» WebServer «LAN» MobileDevice Implementation Model «Internet» «encrypted» UMLsec as CARiSMA Java Annotations Security Checks «deploy» «deploy» «deploy» Security Checks «artifact» «call, secrecy, integrity» «artifact» iTrust Database Program Model «deploy» «call, secrecy, integrity» Fig. 5: Concept of the Framework «artifact» «artifact» «artifact» Doctor AuthentificationService Patient «call, secrecy, integrity» «call, secrecy, integrity» «call, secrecy, integrity» a) Analysis of API calls: Many approaches locally ana- Fig. 4: Excerpt of an Implementation Model for iTrust based lyze calls to critical APIs and whether the chosen parameters on [14] have been selected securely. This covers, for example, calls to crypto APIs [15] or SQL queries [16]. While those approaches are important for the development of secure systems, in this B. Security Checks work we are focusing more on the question whether, e.g. the For the enforcement of security requirements, we can use of a crypto API, has been implemented at a point specified make use of various kinds of security checks, supported by in the models. GRaViTY. In what follows, we give a brief overview of b) Secure data flow analysis: A common approach to different kinds of security checks and in which stages of detect leaks of secret data is a secure data flow analysis. model-driven software development they can be applied. One of the main problems for a precise data flow analysis is the classification of critical sources and sinks. Many tools 1) Model-based Checks: According to the principle of are based on shared libraries of well known critical sources security by design, the system to be developed should already and sinks, created manually or by machine learning [17]. be checked early during its development for security issues. However, more precise information, especially about critical The UMLsec [1] approach, integrated into GRaViTY, allows sources, is available in design-time models, e.g., annotated the specification and check of essential security requirements with UMLsec. For example, in Fig. 2 we declared the property already at design time. In UMLsec, UML models are anno- homeAddress to contain secret values, which has to be tated with security requirements like security levels of class considered during a secure data flow analysis. members. These security annotations are checked for their While all these different security checks on the different compliance with different security policies. artifacts can help in the development of a secure system, In the given example, the class Person from the do- they are often limited to their area of focus. However, such main model in Fig. 2 is annotated with the UMLsec stereo- security checks are more powerful when they are combined. type <>, which specifies that the attribute For example, often information required by a security check homeAddress is on the security level secrecy, meaning on a lower level has already been defined at design-time. This that only legitimate entities are allowed to read its value. information should be reused to avoid misunderstandings and UMLsec allows, as part of the <> divergence in the security assumptions but also to improve security policy, to check if this domain model or any model the effectiveness of the checks. Unfortunately, doing so is refining the domain model contains insecure uses of attributes challenging and should be assisted by tool support. or operations, that are annotated with a security requirement. Here, we can utilize the use of refinement relations between III. GR AV I TY F RAMEWORK the different model kinds for detecting security violations at Our proposed framework, called GRaViTY [6], supports de- no additional cost for considering multiple models. Also, if a velopers in applying the model-driven development approach, security requirement is changed in one representation we can as described in Sec. II-A, to the development and maintenance immediately see the impact on the other UML representations. of secure long-living systems. As shown in Fig. 5, design In the implementation model, we also annotated the calls models (e.g. specified in UML), source code (e.g. written and communication paths with UMLsec stereotypes. E.g., all in Java), and a program model for performing sophisticated data transferred from and to the doctors is sent over an internal analyses, e.g. the security checks from Sec. II-B, are con- LAN connection and all data sent from and to the patients is tinuously synchronized for covering the different phases of sent over an encrypted internet connection. software development. 2) Static Code Analysis: Static code analysis is usually The program model provides a high-level abstraction from used to detect security issues during software implementation. the pure Java source code [18], e.g., by reducing details Thereby, the analysis tools are often integrated within the from the statement level to access edges between the single development environments or build processes. members. In addition, easy to query structures are created, (a) MoDisco Java Model  Program Model Fig. 6: Excerpt from the iTrust Program Model (b) MoDisco Java Model  UML Class Diagram such as structuring methods and fields into a tree with names, signatures, and definitions. For example, Fig. 6 shows Fig. 7: TGG Transformation Rules for Methods a program model with two different method signatures for the method name updateInformation. For the signa- ture with the parameter types EditOfficeVisitForm and integrated into GRaViTY. Unfortunately, unlike the mappings Boolean, a definition from the class EditOfficeVisit using TGGs, there is currently no automation in updating the is shown, which calls an other method definition. This allows different UML models. the easy specification of, e.g., refactorings [19], [18], anti- Let us assume a change in the security knowledge and pattern detection [2] and elimination [20], or compliance look at how the developed hospital system can be adapted checks with models [4]. to this change using the GRaViTY framework. Due to the Security-related specifications are introduced into the dif- introduction of the European General Data Protection Regu- ferent artifacts as annotations. On UML models, we use lation (GDPR) [24], we got a stronger restriction in the ways the UMLsec profile for security annotations proposed by how we have to deal with personal data. Before the GDPR Jürjens [1]. Similar annotations are specified as Java anno- became valid, it was legal to identify patients based on their tations on the source code level and are also contained in names. This information has to be treated with more sensitivity the program model, like the TSecrecy annotation in Fig. 6 now. This change in the security knowledge can, for exam- which relates to the secrecy value of the <> ple, be reflected in annotating the Patient in the domain annotation in Fig. 2. Here, GRaViTY mainly allows the reuse model in Fig. 2 with the UMLsec stereotype <> of security requirements across the different artifacts. For {secrecy={name:FullName}} expressing that the access example, as discussed in Sec. II-B, the UMLsec security to this information is only allowed for legitimate cases. As this annotations can be used to determine the sources and sinks security annotation is inherited by the more concrete subtypes, of a secure data flow analysis. the secure dependency check will fail after this change as there are no corresponding changes on the other elements. To keep the different artifacts consistent, we employ triple Accordingly, this gives a list of accesses to the developers, graph grammars (TGG) [21] for a bidirectional synchroniza- which have to be checked for this purpose. To do so, the tion between the source code and the program model repre- developers have to look into the documentation and can follow sentation of Java programs [18] as well as UML models. Our the trace links generated by GRaViTY. Furthermore, they can implementation is based on the eMoflon graph transformation use the TGGs to transfer the new security annotations into the engine [22]. Among others, eMoflon allows the specification code and re-execute the security analyses to get more detailed and execution of TGGs between models specified using the feedback about the compliance of the implementation. Eclipse Modeling Framework (EMF). While the UML models To conclude, our TGGs provide an automated mechanism to and the program model are specified using EMF, we have to preserve consistency between the three different program rep- parse the Java source code to create an EMF model from it. resentations for managing evolving Java programs. As a result, For this purpose, we are currently using MoDisco [23]. we obtain a model-based framework for arbitrarily interleaving Fig. 7 shows two transformation rules from these TGGs, program evolution and maintenance steps. Furthermore, we which translate a method declared by a type to a method can use this approach to also translate and synchronize security definition in the program model or an operation in a UML class requirements of model elements between different system diagram respectively. Inbetween the models a correspondence representations to execute sophisticated security checks on model is built, that allows the synchronization of changes them as discussed in section II-B. made on one of the two sides of the rule. The single UML models are directly connected by inheri- IV. C HALLENGES TO OVERCOME tance relations, e.g., the User in the design model (Fig. 3) is During our work, we faced various challenges of which a subtype of the Patient in the domain model (Fig. 2). This some have been solved by us, some have been circumvented allows easy detection of changes that lead to inconsistencies, by us, for some we have ideas on how to deal with them, as the inheritance relations can be used as trace links, as and some are still open challenges. In this section, we are demonstrated in Sec. II-B1. For this reason, the UMLsec tool is discussing the three most important challenges we faced. Source Code MoDisco Model Correspondences Program Model transformation 1. discover Fig. 8: Challenge A: Transformations between Models with 2. change Different Granularity 3. discover A. Transformation between Models with Different Granularity Changes between synchronized UML models and code can Fig. 9: Challenge B: Incremental Updates of ASTs easily be propagated, when they are on the same level of granularity, e.g., using the TGG-based approach presented in Sec. III. Models that are modeled by developers in early code, we generate a UML class diagram on the granularity of phases, e.g., the iTrust design model in Fig. 3, have a different the implementation, that is kept in sync with the implementa- granularity. Nevertheless, we have to be able to apply our syn- tion, into the implementation model. This generated model is chronization approach also to those manually defined models. initialized based on elements available in the implementation, Accordingly, the first challenge is how to deal with such a architectural, and design model. Afterward, code stubs, as well different granularity, as shown in Fig. 8. At the development as trace links, can be generated from this generated model. of GRaViTY, we faced this issue in three different variations. If one of the inheritances is lost, e.g., due to a deletion it a) Program Model: Our TGGs have been proven to has to be manually recreated by a developer. Additions in be good in handling different granularity by not translating the implementation are automatically synchronized into the elements, e.g., all details from the method bodies available generated part of the implementation model. in the MoDisco model but not in the program model. Un- c) Security Requirements: The same as discussed before fortunately, they cannot be used for creating structures that holds also for the different security requirements specified differ completely on the two sides. For this reason, we had to on every of these three system representations. While those implement multiple preprocessing steps extending the different security requirements should express the same assumption on models with such structural information. every representation, this assumption should be expressed in an One example is the method representation as name, sig- appropriate granularity on each representation: a more detailed nature, and definition, shown in Fig. 6. While it is pos- specification is required on the source code level than in the sible to create this structure using TGG rules by creat- domain or architectural model. ing the whole structure when a method name is translated the first time and inserting afterward, this produces issues B. Incremental Updates of Abstract Syntax Trees (ASTs) in the synchronization of changes. Let us assume that the One of the biggest issues we faced is the loss of information, TMethodName node in Fig. 6 has been created when the that was added manually or automatically to the created model, method in the class EditOfficeVisit has been translated when the source code has to be parsed again. The same issue and the other signature has been added afterward reusing this has been faced by representatives from industry, we talked to. TMethodName node. In a refactoring, e.g., a pull-up method This problem mainly covers the loss of generated or manually refactoring [19], we now delete the TMethodDefinition added annotations , such as the TSecrecy annotation in defined by EditOfficeVisit and are going to synchronize Fig. 6, and trace links to other artifacts, e.g., as part of the this change into the source code. To do this we have to correspondence model built by the TGGs, as shown at the top undo all rule applications that lead to the creation of deleted of Fig. 9. Usually, the discovery of a model after changes on nodes or edges. As the creation of the TMethodName node the code is executed from scratch resulting in an entirely new took place in the same rule application as the creation of model. As the added annotations and trace links reside in the the deleted TMethodDefintion node, it will be like this old model (as shown in Fig. 9) this results in the loss of all TMethodName node has never been created. This also makes added information that has not been written into the source the creation of the other TMethodSignature node invalid code. This means we would not be aware of the TSecrecy as its context does not exist anymore, leading to a situation annotation on the method definition in Fig. 6 anymore and in which no recovery is possible. To deal with this issue we have no correspondences to the new model, as shown on the defined a preprocessing which already creates the required bottom of Fig. 9. structure on the side of the MoDisco model. As there can be much information annotated to the models, Unfortunately, the handling of such issues by preprocessing if all this information would be written into the source code brings an additional level of complexity to the implementation it could become unreadable. Also, this information is already and makes the synchronization more difficult as most prepro- stored at a different location and should not be duplicated. cessings also need a postprocessing undoing them. In our case, the MoDisco framework builds an entirely new b) UML Models: To overcome the different granularity model each time, leading to the problem that the trace links between the manually maintained UML models and the source of the TGG still point to the old model. The representatives Tester Model transformations. Whenever we need a transformation Transformation ? between the UML Class Diagram and the Program Model we have to execute these two transformations in a row. To speed up this process, we tried to generate a UML Tr an sf Class Diagram  Program Model transformation from the or m at change two specifications we already had. As the two transformations io n ? are translating the same elements from the MoDisco model, it Fig. 10: Challenge C: Maintaining Networks of Transforma- should be straightforward to specify such a transformation. tions For example, as the two rules, in Fig. 7 both translate a MethodDeclaration, we can derive that we have to translate an Operation to a TMethodDefiniton. Un- from industry had the same problem with embedded C code. fortunately, while doing this, we had to learn that we have to To deal with this issue, we generate and apply model patches to resolve many inconsistencies first. Due to a very detailed test follow the source code changes. For this purpose we calculate suite for the two transformations, this was surprising for us. the differences between the old and changed model using EMF In this test suite, we created minimal examples for most Java Compare facing the following issues: language features to test the translation of these features. These a) Scalability: At first EMF Compare behaved very well features range from a simple class definition to exotic features when we applied it to small artificial changes but did not scale such as the definition of an inner class inside of an anonymous on real changes. In our previous works, we built a test set class. All in all, our test suite contains 77 input models that can of open-source projects with different sizes (between 5,800 be given into the two transformations as well as the expected and 200,000 lines of code) [2]. The creation of the program outcomes. All in all, we have 231 test cases in this test suite, model takes between some seconds to some minutes dependent 77 for the preprocessing common to the two transformations as on the size of the program. For each program, we tried to well as 77 test cases for each of the transformations. Besides, calculate the differences between different versions of each we regularly execute the transformation on our test set of open- program. While it took e.g. 7s to build a program model for source projects, introduced in Sec. IV-B. JUnit version 3.8.1 (32,300 nodes in the MoDisco model) it While testing the transformations we also had to deal with took EMF Compare already 37s to calculate the differences the model comparison problem discussed in Sec IV-B. Due to between JUnit version 3.8.1 and 3.8.2. For our next bigger the high complexity of the models, it was also not possible to program GanttProject (146,000 nodes) the TGG is executed compare the generated model directly with an expected model in 6s but EMF Compare did not even finish the comparison without getting pseudo differences. Our solution to this was to after 30 minutes. specify essential expected patterns in Henshin rules [26] and b) Pseudo Differences: An additional issue we discov- to check whether the rules match as expected. ered is regarding the quality of the differences calculated by We had to learn that already a network with only two EMF Compare. We got many differences containing multiple interacting transformations is hard to maintain. Thereby, we changes that reverted themselves. are in line with the observations of Stevens for bidirectional Helpful tool support going in the same direction, that transformations [27]. could be utilized for this, might be a TGG based consistency As the test suite, which contains common input models check [25]. In this case, we have to specify a TGG transfor- to both transformations and expected outputs to the two mation from the MoDisco meta-model to MoDisco that can be transformations, was not enough to avoid an unnoticed diver- used to detect the differences between two MoDisco models. gence, we are currently thinking about other ways to test the However, the best would be an incremental parser for Java, transformation. One of the ideas we are currently thinking of is that updates an initially created model each time it is executed to specify the third missing transformation and to test by using on the same code again. Unfortunately, there are only a few a round-trip execution. To sum up, additional tool support for works on this and none supports EMF. the maintenance of transformations is strongly required. C. Maintaining Networks of Transformations V. R ELATED W ORK The last challenge is regarding the maintenance of networks In this section, we discuss how others dealt with the same of transformations. According to Fig. 10, we have a network challenges we faced in comparable approaches. of transformations and are going to change one of the trans- In the single underlying model approach (SUM), Atkinson formations. The open question is how to systematically derive et al. define a single model, that is able to express all the required changes on the other transformations and how a information about the system [28]. Suitable views according tester for detecting divergences has to look like. to the current task are extracted from this model. The SUM While Fig. 5 shows three transformations between the is comparable to the different connected UML models of our different artifacts, by now we only implemented two of them. approach, in which we integrate all design-time information. To be more precise, these are the MoDisco Java Model  SUM supports an automated extraction of views that could be UML Class Diagram and the MoDisco Java Model  Program helpful in GRaViTY for manual edits of the generated parts of the implementation model. While we support well known plain R EFERENCES UML, SUM made many modifications to the UML to support [1] J. Jürjens, Secure Systems Development with UML. Springer, 2005, all those kinds of different abstractions. Also, SUM does not chinese translation: Tsinghua University Press, Beijing 2009. provide an integration with the concrete implementation. [2] S. Peldszus, G. Kulcsár, M. Lochau, and S. Schulze, “Continuous Detection of Design Flaws in Evolving Object-Oriented Programs using With VITRUVIUS Kramer et al. developed a SUM ap- Incremental Multi-pattern Matching,” in ASE, 2016. proach that also integrates Java source code [29]. Unlike [3] J. Bürger, D. Strüber, S. Gärtner, T. Ruhroth, J. Jürjens, and K. Schnei- der, “A framework for semi-automated co-evolution of security knowl- our approach, the trace links to the model are written into edge and system models,” JSS, vol. 139, 2018. the source code as annotations and might lead to unreadable [4] S. Peldszus, K. Tuma, D. Strüber, J. Jürjens, and R. Scandariato, “Secure source code, as discussed in Sec. IV-A. Data-Flow Compliance Checks between Models and Code based on Automated Mappings,” in MODELS, 2019. On a very similar technical basis as our framework is the [5] D. L. Parnas, “Software Aging,” in ICSE, 1994. Codeling tool of Konersmann [30]. The idea of Codeling is the [6] “GRaViTY.” [Online]. Available: http://gravity-tool.org integration of architecture model information into the program [7] T. Stahl, M. Voelter, and K. Czarnecki, Model-driven Software Devel- opment: Technology, Engineering, Management. Wiley, 2006. code. Like our approach, Konersmann uses TGGs for model [8] B. Hailpern and P. Tarr, “Model-driven Development: The Good, the to model transformations at architecture extraction. In contrast Bad, and the Ugly,” IBM Syst. J., vol. 45, no. 3, 2006. to us, he is not continuously keeping the extracted models up [9] OMG, “UML Superstructure Specification,” 2011. [10] G. Wagner, Information Management - An Introduction to Information to date but always writes all changes, made on an extracted Modeling and Databases, 2019. model, back to the code. Every time an architectural view [11] UML-Diagrams, “Hospital management.” [Online]. Available: https: on the system is needed Codeling extracts it again. By doing //www.uml-diagrams.org/examples/hospital-domain-diagram.html [12] A. Meneely, B. Smith, and L. Williams, “iTrust Electronic Health Care so Konersmann is circumventing the challenge of incremental System Case Study.” [Online]. Available: http://agile.csc.ncsu.edu/iTrust updates discussed in Sec. IV-B at the cost of massively [13] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns: increasing the code base with additional information. Elements of Reusable Object-oriented Software. Pearson, 1994. [14] I. Christantoni, C. Biffi, D. Bonutto, and A. C. Sanz, “Vision pilots Commercial tools like Enterprise Architect (EA) also pro- report,” VisiOn Privacy Platform, Tech. Rep., 2017. vide round-trip engineering for UML models and Code [31]. [15] S. Krüger, S. Nadi, M. Reif, K. Ali, M. Mezini, E. Bodden, F. Göpfert, The main limitation of these tools is the restriction to UML F. Günther, C. Weinert, D. Demmler, and R. Kamath, “CogniCrypt: Supporting Developers in using Cryptography,” in ASE, 2017. models very close to the code which eases the synchronization. [16] X. Fu, X. Lu, B. Peltsverger, S. Chen, K. Qian, and L. Tao, “A Static While EA allows a translation from UML stereotypes to Java Analysis Framework For Detecting SQL Injection Vulnerabilities,” in annotations, which could be used for transferring UMLsec COMPSAC, 2007. [17] S. Rasthofer, S. Arzt, and E. Bodden, “A Machine-learning Approach annotations into the code, they do not support more complex for Classifying and Categorizing Android Sources and Sinks,” in NDSS, information transfers. 2014. [18] S. Peldszus, G. Kulcsár, M. Lochau, and S. Schulze, “Incremental Co- While all approaches are dealing with the same challenges evolution of Java Programs Based on Bidirectional Graph Transforma- as us in similar ways, none of them provides the support tion,” in PPPJ, 2015. to maintain security requirements on different artifacts in a [19] S. Peldszus, G. Kulcsár, and M. Lochau, “A Solution to the Java Refactoring Case Study using eMoflon,” in TTC, 2015. sophisticated way and to check those security requirements in [20] S. Ruland, G. Kulcsár, E. Leblebici, S. Peldszus, and M. Lochau, between the different artifacts. “Controlling the Attack Surface of Object-Oriented Refactorings,” in FASE, 2018. [21] A. Schürr, “Specification of Graph Translators with Triple Graph Gram- VI. C ONCLUSION mars,” in WG, 1995. [22] E. Leblebici, A. Anjorin, and A. Schürr, “Developing eMoflon with eMoflon,” in ICMT, 2014. In this work, we presented the GRaViTY approach for [23] H. Bruneliere, J. Cabot, F. Jouault, and F. Madiot, “MoDisco: A Generic model-driven development and maintenance of secure long- and Extensible Framework for Model Driven Reverse Engineering,” in living systems. Based on GRaViTY, we elaborated on chal- ASE, 2010. [24] European Parliament and Council of the European Uninon, “Regulation lenges we had to overcome for further automation in the de- (EU) 2016/679 – General Data Protection Regulation (GDPR),” in velopment and verification of long-living systems using MDD. Official Journal of the European Union, 2016. [25] E. Leblebici, “Inter-Model Consistency Checking and Restoration with The main challenges are in dealing with all the different Triple Graph Grammars,” Ph.D. dissertation, 2018. levels of abstraction appearing in the development of systems [26] T. Arendt, E. Biermann, S. Jurack, C. Krause, and G. Taentzer, “Henshin: and the synchronization of the single artifacts appearing. While Advanced Concepts and Tools for In-place Emf Model Transformations,” in MODELS, 2010. we have been able to utilize recent developments from the [27] P. Stevens, “Bidirectional Transformations in the Large,” in MODELS, model transformation domain for improving the synchroniza- 2017. tion between the different artifacts, we faced also challenges [28] C. Atkinson, D. Stoll, and P. Bostan, “Orthographic Software Mod- eling: A Practical Approach to View-based Development,” in ENASE. in maintaining those transformations ourselves. Springer, 2009, pp. 206–219. To sum up, GRaViTY supports the model-driven develop- [29] M. E. Kramer, E. Burger, and M. Langhammer, “View-centric Engineer- ment and maintenance of secure software systems by providing ing with Synchronized Heterogeneous Models,” in VAO, 2013. [30] M. Konersmann, “Explicitly integrated architecture-an approach for support to synchronize the different artifacts appearing during integrating software architecture model information with program code,” MDD as well as in the specification and reuse of security Ph.D. dissertation, 2018. requirements in the execution of security checks for ensuring [31] “Enterprise Architect.” [Online]. Available: www.sparxsystems.de the security of the developed system.