ARQUITECTURA DE SOFTWARE

Comienza Ya. Es Gratis
ó regístrate con tu dirección de correo electrónico
ARQUITECTURA DE SOFTWARE por Mind Map: ARQUITECTURA DE SOFTWARE

1. Estructuración del sistema que, idealmente, se crea en etapas tempranas del desarrollo.

2. Es de especial importancia ya que la manera en que se estructura un sistema tiene un impacto directo sobre la capacidad de este para satisfacer lo que se conoce como los atributos de calidad del sistema.

3. Modelos estructurales

3.1. Está compuesta por componentes, conexiones entre ellos y (usualmente) otros aspectos tales como configuración, estilo, restricciones, semántica, análisis, propiedades, racionalizaciones, requerimientos.

4. Modelos de framework

4.1. Los modelos de framework a menudo se refieren a dominios o clases de problemas específicos. El trabajo que ejemplifica esta variante incluye arquitecturas de software específicas de dominios.

5. Modelos dinámicos

5.1. Enfatizan la cualidad conductual de los sistemas. “Dinámico” puede referirse a los cambios en la configuración del sistema.

6. Modelos de proceso

6.1. En esta perspectiva, la arquitectura es el resultado de seguir un argumento de proceso. Esta vista se ejemplifica con el actual trabajo sobre programación de procesos para derivar arquitecturas.

7. Modelos funcionales

7.1. Arquitectura como un conjunto de componentes funcionales, organizados en capas que proporcionan servicios hacia arriba. Es tal vez útil pensar en esta visión como un framework particular.

8. Etapas

8.1. Requerimientos

8.1.1. Se enfoca en la captura, documentación y priorización de requerimientos que influencian la arquitectura.

8.2. Diseño

8.2.1. Es la etapa central en relación con la arquitectura y probablemente la más compleja. Durante esta etapa se definen las estructuras que componen la arquitectura

8.3. Documentación

8.3.1. La documentación de una arquitectura involucra la representación de varias de sus estructuras que son representadas a través de distintas vistas. Una vista generalmente contiene un diagram

8.4. Evaluación

8.4.1. Es conveniente evaluar el diseño una vez que este ha sido documentado con el fin de identificar posibles problemas y riesgos.