Category Archives: Case Studies

How to Create a FreeRTOS™ “Blinky” Application for the Microchip PIC24FJ256GA7 Curiosity Board

Published by:

This is the first post of a short series about model driven engineering using State Machines.
Here we are going to prepare the development environment for the next steps. Since modeling using state machines is particularly suitable for embedded environments, we are going to use the indicated (inexpensive) board from Microchip.

Continue reading

Legacy Code: How To Reverse-Engineer

Published by:

1. Introduction

In a previous post I came to the conclusion that reverse-engineering might be needed the most by new team members working in an already established project.

This covers the scenario when knowledge is not widespread and there is little time to get “the full picture” of what’s going on before being asked to be a contributive member of the team.

The only possibility is to go through the code and try to understand what the team has come up with over the lifetime of the project. Of course, experienced and /or talented programmers could be able read and understand the code fast, but they would still need to rebuild all the discussions with the customers, if they want to understand what the system is supposed to do. For the latter, some diagrams can definitely help.

In principle, reverse-engineering should be used to bring source code into a Model Driven Development process and, for this reason, it should be necessary only once. However, I have seen the process applied either just once to create some diagrams and produce some kind of documentation, or by having someone doing it regularly from the source code, just to maintain the diagrams in sync with the code. I normally call the output of the latter case UML “pictures” or “paintings“and not “diagrams“, because they are not used to communicate among stakeholders before or during development, but probably only for some contractual clause.

Instead, I’ll identify some clear objectives that, depending on the size of the project, can be achieved relatively quickly. We are going to use our tools

  1. to identify all the entities defined in the source code to implement the system
  2. to model the most important relations between the defined entities.

Continue reading

Model Driven Development: The Basics (Part II)

Published by:

In Model Driven Development: The Basics (Part I) we have set up an environment for modeling a system with Enterprise Architect and for generating C++ code to be compilable in Visual Studio.

In this second part of the post we are going to build on that and see how some fundamental entitites in UML are translated into C++. This should give the readers enough experience to play with the basics of MDD and be able to find more advanced features themselves. For brevity I am not going to describe in detail how to access features which have already been described in Part I.

1. Add an Attribute to the Logger Class

The objective of this activity is to put in the Logger class an element which records the current required level of tracing. As usual, we want to use UML while keeping in mind that we want the tools to generate valid C++ source code from that.

Continue reading

Model Driven Development: The Basics (Part I)

Published by:

In a previous post we have identified the need to have a translator from the UML language, which is used to capture requests from customers, to the programming languages used by software developers to make computers fulfill those requests.

The good news is that several products have been developed and are currently available to perform that task. Every tool that offers the possibility of “round-trip engineering” is a candidate. The scope of this post is to show how a specific tool implements it and how we can take advantage of what is available.

Prerequisites are a basic knowledge of

  • the object-oriented paradigm
  • the UML language
  • the constructs of the C++ implementing the object-oriented paradigm. I am using C++ because of my experience and also because it is the language that, at least in my opinion, presents more challenges than others in this field. However, We’ll be focusing on an embedded environment in this example and for this reason we’ll be using C++ syntax, but not the C++ Standard Library. There are reasons, both technical and commercial, for not using the STL in embedded environments, but this might be a subject for a different post.
  • the User Interface in Microsoft Visual Studio

Several good resources on those subjects can be found online.

The presentation of the subject here is going to be generically applicable in different environments. However, in order to be able to present some practical examples, I am going to use

  • Sparx Systems Enterprise Architect rel. 13.5, Professional  Version, as a UML modeling tool. At the time of writing, a 30-day trial version can be downloaded from here.
  • LieberLieber Embedded Engineer rel. 2.1, an add-in for Enterprise Architect that improves the capabilities for code generation from a model. At the time of writing, a 90-day trial version can be downloaded from here
  • Microsoft Visual Studio 2017, Community Edition. Disclaimer: only sofware covered by Open Source licenses is going to be used here and for this reason I can use the indicated version of the development environment. The business environment of the readers can be different and I can’t give advice about the suitability of any licensing in their case. Please check before using the tool) The different versions of the development environment are available here .
  • Microsoft Windows 10 operating system.

Continue reading

Model Driven Architecture: Why We Need It

Published by:

It is very likely that whoever landed on this page doesn’t need the first few paragraphs, but bear with me a second, because I am at a point where I really think that we need to go back to where it all started.

Programming languages are tools developed in order to tell computers what we want them to do for us. More precisely, they are tools developed to speed up the process of telling a computer what to do. It is called “computer software“, or, for brevity, just “software“.

In order to use those languages, we rely on someone writing translators from the programming language we are using to the set of instructions that a processor can actually execute. This is because the different processors’ sets of instructions are in the vast majority of cases considered too primitive to be used in the production of usable software needed to be delivered within an acceptable time frame.

However, programming languages are still considered too technical by the vast majority of the population who can benefit from the use of computer software and for this reason there’s a community of technicians working to interpret the desires for computer programs coming from the population at large. Those technicians write sequences of orders to computer (kind of “speeches“) in those languages, also called “computer programs“, to satisfy the needs arisen from the rest of the community. It should also be discussed how those “needs” are created, but this might be a subject for another discussion.

So, here we are. In any software production activity we have three entities

  1. Computers
  2. Technicians
  3. Customers

Customers want Computers to do something for them, but only Technicians can tell Computers what to do.

And here is where the problems begin.

Continue reading