round trip engineering

DevOps Round-Trip Engineering: Traceability from Dev to Ops and Back Again

• Conference paper
• First Online: 19 January 2019
• Cite this conference paper

• Miguel Jiménez 15 ,
• Lorena Castaneda 15 ,
• Norha M. Villegas 16 ,
• Gabriel Tamura 16 ,
• Hausi A. Müller 15 &
• Joe Wigglesworth 17  

Part of the book series: Lecture Notes in Computer Science ((LNPSE,volume 11350))

Included in the following conference series:

• International Workshop on Software Engineering Aspects of Continuous Development and New Paradigms of Software Production and Deployment

2105 Accesses

5 Citations

This is a preview of subscription content, log in via an institution to check access.

Access this chapter

Subscribe and save.

• Get 10 units per month
• Download Article/Chapter or eBook
• 1 Unit = 1 Article or 1 Chapter
• Cancel anytime
• Available as PDF
• Read on any device
• Instant download
• Own it forever
• Available as EPUB and PDF
• Compact, lightweight edition
• Dispatched in 3 to 5 business days
• Free shipping worldwide - see info

Tax calculation will be finalised at checkout

Purchases are for personal use only

Institutional subscriptions

Similar content being viewed by others

Managing the Variability of Component Implementations and Their Deployment Configurations Across Heterogeneous Deployment Technologies

Harmonia: A Continuous Service Monitoring Framework Using DevOps and Service Mesh in a Complementary Manner

https://www.terraform.io (accessed Oct, 2018).

https://www.openstack.org (accessed Oct, 2018).

In the literature often referred to as [email protected] [ 17 ].

Model synchronisation and RTE are often used interchangeably in the literature [ 12 ].

https://docs.openstack.org/heat/latest/template_guide (accessed Oct, 2018).

https://www.terraform.io/docs/configuration/syntax.html (accessed Oct, 2018).

https://github.com/RigiResearch/jachinte-DevOps2018-evaluation .

https://wiki.eclipse.org/Xcore (accessed Oct 2018).

http://www.eclipse.org/xtend (accessed Oct 2018).

http://www.eclipse.org/Xtext (accessed Oct 2018).

http://yaml.org (accessed Oct 2018).

Sharma, S., Coyne, B.: DevOps for Dummies. Limited IBM Edition (2013)

Google Scholar  

Zhu, L., Bass, L., Champlin-Scharff, G.: DevOps and its practices. IEEE Softw. 33 (3), 32–34 (2016)

Article   Google Scholar  

Fagerholm, F., Guinea, A.S., Mäenpää, H., Münch, J.: Building blocks for continuous experimentation. In: Proceedings of the 1st International Workshop on Rapid Continuous Software Engineering, RCoSE 2014, pp. 26–35. ACM, New York (2014)

Shahin, M., Babar, M.A., Zhu, L.: The intersection of continuous deployment and architecting process: practitioners’ perspectives. In: Proceedings of the 10th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement, ESEM 2016, pp. 44:1–44:10. ACM, New York (2016)

Fabijan, A., Dmitriev, P., Olsson, H.H., Bosch, J.: The evolution of continuous experimentation in software product development: from data to a data-driven organization at scale. In: 2017 IEEE/ACM 39th International Conference on Software Engineering, ICSE 2017, pp. 770–780 (2017)

Schermann, G., Cito, J., Leitner, P.: Continuous experimentation: challenges, implementation techniques, and current research. IEEE Softw. 35 (2), 26–31 (2018)

Morris, K.: Infrastructure as Code: Managing Servers in the Cloud, 1st edn. O’Reilly Media Inc., Sebastopol (2016)

Spanoudakis, G., Zisman, A.: Inconsistency management in software engineering: survey and open research issues, pp. 329–380. World Scientific Publishing Company (2012)

Kruchten, P., Nord, R.L., Ozkaya, I.: Technical debt: from metaphor to theory and practice. IEEE Softw. 29 (6), 18–21 (2012)

Henriksson, A., Larsson, H.: A definition of round-trip engineering. Technical report (2003)

Sendall, S., Küster, J.: Taming model round-trip engineering. In: Proceedings of Workshop on Best Practices for Model-Driven Software Development, p. 1 (2004)

Hettel, T., Lawley, M., Raymond, K.: Model synchronisation: definitions for round-trip engineering. In: Vallecillo, A., Gray, J., Pierantonio, A. (eds.) ICMT 2008. LNCS, vol. 5063, pp. 31–45. Springer, Heidelberg (2008). https://doi.org/10.1007/978-3-540-69927-9_3

Chapter   Google Scholar  

Shahin, M., Babar, M.A., Zhu, L.: Continuous integration, delivery and deployment: a systematic review on approaches, tools, challenges and practices. IEEE Access 5 , 3909–3943 (2017)

ISO/IEC/IEEE, International Standard - Systems and software engineering - Vocabulary. ISO/IEC/IEEE 24765:2010(E), pp. 1–418 (2010)

Hüttermann, M.: Infrastructure as Code, pp. 135–156. Apress (2012)

Nelson-Smith, S.: Test-Driven Infrastructure with Chef: Bring Behavior-Driven Development to Infrastructure as Code. O’Reilly Media Inc., Sebastopol (2013)

Blair, G., Bencomo, N., France, R.B.: [email protected]. Computer 42 (10), 22–27 (2009)

Rahm, J., Graube, M., Urbas, L.: A proposal for an interactive roundtrip engineering system. In: 2017 22nd IEEE International Conference on Emerging Technologies and Factory Automation (ETFA), pp. 1–7, September 2017

Tilley, S.R., Wong, K., Storey, M.A.D., Müller, H.A.: Programmable reverse engineering. Int. J. Softw. Eng. Knowl. Eng. 04 (04), 501–520 (1994)

Fitzgerald, B., Stol, K.J.: Continuous software engineering: a roadmap and agenda. J. Syst. Softw. 123 , 176–189 (2017)

Petre, M.: UML in practice. In: Proceedings 35th International Conference on Software Engineering, ICSE 2013, pp. 722–731. IEEE Press, Piscataway (2013)

Hutchinson, J., Rouncefield, M., Whittle, J.: Model-driven engineering practices in industry. In: Proceedings 33rd International Conference on Software Engineering, ICSE 2011, pp. 633–642. ACM, New York (2011)

Inzinger, C., Nastic, S., Sehic, S., Vögler, M., Li, F., Dustdar, S.: MADCAT: a methodology for architecture and deployment of cloud application topologies. In: Proceedings 8th International Symposium on Service Oriented System Engineering, SOSE 2014, Oxford, UK, pp. 13–22 (2014)

Copil, G., Moldovan, D., Truong, H.L., Dustdar, S.: SYBL: an extensible language for controlling elasticity in cloud applications. In: Proceedings 13th IEEE/ACM International Symposium on Cluster, Cloud and Grid Computing, CCGrid 2013, pp. 112–119 (2013)

Wettinger, J., Breitenbücher, U., Leymann, F.: DevOpSlang – bridging the gap between development and operations. In: Villari, M., Zimmermann, W., Lau, K.K. (eds.) ESOCC 2014. LNCS, vol. 8745, pp. 108–122. Springer, Heidelberg (2014). https://doi.org/10.1007/978-3-662-44879-3_8

Thiery, A., Cerqueus, T., Thorpe, C., Sunyé, G., Murphy, J.: A DSL for deployment and testing in the cloud. In: Proceedings of the 2014 IEEE International Conference on Software Testing, Verification, and Validation Workshops, ICSTW 2014, pp. 376–382. IEEE Computer Society (2014)

Glaser, F.: Domain model optimized deployment and execution of cloud applications with TOSCA. In: Grabowski, J., Herbold, S. (eds.) SAM 2016. LNCS, vol. 9959, pp. 68–83. Springer, Cham (2016). https://doi.org/10.1007/978-3-319-46613-2_5

Holmes, T.: M ing : model- and view-based deployment and adaptation of cloud datacenters. In: Helfert, M., Ferguson, D., Méndez Muñoz, V., Cardoso, J. (eds.) CLOSER 2016. CCIS, vol. 740, pp. 317–338. Springer, Cham (2017). https://doi.org/10.1007/978-3-319-62594-2_16

Bencomo, N., Bennaceur, A., Grace, P., Blair, G., Issarny, V.: The role of [email protected] in supporting on-the-fly interoperability. Computing 95 (3), 167–190 (2013)

Castaneda, L.: Runtime modelling for user-centric smart applications in cyber-physical-human systems. Ph.D. thesis, Department of Computer Science, University of Victoria (2017)

Download references

Acknowledgments

This work was funded in part by the National Sciences and Engineering Research Council (NSERC) of Canada, IBM Canada Ltd. and IBM Advanced Studies (CAS), the University of Victoria (Canada), and Universidad Icesi (Colombia).

Author information

Authors and affiliations.

University of Victoria, Victoria, BC, Canada

Miguel Jiménez, Lorena Castaneda & Hausi A. Müller

Universidad Icesi, Cali, Valle del Cauca, Colombia

Norha M. Villegas & Gabriel Tamura

IBM Toronto Laboratory, Toronto, Canada

Joe Wigglesworth

You can also search for this author in PubMed   Google Scholar

Corresponding author

Correspondence to Miguel Jiménez .

Editor information

Editors and affiliations.

University of Toulouse, Toulouse, France

Jean-Michel Bruel

Innopolis University, Innopolis, Russia

Manuel Mazzara

Innopolis University and Politecnico di Milano, Innopolis, Russia

Bertrand Meyer

Rights and permissions

Reprints and permissions

Copyright information

© 2019 Springer Nature Switzerland AG

About this paper

Cite this paper.

Jiménez, M., Castaneda, L., Villegas, N.M., Tamura, G., Müller, H.A., Wigglesworth, J. (2019). DevOps Round-Trip Engineering: Traceability from Dev to Ops and Back Again. In: Bruel, JM., Mazzara, M., Meyer, B. (eds) Software Engineering Aspects of Continuous Development and New Paradigms of Software Production and Deployment. DEVOPS 2018. Lecture Notes in Computer Science(), vol 11350. Springer, Cham. https://doi.org/10.1007/978-3-030-06019-0_6

Download citation

DOI : https://doi.org/10.1007/978-3-030-06019-0_6

Published : 19 January 2019

Publisher Name : Springer, Cham

Print ISBN : 978-3-030-06018-3

Online ISBN : 978-3-030-06019-0

eBook Packages : Computer Science Computer Science (R0)

Share this paper

Anyone you share the following link with will be able to read this content:

Sorry, a shareable link is not currently available for this article.

Provided by the Springer Nature SharedIt content-sharing initiative

• Publish with us

Policies and ethics

• Find a journal
• Track your research

Round trip engineering | Glossary

Definition:

Round-trip engineering (RTE) is a functionality of software development tools that synchronizes two or more related software artifacts, such as, source code, models, configuration files, and even documentation. The need for round-trip engineering arises when the same information is present in multiple artifacts and therefore an inconsistency may occur if not all artifacts are consistently updated to reflect a given change. For example, some piece of information was added to/changed in only one artifact and, as a result, it became missing in/inconsistent with the other artifacts.

Further Reading:

Book: The Unified modeling Language user guide by Grady Booch, James Rumbaugh and Ivar Jacobson

Share post:

• Click to email this to a friend (Opens in new window)
• Click to share on LinkedIn (Opens in new window)
• Click to share on Twitter (Opens in new window)
• Click to share on Skype (Opens in new window)
• Click to share on Facebook (Opens in new window)
• Click to share on Pinterest (Opens in new window)
• Click to share on WhatsApp (Opens in new window)

Leave a Reply Cancel reply

You must be logged in to post a comment.

This site uses Akismet to reduce spam. Learn how your comment data is processed .

© 2013- 2022 INNOVATION ROOTS SOFTECH PVT LTD

• Cancellation & Refund Policy
• Privacy Policy
• Terms & Conditions Policy

• Create account
• Contributions
• Discussion for this IP address

Introduction to Software Engineering/Reengineering/Round-trip Engineering

Round-trip engineering (RTE) is a functionality of software development tools that synchronizes two or more related software artifacts, such as, source code, models, configuration files, and other documents. The need for round-trip engineering arises when the same information is present in multiple artifacts and therefore an inconsistency may occur if not all artifacts are consistently updated to reflect a given change. For example, some piece of information was added to/changed in only one artifact and, as a result, it became missing in/inconsistent with the other artifacts.

Round-trip engineering is closely related to traditional software engineering disciplines: forward engineering (creating software from specifications), reverse engineering (creating specifications from existing software), and reengineering (understanding existing software and modifying it). Round-trip engineering is often wrongly defined as simply supporting both forward and reverse engineering. In fact, the key characteristic of round-trip engineering that distinguishes it from forward and reverse engineering is the ability to synchronize existing artifacts that evolved concurrently by incrementally updating each artifact to reflect changes made to the other artifacts. Furthermore, forward engineering can be seen as a special instance of RTE in which only the specification is present and reverse engineering can be seen as a special instance of RTE in which only the software is present. Many reengineering activities can also be understood as RTE when the software is updated to reflect changes made to the previously reverse engineered specification.

Another characteristic of round-trip engineering is automatic update of the artifacts in response to automatically detected inconsistencies. In that sense, it is different from forward- and reverse engineering which can be both manual (traditionally) and automatic (via automatic generation or analysis of the artifacts). The automatic update can be either instantaneous or on-demand . In instantaneous RTE, all related artifacts are immediately updated after each change made to one of them. In on-demand RTE, authors of the artifacts may concurrently evolve the artifacts (even in a distributed setting) and at some point choose to execute matching to identify inconsistencies and choose to propagate some of them and reconcile potential conflicts.

Examples of round-trip engineering

Perhaps the most common form of round-trip engineering is synchronization between UML (Unified Modeling Language) models and the corresponding source code. Many commercial tools and research prototypes (e.g., FUJABA) support this form of RTE. Usually, UML class diagrams are supported to some degree; however, certain UML concepts, such as associations and containment do not have straightforward representations in many programming languages which limits the usability of the created code and accuracy of code analysis (e.g., containment is hard to recognize in the code). Behavioral parts of UML impose even more challenges for RTE.

A more tractable form of round-trip engineering is implemented in the context of framework application programming interfaces (APIs), whereby a model describing the usage of a framework API by an application is synchronized with that application's code. In this setting, the API prescribes all correct ways the framework can be used in applications, which allows precise and complete detection of API usages in the code as well as creation of useful code implementing correct API usages. Two prominent RTE implementations in this category are framework-specific modeling languages and Spring Roo.

Round-trip engineering is critical for maintaining consistency among multiple models and between the models and the code in Object Management Group's (OMG) Model-driven architecture. OMG proposed the QVT (query/view/transformation) standard to handle model transformations required for MDA. To date, a few implementations of the standard have been created. (Need to present practical experiences with MDA in relation to RTE).

External links

• UML Round-trip Engineering with Altova

• Book:Introduction to Software Engineering

Round trip engineering for dummies: a proposal

by Stefan Jetchick | Jul 26, 2016 | opinion , reverse engineering , UML and OCL | 3 comments

UPDATE: After some feedback, this post has been extended with a few more clarifications and a comparison with Umple , a tool that adds modeling abstractions directly into programming languages.

This article started out as a newbie question to Mr. Jordi Cabot, about how to improve the collaboration between a software modeling notation (UML for example), and a general-purpose systems programming language (i.e. a “low-level” language immediately above assembler, akin to C++), by designing the programming language from scratch with such a collaboration in mind (i.e. round trip engineering).

In other words, this happened:

Part 1: The problem

Part 2: “code-centric” round-tripping, 3.1 adding uml “syntactic sugar” in the programming language.

• 3.2 Reduce the physical design “semantic gap” between UML and systems programming languages.

3.3 Resuscitate the “Environment Division” of COBOL

• 3.4 Design the programming language to be a “public highway” for all software development tools.

Introduction

My second mistake: political correctness, a critique of umple: was the initial problem solved, or oversimplified, theoretical nuts and bolts are not practical nuts and bolts, conclusion: is umple a dead endle.

What should we do as language designers to make life easier for tool builders, more specifically for software modeling tools that try to provide “round-trip engineering” with a notation like UML?

For all you readers who still have a social life, and who therefore might need a quick reminder on the context:

• General-purpose systems programming languages (GPLs like C++, but there are other ones) are good at expressing all the little implementation details of a software system (hence the jar filled with nuts and bolts in the picture above). You could say it’s a more analytical view.
• Software modeling notations (like UML) are good at expressing “the big picture”, the intentions behind all those implementation details, and transmitting this information in a “more parallel and less serial” way, using more intuition (i.e. “parallel” grasping of many ideas in a single drawing) and less reasoning (i.e. “serial” parsing of source code).  You could say it’s a more synthetic view.

Both the analytical and the synthetic views are needed, and ideally it would be easy to navigate from one to the other and back again (hence the expression “round-trip”). We would like to whip up some UML diagrams, and then “pour out” all this information into source code:

Then we would like to fiddle with the source code and “pour out” all the changes back into various diagrams (thanks Marie-Claude for the lovely hand):

And of course, we would love to be able to repeat this process as often as needed, without “spilling” anything. As the Wikipedia entry for “Round-trip_engineering” says:

The need for round-trip engineering arises when the same information is present in multiple artifacts and therefore an inconsistency may occur if not all artifacts are consistently updated to reflect a given change

What is the solution to this problem? To be honest,  I don’t know what the solution is, but there is a solution I would like to explore. You could call this approach by many names:

• the “ carry-on only ” approach (in reference to air travel round-trips with minimal luggage); or
•  the “ code centric ” approach; or
•  the “ round-tripping for dummies ” approach.

This approach can be explained based on the following principles and assumptions:

• GPLs are NOT software modeling notations, and conversely. Their respective objectives and means are too different (see “analytical vs. synthetic” above). In other words, the “holy grails” of “CASE” (Computer-Assisted Software Engineering), as well as “executable UML”, etc., are probably impossible to fully attain, but getting a little bit closer is still relevant for software development.
•  Despite the fundamental incompatibilities, there is an intersection, (“the good red wine”)  used by both the software modeling notation and the general-purpose systems programming language.
•  In this approach, the “good red wine” (i.e. the common information used by both the diagramming software and the programming language compiler) is never duplicated.
•  The unique copy of the “good red wine” is kept in the source code. (Why? Because source code is the only artifact that is guaranteed to get done, no matter how dysfunctional the development process. Also, if there is a disagreement between the diagrams and the source code, the source code will “win” anyway.)
•  The source code cannot be the repository for the “good red wine”, unless it is designed for that purpose. (In other words, C++ cannot be used, unless its “user-interface” (syntax, keywords, all the visible stuff) is re-designed from the ground up.)
•  The programming language must be aware of the existence of other tools, must provide them with “hooks and slots” to allow collaboration, and must actively maintain that collaboration during the whole development cycle.
•  Collaboration is much easier when somebody is designated to be “in charge”. In this approach, the source code is “in charge”, i.e. if information is replicated in several locations (source code, diagrams, etc.), the version in the source code is deemed correct.
•  The diagramming software presents a visual GUI allowing the user to draw shapes, move them around, connect them, etc. Then, if the changes are only esthetic (colors, sizes, positions, etc.), the diagramming software just saves them to whatever internal file format it uses. But if the changes would modify the common information shared with the programming language (i.e. the “good red wine”), then the diagramming software must use the source code as a kind of “API” to modify the diagrams.

To sum up, automatic and repetitive round-tripping would be much easier if we reduced the scope to the common parts of both ends and we extended the GPL part to be used for that purpose, i.e. if we made it more “modeling amenable” . Let’s see how this could work.

Part 3: Snippets of implementation details

I currently only have snippets of implementation details, i.e. how a new general-purpose systems programming language should be designed to facilitate “round-tripping” with a notation like UML:

3.2 Reduce the physical design “semantic gap” between UML and systems programming languages .

Architects see walls and windows and rooms, not just bricks and bricks and more bricks. Likewise, software architects don’t just think in terms of lines of code, they also see large “packages of code” as well as their interdependencies (“levelization” as taught by Mr. John Lakos).

This could lead to source code such as:

I’m almost serious here. There is something healthy about a programming language having a construct dealing with the outside world. A compiler does not survive alone on an uninhabited island in the Pacific. These days, there are source control management tools, build automation tools, diagramming tools, profilers, class browsers, software component repositories, etc.

The programming language should make an effort to be a “team player”, and this should be in the language itself, not in a private vendor-specific format. This is even more important for C++, which doesn’t even have a language construct for the “project”. (A C++ program is just a heap of disjointed translation units (hopefully) united by a linker.)

Ideally, this means the compiler could:

• Read the “environment” statement;
• Find out what other software development tools currently depend on this source code;
• Detect which “regions” of the source code are “hot”, i.e. must not be touched, otherwise other development tools would break;
• Tell the user how to modify those “hot” regions (for example, “The XYZ diagramming tool has locked this line of code, do you want to start that program to make your modifications to the inheritance hierarchy?”)

3.4 Design the programming language to be a “public highway” for all software development tools .

I say “Highway” because parsing must be very fast (the grammar must not be like a twisty and pot-holed dirt road… like C++), and “public” because there must be no “intellectual property” limitations (i.e. it’s not proprietary).

For parsing speed, I know little about compilers, but I’m guessing this means among others an “S-Grammar” (Hulub 1990, p. 173). Veteran programmers like to repeat that a key advantage of the C programming language is its ability to take one character of input, and throw it away quickly. It’s similar for a programming language that wants to be a “public highway for all software development tools”. It must allow other tools to parse it, and quickly “throw away” what is irrelevant to them. In other words, other tools must be able to easily read the source code to extract the “good red wine”.

As the inventor of C++ famously said: “Inside C++, there is a cleaner and smaller language struggling to get out”. I don’t know what this language will be, but its designers should be able to profit from research on language design rules to streamline round-tripping between it and UML. If you are aware of such research, please contact me, I’m very much interested!

UPDATE: is Umple a dead end?

Umple claims to merge the concepts of programming and modeling by adding modeling abstractions directly into programming languages (currently Java, Ruby and PHP), allowing the Umple pre-processor to both generate basic UML class and state diagrams, and generate reasonably equivalent source code. The diagrams can be seamlessly modified through the source code, and vice-versa, eliminating the necessity for “round trip engineering”. This article confirms all these Umple claims, but adds a harsh disclaimer: the Umple approach works only if you oversimplify the initial problem by simultaneously abandoning both the speed and efficency of low-level systems programming, and the conceptual expressiveness of high-level UML diagramming. Hence, Umple is currently unfit for industrial-grade software development.

Following my article “Round Trip Engineering for Dummies: A Proposal” , Doctor Timothy C. Lethbridge commented:

“[…] round-trip engineering is not necessary, and is in fact harmful. […] Umple allows direct editing of model and code in either textual or graphical form. […] I think Umple achieves much of what you are looking for in this article.”

I will now attempt to examine that comment, in a constructive and courteous way. (Please be forwarned that, even though I claim to be a Christian, I often cause Jesus to facepalm when I open my mouth! 😉 )

2) My first mistake: changing the title of my article

Mr. Jordi Cabot, after receiving my draft, changed the title (and made a few other changes). He was trying to be helpful, and I was trying to be nice, so I approved the changes. That was my mistake. I’m sorry.

The initial title was:

Round-tripping between languages like C++ and UML

I specifically had chosen the expression “like C++”, because I did not want to limit myself to C++, but I also said “like C++”, to exclude non-systems general-purpose programming languages like Java and Ruby. (A general-purpose SYSTEMS programming language can “go down closer to the hardware”, or as Stroustrup says, there is no room for another language in between C++ and assembler.)

The point is not some “language war”. The point is C++ (and other systems programming languages), are much farther away from the high-level conceptual view of UML. The technical challenge of narrowing the semantic gap between languages like C++ and UML is much greater than with Java or Ruby.

The second apparently minor change that I mistakingly approved was the removal of important pedagogical aids, in the name of political correctness. I understand Mr. Cabot’s desire to avoid controversy and accusations of sexism (which is why I approved the edits), but with hindsight, we should just have maintained that the intention was not to demean women. Here are the two original paragraphs, with what was removed in bold:

• General-purpose systems programming languages (like C++, but there are other ones) are good at expressing all the little implementation details of a software system (hence the jar filled with nuts and bolts in the picture above). You could say it’s a more analytical, more “masculine” view.
• Software modeling notations (like UML) are good at expressing “the big picture”, the intentions behind all those implementation details, and transmitting this information in a “more parallel and less serial” way, using more intuition (i.e. “parallel” grasping of many ideas in a single drawing) and less reasoning (i.e. “serial” parsing of source code).  You could say it’s a more synthetic, more “feminine” view (hence the jar filled with lipstick and mascara, or whatever, I’m not sure, I borrowed all that from Marie-Claude) .

My joke might not be as funny as I wanted it to be, but the metaphor was important: it is ridiculous and impractical to put lipstick and mascara in a jar of nuts and bolts.

Now that Dr. Lethbridge has helped me improve my original article by manifesting my errors, I will henceforth prove my gratitude by trying to show why Umple is a dead end. (Is “No good deed goes unpunished” a Principle of Model-Driven Architecture? 😉 )

To continue my tradition of silly pictures that contain important pedagogical metaphors, I will use two more, one about the importance of nuts and bolts, and the other about the importance of mascara and lipstick.

An old joke says: “You can fix anything with only two tools: duck tape and WD-40; indeed, if it moves, and it shouldn’t , use duck tape; but if it doesn’t move, and it should , use WD-40.” (For non-Canadians, WD-40 is a light oil, and duck tape is the handyman’s secret weapon ).

In theory, duck tape and WD-40 are sufficient. They really do cover all cases, in theory . But in practice, they don’t. If all you need to fix are toy programs written by undergrad students, you don’t need complicated tools. But if you are dealing with industrial-grade software, you need nuts, bolts, screws, nails, staples, nylon straps, epoxy glue, etc.

  Then the equivalent Umple code:

Nothing magical here, a basic “1 to Many” relationship. We’re talking about a couple of boxes, one line and two numbers. Now, what could this give in a general-purpose systems programming language? (Pardon my clumsy C++, I’m still learning)

Those are just a few examples of ways to implement a “1 to Many” relationship. I’m sure a competent C++ programmer could name many more, as well as list the advantages and disadvantages for each option, and chose the appropriate one according to the circumstances. (The current Umple version has only one way to implement that relationship, a bizarre pointer to a vector of naked pointers, on top of generating over 400 lines of obscure C++ code just for those two empty classes of “Parent” and “Child”!)

The way Umple is designed, it prevents such necessary implementation flexibility (even if C++ was supported as a base language, because it’s not). Umple claims:

“There is never any need to edit generated code, since any desired effects can be achieved either directly in the model, in the passed-through methods or in the aspect-oriented code injections.”

Pass-through code doesn’t help: if you just “pass-through” a line of code containing a relationship without processing it, the relationship won’t appear in the UML diagram. Aspect code injection doesn’t help either, for the same reason. If you manually modified the generated code, a clever C++ parser might be able to pick up many of those relationships and display them in a UML diagram, but it would not catch all of them. Even then, that wouldn’t work, since Umple doesn’t allow you to modify generated code (round-tripping is forbidden in Umple, remember).

You could transmogrify Umple to make it as expressive and powerful as C++, while providing “UML syntactic sugar” so programmers could give cues to the diagramming software about where the UML relationships are, as well as allowing round tripping, but then, that would not be Umple anymore.

And that’s about it for “lipstick and mascara” in Umple…

But in order for UML to actually work, we need much more “lipstick and mascara”. Modeling is not a simplistic affair. A good model “lets us visualize the invisible, makes the fleeting stand still, and gathers the too large or too small right in the palm of our hand”.  As Grady Booch says, “[…] even the most subtle visual cues can go a long way in communicating meaning”, ( The UML User Guide, 2nd Ed. , 2005, p. 88.).

Let’s take the very simple example of just one class:

• A class must be able to appear in more than one class diagram. (Already, since the position is encoded in the actual source code for that class, this is impossible in Umple. Whip out the paint roller…)
• Each class must also be able to appear in other types of diagrams. (There are many “views” in UML: the use case view, the design view, the interaction view, the implementation view, and the deployment view).
• Each class must also be able to appear in non-predefined diagrams. (“Of course, you are not limited to the predefined diagram types. In the UML, diagram types are defined because they represent the most common packaging of viewed elements. To fit the needs of your project or organization, you can create your own kinds of diagrams to view UML elements in different ways”. op. cit. , p. 91).
• In each of these potentially numerous instances of a “class appearance” , that class must be able to selectively hide from zero to all of its fields and methods (“Show only those properties of the classifier that are important to understand the abstraction it its context”, op. cit. , p. 132).
• Since any class can have extra named compartments containing pretty much anything you want ( op. cit. , p. 79), whatever is in those compartments must also be able to be selectively hidden or displayed. (I personally love to have a named compartment called “Responsibilities” in the important classes; it really helps to understand what is going on.)
• Each class (well, actually each visual element in any diagram) must have a user-definable position and size (and other graphical attributes). One of the important talents of a “UML artist” is organizing things in the diagram so the sizes and positions convey a sense of what is important, what is going on, who depends on who, etc.
• UML gives much freedom for “adornment” flexibility: colors, icons, notes, etc.
• UML also has semi-structured “extensibility mechanisms” (stereotypes, constraints, tagged values), which pretty much mean that the bottleneck is the diagramming software (or the stamina of your wrist muscles if you’re using a whiteboard).

I thought of drawing a UML diagram of all this “lipstick and mascara”, but it’s very complicated! The design of a good UML diagramming program is one tough challenge in itself, because of this complexity. But I hope you now understand why my initial picture at the top is misleading: Marie-Claude doesn’t have one little jar with three tubes of lipstick and mascara. She has MANY MORE! Lipstick, mascara, eyeliner, fingernail paint stuff, powder stuff, and all kinds of incomprehensible stuff filling all the cabinets in her bathroom, and in her bedroom, and in the entrance near the mirror, and in her multiple handbags, etc.

This metaphor is important: good UML diagrams are complicated beasts which require esthetic talent, creativity and powerful tools! If you try to put all that complexity in the source code, you’ll overwhelm the programmer with clutter. If, like the current iteration of Umple, you pretend such complexity isn’t necessary, you’ll basically end up putting on makup with a paint roller. And of course, if you let the diagramming software manage the UML on one hand, and the compiler manage the source code on the other, you’ll end up with the original problem of “synchronizing the jar of nuts and bolts, with the jar of lipstick and mascara”.

Is Umple a Dead End? Of course not. This is software. Anybody can change anything anytime, especially a super-smart Ph.D. like Dr. Lethbridge and his army of super-smart graduate students!

Can I recommend the current version of Umple to my Boss today for real projects? No, because Umple simultaneously manages to take away BOTH my nuts and bolts, AND my lipstick and mascara. I need both, and both synchronized , to build non-academic software.

Currently exploring ideas for a General-Purpose Systems Programming Language with the underlying Object Model of C++, but with an updated “interface” (i.e. the syntax, keywords, etc.), so it can become a “public highway” for all software development tools. See www.gepsypl.org

For almost 20 years I have believed that round-trip engineering is not necessary, and is in fact harmful. For the last 10 years we have developed Umple that makes that perspective concrete. Umple allows direct editing of model and code in either textual or graphical form. See http://www.umple.org

I think Umple achieves much of what you are looking for in this article.

Good day Mr. Tim Lethbridge,

Yes, I examined Umple before writing my article, because of Mr. Jordi Cabot! When I sent him my question, he sent me several hyperlinks of resources, among them a brief description of your work and your web site http://www.umple.org . So you have a vigorous advocate!

I have the memory of a Goldfish, so I will need to go re-read about Umple to answer your comment fully. I don’t have all your degrees and years of experience, so please give me a few days.

I agree that Umple has many of the qualities required here. For the readers, remember that we talked about (and discuss) Umple in this older post: https://modeling-languages.com/umple-language-model-oriented-programming/

Submit a Comment Cancel reply

Your email address will not be published. Required fields are marked *

 subscribe to our newsletter

Notify me of followup comments via e-mail. You can also subscribe without commenting.

Early data modeling

Modeling: all you need to know.

JavaScript diagramming library

Recent comments.

• Jordi Cabot on Teaching Object Constraint Language (OCL)? Why [not]? Your input is needed!
• Jordi Cabot on A new book on low-code is coming – interested?
• Luiz Camargo on Teaching Object Constraint Language (OCL)? Why [not]? Your input is needed!
• philippe lafage on A new book on low-code is coming – interested?
• philippe lafage on Teaching Object Constraint Language (OCL)? Why [not]? Your input is needed!

Twitter / X

Want to build better software faster?

Get the latest news in software modeling, model-based and low-code development

Thanks for your interest. Check your inbox and confirm your subscription!

Pin it on pinterest.

• Hacker News

Share on Mastodon

Software Engineering Institute

Cite this post.

AMS Citation

Kazman, R., 2014: Security Pattern Assurance through Round-trip Engineering. Carnegie Mellon University, Software Engineering Institute's Insights (blog), Accessed September 27, 2024, https://insights.sei.cmu.edu/blog/security-pattern-assurance-through-round-trip-engineering/.

APA Citation

Kazman, R. (2014, January 20). Security Pattern Assurance through Round-trip Engineering. Retrieved September 27, 2024, from https://insights.sei.cmu.edu/blog/security-pattern-assurance-through-round-trip-engineering/.

Chicago Citation

Kazman, Rick. "Security Pattern Assurance through Round-trip Engineering." Carnegie Mellon University, Software Engineering Institute's Insights (blog) . Carnegie Mellon's Software Engineering Institute, January 20, 2014. https://insights.sei.cmu.edu/blog/security-pattern-assurance-through-round-trip-engineering/.

IEEE Citation

R. Kazman, "Security Pattern Assurance through Round-trip Engineering," Carnegie Mellon University, Software Engineering Institute's Insights (blog) . Carnegie Mellon's Software Engineering Institute, 20-Jan-2014 [Online]. Available: https://insights.sei.cmu.edu/blog/security-pattern-assurance-through-round-trip-engineering/. [Accessed: 27-Sep-2024].

BibTeX Code

@misc{kazman_2014, author={Kazman, Rick}, title={Security Pattern Assurance through Round-trip Engineering}, month={Jan}, year={2014}, howpublished={Carnegie Mellon University, Software Engineering Institute's Insights (blog)}, url={https://insights.sei.cmu.edu/blog/security-pattern-assurance-through-round-trip-engineering/}, note={Accessed: 2024-Sep-27} }

Security Pattern Assurance through Round-trip Engineering

Rick Kazman

January 20, 2014, published in.

Software Architecture

The process of designing and analyzing software architectures is complex. Architectural design is a minimally constrained search through a vast multi-dimensional space of possibilities. The end result is that architects are seldom confident that they have done the job optimally, or even satisfactorily. Over the past two decades, practitioners and researchers have used architectural patterns to expedite sound software design. Architectural patterns are prepackaged chunks of design that provide proven structural solutions for achieving particular software system quality attributes , such as scalability or modifiability. While use of patterns has simplified the architectural design process somewhat, key challenges remain. This blog explores these challenges and our solutions for achieving system security qualities through use of patterns.

One common approach for realizing system security is through authentication and authorization. The question for the architect is "How do I design them into the software? What do I have to build in to achieve them?" To resolve this dilemma, the developer might choose to use a pattern. By way of analogy, a building architect might decide to make a truss to support a roof and so choose one of the standard available designs for trusses. The architect is starting with a pre-packaged piece of design. A pattern in software architecture is a piece of design, just like a truss in a physical building.

It is commonplace, however, for developers to implement architectural patterns incorrectly. Due to such factors as ambiguity in specifications or miscommunication during the development process, the transition from design to code often does not go smoothly. Translating patterns into code involves the risk for error that is inherent in any translation process. Moreover, there are interpretation issues regarding how any pattern should be implemented; different programmers often implement the same pattern differently.

Patterns also degrade over time, due to changes made during maintenance. Programmers often insert seemingly innocuous changes to the code without realizing that they're actually undermining the intent of the pattern. For example, let's say that you're designing a system where A should never call B directly, for various reasons, e.g., because you don't want them too tightly coupled or because they're in different security domains. To resolve this you insert C, an intermediary (sometimes called the Mediator pattern) . But later a programmer comes along and looks at the code and thinks, "Well it looks to me like A can just call B," and changes the code, without understanding the design intent. The programmer can't see the grand plan from looking at the minutiae. In this way, even good designs typically are undermined--they erode and degrade over time. For some system qualities, such as modifiability, this is bothersome. For security, it is potentially fatal.

I along with my colleagues-- Jungwoo Ryoo of Pennsylvania State University and Amnon Eden of the University of Essex, U.K--developed an approach to address these challenges. Our approach comprises two major components: the design guide and the Two-Tier Programming (TTP) Toolkit , described below.

In the design guide, we first provide natural language descriptions of approaches for achieving design intent. If your purpose is to achieve security, for example, your design intent might involve detecting, resisting, or recovering from attacks on your system. To help you realize your intent, the guide presents a hierarchy of tactics for building in security. Tactics form the building blocks of patterns. To continue a previous analogy, if a pattern is a roof truss, a tactic is a component of that truss: a chord, web, or plate. Tactics involve a more fine-grained level of design than do patterns.

Hierarchy of Security Tactics Presented in the Design Guide

In the figure above, you'll notice that Limit Exposure is categorized as a tactic for resisting attack. The Limit Exposure tactic minimizes the "attack surface" of a system; it typically is realized by having the least possible number of access points for resources, data, or services and by reducing the number of connectors that may provide unanticipated exposure. This tactic focuses on reducing the probability of and minimizing the effects of damage caused by a hostile action.

The Limit Exposure tactic is associated with patterns that build in security, such as the Check Point pattern. This pattern monitors incoming messages, to determine whether they are consistent with a given security policy, and triggers countermeasures if necessary.

After you have chosen the pattern and its associated tactics for achieving your design intent, these must be converted into code. As mentioned above, whenever you undertake such a translation step, you have the possibility of producing an inaccurate translation.

To solve this challenge, our approach requires that you express your chosen pattern by creating (or, even better, reusing) code charts. Code charts are formal specifications that model and visually depict a program's structure and organization. The figure below shows the Check Point pattern as expressed through a code chart.

The Check Point Pattern as Represented by a Code Chart

You create the code charts through the Two-Tier ProgrammingToolkit , the second element of our approach.

Two-tier programming integrates the representations of both design and implementation. Frequently, when a system undergoes redesign, the changes between the design and the code that implements it may not be coordinated, causing the design to deteriorate. To maintain design quality, programmers must keep these two tiers coordinated through the software's lifecycle.

Our TTP toolkit is a round-trip engineering tool ; it maintains design and implementation as separate representations, while facilitating the propagation of changes between them. It supports round-trip engineering in that it has facilities for forward engineering (planning a new design and ensuring that this design is faithfully implemented by the code) and reverse engineering (determining what structures already exist in the code, and modeling those).

The TTP Toolkit was created by a team of colleagues at the University of Essex whom I joined in developing this tool. The program visualizations are reverse engineered from Java source code, and visual specification of object-oriented design is represented in a visual language (based on the formal specification language, LePUS3 ).

When you have created the code charts via the TTP toolkit, you will need to associate each pattern with the source code that implements it. To do this you simply need to associate (or bind) each variable in the pattern to a specific programming language construct. For example, the Check Point pattern makes use of a security policy, represented as "Policy" in the code chart. The Check Point monitors if messages are consistent with the Policy; if they are not, a counter-measure, represented as "Countermeasure" in the code chart, may be triggered.

Variables and Constants of the Check Point Pattern

Finally, the TTP Toolkit can check that your design is implemented correctly. The toolkit automates the verification process so that you can easily determine whether the code conforms to a tactic or pattern specification. The tool lets you recheck the design at the click of a button any time you make changes to the code, to assure conformance as the system evolves. This verification mitigates the problem of programmers' unwittingly undermining patterns during maintenance.

Successful Verification through the TTP Toolkit

Round-trip engineering tools usually support reverse engineering by generating visualizations from analyzed source code. If the output of the reverse engineering tool (in this case, code charts) can feed directly into the forward engineering tool, and vice versa, then the engineering cycle can be said to be closed--hence round-trip engineering. Closing the engineering cycle can ensure that anytime a gap between design and implementation is generated, it can quickly be detected and remedied. In summary, our approach involves these steps for achieving system security:

• Identify your security requirements to determine your design intent. Using the design guide, find security tactics to compose security patterns, creating a library.
• Through the TTP toolkit, convert this library of security patterns to code charts.
• Use the TTP toolkit to automatically ensure conformance of implementations to design specifications.

Wrapping Up and Looking Ahead

The design guide provides a natural language description of the architectural approach, guiding the architect from a statement of design intents to one or more tactics, which in turn lead to one or more patterns. We have already specified a large number of security patterns in the guide and the toolkit, and are adding more. While many patterns catalogs have emerged over the past two decades, what sets this work apart is that the toolkit adds rigor to the specification of a pattern and adds conformance checking to ensure that the design and implementation always stay synchronized.

This synchrony is essential. If developers don't maintain this coordination, then the software's design will certainly degrade over time, a condition referred to as " software entropy ." Every designer and project manager should be aware of this risk and concerned about reducing it.

It's useful, by the way, to note that the TTP toolkit has limitations and cannot check every property. For example, it can't tell you that A is going to happen after B, or is going to happen immediately after B, because those are temporal specifications, involving timing and ordering. The toolkit can only confirm structural properties, such as A calls B or A inherits from B. In other words, it can check static properties and relationships as opposed to dynamic properties and relationships.

We hope that our approach will enable practitioners to improve their design process and the software it produces. As with the introduction of any new technology, we expect to encounter some resistance to learning a new tool and a new formalism and concern about adoption risks. We also want practitioners to realize that this technology won't solve all of their design problems. It will solve some important ones, however.

If successful, the design guide and TTP toolkit will make it easier to maintain conformance and reduce the cost of doing so. Adopting our approach should result in higher quality design and implementation, in turn resulting in more secure implementations of designs. Please let us know your thoughts about the utility of this techniques in the comments section below.

Additional Resources

To read the book Software Architecture in Practice , which I co-authored with Len Bass and Paul Clements, please visit https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=30264

To read the paper Using Security Patterns to Model and Analyze Security Requirements by Sascha Konrad, Betty H.C.Cheng, Laura A. Campbell, and Ronald Wassermann, please visit http://www.cse.msu.edu/~cse870/Materials/rhas-03-CRC.pdf

To read the paper A Pattern Language for Security Models by Eduardo B. Fernandez and Rouyi Pan, please visit www-engr.sjsu.edu/fayad/current.courses/cmpe133-fall04/docs/PLoP2001_ebfernandezandrpan0_1.pdf

To read the paper In Search of Architectural Patters for Software Security by Jungwoo Ryoo, Phil Laplante, and Rick Kazman please visit https://dl.acm.org/citation.cfm?id=1591991 To read the paper Security Engineering with Patterns by Markus Schumacher and Utz Roedig, please visit http://www.uml.org.cn/sjms/pdf/PLoP2001_mschumacher0_1.pdf .

To read the paper, Architectural Patterns for Enabling Application Security by Joseph Yoder and Jeffrey Baraclo, please visit https://www.idi.ntnu.no/emner/tdt4237/2007/yoder.pdf

Digital Library Publications

Send a message, more by the author, tactics and patterns for software robustness, july 25, 2022 • by rick kazman, two categories of architecture patterns for deployability, february 14, 2022 • by rick kazman, rapid software composition by assessing untrusted components, november 26, 2018 • by rick kazman, prototyping for developing big data systems, july 25, 2016 • by rick kazman, a case study in locating the architectural roots of technical debt, may 16, 2016 • by rick kazman, more in software architecture, building quality software: 4 engineering-centric techniques, august 19, 2024 • by alejandro gomez, the osate slicer: fast reachability query support for architectural models, november 13, 2023 • by sam procter, how to use docker and ns-3 to create realistic network simulations, march 27, 2023 • by alejandro gomez, software isolation: why it matters to software evolution and why everybody puts it off, march 20, 2023 • by mario benitez preciado, experiences documenting and remediating enterprise technical debt, december 19, 2022 • by stephany bellomo, get updates on our latest work..

Sign up to have the latest post sent to your inbox weekly.

Each week, our researchers write about the latest in software engineering, cybersecurity and artificial intelligence. Sign up to get the latest post sent to your inbox the day it's published.

RTET - A round trip engineering tool

Ieee account.

• Change Username/Password
• Update Address

Purchase Details

• Payment Options
• Order History
• View Purchased Documents

Profile Information

• Communications Preferences
• Profession and Education
• Technical Interests
• US & Canada: +1 800 678 4333
• Worldwide: +1 732 981 0060
• Contact & Support
• About IEEE Xplore
• Accessibility
• Terms of Use
• Nondiscrimination Policy
• Privacy & Opting Out of Cookies

A not-for-profit organization, IEEE is the world's largest technical professional organization dedicated to advancing technology for the benefit of humanity. © Copyright 2024 IEEE - All rights reserved. Use of this web site signifies your agreement to the terms and conditions.

Tomsk topographic map

Interactive map.

Click on the map to display elevation .