Executable Uml: How to Build Class Models

• Authors: Leon Starr;Stephen J. Mellor
• Venue: Executable Uml: How to Build Class Models
• Year: 2001

From the Book:Author's prefaceThis book is a collection of models, modeling tips and analysis techniques that have worked for me (and my colleagues) on real projects.It conveys the experience that I have gained in 15 years of buildingexecutable object-oriented models. I have written this book for especially for those of you who have already had an introduction to anexecutable, translation-driven modeling method such as ExecutableUML or the Shlaer-Mellor method. I presume that you are eitherabout to start applying Executable UML on your project or that youhave been building executable models for a year or two. This text isgeared toward those of you who do the hard work of boiling downapplication requirements, formalizing these requirements into fullydetailed models, and getting those models translated into workingsoftware.This book is not a complete statement or grammar of the Executable UML language. For that please see Steve Mellor's text listed inthe "Where to learn more" section at the back of thebook. Instead, I show you some of the ways that I use important features of the object modeling language. I also provide some guidancein how to deal with a few thorny issues.Experience on multiple projects has taught me many things. One ofthe most important lessons is that you can't skimp on the class models and get away with it. You must ensure that your applicationrequirements are thoroughly captured, in great detail, in your classmodels. This takes time and hard work. Whenever my colleaguesand I have cut corners we have run afoul of the following consequences: (1) the state charts become ridiculously complex; (2) oneor two critical requirements lie hidden untillate in the modelingprocess, leading to time-consuming rework; and (3) new requirements that should have been anticipated arise late in the modelingprocess and wreak havoc. On the other hand, a good class modelleads to stable state models and simple threads of control. This bookfocuses on the key to success: building quality class models.Like most of us, coming originally from a function-oriented programming background, learning to build class models has been challenging to say the least. I've noticed that engineers new to object-oriented analysis grapple with many of the same questions that Idid: What model structures are legal? (Can I do that with a generalization relationship?) How much detail should go into the classmodel? How do I build a model that won't fall apart when therequirements change? What's the difference between a good classmodel and a bad class model? Why do I need to write modeldescriptions? What's the best way to express an association involvinga specific number of instances (not 0, 1 or *). What's the best way tomodel a hierarchy of things? This book contains answers to thesequestions and many others.Another big key to success is to use your time effectively. A commonmistake is to spend too much time modeling and not enough timedoing analysis. Few software engineers appreciate the value of distinguishing the activities of analysis and modeling. I don't know howmany times I've seen a novice analyst spend hours building the perfect model to suit a set of perceived requirements. Later on therequirements change, or they turn out to be the wrong requirements, or they turn out to be based on some aspect of the systemthat is so volatile that no attempt to nail down the requirements canbe successful. As a consequence the whole model unravels. I wrotePart 2 of this book to show how this kind of disaster can be avoided.To become a good programmer, not only do you need to write a lotof code, but you also need to look at code written by other people.The same is true when it comes to analysis and modeling. Themodels in this book will give you something helpful to look at fromtime to time as you build lots of models. Have fun.Leon StarrSan Francisco, California