Arquitecturas de software - Parte 2

Arquitecturas de Software
Parte 2
- Características Generales
- Atributos de Calidad
- Patrones/Estilos de Arquitectura
Material académico preparado por:
Ph.D Marta Silvia Tabares B.
Fecha última actualización 4-Sep-2011

Ingeniería de Software II
(mapa conceptual de tópicos de conocimiento)

Material Preparado por MARTA SILVIA TABARES B. UdeM

Bibliografía
Los conceptos utilizados en esta presentación fueron estudiados y tomados en su mayoría
de las siguientes referencias bibliográficas.

1. Arlow, J., and Neustad, I. UML 2 and the Unified Process: Practical Object-Oriented Analysis
and Design (2nd Edition). Addison-Wesley Object Technology Series. 2005.
2. OMG-UML. Unified Modeling Language: Superstructure. Version 2.0, formal/05-07-04. 2005.
3. Jacobson, I., Booch, G., Rumbaugh, J. El Proceso Unificado de Desarrollo de Software.
Addison Wesley. 2000.
4. Alan Dennis, Barbara Haley Wixom and David Tegarden. Systems Analysis and Design with
UML Version 2.0 - An Object Oriented Approach, Second Edition. John Wiley & Sons © 2005.
5. Simon Bennett, Stee McRobb, y Ray Farmer. Análisis y Diseño Orientado a Objetos del
Sistema, Usando UML. McGraw-Hill, 2006.
6. Bass, L., Clements, P., Kazman, R. Software Architecture in Practice Second Edition.
7. Pressman, R. Ingeniería del Software un Enfoque Práctico.
8. Camacho, E.; Cardeso, F.; Nuñez, G. ARQUITECTURAS DE SOFTWARE - GUÍA DE ESTUDIO. (Abril, 2004).
9. www.sei.cmu.edu.co
10. http://www.iso.org/iso/home.html
11. http://iso25000.com/index.php/iso-iec-9126.html
3
Material académico preparado por Marta Silvia Tabares B. UdeM

Arquitectura de Software
Flujo de Definición

Material académico preparado por Marta
4
Silvia Tabares B. UdeM

Pasos para definición de una
arquitectura de software
• Creación del caso de negocio para el sistema
• Entendimiento de los requisitos
• Creación y selección de la Arquitectura
• Documentación y comunicación de la Arquitectura
• Análisis o evaluación de la arquitectura
• Implementación del sistema basado en la
arquitectura
• Aseguramiento de que la implementación esté
acorde a la arquitectura
5


• Por qué hay que hacer modelos de
arquitectura?

– Esto permite valorar hasta qué punto cumple
el sistema los Atributos de Calidad.

6

Calidad del Software
• La Calidad de Software para Pressman
(2002) es:
– “la concordancia con los requisitos
funcionales y de rendimiento establecidos
con los estándares de desarrollo
explícitamente documentados y con las
características implícitas que se espera de
todo software desarrollado de forma
profesional”.
7

Atributos de Calidad
• Según Barbacci et al. (1995) la calidad de software se
define como el grado en el cual el software posee una
combinación deseada de atributos. Tales atributos son
requerimientos adicionales del sistema (Kazman et al.,
2001), que hacen referencia a características que éste
debe satisfacer, diferentes a los requerimientos
funcionales.

• Estas características o atributos se conocen con el
nombre de atributos de calidad, los cuales se definen
como las propiedades de un servicio que presta el
sistema a sus usuarios (Barbacci et al. 1995).

8

Norma ISO/IEC 9126

• ISO/IEC (Intenational Standart Organitation u
Organización Internacional de Estándares en
español) define a la calidad de software como:
– la totalidad de rasgos y atributos de un producto
de software que le apoyan en su capacidad de
satisfacer sus necesidades explícitas o implícitas
(ISO/IEC 9126, 1998).

9

Norma ISO/IEC 9126

http://iso25000.com/index.php/iso-iec-9126.html 10

Norma ISO/IEC 9126
• El modelo de calidad establecido en la primera parte del estándar, ISO 9126-1,
clasifica la calidad del software en un conjunto estructurado de características y
subcaracterísticas de la siguiente manera:

• Funcionalidad - Un conjunto de atributos que se relacionan con la existencia de un
conjunto de funciones y sus propiedades específicas. Las funciones son aquellas
que satisfacen las necesidades implícitas o explícitas.
– Idoneidad
– Exactitud
– Interoperabilidad
– Seguridad
– Cumplimiento de normas.

• Fiabilidad - Un conjunto de atributos relacionados con la capacidad del software
de mantener su nivel de prestación bajo condiciones establecidas durante un
período establecido.
– Madurez
– Recuperabilidad
– Tolerancia a fallos
11

Norma ISO 9126
• Usabilidad - Un conjunto de atributos relacionados con el esfuerzo
necesario para su uso, y en la valoración individual de tal uso, por
un establecido o implicado conjunto de usuarios.
– Aprendizaje
– Comprensión
– Operatividad
– Atractividad

• Eficiencia - Conjunto de atributos relacionados con la relación entre
el nivel de desempeño del software y la cantidad de recursos
necesitados bajo condiciones establecidas.
– Comportamiento en el tiempo
– Comportamiento de recursos

12

Norma ISO 9126
• Mantenibilidad - Conjunto de atributos relacionados con la facilidad
de extender, modificar o corregir errores en un sistema software.
– Estabilidad
– Facilidad de análisis
– Facilidad de cambio
– Facilidad de pruebas

• Portabilidad - Conjunto de atributos relacionados con la capacidad
de un sistema software para ser transferido desde una plataforma a
otra.
– Capacidad de instalación
– Capacidad de reemplazamiento
– Adaptabilidad
– Co-Existencia
13

Atributos de Calidad

• Categorías de Atributos de Calidad Bass et al.
(1998) :
– Observables vía ejecución: aquellos atributos que
se determinan del comportamiento del sistema en
tiempo de ejecución. La descripción de algunos de
– No observables vía ejecución: aquellos atributos
que se establecen durante el desarrollo del
sistema.

14

Atributos de Calidad – No observables vía ejecución

Fuente: Camacho, E.; Cardeso, F.; Nuñez, G. ARQUITECTURAS DE SOFTWARE - GUÍA DE ESTUDIO. (Abril, 2004).
15

Atributos de Calidad – NO observables vía ejecución

Fuente: Camacho, E.; Cardeso, F.; Nuñez, G. ARQUITECTURAS DE SOFTWARE - GUÍA DE ESTUDIO. (Abril, 2004).
16

Qué son Requisitos
Arquitectónicamente Significativos?
• Captura la funcionalidad esencial del sistema

• Tiene amplia cobertura (usa muchos elementos de arquitectura).

• Es un desafío de implementación para la arquitectura.

• Enfatiza o detalla problemas o riesgos identificados.

• Ejemplifica demandas rigurosas en la arquitectura (p.ej exigencias de
rendimiento (performance)).

• Son susceptibles a cambios.

• Involucran comunicación y sincronización con sistemas externos.

17

Definición de una Arquitectura
Candidata
• Aunque una arquitectura muchas veces se define como un conjunto de componentes y
conectores, es importante hacer la siguiente evaluación de los elementos que podrían
determinar una arquitectura candidata:

Naturaleza de los elementos
– Cuál es el significado de su separación?
– Ellos se ejecutan en procesadores separados, en tiempos diferentes?
– Ellos se componen de procesos, programas o ambos?
– Ellos representan la forma en la cual el que hacer de los proyectos será dividido?
– Ellos se definen en el sentido de la separación de ejecución?
– Ellos son los objetos, tareas, funciones, procesos, programas distribuidos, o alguna cosa
parecida?

Responsabilidades de los elementos
– Qué es lo que ellos hacen?
– Cuál es su función en el sistema?

18

Candidata
Significado de las conexiones
Las conexiones significan que los elementos entre si se comunican,
controlan, envían datos, sincronizan, comparten alguna información
secreta.
– Algunas son combinaciones de estos u otras relaciones?
– Cuales son los mecanismos para la comunicación?
– Qué información fluye a través de los mecanismos?

Significado de las capas (vistas)
– Por qué el proceso de control está en un nivel separado?
– Es este llamado por elementos de otras capas?
– Hay restricciones de llamado entre los elementos de diferentes capas?

19

Candidata
Tipo de Arquitectura Ejemplos de Ejemplos de
Elementos Relaciones
Conceptual Componentes Conectores
Modular Subsistemas, Exportaciones,
módulos importaciones
Código Archivos, directorios, Incluye, contiene
bibliotecas
Ejecución Tareas, líneas, Usos, llamadas
interacciones de
objetos

Cuatro aspectos de la arquitectura del software según Soni et al. (adaptado de Weir y Daniels, 1998)

20

La Arquitectura de Referencia

Modelo de
Referencia
Arquitectura de Software de
Referencia Arquitectura

Patrón
Arquitectónico

Estos son conceptos útiles que capturan elementos de una arquitectura,
pero en sí ellos no son arquitecturas.

21

Modelo de Referencia
Un modelo de Referencia es una división de
funcionalidad junto con el flujo de datos entre
las piezas.

Es un estándar de descomposición de un
problema conocido, en partes que
cooperativamente resuelven el problema.

22

Arquitectura de Referencia

Es un modelo de referencia mapeado en
elementos de software que
cooperativamente implementan la
funcionalidad definida en el modelo de
referencia y flujos de datos entre ellos

23

Diseño Arquitectónico
• Estructuras
– Módulos: los elementos son módulos, los cuales son
unidades de implementación.

– Componentes-y-Conector: los elementos son
componentes de ejecución (los cuales son principalmente
unidades de computación) y conectores (los cuales son el
vehículo de comunicación entre los componentes).

– De Localización: muestran la relación entre los elementos
de software y los elementos en uno o más ambientes
externos en los cuales el software es creado o ejecutado.

24

• Estructuras
Localización
Módulo

Asignación Implementación
Descomposición Clase Componente-y- de trabajo
Usos Conector Despliegue

Capas
Cliente- Proceso
Servidor
Concurrencia Datos
compartidos

25

• Los procesos de desarrollo basados en el Proceso
Unificado están centrados en la arquitectura.

• La elección de una arquitectura correcta implica
que los arquitectos deben estar involucrados
desde el principio del proyecto.

• La elección de la arquitectura correcta al principio
del proyecto también tiene que ver con la
reducción de los riesgos del proyecto.

26

• Las arquitecturas del sistema son usadas por diversos
conjuntos de personas en tiempos diferentes en el ciclo de
desarrollo, por esta razón es frecuente ver que estas
arquitecturas son separadas en vistas diferentes.

• El Proceso Unificado Racional (RUP) identifica un conjunto de
vistas estándar llamado 4+1 Vistas de Arquitectura. Este
enfoque permite que todos los grupos de participantes
comuniquen las necesidades (es decir, requisitos), resuelvan
los conflictos, y realicen los documentos de decisiones.

27

Patrones/Estilos Arquitectónicos

Un patrón arquitectónico es una descripción
de tipos de elementos y relaciones con un
conjunto de restricciones de cómo ellos
pueden ser usados.

28

Patrones/Estilos Arquitectónicos
• Estilos de Flujo de Datos
– Tubería y filtros
• Estilos Centrados en Datos
– Arquitecturas de Pizarra o Repositorio
• Estilos de Llamada y Retorno
– Modelo-Vista-Control (MVC)
– Arquitecturas en Capas
– Arquitecturas Orientadas a Objetos
– Arquitecturas Basadas en Componentes
29

Patrones o Estilos Arquitectónicos
• Estilos de Código Móvil
– Arquitectura de Máquinas Virtuales
• Estilos heterogéneos
– Sistemas de control de procesos
– Arquitecturas Basadas en Atributos
• Estilos Peer-to-Peer
– Arquitecturas Basadas en Eventos
– Arquitecturas Orientadas a Servicios
– Arquitecturas Basadas en Recursos

30

Patrón Arquitectónico:
Cliente - Servidor

Servidor Cliente

Cliente

Cliente y Servidor son dos tipos de elementos y su coordinación se
describe en términos del protocolo que el servidor usa para
comunicarse con cada uno de sus cliente

31

Arquitectura Centrada en los Datos
• Un almacén de datos (archivo o base de datos) se encuentra
en el centro de la arquitectura, los otros componentes
tienen acceso a el y cuentan con la opción de actualizar,
agregar, eliminar o modificar datos de dicho almacén.

Software Software
Cliente Cliente

Almacén de Datos

Software Software
Cliente Cliente

32

Arquitectura Física Centrada en los Datos

33

Arquitectura por Capas
Cada capa (layer – Tier) es un nivel de
abstracción del sistema.
System Time (Time). This component allows the
system to run at a userdefined time in a simulation
mode. With multiple instances of this component,
real time and simulated time can be used
concurrently.
Time Synchronization (TSync). With different parts
of the system running on different hardware
nodes, synchronizing the system time on each
node is critical.
Communication Protocols (Comm). This
component includes components dealing with low-
level communication protocols tailored for specific
applications.
Built-in Test (BiT). These modules handle hardware
testing.

34

Arquitectura en o por Capas

Fuente: imágenes de google

Material académico preparado por Marta Silvia Tabares B. UdeM 35

Arquitectura Por Capas (Ej. 1)

36


37


38

Patrón Arquitectónico
Arquitectura Flujo de Datos –
Filtros (Filters) y Tuberías (Pipes)

39

Arquitectura Flujo de Datos –
Filtros (Filters) y Tuberías (Pipes)
Los componentes se
denominan FILTROS que
son conectados por
medio de TUBERÍAS las
cuales transmiten los
datos.

Se aplica cuando los
datos de entrada se
habrán transformado en
datos de salida mediante
una serie de
componentes para el
cálculo o la
manipulación.
40

Arquitectura Flujo de Datos – Filtros y Tuberías
Un ejemplo de uso del patrón Filtros y Tuberías - Requisito de Seguridad

class Filtros y Tuberías

User

- id: int
- name: varchar

1..*

MemberOf

1..*

Role ProtectionObj ect
isAuthorizedFor
- id: int - id: int
- name: varchar - name: varchar

Right

- accessType: varchar

+ checkRights() : void

Modelo de clases: Requisito de Seguridad

Fuente teórica : Fernandez, E; Ortega-Arjona, J; The Secure Pipes and Filters pattern. Fifth LACCEI International Latin American and Caribbean Conference for Engineering and Technology (LACCEI’2007)
“Developing Entrepreneurial Engineers for the Sustainable Growth of Latin America and the Caribbean:
Education, Innovation, Technology and Practice”
29 May – 1 June 2007, Tampico, México. 41

Arquitectura Flujo de Datos – Filtros (Filters) y Tuberías (Pipes)

sd Sistema

:RefMonitor :Right :Filter_j :Pipe_i :Pipe_j

:Role1

op3(role)

checkRights()

:decision

:desicion

op3()

read (data)

read (data)

write (data)
op3()
write(data)

Fuente teórica: Fernandez, E; Ortega-Arjona, J; The Secure Pipes and Filters pattern
42

Arquitectura Flujo de Datos – Filtros (Filters) y Tuberías (Pipes)

Fuente teórica: Fernandez, E; Ortega-Arjona, J; The Secure Pipes and Filters pattern
43

Arquitectura Modelo – Vista - Control
Un Ejemplo:

44

Arquitectura Orientada a Servicios

Imagen tomada de «imágenes google»
45

Arquitectura Orientada a Servicios

Imagen tomada de «imágenes google»
46

Arquitectura Hibridas (Servicios – Capas – Plataformas)

Sharepoint architectura
Imagenes tomada de Avepoint

47

Modelo de Referencia – Patrón Arquitectónico
Modelo-Vista-Controlador
Clase Interfaz <<Interface>>:
• En UML Recepcionar peticiones al sistema.
Mostrar respuestas del sistema.
Se propone para el desarrollo del
Modelo de Análisis de las
aplicaciones, tres tipos de clases Clase Entidad <<Entity>>:
fundamentales, con las cuales Gestionar datos (información) necesaria
podemos expresar todas las para el sistema.
Almacenar datos (información)
funciones de cualquier software, persistentes del sistema.
con sus respectivas Provee la funcionalidad principal de
responsabilidades la aplicación

Clase Controlador
<<Controller>>:
Procesar Información del sistema.
Gestionar visualización de
respuesta del sistema.
Obtiene los datos del modelo.

48


• Este patrón arquitectónico y de diseño fue descrito por primera vez
por Trygve Reenskaug en 1979 y fue implementado en Smalltalk en
los laboratorios Xerox.

• MVC se basa en la separación de la aplicación en tres capas
principales: Modelo, Vista y Controlador.

• Se usa (él o alguna de sus variantes) en la gran mayoría de las
interfaces de usuario.

49

Modelo de Referencia – Patrón
Arquitectónico
Ejemplo del flujo de mensajes entre:

50


• Vista: Se presenta el modelo en un formato adecuado para
interactuar, usualmente un elemento de interfaz de usuario.

• Controlador: Este responde a eventos, usualmente acciones del
usuario e invoca cambios en el modelo y probablemente en la vista.

51

• Muchas aplicaciones utilizan un mecanismo de almacenamiento
persistente (como puede ser una base de datos) para almacenar los
datos. MVC no menciona específicamente esta capa de acceso a
datos porque supone que está encapsulada por el modelo.

• El objetivo primordial del MVC es la reutilización del código ya
implementado.

• Esta tarea se facilita mucho si a la hora de programar tenemos la
precaución de separar el código en varias partes que sean
susceptibles de ser reutilizadas sin modificaciones.

52

Ejemplos

• Los datos de una hoja de cálculo pueden mostrarse de en formato
tabular, con un gráfico de barras, con uno de sectores.
• Los datos son el modelo.
• Si cambia el modelo, las vistas deberían actualizarse en
consonancia.
• El usuario manipula el modelo a través de las vistas.
�� (en realidad, a través de los controladores)

53

Mas de una Vista de un Modelo de
Datos

54


• MVC es utilizado con mayor frecuencia en las aplicaciones
web, donde la Vista es la página HTML, y el Controlador es
el código que reúne la data dinámica y genera el contenido
de la página.

• El Modelo es representado por el contenido actual, que
usualmente se encuentra almacenado en una base de
datos o en archivos XML.

55


56

Fortalezas
• Se presenta la misma información de distintas formas.

• Las vistas y comportamiento de una aplicación deben reflejar las
manipulaciones de los datos de forma inmediata.

• Debería ser fácil cambiar la interfaz de usuario (incluso en tiempo de
ejecución).

• Permitir diferentes estándares de interfaz de usuario o portarla a otros
entornos no debería afectar al código de la aplicación.

57

Muchas interfaces gráficas de usuario, como Swing o MFC, hacen
innecesario el uso de un controlador.

• Definen su propio flujo de control y manejan los eventos
internamente.

• Integran, así, la vista y el controlador.

• A esta variante se la suele denominar Document-View

58

Un controlador (controlador.java, por ejemplo) puede gestionar el clic en un botón, de tal forma que recoge datos
por medio del Modelo (model.cargar_texto(..)) y los manda a la Vista (el applet) para su actualización
(vista.mostrar_texto( )):

/****************************************************************
Responde al click en botón "abrir" La respuesta al evento es hacer que se abra en la vista
el archivo correspondiente a la referencia seleccionada en el combo box
****************************************************************/
void b_abrir_actionPerformed(ActionEvent e) {
…
String texto_archivo = model.cargar_texto( indice_ref ); // Obtener texto de archivo
/*** Si la carga de archivo es ok, lo muestro. Si no, aviso de error ****/
if (texto_archivo != null) {
vista.mostrar_texto(texto_archivo); // Mostrar texto
vista.mostrar_aviso("Carga de " + path + " completada.");
}
else
vista.mostrar_aviso("Error en la carga de " + path);
}

59

Arquitecturas de software - Parte 2

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Arquitecturas de software - Parte 2

Ähnlich wie Arquitecturas de software - Parte 2 (20)

Mehr von Marta Silvia Tabares

Mehr von Marta Silvia Tabares (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Arquitecturas de software - Parte 2