This chapter is from the book
This chapter is from the book
This chapter is from the book
LEGACY ISSUES
There are two particular issues to take up with regard to your legacy systems: mainframes and relational databases.
Mainframes
Most mainframe teams have different vocabularies and have been trained with techniques that are different from their object-oriented colleagues. Prepare for communication difficulties between the two teams and expect them to work in different ways. Many mainframe developers are used to working in a one-pass manner: "Give me the requirements; I'll do high-level design, low-level design, code, and test." Experienced OO developers are used to increments and iterations, multipass, iterative development: "I'll tell you the requirements after we 117 show it to our users twice" (see Chapter 5).
Partition the architecture so that the two groups can work in their own ways. Either get the mainframe developers comfortable with iterative development or develop a synchronization process that gives them their requirements only after the driving design is relatively stable.
The allocation of function to different platforms and languages may cause some trouble. The workstation and mainframe designers are likely to differ on which platform they believe a certain job belongs. This is not an object-oriented problem per se, but it is one that is likely to show up on your OO project. Defining the boundary of the OO system will require negotiation between the lead developers. Either they will have to agree or you will have to use a third party to work out the solution.
Consider using an "object-centered" design for the mainframe services to the workstation. Organize the services around the kind of requests coming from the workstation. The same objects are going to generate the same requests over time. Interestingly, object-centered design has twice been suggested to me by lead mainframe designers, not OO designers.
Relational Databases
Relational databases are fundamentally different from object databases and OO code. Here is a colorful allegory to illustrate the difference:
You are parking your car in an object-oriented garage. You drive into the garage, get out, close the car door, and walk into your house. When you want to leave again, you walk into the garage, climb into the car, start it, and drive away. You are parking your car in a relational garage.
You drive into your garage, get out, take off the car doors, put them onto the stack of doors; take off the wheels, put them onto the stack of wheels; take off the bumpers; and so on. You walk into your house. When you want to leave, you walk into the garage, take the doors off the doors stack, take the bumpers off the bumpers stack, take the wheels off the wheels stack, put them all onto the car's frame, climb into the car, start it, and drive away.
Putting relational data together is called joining. Joins are time-consuming, exactly as the allegory indicates. Fitting an object-oriented design to a relational database calls for additional table joins, usually to capture inheritance and many-to-many relationships. Reducing the number of joins needed is part of the strenuous work of fitting an OO design to a relational database. This one activity requires a great deal of communication, patience, and time. However, it is an important activity since it involves both the people and the models from the programming and the database communities.
The two communities and their models differ in a second key respect. Philosophically, a row in a relational table has no special "identity" beyond the data it contains. Any row that contains the same data is considered "identical." Not so for objects. Philosophically, each object has its own identity, so even when two objects contain the same data, they remain different. Naively putting objects into a relational database results in a clash, probably in the form of a long, drawn-out philosophical argument between the object and database designers over whether to add an identity field to the relational table.
Project Setup C.D., Independent Consultant
If I were to going to make recommendations for a large client/server project, here are a few things I would focus on given my experiences. I'm sure you will recognize a lot of these.
Find the right help. Don't be the guinea pig for a newly formed consulting group that has decided that "objects are hot," and that's where they want to be. If the consulting group you are considering can 't provide references, it means that this is either their first project or that their other projects are "unreferenceable." Don 't become their next unreferenceable project. If references are given, call them, or better yet visit them to see what kind of development environment and development process the consulting group left them with.
Be able to identify a technical architect for the project and make sure there is a commitment for that person to be involved in the project on a daily basis. Don 't settle for a "two-to three-days per week " type of arrangement, and don 't settle for an architect who appears to be a "really bright person " but who has "poor communication skills." Hiring an architect who can 't communicate effectively the hows and whys of the technical infrastructure to both management and programmers is a recipe for disaster. Your project should not be the first project of its type for the architect. Again, demand references.
Realize that Smalltalk "out of the box "is not an appropriate tool for building complex client/server applications. Focus on transforming the completely generic development language/environment of Smalltalk into a business-specific development language/environment. Make sure that management understands the importance of this goal and is willing to allow for it in the project schedule and budget. If possible, develop your business-specific development environment over the course of several small projects. Whatever you do, don't hand your application developers Smalltalk and a database wrapper and let them "have at it."
Strive to develop and communicate standard approaches/solutions to common development scenarios. During the project, take checkpoints and surveys of the types of issues that application programmers are having to deal with on a daily basis. Make sure that the provided frameworks and standardized solutions address those problems effectively. If a framework doesn't appear to be solving the right problem or is getting in the way of the development process, cut your losses and purge it from the development environment as quickly as possible.
Document frameworks and solutions in a handbook you might title "Project ABC Developer's Guide/Cookbook. "It should present an overview of business-object schema and behavior (when it becomes available) and technical architecture. Address the 15,20,30 most common application development scenarios/problems and their standardized solutions, with pointers to examples. The solution may involve a framework, or it might just be a standardized way of solving a given problem. Examples of common problems faced by clientside developers are: How to retrieve, change, and save persistent business objects; how to translate business rules into code; and how to surface the facets and services of business objects to the GUI.
Perform design and code reviews to ensure that new solutions aren't being invented for the problems that have already been solved/documented and to identify deficiencies in existing frameworks or the need for new frameworks or standardized solutions. 7.Make sure that opportunities for reuse between projects are exploited. Interproject communication is essential. Make sure that there is one solution developed and used for a problem that is shared by multiple projects; for example, technical infrastructure (persistence, validation, window management) and possibly even business domain objects.
Case material contributed by a third party, used with permission.
If the relational database's purpose is to support the objects, it will have to have an identity column. Technically, this is simple: Just use the unique key that is automatically generated by the database management system. The situation will be harder to resolve if the database has been there for a long time and it is not practical to add an identity column.
A third, greater hazard to your project when using a relational database is what is called the "persistence black hole." Rather than buying an OO database or buying a commercial framework for interfacing to a relational database, your team decides they can do the whole thing quickly and inexpensively by themselves. They say, "We'll just store the objects as rows. Easy enough."
A short while later, they find they have to optimize joins. Soon after, they find they have to handle transactions and transaction rollback. Then, they face checkpointing data and optimizing data transfer. Finally, they realize they have not adequately handled the object identity issue, and must retrofit that into the system.
In the end, they find they have built a small OO database system. It cost at least $300,000 for their two work-years of effort—perhaps triple that, if they were good enough to complete it at all. This little project-within-your-project swallowed your best programming talent for perhaps a quarter of your project's timeline. You would have been better off buying an object-oriented database to begin with.
If you do decide to use a relational database, search extensively for a company that has already built the persistence subsystem, then buy it. It will cost you much less, and will free up your best programmers to do your project work.
Beware of the "persistence black hole."