SObre Arquitectura - Cuaderno I

LINK A LOS DOCUMENTOS MENCIONADOS EN ETSA NOTA

http://www.linkedin.com/osview/canvas?_ch_page_id=1&_ch_panel_id=1&_ch_app_id=17798120&_applicationId=1300&appParams=%7B%22subview%22%3A%22shared%22%2C%22item_type%22%3A%22folder%22%2C%22shared_name%22%3A%225xau9onhts%22%7D&_ownerId=9863329&completeUrlHash=tnNC


Estimados Colegas :

El presente cuaderno esta referido a uno de los temas en los que hemos recibido consultas o sugerencias: Que es la arquitectura en un
proyecto de software ?.-

En una época en la que jóvenes que apenas tienen un par de años programando en un lenguaje dado, se postulan como
arquitectos, surge la duda o al menos la discusión sobre que cual es esa famosa tarea que tantos postulantes tiene y
tan pocos practicantes reales reconoce.-

Hemos elegido para este envío (que se continuara bajo el mismo tópico en Enero) notas de los adherentes a los métodos
formales y para ello elegimos ingenieros del SEI (Clements, Jazayeri, Batman), tambien elegimos adherentes a los métodos
agiles y para ello seleccionamos a Scott Ambler y Allistair Cockburn y decidimos agregar algunos documentos propios
generados en nuestros proyectos. Estos últimos no como conceptos sino como implementaciones de documentos de arquitectura.-

La seleccion de los representantes de cada "escuela" se ha hecho con el mayor de los respetos, en tanto, para quien esto firma,
ambas escuelas tienen aportes de real valor.-

El cuaderno estara compuesto por 3 envios y este es el primero de ellos.-



Cuadernos del SEI.pdf
**********************

La primera de las notas es de Paul Clements, senior member del staff técnico del SEI (Software Engineering Institute).
La nota “What’s difference between architecture and design?” es un articulo corto en el que se expresan, de modo sencillo,
ideas sobre como definir elementos arquitectónicos (es decir de interés para la arquitectura del software) y elementos de
diseño (es decir de interés de quienes implementan).

La segunda nota “Architecture Paradox” es del Dr Subrahmanyam Allamaraju un reconocido ingeniero en desarrollos sobre
tecnologías J2EE. Es una reflexión sobre las dos fuerzas opuestas que enfrenta un diseño de software: Sobrevivencia y
Evolución. Entendidas como la capacidad de cumplir con el cometido para el que fue construido (Sobrevivencia) y la capacidad
de cambiar a medida que las demandas de negocio así lo requieren (Evolución).-

La tercer nota son extractos de un libro de Jazayeri y otros ("Software Architecture for Product Families").
Los primeros extractos se refieren a la elección de vistas (como cortes parciales de la realidad) para modelar y especificar
una arquitectura.-
La segunda parte, que se refiere a un Marco de conceptual para la arquitectura de software nos parece un buen ejemplo de la
idea de la que parten las Software Factories (tema al que dedicamos el primero de nuestros envíos).-
Recordamos que, en este caso, usamos este termino (Software Factories) no como el espacio físico y de procesos con el que se construye el
software, sino el entorno de desarrollo y el marco en el que se conciben aplicaciones para un dominio dado.-

AGILE ARCHITECURE MODELING-Ambler.pdf
**************************************
Este es un documento 100% Ambler. Y en cierto modo radical. Comienza con el enunciado habitual de igualdad entre todos los
participantes de un equipo de desarrollo (en contra de la cultura “gerente-proyecto-céntrica” demasiado instalada por caso
en nuestro país).-
Y continua con agudas observaciones sobre arquitectos que viven en “torres de marfil”. Es este tipo de observaciones las que
han hecho que Ambler gane fama entre los ambientes de programadores.
De todos modos nos pareció interesante el articulo no por sus primeros enunciados, algo provocativos, sino porque en el
cuerpo de la nota Ambler se extiende en una serie de PRINCIPIOS y NORMAS que un buen arquitecto debe seguir.
Son estas ideas y no las discusiones casi ideológicas las que dan fuerza a las ideas de Extreme Programming y los métodos
agiles de construcción de software y administración de proyectos.-

Agile Programming y los métodos formales son compatibles?

Entendemos que son visiones distintas y a esta altura difíciles de conciliar.-

Igual que las estrategias para ciclos de vida de proyecto, quizás lo mejor este en partes de cada mundo y la sabiduría del
arquitecto y el diseñador esta en elegir las ideas mas adecuadas que lo lleven al éxito en cada proyecto:

Patrones, si.
Dogmas, no.-

Hunting the product line architecture-Batman.pdf
***************************************************
Es un paper de Joseph Batman que es senior member del staff técnico del SEI (Software Engineering Institute).
Este documento nos parece interesante porque se enfoca en la definición de una arquitectura para una Familia de productos
de software que una empresa puede producir. (sea una empresa de software o no).-

Este enfoque con otros nombres (Por ejemplo SDL : Specific Domain Language) es un tema de discusión común cuando se trata de
implementar fabricas de software como entorno y marco de desarrollo.-
En ese sentido una arquitectura de línea de productos es una abstracción de arquitectura que se debe implementar para cada
producto.
Pero así enviamos una nota de Ambler que nos pareció prototípica de las metodologías agiles,
lo que hizo que elijamos este paper como representativo de las escuelas formales y tradicionales es la comparación que hace
Batman entre la necesidad de arquitectura de los productos de software y la organización para un despliegue militar.-

Las ideas del SEI y el Carnegie Mellon se producen (y son esencialmente financiadas) para conducir y medir los enormes
proyectos del DOD (Deparment of Defense) de Estados Unidos.
Y esto no es una observación menor, en tanto esas metodologías aplican a proyectos de gran escala , con participación de
múltiples contratistas y donde la esencia es un dado nivel de calidad (que deben cumplir todos los contratistas del DOD),
respeto a estrictas reglas de seguridad en el envio de informacion y el personal involucrado y participacion de OTROS
CONTRATISTAS certificados. Esto significa que las habituales reglas de decision de proyectos que conocemos (quiero pagar tanto
y lo necesito para tal fecha) no son las de estos casos.-

Esto no confina las ideas del SEI a los proyectos del DOD ya que otros adherentes a estos procesos son, por ejemplo
la empresa Bosch que tiene una línea de software para control del sistema de nafta de motores o Philips con su software
para televisores de bajo costo.-

Pero creemos honestamente, que es necesario entender que, no todas las practicas propuestas por los ingenieros del SEI tienen
aplicación universal y para eso precisamos siempre entender el contexto en el que una determinada idea se considera
valida.-

Con esto en mente entendemos que el documento es rico en ideas útiles para quien desee implementar arquitecturas para sus
líneas de productos de software.

LA IDEA APARECE COMO ESENCIAL PARA AQUELLAS EMPRESAS QUE NO SON PRODUCTORAS DE SOFTWARE, pero tienen en su área de sistemas
la necesidad de hacer con equipos propios o de terceros desarrollos propietarios de considerable volumen y variedad , de
considerable criticidad para el negocio pero siempre apuntados a UNA LINEA DE NEGOCIOS DETERMINADA.-

M3-Architecture Specification for the Autodesk Icon Database - v1.0.6.pdf
**************************************************************************

Por ultimo en esta primer parte (igual haremos en la Parte II de este envío) incorporamos un documento nuestro.
No para abundar en conceptos(ya que en ese terreno no seriamos una digna compañía de quienes mencionamos previamente), sino
para mostrar una implementación de esas ideas en un documento de arquitectura.

Corresponde a un trabajo que Millennium3 hizo para la firma Autodesk, fabricante entre otros productos de
AUTOCAD® .-
Este trabajo lo realizo un equipo de ingenieros de Millennium3 y participaron desde el punto de vista del control técnico
un equipo chino (China Autodesk Development Center) y un equipo estadounidense.-
En un equipo tan diverso y geográficamente disperso se necesitan artefactos de comunicación eficaces.
Nos pareció entonces una buena posibilidad adjuntar este documento, que demas esta decirlo ...no fue el unico artefacto de comunicacion !!.-

------------------------------------------
En fin, estas notas y las ideas subyacentes nos llevan al maravilloso sueño de cualquier diseñador:

“Un diseño no esta terminado cuando no hay nada mas para agregarle, sino cuando su equilibrio interno es tal , que no hay
mas nada que quitarle”.

Ojala podamos lograrlo la mayoría de las veces.-