Introducción a la arquitectura de

softwareDaniel Correa Botero

José López VélezUniversidad de Antioquia 2013-II

Procesos básicos de la ingeniería de software

Especificación del

software

Desarrollo del software

Validación del software

Evolución del software

Ing. del software - Ian Sommerville

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).

(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.

Trabajos en cada área

Especificación del

software

Desarrollo del software

Validación del software

Evolución del software

Administrador de bases de datosAnalist

a

Programador

Diseño Implementación

Diseñador o arquitecto del

softwareIngeniero en

seguridad

Ingeniero en pruebas -

testing

Nota: en algunos casos el programador terminando cumpliendo el rol de: analista, arquitecto, testing, etc.

Gerente de proyectos

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.

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.

Diseño de arquitectura del software

Diseño de arquitectura

Implementación

¿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?.

Decisiones del diseño¿Patrones de arquitectura? ¿Frameworks?

¿Qué sucede si desean realizar modificaciones

con otra empresa o

desarrollador?

¿Cómo vamos a sincronizar la

información de los pagos?

¿Cómo sacar la información de la temperatura de

la caldera?

¿Qué lenguaje de programación

utilizar?La clave para responder todas

estas preguntas es: la experiencia.

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.

Resultados del diseño arquitectónico.

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.

Diagrama de robustez de Jacobson

Ejemplo de un mapa de navegación.

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.

Tipos de arquitecturas

Hearsay Speech Understanding ftp://shelob.cs.umass.edu/pub/Erman_Hearsay80.pdf

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.

Tipos de arquitecturas

http://lasg.ditf.rtu.lv/Portals/0/LASG/Research/Publications/2007/2007-Rudenko-Borisov-RTU.pdf

Muy utilizada en sistemas expertos,

visión artificial, interpretación

sensorial.

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.

Tipos de arquitecturas

Típicamente usada en procesamiento de señales y transformación de flujos

de datos.

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.

Tipos de arquitecturas

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.

Patrones de software

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.

¿Qué es un patrón de arquitectura?

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

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.

Patrón de arquitectura MVC

Ejemplo de una parte del modelo ‘user’ en php.

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).

Patrón de arquitectura MVC

Ejemplo de una vista creada en html y smarty.

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.

Patrón de arquitectura MVC

Ejemplo de un controlador en php.

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.

¿Qué es un patrón de diseño?

¿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".

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.

Otras características de los frameworks

Tipos de documentación

Patterns. [9] Example-based

learning. [7] Cookbooks. [10] Visualization. [11]

Aprendizaje de frameworks de aplicación web

Yii - Error HandlingYii - URL Management

Yii - Data Caching

Codeigniter - Error HandlingCodeigniter - URI Routing

Codeigniter - Caching

Ruby on rails - Exception Handling

Ruby on rails - Rails routesRuby on rails - Caching

Componentes

Caso de estudio

How to define a controller

How to call views

How to call model classes

How to handle errors

13 componentes principales identificados, algunas tareas definidas para cada componente.

Resultados

Learning of web application frameworks components

- Superclass model- Superclass Controller- Route Manager- Error Handler- Template Manager- Database Manager- Role Manager- Data Validation- Helper- Cache- ORM- Automatic code generator- Tester

- 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.

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.

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

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

1) index-malo.php

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 Driven Object Modeling with UML,

Theory and Practice. Doug Rosenberg. 2007.

Bibliografía