I'm wondering how can you make an appropriate maintenance of an asset repository. I mean, how can you determine when a pattern implementation will, and is in fact, worthy enough to store it as an asset in a repository?
Thanks in advance for your answer.
"Software development has been, is, and will remain fundamentally hard"
- Grady Booch
The fact that you decided to invest on creating the pattern implementation suggests that it was valuable. If it was valuable on your context why not publish it and make it available to others so they can also benefit from it?
The role of the repository is to make the pattern (implementation or specification) easily accessible to others.
One of the main roadblock in the spreading of patterns is not the lack of available patterns but the fact that it is difficult to find the right pattern when we need it. The role of the repository is to mitigate this problem by providing a central way to search for patterns. I want also point here that the patterns metadata is also important. What I mean by that is that the classification or the cataloging categories you use to organize your patterns is also important in making them easily to find.
I've been working with Grady Booch on his software architecture handbook (http://www.handbookofsoftwarearchitecture.com) to create a catalog of patterns and more importantly to tag using a categorization that we hope would help people to easily find the right pattern to solve their problem.
I have to say that I found interesting the fact of categorizing the patterns using some kind of metadata, are you and Grady Booch proposing a new way to catalog patterns (and I'm guessing that you and Lee are following the same approach/convention in PBE book)? I'd like to point you to a good framework for this purpose, this is JPatterns http://www.jpatterns.org/, an effort from Heinz Kabutz, are you guys proposing something like this?
Thanks for this annoying questions
Joined: Nov 01, 2010
Thanks for the pointer Victor, I did not know about jpatterns. From what I seen it is more a java annotation meta-language to document pattern use in your code.
The categorization I've worked on with Grady was more to organize pattern specification and make the pattern easier to find. One of the aspect of the patterns we tag for example is the level of abstraction. So if you search for an architecture pattern or a design pattern it would be easier for you to retrieve the subset of patterns that could interest you. Another aspect is the technology, like Java or .Net so if you search for .Net specific patterns it is easier to retrieve the corresponding subset. And of course you can combine them to get all the .Net architectural patterns, for example.
As every reusable asset its value is not in its creation but in its reuse. I firmly believe that we need to get better at reusing existing patterns. And I thing an efficient categorization is on parameter in making that reuse easier by helping the users find the pattern(s) to solve their problem in a minimum of time.
Great stuff you guys have in there (PBE book and software architecture handbook). Certainly to me now is not the amount of patterns I know (which are something like 15 or less :$), instead I believe that one problem on spreading the patterns word is the huge amount of them and the hard way to get the that will fit in our needs. In my experience, I always got one of those patterns I know and fit it into the solution, no matter if that's not the best pattern for it, and obviously I never have done a pattern-based asset repository, so I'm always creating that infrastructure from scratch (really a bad way now that you guys let us know that term).
I'm really hoping to read your book ASAP, I'm pretty sure I'll learn a lot from you guys, Thanks for this gift to the community
subject: Creation of a patterns-based asset repository