Date On Uml

Basic Concepts in UML: A Request for Clarification Part II: The UML Book by C. J. Date (http://www.dbdebunk.com/page/page/622916.htm) .

C.J. Date is not the only man on this planet who thinks UML is largely bogus. Its only high quality is that it fits nice in my resume.

Agreed. UML is largely bogus - see DiagrammaticAlternativesToUml.

The essence of Date's article, if you go behind the style, is that UML - as a pretended modelling language for objects or for OO or whatever - is supposed to have an object model. Well, it doesn't have one (or at least the 8MB pdf file that I have here doesn't have it). How do you expect someone to make a logical argument about a theory that lacks any internal consistency? Date is merely pointing out some contradiction and ill-defined notions, he is not responsible for the fact that he didn't first learn Java so that he could figure out what the pretended definitions are trying to refer to.

To demonstrate that Date's arguments are bogus, you should try to go through the hundreds of meaningless pages of the standard, and point out that the UML authors actually managed to consistently define basic notions such as Object, Class, Instance, Interface, Method, Operation, Association Class, Link and other fancy things, and there's no redundancy and each of these notion is meaningful and necessary. Good luck. I happen to agree with Date, even if not always with his style .

I think I'll dust off my copy of Date's book. I'll be looking specifically for some circular definitions of relations, tuples, domains which Date regards as 'mathematical rigour', IIRC.

Let's see. According to Date's An Introduction To Database Systems Volume I, Fifth Edition "we define a domain to be a named set of scalar values, all of the same type", but later "a domain is nothing more nor less than a data type".

"... a relation consists of two parts, a heading and a body ... The heading consists of a fixed set of attributes, or more precisely attribute-domain pairs ... The body consists of a time-varying set of tuples ..." So the set of tuples varies over time but the set of attributes is fixed, presumably over time. Or is it? DrCodd's 4th rule states that a relational DBMS must have an "Active online catalog based on the relational model". This would be able to change the headings of the relation.

On to the Request for Clarification. The UMLauts define "Class: A description of a set of objects that share the same attributes, operations, relationships and semantics." They didn't make the mistake of calling a class a set of objects - Date did. A class is a description, or in Date's words a "heading". A class is not a set of objects for the same reason a heading is not a body.

But it it most interesting that Date understands the principles of OO all too well. Given that his book was published in 1990 he is hereby excused for not learning Java. Considering his OO definitions precede the UML books' by nine years and exceed them in quality by several orders of magnitude he certainly is impeccably qualified to critique UML in whatever fashion he damn well pleases, including using ConversationalChaff. And while some would find his feigned ignorance screamingly funny, I would have to say Date, KillYourDarlings. -- MattRickard

Well I can hardly see any contradiction.

A type IS A set of values, at least in the database field and in the type theory field, as for OO languages of wide acceptance a type can be anything at all (except for ADA 95 maybe).

The catalog is active in the sense that it always reflects the state of metadata in the database. It cannot be updated in the same sense that you update a base table, it is only updated indirectly by DDL statements (CREATE TABLE, ALTER TABLE ...). While you can alter a table, that doesn't mean you changed the relation. A table is a Relation variable - a variable whose value is a relation (or at least theoretically, in practice table values can be bags of tuples, see DuplicatesAreBad). When you do alter a table you alter the variable (identified by its table name to the database) including the relation type and possibly reorganizing existing values so that they will fit into the new relation type.

It may be possible that Date's work is not perfect, and he corrected several things over the time according to his own words, but I don't think his degree of imperfection is that big.

But it it most interesting that Date understands the principles of OO all too well.

Well, that's the most untrue statement you can make. Not only that Date is not fond of OO , but even people that are fond of OO (including me and many others) don't understand nor even recognize the said OO principles. The said principles either do not exist, or they are not widely recognized and applied, or they are subject to dispute, or they are only empirical assertions. See LiskovSubstitutionPrinciple as one of the all too many examples that we haven't settled our OO theory. And the little OO theory we do have is not applied in OO languages of today. And UML is the most messed up thing OO ever produced.

I wonder whether this page really has a reason of being. If somebdoy has any doubts that UML sucks, I really recommend the link I posted on ModernDinosaur which is written by an OO insider.

Date's can be suspected of bias (after all he's a database researcher and he's admittedly not very fond of OO). I doubt though that somebody can disprove his points on UML. But UML is such a mess (in my opinion and many other's opinion)that I wonder if scoring points aginst it is worth anybody's time (including Mr. Date's ).

I think Date and others are actually fond of some of OO, but they are not fond of the confusion in OO. OO is lacking precise terminology and sound theory behind it and this is what Date and others dislike about OO. Date and other database researchers appreciate OO and even try to incorporate OO into their types in the third manifesto. If they were not fond of OO, they wouldn't try to merge OO with databases in TheThirdManifesto. They dislike the fact that OO has no sound math basis and no sound (precise) terminology/theory behind it. They don't like the fact that classes and objects have no precise meaning (people often confuse instances with classes, confuse objects with classes (what's the difference?), confuse types with objects, etc). The problem is that OO offers too much confusion and not enough precision. People are largely confused about OO because OO is confusing. Relational theory and math tend to be very precise, whereas OO is confusing and non precise. Unfortunately, Date and Darwen make the mistake of thinking that classes = types. This is similar to thinking that structs in Cee equal types. Structs are not equal to types - that is a logical error. Structs are a kind of type, structs do not equal types.

{You have, it appears, misunderstood the FirstGreatBlunder.}

I think it's a mistake to believe that Date doesn't know or understand OO, and even that he dislike it. After all he introduced type inheritance in his updated relational model in TheThirdManifesto (2nd edition). You can say that type inheritance isn't all of OO, but his common critic of OO is the lack of a consistent definition.

If I am interpreting this right, then you are stating that Date believes that OO lacks a consistent definition, and if UML depends on OO, then it is also too inconsistent to be useful.

I think it is clear from his articles that UML's version (and other version as well) of OO is messy and lacks the necessary rigor to be integrated in a sound/formal system. That's why he came with his version of OO (it is unclear though whether his version is any more usable).