Hi Arno, Excuse my delay in responding you. The question of archetypes� classification is something that I have not still worked on. The first thing that I have attempted to meditate is how to integrate software architectures into software development, using a documental format. Any how the classification of the architectures is an important topic. Developing taxonomy could be very beneficial. More than one year ago, I studied almost all PLOP and EUROPLOP papers and I began to make certain classifications depending on the technological area in which I can classify these papers. I didn't go too forward for the lack of time, but I believe is going to be necessary to approach this topic from an iterative point of view and in a multi-categorizing way. Along this process move forward the classification could improve.
Best Regards. Mois�s D. D�az --- Arno Haase <[EMAIL PROTECTED]> escribi�: > Moises, > > I agree that organizing prior art and knowledge, > especially patterns, is > an important and relevant issue. One approach that > is explored at the > pattern conferences is the organization of patterns > into pattern > languages, refactoring existing patterns based on > what is learned on the > way, and exploring sequences in which patterns are > actually applied in > real scenarios. This is being done for several > technical domains that > are relevant for architecture. > > But I do not see how a hierarchical (tree) structure > of topics could > hope to capture such a big and complex topic as > architecture, esepcially > aiming at having a single system for *all* kinds of > systems. In my > experience, there are some technical domains that > are relevant for very > many different systems (security, memory and general > resource > management, remoting, ...) but with different > trade-offs - embedded > systems have some very different forces from e.g. > web shops. And then > there is also the issue of interaction between > process and architecture. > > The hierarchical approach you suggest may work for > very high-level > descriptions of architectures, but I expect there to > be redundancy / > copy & paste when the level of detail goes beyond > powerpoint architectures. > > How do you propose to avoid this redundancy problem > that arises when you > reach a level of detail when most of the > architectural issues become > cross-cutting? And, on a more general note, what is > the primary > dimension you would suggest for the specialization > hierarchy in > architectures you suggest? > > Best regards > > - Arno > > > Mois�ffffe9s D�ffffedaz wrote: > > Hi all, > > > > On my opinion, at this moment, Software > Architectures > > are so abstract that relatively it is not very > useful > > for developers. All that a lot of people can read > > about this topic are generalities that are very > far > > from day-to-day practitioners and software > architects > > that work in software industries. > > > > Nevertheless, I think that we need architecture > for > > understanding systems, organising its development, > > > and making reuse more real. But perhaps we need an > > intermediate (and new) concept to bring software > > architecture to software development. Describing > > different software architectures is not enough. > > > > I think that this new concept must to extend > design > > patterns� success. > > This concept (that I have named �Archetypes�) is a > > form of documenting (in one document): > > Functional requirements. > > Logic architectures (layers, pipelines, etc). > > Physic architecture (real components, frameworks, > > deployment configurations, etc). > > > > The idea is develop a tree of documents related > with > > areas of software (web portals, enterprise > information > > systems). The final documents represent specific > type > > of software system, with defined logic > architecture > > and patterns, and with specific physic > architecture > > (frameworks, components, etc). Higher documents in > the > > tree will be only related to specific types of > > software systems, and logic architectures. > > > > I developed this concept in a small article (It is > not > > updated with the keyword �archetype�, I use > (badly) > > the term �pattern language�): > > http://www.moisesdaniel.com/wri/htdsalp.html . An > > example of archetype would be an article that I > wrote: > > �Enterprise Information Systems� Architecture� > > http://www.moisesdaniel.com/wri/eisarc.html. > > > > I think that identifying main architectures and > > patterns is only a part of the real objective: we > need > > methodologies that can manage in a direct way the > > architectural subject and I think that Archetypes > can > > be a bridge between Software Architectures and > > Methodologies. > > > > What I�m searching at this moment is opinions > about if > > this concept would be interesting and useful. > > > > Excuse me if all what I�m commenting is not very > > reasonable. > > > > Best Regard, > > Mois�s D. D�az > > > > > > > > > > ______________________________________________ > > Renovamos el Correo Yahoo!: �100 MB GRATIS! > > Nuevos servicios, m�s seguridad > > http://correo.yahoo.es > > > > _______________________________________________ > > patterns-discussion mailing list > > [EMAIL PROTECTED] > > > http://mail.cs.uiuc.edu/mailman/listinfo/patterns-discussion > > > > _______________________________________________ > patterns-discussion mailing list > [EMAIL PROTECTED] > http://mail.cs.uiuc.edu/mailman/listinfo/patterns-discussion > ______________________________________________ Renovamos el Correo Yahoo!: �250 MB GRATIS! Nuevos servicios, m�s seguridad http://correo.yahoo.es _______________________________________________ patterns-discussion mailing list [EMAIL PROTECTED] http://mail.cs.uiuc.edu/mailman/listinfo/patterns-discussion
