How to keep your Simulink customizations organized? »

Simulink and Stateflow offer ways to customize the modeling environment. You may for example add a menu to the Simulink Model Editor, or add menu items to existing Model Editor menus. Customizations are a practical way to create shortcuts, allowing you to be more productive in Simulink. However, it can be hard to keep a clear oversight of the customization implementations. The two main reasons are:

  1. Each customization needs a function to implement the callback, and a function to register it. In addition, separate functions are required to define and register the menu with the Simulink Customization Manager. Consequently, if you have multiple customizations for diffent projects or contexts, the number of functions will grow rapidly, and significant bookkeeping is required.
  2. If you work on different projects you might want to make a selection of the customizations you find useful. Or, you might want to target customizations to a specific context. In these cases, the default approach, a single sl_customization.m file with numerous sub functions, will be cumbersome. The alternative approach, multiple sl_customization.m files in different folders, may lead to a messy folder structure.

This calls for a structured approach. Below we present one, and share the code.

EDIT 22 March 2017: Code and MATLAB App can be found on GitHub and MATLAB Central File Exchange from now.

Example

In the example below we add the menu “My Menu” to the Simulink Editor’s menu bar. It contains two custom utility commands.

keep_work_organized_menu_small

The first, “Match Size”, matches the size of selected blocks. This can also be arranged via the Simulink context menu, however the customization adds a keyboard shortcut to it.

MatchSizes

The second, “Make Constants Orange”, colors all Constant blocks in a model orange, which reflects a convention.

ColorBlocksOrange

The unstructured approach

All code is in one sl_customization.m file, which has six sub functions. It works, but if you want to add more customizations this file will soon grow to a size that is no longer maintainable.

The structured approach

The two customizations in our example originate from different contexts: one is a general utility, the other part of a style guide. In the structured approach, separate packages (+styleguide, +utils) reflect the different contexts. Both packages contain a Customizer class. A single sl_customization.m file points to the Customizers employed in our model.

keep_work_organized_folder_structure

The idea is that we separate the definition of the custom menu and its contents from the implementation of the customizations. This way, we can add or remove menu items by editing a single line in sl_customization.m. Also, if we add customizations to a package, they will automatically appear in our custom menu.

The implementation reflects this separation. A generic class Customizer is the super class of the Customizer classes in the package folders. The super class contains a helper method getCustomizeMethods that will automatically assign the customizations to the menu. The customizers variable in sub-function customMenu (line 27) defines the items in menu “My Menu”. The Customizer super class will place a separator between customizations from different packages.

The Customizer class in the +utils package implements the details for the “Match Size” menu item: a registration method matchSizeOfBlocks and a callback sub-function matchSizeOfBlocksCb.

Similarly, the Customizer class in the +styleguide package implements the details for the “Make Constants Orange” menu item. 

In short, this structure allows to easily scale up the number of customizations. Also, it facilitates sharing and re-use. The full implementation of the structured approach is available for download. Use it to automate your repeat work and be more productive in Simulink/Stateflow!

EDIT 22 March 2017: Code and MATLAB App can be found on GitHub and MATLAB Central File Exchange from now.

Requirements – Why bother? »

thinkahead_brassWe regularly exchange ideas and opinions about Model Based Design and modeling using MATLAB and Simulink with our clients. Requirements are a recurring topic in these discussions. It is intriguing to observe that there seems to be no consensus about the virtue of requirements specification. In essence, writing requirements means specifying exactly what functions and qualities should be embedded in a product. Sounds like a logical first step in a design or development process. Does it?

Some companies rather skip requirements definition. They don’t see the immediate benefit. They feel it is complicated and slows them down. They find the administrative burden overwhelming; the requirements system appears rigid and cripples them. Indeed, drafting requirements requires patience and skills. It may be a challenging activity. It requires that the people involved agree on things early in the process, long before the actual product exists.

At MonkeyProof Solutions we are convinced that a structured requirements process has added value. Defining requirements forces you to think ahead. It helps to make implicit ideas explicit, and it is much easier to share, discuss, review, test, implement and improve explicit ideas. In fact, requirements definition directly relates to front loading: it facilitates teams to specify and test ideas early in the development process. A few quick-and-cheap requirements definition iterations early in the process may save many expensive design, implementation and test cycles later on. Clearly defined functional requirements speed up effective implementations. Thinking about non-functional aspects directly sets a target for performance and usability.

We acknowledge that requirements definition requires skills, tools and discipline. Skills you can train. It is our experience that peer reviews boost an engineer’s requirements skills. Tools for requirements management should fit your organization. Requirements tools that suit the workflow are helpful here. Discipline is a hurdle when skills and tools are not in place. We think that enforcing discipline is not necessary. Organizations better facilitate their workers by investing in effective training, automation of tedious tasks, and tools that fit the workflow. As soon as the benefits of requirements definition become clear, discipline is no longer an issue.

In short: requirements specification is a valuable activity, and quality requirements make up a solid frame of reference for design-, implementation- and test cycles. The trick is to keep requirements management practical and dynamic. Let us know if you want to discuss how.