The software architecture is one of the most important artifacts created in the lifecycle of an application. Architectural decisions directly impact the achievement of business goals, as well as functional and quality requirements. Yet once the architecture has been designed, most architectural descriptions are seldom verified or maintained over time. Architecture compliance checking is a sound application risk management strategy that can detect deviations between the intended architecture and the implemented architecture.
Third-generation programming languages (3GL) like COBOL or PL/1 are seen as outdated languages for “has-been” developers, and do not interest new ones anymore (there were even predictions saying that COBOL was going to die in mid-term.) These new developers prefer more modern technologies, like J2EE or .NET, and, worryingly, educational organizations provide few learning opportunities for 3GLs.
These days, it doesn’t matter where I go or which media channel I watch, I hear about the same thing: cost reduction. From governments to households to companies, budgets are on a diet — saving is the new sacred word. Therefore, everyone must do more with much less. When it comes to companies, the first budget to shrink is usually the IT budget. But what can be cut, and how?
Sometimes, entire projects are stopped. With luck, maybe only features will be abandoned.
Sadly, lowering the cost to develop or maintain a project doesn’t lower customers’ expectations. In fact, those expectations increase as time passes and customers’ needs stay the same: They want better, faster, and more complete applications. And it goes without saying that the application has to be rock solid, because a deceived customer can quickly turn into an ex-customer.
But the “fat” has to be cut somewhere. Some would cut the budget on the lower elements of an application — the ones that the customers never see. But this is wrong. You see, an application is like a house. Skimping on the foundation creates an enormous risk of everything else collapsing.
So if you can’t save money on the foundation, you have to remove features. But, what is a house without rooms? Doesn’t removing features also remove the meaning of the project? As you can see, it is difficult to lower a project’s budget without putting it into jeopardy. So what is the miraculous solution? Unfortunately there’s no such thing.
A good start though would be minimizing the cost of heavy maintenance. This can be done by putting a lot of thought into what architecture would be the most efficient from the beginning.
That’s easier said than done! Firstly, defining what architecture is needed is difficult enough. Secondly, it is also difficult to respect the architecture when it comes time to code it. Sometimes, circumventing the architecture permits you to deliver a feature faster. But it defeats the purpose of the architecture and creates flaws in the software. To make sure that doesn’t happen, you need a tool where you can check that your delivered code respects the architecture model.
This tool is delivered by CAST and is called Architecture Checker.
Using CAST Architecture Checker gives a lot of benefits. With it, you will be able to validate the architecture of your application from the moment it’s thought up while choosing the level of detail you want.
And you will be able to validate how good your defined architecture is respected in the developed code whenever the code is modified using the generated set of quality rules. Every time a new feature is coded by the developers, you will make sure that your architecture is respected, permitting your applications to remain robust and easily maintainable. And you will keep your costs low.
In the end, an application is like any other thing. When you ensure that it stays intact during its creation, it doesn’t require costly down the road.
Do you know what happens to your cherished design patterns once your application is delivered and enters the hard, wildlife of exploitation, software evolution, and maintenance? Life is a jungle for the application code and health in the ecosystem of permanent software evolution, rapid maintenance, and changing software maintenance staff. It is likely that their life expectancy turns shorter than ever as the application evolution changes hands.
When you carefully crafted your design patterns, your intent was to exploit the experience of the “Gang of Four” masters and others by using proven, rock-solid arrangements of objects and their documented tradeoffs. Your goal was probably to help promote easier program changes and object reusability through these shared solutions.
However, findings in the field show that your interest and knowledge of design patterns — their purpose, their use, and their benefits — is not always shared as it could be. Lack of knowledge and misunderstanding of major design patterns is a plague. And the consequence is that many times once the team that originally developed the application hands it over to a new staff the life expectancy of the design patterns falls rapidly.
Several researchers have worked on this issue, mainly by proposing automatic detection and documentation of design patterns. Many thesis and research projects that tried (and still try) to automatically detect design patterns in existing code in order to document them. As an example, you can look at this 2007 thesis by Marcel Birkner titled “Objected-Oriented Design Pattern Detection Using Static And Dynamic Analysis In Java Software.”
More recently, and using advanced learning techniques, a team from the School of Computing of DePaul University, Chicago, Ill. produced a “Tactic-Centric Approach for Automating Traceability of Quality Concerns.” This system automates the documentation of “tactics,” a higher level of design patterns. The Chicago team explains in its research paper that:
”Unfortunately, software architectures tend to degrade over time as maintainers modify the system without understanding the underlying architectural decisions. Although this problem can be mitigated by manually tracing architectural decisions into the code, the cost and effort required to do this can be prohibitively expensive.”
At CAST, we regularly analyze recent object-oriented IT applications as well as aging ones, and we have seen the effect of both lack of understanding of design patterns and missing design-to-code traceability.
This is why the protection of design patterns out in the wild is one of our concerns at CAST. And we decided to provide such a protection for both our customers and our own software platform. However, we think that instead of writing or generating paper documentation that will hardly be read, it is necessary to automatically alert development teams and project managers each time that a design pattern is in danger. The idea came while working with customers on how to improve the evolutive maintenance of a mission critical application. To protect their design patterns, they had the idea to use CAST Architecture Checker to help monitor these precious pieces of code in their applications.
The very first pattern they checked was their custom implementation of the classic Model-View-Controler (MVC) pattern. Here is how it works. CAST Architecture Checker is used to define layers and authorized dependencies (or forbidden dependencies) gathered in an architecture model. This model is then checked either within CAST Architecture Checker or within CAST Application Intelligence Platform after static code analysis of all the programming languages in the application code. The violation dependencies are then displayed for remediation.
The idea was to define layers containing each class of the pattern, define the authorized dependencies, and activate the check to detect a violation of the pattern. In the case of the MVC pattern, we’ve defined three layers: one for model classes, another for view classes, and one for controller classes. When defining layers, we tell CAST Architecture Checker how to find M classes, V classes, and C classes using inheritance and naming convention or other conventions. Based on these definitions, the architects can check interactively for unwanted dependencies or integrate the checks into the application health check performed automatically (for example, each night or before new deliveries).
Architecture Checker became a pattern checker! So we started using it that way at CAST too. The idea is to check our own patterns to avoid any errors and degradation of the software platform. One of the patterns checked using CAST Architecture Checker on our own application source code is the interpreter pattern. The interpreter pattern, originally documented by the “Gang of Four,” is heavily used in the CAST family of 16 source code analyzers that cover the application analysis from end to end.
Using CAST quality platform on our own application source code is an operation we call “CAST on CAST.” This design pattern protection schema made part of CAST on CAST checks enables the entire development team to implement changes, continually evolving these analyzers, while being sure that precious patterns are not in danger.
As CAST Architecture Checker enables cross-languages checks, we are also looking at the protection of framework design patterns which involves programming languages, APIs, and XML configuration files.
How about you? Have you experienced any endangered design patterns? Which ones would you like to see protected in your application? Tell us in a comment.