Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

DISEÑO ARQUITECTÓNICO

No description
by

Gloria Molina

on 25 July 2015

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of DISEÑO ARQUITECTÓNICO

DISEÑO ARQUITECTÓNICO
Decisiones del Diseño Arquitectónico
Ventajas de diseñar y documentar la arquitectura del software:
Comunicación con los stakeholders.
Análisis del sistema.
Reutilización a gran escala.
El Modelo de Repositorio
El Modelo Cliente - Servidor
Los clientes acceden a los servicios proporcionados por un servidor a través de llamadas a procedimientos remotos usando un protocolo de petición-respuesta.
Patrones arquitectónicos
Conjuntos de herramientas CASE se han desarrollado alrededor de un repositorio compartido.
El Modelo en Capas
Vistas arquitectónicas
Primera etapa en el proceso de diseño.
Da como resultado una descripción de la arquitectura del software.
Representa un enlace crítico entre los procesos de ingeniería de diseño y de requerimientos.
Oculta detalles y permite a los diseñadores centrarse en las abstracciones clave del sistema.
Mantenibilidad.
Componentes independientes de grano fino que puedan modificarse con facilidad - Productores de datos separados de los consumidores - Evitar estructuras de datos compartidas.
El estilo y estructura particulares elegidos para un sistema dependería de los requerimientos no funcionales críticos del sistema:
Rendimiento.
Pocos subsistemas - poca comunicación entre ellos- Uso de componentes de grano grueso.
Protección.
Arquitectura en capas - recursos más críticos en las capas más internas - validación de seguridad de alto nivel en dichas capas.
Seguridad.
Las operaciones relacionadas con la seguridad localizadas en un único subsistema.
Existe un conflicto potencial entre algunas de estas arquitecturas.
Un diseño de un subsistema es una descomposición abstracta de un sistema en componentes de grano grueso.
Los diagramas de bloques se usan a menudo para describir diseños de subsistemas.
Los componentes individuales implementan los requerimientos funcionales del sistema, los no funcionales dependen de la arquitectura del sistema.
Proceso creativo - decisiones en lugar de actividades - establecer una organización del sistema que satisfaga sus requerimientos.
Los arquitectos del sistema tienen que responder a las siguientes cuestiones:
¿Existe una arquitectura de aplicación genérica que pueda actuar como una plantilla para el sistema que se están diseñando?
¿Cómo se distribuirá el sistema entre varios procesadores?
¿Qué patrón arquitectónico o estilos pueden usarse?
¿Cuál será la aproximación fundamental utilizada para estructurar el sistema?
¿Cómo se descompondrán los compoenentes estructurales en sub-componentes?
¿Qué estrategia se usará para controlar el funcionamiento de las unidades del sistema?
¿Qué organización arquitectónica es la mejor para entregar los requerimientos no funcionales del sistema?
¿Cómo se evaluará el diseño arquitectónico?
¿Cómo debería documentarse la arquitectura del sistema?
Sistemas en el mismo dominio suelen tener arquitecturas similares.
Elegir una arquitectura distribuida es una decisión clave que afecta al rendimiento y la fiabilidad del sistema.
Una arquitectura puede basarse en un estilo o patrón arquitectónico particular conociendo sus aplicaciones, ventajas e inconvenientes.
Como resultado - documento de diseño arquitectónico - representaciones gráficas con texto descriptivo.
Los modelos gráficos del sistema presentan diferentes perspectivas de la arquitectura.
Existen los Lenguajes de descripción de arquitecturas (ADLs) - Solo comprendidos por expertos del lenguaje.
UML y modelos informales son las notaciones mas comunes.
La idea de patrones como una forma de presentar, compartir y reutilizar conocimiento sobre sistemas software es actualmente muy utilizado.
Los patrones arquitectónicos fueron propuestos en 1990 bajo el nombre de estilos arquitectónicos - Estilizada descripción abstracta de buenas prácticas.
Los subsistemas deben intercambiar información para trabajar de forma efectiva. Esto es puede conseguir de dos formas fundamentales:
Todos los datos compartidos se almacenan en una base de datos central, modelo repositorio, subsistemas con gran cantidad de datos.
Cada subsistema mantiene su propia base de datos intercambiando datos entre ellos mediante el paso de mensajes.
El modelo de repositorio es adecuado para aplicaciones en las que los datos son generados por un subsistema y usados por otro.
Una aproximación alternativa se deriva de los sistemas de AI (Inteligencia Artificial) que usan un modelo de pizarra (blackboard), el cual activa a los subsistemas cuando están disponibles ciertos datos. Esto es adecuado cuando el repositorio de datos está poco estructurado. Las decisiones sobre qué herramienta se tiene que activar solo puede realizarse cuando los datos han sido analizados.
Ventajas
Es una forma eficiente de compartir grandes cantidades de datos.
Los subsistemas que producen datos no necesitan conocer cómo se utilizan sus datos por otros subsistemas.
Las actividades tales como copias de seguridad, protección, control de acceso y recuperación de errores están centralizadas.
El modelo de compartición es visible a través del esquema del repositorio .
En el modelo de compartición el repositorio es pasivo y el control es responsabilidad de los subsistemas que utilizan el repositorio.
Los subsistemas deben estar acordes con el modelo de datos del repositorio. El rendimiento puede verse afectado de forma adversa por este compromiso.
La evolución puede ser difícil a medida que se genera un gran volumen de información.
Diferentes subsistemas pueden tener distintos requerimientos de protección, recuperación y políticas de seguridad.
Puede ser difícil distribuir el repositorio sobre varias máquinas.
Desventajas
Es un modelo de sistema en el que dicho sistema se organiza como un conjunto de servicios y servidores asociados, más unos clientes que acceden y usan los servicios.
Los principales componentes de este modelo son:
Conjunto de servidores que ofrecen servicios a otros subsistemas.
Conjunto de clientes que llaman a los servicios ofrecidos por los servidores.
Una red que permite a los clientes acceder a estos servicios. Generalmente se implementan como sistemas distribuidos.
Los clientes pueden conocer los nombres de los servidores disponibles y los servicios que éstos proporcionan.
Los servidores no necesitan conocer la identidad ni cantidad de clientes.
Puede ser necesario realizar cambios a los clientes y servidores existentes para obtener los mayores beneficios de la integración de un nuevo servidor.
Los modelos de datos específicos pueden establecerse para cada servidor con el fin de optimizar su rendimiento.
XML es una forma ineficiente de representar los datos; por lo tanto, su uso puede provocar problemas de rendimiento.
Arquitectura distribuida.
Es fácil añadir un nuevo servidor e integrarlo con el resto del sistema.
Es fácil actualizar los servidores sin afectar al resto del sistema.
Si se usa una representación de los datos basada en XML, puede ser relativamente simple realizar conversiones de un esquema a otro.
Ventajas
Desventaja
También llamado modelo de máquina abstracta.
Organiza el sistema en capas que proporciona un conjunto de servicios.
Cada capa puede pensarse como una máquina abstracta cuyo lenguaje máquina se define por los servicios proporcionados por la capa.
La estructuración de los sistemas puede resultar difícil.
El rendimiento baja debido a que se requieren múltiples niveles de interpretación de comandos.
Los servicios requeridos pueden tener que «atravesar» las capas adyacentes para acceder a los servicios de los niveles inferiores.
Soporta el desarrollo incremental de sistemas.
Soporta bien los cambios y es portable.
Puede reemplazarse una capa por otra capa equivalente.
Cuando las interfaces de la capa cambian solamente se ve afectada la capa adyacente.
Más fácil proporcionar implementaciones multiplataforma de las aplicaciones de un sistema.
Ventajas
Desventajas
En procesos ágiles - etapa temprana del proceso de desarrollo.
Un desarrollo incremental de la arquitectura no es exitoso por el costo de la refactorización.
La especificación de sistemas no debería incluir ninguna información del diseño.
Ejemplo diseño arquitectónico
Bass opina que los diagramas de bloques son una representación pobre, no muestran ni tipo de relación ni las propiedades visibles externamente de los componentes.
Niveles de abstracción:
Arquitectura en lo pequeño: Programas individuales - componentes.
Arquitectura en lo grande: Sistemas empresariales complejos - sistemas, programas y componentes.
Las contradicciones entre teoría y practica se da por los modos de uso del modelo arquitectónico:
Para facilitar la discusión sobre el diseño del sistema. (diagrama de bloques).
Para documentar una arquitectura que ha sido diseñada. (Notación mas detallada).
Diagrama de bloques de un sistema robótica de control de empaquetado.
Las vistas o modelos sugeridas por Krutchen son mas conocidas como Modelo de vistas “4+1”:
Vista lógica: Muestra la clave de abstracción en el sistema como objetos o clases de objetos. Debería ser posible relacionar los requerimientos del sistema con entidades en esta vista lógica.
Vista de procesos: Muestra como, en tiempo real, el sistema esta compuesto de procesos interactivos. Es útil para hacer evaluaciones sobre las características no funcionales del sistema.
Vista de desarrollo: Muestra como se descompone el software en componentes que son implementados por un grupo de desarrolladores. Es útil para administradores de software y programadores.
Vista física: Muestra el hardware del sistema y como los componentes están distribuidos a través de procesadores en el sistema. Es útil para ingenieros de sistemas de planificación de la implementación.
Hofmeister sugiere añade la notación de una vista conceptual.
Vista abstracta del sistema que es la base para la descomposición de requerimientos de alto nivel en especificación mas detallada.
Ayuda a tomar decisiones sobre componentes reutilizables y representa una línea de producción mas que un único sistema.
En la práctica, son casi siempre utilizadas durante el proceso de diseño y son útiles para comunicar la esencia del sistema a diferente stakeholders.
Los usuarios de métodos ágiles afirman que la documentación de diseño detallada en su mayoría no es utilizada.
Una excepción son los sistemas críticos donde se requiere un análisis detallado del sistema representado desde todas sus perspectivas.
EJEMPLO PATRON MODELO-VISTA-CONTROLADOR
Este patrón es base de la interacción de la administración en muchos sistemas basados en web.
La descripción del patrón estilizado incluye el nombre del patrón, una breve descripción con un modelo gráfico asociado y un ejemplo del tipo de sistemas donde el patrón es usado. Debería incluirse también información sobre cuando el patrón debería ser usado y sus ventajas y desventajas.
Existen varios patrones o estilos arquitectónicos probados, los más conocidos son:
Arquitectura en capas
Arquitectura de repositorio
Arquitectura cliente-servidor
Se puede realizar evaluaciones comparando el diseño elaborado con modelos arquitectónicos genéricos o de referencia.
La noción de Garlan y Shaw de un estilo arquitectónico incluye las tres siguientes cuestiones de diseño:
Estos estilos o patrones se pueden utilizar juntos o por separado.
Identifica los componentes estructurales y la comunicación entre ellos para organizar y diseñar la arquitectura general del sistema.
Disponibilidad.
Incluir componentes redundantes - poder remplazar y actualizar componentes sin detener el sistema.
Pueden diseñarse diferentes partes del sistema utilizando distintos estilos arquitectónicos.
Elegir la estructura más adecuada que permita satisfacer los requerimientos del sistema.
Decidir la estrategia para descomponer subsistemas en sus componentes o módulos.
Se desarrolla un modelo general de las relaciones de control entre las partes establecidas del sistema.
Full transcript