Diagrama de Modulos

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

S6I

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 Unificado de Modelado, Modelado, que combina combina elementos gráficos de la metodolog metodología í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 problema que con ayuda de las herramientas graficas y notaciones se representan visualmente todas las fases obtenidas del 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. Especific ficaci ación ón de Clases Clases. Es usad 2. Especi usado o para para capt captur urar ar toda toda la info inform rmac ació ión 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. Diagramas de Tiempo Tiempo. Aumen 6. Diagramas Aumenta ta un diagra diagrama ma de objeto objetoss con inform informació ación 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 como tambié también n por los modelo modeloss estáti estático co y dinámi dinámico, co, estos estos modelo modeloss explic explican an que, 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 aspectos Estáticos los repres represent entan an modelo modelo de objeto objeto,, estruc estructur turas as de datos 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, 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 desplegarán a lo largo de la infraestruct infraestructura ura del sistema. sistema. Detalla las capacidades capacidades de red, las espe especif cific icaci acion ones es del del serv servid idor or,, los los requi requisi sito toss de hard hardwa ware re y otra otra info inform rmac ació ión n relacionada al despliegue del sistema propuesto. El Diag Diagra rama ma de Módu Módulo loss es usad usado o en toda todass esta estass secc seccio ione ness para para una una mejo mejor r organización. Ahora sí podemos referirnos a lo que es un 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. módulos. La misma misma clase puede aparecer en diferentes diferentes módulos, 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

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 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. Dep Depend endenci enciaa 2. Anidación Dependencias Indican que un elemento de un paquete requiere a otro de un paquete distinto. Se represe representa ntan n median mediante te una flecha discon discontin tinua ua con inicio en el paquet paquetee que depende de otro


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. Reali alizaci ación 2. Depe ependenc encia Realización Por lo menos un elemento del paquete realiza la interfaz.


Página 5

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

Esto Estoss diag diagra rama mass de módu módulo loss se real realiz izan an en el mism mismo o tiem tiempo po de las las regl reglas as 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 vent ventaj ajaa de real realiz izar ar Diag Diagra rama mass de Módu Módulo loss se deno denota ta en el arra arranq nque ue 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.


Página 6

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

Principal Capa específica de la Aplicación Reportes

Archivos Maestros

Capa general de la Aplicación

Capa intermedia no específica

Capa de base de datos y servicios de bajo nivel

Transacciones

Configuración del Sistema

Global

.NET Framework General ADO.NET

Microsoft SQL Server 2000

Microsoft Windows

1. Módulo duloss que con contien tienen en clas clases es y otro otross elem elemen ento toss que corr corres espo pond nden en a funcionalidades específicas del proyecto. 2. Módulos que contiene clases ases y oros elementos tos que corre rresponden 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 cor corres responden a funcionalid funcionalidades ades generales a cualquier cualquier aplicación. aplicación. El mismo fue desarrollado desarrollado en este proyecto pero puede ser utilizado en otros sin necesidad de cambios. 4. Módulos que contiene clases y otros elementos que cor corres responden a funcionalidades generales a cualquier aplicación. El mismo representa la librería de clases principal del entorno de desarrollo. 5. Módulos Módulos que present presentan an capas de de gestión gestión de base de de datos y de servicios servicios de bajo 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:


Página 7

Representación de una clase

Representación de un componente

Dibujos utilizados para realizar el Diagrama de Casos de Uso


Página 8

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


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. Agru Agrupa pa los los elem elemen ento toss del del anál anális isis is,, dise diseño ño o cons constr truc ucci ción ón,, detal detalla land ndo o las relaciones de dependencia entre ellos.

Los Módulos están normalmente normalmente organizados organizados para maximizar la coherencia coherencia interna 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


Página 10

Diagrama de Modulos

Recommend Documents