1. Patrones de diseño
1.1. Son soluciones para problemas típicos y recurrentes que nos podemos encontrar a la hora de desarrollar una aplicación.
1.2. Porque usar patrones:
1.2.1. Los patrones de diseño nos ayudan a cumplir muchas reglas de diseño.
1.2.2. Programación SOLID
1.2.3. Control de cohesión
1.2.4. Acoplamiento o reutilización de código
1.2.5. Son algunos de los beneficios que podemos conseguir al utilizar patrones.
1.3. Principales patrones:
1.3.1. Patrones creacionales
1.3.1.1. Corresponden a patrones de diseño software que solucionan problemas de creación de instancias.
1.3.2. Patrones estructurales
1.3.2.1. Son los patrones de diseño software que solucionan problemas de composición (agregación) de clases y objetos
1.3.3. Patrones de comportamiento
1.3.3.1. Se definen como patrones de diseño software que ofrecen soluciones respecto a la interacción y responsabilidades entre clases y objetos
1.4. Aplicación en ámbitos concretos
1.4.1. Patrones de interfaces de usuario
1.4.1.1. Son aquellos que intentan definir las mejores formas de construir interfaces hombre-máquina
1.4.2. Patrones para la construcción de sistemas empresariales
1.4.2.1. En donde se requieren especiales esfuerzos en infraestructuras de software y un nivel de abstracción importante para maximizar factores como la escalabilidad o el mantenimiento del sistema.
1.4.3. Patrones para la integración de sistemas
1.4.3.1. Es decir, para la intercomunicación y coordinación de sistemas heterogéneos.
1.4.4. Patrones de flujos de trabajo
1.4.4.1. Esto es para la definición, construcción e integración de sistemas abstractos de gestión de flujos de trabajo y procesos con sistemas empresariales.
2. Arquitectura 3 capas
2.1. Es un estilo de programacion, su objetivo primordial es la separacion de la capa de presentacion, capa de negocio y capa de datos
2.2. Ventaja principal
2.2.1. Es el desarrollo se puede levar a cabo en varios niveles y, en caso de que sobrevenga algun cambio
2.3. Capas y niveles
2.3.1. Capa de presentacion
2.3.1.1. Esta capa es la que ve el usuario, presenta el sistema al usuario, le comunica y captura la informacion en un mismo proceso
2.3.1.1.1. Se comunica unicamente con la capa de negocio
2.3.2. Capa de negocio
2.3.2.1. Aqui es donde se recibe las peticiones del usuario y se envian las repuestas del proceso
2.3.2.2. Es aqui donde se establecen todas las reglas que deben cumplirse
2.3.3. Capa de datos
2.3.3.1. Es donde residen los datos y es encargada de acceder a los mismos
2.3.3.2. Esta formado por uno o mas gestores de base de datos que realizan todo el almacenamiento de datos
2.3.3.3. Reciben solicitudes de almacenamiento o recuperación de información desde la capa de negocio
3. Vistas
3.1. Representa un comportamiento parcial del sistema.
3.2. Elementos
3.2.1. Forma que se relacionan los elementos los elementos de una vista
3.3. Propuestas arquitecnoticas
3.3.1. Vista arquitectonica de zachman (Matriz de 36 celdas)
3.3.1.1. Iniciando desde un nivel alto de abstracción del negocio y llegando hasta el de implementación
3.3.2. Vista arquitectonica de kruchten Propuso el modelo “4+1
3.3.2.1. Define cuatro vistas diferentes de la arquitectura de softwar
3.3.3. Vista arquitectonica de grady booch, james rumbaugh e ivar jacobson
3.3.3.1. Formularon un esquema de cinco vistas
3.4. Vista logica
3.4.1. Es una abstracción del modelo de diseño
3.4.2. Diagramas de Clases y ObjetosDiagramas
3.4.3. Se complementa con vistas del Área Dinámica
3.4.3.1. Diagramas de Actividad
3.4.3.2. Diagramas de Interacción
3.4.3.3. Diagramas de Estado
3.5. Vista de procesos
3.5.1. Toma en cuenta algunos requerimientos no-funcionales:
3.5.1.1. Rendimiento, disponibilidad
3.5.1.2. Integridad del sistema, tolerancia a fallas
3.6. Vista de despliegue o desarrollo!
3.6.1. Se enfoca en la organización de los módulos del software actual en el ambiente de desarrollo de software.
3.6.2. Se complementa con vistas del Área Dinámica:
3.6.2.1. Diagramas de Actividad
3.6.2.2. Diagramas de Interacción
3.6.2.3. Diagramas de Estado
3.7. Vista Física
3.7.1. Se centra en los requisitos no funcionales
3.7.1.1. Diagrama de despliegue.
3.7.1.1.1. Básicamente este tipo de diagrama se utiliza para modelar el Hardware utilizado en la implementación del sistema y la relaciones entre sus componentes.
3.7.1.1.2. Los elementos usados por este tipo de diagrama son:
3.8. Vista de escenarios
3.8.1. Esta vista contiene los escenarios o casos de uso claves, para cada uno de los cuales se describen las secuencias de interacción entre objetos y procesos
3.8.2. Diagramas de Casos de Uso