Shunxiang Yang (email@example.com)
Wed, 3 Jan 2001 13:40:17 +0800
Hi, Dirk Thank you for your great advice. Actually, I agree with you. For some patterns, the inner constraints are too hard to describe in a formal way. Maybe narratives are more appropriate for pattern descriptions. But, for CASE tool vendors, how can they provide pattern support in their tools? I mean, the maitenance of pattern lib, the auto-instantiation of Design Patterns in models, etc.? I think the way TogetherJ supports Design Patterns is just a start. There must be, or must will be some better way to support Design Pattern applications. But how? This is the problem puzzling me. Thanks again for your help! Best regards, yours, Yang Shunxiang ----- Original Message ----- From: Dirk Riehle <firstname.lastname@example.org> To: <email@example.com> Sent: Wednesday, January 03, 2001 9:10 AM 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 firstname.lastname@example.org > with a message containing the word "unsubscribe".