Tag Archives: Control Flow

Software Reuse: Software Architecture

Posted on by
Reply

Modular Software

One of the primary goals of modern Software Development is the creation of code that is reusable. This is known as Software Reuse or Code Reuse and the results so far are pretty disappointing. There are a number of reasons for this:

 

  • There are multiple software architecture options available
  • There are multiple design methodologies available
  • There are multiple test methodologies available
  • There are different languages and runtime environments
  • It is hard to conceive of all the way a module might need to operate in the future
  • Requirements capture is still not a reliable process
  • Making code too general can also make it unwieldy to use
  • Documenting code so it can be used again is not easy

 

This begins a series of posts looking very briefly at each of these factors.

 

Software Architecture

I consider Software Architecture to be a fundamental component of the success of a software system. But there is a strong dependency with requirements capture. Because the purpose of choosing a particular architecture is to satisfy the requirements within constraints such as the Hardware Platform.

 

Grady Booch is one of the world’s leading experts on Software Architecture and had an excellent series of podcasts at On Architecture.

 

Software Architecture

Software Architecture

The diagram above shows a simple Software Architecture for a process control module. It is missing the link that shows how the messages or instructions with the control tags get to the module, but it does show how the system components relate to each other after that. Like most software problems, it has to be abstracted so we can handle the details in bite sized chunks (or should that be byte sized chunks?). In this case the elements being managed are:

 

  • inputs from a machine under control
  • outputs to control the machine
  • a start-up and shut-down process
  • a human interface device so users can either get reports from the system or interact with it
  • some form of control language using tags that defines the machine control

 

And the Software Architecture shows that there are several internal processes for handling the inputs, outputs, HMI and control tags.

 

The original concept of Software Architecture comes from real architecture. There are foundations, services, facilities, reception, storage and other floors all the way to the top floor. The highest floor represents the highest level of abstraction and generally the highest value adding process. The foundations represent the things that must exist or there can be no system. These are generally the lowest level drivers and IO device controls. And the diagram shows how the pieces relate to and depend upon each other.

 

And of course, all the floors need to be connected, so you have elevators, stairs, electrical cabling, networking, air conditioning, water and other plumbing. These are like the operating and communications systems.

 

Things that need to be clearly defined for a system to be able to be designed with confidence are:

 

  • Control Flow – how is control and execution managed?
  • Data Flow – how is information moved around the system?
  • Timing and Latency – what tasks and response are time critical and which can be handled whenever they can be fitted in?
  • What are the system constraints: memory, speed, worst case response times

 

From this you can design your Software Architecture just like an Architect designs a building.

 

Next we will look at Operating Systems and how to determine the level of complexity needed.

 

Successful Endeavours specialise in Electronics Design and Embedded Software Development. Ray Keefe has developed market leading electronics products in Australia for nearly 30 years. This post is Copyright © 2011 Successful Endeavours Pty Ltd

Squash Lessons for Engineering

Posted on by
2

Squash Lessons for Engineering

The picture in today’s post comes courtesy of Dr Marc Dussault, The Exponential Growth Strategist. At his recent Exponential Business Building Bootcamp, he demonstrated how a Squash Racquet gets broken from repeated use.

 

Broken Squash Racquet

 

So what does this have to do with Engineering? Glad you asked.

 

First, I have to explain the demonstration. Marc showed that it takes a very large amount of force to break the Squash Racquet. He really applied himself to the destructive task and it took a few minutes of escalating Squash Racquet abuse before it finally succumbed and broke. Some of us in the front of the room could tell just how much it required to break the Squash Racquet. However the Squash Racket already had a crack, so Marc knew where to apply the force in order to break it. The picture above is the final outcome. Without the crack being obvious, it would have been almost impossible to have broken the Squash Racquet using just randomly applied force.

 

Marc then explained that way the Squash Racquet became cracked in the first place, was by it being consistently scraped along the wall as he retrieved the ball from shots along the wall. Marc is an outstanding competitive squash player and currently ranks as World # 18! So he knows his stuff when it comes to squash. You can read more about this at his Mindset Of A Champion blog.

 

So if you know what to look for, you can monitor the thinning of the racquet and get an idea of when and where it might fail. If you don’t know what to look for, then the failure will be unexpected.

 

Software Testing and Software Engineering

A lot of Software Testing can suffer from the same problem. If you already know where the weakness will be and how to spot it, then finding a bug is easy. You can set up the scenario, monitor for the symptom and confirm the failure. Or, if you have enough resources you can go the brute force approach and just break it through the persistent use of randomly directed and escalated force of testing. However very products are simple enough and very few companies are large enough to have that level of resource and to solve the problem this way. So for the rest of us, the other 99.995%, a more intelligent approach is needed.

 

Since you don’t know where and when it will fail, it is best to remove failure causes from the beginning. This is where Software Engineering come is. Software Engineering is not just coding. Coding is the production end of the Software Engineering process. Software Engineering is about designing the system so you have defined the components so they are each fully testable in their own right. Then you can apply processes like Unit Testing to ensure they are fully functional as stand alone pieces of software. You can then perform Integration Testing to ensure that software added to the system correctly handles both the Execution Flow, also known as Control Flow, and Data Flow required including error and Exception Handling. The result is that you build up a fully working and correctly executing system quickly and with great confidence. It isn’t a magic bullet but it is close to it.

 

As was famously quipped by Edsger Dijkstra, “If Debugging is the process of removing bugs, then programming must be the process of putting them in”.

 

So if you put less bugs in, you have less debugging to do. And that saves time and removes future time bombs. Because the chance that you find them all is zero percent. And you can’t create a system that is 100% testable by brute force means. So you have to go about it smarter. It will save time, money and improve the business outcome now and into the future.

 

Ray Keefe has been developing high quality and market leading electronics products in Australia for nearly 30 years. For more information go to his LinkedIn profile. This post is Copyright © 2010 Successful Endeavours Pty Ltd.