feature article
Subscribe Now

Coverity Enforces Software Architecture

There’s a school of thought that says that you should write your comments first and the code afterwards and that source code should be treated as a human-readable document that only incidentally contains instructions for the computer. In other words, if you write code that other programmers can understand, you’ll automatically write code that’s more efficient and maintainable. Who knows, some day you may need to revise your little gem, and you don’t want to be caught wondering, “What was this part supposed to do?”

By the same token, diagrams and flow charts aren’t just for maintenance and documentation. Writing (or even sketching) complete design documents before the code starts flying can help everyone visualize the overall application — to see what goes where. That’s particularly important for large programming teams where the work is divided up amongst individuals who may or may not share the boss’s big-picture view.

A company called Coverity is automating this whole process with its “Architecture Analyzer” product. As the name suggests, Architecture Analyzer analyzes the, uh, architecture of your software. It’s a detailed, automated, corporate safety net for large programming projects that eliminates bugs at the source. Which is to say, it prevents you from writing faulty code in the first place, rather than having to debug it afterwards.

Magic, you say? Not really. Just the methodical enforcement of good programming practices. Practices, it must be said, that many programmers despise.

Like a third-grade penmanship teacher, Coverity’s Architecture Analyzer (CAA) encourages you to write neatly and between the lines. It’s all about clarity, repeatability, and good manners. In programming terms, CAA enforces clear thinking, well-defined interfaces, and adherence to the API rules.

That’s more structure than many programmers like – but exactly what their bosses crave. CAA is the antithesis of the cowboy code jock slinging code in the middle of the night, hacking functions and fixes in a caffeine-crazed blur. In contrast, CAA is all about premeditation, good code hygiene, and clear documentation. By enforcing those rules, it eliminates the source of many bugs, reliability holes, and security leaks.

Architecture Analyzer is graphical. You diagram the overall structure of your application with boxes and arrows. Boxes represent functional units of code, while arrows reflect how data passes in and out of these boxes. No arrow, no communication with the black box. This flowcharting process is central to Coverity’s fault-checking process. It also, not incidentally, forces the programmer to take a big-picture view of his overall project and outline just how processes and functions will interrelate. Seat-of-the-pants code hackers need not apply.

You can diagram your application code any way you like. CAA doesn’t enforce any particular style or architecture; that’s up to you. What it does do is make sure you stick to your own rules, and that those rules are self-consistent. If you’ve defined a function with one data source and one sink, for example, CAA will make sure no other functions call or depend upon that module.

Once the diagramming is done, Coverity’s tool analyzes the information flow and looks for unintended back doors. Is there, for example, a way to pass information into a control block without first passing through its encryption API? Can one process snarf data from another unintentionally, accidentally, or maliciously? Have you created any circular dependencies?

What CAA doesn’t do is nit-pick individual lines of code. That’s what compilers and lint checkers are for. CAA is strictly a big-picture tool, making sure that the structure of your application is sound, reliable, and free from loopholes that might present problems later on. You’re still free to write comments and indent lines any way you like.

On one level, CAA works simply because it forces programmers to graph out their application. That’s already more discipline than some programmers usually demonstrate. The very act of diagramming a program’s overall architecture will highlight certain structural problems. In the early stages, it almost doesn’t matter that CAA even has an analysis back end; the diagrams themselves are diagnostic.

But of course, Coverity’s back end does perform elaborate and detailed analysis. Once your flow diagrams pass the “sniff test,” they become enforceable design blueprints. CAA makes sure you stick to the architecture you defined without straying from the ins and outs described in the diagrams. Naturally, you can revise your architectural diagrams whenever you like, but doing so may affect the code development already underway.

Coverity’s Architecture Analyzer can prevent (or at least forestall) software “entropy” as the design ages and the code accumulates hacks, cruft, and patches. It stands as a shining beacon of the original program architects’ intent and structure. It prevents quick fixes from circumventing (either deliberately or accidentally) intended procedures, built-in security mechanisms, bounds checking, parameter inspection, and so on. It’s a silent QA manager looking over your shoulder to be sure you don’t outsmart yourself or the other programmers or wind up creating spaghetti code that no one else can maintain. In short, CAA tries to make you a better programmer.

Not everyone wants that. Programming is often treated as a creative endeavor, undertaken by spirited and talented artistes who cannot or should not be shackled to convention, regulations, or reasonable hygiene. Get over it. Programming is a job like any other, and an employer’s responsibility is to ship a profitable product, not coddle and babysit self-indulgent hackers. While some programs can be created by individuals working solo, it’s more common for teams of coders to work cooperatively, and, for those times, a tool like CAA is probably a prudent business investment. It’s said that communication gets exponentially harder the more members involved, so it’s not surprising that miscommunication can be a big problem in large programming projects. Codifying that communication (some of it, at least) through CAA eliminates one source of miscommunication and adds rigor to an otherwise ad-hoc process. In the realm of commercial software development, that’s got to be a good thing.

Leave a Reply

featured blogs
Sep 30, 2022
Wow, September has flown by. It's already the last Friday of the month, the last day of the month in fact, and so time for a monthly update. Kaufman Award The 2022 Kaufman Award honors Giovanni (Nanni) De Micheli of École Polytechnique Fédérale de Lausanne...
Sep 29, 2022
We explain how silicon photonics uses CMOS manufacturing to create photonic integrated circuits (PICs), solid state LiDAR sensors, integrated lasers, and more. The post What You Need to Know About Silicon Photonics appeared first on From Silicon To Software....
Sep 22, 2022
On Monday 26 September 2022, Earth and Jupiter will be only 365 million miles apart, which is around half of their worst-case separation....

featured video

PCIe Gen5 x16 Running on the Achronix VectorPath Accelerator Card

Sponsored by Achronix

In this demo, Achronix engineers show the VectorPath Accelerator Card successfully linking up to a PCIe Gen5 x16 host and write data to and read data from GDDR6 memory. The VectorPath accelerator card featuring the Speedster7t FPGA is one of the first FPGAs that can natively support this interface within its PCIe subsystem. Speedster7t FPGAs offer a revolutionary new architecture that Achronix developed to address the highest performance data acceleration challenges.

Click here for more information about the VectorPath Accelerator Card

featured paper

Algorithm Verification with FPGAs and ASICs

Sponsored by MathWorks

Developing new FPGA and ASIC designs involves implementing new algorithms, which presents challenges for verification for algorithm developers, hardware designers, and verification engineers. This eBook explores different aspects of hardware design verification and how you can use MATLAB and Simulink to reduce development effort and improve the quality of end products.

Click here to read more

featured chalk talk

Enabling the Flow of Data in the World of IoT

Sponsored by Mouser Electronics and YAGEO Group

At the heart of our growing IoT ecosystem are high performance semiconductors, but integrated circuits alone cannot make a successful IoT system. In this episode of Chalk Talk, Amelia Dalton chats with Peter Blais from KEMET and Ryan Wenzelman from Pulse about how passive components are crucial to the development of successful IoT frameworks. They take a closer look at RF, wired and power distribution aspects of IoT system development and investigate how YAGEO Group is advancing innovation in the world of IoT with a wide selection of passive components.

Click here for more information about Pulse Electronics World of IoT