UNIVERSIDAD TECNOLOGICA DEL PERU
FILIAL - A AREQUIPA
ESCUELA PROFESIONAL DE INGENIERIA DE SISTEMAS E INFORMATICA VIII CICLO TURNO MAÑANA
CURSO: DISEÑO Y ARQUITECTURA DE SOFTWARE INTEGRANTES: EDGAR
ARTURO QUISPE MAMANI JUAN MIGUEL PAREJA TEMA: DISEÑO ARQUITECTONICO AREQUIPA – PERU 2014
INTRODUCCION En los inicios de la informática, la programación se consideraba un arte y se desarrollaba como tal, debido a la dificultad que entrañaba para la mayoría de las personas, pero con el tiempo se han ido descubriendo y desarrollando formas y guías generales, con base a las cuales se puedan resolver los problemas. A estas, se les ha denominado Arquitectura de Softare, porque, a seme!an"a de los planos de un edificio o construcción, estas indican la estructura, funcionamiento e interacción entre las partes del softare. En el libro #An introduction to Softare Architecture#, $avid %arlan y &ary Sha definen que la Arquitectura es un nivel de diseño que hace foco en aspectos #más allá de los algoritmos y estructuras de datos de la computación' el diseño y especificación de la estructura global del sistema es un nuevo tipo de problema#.
DISEÑO ARQUITECTONICO ¿Qué se entiende por diseño r!uite"t#ni"o$ •
(omprende el establecimiento de un marco de traba!o estructural básico para un sistema.
•
Alude a la estructura general del softare y el modo en que la estructura ofrece una integridad conceptual al sistema.
•
$e modo simple, se puede considerar que está compuesta por la estructura !erárquica de los componentes )módulos*, la manera en la que dichos componentes interact+an y la estructura de datos que es utili"ada por dichos componentes.
Ar!uite"turs So%t&re' (ene%i"ios
Des"ri)ir e*p+,"itente + r!uite"tur
de un siste
so%t&re
propor"ion )ene%i"ios o
$urante la gestión del sistema
$ocumento sobre el que poder discutir Aumenta la precisión en la estimación del coste y tiempo El arquitecto proporciona información +til
Durnte e+ desrro++o de+ siste o
Es una e-celente vista general y consistente de m+ltiples vistas del sistema
o
roporciona la relación de puntos de diseño a tratar
o
/acilita el desarrollo simultáneo de componentes
o
/acilita la reutili"ación a gran escala ) es la base para construir líneas de productos*
Propieddes !ue de)en espe"i%i"rse "oo prtes de un diseño r!uite"tur+'
Propieddes estru"tur+es.0 define los componentes de un sistema y la manera en la que dichos componentes se agrupan en paquetes e interaccionan entre ellos.
Propieddes e*tr-%un"ion+es.0 debe indicar cómo el diseño arquitectónico alcan"a los requisitos no funcionales como rendimiento, capacidad, fiabilidad, seguridad, adaptabilidad, etc.
Fi+is de sistes re+"iondos.0 debe permitir reconocer su estructura en los patrones repetitivos que se encuentran de manera habitual en el diseño de sistemas similares. $ebe ser capa" de reutili"ar bloques de construcción arquitecturales.
Un diseño r!uite"tur+ de)e des"ri)irse uti+i.ndo di%erentes tipos de ode+os'
/ode+os estru"tur+es.0 representan la arquitectura como una colección organi"ada de componentes.
/ode+os Fre&or0s.0 identifican patrones de diseño arquitectónico repetibles que se encuentran en aplicaciones similares.
/ode+os din1i"os.0 muestran los aspectos del comportamiento dinámico de la arquitectura, indicando cómo la estructura o la configuración del sistema pueden cambiar en función de eventos e-ternos.
/ode+os de pro"esos.0 se enfocan en el diseño de los proceso del negocio que el sistema debe soportar.
/ode+os %un"ion+es.0 pueden utili"arse para representar la !erarquía funcional de un sistema.
Esti+os r!uite"t#ni"os
1n diseño arquitectónico se refiere a la arquitectura de un sistema concreto.
1n estilo arquitectónico define componentes, relaciones entre componentes y restricciones sobre esas relaciones, esto es, establece las restricciones sobre la arquitectura de una familia de diseños arquitectónicos. 2 (entrada en datos 2 /lu!o de datos 2 or capas 2 (omponentes independientes
Esti+os r!uite"t#ni"os 3 &odelos de descomposición de sistemas. 3&odelo de almac4n central. 3(liente5servidor. 3&odelos de máquinas abstractas. 3 &odelos de control. 3(entrali"ado. 3&odelo de eventos.
3 &odelos de descomposición modular. 3&odelo de flu!o de datos. 3&odelo orientado a ob!etos. 3 &odelos de dominio específico.
ESTILOS ARQUITECT2NICOS Ar!uite"tur "entrd en +os dtos3
/acilita la integración pues los componentes son independientes.
Se puede pasar datos entre componentes a trav4s del almac4n de datos.
Cr"ter,sti"s romueve la capacidad de integración, es decir, que es posible cambiar componentes e-istentes y agregar nuevos componentes a la arquitectura sin preocuparse por otros clientes, además es posible pasar datos entre clientes empleando el mecanismo del pi"arrón. 6os componentes clientes e!ecutan los procesos de manera independiente.
Ar!uite"tur "entrd en +os %+u4os de dtos3-
Se aplica cuando los datos de entrada se han de transformar en datos de salida mediante una serie de operaciones.
6os componentes )filtros* van transmitiendo datos al siguiente por medio de tuberías.
6os filtros no necesitan saber el funcionamiento de los vecinos. Sólo se preocupan de su entrada y su salida.
Si hay una sola línea de transformaciones se denomina procesamiento por lotes secuencial )pipeline*.
Coponentes independientes •
1n subestilo es que los componentes sigan una !erarquía de control donde un programa principal invoca a varios componentes de programa que pueden invocar a otros componentes.
•
Cr"ter,sti"s
6as arquitecturas de flu!o de datos no se basan en un contador de programa )al menos conceptualmente* en tanto en cuanto la posibilidad de e!ecución de las instrucciones solamente viene determinada por la disponibilidad de los argumentos de entrada de las instrucciones. •
5ent4s 6a e!ecución fuera de orden se ha convertido en el paradigma computacional por e-celencia desde los años 78. Es una forma de flu!o de datos restringido. Este paradigma introdu!o la idea de ventana de e!ecución, que sigue el orden secuencial de la arquitectura de von 9eumann' sin embargo, dentro de la ventana se permite que las instrucciones sean completadas en el orden de las dependencias de datos.
•
Des6ent4s 6a comple!idad lógica de mantener el rastro de las dependencias de datos de forma dinámica restringe a los procesadores basados en e!ecución fuera de orden a un reducido n+mero de e!ecuciones )de : a ;* y limita el tamaño de la ventana de e!ecución de <: a :88 instrucciones, mucho menor que las utili"adas en las máquinas puras de flu!o de datos.
Ar!uite"tur de L+d 7 Retorno
Estilo clásico desde los años =7;8. $escomposición !erárquica en subrutinas )componentes* que solucionan una tarea o función definida. 6os datos son pasados como parámetros y el mane!ador principal proporciona un ciclo de control sobre las subrutinas. >efle!an la estructura del lengua!e de programación. ermite al diseñador del softare construir una estructura de programa relativamente fácil de modificar y a!ustar a escala. Se basan en la bien conocida abstracción de procedimientos5funciones5m4todos.
•
Cr"ter,sti"s
?ilo de control simple soportado por los lengua!es de programación.
1sa una estructura implícita de subsistemas.
>a"onamiento !erárquico, cambios en una subrutina implican cambios en las subrutinas que hacen la invocación.
retenden incrementar el desempeño distribuyendo el traba!o en m+ltiples procesadores.
•
•
5ent4s
1tili"ados en grandes sistemas de softare.
6a descomposición en módulos disminuye la comple!idad.
ersiguen escalabilidad y modificabilidad.
Des6ent4s
$ependencia y acoplamiento entre módulos.
6a reutili"ación y el mantenimiento son difíciles
Ar!uite"tur orientd o)4etos3En este estilo los componentes son los ob!etos, o instancias de tipos de datos abstractos. Estos ob!etos son de un tipo de componente denominado manager porque es responsable por preservar la integridad de un recurso. 6os ob!etos interact+an a trav4s de invocaciones a procedimientos y funciones.
Aspe"tos iportntes •
•
1n ob!eto es responsable de preservar la integridad de su representación )usualmente manteniendo alg+n invariante*. 6a representación se oculta a otros ob!etos.
5ent4s •
•
(omo un ob!eto oculta su representación a sus clientes, es posible cambiar su implementación sin modificar los clientes modificabilidad. 6a integración de un con!unto de rutinas de acceso con los datos que manipulan permite a los diseñadores descomponer los problemas en colecciones de agentes que interact+an.
Des6ent4s •
ara que un ob!eto interact+e con otro )mediante la invocación a un procedimiento* debe conocer la identidad del otro ob!eto. 6uego, cuando la
•
identidad de un ob!eto cambie es necesario modificar todas las invocaciones a tal ob!eto. Se pueden presentar efectos laterales si los ob!etos A y ( usan al ob!eto @, entonces los efectos de ( en @ lucen como efectos laterales no esperados en A, y viceversa.
Ar!uite"tur en "ps3
6os estilos se suelen me"clar. or e!emplo, una arquitectura por capas puede usar un estilo diferente en cada capa
ue las dos +ltimas capas sean una arquitectura centrada en datos.
1na capa se implemente como un flu!o de datos o con componentes independientes.
CONCLUSIONES •
El diseño arquitectónico es fundamental para el resultado final del desarrollo softare.
•
6a arquitectura de Softare nos proporciona una visión global del sistema a construir.
•
6a arquitectura marca decisiones de diseño tempranas y proporciona el mecanismo para evaluar los beneficios de las estructuras del sistema.
•
odemos tener
modelos estáticos
)paquetes,
componentes*, dinámicos
)secuencia, comunicación, estados* y de despliegue. •
6os estilos arquitectónicos definen la estructura general del sistema.
(I(LIO8RAFIA
9E(8RAFIA •
$epartamento de lengua!es y sistemas informáticos 1niversidad de Sevilla. http55.lsi.us.es5docencia5get.phpBidCD8F
•
•
http55.ecured.cu5inde-.php5EstilosGarquitectH(
Artículos de Arquitectura de Softare http55.microsoft.com5spanish5msdn5arquitectura
•
&odelado y $iseño de Arquitectura de Softare http55cic.pu!.edu.co5iIi5lib5e-e5fetch.phpB mediaCmateriass:conceptosdemodelado.pdf
•
Arquitectura de Softare http55es.iIipedia.org5iIi5ArquitecturaGdeGsoftare
•
&odelar la arquitectura de un sistema de softare http55msdn.microsoft.com5es0es5library5ddJ78;.asp-