Words of Wisdom ...

• "Our primary tool for design is abstraction. It allows us to effectively use encapsulation, inheritance, collaboration, and other object-oriented techniques."
  Rebecca Wirfs-Brock, Alan McKean, 2002, Object Design: Roles, Responsibilities, and Collaborations
  
  
  
• "... the most significant complexity of many applications is not technical. It is in the domain itself, the activity or business of the user. When this domain is not handled in the design, it won't matter that the infrastructural technology is well conceived. A successful design must systematically deal with this central aspect of the software."
  Eric Evans, 2003, Domain-Driven Design: Tackling Complexity in the Heart of Software
  
  
  
• "Patterns provide software designers with a common vocabulary. As designers, we use patterns not on;y to help us leverage and duplicate successful designs, but also to help us convey ideas to developers using a common vocabulary and format."
  Deepak Alur, Dan Malks, John Crupi, 2003, Core J2EE Patterns: Best Practices and Design Strategies
  
  
  
• "Object modeling addresses the 'what' of the business; its concern is only with what is to be built, never why or how. Prior to the object modeling session, a good object architect inquires about the “why” questions, and raises a red flag if no one at the client site knows the answers. Clients not clear on their strategy are not ready to discuss what they want to build."
  Jill Nicola, Mark Mayfield, Mike Abney, 2001, Streamlined Object Modeling: Patterns, Rules, and Implementation
  
  
  
• "Just as the transition from black-and-white photography to color is so profound, the transition from black-and-white modeling to color is an awesome one."
  Peter Coad, Eric Lefebvre, Jeff De Luca, 1999, Java Modeling In Color With UML: Enterprise Components and Process
  
  
  
• "Classes and objects form an outline, a skeleton, an organizational framework that is easy to understand and likely to be much more stable over time when compared to software organized around data, functions, or external interfaces."
  Peter Coad, David North, Mark Mayfield, 1996, Object Models: Strategies, Patterns, and Applications
  
  
  
• "When doing analysis you are trying to understand the problem. To my mind this is not just listing requirements in use cases. … Analysis also involves looking behind the surface requirements to come up with a mental model of what is going on in the problem. ... Some kind of conceptual model is a necessary part of software development, and even the most uncontrolled hacker does it."
  Martin Fowler, 1996, Analysis Patterns: Reusable Object Models
  
  
  
• "In reality, in even the simplest project, developers do some amount of modeling, albeit very informally. … Even in the realm of disposable software … modeling can help the development team better visualize the plan of their system ..."
  Grady Booch, James Rumbaugh, Ivar Jacobson, 2005, The Unified Modeling Language User Guide
  
  
  
• "Systems analysis exhilarates and exasperates those who fall prey to its siren song. What is so difficult about analysis? What is the challenge? We feel that four major difficulties plague systems analysis on all types of projects: problem domain understanding, person-to-person communication, continual change, and reuse."
  Peter Coad, Edward Yourdon, 1990, Object Oriented Analysis
  
  
  
• "When one uses abstraction, one admits that a real-world artifact is complex; rather than try to comprehend the entire thing, one selects only a part of it."
  Peter Coad, Edward Yourdonn, 1991, Object-Oriented Design
  
  
  
• "You do need to take the time – really take the time – to properly architect your system. If you begin coding with the very first architecture that comes to mind, you'll waste a lot of time thrashing around in code."
  Peter Coad, Jill Nicola, 1993, Object-Oriented Programming
  
  
  
• "Inheritance was all the rage in the early days of object-oriented development. But over time, designers have discovered that inheritance is effective only within certain contexts. Composition, in tandem with interfaces … is far more common, far more generally useful, and much closer to the heart of good object-oriented design."
  Peter Coad, Mark Mayfield, Jonathan Kern, 1996, Java Design: Building Better Apps and Applets
  
  
  
• "The best software designs look simple, but ... it takes a lot of hard work to design a simple architecture."
  Grady Booch, 2007, Object-Oriented Analysis and Design
  
  
  
• "Any fool can write code that a computer can understand. Good programmers write code that humans can understand."
  Martin Fowler, 1999, Refactoring: Improving the Design of Existing Code
  
  
  
• "... he [Ralph Johnson] brought out the point that architecture is a subjective thing. A shared understanding of a system's design by the expert developers on a project. Commonly this shared understanding in in the form of the major components of the system and how they interact. It's also about decisions,..."
  Martin Fowler, 2003, Patterns of Enterprise Application Architecture
  
  
  
• "One thing expert designers know not to do is solve every problem from first principles. Rather, they reuse solutions that have worked for them in the past. When they find a good solution, they use it again and again. Such experience is what makes them experts. Consequently, you'll find recurring patterns of classes and communicating objects in many object-oriented systems."
  Erich Gamma, Richard Helm, Ralph Johnson, John M. Vlissides , 1994, Design Patterns: Elements of Reusable Object-Oriented Software
  
  
  
• "We all want our software systems to be fast, reliable, easy to use, readable, modular, structured and so on. But these adjectives describe two different sorts of qualities. On one side, we are considering such qualities as speed or ease of use, whose presence or absence in a software product may be detected by its users. These properties may be called external quality factors. … In the end, only the external factors matter. ... But the key to achieving these external factors is in the internal ones..."
  Betrand Meyer, 2000, Object-Oriented Software Construction
  
  
  
• "Use case modeling, when used in isolation and performed incorrectly, may lead to certain types of problems.... the possibility of ending up with a functional model instead of an object model. … Use cases authored by different developers may describe the same thing differently. … When domain analysis is performed in conjunction with use case modeling, it reduces the risk of a functional design. … Domain analysis pinpoints the language to be used to create textual descriptions in the use cases."
  Frank Armour, Granville Miller, 2001, Advanced Use Case Modeling: Software Systems
  
  
  
• "The fundamental reason to use UML involves communication. … Natural language is too imprecise and gets tangled when it comes to complex concepts. Code is precise but too detailed. So I use UML when I want a certain amount of precision but I don't want to get lost in the details."
  Martin Fowler, Kendall Scott, 2000, UML Distilled: A Brief Guide to the Standard Object Modeling Language