David Ramsey
Posts: 34
Nickname: dlramsey
Registered: Apr, 2002
|
|
Re: Software Architecture
|
Posted: Feb 6, 2004 9:14 AM
|
|
I believe this is due to two things, both related to software complexity.
1. Management, as external observers to the software process, have no real inkling of the complexity of software.
2. The technical community has been unable, until very recently, to specify design in meaningful ways and sufficient detail.
However, I see the evolution of UML in becoming more and more precise as overcoming obstacle number 2 eventually. Already we have early design tools that can take a design and give you code or take code and give you back the design (reverse engineering).
Some people will argue that such tools can never produce code as good as they can code manually. My response to that is baloney!
Many, many years ago, when my son was younger than my youngest grandchild is now, I listened to assembly language programmers insisting that compilers could never outperform them. And yet we've reached a state where the best optimizing compilers produce tighter, faster, and more reliable code than 99.9% of those old assembly language programmers.
What's occurring now is the recognition of things larger than just algorithms, such as design patterns and anti-patterns. And as this continues to evolve, the best patterns and worst anti-patterns will become part of the best design tools allowing you to specify a good pattern from the start and to identify anti-patterns when they exist.
I happen to believe that we are not far from Booch's "executable model" idea. I further believe that this is just another level of abstraction in the problem solving process, just as the move from assembly language to compiled languages was.
Somewhere in the not too distant future, you will prototype by modeling.
Here's an example that is happening in code but could be done with UML and modeling tools as the tools mature. My organization is looking hard at JDO. We're experimenting with the JDO reference implementation from Sun along with the OJB backend plug-in from Jakarta to the reference implementation. If we are really happy with the semantics of this, we'll likely drop the reference implementation and OJB, and migrate to a different implementation for higher performance, better tuning, and scalability. But since it's still JDO, our prototype is our working model. All we will do in the software is swap out some jar files to let us go to a different implementation.
|
|
Previous Topic
