In den vorherigen beiden Kapiteln wurde gezeigt, wie man ein Klassendiagramm, das eventuell mit Zustandsdiagrammen und OCL-Constraints ergänzt wird, in Programmcode umsetzen kann. Bereits am Anfang des Kapitels  5 wurde erwähnt, dass das erreichte Analyseklassenmodell sich nur sehr bedingt für eine direkte Umsetzung eignet, gerade wenn es von unerfahrenen Modellierern erstellt wurde. Generell wird nach einem Klassenmodell gesucht, das möglichst alle drei der folgenden Eigenschaften vereint und durch Design Pattern ermöglicht wird Zunächst soll das Klassenmodell leicht änderbar sein. Kleine Änderungen sollen nicht dazu führen, dass man viele Klassenimplementierungen ändern muss. Weiterhin soll das Klassenmodell leicht erweiterbar sein. Neue Klassen, gerade Klassen, die Ähnlichkeiten zu existierenden Klassen haben, sollen leicht in das bisherige Klassengefüge eingebaut werden können. Dazu muss unter anderem die Lesbarkeit des Klassenmodells auch für Entwickler gewährleistet sein, die nicht an der Entwicklung beteiligt waren. Zu guter Letzt soll das Klassenmodell modulare Strukturen ermöglichen. Es soll Klassen ergeben, die eng zusammenarbeiten und nur möglichst einfache Verbindungen zu anderen Klassen haben.