Bookmark Topic Watch Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
  • Mikalai Zaikin
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Report post to moderator
This is the FAQ page for the OO, Patterns, UML and Refactoring forum. Like all other page in this wiki, the page is editable by anyone, so don't hesitate to add useful information.


  • SingletonPattern
  • Design Books, UML References
  • Design
  • Design Patterns
  • Refactoring
  • UML
  • UML Tools
  • Use Cases
  • ORM

  • UmlCertifications

  • Design Books, UML References 

    The book title is linked to the publisher where sample content may reside. The ISBN links to Amazon US which tends to list reviews.

    Agile Software Development: Principles, Patterns, and Practices (2002) ISBN 0135974445  Bunkhouse Review
    A favorite with forum regulars probably because of its balance. Enough code examples to have you working along but not so much that you will be missing the forest for the trees. UML is only used to model the "interesting bits" and where the code clutter may get in the way of clarity. Primary focus is on object-oriented design principles; patterns come in second - emerging from the OO design principles. An evolution of the author's "Designing Object-Oriented C++ Applications Using the Booch Method" ISBN 0132038374. (See Articles By Robert C. Martin). Received an update as APPP in C#.

    UML Distilled: A Brief Guide to the Standard Object Modeling Language, 3e (2003) ISBN 0321193687  Bunkhouse Review (1e)
    Fowler distinguishes between three modes of UML : 1. as a sketch a blueprint 3. as a programming language . Usage as a blueprint tends to be unproductive and usage as a programming language tends to be ineffective, so this title focuses on "UML as a sketch". If you have some serious UML laywering to do then you need to go with the UML Reference Manual.

    Refactoring: Improving the Design of Existing Code (1999) ISBN 0201485672  web page Bunkhouse Review

    Working Effectively with Legacy Code (2004) ISBN 0131177052  Bunkhouse Review
    "To me, legacy code is simply code without (automated) tests." So you've realized that refactoring is useful and essential - however it requires that you have unit tests for the system that you are working on (unless you like working without a safety net). Michael Feathers describes how to approach this problem. Sample code is in Java and C++. Great companion to Refactoring.

    Design Patterns: Elements of Reusable Object-Oriented Software (1994) ISBN 0201633612  Bunkhouse Review
    The original Gang of Four (GoF - Erich Gamma, Richard Helm, Ralph Johnson, John Vilissides) design patterns book. Code examples are in C++ and diagrams are pre-UML (close enough though). If this is you first foray into design patterns then you may want to start with Head First Design Patterns. To those familiar with design patterns this remains the core design patterns reference. Also available in HTML as the Design Patterns CD ISBN 0201634988.

    Patterns of Enterprise Application Architecture (2002) ISBN 0321127420  web page Bunkhouse Review
    PoEAA (PEAA)

    Domain Driven Design -- Tackling Complexity in the Heart of Software (2003) ISBN 0321125215  web page
    Your application has finally gotten complex enough to invest the effort into a Domain Model. Do changes to your application always seem to run orthogonal to your current object model? To solve these problems you will have to sit down with your domain experts and formulate a ubiquitous language that forms the base for your new domain object model and will be used for communication among the team and the clients. Then you can move on and create the requisite Entities, Value Objects, Services and Repositories which your software solution will be based on. Eric Evans presents the ideas and concepts that are necessary to create an effective domain model and how to maintain it even in the face of less than perfect collaborating systems. Applying DDD gives a more hands on view (if you don't mind a .NET implementation). The minibook Domain Driven Design Quickly is offered by InfoQ.

    Writing Effective Use Cases (2000) ISBN 0201702258  web page

    Design Patterns Explained: A New Perspective on Object-Oriented Design, 2e (2004) ISBN 0321247140 
    The title of this book needs to be reversed. It's primarily about object-oriented design and shows how design patterns emerge from the systematic application of object-oriented design principles. As far as design patterns go it only discusses the Façade, Adapter, Strategy, Bridge, Abstract Factory, Decorator, Observer, Template Method, Singleton, Object Pool, and Factory Method patterns but in the context of object-oriented design principles. Also notewothy is the inclusion of commonality-variability analysis (from James O. Coplien's Thesis) and the "Analysis Matrix". (Rebecca Wirfs-Brock: Alan Shalloway's Hat Trick)

    Object Design: Roles, Responsibilities, and Collaborations (2002) ISBN 0201379430 

    Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, 3e (2004) ISBN 0131489062  web page Bunkhouse Review 2e
    The third edition departs from its more Big Design Up Front roots and focuses on iterative development; however there still is more documentation being generated here than most Agilists would be comfortable with. Notwithstanding it is a good introduction on OOAD with UML and patterns, though it focuses much more heavily on the non-code/non-executable artifacts (and communication) than APPP does. The quick references printed on the endpapers are extremely useful when you are UML diagramming/sketching.

    Head First Design Patterns (2004) ISBN 0596007124  web page Bunkhouse Review
    Popular with the Head First crowd. Great for learning about design patterns. The GoF book is still widely used as the core design patterns reference.

    Head First Object-Oriented Analysis and Design (2006) ISBN 0596008678  web page
    Popular with the Head First crowd.

    Refactoring To Patterns (2004) ISBN 0321213351  web page Bunkhouse Review

    Refactoring Databases: Evolutionary Database Design (2006) ISBN 0321293533  web page

    Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions (2003) ISBN 0321200683  web page Bunkhouse Review

    Effective Java: Programming Language Guide (2001) ISBN 0201310058  Bunkhouse Review
    Itemizes and explains 57 ways to improve your Java code.

    AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis (1998) ISBN 0471197130  web page Bunkhouse Review

    Core J2EE Patterns: Best Practices and Design Strategies, 2e (2003) ISBN 0131422464  web page Blueprints Bunkhouse Review
    Patterns to deal with problems typical of distributed component architectures and more importantly the idiosyncrasies of J2EE.

    J2EE AntiPatterns (2003) ISBN 0131422464  Bunkhouse Review
    When working in a distributed component architecture it is important to remember the First Law of Distributed Object Design: Don't distribute your objects (PoEAA p.89). This book explores all the other sins that are so easily committed on the J2EE platform. Good companion to Core J2EE Patterns.

    The Unified Modeling Language Reference Manual, 2e (2004) ISBN 0321245628 
    If you need to explore some of the dustier corners of UML this is the source to go to. Just don't expect to learn UML from it. Also comes with a handy book-on-CD PDF. For your 20% that you use 80% of the time stick with UML Distilled.

    UML for Java™ Programmers (2003) ISBN 0131428489 

    Agile Principles, Patterns, and Practices in C# (2006) ISBN 0131857258 
    An update to APPP entirely in C# (no Java); also incorporates some of the material from UML for Java™ Programmers (in C#, of course).

    Applying Domain-Driven Design and Patterns: With Examples in C# and .NET (2006) ISBN 0321268202 

    Object-Oriented Reengineering Patterns (2002) ISBN 1558606394  web page

    Object-Oriented Design Heuristics (1996) ISBN 020163385X 
    A collection of OO design heuristics that was already collected in the age of C++. Published shortly after the GoF book.

    Information Modeling and Relational Databases: from Conceptual Analysis To Logical Design (2001) ISBN 1558606726  Home
    There is a newer edition of this book (2008):
    The book on Object Role Modeling. Can be a bit frustrating as some terms are used before they are defined and are nowhere to be found in the glossary. See ORM.



  • Introduction to Object-Orientation and the UML (Scott Ambler)
  • Object-Oriented Design Principles (Object Mentor , But Uncle Bob ; Robert C. Martin)
  • What Is Software Design? (Jack W. Reeves)
  • Is Design Dead? (Martin Fowler)
  • Handbook of Software Architecture (Grady Booch)
  • Naked Objects - A critical look at object-orientation (Richard Pawson/Robert Matthews)
  • Tons of resources on Design going back over 30 years now, and still actively being updated and added to!(Rebecca Wirfs-Bock)
  • Why extends is evil (Allen Holub)
  • Why getter and setter methods are evil (Allen Holub)
  • More on getter and setters (Allen Holub)

  • Object Relational Impedance Mismatch (Scott Ambler) The entity relationship model and the domain object model serve two different masters...
  • Mapping Objects to Relational Databases: O/R Mapping In Detail (Scott Ambler) ... so it's a bad idea to try to generate one from the other. Map with intent.

  • A Laboratory For Teaching Object-Oriented Thinking (Kent Beck/Ward Cunningham) CRC cards (Class, Responsibility, Collaboration)
  • Using CRC cards (Alistair Cockburn)
  • Class Responsibility Collaborator (CRC) Models (Scott Ambler)

  • OoDesignFaq

    Design Patterns 

    Before diving into design patterns make sure that you know and understand the Object-Oriented Design Principles. Always Apply Patterns Gently. Realize that you may be experiencing Gregg Irwin's ten stages of design pattern adoption:

  • You use it without being aware that you're using it
  • You hear about it, read up on it, and tinker a bit
  • You learn more and start using it explicitly, if naïvely
  • You get the fire and evangelize (optional)
  • Something "clicks"
  • You learn more and apply it "less naïvely" and more implicitly
  • Time passes and you see flaws
  • You question the concept (often because you misapplied it)
  • You either forget about it or add knowledge and experience (Repeat steps 5--9 as necessary)
  • You use it without being aware that you're using it

  • From: A Head Start on Domain-Driven Design Patterns
    Design patterns make communication more effective. Using design pattern monikers prevents getting bogged down in the discussion of minutiae, provided all parties are equally versed in the design patterns referenced.
    We allow inner complexity of language because it enables us to shift that complexity away from the individual utterance.
    (p. xlv, The Ruby Way, 2e ISBN 0672328844).

  • Evil Design Patterns (Paul Wheaton)
  • Patterns Library

  • Specification Pattern (Martin Fowler/Eric Evans) And you thought that you needed a rules engine!

  • WhenToApplyDesignPatterns


  • Book: Refactoring: Improving the Design of Existing Code
  • Refactoring Home Page
  • Bad Smells In Code
  • Book: Refactoring Databases: Evolutionary Database Design

  • UML 

  • Introduction to the Diagrams of UML 2.0 (Scott Ambler)
  • A Quick Introduction to UML Sequence Diagrams (Yanic Inghelbrecht)
  • UML: The Positive Spin (Satire; Bertrand Meyer)
  • GoodBooksOnUml

  • AssociationVsAggregationVsComposition

    UML Tools 

    If you are using UML as a sketch then most simple UML tools will do. If you want to generate code from UML - well, you may want to reconsider. It is probably going to take longer than to simply code the thing. All of the excruciating detail that you have to supply will only serve to obfuscate your essential design.
    Model-Driven Development: One Curmudgeon's View - Why won't the general purpose language be graphical?
    It was simply faster to write code: Computers don't do big picture.
    If you are trying to reverse engineer a blueprint from existing code then be prepared to toss the generated artifact after you have developed an initial understanding of the system. It will usually take intervention from a human being to re-organize and re-interpret the diagrams, to strip away the trivial to only leave the essential, in order to attain any degree of clarity. Usually simpler is better. For example the built-in UML capability of Visio Studio Professional 2002 bogs you down with pointless micro-management of the entire model. With Pavel Hruby's "Visio Stencil and Templates" you can simply focus on what needs to be communicated.

  • Wikipedia: List of UML tools
  • ArgoUML
  • JUDE
  • StarUML
  • Trace Modeler an easy-to-use and smart editor for UML Sequence Diagrams
  • Pavel Hruby's Visio Stencil and Template for UML 2.0
  • Visual Paradigm for UML

  • Use Cases 

    Primers on text-based use cases by Alistair Cockburn:

  • Book: Writing Effective Use Cases
  • Use case fundamentals
  • Structuring use cases with goals

  • UML for Java™ Programmers Chapter 5: Use Cases :
    Use Cases Diagrams Of all the diagrams in UML, use case diagrams are the most confusing, and the least useful. With the exception of the System Boundary Diagram, which I’ll describe in a minute, I recommend that you avoid them entirely. ... Use Case Relationships Use case relationships fall into the category of things that “seemed like a good idea at the
    time”. I suggest that you actively ignore them. They’ll add no value to your use cases, or to your understanding of the system, and they will be the source of many never ending debates about whether or not to use «extends» or «generalization».

  • Use Cases (pdf) (Robert C. Martin)
  • Use Case Reuse (Scott Ambler)

  • ORM 

    Not Object Relational Mapping but Object Role Modeling. In fact the Object in ORM has little to do with the Object from object-orientation. ORM consists of a 7 step Conceptual Schema Design Procedure (CSDP) which leads to a logical model that can then be algorithmically transformed into a design described by an entity relationship or UML diagram. The CSDP hasn't really caught on. However Joe Celko made an interesting observation in his book Data & Databases: Concepts in Practice ISBN 1558604324 p.23:
    The main proponent of ORM is Terry Halpin, and I recommend getting his book for details of the method. What I do not recommend is using the diagrams in his method. In addition to diagrams, his method includes the use of simplified English sentences to express relationships. These formal sentences can then be processed and used to generate schemas in a mechanical way. Most of the sentences are structured as subject-verb-object, but the important thing is that the objects are assigned are role in the sentence. For example, the fact that "Joe Celko wrote Data and Databases for Morgan Kaufman Publishers" can be amended to read 'AUTHOR: Joe Celko wrote BOOK: 'Data and Databases' for PUBLISHER: Morgan Kaufman," which gives us a higher level, more abstract sentence...with the implication that there are many authors, books and publishers involved. Broadly speaking, objects and entities become the subjects and objects of the sentences, relationships become verbs, and the constraints become prepositional phrases.

    In essence the first step of the CSDP can be used as a valuable method during the initial stages of data design even if you don't go with the full-blown CSDP. This step is described in the sample chapter of Halpin's book. Also users tend to be more comfortable with these word based designs - they don't require them to learn yet another notation (Technical diagrams (ORM, ER, UML) don't make much sense to non-technical domain experts).

  • Book: Information Modeling and Relational Databases: from Conceptual Analysis To Logical Design
  • Sample Chapter: 3 Conceptual Modeling: First Steps
  • Publishers page with the link to the sample chapter
  • Object Role Modeling: An Overview (Terry Halpin)
  • Object Role Model (ORM) Diagrams (Scott Ambler)
  • ORM site

  • CategoryFaq CategoryUml
      Bookmark Topic Watch Topic
    • New Topic