finding design patterns from Model or P.E file

Hi,

Are there any tools or APIs that take a model (as XMI probably) or a P.E file (so in effect, source code won't be available) and give the design patterns that were used in the model ? Which classes participate in which patterns and related info ? It could probably be one of the stages in reverse engineering, isn't ?

Thank you.

[353 byte] By [raghavaa] at [2007-10-2 16:26:41]
# 1

Many GoF patterns are structurally the same code-idiom but have different interpretations (by the naming adds value - a delegate that returns a new string value, a decorator that returns a new container or an abstract factory all appear the same at the instruction level - a call delegates and a new object is returned).

Many classical application design patterns (eg ?Magnetism, Once And Once Only, Automatic Mode Changes) exist a long way above the code idioms.

It's unlikely that you will get any useful sematic patterns from reverse engineering code or uml.

Pete

pm_kirkhama at 2007-7-13 17:26:26 > top of Java-index,Other Topics,Patterns & OO Design...
# 2

Hi Pete,

Does that mean GOF patterns are not used in real world applications (thats what I inferred from what you said. Sorry if Iam wrong) ? Iam a student, so Iam not familiar with the design mechanisms used in the industry.

Anyway, I need that kind of a tool which can generate pattern information from an XMI file. Please tell me if there are any ?

Thank you.

raghavaa at 2007-7-13 17:26:26 > top of Java-index,Other Topics,Patterns & OO Design...
# 3

Originally, 'pattern' was used in the smalltalk community to describe user observable patterns, such as Undo/Redo, having a split window with selection and detail etc. It's still used that way in the usability community.

The GoF took the pattern idea and used it as a higher level coding idiom. They are used a lot in real world code, but there are different patterns (eg Composite and Decorator) that have identical implementation structures if you don't know which methods are important to the pattern, which is all a tool can see. The main value in GoF patterns is that they communicate the purpose behind the structure, adding information that isn't in the codebase. (Eg adapter is structurally a composite strategy, but not every composite strategy is an adapter).

The UML2 committee decided to use 'pattern' to describe a template library feature for UML(as did others), equivalent to Visual Studio code snippets where you fill in a few fields. If all your code is generated from a wizard, you might detect some fingerprint. But by the time you're having to use wizards to create the diagrams intended to simplify communication between humans so that machines have enough information to generate code that you later reverse engineer, something's gone wrong somewhere.

Given that the GoF patterns were originally extracted from practice, it might be interesting to use a graph matcher on a large codebase to find regions of similarity; I've looked at doing something similar to re-engineer legacy unstructured 500KLoc Fortran applications into something much smaller with subroutines. The similar subgraphs may then indicate patterns, or idioms (such as using an Iterator over a Collection), but naming the patterns is another matter.

Pete

pm_kirkhama at 2007-7-13 17:26:26 > top of Java-index,Other Topics,Patterns & OO Design...
# 4
Thanks Pete. That was nice insight into some of the things.
raghavaa at 2007-7-13 17:26:26 > top of Java-index,Other Topics,Patterns & OO Design...