Introducción a la Arquitectura de Software

1. Daniel Correa Botero
José López Vélez
Universidad de Antioquia 2013-II

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

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

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

9.  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.  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.
Hearsay Speech Understanding
ftp://shelob.cs.umass.edu/pub/Erman_Hearsay80.pdf

16.  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.
http://lasg.ditf.rtu.lv/Portals/0/LASG/Research/Publi
cations/2007/2007-Rudenko-Borisov-RTU.pdf
Muy utilizada en
sistemas expertos,
visión artificial,
interpretación
sensorial.

17.  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.  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.  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.  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%5Clanguag
es%5Cjava%5CPGEArchitecture.pdf

21.  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.  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.  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.  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.  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.  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. Tipos de documentación
 Patterns. [9]
 Example-based
learning. [7]
 Cookbooks. [10]
 Visualization. [11]
Yii - Error Handling
Yii - URL Management
Yii - Data Caching
Codeigniter - Error Handling
Codeigniter - URI Routing
Codeigniter - Caching
Ruby on rails - Exception
Handling
Ruby on rails - Rails routes
Ruby on rails - Caching
Componentes

28. How to define
a controller
How to call
views
How to call
model
classes
How to handle
errors

29.  13 componentes principales identificados, algunas
tareas definidas para cada componente.
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.

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

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