Clase Arquitectura de Software

ARQUITECTURA DE SOFTWARE

Walter Adrin Gmez Cspedes

Ingeniero de Sistemas Especialista en Pedagoga Universitaria

Candidato a Mster en Direccin Estratgica en Ingeniera del Software

DESARROLLO DE SISTEMAS DE SOFTWARE

Requisitos

Funcionales

del Software

Servira para un

Software

monoltico

Los atributos de calidad de Software son esenciales

Arquitectura

de Software

SW de Calidad

Software

Software

LOS REQUISITOS DETERMINAN EL MODELO

Requisitos

Conocimiento

Arquitecto

Sistema

IMPLICACIONES DE NO SEGUIR UN PROCESO CONOCIDO DE MODELADO

Arquitectura es una abstraccin de un sistema

Los sistemas tienen

una estructura

Todo sistema tiene

una arquitectura.

El tener una arquitectura, no implica que se

tiene una arquitectura conocida.

El no desarrollo

de una

arquitectura

explcita

conduce a

inconformidad

CONSECUENCIAS DE LAS DECISIONES DE AS SOBRE LAS CUALIDADES

La arquitectura es crtica para alcanzar los

atributos de calidad

Las cualidades del producto deben

disearse como parte de la arquitectura

Un cambio en la estructura que mejora una

cualidad suele afectar a otras cualidades

La arquitectura slo puede permitir, no garantizar que

cualquier requisito de calidad se alcance

Dependiendo

de las

decisiones de

Arquitectura, un

sistema alcanza

sus requisitos de

calidad

INFLUENCIA DE LOS INTERESADOS

Arquitecto

Gerente

Empresa

Gerente

Producto

Usuario Final

Ingeniero de

soporte

Cliente

Bajos costos

Ocupar personal

Valor Activos

Elementos

atractivos

Terminar rpido

Comparar

competencia

Comportamiento

Seguridad

Confiabilidad

Usabilidad

Modificabilidad

Bajos costos

Terminar rpido

Pocos cambios

INTERESADOS INVOLUCRADOS

Objetivos de la organizacin y las propiedades del sistema

requeridas por el negocio, raramente se comprenden

Los requisitos de

calidad del cliente,

casi nunca se

documentan

Identificar e

involucrar

activamente a los

interesados

Qu debe

tener en

cuenta el

arquitecto de

software?

- Objetivos que no

se alcanzan.

- Conflicto entre los

interesados.

- Comprender restricciones

reales del sistema.

- Administrar las

expectativas.

- Negociar prioridades del

sistema.

-Tomar decisiones de

compromiso.

ESQUEMA DE PROCESO DE MODELADO DE AS

Determinar los

Requisitos

Arquitectnicos

Diseo de la

Arquitectura

Validacin

ESQUEMA DE PROCESO DE MODELADO DE AS

Determinar los

Requisitos

Arquitectnicos

Involucra crear un modelo desde los requerimientos que

guiarn el diseo de la arquitectura basado en los

atributos de calidad esperados.

Diseo de la

Arquitectura

Involucra definir la estructura y las responsabilidades de

los componentes que comprendern la Arquitectura de

Software.

Validacin

Significa probar la arquitectura, tpicamente pasando a

travs del diseo contra los requerimientos actuales y

cualquier posible requerimiento a futuro.

IDENTIFICAR REQUERIMIENTOS

Requisitos

Funcionales

Requisitos de

los interesados

Determinar los Requisitos

Arquitectnicos

Requisitos de

Arquitectura

Priorizar

Clasificacin de los requisitos no funcionales

Identificar restricciones

REQUERIMIENTOS NO FUNCIONALES

Describen como el software debe comportarse, es decir

como hacer algo, no que debe hacer.

Estn relacionados con los requerimientos funcionales

porque describen la forma que se espera se logren

dichos requerimientos.

En algunos casos tienen restricciones de cmo hacerlo.

Se clasifican de acuerdo al atributo de calidad esperado

del sistema.

EJEMPLO DE REQUERIMIENTOS DE AS

ACTIVIDAD CON EL GRUPO DE TRABAJO

Como ya se tiene planteado cul es el software que se va a desarrollar

durante el trimestre, el siguiente paso a trabajar en identificar los

requerimientos funcionales y no funcionales, para ello hacer uso de la

siguiente forma para el levantamiento de requerimientos:

Nombre:

Tipo:

Crtico: Si/No

Descripcin:

Criterios de Aceptacin:

DEFINICIONES DE AS

Clements: Vista del sistema que incluye los componentes principales del mismo, la conducta de esos componentes segn se la percibe desde el resto del sistema y las

formas en que los componentes interactan y se coordinan para alcanzar la misin del sistema.

IEEE Std 1471-2000: es la organizacin fundamental de un sistema encarnada en sus componentes, las relaciones entre ellos y el ambiente y los principios que orientan su diseo y evolucin.

Se

ocupa

de

Diseo preliminar o de alto nivel.

Organizacin a alto nivel 1. Descripcin y anlisis de estructura.

2. Protocolos de comunicacin.

Aspectos relacionados con

el desarrollo del sistema y

su evolucin.

composicin, reconfiguracin,

reutilizacin, escalabilidad,

mentenibilidad.

No se

ocupa

de

Diseo Detallado, Diseo de algoritmos, diseo de estructura de

datos.

MODELOS DE AS

Modelos estructurales: AS est compuesta por componentes, conexiones entre ellos y

(usualmente) otros aspectos (configuracin, estilo, restricciones, semntica, anlisis,

propiedades, racionalizaciones, requerimientos, necesidades de los participantes).

Modelos de framework: Son similares a la vista estructural, pero su nfasis primario radica en la estructura coherente del sistema completo, en vez de concentrarse en su composicin. Los modelos de framework a menudo se refieren a dominios o clases de problemas especficos.

Modelos dinmicos: Enfatizan la cualidad conductual de los sistemas. Los cambios en la

configuracin del sistema, o a la dinmica involucrada en el progreso de la

computacin, tales como valores cambiantes de datos.

Modelos de proceso: Se concentran en la construccin de la arquitectura, y en los pasos

o procesos involucrados en esa construccin. En esta perspectiva, la arquitectura es el

resultado de seguir un argumento (script) de proceso.

Modelos funcionales: Una minora considera la arquitectura como un conjunto de

componentes funcionales, organizados en capas que proporcionan servicios hacia

arriba. Es tal vez til pensar en esta visin como un framework particular.

CONCEPTOS FUNDAMENTALES

Estilos

Concepto descriptivo que define una forma de articulacin u

organizacin arquitectnica. El conjunto de los estilos cataloga las

formas bsicas posibles de estructuras de software. Conjugan elementos,

conectores, configuraciones y restricciones.

ADL

Lenguaje de Descripcin Arquitectnica. permiten modelar una

arquitectura mucho antes que se lleve a cabo la programacin de las

aplicaciones que la componen.

Frameworks y Vistas

Es una estructura conceptual y tecnolgica de soporte definido, normalmente

con artefactos o mdulos de software concretos, que puede servir de base

para la organizacin y desarrollo de software.

Abstra-ccin

Extraer las propiedades esenciales, o identificar los aspectos importantes,

o examinar selectivamente ciertos aspectos de un problema,

posponiendo o ignorando los detalles menos sustanciales, distractivos o

irrelevantes.

ARQUITECTURA O DISEO

Diferencias

entre Arquitectura

y Diseo

1. Arquitectura y Diseo son lo mismo

2. Arquitectura se encuentra en un nivel de abstraccin

por encima del diseo.

3. Arquitectura es algo nuevo y en alguna medida

diferente del diseo (pero de qu manera y en qu

medida se dejan sin especificar).

4. Shaw y Garlan: AS es

el primer paso en la

produccin de un

diseo de software.

a. Arquitectura.

b. Diseo del cdigo.

c. Diseo de ejecutable.

ARQUITECTURA O DISEO

Arquitectura

Asocia las capacidades del sistema especificadas en el requerimiento con los componentes del sistema que habrn de implementarla. La descripcin arquitectnica incluye componentes y conectores (en trminos de estilos) y la definicin de operadores que crean sistemas a partir de subsistemas o, en otros trminos, componen estilos complejos a partir de estilos

simples.

Diseo del

cdigo

Comprende algoritmos y estructuras de datos; los

componentes son aqu primitivas del lenguaje de

programacin, tales como nmeros, caracteres, punteros

e hilos de control. Tambin hay operadores primitivos.

Diseo

Ejecutable

Remite al diseo de cdigo a un nivel de detalle todava

ms bajo y trata cuestiones tales como la asignacin de

memoria, los formatos de datos, etctera.

RELEVANCIA DE LA AS

Comunicacin

Mutua

Decisiones

tempranas de diseo Restricciones

constructivas

Abstraccin

transferible

Entendimiento

mutuo, formar

consenso y

comunicarse

entre si.

Respecto al

desarrollo

restante del

sistema, su

servicio en el

despliegue y su

vida de

mantenimiento.

Blueprints

parciales para

el desarrollo

Modelo

relativamente

pequeo de la

forma en que

un sistema se

estructura y sus

componenten

se entienden

entre si.

Exponer

restricciones de

alto nivel sobre

el diseo y

justificar las

decisiones

arquitectnicas

Participantes usan como base para Tienen un peso

Proporciona Encarna

Permite

Componentes y

dependencias

entre ellos.

Indicando

RELEVANCIA DE LA AS

Evolucin Anlisis Administracin

Exponer las

dimensiones a

lo largo de las

cuales puede

esperarse que

evolucione el

sistema.

Nuevas

oportunidades

para anlisis

Logros clave

para el

desarrollo de

proyectos

exitosos.

La AS puede

Aporta AS proporciona

Verificaciones de

consistencia,

conformidad con las

restricciones impuestas

por un estilo,

conformidad con

atributos de calidad,

anlisis de

dependencia, anlisis

de dominio y negocios.

Incluyendo

ESTILOS ARQUITECTNICOS

Estilos indican

Los tipos de componentes y conectores involucrados.

Patrones y restricciones de interconexin

o composicin entre ellos.

Serie de propiedades que lo caracterizan, determinando sus ventajas e inconvenientes

Estilos se les asocian

Condiciona la eleccin de uno u otro estilo

Un estilo arquitectnico define una familia de sistemas (cierto tipo de sistemas) en trminos de

patrones estructurales, de control, de comunicacin, etc.

CLASIFICACIN DE LOS ESTILOS

Sistemas basados en flujos de datos

- Pipes and Filters (Tuberas y Filtros). - Secuencial (Batch).

Sistemas llamada y retorno

- Sistemas principal/subrutinas.

- Sistemas OO. - Capas jerrquicas

Mquinas Virtuales - Intrpretes. - Sistemas basados en el conocimiento.

Sistemas centrados en datos

- Bases de datos. - Sistemas de Hipertexto. - Sistemas de pizarra.

DESCRIPCIN DE ALGUNOS ESTILOS

Estilo de flujo de datos: enfatiza la reutilizacin y la modificabilidad. Es apropiada para sistemas que implementan transformaciones de datos en pasos sucesivos.

Tuberas y Filtros

Una tubera (pipeline) es una popular arquitectura que conecta componentes computacionales (filtros) a travs de conectores (pipes), de

modo que las instrucciones se ejecutan a la manera de un flujo.

Cada componente tiene un conjunto de entradas y uno de salidas.

Cada componente lee las entradas y las transforma en salidas.

Los filtros deben ser independientes, no comparten estado con otros.

Los filtros realizan la labor independientemente del flujo de entrada.

Ventajas: 1. Permite entender el sistema global en trminos de sus componentes. 2. Soporta la reutilizacin (Son independientes de sus vecinos). 3. Facilidad de mantenimiento y de diagnstico.

Desventajas: 1. No es aconsejado para cuando se necesita interactividad. 2. Problemas de performance ya que los datos se transmiten en forma completa entre filtros. 3. Facilidad de mantenimiento y de diagnstico.

SE RECOMIENDA PARA

Procesamiento de seales .

Procesamiento de

imgenes o sonido.

Compiladores. Procesamiento de cadenas.

Sistemas con poca o nula

interaccin con el usuario cuyo

flujo de datos se entienda o

perciba como continuo.

Aplicarlo para el clculo, algoritmos

de bsqueda y modelos de

simulacin cientfica.

Para

Desarrollos

ARQUITECTURA DE TUBERAS

Filtros o componentes (Transformacin de los datos).

Tuberas (Flujo de

datos).

EJEMPLO DE TUBERAS

Problema: Se desea implementar un software que sirva como traductor de algunos idiomas.

Leer

Traducir al ingls Escribir ingls

Traducir al Francs Escribir Francs

Nivel 0:

Nivel 1: Vista conceptual

Analizador Lexicogrfico

Analizador Sintctico/Parser

Analizador Semntico

Generador de Cdigo Intermedio

Tabla de

Smbolos

Traduccin

EJEMPLO DE TUBERAS

Interfaz de

usuario

Herramienta

Diccionario

Filtro

Java, .NET,

otro

Filtro

Herramienta

Para gestin

contenidos

Filtro

Nivel 2: Vista lgica

EJEMPLO DE TUBERAS

Input

getDato()

Lexicogrfico

Lexo()

Parser

Aparse()

Analizador Semntico

Generador de Cdigo

writeCodeByte()

tubo SW

Leer Escribir

Intrprete

getDato()

call getDato

call Alexo call Asemantico

call codgen Escribir pipe

Leer pipe


EJEMPLO DE TUBERAS

Fuente de

datos

push

Lexicogrfico push

Parser

push

Receptor

de Datos

escribir

datos

escribir

datos

datos

escribir

f1

f2

NOTA: La accin se inicia empujando los datos hacia el siguiente filtro

Nivel 4: Flujo de datos


MVC

Modelo Vista controlador (Model View Controler).

Estilo llamada/retorno: enfatiza la modificabilidad y la escalabilidad. Son los estilos ms generalizados en sistemas en gran escala. Miembros de la familia son las

arquitecturas de programa principal y subrutina, los sistemas basados en llamadas

a procedimientos remotos, los sistemas orientados a objeto y los sistemas

jerrquicos en capas.

Un propsito comn en numerosos sistemas es el de tomar datos de un almacenamiento y mostrarlos al usuario. Luego que el usuario introduce

modificaciones, las mismas se reflejan en el almacenamiento.

Modelo. Maneja el comportamiento y los datos del dominio de la aplicacin, responde a los requerimientos de informacin acerca de su estado (usualmente desde la vista) y responde a las instrucciones para cambiar de estado (usualmente desde el controlador).

Vista. Maneja la visualizacin de la informacin.

Controlador. Interpreta las acciones del ratn y el teclado, informando al modelo y/o a la vista para que cambien segn resulte apropiado.


Ventajas: 1. Soporte de vistas mltiples. Dado que la vista se halla separada del modelo y no hay

dependencia directa del modelo con respecto a la vista, la interfaz de usuario puede mostrar mltiples vistas de los mismos datos simultneamente.

2. Adaptacin al cambio. Los requerimientos de interfaz de usuario tienden a cambiar con mayor rapidez que las reglas de negocios.

Tanto la vista como el controlador dependen del modelo. Sin embargo,

el modelo no depende ni de la vista ni del controlador.

La separacin permite que el modelo sea construido y probado

independientemente de la presentacin visual.

La separacin entre vista y controlador es secundaria en muchas

aplicaciones, sin embargo en las aplicaciones Web la vista (el

navegador) y el controlador (los componentes del lado servidor) estn

bien definidos.

EJEMPLO ARQUITECTURA MVC

Software para la gestin de prstamo a usuarios de biblioteca.

MODELO Un conjunto de libros, conjunto de

usuarios, conjunto de prestamos. El

prstamo almacenar el libro

seleccionado por un usuario. El usuario

contendr informacin sobre su

profesin y rea a la que pertenece.

VISTA Consiste en un listado de usuarios que

realizan prstamos. Un listado de los

libros disponibles. Estadsticas de

prstamos.

CONTROLADOR Actualizacin por medio de teclado.

Ingreso de datos por medio del teclado.

Bsqueda de informacin por teclado

y mouse.


Tanto la vista como el controlador dependen del modelo, pero el modelo no depende de estos.


Interfaz de

Usuario

Procedimientos Funciones

Clases para mostrar los datos

provenientes de las rdenes.

CONTROLADOR

Reportes Vistas SQL

VISTA

Clases para: Manejo de usuarios,

estado del prstamo, ubicacin de libros,

estado, etc.

MODELO




Orden

Prstamo

Tipo: String

Items: String

Consultar()

Actualizar()

Usuario

Nombre: String

Telfono: Integer

Guardar()

Consultar()

Actualizar()

Usuario Prstamo Libro

Libro

Nombre: String

Tipo: String

Cantidad: Integer

Guardar()

Consultar()

Actualizar()

Ficha

Fecha: Date

Ndias: Integer

Entrega

Publicacin:

String

Validacin

Actualizar()



CONTROLADOR VISTA MODELO

Evento:

Teclado

Mouse Servicio:

Bsqueda

Registro

Actualizacin

Visualizacin

Obtener Dato


Enrutador

Mvil

Aplicacin

Escritorio

Dispositivo Tradicional

Aplicacin

Mvil

Dispositivo Mvil

WinForms

Reportes

SQL

Clases

Proced.

Funciones.

Aplicativo

Controlador

Interfaz

Controlador

Interfaz

Mvil

C#.Net

WAP. ASP.Net

Nivel 5: Vista Fsica

Servidor

Base de

Datos


Arquitectura

en Capas

El diseo y desarrollo de estos sistemas informticos se realizan de forma jerrquica (capas). Los componentes de una capa slo pueden hacer referencia a componentes en capas inmediatamente inferiores.

Presentacin

Lgica

Datos

Se encarga de que el sistema interacte con el usuario y viceversa, muestra el sistema al usuario, le presenta la informacin y obtiene la informacin del usuario en un mnimo de proceso.

Residen las funciones que se ejecutan, se reciben las peticiones del usuario, se procesa la informacin y se envan las respuestas tras el proceso.

Encargada de almacenar los datos del sistema y de los usuarios. Su

funcin es almacenar y devolver datos a la capa de negocio, aunque para esto tambin es necesario en algunos casos, que tengan procedimientos almacenados y funciones dentro de la capa.


Ventajas:

1. Permite a los implementadores partir un problema complejo en una secuencia de pasos incrementales.

2. El estilo admite muy naturalmente optimizaciones y refinamientos.

3. Proporciona amplia reutilizacin.

Desventaja:

Los cambios en las capas de bajo nivel tienden a filtrarse hacia las de alto nivel.


Arquitectura OO

Los componentes de este estilo son los objetos, o ms bien instancias de los tipos de dato abstractos. Los objetos interactan a travs de invocaciones de funciones y procedimientos.

POO

Clases

Polimorfismo

Herencia

Abstraccin

de datos Encapsulacin

Ocultamiento de

Informacin


Ventajas: 1. Se puede modificar la implementacin de un objeto sin afectar a sus clientes. 2. Es posible descomponer problemas en colecciones de agentes en interaccin.

3. Un objeto es ante todo una entidad reutilizable en el entorno de desarrollo

Desventajas:

1. Para poder interactuar con otro objeto a travs de una invocacin de procedimiento, se debe conocer su identidad.

2. Cuando se modifica un objeto se deben modificar tambin todos los objetos que lo invocan.

3. Se presentan problemas de efectos colaterales en cascada.


Pizarra

Hay dos componentes principales: una estructura de datos que representa el estado actual y una coleccin de componentes independientes que operan sobre l.

Estos sistemas se han usado en aplicaciones que requieren complejas interpretaciones de proceso de seales (reconocimiento de patrones, reconocimiento de habla, etc), o en sistemas que involucran acceso compartido a datos con agentes dbilmente acoplados.

Todo modelo de este tipo consiste en las siguientes tres partes:

1. Fuentes de conocimiento, necesarias para resolver el problema.

2. Una pizarra que representa el estado actual de la resolucin del problema.

3. Una estrategia, que regula el orden en que operan las fuentes.


Software para la gestin de prstamo a usuarios de biblioteca.

MODELO Este componente se encarga del

manejo del comportamiento y los datos

del dominio de la aplicacin, responde

a los requerimientos de informacin

acerca de su estado (usualmente

desde la vista) y responde a las

instrucciones para cambiar de estado

(usualmente desde el controlador)

VISTA Este componente se encarga todo el

despliegue de la informacin del

software.

CONTROLADOR Este componente se encarga del

Interpreta las acciones del usuario de teclado y ratn, informando al modelo

y/o a la vista para cambiar

apropiadamente sus estados.


Tanto la vista como el controlador dependen del modelo, pero el modelo no depende de estos.


Interfaz de

Usuario

Procedimientos Funciones

Clases

CONTROLADOR

Windows Forms Reportes Vistas SQL

VISTA

Plataforma .NET Visual Studio 2010

MODELO




Orden

Prstamo

Tipo: String

Items: String

Consultar()

Actualizar()

Cliente

Nombre: String

Telfono: Integer

Guardar()

Consultar()

Actualizar()

Cliente Prstamo Publicacin

Publicacin

Nombre: String

Tipo: String

Cantidad: Integer

Guardar()

Consultar()

Actualizar()

Ficha

Fecha: Date

Ndias: Integer

Entrega

Publicacin:

String

Validacin

Actualizar()



CONTROLADOR VISTA MODELO

Evento

Servicio

Actualizacin

Obtener Dato


Enrutador

Mvil

Aplicacin

Escritorio

Dispositivo Tradicional

Aplicacin

Mvil

Dispositivo Mvil

WinForms

Reportes

SQL

Visual

Studio

2012

Proced.

Funciones.

Clases

Aplicativo

Controlador

Interfaz

Controlador

Interfaz

Mvil

C#.Net

WAP. ASP.Net

Nivel 5: Vista Fsica

Servidor

Base de

Datos

Clase Arquitectura de Software

Documents

Transcript of Clase Arquitectura de Software