Company and team description: Develops financial information systems for world market. Part of a multinational. Development teams in several countries. Studied the team in Sydney.
Experience: Long experience with traditional development. Long experience with E/R modeling. OO development since 1993.
How contact was established: After reference from Brian Henderson-Sellers, whom I told about the findings from Denmark. His comment was that I apparently had found a bad sample of development teams. He referred me to Dow Jones, Sydney, which according to Brian should know how to make truly OO systems. My study showed that their OO systems where no better architecturally than other systems I had studied. Actually, they had avoided several problems because their applications mainly were doing data retrieval. Other teams had struggled with these problems and some had found a solution.
Study form: Meeting half a day. Demo and overhead presentation. Interview with several developers, study of OO diagrams, discussion of my list of problems. No code studied.
Applications studied: A financial information system with advanced calculations and display of trends, etc. for shares, bonds, etc. Draws on a distributed global database. Monthly releases of new versions with new analysis tools. Previous system was a DOS and C version consisting of about 1,000,000 lines of code. Had become very difficult to maintain. New version was OO-based in its architecture and used C++. It was only 70,000 lines of code due to the use of Foundation classes, rather than home-made subroutines as in the old version.
Platform: SQL databases. C++, later Visual C++. Windows NT. Experience with Visual Basic too. The application used no local database, except for local configuration information. CASE tool for Moses/Open.
OO-Architecture: Used the Complex Business Architecture with several modifications:
Commit: Not part of the architecture. Done in a modal dialogue.
Integrity: Not part of the architecture. Since the system only updates in a modal dialogue, the integrity problem doesn't need a solution.
Data retrieval: A significant problem. Each record is retrieved as a separate query, and retrieving all the data needed for a complex calculation or a long list of bonds or shares is very time consuming. This was the first time I really understood the data retrieval problem. Other teams had mentioned it but said it wasn't a big problem. Dow Jones was trying to find solutions to the retrieval problem, but had no good idea at that time. A solution would be something in conflict with the OO way of thinking.
Distribution: Not implemented. The team had discussed it since there was some need for a solution, but the fear of uncontrolled recursion and deadlock (the call-back problem) had stopped them.
Call-back: Not present since the distribution problem isn't solved.
Encapsulation: Most objects are degenerate with either data-only or function-only. Computation objects, however, store their latest results for improved efficiency.
User involvement: Not done by means of OO talk. Main vehicle was prototypes of screens and mathematics for calculating trends, etc.
Seamless transition: Calculation objects (a kind of service objects) and database objects had operations that developed gradually during analysis, design and implementation. The user operations as seen on the user interface where completely different, however.
User interface: Advanced pictures much easier to make due to Foundation classes. OO thinking in itself had no influence.
Maintainability: System is easier to maintain than old system, but difficult to know whether it is a result of being a young system (fewer people have messed with it), being much shorter (due to Foundation classes), or because of the OO approach. It was a problem for new developers in the team to learn the Foundation classes, but that was easier anyway than learning the old system's in's and out's.
Reuse: No experience with reusing classes in other projects. (Reusing the classes within the project for new releases or variants is not considered reuse, but maintenance).
Company and team description: Develop various kinds of business applications for banks, breweries, TV-companies, etc. Also sell their development tool internationally. The company was quite small and had about four developers including the manager, Anders Bonde, who developed the tool based on his mathematical background and many years of IBM experience. Usually the company works together with the customer's developers on the job to ensure a smooth transfer of knowledge and responsibility. Usually the customer's developers have no OO experience, but learn the necessary techniques during the project.
Experience: Long with traditional development. More than five years with OO.
How contact was established: After several weeks of debate in the Danish Computer World, ObjectDesign wrote an article with an impressive list of delivered systems with a very fast development time. Typically 5 months for developing a system with 40 main classes (entities) and 60 windows. I had never heard of the company before.
Study form: Meeting half a day with a follow-up meeting later. Demo of several systems. Interview with Anders Bonde and another developer (with a background in house architecture). Study of diagrams and actual code.
Applications studied: Several applications were discussed and seen. They were all built on the same pattern.
Platform: SQL databases. SmallTalk. Considered transforming the tool to C++, but has now announced a version for Java. Runs under Windows NT, Mac, OS/2 (and UNIX - not quite sure?). Porting between these platforms is easy because SmallTalk and SmallTalk's GUI-objects are easy to port: The source text is ported as "text" and interpreted by the SmallTalk interpreter on the target platform.
Their own tool includes a CASE tool, but parts of their tool can be bypassed so that they use an external CASE tool. I saw examples where Excelerator and ADW were used for handling the database in an E/R fashion. With their tool, a GUI object addresses the database by means of a C-style notation where the programmer directly references entities and relationships. E.g.:
OO-Architecture: The applications all followed the Complex Business Architecture, and they were the most complete examples of that architecture that I have seen.
The active database records were kept in database wrapper objects, that had structure and relationships like the E/R database. The wrapper objects were removed automatically by SmallTalk's garbage collection when the data wasn't referenced anymore.
Observer Objects linked the wrapper objects to the various GUI objects that somehow showed that record. Although SmallTalk has a built-in MVC mechanism to broadcast changes, ObjectDesign had made their own observer objects. Subclassing and overloading allowed them to make tailored versions of the observer objects. This was needed for instance when a total of many records was shown; the GUI object showing the total should not recompute the total from scratch, but adjust the total incrementally. Another example is a complex graphical representation reflecting many database records; the display update should not be automatic in this case since that would slow the system down. Instead, the user could ask for refresh. Observer objects made heavy use of the SmallTalk possibility for late binding and dynamic manipulation of class names and operation names.
Many high-level operations are handled directly by the GUI objects. Others are handled by separate Service Objects. Sometimes the high-level operations were distributed between wrapper objects, service objects, and GUI objects.
Issues:
Commit: Under programmer control. Commit and Rollback operations
exist as a standard.
Integrity: The use of database wrapper objects ensured that data existed only in one copy in each PC or work station. (Integrity between PCs was handled by the RDB-system behind the scene).
Data retrieval: The developers talked about data retrieval not being a serious problem, and databases usually being close to the PC. At that time I didn't quite understand the problem, but when I visited Dow Jones I saw the nasty problem they were grappling with. I am not sure whether ObjectDesign has a solution or not. Or whether they can make reasonable ad-hoc solutions in practice.
Distribution: Fully solved through the Observer Objects.
Call-back: Was not a problem. Probably the GUI objects didn't pass update requests on when they were asked to update themselves. That should solve most of the call-back problems.
Encapsulation: The developers were very pragmatic about this. Experience had taught them that they only called for problems if they insisted on the nice textbook encapsulation. In practice most objects were degenerate (database objects data-heavy and service objects operation-heavy), but they did whatever they found convenient in each specific instance.
User involvement: Usually, they didn't discuss object matters with their customers, but they used their tool to practice Rapid Application Development. Typically they started with a "visual datamodel" where they showed each entity from the E/R model as a list of records or a single record with lists of associated records. Their tool could generate such screens automatically. These screens were then discussed with expert users. Many changes to the database resulted from this.
The next step was to develop special screens for critical user tasks. I saw highly graphical presentations where the user could manipulate the graphics (e.g. drag schedule pieces around) in order to update the database. Such pictures where quite easy to develop, although it couldn't be done automatically.
Interestingly, they frequently discussed parts of the code with expert users. They said that these users could follow C-style expressions like those above.
Seamless transition: Again, the developers were very pragmatic. They didn't try to consider operations early in the analysis and design. Early on they only focused on database entities with standard functionality (CRUD). The database entities transferred very well to the final implementation, and their tool even allowed the relational tables to be invisible in the final implementation.
Operations were added late as part of the interface design and implementation. Operations were included in the objects where it seemed most convenient (see "encapsulation" above).
User interface: The developers had a very good understanding of the need for more complex windows than those generated automatically (database-oriented windows), and they could show many examples of such complex windows.
Maintainability: Not known. Maintenance was done by the customers, who apparently could do it without resorting to ObjectDesign all the time. (The few developers at ObjectDesign would not be able to maintain all the products they had developed in cooperation with the customers).
Reuse: The tool and all the standard objects (wrappers, observers and special GUIs) were reused from project to project. I don't know to what extent they sub-classed/overloaded the standard classes to produce a new application, and to what extent they just copied and modified the code.
Company and team description: Their main market is applications for Danish local governments. The company has many development teams in different geographical locations. The teams work quite independently of each other and can choose their own tools and approaches to some extent. The company has about 700 developers. The study reported here was with a small team which had been OO pioneers within Kommunedata. Their effort was not, however, well-known within Kommunedata until they "went public".
Experience: Four years of OO development of administrative applications. No information about previous experience.
How contact was established: After my first letter in Computer World, this team responded vigorously, claiming that they had a successful application and that no other successful OO business applications were known.
Study form: Several telephone discussions. Detailed study of part of their documentation, e.g. entire listing of classes and subclasses (I received a total of 40,000 lines of code). A series of letters in Computer World.
Applications studied: An application for managing courses in the public health sector.
Platform: SQL databases. SmallTalk. Used a Danish CASE tool (OoASE) which didn't deal with entities and relationships (or similar object diagrams) but was strictly responsibility driven. The basic diagram with OoASE seemed to be a call graph, very much like a dataflow diagram. (The author of OoASE, Soren Skogstad Nielsen, never accepted the similarity with dataflow, and we had many other difficulties understanding each other.)
OO-Architecture: The Complex Business Architecture. The Database Wrappers were basically degenerate objects, although some of them had added functionality, for instance to produce a list of records. There were about 10,000 lines of code to implement about 80 classes and subclasses that handled the database entities. Service objects provided high-level functionality and encapsulated "responsibilities" (as prescribed in some textbooks). It seemed that most of these objects had much functionality, but no other data than the parameters passed to them. (One of their letters published in Computer World explains an "object" which can enroll, cancel, etc. one or more participants on one or more courses. It is a convenient packet of subroutines for maintaining course participants, but it needs no data other than the database wrappers and the parameters passed to it).
Issues:
Commit: Not known for sure. Probably under programmer control.
Integrity: Solved through the database wrapper objects.
Data retrieval: Not known for sure, but the addition of database wrapper operations for retrieval of a list opens a possibility for getting several records in one SQL query.
Distribution: Not known for sure, but the listings I saw showed no signs of Observer Objects. Probably the distribution is done in an ad-hoc fashion from other objects - or it is left to the user to ask for a refresh.
Call-back: Not mentioned as a problem, probably because the distribution is ad-hoc.
Encapsulation: Most objects are quite degenerate. The high-level operations are usually separate from the data they operate on.
User involvement: To some extent they used the OoASE diagrams as a communication tool with users. This surprised me, since other groups gave up on using OO diagrams (E/R-like) for user communication. A closer study revealed that OoASE diagrams are more like dataflow diagrams, and that matched other observations I had about users understanding dataflow diagrams, but not E/R-diagrams. They didn't mention prototyping or Rapid Application Development, and it seems that their architecture wasn't that well developed that this would have been possible.
Seamless transition: Since I didn't get the full analysis part (in OoASE), it was difficult to track systematically. However, a few checks showed that many concepts in the analysis part didn't have a counterpart in the code that I had. Some had, however. Asked about the traceability, the developers became fuzzy, talking about not following the method as they should, lack of tool support, facilities not yet implemented, etc.
User interface: I have not seen all the actual screens, and developers never talked about graphical presentations. The listing of user interface objects seems to contain only traditional database-oriented presentations, including classes for searching from the database.
Maintainability: No experience yet. When asked about it, the developers repeat the usual hype (expectations that it will be easier). They admitted that it would be hard to add ad-hoc queries and reports, because the database wrappers were not geared to that. They suggested that traditional report generators be used for that - using direct access to the RDB.
Reuse: No experience yet. Expect that the database wrappers can be reused with some modifications.
Company and team description: Develops applications for the government. The study was with a pioneer team that was very proud of making the first OO application in the company. At the time of my investigation, they considered themselves successful.
Experience: This was their first OO application. Some team members had more than ten years experience with application development in general, primarily with mainframe systems. Other team members were very enthusiastic about OO, but had little development experience.
How contact was established: The team announced their success during one of the seminars I joined prior to my letter to Computer World.
Study form: Interview half a day. Saw analysis diagrams. Follow up interview with other developers later.
Applications studied: A single administrative application.
Platform: SQL databases. Visual Basic. MS-Windows.
OO-Architecture: It was the Simple Business Architecture. Essentially, each window had its own buffer and retrieved the data through SQL.
Issues:
Commit: When the window is closed or at user request.
Integrity: Problem avoided by ensuring that only one window could update a specific record: The user had to do most editing trough one-record windows.
Data retrieval: One or a few queries per window. No problem.
Distribution: No attempt to solve the problem.
Call-back: No problem since there is no distribution.
Encapsulation: The implementation wasn't really OO. Or you might consider each window and each VB control an object.
User involvement: They struggled primarily with the technical and methodological aspects of their application and involved users in the traditional way. (Written specifications without prototyping and without specification of user tasks).
Seamless transition: They had done the analysis in an OO fashion, but then the whole thing was redesigned in Visual Basic. There was no visible connection between analysis and implementation except for the relational database.
User interface: The standard database-oriented windows. The customers were accustomed to this kind of screens from the mainframe world, and found the new screens more Windows-like, but with the old mainframe functionality.
Maintainability: No experience, but expected the hype to be true.
Reuse: No experience, but expected the hype to be true.
Other comments: Although they considered themselves advanced, this was a very primitive exercise with the primary aim of adding a graphical face to a mainframe system. They struggled with making sense out of OO principles in the analysis stage and handling client-server technology in the implementation.
Company and team description: The team came from a well-renowned software house with about 30 developers. The team had experience with many kinds of applications from business applications to technical applications, embedded software, and real-time software.
Experience: They had many years of experience with many kinds of platforms. They mastered traditional development techniques (usually the customer determined which kind of diagrams, etc. they should use), and some of them had for more than five years designed systems in an OO way.
How contact was established: I knew them from earlier on and asked them for an interview prior to writing my first letter to Computer World.
Study form: Interview with a chief developer. Exchange of architectural diagrams.
Applications studied: The different architectures were discussed without detailed studies of specific applications.
Platform: Many, all kinds. Surprisingly, they used OO approaches even if they worked in a non-OO language and on a non-OO platform.
OO-Architecture: They used several architectures, and often mixed them. Although they didn't give them names, they had been using the technical, the simple business, and the complex business architecture.
They very much developed what was needed for the specific customer, drawing on their general experience rather than a specific architecture. For smaller, simple applications they tended to use the simple business architecture.
Issues:
Commit:Knew the problem and handled it in different ways depending
on platform, etc.
Integrity: Knew the problem and handled it in different ways depending on platform, etc.
Data retrieval: We didn't discuss that problem, probably because I wasn't aware of it at that time.
Distribution: Knew the problem and handled it with Observer Objects in some cases, ad-hoc updating in some cases, user controlled refresh in other cases.
Call-back: Knew that it was essential to separate object operations that called "upwards" from those called from "above".
Encapsulation: Were very pragmatic. Objects were just another way to structure your code and your design. In business applications, the database objects tended to be degenerate (mainly CRUD functionality), in more technical systems, domain objects with high-level functionality were more common. Mentioned a tendency for large technical systems to blend with business-like applications, and suggested that technical systems would end up having a business architecture.
User involvement: Depended on the customer. Some customers were highly technical and could discuss technical aspects of design. Had tried to use E/R diagrams and OO-diagrams for discussing with ordinary end-users, but that never worked.
Seamless transition: Focused on the implementation right from the beginning. Their dataflow diagrams, for instance, dealt with the computer system, not with the human activities. For objects, they did the same. Thus they skipped the textbook domain analysis, but gained good traceability and seamless transition.
User interface: Could develop all kinds of interfaces.
Maintainability: Couldn't see any difference between OO and non-OO.
Reuse: Very little since the platform and the customers were so different.
Company and team description: The company produces sophisticated measurement equipment with embedded software, or controlled by a PC, or a combination.
Experience: Long experience with development of embedded and real-time software. The company had many development teams that were allowed to chose their own approaches and platforms. Started the first OO projects in 1988 but didn't succeed well until after 1992. The problems were lack of formal training, immature tools, and too much faith in OO so that for instance requirements specification and project management were ignored.
Became successful after 1992 with a more controlled introduction of OO, restricting themselves to projects that were well suited and staffed with well-educated developers.
How contact was established: I had known the company for many years. Got into OO contact with them after the long debate in Computer World.
Study form: Followed a project closely. Multiple interviews. Studied analysis and design documents, error reports, etc.
Applications studied: A PC-based measurement system interacting with special equipment.
Platform: C++. Windows NT.
OO-Architecture: The technical architecture. Had big troubles finding out how to handle concurrency (multi-tasking) with OO. Their solution doesn't seem to be a natural part of OO, where the theoretical handling of concurrency would be to let some objects execute concurrently and let the rest serve as monitors that guarded their own data against concurrent access. The need for call back, however, makes this scheme dangerous.
Issues:
Commit: No problem since there is no database on disc. Editing
of data (system parameters, etc.) is done in a modal dialogue. The users,
however, often would have preferred a non-modal dialogue.
Integrity: No problem. Data is stored in only one place except during editing, which however is done in a modal dialogue.
Data retrieval: There is no large database behind the scene, so there is no general problem here. However, measurement setup and results are stored by means of MS-Windows facilities (MFC) that turned out to be unexpectedly slow. (I have not classified this as a general OO problem).
Distribution: Solved in an ad-hoc fashion. Caused many problems: lack of proper updates, lack of proper graying of menu points, etc.
Call-back: Caused many problems too, due to the ad-hoc distribution. Early versions of the system could go into long periods of screen refresh before it unexplainably settled down.
Encapsulation: Works reasonably. The domain objects have high-level functionality too.
User involvement: In the same way as without OO.
Seamless transition: No seamless transition. Made an analysis OO model as an appendix to the requirement specification (primarily to check against inconsistencies in the requirements). The requirements themselves were in a text form that marketing could easily understand. Marketing never cared about the OO model. The later OO design model was completely different from the analysis model. It modeled the final code, not the more abstract domain.
User interface: Much effort was invested here and highly sophisticated graphical pictures could be shown. That was the very sales theme. Would have been very expensive to make without a GUI.
Maintainability: The developers say that the system is more easy to maintain because the OO-based design is more carefully planned.
Reuse: The company has realized that even after two "generations" of OO systems, they cannot reuse any code from one project to another. One kind of reuse has been achieved, however: The different teams in the company now agree on what they mean by terms such as driver, interface, controller, etc.
Comments: Making new kinds of windows with data cross-linked in other ways was a problem and it caused changes to domain objects.
Company and team description: Another company making sophisticated measurement equipment, but for a completely different domain.
Experience: Long general experience with development of embedded SW, real-time systems, etc. First completed OO project.
How contact was established: Learned in another connection that they worked with OO-based projects.
Study form: Half-day meeting with study of code and diagrams.
Applications studied: Embedded software for a new product.
Platform: Borland products. Had developed their own OS for the target hardware.
OO-Architecture: Technical architecture. Had composed their OS in an OO manner. Some objects had their own life (task objects, i.e. threads of execution) and executed concurrently with other such objects. Other objects were monitors that guarded their own data against concurrent access. Had long experience with real-time systems and knew how to prevent deadlocks.
Issues:
Commit: No problem. All data is in memory and not on disc.
Integrity: No problem. Data is in one copy and the monitors guard against concurrent access.
Data retrieval: No problem. Data is in memory.
Distribution: No problem. Very little user interface. Main i/o is over a communication line.
Call-back: No problem due to their real-time experience which was transferred to the OO version.
Encapsulation: Nice. Objects had meaningful operations and not just CRUD.
User involvement: Users are technicians. They talk about communication protocols and may comment on the user interface. Didn't talk objects with the users.
Seamless transition: Development focused on modeling the final code right from the beginning. No seamless transition form analysis to design, but OK from design to code.
User interface: Rudimentary. Not GUI based.
Maintainability: No experience.
Reuse: Hope to reuse the OS, for instance.
Comments: Had troubles figuring out how to model the protocols with objects. Their application domain was very much communication protocols, and it was surprising that it was difficult to model OO-wise.
The professional developers could recognize the architectures and many of the problems. Often they were happy to hear that other people had the same problems. Sometimes they suggested solutions or referred me to papers with discussions of some of the problems.
Some developers were very happy with OO, but it turned out that they had never used data modeling (E/R) and it was those aspects of OO they liked.
The OO-promoters said that all the promises were true and that I had looked at the wrong cases, or that I was old-fashioned and couldn't adapt to OO. However, they failed to provide evidence for successful applications - even when asked. In some cases they claimed evidence by referring to a successful application, but when I studied the case, it was no better or worse than other things I had seen. Often the promoters gave a presentation too. Here they tended to use examples from the physical/technical world (bikes, speed regulators, overhead projectors), exactly those where objects aggregate naturally and where the technical architecture works well.
My latest seminar in this area (May, 1997) was at Simpsion & Bowles, Melbourne, for about 30 professionals. All accepted the findings. Some had suggestions for solution of the distribution problem.
Some developers had tried OO databases but found performance problems and immature mechanisms for locking and roll-back.
People using Oracle Forms explains that it uses the simple architecture with a buffer for each window. This approach has two problems: Integrity (multiple copies of data) and distribution of updates. Oracle Forms solve the integrity problem in this way: The data retrieved for each window is kept in two copies. Only one copy is modified. When committing the data (updating the database), Oracle checks that the retrieved data (the untouched copy) is still the most recent. Otherwise, the update is rejected. (The user will probably have to ask for a refresh and repeat the data entry in such cases.) As far as I know, there is no standard solution of the distribution problem under Oracle Forms.
The software worked fine and one company based a range of real-time systems on it. However, it never became a commercial success, primarily because good memory management HW didn't exist at that time, the necessary programming languages were not industrially accepted, and due to lack of hardware support, the inter-object calls tended to be too much of a bottleneck, especially if you used them also within parts of a single application.
In 1992 I was advisor on a thesis written by Margit Baek Bramming and Belinda Werum. They compared traditional structured analysis/design with OO analysis/design. They took an existing business administration system and documented central parts of it with dataflows, E/R, and OO diagrams. I checked through several rounds of "design" that their models were correct and used OO principles in a reasonable way. They then tested whether users and expert users could better understand one form or the other. The conclusion was clear: Even expert users didn't understand OO diagrams, they could understand E/R a little bit, and they readily understood and commented dataflow diagrams. (Later, practitioners told me about similar experiences).
Next, the students were asked to modify the design by introducing a realistic but more advanced way of handling discounts (products and customers could be assigned to a discount group, and each combination of product group and customer group could have its own discount rate). They then studied the changes made to the documentation. E/R and dataflow required only simple, localized changes, while the OO model needed a lot of changes in many objects. These changes were not so much adding new classes or new operations to existing classes, but having to carry additional parameters dealing with discount stuff. Even if an operation didn't deal with discount, it often had to pass information about discount from the caller to another object. This was very much a surprise, since we thought the design had been good and robust. (The design didn't include the user interface, only the domain/database part of the system).
In 1995 I was advisor on another thesis, written by Carsten Gronning. His main goal was to show how a truly object-oriented user interface could be systematically designed. Soon he realized that he had to attack the problem of how to link the database to the GUI interface in an OO fashion. He experimented with domain objects, user-oriented objects, observer objects, etc. but never found a truly satisfying approach. I can see now that he tried to strike a balance between the simple, the complex, and the technical architecture. No clear architecture would come out of that. However, he made an elegant solution to the distribution problem. Unfortunately, it would only work in a SmallTalk environment, because C++ would require too much type match.
These two student projects were academic, although they used realistic applications as basis for their examples. Were the problems we encountered caused by our relative inexperience with OO, or inherent to the OO ideas? My later case studies have shown that OO problems are widespread, many companies are not aware of the problems, and few have solved them.
Last update 97-10-30 by Søren Lauesen