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 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 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. 2. 3. 4.
Permitir un mejor entendimiento del sistema Permitir que la gente trabaje en piezas individuales del sistema en forma aislada. Prepararse para la extensión del sistema. 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 res olver 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:
responsabilidades.
describe cómo colaboran los participantes para llevar a cabo sus
Consecuencias: describe las
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. “fuerzas de diseño”
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. arquitectura constituye un modelo relativamente pequeño e intelectualmente La 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.
