Written by the inventor of the Bassett Frame Technology, this authoritative volume explains how cost-effectiveness of large IS departments can be improved 50-fold by implementing highly effective software engineering.
| |||||||||||||||
Book Description
Editorial Reviews
From the Publisher
The complete guide to frame-based code reuse techniques -- by their inventor! Written by the inventor of the Bassett Frame Technology, this authoritative volume explains how IS cost-effectiveness can be dramatically improved through reuse technologies that really work. It explains basic concepts, especially the central role of reuse in software engineering, and presents the software assembly commands of frame technology. Learn frame engineering principles through simple examples and case studies. Explore the software design and development process, both for reusable frame components and for systems assembled from them. Understand the design principles for software construction tools, and connects frames to advanced mathematical ideas such as context-sensitivity. This is an ideal guide for software practitioners, managers, consultants, researchers, faculty and students involved in software engineering and reuse.
From the Inside Flap
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 unpredictable modifications 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.
Origins
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.
Overview
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.
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 unpredictable modifications 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.
Origins
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.
Overview
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.
Product Details
Would you like to update product info or give feedback on images?
|
More About the Author
Discover books, learn about writers, read author blogs, and more.
Customer Reviews
|
Share your thoughts with other customers:
|
||||||||||||||||||||||
|
Most Helpful Customer Reviews
7 of 7 people found the following review helpful:
5.0 out of 5 stars
Excellent book on reuse,
This review is from: Framing Software Reuse: Lessons From the Real World (Textbook Binding)
I thought I was becoming comfortable with OO until I ran into a group of Smalltalkers. What a mind bender! I learned things about OO that I didn't know. I also became concerned as, ostensibly for reuse purposes, the design stage decoupled logically unrelated functionality and fragmented real-world objects far beyond their natural granularity, to the point that I found myself mired in bitty components and methods with so little responsibility that I could no longer see the big picture. Worse, those myriad components now had complex interrelationships, most of which I could no longer see. I fully agreed that reuse was a worthy goal - but at the expense of readability and maintainability? Paul G. Bassett not only identifies and describes all of these issues (and much more), he has concrete solutions to these problems, with bottom line statistics to back up some pretty wild claims. His book is small - initially a concern for me. Don't worry. Paul G. Bassett is clear, concise, correct, complete. This, I strongly believe, is where we're headed.
2 of 3 people found the following review helpful:
5.0 out of 5 stars
Be prepared for a shock,
By one@zeroconfig.com (Munich, Germany) - See all my reviews
This review is from: Framing Software Reuse: Lessons From the Real World (Textbook Binding)
I have pretty much experience with object oriented and procedural programming in several languages, now getting into AOP and byte code engineering. The first 30 minutes with this book were dissapointing - i couldn't figure out what the heck this guy is talking about. So i started at the front, not back cover. And this is my hint - read it from the beginning, page by page. I knew, there is something wrong with software development in general, now i know what it is exactly, and why. I knew it! More - i know how i can break this vicious circle and burn the tires. We've been going the wrong way folks! This definitely is the most valuable book in my monster library (some 100 titles). This is the top secret knowledge, worth thousands and thousands of bucks. I really am not related to the author or publisher. Great stuff!
5.0 out of 5 stars
Excellent design philosophy,
By A Customer
This review is from: Framing Software Reuse: Lessons From the Real World (Textbook Binding)
Found my first copy in the university book store in Ames, Iowa, and have been looking at it constantly, until I lost it in one of my numerous moves. Bassett has the right idea. Software should be **engineered**, not hand crafted, and Netron seems to have found at least one way to do it. Another thing. To my knowledge, no one else in the field has advocated the notion of **balance** between source level changes and the re-use of executeable objects. This is probably the most important idea expressed here.
Share your thoughts with other customers: Create your own review
|
|
Tag this product(What's this?)Think of a tag as a keyword or label you consider is strongly related to this product.
Tags will help all customers organize and find favorite items. |
Sell a Digital Version of This Book in the Kindle Store
If you are a publisher or author and hold the digital rights to a book, you can sell a digital version of it in our Kindle Store.
Learn more
Customer Discussions
|
This product's forum
Active discussions in related forums
Search Customer Discussions
|
Related forums
|
Listmania!
So You'd Like to...
Look for Similar Items by Category
- Books > Computers & Technology > Computer Science > Software Engineering > Information Systems
- Books > Computers & Technology > Programming > Software Design, Testing & Engineering > Object-Oriented Design
- Books > Computers & Technology > Programming > Software Design, Testing & Engineering > Software Development
- Books > Computers & Technology > Programming > Software Design, Testing & Engineering > Software Reuse
- Books > Computers & Technology > Software
- Books > Science & Math > Mathematics
