diseño de software y diseño arquitectónico_ppt

8/18/2019 Diseño de Software y Diseño Arquitectónico_ppt

1/37

DISEÑO DE SOFTWARE YDISEÑO ARQUITECTÓNIC


2/37

CONCEPTOS DE DISEÑO

¿Qué es el diseño? Es donde se está con un pie en dos mundos-el de latecnología y el de las personas y los propósitos humanos-que tratan deunificarse…

Vitruvio, romano crítico de arquitectura, afirmaba que los edificios bien diseñadoseran aquellos que tenían resistencia, funcionalidad y belleza.

El diseño del software cambia continuamente, conforme evolucionan los

nuevos métodos, surgen mejores análisis y se obtiene una compresión másamplia.


3/37

DISEÑO EN EL CONTEXTO DE LAINGENIERÍA DE SOFTWARE

El diseño de software comienza una vez que se han analizado y modelado losrequerimientos, es la última acción de la ingeniería de software dentro de laactividad de modelado y prepara la etapa de construcción (generación yprueba de código).

La importancia del diseño de software se reúne en una palabra: calidad . Eldiseño es el sitio en el que se introduce calidad en la ingeniería de software.


4/37

EL PROCESO DE DISEÑO

El diseño de software es un proceso iterativo por medio del cual se traducenlos requerimientos en un “plano” para construir el software.

A medida que tienen lugar las iteraciones del diseño, las mejoras posterioresconducen a niveles menores de abstracción. Éstos también pueden rastrearsehasta los requerimientos, pero la conexión es más sutil.


5/37

LINEAMIENTOS Y ATRIBUTOS DE LACALIDAD DE SOFTWARE

A través del proceso de diseño se evalúa la calidad de éste de acuerdo con laserie de revisiones técnicas. McGlaughlin [McG91] sugiere tres característicasque funcionan como guía para evaluar un buen diseño:

Implementar todos los

requerimientos explícitos ydar cabida a todos losrequerimientos implícitosque se desean.

Ser una guía legible y

comprensible para quienesgeneran el código y paralos que lo prueban y danel apoyo posterior.

Proporcionar el panoramacompleto del software, y

abordar los dominios delos datos, las funciones y elcomportamiento desde elpunto de vista de laimplementación.


6/37

LA EVOLUCIÓN DEL DISEÑO DESOFTWARE

La evolución del diseño del software es un proceso continuo que ya hacubierto casi seis décadas.

Sin importar el método de diseño que se utilice, debe aplicarse un conjunto deconceptos básicos al diseño en el nivel de datos, arquitectura, interfaz ycomponente. En las secciones que siguen se estudian estos conceptos.


7/37

CONCEPTOS DE DISEÑO

Durante la historia de la ingeniería de software, ha evolucionado un conjuntode conceptos fundamentales sobre su diseño.

Todos ayudan a responder las preguntas siguientes:

¿Qué criterios se usanpara dividir el softwareen sus componentes

individuales?

¿Cómo se extraen losdetalles de la función o

la estructura de datosde la representación

conceptual delsoftware?

¿Cuáles son los

criterios uniformes quedefinen la calidadtécnica de un diseño

de software?


8/37

CONCEPTO DE DISEÑOABSTRACCIÓN

Cuando se considera una solución modular para cualquier problema, esposible plantear muchos niveles de abstracción.

En el más elevado se enuncia una

solución en términos gruesos conel uso del lenguaje del ambientedel problema.

En niveles más bajos deabstracción se da la descripciónmás detallada de la solución


9/37

CONCEPTO DE DISEÑOARQUITECTURA

La arquitectura del software alude a “la estructura general de éste y a las formas en las queésta da integridad conceptual a un sistema” .

Shaw y Garlan describen un conjunto de propiedades que deben especificarse como partedel diseño de la arquitectura:

Propiedades estructurales

Propiedades extra funcionales

Familias de sistemas relacionados


10/37

CONCEPTO DE DISEÑOPATRONES

“Es una mezcla con nombre propio de puntos de vista que contienen la esencia de unasolución demostrada para un problema recurrente dentro de cierto contexto de necesidadesen competencia” .

El objetivo de cada patrón de diseño es proporcionar una descripción que permita a undiseñador determinar :

1) si el patrón es aplicable al trabajo en cuestión,

2) si puede volverse a usar (con lo que se ahorra tiempo de diseño)

3) si sirve como guía para desarrollar un patrón distinto en funciones o estructura.


11/37

CONCEPTO DE DISEÑODIVISION DE PROBLEMAS

La división de problemas es un concepto de diseño que sugiere que cualquierproblema complejo puede manejarse con más facilidad si se subdivide enelementos susceptibles de resolverse u optimizarse de manera independiente. .

.Un problema es una característica o comportamiento que se especifica en elmodelo de los requerimientos para el software.

También se concluye que cuando se combinan dos problemas, con frecuencia lacomplejidad percibida es mayor que la suma de la complejidad tomada porseparado. Esto lleva a la estrategia de divide y vencerás.


12/37

CONCEPTO DE DISEÑOMODULARIDAD

La modularidad es la manifestación más común de la división de problemas. El software se divide en componentes con nombres distintos y abordables por

separado, en ocasiones llamados módulos , que se integran para satisfacer losrequerimientos del problema.


13/37

CONCEPTO DE DISEÑOOCULTAMIENTO DE INFORMACIÓN

El ocultamiento implica que la modularidad efectiva se logra definiendo unconjunto de módulos independientes que intercambien sólo aquellainformación necesaria para lograr la función del software.

El uso del ocultamiento de información como criterio de diseño para lossistemas modulares proporciona los máximos beneficios cuando se requiere

hacer modificaciones durante las pruebas, y más adelante, al darmantenimiento al software.


14/37

CONCEPTO DE DISEÑOINDEPENDENCIA FUNCIONAL

El concepto de independencia funcional es resultado directo de la separaciónde problemas y de los conceptos de abstracción y ocultamiento deinformación.

La independencia se evalúa con el uso de dos criterios cualitativos: la cohesióny el acoplamiento.


15/37

CONCEPTO DE DISEÑOREFINAMIENTO

Un programa se elabora por medio del refinamiento sucesivo de los detallesdel procedimiento.

En realidad, el refinamiento es un proceso de elaboración. Inicia con unenunciado de la función (o descripción de la información), definida en un nivelde abstracción alto.

La abstracción y el refinamiento son conceptos complementarios.


16/37

CONCEPTO DE DISEÑOASPECTOS

Un aspecto es una representación de una preocupación de interferencia.

Es importante identificar aspectos, de modo que el diseño les pueda daracomodo conforme sucede el refinamiento y la división en módulos.

En un contexto ideal, un aspecto se implementa como módulo (componente)separado y no como fragmentos de software “dispersos” o “regados” enmuchos componentes [Ban06].


17/37

CONCEPTO DE DISEÑOREDISEÑO

Una actividad de diseño importante que se sugiere para muchos métodoságiles es el rediseño, técnica de reorganización que simplifica el diseño (ocódigo) de un componente sin cambiar su función o comportamiento.

Cuando se rediseña el software, se examina el diseño existente en busca deredundancias, elementos de diseño no utilizados, algoritmos ineficientes o

innecesarios, estructuras de datos mal construidas o inapropiadas y cualquierotra falla del diseño que pueda corregirse para obtener un diseño mejor.


18/37

CONCEPTO DE DISEÑO ORIENTADO A OBJETOSCLASES DE DISEÑO

Clases de usuario de la interfaz Definen todas las abstracciones necesariaspara la interacción humano-computadora (IHC)

Clases de l dominio de negocios Es frecuente que sean refinamientos de lasclases de análisis definidas antes.

Clases de proceso Implantan abstracciones de negocios de bajo nivel que serequieren para administrar por completo las clases de dominio de negocios.

Clases persistentes Representan almacenamientos de datos (por ejemplo, unabase de datos) que persistirán más allá de la ejecución del software.

Clases de sistemas

Implantan las funciones de administración y control delsoftware que permiten que el sistema opere y se comunique dentro de suambiente de computación y con el mundo exterior.


19/37

EL MODELO DEL DISEÑO


20/37

DISEÑO ARQUITECTONICO

El diseño arquitectónico es la primera etapa en el proceso de diseño. Bass y otros (Bass et al., 2003) señalan tres ventajas de diseñar explícitamente y

documentar la arquitectura del software:

Comunicación con los

stakeholders

Análisis del sistema

Reutilización a g ran

escala


21/37


Hofmeister y otros (Hofmeister et al., 2000) ponen de manifiesto cómo lasetapas del diseño arquitectónico fuerzan a los diseñadores del software aconsiderar aspectos de diseño claves en etapas tempranas del proceso.

El estilo y estructura particulares elegidos para una aplicación puede, por lotanto, depender de los requerimientos no funcionales del sistema:

Rendimiento Protección Seguridad

Disponibilidad Mantenibilidad


22/37



23/37

DECISIONES DE DISEÑOARQUITECTÓNICO

El diseño arquitectónico es un proceso creativo en el que se intenta establecer unaorganización del sistema que satisfaga los requerimientos funcionales y no funcionales delpropio sistema.

los arquitectos del sistema tienen que responder a las siguientes cuestiones fundamentales:

¿Existe una arquitectura de aplicación genérica que pueda actuar como una plantilla para el sistemaque se están diseñando?

¿Cómo se distribuirá el sistema entre varios procesadores?

¿Qué estilo o estilos arquitectónicos son apropiados para el sistema?

¿Cuál será la aproximación fundamental utilizada para estructurar el sistema?

¿Cómo se descompondrán en módulos las unidades estructurales del sistema?

¿Qué estrategia se usará para controlar el funcionamiento de las unidades del sistema?

¿Cómo se evaluará el diseño arquitectónico?

¿Cómo debería documentarse la arquitectura del sistema?


24/37

DECISIONES DE DISEÑOARQUITECTÓNICO

El resultado del proceso de diseño arquitectónico es un documento de diseñoarquitectónico.

Los modelos arquitectónicos que pueden desarrollarse pueden incluir:

Un modelo

estructural estático

Un modelo de

proceso dinámico

Un modelo de

interfaz

Modelos de

relaciones

Un modelo de

distribución


25/37

ORGANIZACIÓN DEL SISTEMA

La organización de un sistema refleja la estrategia básica usada paraestructurar dicho sistema.

En esta sección, se incluyen tres estilos organizacionales ampliamente usados:un estilo de

repositorio de datos

, un estilo de servicios y servidores

compartidos y una máquina abstracta o estilo por capas en donde el sistemase organiza en un conjunto de capas funcionales.


26/37

El MODELO DE REPOSITORIO

Los subsistemas que forman un sistema deben intercambiar información paraque puedan trabajar conjuntamente de forma efectiva. Esto se puedeconseguir de dos formas fundamentales:

Todos los datos compartidos se almacenan en una base de datos central a la quepuede acceder por todos los subsistemas.

Cada subsistema mantiene su propia base de datos. Los datos se intercambian conotros subsistemas mediante el paso de mensajes entre ellos.


27/37

EL MODELO DEL REPOSITORIO


28/37

EL MODELO DE REPOSITORIO

VENTAJAS

Es una forma eficiente de compartirgrandes cantidades de datos.

Los subsistemas que producen datos nonecesitan conocer cómo se utilizan susdatos por otros subsistemas.

Las actividades tales como copias deseguridad, protección, control deacceso y recuperación de errores estáncentralizadas.

El modelo de compartición es visible através del esquema del repositorio.

DESVENTAJAS

Sin embargo, los subsistemas debenestar acordes con el modelo de datosdel repositorio.

Sin embargo, la evolución puede serdifícil a medida que se genera un granvolumen de información de acuerdo

con el modelo de datos establecido. Sin embargo, diferentes subsistemas

pueden tener distintos requerimientosde protección, recuperación y políticasde seguridad.

Sin embargo, puede ser difícil distribuirel repositorio sobre varias máquinas.


29/37

EL MODELO CLIENTE - SERVIDOR

El modelo arquitectónico cliente-servidor es un modelo de sistema en el quedicho sistema se organiza como un conjunto de servicios y servidoresasociados, más unos clientes que acceden y usan los servicios.

Un conjunto de servidores Un conjunto de clientes

Una red


30/37

EL MODELO CLIENTE - SERVIDOR


31/37

EL MODELO DE CAPAS

El modelo de capas de una arquitectura (algunas veces denominada modelode máquina abstracta) organiza el sistema en capas, cada una de las cualesproporciona un conjunto de servicios.

Un ejemplo del modelo de capas es el modelo de referencia OSI de protocolosde red (Zimmermann, 1980).

Otro ejemplo que ha tenido cierta influencia fue propuesto por Buxton

{Buxton, 1980), quien sugirió un modelo de tres capas para un Entorno deSoporte de Programación en Ada (APSE).


32/37

EL MODELO DE CAPAS


33/37

ESTILOS DE DESCOMPOSICIONMODULAR

Después de que se haya elegido la organización del sistema en su totalidad, esnecesario decidir la aproximación a usar para descomponer los subsistemas enmódulos.

No hay una distinción clara entre subsistemas y módulos, pero resulta útilpensar sobre ellos de la siguiente forma:

Un subsistema es un sistema en sí

mismo, cuyo funcionamiento nodepende de los serviciosproporcionados por otros

subsistemas.

Un módulo es normalmente uncomponente de un subsistemaque proporciona uno o másservicios a otros módulos.


34/37

ESTILOS DE DESCOMPOSICIONMODULAR

Hay dos estrategias principales que se pueden usar cuando se descompongaun subsistema en módulos:

Descomposición orientada a

objetos

Descomposición orientada a

flujos de funciones


35/37

DESCOMPOSICION ORIENTADA AOBJETOS


36/37

DESCOMPOSICION ORIENTADA A

FLUJOS DE FUNCIONES


37/37

diseño de software y diseño arquitectónico_ppt

Documents