Successfully piloting large-scale object-oriented software development projects requires careful navigation
Edmund X. Dejesus
Missed deadlines. Poor training. Lack of commitment. These are the signposts on the way to Failure City.
Peter Fontana
knows all about failure. More accurately, he knows how to avoid it. Fontana is a consultant helping GTE make a large-scale OO (object-oriented) development project succeed, despite a path strewn with pitfalls and potholes.
The project is astoundingly large: GTE Government Systems is completely rewriting the firmware and software for its new high-capacity ATM (asynchronous transfer mode) switch. This means that several dozen people have only 18 months to reengineer several hundreds of thousands of lines of code. And then they can start facing
upgrades.
If it sounds impossible, it is--at least if you tried to use conventional engineering techniques. There's no way this group could do the project in the C and Ada code that the previous ATM switch used. GTE knows this. That's why, from the start, management chose to implement an OO approach over traditional methods. There's at least a fighting chance. Especially when version 2 rolls around in a few months.
Inviting Disaster?
Wait! Doesn't OOP (object-oriented programming) take longer to learn? Doesn't it generate bloated, slow code? Isn't using a new technique just inviting disaster? Maybe--if you burst in expecting to churn out 10,000 lines of code a day. The OO mindset is
radically different from the traditional.
OO development models the business problem instead of just throwing code at it. It might take more time and effort but, because it looks at the process as a whole, a successful model can solve both the original problem a
s well as related problems. The expected payoff is in better problem analysis, faster development, higher quality code, simpler subsequent development and maintenance, and reduced overall cost.
Once having decided to go OO, you may think that you just start coding in C++ or SmallTalk. Hardly. Writing code is a small part of any OO project. Choosing a method is actually step one.
There are several OO methods, each of which determines much of the process a project will follow. One broad category is called
elaborational,
and includes Booch, Rumbaugh OMT (Object Modeling Technique), and similar methods. Attractive to code-oriented developers, this approach iterates through analysis, design, and coding, capturing additional information on each pass, until the final iteration is at the code level. GTE felt that this style was too time-intensive, required many highly trained creative and experienced people, and was prone to error.
The
translational
style, which includes the Shl
aer-Mellor method (see the figure
"The Shlaer-Mellor Method"
), automatically translates OOA (object-oriented analysis) models into code based on the CASE information. Partitioning the problem into independent domains, with implementation details separate from the application analysis model, allows concurrent development of the application analysis and the translation mechanism design. Also, software projects tend to fix problems in the code without making appropriate changes to the design, and difficult disjoints between design and code may complicate further development. But translational methods help calm the temptation to fix problem code, since fixing the model itself will translate into changed code, keeping design and code in sync. Tool sets can check semantic correctness, consistency, and completeness.
Starting from scratch on an OO project, as in this case, can be difficult, but Fontana feels that Shlaer-Mellor is a more complete method in such cases. So the GTE projec
t adopted Shlaer-Mellor, supported by Cadre Technologies' ObjectTeam for Shlaer-Mellor running on Sun SparcStations.
Model Merits
"Without a method, OOP is just another way to hack code," says Fontana. You may find yourself tempted to grab a CASE tool and just start coding. It's happened often enough. But you won't get all the advantages of OO methods, such as reuse at the highest levels, concurrent development, and simplified upgrades. The high-level nature of the initial analysis forces developers to think about, and solve, the problem more completely up-front.
Fontana sees many benefits to Shlaer-Mellor. These include its concise notation, its ability to translate method to code automatically, its partitioning of the problem into logical domains, and its opportunities for code reuse at the domain level.
Why not another method? Fontana preferred Shlaer-Mellor's concise notation, especially because this was the first foray into OO development for many programmers
. Though other methods proudly claim a "rich notation," watch out: That could be a synonym for "too many choices." It's fine to have many choices if your entire programming staff is the cream of the crop, but for the rest of us, Shlaer-Mellor's more concise notation is simpler to learn, easier to translate into code, and less confusing, especially for first-time OO developers. Since many of GTE's developers had never used OO methods, Fontana's choice makes sense.
The Reuse Grail
The main reason GTE chose OO development was code reuse. The ATM-switch software was slated for update every six months--an aggressive schedule, especially for adding new features. Reusing code would save time and development costs and simplify future development projects.
Developers aren't automatically reusers. They might require specific training or experience with the reuse system. Allocating or assigning a reuse librarian (a human being), or using a CASE tool like ObjectTeam, can help by bui
lding and managing searchable libraries of objects. Still, some programmers find it harder to use an existing component than to write one from scratch.
The benefits of reuse are especially realized for large-scale, long-term projects with expected upgrades or future related projects. The GTE project meets all of these criteria, and developers expect a large reuse bonus in terms of saved time, especially when related projects reuse entire domains.
Method Minuses
Life is not a bed of roses, even with Shlaer-Mellor OO methods. GTE found that it had to deal with training people in new methods, new programming languages, new support tools, and new platforms. And, possibly the greatest challenge, it had to overcome hesitancy from workers.
Multiple learning curves present the foremost problem. Some project team members required greater familiarity with new hardware (Sun SparcStations, instead of the Macintoshes most of the developers were familiar with), new OSes (SunOS
and Solaris vs. MacOS), new tools (Cadre's ObjectTeam where before there was nothing), a new language (C++, instead of Ada and C), plus OO methods in general and Shlaer-Mellor in particular (rather than traditional functional decomposition). That's definitely a lot to absorb.
Fontana observes that traditional experience can run against you, especially if experience means, "I'm not learning some new method when the old method worked just fine." To facilitate change, start with five or six forward-thinking people on a six-to-nine-month pilot project: This builds support for new methods. By building support from your initial group outward, you don't have to forcibly convert people.
The key to success is to get going: Real pressures force organizations to face the changes and move forward. "To start the journey to get functionality to market, you have to step off the dock," Fontana says.
Take Hung Trinh, for example. He's a GTE software engineer who had programmed previous switches in assembl
er and had no prior experience with OO methods or C++. He found it hard to learn Shlaer-Mellor at first, but within about three months he felt comfortable. A course in C++, building on previous C knowledge, helped clarify how the OOA model translates into code. An added benefit: He believes his C++ and Shlaer-Mellor experience enhances his career.
Appropriate support tools simplify starting with a new OO method. For instance, ObjectTeam supports Shlaer-Mellor recursive design, diagrams, and notation. Automating the method's details can flatten a learning curve. By contrast, software architect Jim Connolly feels that current ObjectTeam tools don't adequately support configuration control and releases (especially for parallel configurations), requiring manual workarounds. While appreciating some features of ObjectTeam, Trinh thought the editor and other parts difficult to use.
Another possible pitfall for some companies is that metrics for OOA projects differ from conventional metrics. Some may in
sist on using the old "
x
percent lines of code done" milestones. Project-level management must vigorously defend the new metrics to upper management. Shlaer-Mellor is a consistent and straightforward method, with discrete steps and milestones, although not the traditional ones. GTE's management uses the new metrics and has changed its way of reading metrics.
Fontana has also seen upper management in other companies get antsy and say, "No code yet? Forget the pretty pictures, start coding." GTE's management has a more sophisticated view: They don't expect to see any code until they're about 60 percent of the way along. They then anticipate getting 50,000 to 100,000 lines of automatically translated code (bug-free, assuming that the architecture level and translator are correct) in a week. ObjectTeam for Shlaer-Mellor provides checking of milestones. Simulation and testing of the high-level analysis itself reduces the errors seen at the code level.
Defending against management panic usual
ly includes pointing out the chosen method's historical success stories, gleaned from consultants, books, and published case histories. High-priced consultants can be very cost-effective if they can save an endangered multimillion-dollar project from the chopping block.
As if all this weren't enough, Connolly observed that scheduling and planning--requiring insights only available through experience--can be a nightmare for administrators unpracticed in OO methods. Consultants can help by estimating such factors as the number of objects based on specifications, how much time each phase should take, when to review, and analysis rules of thumb. Project Technology (founded by Sally Shlaer and Steven J. Mellor) provides consulting services, training, and books. Fontana has found that such knowledgeable and experienced consultants, like guides through the wilderness, can help you tell "the lettuce from the poison ivy." Connolly, too, felt that consultants and training services were almost essential in helpin
g managers deal with schedules, plan team assignments, and select appropriate tools. Trinh found that Project Technology consultants offered helpful suggestions, especially with part of the analysis that seemed open to the risk of errors. The consultants did underestimate the time required for certain activities, probably because they did not fully appreciate the extreme complexity of the switch.
GTE declined to talk money, but one analyst experienced with OO development suggested a ballpark price tag of $5 million to $10 million for the initial 18 months of the project. In an OO project, you can estimate the number of objects required by the number of distinct entities--both tangible, like airplanes or invoices, and intangible, like roles or events--the project must address. These entities can range from a handful, for projects far smaller than GTE's, to several hundred or even several thousand for extremely complex problems. Information from Project Technology suggests you should allow one person/mon
th (at about $9000) per object. Naturally, your mileage may vary, depending on the experience and pay-rate of the developers.
The Future Course
Despite encountering many cultural and technical problems, the GTE project is over half done and still on track, both Connolly and Fontana agree, with productivity at least as good as it would be using traditional methods. Based on projects by experienced colleagues, Fontana feels that, had there not been so many new technologies for developers to absorb, even higher productivity rates (and lower costs and faster deliveries) probably would have occurred. In this project, the payoff will be faster deliveries and simpler development for subsequent releases--a real bonus of successful OOP.
WHERE TO FIND
Cadre Technologies
Providence, RI
(800) 743-2273
(401) 351-5950
fax: (401) 455-6800
Kennedy Carter
London, U.K.
+44-181
-947-0553
Objective Spectrum
Cary, NC 27511
(919) 460-1500
Project Technology
Berkeley, CA
(510) 845-1484
Rogue Wave Software, Inc.
Corvallis, OR
(800) 487-3217
(503) 754-3010
fax: (503) 757-6650
SES (Scientific and
Engineering Software)
Austin, TX 78746-6564
(800) 759-6333
(512) 328-5544
Sun Microsystems
Mountain View, CA 94043-1100
(800) 821-4643
(800) 821-4642 (CA)
(415) 960-1300
fax: (415) 969-9131
LARGE-SCALE OBJECT-ORIENTED DEVELOPMENT
THE PROBLEMS
-- Upgrading software and firmware for high-end ATM (asynchronous
transfer mode) switch.
-- Meeting demanding delivery schedules.
-- Allowing for possible future expansion into a line of products.
-- Dealing with multiple learning curves.
THE SOLUTIONS
-- OO (object-oriented) software development.
-- Shlaer-Mellor method of OO development.
-- Cadre Technologies' O
bjectTeam for Shlaer-Mellor CASE tool.
-- Consultants provide guidance for planning and scheduling.
-- Training in C++ and Shlaer-Mellor method.
THE BENEFITS
-- On target to meet deadlines.
-- Productivity meets or exceeds non-OO methods.
-- Concurrent development of application analysis and
implementation design saves time.
-- Flexibility allows changes to hardware implementation without
impacting analysis.
-- Shlaer-Mellor OOA is reusable on future related projects.
-- Nonexpert developers can get up to speed quickly.
-- Management and developers gain experience for future projects.
LESSONS LEARNED
-- Choose an OO method appropriate to the project before choosing
the tools and language.
-- Management support is essential.
-- Expect multiple learning curves when using new development technologies.
-- Build support for OO methods with the most progressive workers.
-- Use metrics appropriate to method.
-- Consultants can offer valuable insights
for planning and process.
TOOLS SUPPORTING SHLAER-MELLOR
Cadre's
ObjectTeam for
Shlaer-Mellor
shows windows including a State Transition
Diagram and a State Event Matrix. Available for SunOS, Sun Solaris,
HP-UX, Digital Unix, DEC OpenVMS, DEC Ultrix, IBM AIX, IBM OS/2, and
SGI IRIX.
Objective Spectrum's BridgePoint 3.0
provides a user interface for
easy navigation between model components. Available for SunOS, Sun
Solaris, HP-UX, and SGI IRIX. (Objective Spectrum was recently
acquired by Project Technology.)
Kennedy Carter's Intelligent OOA
(object-oriented analysis)
application development environment propagates changes to the model
automatically and provides debugging and regression-testing support.
Available for Sun Solaris, IBM AIX, HP-UX, and DEC OSF/1.
SES's (Scientific and Engineering Software) Objectbench
Consists of a
graphical modeling tool for creating
OOA models and an on-screen
animated simulator for examining the dynamic behavior of OOA models.
Available for SunOS, Sun Solaris, HP-UX, and IBM AIX.
illustration_link (46 Kbytes)
Shlaer-Mellor is often used for large-scale and complex projects. Domains partition the system into independent areas: application (what the user cares about), software architecture (responsible for translating the OOA model to the computer language), and so forth. Reuse on the domain level brings greater return on investment than reuse of design or programming components.
Analyzing each domain produces an object informatio
n model that defines objects, their attributes, and relations to other objects.
Each object has a state model to describe its behavior and interactions with other objects.
Each state has a process model that details the processing needed in each state.
illustration_link (34 Kbytes)
TRADITIONAL
Traditionally, system analysis produces an analysis of the problem, then system design creates a design to implement that analysis, and then code is written to carry out the design. Testing the code may result in bugs (fixed in code), design changes (requirin
g redoing design and code), or system changes (requiring redoing analysis and design and code). Changes at any level require work and testing at all lower levels. Often, only the code is changed, and analysis and design are never updated.
SHLAER-MELLOR
In Shlaer-Mellor, analysis of independent domains can happen in parallel and concurrently. Simulation and testing can occur at the analysis level. The model translates directly into code. Changes to one domain need not affect other domains. Since change at the analysis level translates directly into code, code and analysis stay in sync.
photo_link (106 Kbytes)
screen_link (17 Kbytes)
Edmund X. DeJesus is a BYTE senior editor. He has a Ph.D. in physics and has been a professional programmer for more than 15 years. You can reach him on the Internet at
edejesus@bix.com
.
Big OOP, No Oops
