Universidad de Guayaquil Carrera de Ingeniería en Sistemas Computacionales

07

Diagramas de Módulos

Michelle Coello Marlon Ruiz José Salame Ciceley Sierra Ramiro Toro Lisseth Ullaguari Griselda Villegas Johnny Yuquilema

S6I

Introducción

Partiendo de que en sistemas, la Orientación a Objetos, es una metodología o manera de pensar, podemos referirnos a las técnicas que se utilizan en la Ingeniería de Software para el desarrollo de sistemas de calidad.En este trabajo se describe la Metodología de Booch, Rumbaught (OMT) y Jacobson que es un lenguaje de modelado de objetos y una metodología ampliamente usada en el diseño de software orientado a objetos. Los aspectos notables de la metodología de Booch han sido superados por el Lenguaje Unificado de Modelado, que combina elementos gráficos de la metodología de Booch junto a elementos de la técnica de modelado de objetos y la Ingeniería de software orientada a objetos.Esta metodología no es un proceso aislado, sino que todo el modelo del problema se interrelaciona con cada especificación del problema que con ayuda de las herramientas graficas y notaciones se representan visualmente todas las fases obtenidas del análisis y Diseño. Utilizar un Lenguaje Unificado de Modelado es muy recomendable para la producción de software, ya que da plena libertad a la persona de implementar el diseño según el usuario. No es rígida y esto es de gran de ayuda en ciertos procesos donde se necesite adecuar o personalizar debido a casos específicos. El Lenguaje Unificado de Modelado usa los siguientes tipos de diagramas para describir las decisiones de análisis y diseño, tácticas y estratégicas, que deben ser hechas en la creación de un sistema orientado por objetos.  

1. Diagrama de Clases. Consisten en un conjunto de clases y relaciones entre ellas.

2. Especificación de Clases. Es usado para capturar toda la información importante acerca de una clase en formato texto.

3. Diagrama de Categorías. Muestra clases agrupadas lógicamente bajo varias categorías

4. Diagramas de transición de estados. 5. Diagramas de Objetos. Muestra objetos en el sistema y su relación lógica. 6. Diagramas de Tiempo. Aumenta un diagrama de objetos con información

acerca de eventos externos y tiempo de llegada de los mensajes. 7. Diagramas de módulos. Muestra la localización de objetos y clases en módulos

del diseño físico de un sistema. Un diagrama de módulos representa parte o la totalidad de la arquitectura de módulos del sistema.

8. Subsistemas. Un subsistema es una agrupación de módulos, útil en modelos de gran escala.

9. Diagramas de procesos. Muestra la localización de los procesos en los distintos procesadores de un ambiente distribuido.

El propósito de esta investigación es describir el Diagrama de Módulos, para la cual nos hemos basado en conceptos y ejemplos dados en Internet.

Diagrama de Módulos Página 2

AntecedentesAntes de especificar que son los Diagramas de Módulos, primero diremos qué es un módulo de manera general y en que parte es usado dentro del desarrollo orientado a objetos.

Un Módulo es una unidad funcional, es una construcción lógica para agrupar clases, asociaciones y generalizaciones, sus límites son ligeramente arbitrarios y son materia opinable.

El desarrollo orientado a objetos está conformado por los modelos lógico y físico, así como también por los modelos estático y dinámico, estos modelos explican que, algunos diagramas son estáticos mientras que otros son de carácter dinámico. El diseño lógico se lleva a cabo, básicamente, durante las fases de análisis y diseño del sistema, mientras que el modelo físico, se desarrolla, más bien durante la fase de programación.

El modelo dinámico se usa para expresar y modelar el comportamiento del sistema a lo largo del tiempo. Incluye soporte para diagramas de actividades, diagramas de estados, diagramas de secuencia y extensiones incluyendo modelado de proceso de negocio.

Los aspectos Estáticos los representan modelo de objeto, estructuras de datos del sistema.

Un modelo Lógico es una vista estática de los objetos y las clases que cubren el espacio de análisis y diseño. Típicamente, un modelo de dominio es una vista más pobre, de alto nivel de los objetos de negocio y de las entidades, mientras que el modelo de clases es un modelo más riguroso y enfocado al diseño.

El Modelo Físico provee un modelo detallado de la forma en la que los componentes se desplegarán a lo largo de la infraestructura del sistema. Detalla las capacidades de red, las especificaciones del servidor, los requisitos de hardware y otra información relacionada al despliegue del sistema propuesto.

El Diagrama de Módulos es usado en todas estas secciones para una mejor organización. Ahora sí podemos referirnos a lo que es un Diagrama de Módulos.

Diagrama de Módulos Página 3

MódulosProfundizando un poco más a cerca de lo que es un módulo o paquete (“package”) pues podemos decir que el módulo captura diferentes perspectivas de un sistema. Los bordes entre los diferentes módulos pueden ser bastante arbitrarios. Los nombres de clases y asociaciones deben ser únicos en cada módulo, y se debe mantener consistencia entre los nombre de varios módulos. La misma clase puede aparecer en diferentes módulos, aunque debe ser definida solamente en uno de los módulos y referido en los otros. Debe haber menos conexiones entre módulos que asociaciones dentro de los módulos. En sistemas grandes la jerarquía de módulos puede ser de múltiples niveles.Cada módulo debe proveer una visión de alto nivel de las clases más importantes del sistema, mostrando las clases y sus asociaciones sin atributos u operaciones. Cada una de estas clases se asigna a su propio módulo, mostrando su descomposición en clases por generalización y agregación. En la siguiente figura se muestra la notación para un módulo o paquete en UML. Nótese que el módulo no tiene ninguna propiedad, a diferencia de la clase. Sirve únicamente como elemento organizacional de las clases.

Interfaz

Paquete

Vamos a definir unas de reglas que nos pueden ser de utilidad a la hora de agrupar los diferentes elementos en paquetes o módulos.

• Conviene agrupar elementos que proporcionen un mismo servicio.• Los elementos que se agrupen en un mismo módulo han de presentar un alto grado de cohesión, es decir deben estar muy relacionados.• Los elementos que estén en diferentes paquetes deben tener poca relación, es decir deben colaborar lo menos posible.

Existen conceptos importantes que hay que describir para poder realizar el diagrama de módulos.

Interfaz

Una Interfaz representa la parte pública del paquete, visible y accesible desde afuera del mismo paquete.

Relaciones en Diagramas de MódulosExisten 2 características importantes para realizar una relación entre dos módulos.

1. Dependencia2. Anidación

DependenciasIndican que un elemento de un paquete requiere a otro de un paquete distinto.Se representan mediante una flecha discontinua con inicio en el paquete que depende de otro

Diagrama de Módulos Página 4

Interfaz

Paquete

AnidaciónIndica que un módulo contiene a otro módulo.

Relaciones entre un módulo y una interfazTambién existen 2 tipos que son:

1. Realización 2. Dependencia

RealizaciónPor lo menos un elemento del paquete realiza la interfaz.

Diagrama de Módulos Página 5

DependenciaPor lo menos un elemento de un paquete hace uso de la interfaz (es decir, un elemento del otro)

Estos diagramas de módulos se realizan en el mismo tiempo de las reglas de codificación ya que nos permite predecir y evaluar su comportamiento temporal.Se desarrollan teniendo en cuenta las plataformas de desarrollo y ejecución elegidas y las experiencias en otros proyectos. La ventaja de realizar Diagramas de Módulos se denota en el arranque de la implementación y facilita su control y puesta en explotación.La desventaja es que existe el riesgo de que se produzca redundancia de información con otros documentos, debiendo de evitarse.

Diagrama de Módulos Página 6

Ejemplo

Archivos Maestros

Configuración del Sistema

General

Global

Principal

Reportes Transacciones

.NET Framework

Microsoft SQL Server 2000

Microsoft Windows

Capa de base de datos y servicios de bajo nivel

Capa intermedia no específica

Capa general de la Aplicación

Capa específica de la Aplicación

ADO.NET

Todos los paquetes de esta capa tienen relación de dependecia con el paquete .NET Framework

1. Módulos que contienen clases y otros elementos que corresponden a funcionalidades específicas del proyecto.

2. Módulos que contiene clases y oros elementos que corresponden a funcionalidades generales del proyecto que son utilizadas a lo largo de todo el software.

3. Módulos que contiene clases y otros elementos que corresponden a funcionalidades generales a cualquier aplicación. El mismo fue desarrollado en este proyecto pero puede ser utilizado en otros sin necesidad de cambios.

4. Módulos que contiene clases y otros elementos que corresponden a funcionalidades generales a cualquier aplicación. El mismo representa la librería de clases principal del entorno de desarrollo.

5. Módulos que presentan capas de gestión de base de datos y de servicios de bajo nivel del sistema operativo.

Como ya se había mencionado los módulos agrupan, clases, componentes, casos de uso e incluso otros paquetes. Como referencia podemos especificas las notaciones de estos elementos:

Diagrama de Módulos Página 7

Representación de una clase

Representación de un componente

Dibujos utilizados para realizar el Diagrama de Casos de Uso

Diagrama de Módulos Página 8

Existen herramientas donde se pueden realizar los Diagramas de Módulos como por ejemplo: Rational Rose, Vizio, etc.

Diagrama de Módulos Página 9

Conclusión

Indicamos las ideas principales de este trabajo.

Agrupación de elementos, que pueden ser: casos de uso, clases o componentes. Es posible anidar módulos entre si.

Se representan mediante un símbolo en forma de carpeta. El nombre se coloca en la pestaña y el contenido dentro de la carpeta.

Nos permite obtener una visión más clara del sistema de información orientado a objetos, organizándolo en subsistemas.

Agrupa los elementos del análisis, diseño o construcción, detallando las relaciones de dependencia entre ellos.

Los Módulos están normalmente organizados para maximizar la coherencia interna dentro de cada paquete y minimizar el acoplamiento externo entre los paquetes.

Bibliografía http://www.itlalaguna.edu.mx/academico/carreras/sistemas/Analisis%20y

%20dise%F1o%20orientado%20a%20objetos/MBooch.pdf http://gidis.ing.unlpam.edu.ar/downloads/pdfs/IntroduccionUML.PDF http://www.galeon.com/gpw/aficiones75346.html http://petra.euitio.uniovi.es/~darioa/practmp2/binarios/guiaootv101.pdf

Diagrama de Módulos Página 10