Framing Software Reuse: Lessons from the Real Worldby Paul G. Bassett
Reuse is a fundamental principle of all mature engineering disciplines. As the software engineering field grows up, software engineers will also take advantage of this central engineering concept. Though software reuse introduces new degrees of freedom to the classical methods, you can harness those freedoms for immense practical benefit through frame technology. Frame-based systems are not only more robust, easier to tune, maintain, upgrade, interface, and port, but independent auditors have confirmed a productivity breakthrough-in a statistically significant sample, which included complex mega-projects, they compared to industry norms and found that development costs averaged 84% less, and time-to-market shrank by an astounding 70%.
Paul G. Bassett's frame technology allows the creation of language-independent software components that can adapt to each other. Framing permits high quality without sacrificing productivity, and preserves flexibility without compromising performance. Systems can be ported to multiple platforms without losing their native look and feel. By reducing complexity and redundant development, frames save time and money.
Read an Excerpt
PREFACE: This book shows software developers, analysts, and managers how to make reuse work. The book highlights frame technology: a language-independent way to manufacture software from components that can adapt each other. Why should you read this book? Because of what adaptive reuse can do for you.
Example: One Fortune 50 company's entire information systems development staff numbers only 40 people (with no outside contractors). Yet they satisfy over 28,000 user requests for software changes and enhancements each year.
Further example: A major retailer developed and deployed its mission-critical purchase-order management system in 80% less time and effort than development projects used to take them before they embarked on adaptive reuse. The project was enormous--over 1300 programs and 5 million lines of code. On the last four subsystems alone they saved $11 million in development costs, and $12 million in early deployment benefits.
Frames solve thorny, long-standing software industry problems. Finally, we can combine high productivity with high quality, preserve flexibility without sacrificing performance, port systems to multiple platforms with native look-and-feel functionality, reduce complexity (in addition to hiding it), and, most importantly, reduce the cost of so-called maintenance. Sounds like magic, right?
Wrong. It is not magic. Reuse is so fundamental to all mature engineering disciplines, it is not even part of their jargon! But effective software reuse is harder, because nonphysical things have more degrees of freedom available to them. Physical parts are reused as is. Software parts often need unpredictablemodifications before they can be reused.
Software practice has begun to mature, to acquire some of the substance and rigor that are the hallmarks of an engineering discipline. As with all new paradigms, there has been an initial period of healthy confusion. Software's "craft" phase has been an exciting half-century of brash precocity, experimentation, fads, buzzwords, religious wars--an on-going turmoil. Emerging from this pandemonium are principles that can effectively lead us out of the wilderness.
I have a very clear memory of that fall day in 1978, standing at the greenboard in my York University office, talking to my colleague, professor Gunnar Gotshalks, about the frustrations of code generators. In addition to teaching computer science, I had recently founded a software house, called Sigmatics Computer Corporation, to serve the needs of local businesses. Gunnar was under contract for Sigmatics; we were installing a custom software system for the city of Barrie, Ontario. We were using code generators I had created to automate the tedium of writing screen and report programs.
The report generator, for example, certainly avoided a lot of drudgery by automatically coding the details of report layouts, providing subtotals, and the like. Over 90% of a typical report program was generated from its wysiwyg (what you see is what you get) specification. The rest was the "fine-tuning," always necessary to adapt generated code to the specifics of the system. The frustration was not the fine-tuning per se, but the aggravation of having to manually retune it every time so much as a one character change was made to the wysiwyg specification. Most people would simply give up at this point and resort to patching the generated code. But I had built those generators and I was determined to use them!
On the greenboard I drew a state transition diagram, representing a program. "We should be able to cut any line of the graph and splice a sub-graph into the cut automatically," I said to Gunnar. Then I erased a line and drew more circles and lines, in place of the erased line. "Of course, we need to be able to nest the splices, and we should also be able to delete sub-graphs as easily as add them."
That was the genesis of "frames"#1. As hoped, I could modify my screen and report definitions, regenerate the programs, and recustomize them automatically. To my pleasant surprise, I also could modify frames without affecting programs already containing those frames. This smooth meshing of frames with generators and existing programs produced a palpable sense of untapped power.
It was immediately obvious that even without code generators, frames could be reused in interesting ways. They were a universal way to package information into components�any text in any language (including natural languages such as English) could be constructed entirely from frames. During the assembly process, frames automatically adapted, and were adapted by, other frames. But the real proof of the pudding has been in the eating. Hence this book.
The rules of chess are simple, but master-level play is not. Just so, frame technology is simple, but its implications become simple only when we change the way we think about software development. In my own case, for example, it was to take me over a decade to reach my present, still limited, understanding of why frames work as well as they do.
This book is intended for both practitioners, especially those involved in business application software, and their managers. They will learn how to overcome many of the frustrations plaguing current practice. Students of software engineering will find a conceptually integrated, easy-to-learn software design and construction process.
You can understand reuse, and how to make it work, from this book. To use frame technology in practice, as is the case with any technology, requires a tool set. Netron, Inc., provides such tools, but describing them exceeds my purpose and scope.
This book is divided into four parts, and interspersed with case studies of practical applications.
Part I, called Executives Overview--Reuse That Works, provides an executive's overview of reuse: concepts, technology, methodology, infrastructure, and culture. But theories, no matter how intriguing, must be backed by tangible results. Those who have applied the ideas in Part I have reduced project costs and time-to-market by an order-of-magnitude or more.
Part II, Frames Enable Reuse, goes into details about component- based software engineering and frame technology, including analysis and design issues. Frames are compared to other software constructs, including an explanation and discussion of object orientation. However, technology merely enables. Reuse, to achieve its greatest effectiveness, must also involve the appropriate processes, infrastructure and cultural attitudes. Managers can, if they wish, proceed directly from Part I to Part III.
Part III, Reuse Changes the Software Engineering Process, explains how reuse changes the software development process: how to develop and standardize adaptable components, and, in parallel, how to develop systems that reuse those components.
Part IV, Managing the Transition, returns more thoroughly to the challenge of transforming organizations into ones that obtain two orders-of-magnitude advantages from adaptive reuse.
and post it to your social network
Most Helpful Customer Reviews
See all customer reviews >