General talk about software patterns

[Moisÿffffe9s Dÿffffedaz <mddtoledano AT yahoo.es>]

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 
<Arno.Haase AT haase-consulting.com>
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
> > patterns-discussion AT cs.uiuc.edu
> >
>
http://mail.cs.uiuc.edu/mailman/listinfo/patterns-discussion
> > 
> 
> _______________________________________________
> patterns-discussion mailing list
> patterns-discussion AT cs.uiuc.edu
>
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