Introducción a la arquitectura de software

1. Introducción a la arquitectura de software Daniel Correa BoteroJosé López VélezUniversidad de Antioquia 2013-II

2. Procesos básicos de la ingeniería de software Especificación del software Desarrollo del software Validación del software Evolución del software (Diseño e implementación) Arquitectura del software – diagramas UML - patrones de arquitectura - patrones de diseño – patrones grasp y gof – frameworks – artefactos – componentes – librerías. Entrevistas – Plantillas – Modelo del dominio – Casos de uso – Req funcionales y no funcionales – Etiquetado – Objetivos – Diagrama de clases – Modelo entidad relación – Diagramas estructurales y de comportamiento (UML). Ing. del software - IanSommerville

3. Trabajos en cada área Gerente de proyectos Especificación del software Desarrollo del software Validación del software Evolución del software Diseño Implementación Administrador de bases de datos Analista Diseñador o arquitecto del software Programador Ingeniero en pruebas - testing Ingeniero en seguridad Nota: en algunos casos el programador terminando cumpliendo el rol de: analista, arquitecto, testing, etc.

5. Diseño de arquitectura del software • La primera etapa del diseño e implementación del software es llamada diseño arquitectónico. • Comprende el establecimiento de un marco de trabajo estructural básico para un sistema (patrón de organización del sistema). • Sirve para identificar los principales componentes de un sistema y la comunicación entre estos.

6. Diseño de arquitectura del software • Permite conocer si el sistema podrá cumplir reglas del negocio y requisitos críticos tales como rendimiento, seguridad, adaptabilidad, fiabilidad y mantenibilidad. • Toda esta etapa es llevada a cabo por el arquitecto de software. Nota: en algunos casos no existe el arquitecto de software. Las decisiones son tomadas entre los analistas o por un analista líder. Incluso a veces no se realiza documentación adicional de la parte del diseño arquitectónico.

7. Diseño de arquitectura Implementación

8. Decisiones del diseño ¿Patrones de arquitectura? ¿Frameworks? • ¿Existe una arquitectura de aplicación genérica que pueda actuar como una plantilla para el sistema que se está diseñando?. • ¿Qué estilo o estilos arquitectónicos son apropiados para el sistema?. • ¿Cómo debería documentarse la arquitectura del sistema?. • ¿Cómo se descompondrán en módulos las unidades estructurales del sistema?. ¿Qué sucede si desean realizar modificaciones con otra empresa o desarrollador? ¿Cómo vamos a sincronizar la información de los pagos? ¿Qué lenguaje de programación utilizar? ¿Cómo sacar la información de la temperatura de la caldera? La clave para responder todas estas preguntas es: la experiencia.

9. Resultados del diseño arquitectónico. • El resultado es un documento de diseño arquitectónico. Incluye representaciones graficas del sistema junto con texto descriptivo asociado. • Debería describir como se divide el sistema en subsistemas y como se divide cada subsistema en módulos. • Existen múltiples forma de desarrollo de un documento de diseño arquitectónico. Puede ser: utilizando notación UML, diagramas de procesos, interfaces, diseño orientados a objetos, entre otros. Nota: la evaluación de un sistema arquitectónico es muy difícil debido a que consiste en averiguar el grado de satisfacción de los requisitos funcionales y no funcionales especificados anteriormente, y para esto se debe implementar el software.

13. Diagrama de robustez de Jacobson

14. Ejemplo de un mapa de navegación.

15. Tipos de arquitecturas • Arquitecturas centradas de datos. Algunas veces llamado Blackboard. En el centro de esta arquitectura se encuentra un almacén de datos (por ejemplo, un documento o una base de datos) al que otros componentes acceden con frecuencia para actualizar, añadir, borrar o bien modificar los datos del almacén. HearsaySpeechUnderstanding ftp://shelob.cs.umass.edu/pub/Erman_Hearsay80.pdf

16. Tipos de arquitecturas • Arquitecturas centradas de datos. • Adobe Acrobat Capture (OCR) (ahora descontinuada) uso un sistema Blackboard para descomponer y reconocer páginas de imágenes para entender los objetos, el texto y las fuentes en la página. • Uno de los componentes principales del sistema de misión de control de RADARSAT-1 utilizó la arquitectura Blackboard. Muy utilizada en sistemas expertos, visión artificial, interpretación sensorial. http://lasg.ditf.rtu.lv/Portals/0/LASG/Research/Publications/2007/2007-Rudenko-Borisov-RTU.pdf

17. Tipos de arquitecturas • Arquitecturas de flujo de datos. Esta arquitectura se aplica cuando los datos de entrada son transformados a través de una serie de componentes computacionales o manipulativos en los datos de salida. Típicamente usada en procesamiento de señales y transformación de flujos de datos.

18. Tipos de arquitecturas • Arquitecturas orientadas a objetos. Los componentes de un sistema encapsulan los datos y las operaciones que se deben realizar para manipular los datos. La comunicación y la coordinación entre componentes se consigue a través del paso de mensajes. • Arquitecturas estratificadas (por capas).Se crean diferentes capas y cada una realiza operaciones diferentes. La ventaja principal de este estilo es que el desarrollo se puede llevar a cabo en varios niveles y, en caso de que sobrevenga algún cambio, sólo se ataca al nivel requerido sin tener que revisar entre código mezclado.

19. Patrones de software • En el desarrollo de software de casi todas las aplicaciones es necesario solucionar una y otra vez los mismos problemas: autenticación del usuario, persistencia de datos, separación de la capa de presentación, lógica, control, etc. • En lugar de reinventar la rueda es mas conveniente aplicar estrategias que ya hayan funcionado con anterioridad. • Ventajas: ya están probados, son reutilizables, reducen notablemente el esfuerzo y las líneas de código.

20. ¿Qué es un patrón de arquitectura? • Para algunos autores existe una sutil diferencia entre tipos de arquitectura (o estilos de arquitectura) y patrones de arquitectura. Diciendo que un estilo de arquitectura es una manera conceptual como se creará o trabajará el sistema, mientras que un patrón de arquitectura describe una solución para la aplicación de un estilo de arquitectura a nivel de subsistemas o módulos y sus relaciones. • Para otros autores son conceptos similares. Figura patrón mvc A Practical Guide to Enterprise Architecture (The Coad Series) http://library.riphah.edu.pk/books%5Ccs%5Cprog%5Clanguages%5Cjava%5CPGEArchitecture.pdf

21. Patrón de arquitectura MVC • El Modelo: Es la representación de la información con la cual el sistema opera, por lo tanto gestiona todos los accesos a dicha información, tanto consultas como actualizaciones, implementando también los privilegios de acceso que se hayan descrito en las especificaciones de la aplicación (lógica de negocio). En los frameworks actuales normalmente representa una entidad del diagrama entidad-relación. Ejemplo de una parte del modelo ‘user’ en php.

22. Patrón de arquitectura MVC • La Vista: presenta el modelo (información y lógica de negocio) en un formato adecuado para que un usuario pueda interactuar (usualmente la interfaz de usuario). Ejemplo de una vista creada en html y smarty.

23. Patrón de arquitectura MVC • El controlador: es el intermediario entre la vista y el modelo, su función consiste en controlar el flujo de datos, responder a eventos (usualmente provocados por los usuarios) e invocar peticiones al modelo. Ejemplo de un controlador en php.

24. ¿Qué es un patrón de diseño? • Un patrón de diseño es una solución reutilizable general a un problema que ocurre comúnmente en un contexto determinado en el diseño de software. • Los patrones de diseño se encuentran en el dominio de los módulos y las interconexiones. Dominios de mas bajo nivel que los patrones de arquitectura. • Los patrones de diseño son generalmente asociados con aspectos comunes a nivel de código.

25. ¿Qué es un Framework ? • Es un marco (un esqueleto, un patrón) para el desarrollo y/o la implementación de una aplicación. Ventajas: • Mayor seguridad, agrupa prácticas y criterios para solucionar problemas comunes. • Reutilización de código (no hay que reinventar la rueda). • Acceso a tutoriales y documentación sobre como crear aplicaciones. • El programador no necesita plantearse una estructura global de la aplicación, sino que el framework le proporciona un esqueleto que hay que "rellenar".

26. Otras características de los frameworks • Poseen un árbol de carpetas estructurado. • Poseen patrones de diseño y de arquitectura integrados. • Poseen componentes y librerías pre-instaladas que facilitan la programación. • Evolucionan continuamente para adaptarse a las nuevas necesidad o corregir errores de versiones anteriores.

27. Aprendizaje de frameworks de aplicación web Tipos de documentación • Patterns. [9] • Example-based learning. [7] • Cookbooks. [10] • Visualization. [11] Componentes Yii - Error Handling Yii - URL Management Yii - Data Caching Codeigniter - Error Handling Codeigniter - URI Routing Codeigniter - Caching Rubyonrails - ExceptionHandling Rubyonrails - Railsroutes Rubyonrails - Caching

28. Caso de estudio Howto define a controller Howtocallviews Howtocallmodelclasses Howtohandleerrors

29. Resultados • 13 componentes principales identificados, algunas tareas definidas para cada componente. - Identify how to create controller classes and what functions should be override. - Identify how to call model classes.- Identify how to call libraries or plugins. - Identify how to call views.- Identify how to receive data from views. - Identify how to do redirects. Learning of web application frameworks components

30. ¿Que pasa cuando se omite el diseño arquitectónico? • Proyectos desechados poco tiempo después de ser entregados. • El mantenimiento se convierte en una tarea casi imposible. • Grandes sobrecostos por incluir funcionalidades adicionales. • Proyectos con mala calidad y poca fiabilidad.

31. ¿Que pasa cuando se omite el diseño arquitectónico?

32. Bibliografía • Learning UML 2.0 O’Reilly. 2006. • Software Modeling & desing. UML, use cases, patterns, & software architectures. Hassan Gomma. 2011. • Ingenieria del software. 7th edición. Ian Somerville. 2005. • UML y patrones. Craig Larman. 1999. • Ingeniería del software. Un enfoque practico 5ta edición. Roger S. Pressman. 2002. • Use Case DrivenObjectModelingwith UML, Theory and Practice. Doug Rosenberg. 2007.