H.S. Lahman on OO and MDA

1.0 Selecting an OOA/D book

Blog root page
next post in category

One needs to understand OOA/D even if one is doing an OOP-based process like XP where one rarely does formal modeling. Even when one doesn't model, one needs to know how to abstract the problem space into classes, responsibilities, and collaborations. It's kind of like iteration, sorting, direct element access, and a whole bunch of other stuff software people tend to take for granted when programming -- the fundamentals are there but we rarely consciously think about them.

I would be cautious about book reviews. While they are useful for separating out the chaff, they may not be useful for choosing among the better books. That's for a couple of reasons. Reviewers who already use the author's methodology are much more likely to view the book in a kindly fashion. There is also a possible problem in the perspective. That is, the review may be quite accurate that it is a good book, but it is really about something other than what you want or it is focused differently than you would like (e.g., theoretical vs. pragmatic). Finally, there is the matter of style. One will tend to "click" better with one author than another if they have significantly different writing styles. In the end it is important to get the book that is the easiest read for you for a given subject matter. So it is important to go to the local bookstore, library, or university bookstore and browse.

I would look for a book with OOA and/or OOD in the title. But I would avoid books with 'UML' or a particular OOPL in the title. Such books are usually more focused on manipulating syntax than fundamentals. IOW, they do a good job of explaining how to represent your design but they don't help a lot in figuring out the right design in the first place.

Then look up certain groups of words in the index. In particular look for {class, object, instance}, {method, message}, {responsibility, attribute, method}, and {class, entity, type}. If any of these words are not in the index, put the book back on the shelf. Assuming they are all there, read the sections that define each term. If you feel the author has clearly defined each term and, more important, you feel you understand the differences between the terms, then it is problem a pretty good book on the fundamentals.

[If the author also explains Why the terms in each group are different and Why we should care, then let me know and I will buy the book!]

There one other thing to watch out for. If the index has more entries under 'type' than under 'class', put it back on the shelf. A type system is a mechanism for implementing an OOA/D class system at the 3GL level. So if the author is more interested in types than classes, it indicates the author is really more focused on OOP than OOA/D.

Blog root page
next post in category

2.0 My bookshelf for OOA/D/P

Blog root page
previous post in category
next post in category

Selecting a good book on OOA/D/P tends to be a personal choice because style can be an important bridge to understanding and author's styles vary a great deal.  However, the following are the books that have stood the test of time on my own bookshelf...

Object-Oriented Software Construction by Bertrand Meyer.  This book was my personal epiphany to OO development back in the early '80s.  Meyer had an agenda in that the book justifies Eiffel, the OOPL he designed.  Nonetheless it is a classic in the field and he does an excellent job of explaining Why we should use OO techniques.

Executable UML by Steve Mellor and Marc Balcer.  This is a modern update of the Shlaer-Mellor methodology, which I've used for nearly two decades.  The primary goal of the book is to define an MDA profile suitable for PIM models when doing translation, so it is a little short on practical How-To for doing OOA/D.  However, Mellor is a premier modeler and the examples are excellent.  Mellor was an early advocate of modeling invariants while leaving detailed differences to data and the models strongly reflect that.  In other words, the models are often suitable for large scale reuse.

Executable UML: How to Build Class Models by Leon Starr.  This is unquestionably the most comprehensive book on Class Modeling available.  Starr deals with topics I've never seen mentioned by other authors.  Though the book addresses only PIM modeling for translation methodologies, it is still the most complete text on the subject around.

Object-Oriented Software Engineering by Ivar Jacobson et al.  Though a bit out of date by today's standards, it is still a classic exposition of applying use cases to OOA/D.  Jacobson was the primary advocate of employing use cases in software development and has had substantial influence on both OOA/D technique and requirements specification.

Object Design: Roles, Responsibilities, and Collaborations by Rebecca Wirfs-Brock and Alan McKean.  Wirfs-Brock's early writings were also a part of my OO epiphany.  This is an updated version of her role based approach.  Here stuff is important because she was a pioneer in emphasizing abstraction of responsibilities rather than just data and operations.  I am a bit uncomfortable about her emphasis on requests in collaboration, but her treatment of role-based anthropomorphism is excellent.

Object-Oriented Design Heuristics by Arthur Riel.  This is another classic.  It is a practitioner's view of OOA/D that provides cookbook techniques for dealing with everyday design problems.  It did for OOA/D what Fowler's book (below) did for OOP.  Though the justifications for the techniques are a bit dated by today's standards, the heuristics themselves are timeless.

Design Patterns by Erich Gamma et al.  (Aka the GoF Book, as in Gang of Four authors.)  Though relatively recent, this book has become a classic.  It was the first book to apply basic pattern recognition to software development.  The patterns have become a lingua franca for communicating designs.  Though the patterns in the book are limited to reifications of relationships that have too much dynamic complexity to express in simple associations, that covers a huge amount of ground in practical design.

Large Scale C++ Software Design by John Lakos.  This was the first formal recognition of one of the root causes of software mantainability problems: physical coupling in 3GLs in general and OOPLs in particular.  While the the book is concerned with C++, which is the worst offender, the ideas are readily transferable to other languages.  The techniques he provides for solving the problems are dated today, but his exposition of the root causes is still among the best.  He also provided quantitative data on the performance costs of dependency management.

Refactoring by Martin Fowler.  This is actually a better How-To book for dependency management than Lakos' book, mainly because it is more modern and benefits for a decade of raised consciousness about physical coupling.  Essentially it is a distillation of OOA/D ideas into rules, guidelines, and policies suitable for OOP.  If it has a shortcoming it is that it doesn't spend much time explaining why the problems it addresses are problems.

Agile Software Development by Robert Martin.  Along with Lakos, Martin was one of the first to expound about fundamental coupling problems in OOPLs and he essentially pioneered the field of dependency management.  While I am on the opposite end of the development spectrum from the OOP-based agile processes that Martin advocates through the book, the Principles he describes for managing dependencies are something every developer who manually writes code in an OOPL should understand.

Object-Oriented Software Testing by Bob Binder.  Probably the most comprehensive book available on the testing of OO software.

Software Metrics by Fento and Pleeger.  This is a good book about the basics of software measurement.

Metrics and Models in Software Quality Engineering by Stephen Kan.  This is a more theoretical book about the models used  for SQA.  Nonetheless it provides a good, readable explanation of a topic that most software engineers sadly do know know exists.

Applied Software Metrics by Capers Jones.  Though a bit out of date now, this was a classic in the field of software metrics.

Successful Software Process Improvement by Robert Grady.  This book has already become a classic in software process engineering.  It is effectively a chronicle of Grady's experiences at HP that helped build HP into a legendary high-quality software shop.  It is particularly noteworthy because Grady introduced many of the described practices to software engineering.  The book is essentially an application of TQM to software development.

A New American TQM by Shiba, Graham, and Walden.  This is a general description of Total Quality Management as currently applied in the US.  Though not specifically focused on software development, I have used the tools described for nearly two decades and I can testify to how well they work.  Anecdotal data point: in 1984 we were 24 months late on a 9-month project, overtime was routine, the mean time to system crash was about 40 minutes, and each subsystem of the software had ~1K customer defect reports per release.  We applied TQM principles religiously for a decade.  By the mid-'90s we hit one-year schedules about -5/+15% without overtime, our defect rate was down to about 0.2 defects/KNCLOC released to System Test, and we could count our customer defect reports for the whole system for a release on two hands.  We got an award form the USN for 600 deployed systems that had an average MTTF of 2.7 years in 24x7 operation, including hardware failures.  I cannot overemphasize how important a process like TQM is to software development.

Revolutionizing Product Development by Wheelwright and Clark.  This is an excellent reading for placing software development into context with the rest of the business context.  While it is mostly just relevant to the way requirements are gathered for software development, that context is particularly interesting in light of today's vogue for agile OOP-based processes that attribute great importance on the idea that requirements priorities change.

If you are wondering why my list has almost as many books on metrics and process as it has book on OOA/D/P, there is a reason.  Anyone who believes that grinding out 3GL code is all that software development is about is not living in the real world.  The only thing that currently breaks in the customer's world is software and that has been noticed.  It is no longer possible to pass off unreliable software as something that is unavoidable because of the inherent creative content.  (That is, other engineering disciplines are somehow not as creative in their design efforts as software developers.)  Nor is it tenable to believe that one can achieve high software reliability through testing.  (At best one can achieve 5-Sigma quality with testing; for 6-Sigma and beyond one need militant defect prevention.)

The software industry is going to have to learn what other engineering disciplines learned decades ago: reliability and scheduling are process issues that are orthogonal to the fundamental product design.  Processes need to be managed, which requires data collection, metrics, and a disciplined, self-correcting process needs to be in place as a framework for design creativity.  Developers can no longer afford the luxury of myopia around pure software issues.  So don't kid yourself -- if you want to think of yourself as a software engineer you are going to have to know as much about the process side of things as the design side.

Blog root page
previous post in category
next post in category

About Pathfinder Solutions

Blog root page
Previous page in category

Since Pathfinder Solutions has been kind enough to sponsor this weblog, I need to provide some information about them. Pathfinder Solutions is a company that provides tools and consulting related to translation.

Translation is a paradigm shift in the way software is developed. Translation is a logical evolution in software development that represents automation and design reuse of the computing space. When I started in this business programs were done on plug boards. Assembly Language was the Silver Bullet to solve the Software Crisis while FORTRAN and COBOL hadn't been introduced and there weren't even linkers or loaders. Over the decades a whole lot of automation has been introduced to the point where writing Assembly is now an anachronism in specialized niches like embedded systems and it is possible to develop entire applications using RAD environments without writing even 3GL code.

That automation is possible because the computing space itself is highly deterministic. Everything we do in that space must eventually be unambiguously mapped into the computational models of Turing and von Neumann. So everything in the computing space tends to be defined with mathematical precision. Thus automation is an inevitable evolution. However, it is not achieved without pain because the computing space is quite large and enormously complex.

Though the technology has been around since the early '80s, it was not until the late '90s that the engineering had improved to the point where it could enter the mainstream of general purpose software development. In addition, it was only in the late '90s that the Object Management Group (OMG) provided much needed standardization through its Model-Driven Architecture (MDA) initiative.

Once one automates the computing space, though, there are tremendous benefits. All nonfunctional requirements -- size, performance, reliability, maintainability, etc. -- depend upon the specific computing environment. (The "computing environment" is a catch-all for target 3GL, hardware platform, operating system, technologies like networking, infrastructures like EJB or .NET, and a host of other specialized facilities.) The basic idea behind translation is that one can isolate those concerns in a transformation engine that is tailored to the specific environment. That engine can then optimize any application that needs to execute in that environment. In effect one gets compete reuse across applications of engineering that deals with optimization for nonfunctional requirements.

That, in turn, allows the application developer to focus exclusively on the solution to the functional requirements of the particular customer problem without being concerned about optimizations for nonfunctional requirements. That focus improves productivity and reliability enormously, especially when the notation employed has the abstraction of a fourth generation language (4GL). It also allows portability of the application across computing environments without any change to the solution.

Pathfinder Solutions provides tools for 100% 3GL code generation from 4GL UML models, consulting, mentoring, and other services related to translation. If you are not familiar with translation, I strongly urge you to visit their web sight and peruse their technical papers. It could mean double-digit improvement in your bottom line.

Blog root page
Previous post in category