AOP originated at IBM. Initially it focuses on cross-cutting concerns like security that turn up in our non-functional requirements, as opposed to our functional requirements that describe the logic of the automated and automating domains implemented via OOP. Java extensions supporting AOP exist.
AOP in non-invasive. OOP provided a huge improvement in encapsulation, or coupling and cohesion, over structured programming. Encapsulation puts code inside black boxes. AOP doesn't mess with the stuff inside those black boxes. The messaging of OOP happens outside the encapsulations. AOP intercepts messages, triggers processing in the AOP code, and then sends the message, unchanged, on to its intended recipient, so the execution of the OOP code continues uninterrupted, and unchanged.
As product managers, we have to remain non-invasive with respect to the implementing performed by our team members. Cross-cutting concerns can be left to your technical architects. But, when it comes to long-term maintenance, evolution, and testing, AOP offers distinct advantages to the software vendor.
When your team finds bugs, they get invasive to fix the bug, and introduce other bugs. A bug fix doesn't necessarily reduce your bug count. A bug fix may insert more bugs than it fixes. QA does full regressions after bug fixes, because you never know where a bug will show up in once clean code. Those full regressions are limited by your budget. They only reach so far. And, we all know that there is always another bug. Hackers are actually testing your application beyond the economic limit (budget) of your company. Hackers have no economic limit, so they will find the next bug before you or your customers do. AOP can help here.
If bugs are corrected non-invasively, that clean code never has to have the same tests run on it again. So instead of using your test budget on the same old tests, you get to run new tests that test deeper and wider and expand the reach of your economic limit. You would have to create new tests for the fix, but the scope of those tests would be much narrower than those run in a modified full regression.
Your application would take on an object-within-an object architecture. OOP already can be viewed that way. JavaScript in its DOM processing is organized in this manner.
You would code the core functionality. Once released, the next upgrade would be coded as a non-invasive extension where AOP would provide the integration between the core and the upgrade layer.
In this figure black represents the core code or initial release. The blue represents the subsequent release. The red represents the AOP interface between the core code and the code for the subsequent release.
In this figure, the curves from the regression tests have been added. While coding the subsequent release, additional tests were run on the core code. The code for the new code is tested as well.The regression curves in the figure reflect a reduced test budget. If the test budgets were held to ordinary issues the volume of tests would be some multiple of that shown for the prior tests.
The economic limit of the firm, shown in gray, can be moved from the testing bought in the initial release to additional test coverage bought during the upgrade effort.
AOP can reduce time, money, customer dissatisfactions, and emergency efforts focused on security issue responses. Consider AOP a strategic option. Explore it today.
Any comments? Leave them here, or email them to Dave44000@yahoo.com. Thanks.
No comments:
Post a Comment