It may be difficult to think of you project in terms of animate, maybe living, thinking things, almost like people. A common question we found ourselves asking during our developments were things like:
Notice that we always talk in the first person. Object Oriented Design really should not be done in isolation, do it in a team, the interaction between team members can be invaluable.
We now use Object Oriented Design and Object Oriented Programming tools for two product lines. One, the W9000 Network Management System for our traditional wide area network access devices, and the other project involved the development of our latest MS Windows based airline terminal emulations and applications.
For those of you who are interested, these products are being demonstrated at the Westinghouse booth.
But what is a system or a process?
Anything can be thought of as a system to manage, whether its a data communications network like an X.25 or Frame Relay network, a LAN, or telephone or satellite system. It could also be a nuclear power reactor, a subway system, a steel mill, aircraft and crew scheduling, paperwork flow through a company; like following an order.
These are all places where things happen. These things have characteristics or attributes. When a "thing" aquires a particular attribute, it can be said that this "thing" now has some inherent knowledge about itself. And so once it 'knows' something, it can act on it. These actions can cause interactions with other 'things', and so the cycle continues.
This simply is event driven programming, somthing we have doing for years. What we thought about were the events, we did not think of objects. We thought of what the events meant and what we should do next. But wait, you say an event is a 'thing'. No it isn't, the event was somthing that an object did. And the fact that the object did something is the important distiction.
In our Network Manager we had to deal with the physical things, communications ports. These ports are on circuit cards. Those cards are plugged into boxes. The boxes are connected together by a LAN in a group, and there can be many LANs in a city. In this hirarchy of devices or objects, each can have characteristics and attributes that may be of interest to the network manager. Any of these objects can do something and/or have something done to them.
Our goal was to be able to process all of the events that each of these things generate, catagorize the events, and possible turn them into alarms, and remember which device effectively generated the alarm. From the human beings perspective they are presented with a view of the world, containing a group of icons. Each icon represents a city. Clicking a city shows the equipment groups, clicking a group shows the box, and so on down the hierarchy until the lowest level of object is show, At each level the user has the ability to show all knowledge available about that object, and any alarms generated or related to that object.
Once we could agree on our terminology and our common frame of reference, we could then start to talk about our problem, our boxes and ports.
Many times we found ourselves talking about:
Many people ask about OOPS versus procedural programming, Etiher is only as good as the designer or programmer.
In other words it is just as easy to develop bad code in OOPS as it is using procedural coding techniques. It actually might be easier to develop bad code in OOPS, if you create a poor analogy or make bad choices in your problems domain.
There may actually be a right answer to this question, since we don't really care about the container itself, but what it contains.
Most programmers working today, might have actually been brainwashed into only thinking in a procedural manner.
OOPS is more like impulse buying:
There is room for both types of thinking.
There is one impression I would like to leave you with is that for my team and my associates. We found it difficult to convert to object orientation. Unless you work on it, you won't understand it. But once you understand, it can almost become a religion where you are constantly trying to convice others to use these marvelous new techniques.
Some C++ programmers think (or say) they are coding in an OOPS languange, yet all they are really doing is using a compiler that performs stricter type checking. Yet C is just an overgrown assembler that relieves the programmer from worrying about register allocations. C++ has added the high level object oriented constructs to that 'overgrown assembler'.
Our second project, involved re-architecting our Affinity family of PC based emulators in C++.
I started to learn C++ 6 years ago, but didn't really understand what I was reading until I found a GOOD languaguage with a cleaner more obvious syntax. There are many object oriented languages available out there, some with better lineage.
Some programming languages have a more intuitive language syntax than others. That may make them easier to learn, and easier to use.
Rapid prototyping is a wonderful tool, but don't be misled by a fancy user interface that has no functionality behind it. It may take longer than you realize or want, to flesh out the actual body of the program. In the end does it really take less time?
You may be tempted to forgo your existing programmers for new experienced ones. You may be pleasantly surprised to find your existing personel to be reasonably knowledgable, and even enthusiatic to use these new technologies if you let them.
A person who likes what they do, probably will do it better.
OOPS promotes evolution, not revolution.
The old paradigms for procedural software emphasised spending more time up front on design. Improving the design, getting it right, before you start coding. Unless you have a VERY experienced developer, this is difficult, Now contary to what you as managers have probably been trying to promote for the last 30 years, you now should encourage getting some code running early. This way you can see if your domain design is progressing along the correct path. Get some things running, and then modify it and update it as you go along. This is where knowlege engineering comes along. Show the design to the users, all of them, singly or in groups, get their input and modify your design until it matches what you need. A lot of times, a programmer thinks they know exactly what the business needs, and ends up with something that works, but is un-natural.
Although OPPS requires more design up front, it is also easier to do iterative improvements, without doing a "fork-lift" upgrade.
Whats really needed is someone who is:
Finding all of these characteristics in one person is difficult, but not impossible.
If it helps you to understand what you are doing, thats all thats important.
Just giving them a course on objects does not adequatly prepare someone to correctly and succesfully use OOPS. What works in a contrived training course may not be able to be used in a real-world situation. A student may have been briliant during a course and yet flounder during a live project. Also you really need to train everyone who will be involved in a project. Don't send only one person for training and expect that person to become an "instant" expert, and be able to train everyone else. Send everyone on that training, More people give you a larger base of viewpoints to draw from.
Any one individual may:
Consider using a mentoring process. Someone who has either successfully, or for that matter unsuccessfully completed an OO project. Having someone to discuss the object model and inheritance is invaluable.
Use an integrated tool, instead of a a mish-mash of products that you have to integrate. What you saved in cost, you probably paid for in time.
Beware of purchased class libraries. NIH or "Not Invented Here" is always a problem, but now more than ever there may be a reason for agreeing with supporting an NIH attitude, having to learn someone elses design, to reverse engineer someones class library is an arduous task, it may cost you more in the end even though you will probably get a prototype very quickly. Developing a class library yourself will take a long time, but your staff will intimately know what they have when they are done.
Beware of products that give you source code. It may not be because the vendor is being nice and open with you, but because it may not be a mature or stable product. Please note that this is not always the case with every vendor, but it is something that you should ask yourself before investing in that product. In general, if you have to spend the time reverse engineering their class libraries, would you have been better off developing them yourself. Ask yourself how much has reverse engineering already cost me on previous projects.
Measuring productivity does not change when deailing with objects. Progress should be measured by function points and not by the number of lines of code. Don't encourage programmers by "paying them by the pound".
Unless someone has used that exact tool, on a very similar project before, if someone tells you I'll get this job done 50% faster if I use this new tool they are probably lying to you. Don't believe them.
Software today, is rarely based on functionailtiy, but on glitz, "chrome sells" and the people that have the buying power like chrome. Put in the glitz, and it is easier to sell. Just don't forget to put some power behind the chrome.
Software expands to fill the available memory. (Parkinson law)
Software is getting slower more rapidly than hardware is getting faster. (Reiser law) (but people STILL expect the chrome!)
Object oriented does not mean icons (most people don't recognize the icons) don't forget about local customs and symbols. (this may be important in the global market we deal with in air transport)
Don't add features. Every feature is more code, every line of code means another opportunity for errors, (small is better!). If you can make a system more versatile by removing limitations, do it, it probably lets you delete code.
"Rampant featuritice" adds complexity adding complexity generally decreases quality. Focusing on objects, forces you to think of whats needed without worrying about unneccessary frills.
As a programmer, make things more obvious, "If you have to read the manual, its too complicated!"
"To reduce software complexity by concentrating only on the essentials is a proposal swiftly dismissed as ridiculous in view of customers' love for bells and whistles" (Wirth)
Smaller is better! Obvious is better!
"The sign of a productive programmer is not how many lines of code you wrote, but how many you deleted!" (Fulkos law)
Provide enough time to train, learn, and EXPERIMENT with this new technology. Remember a new language isn't learned overnight, and a new way of thinking rarely creates instant converts.
OPPS allows the developer to reduce the number of global constructs, encapsulating them into application or object specific domains. Once hidden, those classes reduce the temptation to use them directly. If they are not used directly, but only in the manner in which they were intended, it is less likely that the programmer can 'break' the application, and do something in a completely incompatible manner.
Reducing the scope of information, not only focusses the programmer into concentrating to the specifics of the particular problem, but reduces the complexity. Reducing the complexity reduces the number of possible errors. Reducing the errors improves the quality.
| C++, Smalltalk | |
| SNAP | Template Software 13100 Worldgate Drive, Suite 340 Herndon, VA 22070-4382, USA info@template.com |
| Ilog | ILOG Inc. 2005 Landings Drive, Mountain View, CA, 94043, USA vgui@ilog.com |
| Galaxy | Visix Software Inc. 11440 Commerce Park Drive Reston, VA, 22091, USA galaxy@visix.com |
| Tcl/Tk | URL: http://www.x.co.uk/of_interest/tcl/Tcl.html |
| Perl | URL: http://www.metronet.com/perlinfo/perl5.html |