The challenge of automating, especially, non-trivial systems is the rising cost curve for further changes as the system grows in complexity. But let’s see how they summarize the problem we talked about previously: They had a very nice way of explaining what the problem is, which I felt was true but at the time of reading could not be put into context. It seems I am not the only one having similar thoughts: there is actually a new movement and technique called event modeling trying to provide a solution for the same problem. But I started thinking: why is it so? Am I just accepting the status quo, or we, as an industry, are doing something incorrectly? As a developer I always thought that this is normal: business cases are implemented in the code, and as more business cases are implemented, the codebase becomes more complex, therefore it needs more time to check and understand. As more and more functions were required to be implemented it was soon realized that the required business use cases and the implementation diverged drastically: in order to check if, where and how a business case was implemented the codebase the answer was the usual: I need some time to dig through the code. This worked perfectly when we needed to write a very simple plugin. This business logic might have accessed multiple components either for read or for modification purposes, it also might have read from the file system or created some model elements, even diagrams in the current project. Since our first plugins were very simple, we followed a very common pattern: add an event listener on the component triggering the execution of some business logic. What we found however is that a standard backend developer working with Java can pick up the necessary skills rather fast. This is an advantage and a disadvantage as well, the advantage is that the system is mature, the disadvantage is that nowadays not many people are writing desktop applications in Java therefore the talent pool is limited. Technologically speaking MagicDraw is a standard desktop application written in Java, using the well known Swing GUI Widget toolkit developed around 2007. Plugins might be developed in various languages, but the most common language used is Oracle’s Java. MagicDraw allows developers to extend the functionalities of the product using so called plugins. MagicDraw is a modeling tool developed by NoMagic acquired recently by the french company Dassault Systèmes. During the design of the system we realized very soon that certain functionalities are not provided by the vendor or third parties therefore we decided to develop them on our own. Our company uses MBSE/SysML with MagicDraw to design our distributed, microservice based software solution for digital certificates. The following article describes the lessons learned during the development of plugins for Catia’s MagicDraw.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |