UNIDAD IV DISEÑO

Diseño e implementación de software

El diseño es el primer paso de la fase de desarrollo de cualquier producto o sistema de ingeniería.
definición: el proceso de aplicar distintas técnicas y principios con el propósito de definir un
dispositivo, proceso o sistema con los suficientes detalles como para permitir su realización física.
El diseño de software es la última acción de la ingeniería correspondientes a la actividad de
modelado, la cual establece una plataforma para la construcción (generación de código y
pruebas).
Cada uno de los elementos de análisis proporciona la información necesaria para crear los cuatro
modelos que se requieren para una especificación completa de diseño.
Modelos de diseño:
Diseño de datos-clase: transforma los modelos de análisis y clases en las clases de diseño y las
estructuras de datos que se requieran para implementar el software. Las relaciones entre clases, los
atributos de las clases y otras notaciones proporcionan la base para la actividad de diseño de
datos.
Diseño arquitectónico: define la relación entre los elementos estructurales más importantes del
software, los estilos arquitectónicos y patrones de diseño que pueden usarse para satisfacer los
requisitos del sistema y las restricciones que afectan la manera en que se pueden implementar los
patrones arquitectónicos.
Diseño de la interfaz: describe la forma en que el software se comunica con los sistemas que
interactúa con él y con los humanos que lo utilizan. Los escenarios de uso y los modelos de
comportamiento proporcionan mucha de la información que se requiere para el diseño de la
interfaz.
Diseño a nivel de componente: transforma los elementos estructurales de la arquitectura del
software en una descripción procedimental de los componentes de éste.
Diseño
Durante el diseño se toman decisiones que afectan al éxito de la construcción del software y la
facilidad con la que se podrá mantener.
La importancia del diseño del software se puede expresar con una sola palabra: CALIDAD
El diseño proporciona las representaciones del software que pueden evaluarse respecto a la
calidad. El diseño de software sirve como fundamento para todas las actividades subsecuentes de
la IS y del soporte del sistema.
Sin diseño se construye un sistema inestable; que fallará en cuanto se realicen cambios pequeños;
que será difícil de probar; cuya calidad no se pueda evaluar sino hasta etapas tardías, cuando
queda poco tiempo y se ha gastado mucho dinero en él.
El proceso de diseño
El diseño del software es un proceso iterativo mediante el cual los requisitos se traducen en un
“plano” para construir el software.
El diseño se representa en un grado alto de abstracción, el cual puede rastrearse de forma directa
hasta conseguir el objetivo específico el sistema y requisitos más detallados de comportamiento,
funcionales y de datos. A medida que ocurren las iteraciones se consigue un refinamiento que
conduce a representaciones de diseño a grados mucho más bajos de abstracción.
A través del proceso de diseño la calidad de éste debe ser evaluada. McGlaughlin sugiere tres
características que sirven como guía en la evaluación de un buen diseño:
 Debe implementar todos los requisitos explícitos contenidos en el modelo de análisis, y debe
ajustarse a todos los requisitos implícitos que desee el cliente.
 Debe ser una guía legible y comprensible para los que generan el código y realizan las
pruebas, así como para quienes dan el soporte (mantenimiento).
 Debe proporcionar una imagen completa del software (identificándose los dominios de
datos, funcional y de comportamiento) desde una perspectiva de implementación.
De hecho cada una de estas características es una meta del proceso de diseño, pero:
¿Cómo alcanzar cada una de ellas?
Directrices de calidad para el diseño
Se presentan las siguientes directrices con el fin de evaluar la calidad de una representación de
diseño:
1. Un diseño debe presentar una estructura arquitectónica que:
a) Se haya creado mediante patrones de diseño reconocibles.
b) La integren componentes que exhiban buenas características de diseño.
c) Pueda implementarse de manera evolutiva
2. Un diseño debe ser modular, esto es, el software deberá dividirse de manera lógica en
elementos o subsistemas.
3. Un diseño debe contener distintas representaciones de los datos, la arquitectura, las
interfaces y los componentes.
4. Un diseño debe conducir a estructuras de datos que sean apropiadas para las clases que
habrán de implementarse.
5. Un diseño debe conducir a componentes que presenten características funcionales
independientes.
6. Un diseño debe conducir a interfaces que reduzcan la complejidad de las conexiones entre
los componentes y el ambiente externo.
7. El diseño debe obtenerse por medio de un método repetible que se base en la información
obtenida durante le análisis de requisitos del software.
8. El diseño debe representarse por medio de una notación que comunique de manera eficaz
su significado.
Esto se puede lograr aplicando principios fundamentales de diseño, una metodología sistemática y
una revisión cuidadosa.
Conceptos de diseño
M. A. Jackson dijo: “El comienzo de la sabiduría para un ingeniero de software es reconocer la
diferencia entre hacer que un programa funcione, y conseguir que lo haga del modo correcto”.
Los conceptos fundamentales de diseño de software ofrecen el marco de trabajo necesario para
hacer las cosas “del modo correcto”.
Abstracción
Es una de las formas fundamentales en las que el humano enfrenta la complejidad (Grady Booch).
La abstracción es el examen selectivo de ciertos aspectos de un problema.
Su finalidad es aislar aquellos aspectos que sean importantes para algún objetivo y suprimir los
aspectos que no lo sean.
La abstracción siempre debe hacerse con algún objetivo prefijado, porque el propósito determina
lo que es y lo que no es importante.
Es posible efectuar muchas abstracciones diferentes de la misma cosa, dependiendo del propósito
para el cual se hagan esas abstracciones.
Cuando se considera una solución modular para cualquier problema, pueden exponerse muchos
grados de abstracción:
 En un alto grado de abstracción, se establece una solución en términos generales, usando el
lenguaje del entorno del problema.
 A medida que nos movemos a través del proceso de diseño, se reduce el nivel de
abstracción proporcionando una descripción más detallada de la solución.
 Finalmente, se alcanza el nivel inferior de abstracción cuando se construye el código.
Conforme cambian los diferentes grados de abstracción se trabaja para crear:
 Abstracciones procedimentales. La cual se refiere a una secuencia de instrucciones que
tiene una función específica y limitada. El nombre de la abstracción procedimental implica
estas funciones pero se omiten detalles específicos. Por ejemplo la palabra abrir para una
puerta; implica una larga secuencia de pasos procedimentales (caminar a la puerta,
alcanzar la manija, darle vuelta a la manija, empujar la puerta, etc.).
 Abstracciones de datos. es una colección nombrada de datos que describen un objeto de
datos, un ejemplo podría ser PUERTA ya que comprende un conjunto de atributos que la
describen (tipo de puerta, dirección de apertura, mecanismo de apertura, peso,
dimensiones).
Arquitectura
En la construcción de edificios, la arquitectura juega un rol central. La arquitectura de un edificio se
describe usando un conjunto de planos, que juntos, representan todos los aspectos del edificio. Ésta
describe el edificio desde diferentes puntos de vista, como electricidad, plomería, estructura, etc.
El arquitecto es la persona encargada del proyecto completo. Es el responsable de asegurar que el
edificio será sólido, costo-efectivo y satisfactorio para el cliente.
La arquitectura del software es similar. Ésta juega el papel central en la ingeniería de software e
involucra el desarrollo de una variedad de vistas de alto nivel del sistema.
La arquitectura del software es el proceso de diseñar la organización global de un sistema software,
incluye la división del software en subsistemas, decisiones de cómo van a interactuar los subsistemas
y determinar sus interfaces.
Los ingenieros de software discuten todos los aspectos del diseño de un sistema en términos del
modelo arquitectónico. Por lo tanto, las decisiones hechas mientras este modelo está siendo
desarrollado, tienen un profundo impacto sobre el resto de las actividades del proceso de diseño. El
modelo arquitectónico es el núcleo del diseño, así que todos los miembros del equipo de desarrollo
necesitan entenderlo.
Hay 4 razones principales por las que es necesario desarrollar un modelo arquitectónico:
1. Permitir un mejor entendimiento del sistema
2. Permitir que la gente trabaje en piezas individuales del sistema en forma aislada.
3. Prepararse para la extensión del sistema.
4. Facilitar la reusabilidad.
Permitir un mejor entendimiento del sistema: Conforme un sistema se va haciendo más y más
complejo, hacerlo entendible es mucho más difícil. Un buen modelo arquitectónico permite que la
gente entienda cómo el sistema trabaja en conjunto, también define los términos que la gente usa
cuando se comunica con los demás acerca de detalles de bajo nivel.
Permitir que la gente trabaje en piezas individuales del sistema en forma aislada: El trabajo de
desarrollo de un sistema de software complejo debe ser distribuido entre una gran cantidad de
gente. La arquitectura permite la planeación y coordinación de este trabajo distribuido. La
arquitectura debe proveer información suficiente para que el trabajo de un individuo o equipo
pueda integrarse más tarde para formar el sistema final. Esta es la razón por la que las interfaces y
las interacciones dinámicas entre los subsistemas son una parte importante de la arquitectura.
Prepararse para la extensión del sistema: Con un modelo arquitectónico completo, se hace más
fácil planear la evolución del sistema. Los subsistemas que se preve serán parte de futuras versiones
pueden ser incluidos en la arquitectura, incluso aunque no sean desarrollados inmediatamente.
Facilitar la reusabilidad: El modelo arquitectónico hace visible a cada componente del sistema.
Analizando la arquitectura podemos descubrir aquellos componentes que puedan ser obtenidos de
proyectos pasados. También se pueden identificar componentes que tengan un alto potencial de
reusabilidad. Hacer una arquitectura tan genérica como sea posible es la clave para asegurar la
reusabilidad.
Contenido de un buen diseño arquitectónico:
 Análisis lógico en los subsistemas, esto se muestra usando diagramas de paquetes.
 La dinámica de interacción entre componentes (en tiempo de ejecución), esto se expresa
usando diagramas de interacción y diagramas de actividades.
 Los datos que serán compartidos entre los subsistemas, se expresa típicamente usando
diagramas de clases.
 Los componentes que existirán en tiempo de ejecución y las máquinas o dispositivos sobre los
cuales estarán localizados, esta información se expresa usando diagrama de componentes o
diagramas de despliegue.
Modularidad
El software se divide en componentes con nombres independientes y que es posible abordar en
forma individual. Estos componentes llamados módulos se integran para satisfacer los requisitos del
problema.
Se ha dicho que la modularidad “es el atributo particular del software que permite que un
programa sea manejable de manera intelectual”.
El software monolítico (un gran programa compuesto de un único módulo) no puede ser entendido
fácilmente por un lector.
Para ilustrar lo anterior consideremos lo siguiente:
Sea C(x) una función que define la complejidad de un problema x.
E(x) una función que define el esfuerzo (en tiempo) requerido para resolver un problema x.
Para 2 problemas p1 y p2, si
C(p1) > C(p2) entonces E(p1) > E(p2)
Obviamente se tarda más tiempo en resolver un problema difícil.
Se ha encontrado otra propiedad interesante:
C(p1+p2) > C(p1) + C(p2)
Esto indica que la complejidad de un problema compuesto por p1 y p2 es mayor que la
complejidad total considerando cada problema por separado. Por lo tanto:
E(p1+p2) > E(p1) + E(p2)
Esto nos lleva a la conclusión del tipo “divide y vencerás”, es más fácil resolver un problema cuando
se divide en trozos más manejables.
De acuerdo a las desigualdades anteriores nos hacemos la siguiente pregunta:
Si partimos el software indefinidamente, ¿el esfuerzo requerido para desarrollarlo sería
insignificantemente pequeño?
Esta afirmación no es cierta, desgraciadamente intervienen otros factores, mientras más módulos
haya, el número de interfaces crece y se hace más complicado integrar los módulos.
Un diseño y el programa resultante se modularizan de manera que el desarrollo se pueda planear
con mayor facilidad; se puedan definir y entregar incrementos del software; los cambios puedan
ajustarse con mayor facilidad; las pruebas y la eliminación de errores se pueda hacer con mayor
eficiencia, y el mantenimiento se pueda realizar sin efectos colaterales de consideración.
Ocultamiento de Información
El concepto de modularidad conduce a todos los diseñadores de software a plantearse una
pregunta fundamental: ¿Cómo puede descomponerse una solución de software para obtener el
mejor conjunto de módulos?
El principio de ocultamiento de la información sugiere que los módulos deben especificarse y
diseñarse de manera que la información (procedimiento y datos) que está dentro del módulo sea
inaccesible para otros módulos que no necesitan esa información.
El ocultamiento implica que puede conseguirse una modularidad efectiva al definir un conjunto de
módulos independientes que se comuniquen entre si y que intercambien sólo la información
necesaria para lograr la función del software.
El ocultamiento define y fortalece las restricciones de acceso para los detalles de procedimiento
dentro de un módulo y para cualquier estructura de datos que utilice el módulo.
El uso del ocultamiento de información como un criterio de diseño para sistemas modulares,
proporciona los mayores beneficios cuando se requieren modificaciones, durante el proceso de
prueba y después durante le mantenimiento.
Esto significa que como la mayoría de los datos y procedimientos estarán ocultos para las otras
partes del software, será menos probable que los errores introducidos inadvertidamente durante las
modificaciones se propaguen a otros lugares del software.
Independencia Funcional
El concepto de independencia funcional (IF) es la suma directa de la modularidad y de los
conceptos de abstracción y ocultamiento de información.
La IF se consigue al desarrollar módulos con una función “determinante” y una “aversión” a la
interacción excesiva con otros módulos.
Esto es, diseñar el software de tal manera que cada módulo aborde una subfunción específica de
los requisitos y tenga una sola interfaz.
¿Por qué es importante la independencia?
El software con una modularidad efectiva, es decir con módulos independientes, es más fácil de
desarrollar porque la función se puede fraccionar y las interfaces se simplifican (por ejemplo:
cuando el desarrollo se realiza en equipo).
Los módulos independientes son más fáciles de mantener y probar porque se limitan los efectos
secundarios que originan las modificaciones al diseño o al código, se reduce la propagación de
errores.
Es posible emplear módulos reutilizables.
En resumen la independencia funcional es la clave para lograr la calidad del software.
La independencia funcional se evalúa aplicando dos criterios cualitativos:
 Cohesión
 Acoplamiento.
Refinamiento
El refinamiento es una estrategia de diseño descendente que propuso inicialmente Niklaus Wirth.
El refinamiento es un proceso de elaboración. Se inicia en el enunciado de una función (o una
descripción de datos) que se define con un alto grado de abstracción, es decir el enunciado
describe la función o los datos de manera conceptual pero no proporciona información acerca de
los trabajos internos de la función o de la estructura interna de los datos.
El refinamiento hace que el diseñador trabaje sobre el enunciado original y que conforme se realiza
cada refinamiento (elaboración) sucesivo proporcione más y más detalles.
Independencia Funcional
La abstracción y el refinamiento son conceptos complementarios.
La abstracción le permite al diseñador especificar procedimientos y datos sin considerar detalles de
grado menor.
El refinamiento ayuda al diseñador a revelar los detalles de grado menor mientras se realiza el
diseño.
El modelo de diseño
El modelo de diseño puede verse en dos dimensiones diferentes:
 La dimensión del proceso: indica la evolución del modelo de diseño conforme se ejecutan las
tareas de diseño como una parte del proceso del software.
 La dimensión de abstracción: representa el grado de detalle a medida que cada elemento
del modelo de análisis se transforma en un equivalente del diseño y después se refina de una
manera iterativa.
En la figura se ilustra lo anterior.
Elementos del diseño de datos
El diseño de datos crea un modelo de datos o información que se representa con un alto grado de
abstracción. Después este modelo de datos se refina en representaciones que tengan una
implementación específica y que puedan procesarse mediante el sistema basado en
computadora.
El diseño de datos tiene una profunda influencia sobre la arquitectura de software que los debe
procesar.
La estructura de los datos siempre ha sido una parte importante del diseño de software:
 Al nivel de los componentes del sistema, las estructuras de datos y los algoritmos con que se
manipulen son esenciales para la creación de aplicaciones de alta calidad.
 Al nivel de la aplicación, la traducción de un modelo de datos a una base de datos es
esencial para alcanzar los objetivos de negocio de un sistema.
 Al nivel de negocios, la colección de información almacenada en bases de datos dispersas y
reorganizadas en un “almacén de datos” permite la explotación de datos o el
descubrimiento de un conocimiento que puede tener un impacto sobre el éxito del mismo
negocio.
En cada caso, el diseño de datos juega un papel importante.
Elementos del diseño Arquitectónico
Los elementos del diseño arquitectónico dan una visión general del software.
El modelo arquitectónico se obtiene a partir de 3 fuentes:
1. La información acerca del dominio de la aplicación.
2. Los elementos de análisis específico (DFD, diagramas de clases y sus relaciones)
3. La disponibilidad de patrones y estilos arquitectónicos.
Elementos de diseño de Interfaz
Los elementos del diseño de la interfaz muestran como fluye la información hacia el sistema o fuera
del sistema y cómo éste está comunicado entre los componentes definidos como parte de la
arquitectura.
Existen tres elementos importantes del diseño de interfaz:
1. La interfaz con el usuario.
2. Interfaces externas a otros sistemas, artefactos, redes u otros productores o consumidores de
información.
3. Interfaces internas entre varios componentes de diseño.
Estos elementos de diseño de interfaz permiten al software comunicarse de manera externa y
permiten la comunicación y colaboración interna entre los componentes que integran la
arquitectura del software.
Elementos de diseño al nivel de componentes
El diseño al nivel de componentes para software describe por completo el detalle interno de cada
componente del software.
Para lograrlo el diseño el diseño al nivel de componente define estructuras de datos para todos los
objetos locales, así como detalle algorítmico para todo el procesamiento que ocurre dentro de un
componente y una interfaz que permite el acceso a todas las operaciones de los componentes
(comportamientos).
Diagrama de componente en UML para ManejoSensor

En esta figura se representa un componente llamado ManejoSensor. El componente está

conectado a una clase llamada Sensor, la cual está asignada al componente mediante una flecha
punteada. El componente ManejoSensor realiza todas las funciones asociadas con los sensores
entre las que se encuentran monitoreo y configuración.
Elementos de diseño a nivel de despliegue
Los elementos de diseño a nivel del despliegue indican como se ubicarán las funcionalidad y los
subsistemas dentro del entorno computacional físico que soportará al software.
Por ejemplo, los elementos de HogarSeguro están configurados para operar dentro de tres entornos
de computación primarios: una PC doméstica, el panel de control de HogarSeguro y un servidor
ubicado en CPI Corp. (lo que proporciona acceso al sistema a través de Internet).
Diagrama de despliegue en UML para HogarSeguro
Se muestran tres ambientes computacionales. Se indican los subsistemas (funcionalidad) que se
alojan dentro de cada elemento de cómputo.
Por ejemplo la computadora personal aloja subsistemas que implementan seguridad, vigilancia,
características de comunicación y un subsistema de acceso externo para controlar los accesos al
sistema HogarSeguro. Cada subsistema debe ser elaborado para indicar los componentes que
implementa.
Diseño de software basado en patrones
Conforme se obtiene experiencia en el desarrollo de software OO, se empieza a notar que muchas
partes de los diseños reaparecen, con solamente algunos insignificantes cambios, en muchos
diferentes sistemas o subsistemas. Estos aspectos recurrentes de diseño son llamados patrones de
diseño.
Muchos de ellos han sido documentados sistemáticamente para que todos lo desarrolladores de
software los usen.
Definiciones:
 Un patrón es un par problema/solución con nombre que se puede aplicar a nuevos
contextos, con consejos acerca de cómo aplicarlo en nuevas situaciones.
 Un patrón es el resultado de una solución reusable para un problema general encontrado en
un contexto particular.
Un patrón de diseño puede describirse empleando la plantilla que se muestra a continuación:
Plantilla del patrón de diseño
Nombre del patrón: describe la esencia del patrón en un nombre corto pero expresivo.
Intención: Describe el patrón y lo que hace.
También-conocido-como: lista de los sinónimos para el patrón.
Motivación: proporciona un ejemplo del problema.
Aplicabilidad: situaciones específicas de diseño en las cuales es aplicable el patrón
Estructura: describe las clases que se requieren para implementar el patrón.
Participantes: describe las responsabilidades de las clases que se requieren para implementar el
patrón.
Colaboraciones: describe cómo colaboran los participantes para llevar a cabo sus
responsabilidades.
Consecuencias: describe las “fuerzas de diseño” que afectan al patrón y los intercambios
potenciales que deben considerarse cuando se implementa el patrón.
Patrones relacionados: patrones de diseño relacionados mediante referencias cruzadas.
Las fuerzas de diseño son aquellas características del problema (requisitos no funcionales) y aquellos
atributos de la solución que restringen la forma en se puede desarrollar el diseño.
Un buen patrón debe ser tan general como sea posible, conteniendo una solución que ha sido
provista para resolver el problema efectivamente en el contexto indicado.
El patrón debe ser descrito en una forma fácil de entender, de modo que la gente pueda
determinar cuando y como usarlo. Estudiar patrones es una manera efectiva para aprender de la
experiencia de otros.
Diseño Arquitectónico
El diseño arquitectónico representa la estructura de datos y los componentes de programa
necesarios para construir un sistema computacional. Asume el estilo arquitectónico que tomará el
sistema y las interrelaciones entre todos los componentes arquitectónicos de un sistema.
La arquitectura del software de un programa o sistema de cómputo es la estructura del sistema, que
incluyen los componentes del software, las propiedades visibles externamente de los componentes y
las relaciones entre ellos.
La arquitectura es la representación que permite que un ingeniero de software:
1. Analice la efectividad del diseño para cumplir con los requisitos establecidos.
2. Considere opciones arquitectónicas en una etapa en que aún resulta relativamente fácil
hacer cambios al diseño y,
3. Reduzca los riesgos asociados con la construcción del software.
Razones claves por las cuales la arquitectura del software es importante:
 Las representaciones de la arquitectura del software permiten la comunicación entre todas
las partes (participantes) interesadas en el desarrollo del sistema.
 La arquitectura destaca las decisiones iníciales relacionadas con el diseño que tendrán un
impacto profundo en todo el trabajo de la IS que le sigue, y también en el éxito final del
sistema.
 La arquitectura constituye un modelo relativamente pequeño e intelectualmente
comprensible de cómo está estructurado el sistema y como trabajan juntos sus componentes.
Estilos y patrones arquitectónicos
Un estilo arquitectónico es un mecanismo descriptivo para diferenciar una construcción de otra (en
el contexto de la construcción de edificios). Pero algo más importante es que el estilo
arquitectónico es una plantilla para la construcción, resultará necesario proporcionar mayores
detalles, agregar características personales, etc. Pero el estilo que se haya elegido es el que guía el
trabajo del constructor.
El software que se construye para sistemas de computo puede mostrar uno o muchos estilos
arquitectónicos.
Cada estilo describe una categoría de sistemas que abarca:
1. Un conjunto de componentes que realizan una función requerida por el sistema.
2. Un conjunto de conectores que permiten la comunicación, coordinación y cooperación
entre los componentes.
3. Restricciones que definen cómo se integran los componentes para formar el sistema.
4. Modelos semánticos que permiten a un diseñador, mediante el análisis de las propiedades
conocidas de las partes que lo integran, comprender las propiedades generales de un
sistema.
Un estilo arquitectónico es una transformación impuesta al diseño de todo un sistema.
El objetivo es establecer una arquitectura para todos los componentes del sistema.
Un patrón arquitectónico también impone una transformación en el diseño de una arquitectura. Sin
embargo un patrón difiere de un estilo en varios elementos fundamentales:
1. El alcance de un patrón es menor, ya que se concentra en un aspecto, en lugar de hacerlo
en toda la arquitectura.
 2. Un patrón impone una regla sobre la arquitectura pues describe la manera en que el
software manejará un aspecto de su funcionalidad al nivel de la infraestructura
(concurrencia).
3. Los patrones arquitectónicos tienden a abarcar aspectos específicos del comportamiento
dentro del contexto de la arquitectura.
Los patrones se usan junto con un estilo arquitectónico para determinar la forma de la estructura
general de un sistema.
Arquitecturas de uso común en el software
Arquitectura centrada en datos: en el centro de esta arquitectura se encuentra un almacén de
datos (base de datos o archivos); otros componentes tienen acceso a él y cuentan con la opción
de agregar, eliminar o modificar los datos de ese almacén. Una arquitectura centrada en datos
promueve la capacidad de integración, esto significa que es posible cambiar componentes
existentes y agregar nuevos componentes cliente a la arquitectura sin ningún problema, ya que los
componentes cliente operan de manera independiente.
Arquitectura centrada en datos

Arquitectura de flujo de datos: Esta arquitectura se aplica cuando los datos de entrada se habrán
de transformar en datos de salida mediante una serie de componentes para el cálculo o la
manipulación. Se representa mediante una estructura de tuberías y filtros, en la que los
componentes se denominan filtros que están conectados por tuberías que transmiten datos de un
componente al siguiente. Cada filtro funciona sin tomar en cuenta el flujo de los componentes
(ascendente o descendente), está diseñado para esperar la entrada de datos con cierta forma y
producir su salida de una manera específica. No es necesario que un filtro conozca el
funcionamiento de los filtros vecinos.
Arquitectura de flujo de datos

Tuberías y Filtros
Arquitectura de llamada de retorno: Este estilo permite que un diseñador de software obtenga una
estructura de programa relativamente fácil de modificar. Existen dos sub-estilos:
 Arquitectura de programa principal/subprograma: esta estructura clásica separa la función
en una jerarquía de control donde un programa “principal” invoca a varios componentes de
programa, que a su vez pueden invocar a otros componentes.
 Arquitectura de llamada de procedimiento remoto: los componentes de una arquitectura de
programa principal/subprograma se distribuyen entre varias computadoras de una red.
Arquitectura de programa principal/subprograma

Arquitectura orientada a objetos: Los componentes de un sistema encapsulan los datos y las
operaciones que deben aplicarse para manipular los datos. La comunicación y coordinación entre
componentes se consigue mediante el paso de mensajes.
Arquitectura estratificada: Aquí se definen varias capas, cada una de ellas realiza operaciones que
se acercan progresivamente al conjunto de instrucciones de la máquina. En la capa externa los
componentes sirven a las operaciones de interfaz de usuario. En la capa interna los componentes
sirven como interfaz con el sistema operativo. Las capas intermedias proporcionan servicios de
utilería y de software de aplicaciones.
Arquitectura estratificada
Estos estilos arquitectónicos son algunos de los que se dispone para diseñar el software. El estilo
arquitectónico o la combinación de estilos se eligen dependiendo de las características y
restricciones del sistema que se habrá de construir. En muchos casos será apropiado más de un
estilo. Por ejemplo en muchas aplicaciones de base de datos se combina un estilo por capas
(apropiado para casi todos los sistemas) con una arquitectura centrada en datos.