RE: specifying design patterns using UML



Date view Thread view Subject view Author view

Daniel Jackson (dnj@lcs.mit.edu)
Wed, 3 Jan 2001 09:02:21 -0500


dirk, 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 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". ....


Date view Thread view Subject view Author view