Rapid Integration with Confidence

As software systems become more complex, adaptive, and resilient, managing them can be a real challenge. To effectively tackle complexity like this, mathematician Freeman Dyson suggested that two perspectives are useful. The perspective of frogs and that of birds. On one hand, frogs see the details. They are close to the ground and can see in high resolution what is right in front of them. On the other hand, birds see the big picture. From high above it is the dynamic interrelationships, not the details, that are in their view. From Dyson's example of frogs and birds, we can learn that complexity has two sides.

It turns out understanding both detail and dynamic complexity for elaborate software systems, is critical for ongoing maintenance and integrating new capabilities. But too often the treacherous gap between software and system engineers prevents the birds and frogs from sharing what they know.

We made Tangram Pro™ to help system and software engineers cross that treacherous gap so that frog style, detail complexity and bird style, dynamic complexity could be more easily understood, shared, and managed. When this happens and the treacherous gap is crossed, software and system engineers can rapidly integrate new Components into their systems with confidence!

You'll learn how Tangram Pro™:

Defines Transforms
Leverages Flex to rapidly integrate with confidence
Connects Components with a Transform
Generates executable Transform code
Easily swaps Components

What is a Transform?

Tangram Flex thinks of Transforms as the relationships between different representations of data that allow software Components to interact. In other words, a Transform describes how to derive a “Message B” from a “Message A.” Manually writing that description, or Transform code, can be quite tedious. Plus, there may be new vulnerabilities introduced into the system.

Tangram Pro™ uses Flex, a specification language, to describe Transforms. Flex enables accurate transform specification and can be transpiled into a variety of languages and output formats. When a Transform is written in Flex, the author can be confident that the code will only do what it is intended to do because of the formal mathematical specification behind the language design. Then, once the Transform is made available in Tangram Pro™, it can be reused in that instance across teams and systems to optimize the original engineer's effort. Reducing rework and saving time through automation is just plain great.

Connecting Components with a Transform

In the example below, you can see how this plays out in Tangram Pro™. What you are seeing is an new Component being added to the system you built in the previous tutorials. The difference is that this new Component does not speak LMCP. Instead, the new Component uses an international message specification called STANAG4586. Because one of our engineers used Flex to manually write the LMCP to STANAG4586 message Transform and made it available in the product, it can easily and automatically be leveraged in the system when connecting Components.

Generating Transform code

In the same way that you generated a CSI from a Build in an earlier tutorial, you can generate Transform code with Tangram Pro™. With the Transform now included in the system design, running a Build will generate Transform code.

Swapping Components

Whether Components are using the same message set, or are connected with Transforms, the ability to safely swap Components is a powerful feature that helps manage emergent, or unexpected behavior. Here you can see that one Component is effortlessly swapped with another Project in Tangram Pro™.

So, how is the emergent behavior managed? Well, the answer is in Component Interfaces and their specification in Tangram Pro™. In other words, a Project can be swapped for a Component as long as they conform to the specified Interfaces. Notice that when the Component and Project above are swapped they are very different internally. One has no internal sub-Components, while the other has internal sub-Components that are leveraging a Transform. The key is that both the Component and the Project, while very different, conform to the specified Component Interface. This means they can be swapped without disrupting the rest of the system!