Tag: Cradle

Cradle-SWE Module

The Cradle SWE module provides reverse engineering and code generation to maintain consistency between a detailed system design and its software implementation.

Software Engineering

There are many contexts for software engineering, each using its own methods and languages. This module is intended for groups using functional methods to build software in C, Ada or Pascal.

Detailed software designs are represented using Structure Charts (STCs) with 3SL extensions to support:

• Hierarchical descriptions of software into systems
• Programs
• Subsystems
• Modules and source files
• Representation of functions
• Representation of basic data types

Software designs are described with diagrams, data definitions and module specifications that hold the pseudo code, descriptions or source code. This software design is cross referenced to architecture, design/analysis models, to requirements/test cases, and to all other data.

The initial design can be code generated to:

• C, Ada and Pascal type definition header files (built from the model’s data definitions)
• Source files that contain the call hierarchy from the STCs
• Call arguments and local variable declarations
• Content of the STC’s module specifications’ pseudo code or detailed design material.

Once algorithmic content is added to the generated code, the resulting completed source files can be reverse engineered back into the Cradle database, to update its design diagrams, and both the data definitions and module specifications of these diagrams’ symbols.

Reverse Engineering

Reverse engineering merges the actual source code into the design definitions and specifications. Each source file is subdivided into the individual routines. The component parts are then stored into separate frames in the module specification and data definition items in the database. Every line in each source file is stored in a frame of one of these items in the database.

The Code Generator can be run on the results of the reverse engineering to reconstruct the source files, either as they were, or including any changes made in the design model. In this case, the source code is generated using call interfaces built from the (possibly modified) STCs and the routines’ bodies are created from either the STC call hierarchy or the source code from the previous reverse engineer operation.

The process can start by reverse engineering legacy source code into an initial design model, recovering designs in situations where only the implementation currently exists.

As reverse engineering loads all source files into the database, the source files could be deleted, and instead configuration managed through the Cradle Configuration Management System as part of the design.

The diagrams, specifications and data definitions can contain any number of attributes, including URLs to reference the source code in a source code control system, such as Git or Subversion.

Format of Generated Code

The format of all generated code can be tailored to match your coding standards. Data definitions can be marked to be standard data types and generated into the source code. Header files can be produced from the composition specifications inside the data definitions to create record and variant structure declarations.

Support

The reverse engineering tool supports any compiler programs and conditional compilation directives. It can distinguish application code, application libraries and standard library or operating system / runtime routines, and render the design diagrams accordingly. This uses any combination of regular expressions, and Cradle-supplied or user-defined library routine lists.

Reverse engineering can process one or more source files in one run, creating a hierarchy of design diagrams to represent the code structure beyond individual source files.

Full Traceability

Using the reverse engineering tool creates full traceability across the entire system lifecycle, from user needs to system requirements to analysis, architecture and design models, to test procedures, specifications and test cases, to the source code. Cradle’s transitive cross reference view facilities allow users to directly see the user requirements and acceptance criteria associated with each source code module, and vice versa.

Feature Summary

Please contact 3SL for further information about adding a Cradle SWE module to your existing system.

Cradle-PERF Module

The Cradle PERF module applies user-defined calculations to an architecture model, to compare the performance of alternative architectures and apportion performance budgets to subsystem, component and equipment designs.

Simulation is an activity to reproduce a system’s behaviour in an artificial environment to test the system in a variety of scenarios. Simulation is used where testing the real system is either dangerous, impracticable or too time-consuming or expensive. The most fundamental behavioural characteristics of systems are set early in the design process, as alternative architecture topologies are assessed and performance budgets are set. But as there is no behaviour allocated to the components, it is not possible to build a simulation.

Performance Assessment

Performance assessment solves this problem. It is used before behaviour is known and allocated and so before simulation can be used. It can be used:

• To confirm if a proposed architecture is viable
• To compare performance characteristics of candidate architectures
• To define budgets for lower design levels (apportionment)
• To aggregate actual values

Performance assessment is expressed in user defined characteristics, typically concerned with timing, data error or precision, such as:

• Bandwidth
• Utilisation
• Size
• Cost
• Data rate
• Staleness
• Weight
• Power

They can be subdivided, for example to study best case, worst case and typical conditions. They are held as user-defined formulae in the specifications and data definitions of the symbols in the architecture models’ diagrams.

Performance Characteristics

Any number of performance characteristics can be defined and associated with each diagram symbol. Each has its own formula. These are defined using a function library and user-defined calculation routines. This library contains logical, arithmetic, logarithmic, exponential, ladder, table lookup and interpolation routines, amongst others.

System performance requirements are applied as constraints to these characteristics by linking the items in the database and defining ranges of values for the performance characteristics that should not, or may not, be exceeded.

Analyses

Analyses are run on state models that are sets of interconnected diagrams at appropriate levels in the architecture.

A state model can have external loads applied to it to represent different usage scenarios. An analysis can contain many such environmental loads. The environmental loads are defined as values of any of the performance characteristics at the external input(s) to the model.

Each analysis applies the environmental load and calculates performance characteristics for all of the symbols in the state model’s diagrams using the formulae and constraints in each symbol. The results are therefore quantitative. They are stored inside the symbols’ descriptions.

The results can be reported in the same manner as other information in a Cradle database. They can also be graphed. The graphs will typically show the values of specified characteristics along a path through the model, termed a thread. Each graph will show any constraints applied from the system requirements and the effect of the constrains on the analysis results. The data in such graphs can be exported to CSV.

Any number of thread analyses can occur.

The results will show that an architecture is viable if none of its constraints are violated.

Since the performance data is built into the architecture model, any changes to the model’s topology (such as a change to the architecture) will be automatically reflected in changes to the performance results. This allows easy comparison between alternative architectures.

The analysis results are the characteristics of a viable architecture. Hence, they are the constraints or budgets for the next level of design. So the analysis of each level produces performance constraints for the next level. This process can continue through the design levels until the system behaviour is sufficiently defined for simulation to be practicable.

Feature Summary

Please contact 3SL for further information about adding a Cradle PERF module to your existing system.

Cradle-SYS Module

The Cradle SYS module provides an analysis, process, architecture and design modelling environment that, being linked into the systems engineering lifecycle, provides full traceability and coverage for all model information. You can use SysML, UML, ADARTS, SASD, eFFBD, IDEF, BPM and other notations to achieve your MBSE goals.

Models

A model is an abstraction of an aspect of a system being developed.  Therefore, models should not be separate from the needs, goals and objectives that the model seeks to satisfy, nor from the tests that validate the system’s compliance. Hence Cradle integrates modelling into all requirements and other systems engineering data, so every component of every model is traced to the highest level user need and to the lowest level test result.

This applies to agile and phase-based processes. An agile process has no less need for models simply because its iterations are short. To neglect rigorous design in agile projects will ultimately compromise the system if a clear design is not modelled at the outset and maintained through each iteration.

Domains

Each Cradle database provides analysis and design domains. Each domain can contain any number of models, optionally organised in hierarchies. Models can be used to represent concepts such as:

• Alternative missions in a CONOPS
• Products within a range
• Regional variants of a product
• Comparative analysis of architectures

Each model contains any number of diagrams from a wide variety of notations.  Each diagram contains symbols, and each symbol is described by a data definition or specification.

All diagrams, specifications and data definitions in a model can be cross  referenced to each other and to information in all parts of the lifecycle. So user requirements can be linked to use cases, that are linked to system requirements, that link to a logical model of system behaviour, that can be allocated to a logical architecture, which in turn can be allocated to multiple physical architecture models for assessment.

A System Breakdown Structure (SBS) is useful as an abstraction of the system composition, and as a single structure to which all the requirements can be linked. The alternative system architectures and designs can be explored, each in its own model, all models linked to the SBS. This simplifies traceability for the requirements and the performance constraints, without restricting the modelling activities.

Models can link to a Product Breakdown Structure (PBS) to allow linking to a PLM environment.

Diagram Notations

Cradle has over 20 diagram notations from methods including UML, ADARTS, IDEF, SASD, SysML and data, process and architecture modelling. The notations can be combined when semantically viable. Cradle does not limit you to one method, nor constrain your choices for the notations that will best express the system for the audience of that model.

Cradle provides a consistent, interface to building diagrams. It includes time-saving features to build diagrams in time-sequenced notations, such as Process Flow Diagrams (PFDs) and extended Function Flow Block Diagrams (eFFBDs).

In hierarchical notations, Cradle has a range of features to build both child and parent diagrams that are automatically consistent.

Consistency Checking

Cradle enforces diagram syntax when editing. Completeness and I/O consistency checks are provided, both within a diagram and between diagrams to ensure conservation of data and function. Cradle can also check the consistency of diagram graphics and text descriptions. For notations that use it, Cradle provides a full Data Dictionary with a formal BNF notation to describe data composition.

Bitfields

In architecture models, Cradle supports data protocol descriptions across interfaces and can generate message formats (bitfields) that describe the formatting of the messages in all data exchanges.

Symbols

Diagram symbols can be coloured and have embedded graphics, to ease users’ understanding of the model.

Notations and Models

Notations can be combined, such as using UML and other diagrams in the same model. Some notations can be used in many contexts. For example Sequence Diagrams (SQDs) can show a message protocol across an architecture model interface, their role in SDL before their use in UML.

All model elements can contain graphics, video, figures, tables, equations, URLs and integrate with desktop tools including Visio, Word, and Excel. Each diagram, data definition or specification is an item in the database and so can contain any number of attributes each containing, or referencing, up to 1 TByte of any type of data.

Configuration Management

Models have change histories, discussions, comments, are formally reviewed in Cradle’s CM system, and can be baselined.

Reports

Models can be printed to a variety of devices. They can be part of user-defined documents with requirements, tests and any other information. Models can be published into static, hyperlinked websites that provide links between diagrams and between symbols and the descriptions. All Cradle web UIs support viewing and navigation of models.

Import/Export

Models can be loaded from other tools by import or data conversion from other tools’ data formats or XML.

Feature Summary

Please contact 3SL for further information about adding a Cradle SYS module to your existing system.