Un Recorrido Panorámico

Msc. Jose Angel Franco NavarroFacultad Ingeniería Informática Cujae

afranco@ceis.cujae.edu.cu

Definir el término Arquitectura de Software

Conozcan rasgos característicos del rol Arquitecto de Software

Conozcan a qué se dedica la disciplina de Arquitectura de software dentro del desarrollo de un sistema software. ¿Qué? ¿Cuando? y ¿Cómo?

Conozcan elementos básicos sobre cómo se documenta según RUP

Code Complete 2nd Edition. Steve MacConnell, 2004

Documenting Software Architectures, Clements, Bachmann, Bass, Garlan, Ivers, LIttle, Nord, Stafford, Addison Wesley 2001

Software Architecture in Practice, Second Edition, Len Bass, Paul Clements, Rick Kazman, Addison Wesley 2003.

Software architecture is "the structure of the components of a program/system, their interrelationships, and principles and guidelines governing their design and evolution over time.”

Garlan and Perry, guest editorial to the IEEE Transactions on Software Engineering, April 1995

Software architecture encompasses the set of significant decisions about the organization of a software system:• selection of the structural elements and their

interfaces by which a system is composed• behavior as specified in collaborations among

those elements• composition of these structural and behavioral

elements into larger subsystemGrady Booch

EstructuraOrganización de las piezas

fundamentalesReglas para la interacción entre las

piezasDecisiones claves

¿Esto cómo se puede tocar?

Los Requisitos definen el problema a resolver

La Arquitectura garantiza que la solución sea la apropiada

Evitar el síndrome de WISCA / WIMP:• Why Isn´t Sam Coding Anything?• Why Isn´t Mary Programming?

No violar el orden debido, ahorra tiempo, esfuerzo y dinero.• Entre 10 y 100 veces menos costo de

reprogramación y corrección de error, al encontrarlo en etapas tempranas (Estudios entre el 1976 - 2004)

Rasgo de un sistema desarrollado con calidad

El mismo tipo de problemas = Mismo tipo de solución, a todo lo ancho del sistema.

Creativo, innovador, solucionador de problemas

Ve primero la imagen completa, capaz de abstraer obviando los detalles.

Buen comunicador, sabe escuchar, sabe expresar ideas con claridad a audiencias diversas, sabe persuadir

Negociador, bueno manejando ambigüedades, estableciendo prioridades, manejando prioridades que entran en conflicto y estableciendo compromisos

Mediador de conflictos

Habilidades en lenguajes para la descripción o documentación técnica

Conocedor en profundidad de la tecnología a emplear

Diseñador con experiencia• Dominio de patrones y principios de diseño

Conocedor de Estilos y Patrones de Arquitectura

Humilde Tiene presente que falta siempre mucho por aprender

Priorizar Casos de Uso para incluir en la arquitectura• Casos de uso esenciales para el negocio• Casos de uso que mitigan riesgos• Casos de uso Tipo

Supervisa Identificación y establecimiento de criterios de medida para propiedades/características globales del sistema (Requisitos no funcionales)

Atributos de Calidad Atributos de Calidad InternaInterna

Definidos sin ambigüedadCon criterios claros de medida para

verificar cumplimiento o no.

“Al decir rápido quiero decir…”“El sistema debe ser fácil de usar…”“El sistema debe ser escalable…”

Conjunto de piezas, que solucionan problemas comunes a varios casos de uso del mismo sistema o varios sistemas.

• Integridad Conceptual

Transacciones• Programáticas o Declarativas• A un solo recurso o Distribuidas• Gestionadas por el servidor de aplicaciones o

por el propio sistema?

Control de Concurrencia• Bloqueo optimista o pesimista• Implementado por la tecnología o por el

programador

Control de eventos del usuario(Presentación)

Registros de Eventos para depuración

Manipulación de Errores

Control de la navegación• Regresos atrás, reenvío de formularios

Seguridad• Autenticación encadenada en múltiples

fuentes• Single Sign On

Seguridad• Autorización en el acceso a recursos• Accesos de solo lectura• Registros de Trazas para auditoría

Acceso a Datos

Internacionalización(Multi-Idioma)

Comunicación con sistemas externos

Problema Común Mecanismo

Cómo se Documentan:• Participantes (Diagramas de clases)• Colaboraciones genéricas(Diagramas de

Interacción)• Quedar claro, cómo se emplea, qué escenarios

de uso tiene, si por herencia o por delegación etc.

Principios de Diseño• Open-Closed Principle• Encapsulate Variability• Single Responsability Principle• Once and only Once Rule• Liskov Substitution Principle• Dependency Inversion• Interface Segregation

Concepto de Vistas (Planos)Vistas propuestas por RUP

• Vista Funcional o de Casos de Uso• Vista lógica• Vista de Despliegue• Vista de Procesos• Vista de Implementación

Vistas (4 + 1)Estilo Arquitectónico y Patrones

• N – capas, Cliente Servidor, Service Oriented etc…Lineamientos

• Diseño, ImplementaciónCatálogo de MecanismosFundamentación de decisiones(Rationale)

• Disyuntiva clave Decisión tomada, Otras opciones valoradas, causas que fundamentaron la selección

¿Está clara la organización global del sistema? ¿Se encuentran bien definidos los principales

componentes o piezas del sistema(Subsistemas, Paquetes), incluyendo sus responsabilidades e interfaces brindadas a otros componentes?

¿Se han descrito y justificado las clases más críticas? ¿Se han descrito los lineamientos para el diseño de

los datos? ¿Se ha especificado la organización prevista de la

base de datos? ¿Se han enumerado las principales reglas o

restricciones de negocio, conjuntamente con su impacto en el sistema?

¿Se ha descrito la estrategia para el diseño y construcción de la interfaz con el usuario?

¿Se ha concebido la interfaz de usuario de forma modular de modo que cambios en esta no afecten al resto del programa?

¿Se ha descrito una estrategia para la manipulación de Entrada/Salida?

¿Se ha descrito y justificado una estrategia para el empleo y consumo de recursos?

¿Se han descrito y justificado los requisitos de seguridad que deberá garantizar la arquitectura?

¿Se han descrito y justificado los requerimientos de escalabilidad? ¿La arquitectura describe cómo se logrará esta?

¿Se han descrito y justificado los requerimientos de interoperabilidad?¿Existe un planteamiento de cómo lograrla?

¿Se ha descrito una estrategia para la internacionalización (multi-idioma)?

¿Se ha provisto una estrategia coherente para la manipulación de errores?

En caso de ser necesario. ¿Se ha definido el enfoque para la tolerancia a fallos?

¿Han quedado demostrado como realizables todos los problemas o temas técnicos de las distintas partes del sistema?

¿Se han incluido y fundamentado las decisiones de Comparar vs Construir?

¿Se ha definido una estrategia para el re-huso? ¿Tiene la arquitectura reconocidos los cambios

más probables y ha considerado formas para acometerlos de ser requerido?

¿Qué es la arquitectura?:• Un subproducto, una parte del sistema software en

cuestión• Formado por un conjunto de decisiones claves acerca

de su estructuración, piezas o componentes que lo conforman conjuntamente con las restricciones para las interacciones entre estos, que se plasman en el Documento de Arquitectura. Más las propias piezas o componentes en sí, que aparte de quedar identificadas en el documento de arquitectura se pueden tocar en el código resultante(Clases, Interfaces, Subsistemas), que son de conjunto los fundamentos o bases sobre las cuales se construye el sistema.

En pocas palabras: Especialista multifacético, que tiene en sus manos el timón del éxito técnico del proyecto• Interacción con múltiples involucrados• Líder, supervisor técnico, punto de

consultas. • Negociador, Persuasivo, buen comunicador• Capaz de abstraer la imagen global y

transmitirla

Recoge múltiples aristas del software en vistas separadas.

Incluyendo fundamentación de decisiones y referencias de solución a problemas típicos (Mecanismos)

Un Recorrido Panorámico

Msc. Jose Angel Franco NavarroFacultad Ingeniería Informática Cujae

afranco@ceis.cujae.edu.cu