Diseño Arquitectónico Del Software 6m304y

Ingeniería de Software II Diseño Arquitectónico del software

Prof. Ing. Edgar Muñante Villafuerte

Ingeniería de Software II

Slide 1

Diseño Arquitectónico El desarrollo de un proyecto de construcción de software es un proceso en el que intervienen muchos factores y por ello es importante contar con las herramientas adecuadas. Actualmente hay disponibles muchas opciones tecnológicas que nos ayudan a componer nuestras soluciones, pero sin embargo no mitigan las principales problemáticas de un proyecto:  





Necesidades de adaptación a cambios en los proyectos (requerimientos funcionales y técnicos), que pueden tener un alto impacto en lo que a esfuerzo se refiere. Incertidumbre a la hora de escoger y utilizar la tecnología que mejor encaja en cada escenario. Integración con sistemas heredados que no tienen un alineamiento claro con los requerimientos de proyecto.


Slide 2

Diseño Arquitectónico El diseño de la arquitectura de un sistema es el proceso por el cual se define una solución para los requisitos técnicos y operacionales del mismo. Este proceso define qué componentes forman el sistema, cómo se relacionan entre ellos, y cómo mediante su interacción llevan a cabo la funcionalidad especificada, cumpliendo con los criterios de calidad indicados como seguridad, disponibilidad, eficiencia o usabilidad.

Requisitos

Diseño


Construcción

Slide 3

Diseño Arquitectónico Durante el diseño de la arquitectura se tratan los temas que pueden tener un impacto importante en el éxito o fracaso de nuestro sistema. Algunas preguntas que hay que hacerse al respecto son:    



¿En qué entorno va a ser desplegado nuestro sistema? ¿Cómo va a ser nuestro sistema puesto en producción? ¿Cómo van a utilizar los s nuestro sistema? ¿Qué otros requisitos debe cumplir el sistema? (seguridad, rendimiento, concurrencia, configuración…) ¿Qué cambios


Slide 4

Diseño Arquitectónico

 Definición Se define arquitectura software como la estructura del sistema, que comprende elementos software, las propiedades de esos elementos visibles externamente y las relaciones entre ellos. La arquitectura software conforma el esqueleto de cualquier sistema software, y es la principal responsable de los atributos de calidad del sistema. Una arquitectura adecuada, correctamente diseñada, documentada y evaluada, constituye la base para que un proyecto finalice con éxito Esta definición implica que la arquitectura de un sistema define componentes y la interacción existente entre ellos. La arquitectura del sistema se puede ver desde un número no determinado de perspectivas, todas ellas válidas siempre que valgan para algún fin: análisis, comunicación o comprensión. Ingeniería de Software II

Slide 5


El proceso de diseño inicial que identifica estos subsistemas y establece un marco para el control y comunicación de los subsistemas se llama diseño arquitectónico. El resultado de este proceso de diseño es una descripción de la arquitectura del software.


Slide 6


El proceso de diseño arquitectónico está relacionado con el establecimiento de un marco estructural básico que identifica los principales componentes de un sistema y las comunicaciones entre estos componentes. Para diseñar la arquitectura de un sistema es importante tener en cuenta los intereses de los distintos agentes que participan. Estos agentes son los s del sistema, el propio sistema y los objetivos del negocio. Cada uno de ellos impone requisitos y restricciones que deben ser tenidos en cuenta en el diseño de la arquitectura y que pueden llegar a entrar en conflicto, por lo que se debe alcanzar un compromiso entre los intereses de cada participante. Ingeniería de Software II

Slide 7


• Para los s es importante que el sistema responda a la interacción de una forma fluida, mientras que para los objetivos del negocio es importante que el sistema cueste poco. • Los s pueden querer que se implemente primero una funcionalidad útil para su trabajo, mientras que el sistema puede tener prioridad en que se implemente la funcionalidad que permita definir su estructura. • El trabajo del arquitecto es delinear los escenarios y requisitos de calidad importantes para cada agente así como los puntos clave que debe cumplir y las acciones o situaciones que no deben ocurrir.


Slide 8


El objetivo final de la arquitectura es identificar los requisitos que producen un impacto en la estructura del sistema y reducir los riesgos asociados con la construcción del sistema. La arquitectura debe soportar los cambios futuros del software, del hardware y de funcionalidad demandada por los clientes. Del mismo modo, es responsabilidad del arquitecto analizar el impacto de sus decisiones de diseño y establecer un compromiso entre los diferentes requisitos de calidad así como entre los compromisos necesarios para satisfacer a los s, al sistema y los objetivos del negocio.


Slide 9


En síntesis, la arquitectura debería: • Mostrar la estructura del sistema pero ocultar los detalles. • Realizar todos los casos de uso. • Satisfacer en la medida de lo posible los intereses de los agentes. • Ocuparse de los requisitos funcionales y de calidad. • Determinar el tipo de sistema a desarrollar. • Determinar los estilos arquitecturales que se usarán. • Tratar las principales cuestiones transversales.


Slide 10


Una vez vistas las principales cuestiones que debe abordar el diseño de la arquitectura del sistema, ahora vamos a ver los pasos que deben seguirse para realizarlo. En una metodología ágil como Scrum, la fase de diseño de la arquitectura comienza durante en el pre-juego (Pre-game) o en la fase de Inicio (Inception) en RUP, en un punto donde ya hemos capturado la visión del sistema que queremos construir. En el diseño de la arquitectura lo primero que se decide es el tipo de sistema o aplicación que vamos a construir. Los principales tipos son: aplicaciones móviles, de escritorio, RIAs (Rich Internet Application), aplicaciones de servicios, aplicaciones web… Es importante entender que el tipo de aplicación viene determinado por la topología de despliegue y los requisitos y restricciones indicadas en los requisitos. Ingeniería de Software II

Slide 11


La selección de un tipo de aplicación determina en cierta medida el estilo arquitectural que se va a usar. El estilo arquitectural es en esencia la partición más básica del sistema en bloques y la forma en que se relacionan estos bloques. Los principales estilos arquitecturales son: Cliente/Servidor, Sistemas de Componentes, Arquitectura en capas, MVC, NNiveles, SOA… Como ya hemos dicho, el estilo arquitectural que elegimos depende del tipo de aplicación. Una aplicación que ofrece servicios lo normal es que se haga con un estilo arquitectural SOA. Ingeniería de Software II

Slide 12


Tras haber seleccionado el tipo de aplicación y haber determinado los estilos arquitecturales que más se ajustan al tipo de sistema que vamos a construir, tenemos que decidir cómo vamos a construir los bloques que forman nuestro sistema. Por ello el siguiente paso es seleccionar las distintas tecnologías que vamos a usar. Estas tecnologías están limitadas por las restricciones de despliegue y las impuestas por el cliente. Hay que entender las tecnologías como los ladrillos que usamos para construir nuestro sistema. Por ejemplo, para hacer una aplicación web podemos usar la tecnología ASP.NET o para hacer un sistema que ofrece servicios podemos emplear WCF.


Slide 13


Tras haber seleccionado el tipo de aplicación y haber determinado los estilos arquitecturales que más se ajustan al tipo de sistema que vamos a construir, tenemos que decidir cómo vamos a construir los bloques que forman nuestro sistema. Por ello el siguiente paso es seleccionar las distintas tecnologías que vamos a usar. Estas tecnologías están limitadas por las restricciones de despliegue y las impuestas por el cliente. Hay que entender las tecnologías como los ladrillos que usamos para construir nuestro sistema. Por ejemplo, para hacer una aplicación web podemos usar la tecnología ASP.NET o Java.


Slide 14



Slide 15


Los procesos software actuales asumen que el sistema cambiará con el paso del tiempo y que no podemos saber todo a la hora de diseñar la arquitectura. El sistema tendrá que evolucionar a medida que se prueba la arquitectura contra los requisitos del mundo real. Por eso, no hay que tratar de formalizar absolutamente todo a la hora de definir la arquitectura del sistema.


Slide 16


A la hora de crear la arquitectura de nuestro sistema de forma iterativa e incremental, las principales preguntas a responder son: • ¿Qué partes clave de la arquitectura representan el mayor riesgo si las diseño mal? • ¿Qué partes de la arquitectura son más susceptibles de cambiar? • ¿Qué partes de la arquitectura puedo dejar para el final sin que ello impacte en el desarrollo del sistema? • ¿Cuáles son las principales suposiciones que hago sobre la arquitectura y como las verifico? • ¿Qué condiciones pueden provocar que tenga que cambiar el diseño?


Slide 17

Diseño Arquitectónico En el marco de la ingeniería del software y del ALM, el proceso de diseño de la arquitectura juega un papel muy importante. La diferencia entre un buen proceso de diseño arquitectural y uno malo puede suponer la diferencia entre el fracaso o éxito de nuestro proyecto. En el diseño de la arquitectura tratamos los temas más importantes a la hora de definir nuestro sistema, es decir, creamos un molde básico de nuestra aplicación. Dentro del proceso de diseño de la arquitectura se decide: • • • • •

Qué tipo de aplicación se va a construir. (Web, RIA, Rich Client…) Qué estructura lógica va a tener la aplicación (N-Capas, Componentes…) Qué estructura física va a tener la aplicación (Cliente/Servidor, N-Tier…) Qué riesgos hay que afrontar y cómo hacerlo. (Seguridad, Rendimiento, Flexibilidad…) Qué tecnologías vamos a usar (WCF,WF,WPF, Silverlight, Entity Framework, etc.)


Slide 18

Diseño Arquitectónico Para realizar todo este proceso partiremos de la información que ha generado el proceso de captura de requisitos, más detalladamente, esta información es: • Casos de uso o historias de . • Requisitos funcionales y no funcionales. • Restricciones tecnológicas y de diseño en general. • Entorno de despliegue propuesto.

A partir de esta información deberemos generar los artefactos necesarios para que los programadores puedan implementar correctamente el sistema. Como mínimo, en el proceso de diseño de la arquitectura debemos definir: • Casos de uso significativos a implementar. • Riesgos a mitigar y cómo hacerlo. • Arquitecturas candidatas a implementar.


Slide 19

Diseño Arquitectónico SELECCIONAR LOS CASOS DE USO ARQUITECTURALMENTE IMPORTANTES

El diseño de la arquitectura es un proceso dirigido por el cliente y los riesgos a afrontar, esto significa que desarrollaremos primero los casos de uso (funcionalidad) que más valor tengan para el cliente y mitigaremos en primer lugar los riesgos más importantes que afronte nuestra arquitectura (requisitos de calidad). La importancia de un caso de uso la valoraremos según los siguientes criterios:

• Lo importante que es el caso de uso dentro de la lógica de negocio • El desarrollo del caso de uso implica un desarrollo importante de la arquitectura. • El desarrollo del caso de uso implica tratar algún requisito de calidad. • Lo que se adapte el caso de uso a los objetivos de la iteración.


Slide 20

Diseño Arquitectónico REALIZAR UN ESQUEMA DEL SISTEMA

Una vez que están claros los objetivos de la iteración y la funcionalidad que desarrollaremos, podemos pasar a su diseño. Llegados a este punto, el primer paso es decidir qué tipo de aplicación vamos a desarrollar. El tipo de aplicación que elegiremos dependerá de las restricciones de despliegue, de conectividad, de lo compleja que sea la interfaz de y de las restricciones de interoperabilidad, flexibilidad y tecnologías que imponga el cliente. Cada tipo de aplicación nos ofrece una serie de ventajas e inconvenientes, el arquitecto tiene que escoger el tipo de aplicación que mejor se ajuste a las ventajas que espera que tenga su sistema y que presente menos inconvenientes.


Slide 21


Los principales tipos de aplicaciones que desarrollaremos son: • Aplicaciones para dispositivos móviles: Se trata de aplicaciones web con una interfaz adaptada para dispositivos móviles o aplicaciones de desarrolladas para el terminal. • Aplicaciones de escritorio: Son las aplicaciones clásicas que se instalan en el equipo del que la vaya a utilizar. • RIA (Rich Internet Applications): Se trata de aplicaciones que se ejecutan dentro del navegador gracias a un plug-in y que ofrecen una mejor respuesta que las aplicaciones web y una interfaz de calidad similar a las aplicaciones de con la ventaja de que no hay que instalarlas. • Servicios: Se trata de aplicaciones que exponen una funcionalidad determinada en forma de servicios web para que otras aplicaciones los consuman. • Aplicaciones web: Son aplicaciones que se consumen mediante un navegador y que ofrecen una interfaz de estándar y completamente interoperable Ingeniería de Software II

Slide 22


Una vez que tenemos decidido el tipo de aplicación que vamos a desarrollar, el siguiente paso es diseñar la arquitectura de la infraestructura, es decir, la topología de despliegue. La topología de despliegue depende directamente de las restricciones impuestas por el cliente, de las necesidades de seguridad del sistema y de la infraestructura disponible para desplegar el sistema. Definimos la arquitectura de la infraestructura en este punto, para tenerla en consideración a la hora de diseñar la arquitectura lógica de nuestra aplicación. Dado que las capas son más “maleables” que los niveles, encajaremos las distintas capas lógicas dentro de los niveles del sistema. Generalizando existen dos posibilidades, despliegue distribuido y despliegue no distribuido.


Slide 23


Tras decidir qué tipo de aplicación desarrollaremos y cuál será su topología de despliegue llega el momento de diseñar la arquitectura lógica de la aplicación. Para ello emplearemos en la medida de lo posible un conjunto de estilos arquitecturales conocidos. Los estilos arquitecturales son “patrones” de nivel de aplicación que definen un aspecto del sistema que estamos diseñando y representan una forma estándar de definir o implementar dicho aspecto.


Slide 24


La diferencia entre un estilo arquitectural y un patrón de diseño es el nivel de abstracción, es decir, un patrón de diseño da una especificación concreta de cómo organizar las clases y la interacción entre objetos, mientras que un estilo arquitectural da una serie de indicaciones sobre qué se debe y qué no se debe hacer en un determinado aspecto del sistema


Slide 25

Relación de abstracción entre estilos y patrones


Slide 26

Diseño Arquitectónico Del Software 6m304y

Overview 6h3y3j

More details h6z72

Related Documents 543cg

Utilizacion Del Software "sahara" 2x3o5s

Tratamiento Contable Del Software 452h1x

Proteccion Legal Del Software 5x3p1t

Revisiones Del Software 1j2p6q

Aplicaciones Del Software Scada 2p445f

Implementacion Del Software Mp8 3e425s

More Documents from "Carlos Vega" 105t16

11482j

11482j

Ministerios Aldazabal 71155z

Ficha Comb I 9123h

11482j

11482j