“Keeping you up to date with everything software engineering!”

Leveraging Application Frameworks

Architecture | September 20, 2004 | 4 comments

As an engineer, the one thing I hate the most is having to re-invent the wheel time and time again. Time that is wasted designing, implementing and testing core concepts and software artifacts can be better spent building on top of a solid base and even improving the base. Now that is engineering! Or do you enjoy coming up with a way to fasten the toilet seat to the toilet bowl every time you design a new toilet?

Leveraging Application Frameworks published in the ACM Queue and written by Dr. Douglas C. Schmidt, Aniruddha S. Gokhale and Balachandran Natarajan covers what Frameworks are, their benefits, how to evaluate them and in general how to work with them.

A framework defined by the article is:

"an integrated set of software artifacts (such as classes, objects, and components) that collaborate to provide a reusable architecture for a family of related applications."

and the key characteristics of frameworks are:

• exhibits "inversion of control" at runtime via callbacks
• provides an integrated set of domain-specific structures and functionality based on patterns.
• semi-complete application.

For my last couple of projects I have used different frameworks and been very happy with each.

Do you use Frameworks for your projects? If so why do you, if not why not? What frameworks are you a fan of? Which ones should we stay away from?

Help Support Us By Visiting Our Sponsor

10% of our revenue from these ads go towards scholarships!

Comments

September 21, 2004 09:30 PM | Ness commented:

My biggest beef is what happens when the framework fails. Can you really lean on someone else to write the software for you?

For some applications the answer is yes. I’ll leave it to the reader to decide which applications those are.

But if you are a true software engineer and you have signed off on the product you built - much like any other engineer - can you take the risk that someone else’ code/design will not fail in the system?

It’s not good enough to say: “Oh, I didn’t write that, so it’s not my fault. I don’t know how that code works by abstraction”.

The system failed and you are now in a lawsuit because it failed when you said it wouldn’t.
I know there are ways to pass the blame around. If you have the source of the framework, you can inspect and verify it against your own projects standards. But some frameworks/libraries seem to be still evolving, which kills the purpose of verification since it’s expensive and time consuming.

I believe it all comes down to what type of software you want to build and how much responsibility you are willing to shoulder for your product. Once again, it’s not black and white.

September 22, 2004 11:26 AM | Anonymous commented:

But don’t other engineers take the same risk with equations they use/materials. New alloys etc which they are told will be better for the bridge, but to only find out over time that rains weakens it faster then expected. Another example: Someone uses for physics equations that have been simplified down to three terms—- they did not know that the mathmatician made a mistake.

While the equation example is less likely to happen then the alloy, these are problems that other engineering discplines encounter.

With the idea of frameworks (from my understanding), if someone realizes a problem, it can be fixed, and dynamically (automagically) fixed. If you design your program with respect to modules,information hiding and whatnot, then it should countinue to work as long as it can still call the same variables, and get results of the right type/class.

I guess I’m saying this is not a problem only fit to software engineers (“true or false” ones), but is one of every profession.

September 22, 2004 11:28 AM | Ness commented:

Good point, but most of the equations and materials are time tested and true. The frameworks/libraries that are available today cannot really be compared to Newtons Laws or steel - yet. Your alloy example seems to define frameworks quite well. They are mostly a new idea and unproven in high-stress products.

Frameworks, as I understand them, are the structure [or main control loop] of your program written by someone else for the GENERAL public. It is not tuned for your application (though some will argue you can extend them in an OO or with a wrapper program).

It is then the programmers job to provide the meat or “business logic” as it’s called - that does the non-generic work of the system before handing back control to the framework for the next “event”.

The part that really winds my crank is that people assume the framework is correct and use workarounds in their business logic to get the desired valid outcome. I’m not sure if it’s laziness or simply blindness that causes this (often because you have no way of checking the framework).

Properly written frameworks should be able to unplug from the business logic and a replacement that honours the interfaces of the old oneshould satisfy the program. That is simply modularization or what is called “contract” programming at its best. They require well defined interfaces which often leads to standards, working groups and bureaucracy when more than one party is involved.

I believe the main reason frameworks are not flexible and interchangeable in commercial software is “vendor lock-in”. Once you commit to a framework the vendor wants you to stay with them and buy their upgrades. But I like to ask; Why should you upgrade, wasn’t it correct when you bought it?

Overextending a framework or library is a risk I think we will see more of in the future. But as Martin said, a good engineer in any field will be able to measure the risks of his actions and will know whether it is acceptable or not to use a tool/framework/library for the particular system they are building or not.

Frameworks are generic. They may be excellent for some software, but are not sufficient for all products. Some times you have to do it the old fashioned way and start from the ground up.

September 23, 2004 10:33 AM | Anonymous commented:

You have to be careful when discussing these two things since they are not quite the same thing. A library is exactually as you said Ness which is code you take that someone has written and then use it for your own without testing or questioning. You should just be careful about which libraries you use. For instance java.util.* is a throughly tested libraries through not only other applications but SUN makes sure that it works exactly how it’s supposed to before it releases it.

So there are two points that you can draw from this

1. Know the source : Just like materials you are going to trust “Crazy Habi’s” structural integrity clinic to tell you which material to use. You shouldn’t necessarily go to “Joe Blow’s discount coding” to get a library.

Frameworks on the other hand are directions for how you are supposed to code. You have to note that you still do all the coding yourself (or can choose to) but the Framework is just a direction. For example

If you are going to do a simple true/false validation you should use a if condition If the test is complex you should use a switch

That would be a poor example of framework that is laid down. It is expected that everyone will follow that direction to make the best code you can but nothing is really forcing you too and you aren’t really reusing other people’s code. Take a Car for example the framework is set on how to make the engine/breaks/steering (with minor variables) but there is nothing saying you have to use it (There is a good chance you will screw up) but you don’t have to.

Then again I could be completely wrong.

Post Your Comments

Comments:

Name:

Email Address:
(note: not displayed)

URL:
(note: displayed with comment)