Re: specifying design patterns using UML



Date view Thread view Subject view Author view

Dirk Riehle (riehle@inf.ethz.ch)
Thu, 4 Jan 2001 01:27:28 +0100 (MET)


> your points are well taken. formalization is not an end in itself; we need > to ask _why_ we want to make design patterns more formal. > > instead of characterizing the pattern per se, we might look for properties > of the pattern that affect its soundness. that is, rather than worrying I think we need all the help we can get :-)) I like a bottom-up property oriented approach as the harness it imposes on pattern instantiations is less strict than others I have seen. I don't object formalizing patterns in general either, as the usefulness of conformance checking, code generation, etc. are obvious to me. The only problem I see is if things are simplified to the extent that they become practically unusable. Having a template for code generation is fine, but if a pattern instance that does not conform to the template is denied pattern status just because it does not fit the template, we loose much of the power of patterns. In some sense, it would have been better if we had never invented the word pattern and stick to templates :-)) The word "pattern" sells well, though. My prediction for its use is that tools give you "patterns", meaning they provide you with one specific template for a pattern. This is already the case. Next thing will be that tool developers recognize that they need different templates for the same pattern, which are then probably called pattern variants in order not to give up the marketable name pattern. Eventually, I hope, "pattern variant" will turn into template and pattern will become again what the GOF book and others meant it to be. Dirk > about whether a pattern has been "instantiated correctly", we could ask > whether it has been implemented in a way that preserves properties that the > correct working of the pattern relies on. some examples: > > pattern: composite > property: no null fields > why: traversals don't do null checks, and will throw exn > > pattern: observer > property: no cycles in subject-observer graph > why: notify will loop forever > > pattern: flyweight > property: flyweight objects are immutable > why: pattern relies on making sharing transparent > > pattern: iterator > property: iterator modifications must preserve rep invariant of collection > why: modifications to iterator can cause collection methods to behave badly > > /daniel > > > ....-----Original Message----- > ....From: Dirk Riehle [mailto:dirk@riehle.org] > ....Sent: Tuesday, January 02, 2001 8:11 PM > ....To: puml-list@cs.york.ac.uk > ....Subject: specifying design patterns using UML > .... > .... > ....Hi, > .... > ....currently, there is no way of properly specifying design > ....patterns using > ....UML. In the collaboration specifications chapter, a > ....declaration of intent > ....exists that you should use collaboration specifications to > ....express a > ....pattern's structure, but that's about it. > .... > ....And it is not even precise. Better would be, if you used > ....templates of > ....collaboration specifications rather than specific collab. > ....specs. However, > ....the template mechanism in UML is broken too. > .... > ....Most research I've seen assumes a kind of refinement > ....relationship between a > ....pattern representation and an instantiated pattern. From a > ....practitioner's > ....point of view, I find this unsatisfying. Here is why: > .... > ....Both a formal representation of a pattern and a pattern > ....instantiation are > ....(partial) models. The relationship between these models is > ....commonly called > ...."instantiation." Mapping this on a refinement relationship > ....between an > ....abstract and more concrete model may bring these terms to > ....common ground, > ....but does not match how people use patterns. The semantics of > ...."instantiation" are more loose than those of "refinement". > ....Deliberately so, > ....since most real-world instantiations of design patterns > ....cannot formally be > ....derived from the structure diagram in the GOF book. Unless > ....you want to tell > ....developers that 90% of their pattern applications aren't pattern > ....applications, you will have to accomodate for these semantics. > .... > ....On a sidenote: I think a formally represented design > ....pattern should not be > ....called a design pattern, because it is a template that you > ....instantiate. As > ....soon as you are on formal grounds, you either have to deal > ....with the loose > ....semantics of "instantiation" (more like "adaptation") or > ....you have to > ....exclude 90% or so of all pattern uses. I think it is better > ....to leave > ....patterns unspecified and rather use a number of templates that are > ....understood as formal representations of one specific > ....pattern. (Remember: > ....the structure diagram in the GOF book is one common form of > ....the pattern, > ....but usually not the only one. For each pattern, there is an > ....infinite number > ....of such abstract forms. GOF just gave us the most well-known one.) > .... > ....Dirk > .... > .... > .... > .... > ....To remove yourself from this list please mail > ....puml-list-request@cs.york.ac.uk > ....with a message containing the word "unsubscribe". > .... > > > > To remove yourself from this list please mail puml-list-request@cs.york.ac.uk > with a message containing the word "unsubscribe". >


Date view Thread view Subject view Author view