Universidad de Guayaquil

Carrera de Ingeniería en Sistemas

Computacionales

Diagramas de
Módulos
Michelle Coello
Marlon Ruiz
José Salame
Ciceley Sierra
Ramiro Toro
Lisseth Ullaguari
Griselda Villegas
Johnny Yuquilema

07
 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

 Antecedentes
Antes 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ódulos
Profundizando 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.
Paquete

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
Interfaz

Una Interfaz representa la parte pública del paquete, visible y accesible

Interfaz desde afuera del mismo paquete.

Relaciones en Diagramas de Módulos

Existen 2 características importantes para realizar una relación entre dos módulos.
1. Dependencia
2. Anidación

Dependencias
Indican 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
 Anidación
Indica que un módulo contiene a otro módulo.

Relaciones entre un módulo y una interfaz

También existen 2 tipos que son:
1. Realización
2. Dependencia

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

Diagrama de Módulos Página 5

 Dependencia
Por 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
Todos los paquetes de
esta capa tienen relación
Principal de dependecia con el
paquete .NET Framework

Capa
específica de
la Aplicación
Reportes Archivos Transacciones Configuración
Maestros del Sistema

Capa general
de la Global
Aplicación

.NET Framework
Capa
intermedia no General
específica
ADO.NET

Capa de base
de datos y Microsoft SQL Microsoft
servicios de Server 2000 Windows
bajo nivel

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%20di
se%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