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
Jun 18, 2021
It's a short week here at Cadence CFD as we celebrate the Juneteenth holiday today. But CFD doesn't take time off as evidenced by the latest round-up of CFD news. There are several really... [[ Click on the title to access the full blog on the Cadence Community sit...
Jun 17, 2021
Learn how cloud-based SoC design and functional verification systems such as ZeBu Cloud accelerate networking SoC readiness across both hardware & software. The post The Quest for the Most Advanced Networking SoC: Achieving Breakthrough Verification Efficiency with Clou...
Jun 17, 2021
In today’s blog episode, we would like to introduce our newest White Paper: “System and Component qualifications of VPX solutions, Create a novel, low-cost, easy to build, high reliability test platform for VPX modules“. Over the past year, Samtec has worked...
Jun 14, 2021
By John Ferguson, Omar ElSewefy, Nermeen Hossam, Basma Serry We're all fascinated by light. Light… The post Shining a light on silicon photonics verification appeared first on Design with Calibre....

featured video

Reduce Analog and Mixed-Signal Design Risk with a Unified Design and Simulation Solution

Sponsored by Cadence Design Systems

Learn how you can reduce your cost and risk with the Virtuoso and Spectre unified analog and mixed-signal design and simulation solution, offering accuracy, capacity, and high performance.

Click here for more information about Spectre FX Simulator

featured paper

What is a Hall-effect sensor?

Sponsored by Texas Instruments

Are you considering a Hall-effect sensor for your next design? Read this technical article to learn how Hall-effect sensors work to accurately measure position, distance and movement. In this article, you’ll gain insight into Hall-effect sensing theory, topologies, common use cases and the different types of Hall-effect sensors available today: Hall-effect switches, latches and linear sensors.

Click to read more

featured chalk talk

Meet the Latest Wireless Member of the DARWIN Family

Sponsored by Mouser Electronics and Maxim Integrated

May 21, 2021 -- Your next MCU needs to be more than just smart. It needs to be power-efficient, have ample memory, and industrial-grade security. In this episode of Chalk Talk, Amelia Dalton chats with Zach Metzinger of Maxim Integrated about the latest member of the DARWIN family with a new RISC-V co-processor.

Click here for more information about Maxim Integrated MAX32655 Low-Power Wireless Microcontroller