Después de elegir la organización del sistema en su totalidad, debemos decidir cómo descomponer los subsistemas en módulos. No existe una distinción rígida entre la organización del sistema y la descomposición modular. Sin embargo, los componentes de los módulos son normalmente más pequeños, lo que permite usar estilos alternativos de descomposición. Estilos de descomposición modular
1. Un subsistema es un sistema en sí mismo. Su funcionamiento no depende de los servicios proporcionados por otros subsistemas. Los subsistemas se componen de módulos y tienen interfaces definidas, que se usan para comunicarse con otros subsistemas. 2. Un módulo suele ser un componente de un subsistema, que brinda uno o más servicios a otros módulos. A su vez éste usa los servicios proporcionados por otros módulos. No se le puede considerar como un sistema independiente. Distinción entre subsistemas y módulos
Los módulos se componen normalmente de varios componentes del sistema más simples. Hay dos estrategias para descomponer un subsistema en módulos: 1. Descomposición orientada a objetos: donde se descompone un sistema en un conjunto de objetos que se comunican. 2. Descomposición orientada a flujos de funciones: donde se descompone el sistema en módulos funcionales que aceptan datos y los transforman en datos de salida. Distinción entre subsistemas y módulos
En la aproximación Orientada a Objetos, los módulos son objetos con estado privado y operaciones definidas sobre ese estado. En el modelo de Flujos de Funciones, los módulos son transformaciones funcionales. Los programas secuenciales son más fáciles de diseñar, implementar. verificar y probar que los sistemas en paralelo. Las dependencias temporales entre los procesos en paralelo son difíciles de formalizar, controlar y verificar. Estilos de descomposición modular
Es mejor descomponer los sistemas en módulos, y entonces decidir durante la implementación si éstos necesitan ejecutarse secuencialmente o en paralelo. Estilos de descomposición modular
Un Modelo Arquitectónico Orientado a Objetos estructura el sistema en un conjunto de objetos débilmente acoplados y con interfaces bien definidas. Los objetos realizan llamadas a los servicios ofrecidos por otros objetos. Una Descomposición Orientada a Objetos está relacionada con las Clases de Objetos, sus Atributos y sus Operaciones. Cuando se implementa, los objetos se crean a partir de estas clases y se usan algunos modelos de control para coordinar las operaciones de los objetos. Descomposición orientada a objetos
Las ventajas de la aproximación orientada a objetos son bien conocidas. Como los objetos están débilmente acoplados, su implementación puede modificarse sin afectar a otros objetos. Los objetos suelen ser representaciones de entidades del mundo real, por lo que la estructura del sistema es fácilmente comprensible. Como las entidades del mundo real se usan en sistemas diferentes, los objetos pueden reutilizarse.
Descomposición orientada a objetos
Desventajas de la aproximación orientada a objetos: Para utilizar los servicios, los objetos deben referenciar de forma explícita el nombre y la interfaz de otros objetos. Si se requiere un cambio de interfaz, hay que evaluar el efecto de ese cambio sobre todos los usuarios de los objetos cambiados. Si bien los objetos pueden corresponderse con entidades del mundo real a pequeña escala, algunas veces es difícil representar como objetos entidades más complejas. Descomposición orientada a objetos: Desventajas
| Página siguiente |