Simon brown ha publicado un articulo con el que estoy muy de acuerdo; se trata del por qué es bueno documentar la arquitectura del software, ya que los comentarios en el código fuente no nos ayudan a entender del todo como funciona el sistema.
Una lectura ampliamente recomendable.
Link: Coding The Architecture
97 things es un proyecto que busca reunir 97 cosas que un arquitecto debe saber.
La idea de esta lista es reunir experiencias publicadas por diferentes arquitectos, si logras hacer que publiquen un contenido tuyo te conviertes en autor. Al final O’reilly publicará un libro con los 97 axiomas que un arquitecto debe conocer.
Hasta el momento llevan 82 y siguen subiendo.
(Via)
Es un modelo de arquitectura de software, algo similar al modelo-vista-controlador (MVC). PAC se utiliza como una estructura jerárquica de los agentes, cada uno de ellos consistente en una tríada de presentación, la abstracción y el control de partes. Los agentes (o tríadas) se comunican entre sí sólo a través del control de parte de cada tríada. También difiere de MVC en que dentro de cada tríada, se aísla por completo la presentación (vista en MVC) y la abstracción (modelo en MVC), Este ofrece separar el modelo y la vista, lo cuál, da al usuario una experiencia de usuario por los cortos periodos, de cómo la interfaz (presentación) puede ser mostrada antes que la abstracción este completamente inicializada.
El control es algo similar al Controlador en la arquitectura MVC. Este procesa eventos externos y actualiza el modelo. También se actualiza directamente la parte de presentación. Sin embargo, es diferente del controlador en MVC en la medida en que éste pasa los cambios que se están realizando a su componente padre.
La Abstracción contiene los datos, al igual que en MVC. Sin embargo, puede ser sólo una parte de la estructura de datos completa de la aplicación, y no desempeñar un papel activo en la notificación de cambios.
La presentación es exactamente igual que la vista en el MVC. Muestra la información desde la abstracción.
Como funciona
El control padre crea los elementos de su hijo PAC, ya sea en el arranque del programa, o dinámicamente en tiempo de ejecución.
Cuando el control de un PAC recibe un evento de usuario (1), este debe actualizar su presentación (2a) y/o su abstracción (2b). A continuación, se envía un evento de cambio a su padre (3). El padre actualiza sus hijos (pero no al nodo donde surgió el cambio) (5), por lo que todos actualizan su Presentación (6a) y/o abstracción (6b). Después que los nodos han sido actualizados, el padre se actualiza (7). Esto termina cuando todos los elementos PAC necesarios han sido actualizados.
Los hijos y padres pueden enviar eventos muy concretos para actualizar a sus vecinos. De esta forma, los elementos PAC podrán decidir la extensión del efecto del cambio. Pequeños cambios no tienen por qué ser propagados a través de toda la jerarquía.
Problemas
Las actuales herramientas de programación visual tienen algo relacionado con esta arquitectura, pero tienen todo tipo de peculiaridades y excepciones. Así que se puede tratar de reconocer la arquitectura en herramientas visuales, pero no son tan exactos. Además, la mayoría de herramientas dicen basarse en la arquitectura MVC, lo que tampoco es completamente cierto.
Técnicas de implementación
El Control es modelado por el patrón de diseño Mediator.
La presentación es modelada por el patrón de diseño Strategy.
Hacia una definición de la arquitectura
La arquitectura ayuda a completar los requisitos
Por supuesto, hay numerosos aspectos de desarrollo de software que contribuyen a que los requisitos se cumplan. La arquitectura ofrece la estructura para el desarrollo, mejorar el control, por lo que el proyecto puede ser entregado con una mayor seguridad. La arquitectura se basa también en mejores prácticas de la industria y crea un plan de aplicación para reducir el riesgo y el costo inherente del proyecto.
Como un sustantivo, el diseño es la llamada (aunque no siempre se puede) estructura o comportamiento de un sistema cuya presencia se resuelve o contribuye a la resolución de una fuerza o fuerzas en el sistema. Un diseño por lo tanto, representa un punto en un potencial espacio de decisión. Un diseño puede ser singular (lo que representa una hoja de decisión) o puede ser colectiva (lo que representa un conjunto de otras decisiones). [Grady Booch]
En primer lugar, existe el diseño para resolver una fuerza en el sistema. Fuerzas pueden ser el costo, el alcance, recursos, plazos, requisitos – cualquier cosa que usted desee tomar en consideración como parte del diseño. Es decir, que el diseño debe tener un propósito. Como veremos, esto es un aspecto importante de la arquitectura de software.
Toda arquitectura es diseño, pero no todo diseño es arquitectura. Ésta representa las decisiones de diseño significativas que dan forma a un sistema, donde lo significativo es medido por el costo del cambio. [Grady Booch].
Recent Comments Gravatars
alfredojv on DISEÑO DE INTERFACES DE USUARIO EN APLICACIONES WEB MODERNAS
SirphatOn on DISEÑO DE INTERFACES DE USUARIO EN APLICACIONES WEB MODERNAS
osvmza on [Tips] función para obtener todos los elementos de cierto tipo en javascript
Alfredo Juarez is Digg proof thanks to caching by WP Super Cache
