|
UHR lets users or developers rapidly assemble systems of any kind from reusable parts, while the system is running or not. Several dozen key mechanisms are used to do this extremely well.
UHR stands for Ultra High Reuse. It's a total approach to software development based on the guiding force of reuse. Many things are reused. Parts (aka Components) are the main thing that is reused. UHR also reuses frameworks, a microkernel that provides infrastructure, visual tools, user intentions, process, user training, and entire systems. The particular way all this is done is UHR. It's very different from other approaches, such as IDEs and CBD, though on the surface it looks about the same.
One developer described UHR as a "framework for frameworks." Another described it as "the 20 best practices rolled into one."
UHR is too novel and complex to explain briefly.
2. What do all these strange terms mean?
See the UHR Glossary but beware, it's big and deep.
BA stands for Bean Assembler. It's the reference implementation of UHR. The word "Bean" was used in the earliest version and stuck, even though it doesn't use Java Beans at all. These days, PA for Part Assembler would be more appropriate. The BA is freely available as Open Source. See Downloads.
Java Consortium. This is the small group who started all this. The BA codebase is in Java and uses org.jcon as the root package prefix.
Also known as Components, a part is a reusable black box used in assembling systems from parts. From a business perspective, think of a part as your redeployable Intellectual Property. From a user's perspective, you get a part from a Part Shop, drop it into a tree representing a system of parts, configure the part to behave the way you want it, configure other parts to collaborate with the part, and you're done. All this happens while the system is running or not. Parts and good Visual Tools open the door to users creating and improving their own systems of any kind.
6. Okay, what are the gory details about parts?
At the low level, UHR parts work differently from other approaches.
First off, the user never codes anything. Instead parts are reused by passing them Declarative Knowledge, known as DK. This separates what to do from how to do it. Using DK, the user declares what to do with simple Visual Tools, and the part figures out how to do it. Of course parts are written in code, but they are only written once.
There are many more features, but these are the basics. We expect the average developer to use over 2,000 parts.
Parts are created with code, but reused with Declarative Knowledge. Most parts fill "plugpoints" in a Plugpoint Framework. In general, first a framework is designed and then implemented along with a few parts. Then additional parts are designed and implemented, while making gradual improvements to the framework. After awhile things start to look mature, and the Plugpoint Framework and Parts are ready for reuse. Framework creation takes very high OOAD abilities, while plugpoint parts can be created by most developers.
8. Where can I get more parts?
Hmmmmmm, right now the only existing parts are in the jcon examples or are proprietary parts. We hope to grow more jcon parts. Third party part suppliers will eventually appear. Many parts will be created by businesses using UHR. We expect that eventually over 250,000 UHR parts will be internet available via Part Shops. This number of internet available parts has already occured in the Electronic Design Automation (EDA) industry.
You can also go to the "Part Sweat Shop". :-)
UHR is still an emerging technology, so you will need insight and determination. Try studying this website first. If it makes sense, join the JSL and ba-general mailing lists and come to meetings if you can. Get the downloads, run them, and see if you can make small changes. Try creating a small BA system. We will soon have a BA Tutorial. By the time you've gotten this far, the next steps will be apparent.
10. Who's providing all this UHR and BA stuff?
A small group of Java and OOAD enthuasists in the Atlanta area started talking and developing things in 1997. From the beginning their work has been on a volunteer basis, but subsidized by their employers who saw the value of this work. They have met at Atlanta Java Users Group meetings (monthly), Java Second Language study group meetings (every 2 weeks in Atlanta) and at two "BA Workshops" in Atlanta. At the second workshop we had one fellow from Chicago and another from Seattle, indicating we are becoming more of a virtual geographically distributed group.
There are a few related websites. These are evolving in fits and starts, ups and downs, as we attempt the very difficult task of taking an incredibly novel concept from laboratory to production. These sites are fairly quiet compared to commercial sites. Keep in mind this is an Open Source project.
- UHR Study Group - This is very small and just starting out. (John, KT, Cindy, Tom)
- jcon.org - Michael Ivey, "Keeper of the Arcane Magic." (preliminary, may be down due to recent disk crash)
11. How do you know UHR works?
We don't yet have any statistics, but we do have these estimates:
- Jack Harich developed a Plugpoint Framework using the BA at REALM in Fall 1998. He and management there estimate a productivity increase of a factor of 2 to 4 for the system involved, which was a Java client with 30 parts.
- (more to follow)
12. Isn't UHR just another Silver Bullet?
Actually we really don't know yet. Supporting trends we have seen are:
- Those who have built their own serious frameworks tend to understand and want to use UHR. To date the specific developers doing this are Paul Reavis, Christian Cryder, Steve Alexander and Jack Harich. More are getting close.
- Those receiving long detailed presentations of the UHR Technology Grid tend to want to start using the technolgy ASAP.
- Those organizations who have actually used the BA to develop systems in new domains want to use it a lot. This is currently mostly REALM.
- Components are hot!
Also, consider that the average developer creates 10 to 30 lines of code per day. Studies have shown this average to be independent of the language used. Thus the "higher" the level of the language used, the more productive you are. For example assembly is much more productive than machine language, and C is much more produtive than assembly, and Java is much more productive than C or C++.
Now what happens if your "higher level language" is parts? One part easily replaces 100 lines of code. UHR parts are used for everything, not just GUI widgets. How do you think this will affect your productivity?
13. Can end users really use the BA?
Not yet. The first iteration of the BA is for developers only. The second generation will have Visual Tools allowing power users to modify their own systems. By the third generation we expect to extend this to average users.
To date REALM Information Technologies in Atlanta (lots), CDC in Atlanta (little), and Partner Software in Athens, GA (soon lots). Individuals are also exploring it.
15. How long does it take to learn UHR and the BA?
This depends on where you're starting from, and how you plan to get there.
If you're experienced with developing your own advanced frameworks, allow 6 months. Include throwaway practice projects. Get initial training.
If you're not experienced with similar technology, first somewhat master OOAD and Java. Then get initial and ongoing training. Design a 12 to 24 month plan for your key people. Include at least 5 small throwaway practice projects, each taking several weeks full time. This is a serious investment, but will pay off bigtime.
The above is for those needing to develop their own frameworks. The time is much less for just parts, and even less for just assemblying parts.
16. Why are you doing all this?
Because it's useful, fun, a creative challenge and a great pleasure to share what we have with others.
If you're a technical type, try the UHR Glossary and Key UHR Behaviors. If you're a management type, try Corporate Perspective of UHR and The Advantages of UHR.