Date: Fri, 26 Dec 1997 10:24:18 -0600 From: "Robert C. Martin" Subject: RE: (OTUG) UML and Relational Database On Saturday, December 20, 1997 1:24 PM, Michael Feathers [SMTP:feathers@icanect.net] wrote: > > > ---------- > > From: Robert C. Martin > > > >The problem is that OO is a behavioral paradigm, and databases are a data > >paradigm. We use OO to help us design applications. We use data modeling > > >techniques to help us design databases. The goals and constraints of the > two > >paradigms are very different. > > The above text was in one message of yours and I was about to reply and > say something about the commonality of the two appraoches. Luckily, I > held off and read your next reply which has the following text: > > > You can use UML to draw Entity-Relationship diagrams that can fully > document an > > RDB. The entities can > > be drawn as classes with the stereotype <> and the relationships > can be > > drawn as binary are n-ary associations. > > This points out that there is an underlying foundation which unites the > data and > behavioral orientations and any separation is a matter of perception rather > than fact. I don't think so. It is true that you can use UML notation to describe either data or behavior, but you use very different parts of UML for each. This does not indicate that data and behavior orientations are united. Indeed, they are diametrically opposed from one another. In a data orientation we expose the structure and details of the data and omit behavior altogether. In behavior orientation we describe the structure of the behavior and hide the structure and details of the data. **We are looking for good engineers. Check our **website for more information. Robert C. Martin | Design Consulting | Training courses offered: Object Mentor | rmartin@oma.com | Object Oriented Design 14619 N Somerset Cr | Tel: (800) 338-6716 | C++ Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com "One of the great commandments of science is: 'Mistrust arguments from authority.'" -- Carl Sagan > On Friday, December 19, 1997 8:43 AM, Paul D. Thompson [SMTP:pdt@pdth.com] > wrote: > > > > I'm interested in finding out about a related issue: why doesn't UML seem > > to support the mapping of a class model to a (relational) logical database > > design? > > Class models are, in a sense, database designs. This is only true in the very specific, instance when you are using classes to describe data. However, it is more often the case that we use classes to partition behavior, in which case class models are not database designs at all. These two ways to use classes are very different from each other. The first case I call "representational". The classes that form a representation model are typically poor in behavior, (i.e. they have few meaninful methods) but rich in data. Either the data is made public, or there are accessors and mutators for all the fields. It is the purpose of such classes to represent data. If they are integrated into an OO database with many applications using them, then they will become even poorer in behavior since each application will not want to be polluted with behaviors that are specific to other applications. Inheritance is common, but is typically associated with downcasts and typecasts in the application code. The type of a representational object can be viewed as an attribute that can be querried; rather like a discriminated union. The second case I call "OO". In that case, the classes represent a partitioning of behavior. Data is hidden, and may be implemented in many different ways. Accessors and Mutators are relatively rare. Abstraction and polymorphism are common. Downcasting and typecasting are extremely infrequent. The type of an OO object is normally hidden; nothing at all like a discriminated union. If such classes are reused, they are resused for their behavior, not their data. The representational case has very little to do with the precepts of OO. Indeed, it is nearly identical to ER modeling with discriminated unions. It is something of an accident that the same notation can be employed for both cases. Indeed, only *parts* of the notations can be shared. **We are looking for good engineers. Check our **website for more information. Robert C. Martin | Design Consulting | Training courses offered: Object Mentor | rmartin@oma.com | Object Oriented Design 14619 N Somerset Cr | Tel: (800) 338-6716 | C++ Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com - ---------- > From: Robert C. Martin > To: 'Michael Feathers' ; 'Yousef Syed' ; otug@Rational.Com > > This points out that there is an underlying foundation which unites the > > data and behavioral orientations and any separation is a matter > > of perception rather than fact. > > I don't think so. It is true that you can use UML notation to > describe either data or behavior, but you use very different parts > of UML for each. This does not indicate that data and behavior > orientations are united. Indeed, they are diametrically opposed > from one another. Wow. It is just the day after Christmas and this cuts to the core of OO. Anyway, I would agree with you in terms of the way that people graft OO and relational today for practical reasons but not in the sense that I was using the terms, that objects of our conceptualization (be they software or non-software) can be described with data and exhibit behavior. Data and behavior are like matter and energy, pretty much convertible but it takes work; even in LISP ;-). That said, prior to any optimization in a design, there should be some conceptual entities that can be referred to by name, which both exhibit behavior and have state that must persist. This is the common area. If things must diverge for optimization, so be it, but from an analysis perspective both data and behavior are features of objects. The line between them can be as slippery as a designer is creative. Here is a paper by Desmond D'Souza which deals with precisely with this issue. Behavior Driven vs. Data Driven: A Non-Issue? http://www.iconcomp.com/papers/data-vs-behavior/index.html Here is an interview with James Rumbaugh where he talks about how OMT builds on ER (which transitively applies to UML). The points about associations and database design with OMT are particularly interesting: http://www.sigs.com/publications/docs/oc/9602/oc9602.d.rumbaugh.html