Ignacio Mora 2016133524

Arquitectura del Software

La arquitectura de aplicaciones de Software es el proceso en el que se define una solución
que cumpla todos los requerimientos, mientras se optimizan atributos como el rendimiento y la
seguridad.
Como cualquier estructura compleja, el software debe ser construido sobre cimientos
sólidos. No considerar escenarios y posibles complicaciones, puede hacer que una aplicación
sea de mala calidad y que alguna característica de ella falle, o que no sea adaptable a posibles
requerimientos futuros.
Los sistemas deberían ser diseñados considerando al usuario, la infraestructura, y las metas
de negocios. para cada una de estas areas, se deben pensar escenarios claves, e identificar
atributos importantes de calidad.
Posiblemente se deba hacer un balance entre requerimientos contradictorios de estas tres
areas. A veces para que la experiencia del usuario sea ideal se debe hacer cambios en la
infraestructura o en el aspecto del negocio, o viceversa. Además es posible que el
administrador no pueda invertir en hardware para cumplir la meta el 100% del tiempo, por lo
que un punto de balance podría ser cumplir la meta un 80% del tiempo.
La arquitectura se enfoca en cómo los elementos y componentes dentro de una aplicación
son usados por o interactúan con, otros componentes y elementos importantes de la aplicación.
A veces la arquitectura y el diseño se confunden, pero mas que usarlos intercambiablemente,
hay decisiones del lado de cada una que van a necesitar a la otra. En unos casos las
decisiones son claramente de arquitectura, pero en otros, son más del lado del diseño, y de
cómo ayudan a la arquitectura.
Debemos considerar los siguientes aspectos cuando se va a pensar en arquitectura:
• ¿Cómo van a usar los usuarios la aplicación?
• ¿Cómo será lanzada la aplicación a producción y administración?
• ¿Cuáles características importantes, como seguridad, rendimiento, configuración o
internacionalización, debe tener la aplicación?
• ¿Cómo se puede diseñar la aplicación para que sea flexible y se le pueda hacer
mantenimiento a través del tiempo?
• ¿Cuáles tendencias de arquitectura podrían afectar a su aplicación ahora o después de
que sea lanzada?

La arquitectura busca construir un puente entre requerimientos de negocios y técnicos

mediante el entendimiento de estos con casos de usos, y luego buscar formas de
implementarlos. Una buena arquitectura disminuye los riesgos asociados a la solución.
Una buena arquitectura debe:
• Exponer la estructura del sistema, pero esconder detalles de implementación.
• Exponer todos los casos de uso y escenarios.
• Tratar de encargarse de todos los requerimientos de las partes interesadas.
• Manejar requerimientos funcionales y de calidad.

Siempre van a ver tendencias de arquitectura, por ello es importante considerar las del
momento y estar preparados para las de futuro.

El pensamiento actual de la arquitectura asume que nuestro diseño va a evolucionar a

través del tiempo y que no se puede saber todo lo necesario para diseñar nuestro sistema.
Usualmente este evolucionará durante las diferentes etapas de nuestra implementación.
Debemos crear nuestra arquitectura con esta evolución en mente.
 Ignacio Mora 2016133524

Hay que considerar ciertas preguntas cuando se va a crear un diseño de arquitectura:

• ¿Cuáles son las partes fundamentales de su arquitectura que representa el mayor riesgo
si se falla?
• ¿ Cuáles son las partes con un cambio más probable, o cuyo diseño se pueda postergar
hasta después, con poco impacto?
• ¿Qué asume usted y como lo probaría?
• ¿Cuáles condiciones pueden hacer que usted tenga que modificar el diseño?
Cuando se está diseñando, es útil dejar opciones abiertas para cambios posteriores. Habrán
aspectos que se deben arreglar en etapas tempranas del proceso, que podrían representar un
costo importante si se tuvieran que rediseñar. Tenemos que identificar estas areas temprano e
invertir el tiempo que sea necesario en arreglarlas.

Hay ciertos principios que hay que considerar cuando estamos diseñando la arquitectura:
• Construya para el cambio en vez de la posteridad.
• Diseñe para analizar y reducir riesgo: para esto utilice sistemas de diseño como UML,
para que pueda visualizar su modelo con claridad, sin embargo no lo formalice tanto como
para que no sea posible hacerle cambios y adaptaciones.
• Utilice el modelo como una herramienta de comunicación y colaboración.
• Identifique decisiones de ingeniería claves.

Es útil considerar usar un acercamiento iterativo e incremental cuando refinamos nuestra

arquitectura. Deberíamos empezar con una base para empezar a acertar el gran panorama de
nuestro diseño. Solo es necesario poder empezar a probar el diseño, antes de empezar con los
detalles.
En sí, la arquitectura agrupa componentes en areas según su objetivo, y además en como
se relaciona con otra area. Y sus principios son:
• Separe bien las areas por su objetivo.
• Principio de Responsabilidad Única.
• Principio del menor conocimiento.
• No repita funcionalidad.
• Minimice el diseño superficial de la arquitectura.

Cuando se está diseñando una aplicación, se debe minimizar la complejidad separando el

diseño en diferentes areas. Por ejemplo, la interfaz, el procesamiento de datos. En cada area,
los componentes del diseño deberían enfocarse en esa area específica, y no se debe mezclar
el código con el de otras areas.

Prácticas de diseño:
• Mantenga patrones de diseño consistentes con cada capa.
• No duplique funcionalidades dentro de la aplicación.
• Prefiera composición a herencia.
• Establezca una convención para el estilo y los nombres durante el desarrollo
• Mantenga la calidad del sistema usando verificación de calidad automatizada.
• Considere la operación de su aplicación

Capas de la aplicación:
• Separe las areas por tareas.
• Sea explícito acerca de la comunicación entre las areas
• No mezcle diferentes tipos de componentes en la misma capa lógica.
 Ignacio Mora 2016133524

Componentes, Módulos y Funciones:

• Un componente u objeto no debe depender de los detalles internos de otros
componentes u objetos.
• No sobrecargue la funcionalidad de un componente.
• Entienda cómo se comunican los componentes entre sí.
• Separe el código de partes sensibles del de la aplicación en sí.
• Especifique los componentes en el contrato.

La arquitectura orientada a objetos divide las responsabilidades de una aplicación en objetos

reusables y auto suficientes, cada uno contiene los datos y comportamientos relevantes a sí. Al
final, cuando tenemos la arquitectura armada, se la mostramos a las partes interesadas y si se
llega a un acuerdo, se prosigue con la parte de desarrollo.