SEP SEIT DGIT

Centro Nacional de Investigación y Desarrollo Tecnológico

cenidet

Sistema Visual para el Disefjo Detallado de Métodos de Clases con UML

T E S I S QUE PARA OBTENER EL GRADO DE MAESTRO EN CIENCIAS EN CIENCIAS COMPUTACIONALES

p r e s e n t a : Javier Román Castañeda

M

"""I CiN l D E t /ZNTRO DE INFORMACION Director de tesis: M.C. OLIVIA G. FRAGOSO DL42 Co-director: M.C. RENÉ SANTAOLAYA SALGADO 0 3 - 0 0 2 6

Cuernavaca, Morelos marzo de 2003

Cuemavaca, Mor., a 19/febrero/2003

Dr. Gerard0 Reyes Salgado Presidente de la Academia de Ciencias Computacionales Presente

Nos es grato comunicarle, que conforme a los lineamientos para la obtención del grado de Maestro en Ciencias de este Centro, y después de haber sometido a revisión académica la tesis denominada: "SISTEMA VISUAL PARA EL DISENO DETALLADO DE MÉTODOS DE CLASES CON UML", realizada por el C. Javier Román Castañeda, y habiendo cumplido con todas las correcciones que le heron indicadas, acordamos no tener objeción para que se le conceda la autorización de impresión de la tesis.

Sin otro particular, quedamos de usted.

Atentamente

La comisión de revisión de tesis

,+--I. Lu , kL.2,' MC. Mario Guillen Rodriguez

Dr. Javier rtiz Hernández -¡!%-- ~ ~ ~ . - ~ - , ' - ' ' . ~ I_ , . ,.-

~ . ,,.~ , ~ :,., , ,_: .: .... . MC. René Santáolaya Salgado .{ cE:;::,::.:. -- , ;c:.~opJCkiC.~:!

c,;':c,i:2 Codirector de tesis

:.c.p. Dr. Rodolfo A. Pazos RangeVJefe del Depto. de Ciencias Computacionales NTERIOR INTERNADO PALMIRA S/N. COL. PALMlRA . A.P. 5-164. CP. 62490. CUERNAVACA. MOR. - MÉXICO 'ELS. (777) 312 23 14.318 77 41. FAX (777) 312 24 34 :MAIL Pazos@sd-cenidet.com.mx

cenjdef

FORMA C4 AUTORIZACION DE IMPRESI~N DE TESIS

Cuemavaca, Mor., a 24/febrero/2003

C. Javier Rornán Castañeda Candidato al Grado de Maestro en Ciencias en Ciencias Computacionales Presente

Después de haber atendido las indicaciones sugeridas por la Comisión Revisora de la Academia de Ciencias Computacionales en relación a su trabajo de tesis: "SISTEMA VISUAL PARA EL DISENO DETALLADO DE METODOS DE CLASES CON UML"., me es grato comunicarle, que conforme a los lineamientos establecidos para la obtención del grado de Maestro en Ciencias en este Centro, se le concede la autorización para que proceda con la impresión de su tesis.

Atentamente

Jefe del Depto. de Ciencias Cornputacionales s. E . P. CENTRO NACiCNAL CE

iN\fESTIGAClON Y DESARROLLO TECNOLOGICO

CI iNCIAS CUMPUlACIONAL€S

4TERIOR INTERNADO PALMIRA SIN. COL, PALMIRA, A.P. 5-164. CP. 62490. CUERNAVACA. MOR. - M6XiCO ELS. (7771 312 23 14.318 77 41. FAX (777) 312 2434 MAIL pazor~sd-cenidet.com.mx

Dedicatorias

A Dios por darme fuerza y sabiduría en todo momento

A mi esposa y. compañera por siempre Yuri, que siempre me ha dado su apoyo incondicional. Gracias amor

A mis padres Reynaldo y Hubertina, de quienes estaré eternamente agradecido, gracias, porque esto

es la mejor herencia que me han dado.

A mis hermanos Jorge, Gerardo, Pedro y Mariona, por todo el apoyo que me han brindado, siempre estarán en mi corazón

Agradecimientos

Agradezco a mis asesores O h i a Fragoso y René Santaolaya por sus valiosos consejos y su gran apoyo en el desarrollo de esta tesis.

Agradezco a mis revisores-y maestros Humberto, Mario, Javier y Max, por sus comentarios y observaciones, que ayudaron a enriquecer esta tesis.

Agradezco a mis amigos de generación Laura, Miguel, Cesar, Juan Gabriel, Osslan, Abril, Isabel, Carlos, Alberto, René, Omar

y Gustavo, por compartir conmigo sus conocimientos y momentos maravillosos. Y a todos mis amigos del cenidet.

Agradezco a la DGETI, y en especial el Ing. Juan Ibóñez, por brindarme su apoyo para seguirme superando

Agradezco a mis amigos Humberto, Carlos, Gina y Cesar, por darme su amistad. Y a todos (os amigos del Cetis No. 43.

Agradezco al cenidet por abrirme las puertas y darme la oportunidad de alcanzar una nueva meta. También a Cosnet por el

apoyo que me dio para realizar mis estudios.

Gracias a todos ...

CONTENDO

Resumen

Capítulo i INTRODUCCI~N .__.. .__..

Capitulo 3 ESTAD0,DEL ARTE.

3.1 introducción .... 3.2 Métodos y técnic

............. ......................... 3 1

3.2.1 Metodología OMT .. .................. 3.2.2 Método de Booch .... .................. 3.2.3 Método de Coad y Yo ......................... 3.2.4 Lenguaje Unificado de Modelado (UML)

3.3 Herramientas de análisis y diseño de sistemas ....... ......................

3.3.1 Rational Rose ......................

3.3.3 Power PDL

3.4.3 Verificación de flujos de trabajo c'on diagramas de actividades ._ 37

3.4.5. Diagramas de actividades para modelar sistemas móviles ......... 38 3.4.4 Protocolos con diagramas de actividades de UML . .... 37

3.5 Referencias ...................... 39 .... ...............................

Capítulo 4 DESARROLLO DE LA HERRAMIENTA

4.1 4.2

4.3

4.4 4.5

4.6 4.7

4.8 4.9

4.10

............... ............................ Introducción ......................... 42. Análisis general del sistema ....................... ......................... 43

................................................................. 43 4.2.1 Vista conceptual 4.2.2 Vista arquitectonica ................................................................. 44 Definición de la gramática visual de SIDDOO ................................... 45 4.4.1 Símbolos terminales y no terminales ....................................... 45 4.4.2 Reglas de producción ........................... 4.4.3 Descripción de 1 .................... 47 Analizador visual ...... Diseño estático y diná 4.6.1 Diagramas de 4.6.2 Diseño dinámico de SIDDOO ............ Aplicación de patrones de diseño .. Ambiente de modela 4.8.1 Manipulación 4.8.2 Uso de conec 4.8.3 Líneas de co 4.8.4 Manejo de texto en el modelado 4.8.5 Estructuras Guardar y recupe Funcionalidad de 4.10.1 interfaz de SIDDOO 4.10.2 Construcción de los m

, , .

............. .................. Referencias ...................................... 71

< .

11

Capítulo 5 PRUEBAS DEL SISTEMA

5.1 Grupo de pruebas .................................................................................. 73 5.2 Evaluación de resultados ...................................................................... 79

Capítulo 6 CONCLUSIONES

6.1 Conclusiones ........................................................................................ 83 6.2 Recomendaciones y trabajos futuros ................................................... 84

Bibliografía

ANEXO A Gramática visual del diagrama de actividades ......... 89 ANEXO B Patrones de diseño utilizados .................................... 95 ANEXO C 102 Descripción de clases utilizadas en el diseño .............

... 111

r

LISTA DE TABLAS Y FIGURAS

No. Tabla Descripción

1. 2. 3. 4.

Comparación de herramientas de análisis y diseño Comparación de métodos y técnicas de diseño O 0 Elementos de la notación de BNF Tabla de análisis de un LR posicional ,-

Pag.

37 38 44 48

. No. Figura Descripción Pig.

I. 2. 3. 4. 5. 6. 7. 8. 9. IO. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32.

Arquitectura actualizada de AMASS. 4 Fases del desarrollo de un sistema 10 Modelos de un sistema 20

42 43

Modelo conceptual de SIDDOO Arquitectura de SIDDOO

45 47 47 49 51 5 3. 57

Diseño del área de modelado de SIDDOO 58 59

Uso de conectores en SIDDOO 59 Construcción de la flecha 60 Tipos de línea de conexión 61 Línea punteada en bloques 62 Segmentación de conexiones 62 Estructura de clases para el manejo de texto .63 Estructuras de datos utilizadas 64 Guardar y recuperar archivos 66 Interfaz de usuario de SIDDOO ' 67 Diagrama de secuencias para pintar símbolo en SIDDOO 69 Diagrama de secuencias para conectar símbolos en SIDDOO 69

73 Diseño detallado del método creaCoenctores de la clase Pinicio 74

75 Diseño detallado del método sumupar de la clase Integra 76

77 Validación durante la construcción del modelo 78

80

Símbolos terminales con sus puntos de conexión Oración visual del lenguaje de SIDDOO Ejemplo ¿le producciones de la gramática visual de SIDDOO Modelo de comportamiento de SIDDOOO

Diagrama de estados de SIDDOO Área para manipulación de gráficos en SIDDOO

Símbolo de actividad con sus conectores que lo componen

Diagrama general de clases de SIDDOO

Diseno detallado del método dibuja de la clase Pinicio.

Diseño detallado del método simpson de la clase Integra

Diseño detallado del método sumanon de la clase Integu

Respaldo de archivos de diagramas

iv

RESUMEN

~1 contexto de este trabajo de investigación es el diseño de sistemas de y en particular es el diseño detallado de un sistema Orientad0 a objetos. Sin duda, una de las fases de mayor impo,.tancia dentro del ciclo de desarrollo del software es el diseño. Debido a que el realizar un buen diseño puede marcar la diferencia en ia obtención de Un Producto de buena o mala &idad, generalmente, un buen diseño puede garantizar mayor tiempo de vida del evitando problemas futuros de mantenimiento y facilitando la d ~ c i ó n de imprevistos d-te la fase de implementación. Por lo tanto, contar con un buen diseño antes de llegar a la codificación, puede ahorrar tiempo, dinero y esfuerzo.

El objetivo principal de este trabajo de tesis es consmiir una herramienta de software, que permita modelar el diseño detallado de los métodos de un sistema orientado a objetos, con base en un lenguaje visual definido de acuerdo a la notación de los diagramas de actividades del Lenguaje Unificado de Modelado (UML), y que al mismo tiempo sirva de apoyo a los desarrolladores de software en las tareas de diseño detallado.

Para tener un marco de referencia importante, sobre los temas de interés para esta investigación, se realizaron estudios minuciosos de los métodos, técnicas y herramientas enfocadas al área del diseño orientado a objetos (00), y por supuesto, a las técnicas tradicionales de diseño detallado. También se realizó una investigación sobre el modelado dinámico de un sistema con diagramas de actividades de UML. Considerando además, el estudio de las bases teóricas de los' lenguajes y gramáticas visuales para la definición de lenguajes del tipo diagramático . .

La herramienta producto de esta tesis, es denominada SIDDOO, y se desarrolló siguiendo un proceso metodológico. A partir de un modelo conceptual del funcionamiento general del sistema, se determinaron los elementos principales que participaran en su funcionamiento. Primero se definió un lenguaje de modelado visual, con base al formalismo de las gramáticas visuales posicionales, considerando la notación de los diagramas de actividades de UML para la construcción de sus oraciones visuales. Después se realizó el diseño general de clases, considerando una estructura reusable y codable para posibles extensiones a su funcionalidad: Además, Se implementó un módulo para validar los diagamas al momento de su consmicción con la herramienta.

De acuerdo a los resultados obtenidos con este trabajo de tesis, se concluye que la herramienta desarrollada SIDDOO sirve de apoyo importante para los ingenieros del software en la fase del diseño detallado de métodos de clases. Debido a que, cumple con el objetivo para lo cual fue desarrollada, permitiendo obtener una documentación importante, con la obtención de los modelos correspondientes al diseño detallado generados por la herramienta y representados por los archivos de diagramas correspondientes a cada método. Con todo esto, un trabajo futuro puede ser que, a partir de los modelos construidos se genere SU código correspondiente de forma automática. Además, otra ventaja importante es la utilización de la notación de UML, debido a que actualmente e s considerado un estándar para el modelado de sistemas orientados a objetos.

V

c+,,I,, i : IN.I .RODCICCI~N

Introducción. >

i

En este capítulo se presentan los antecedentes de este proyecto de investigación, así como el objetivo, la definición del problema y la justificación. Además, se indican cuales son los alcances y los beneficios que se esperan tener con este trabajo de tesis, mencionando la metodología de solución que se utilizó.

1 ccrridcl 2003

Capítulo i : INTRODUCCION

1.1 Antecedentes

Desde 10s inicios de la programación, los desarrolladores de software, han tratando Problemas cada vez más grandes y complejos, utilizando diferentes técnicas y

(Paradigma) que les ayuden a resolver las necesidades que se tienen en diferentes de

aplicaciones, Y que garanticen una mayor calidad en SUS productos de software.

Una de las fases de la ingenieria de software que sin duda es muy importante en el desarrollo de cualquier sistema de software es el diseño. La importancia del diseño del software se puede expresar con una Única palabra: culidud. El diseño es el proceso en el que se asienta la calidad del desarrollo del software, produce las representaciones del software en las que puede evaluarse su calidad y sirve de base para las etapas posteriores del desarrollo. No podemos negar que siempre que se termina el des&ollo de cualquier sistema es necesario realizar una etapa de pruebas, entonces, es aqui, cuando un buen diseño resulta indispensable para 'la depuración y corrección de dicho sistema. Además no es nada grato para un desarrollador prescindir de un diseño previo en la fase de mantenimiento de un sistema. Sin diseño nos 'miesgamos a constkir un sistema inestable, un sistema que falle cuando se realicen pequeños, cambios, que pueda ser dificil de probar y cuya calidad no pueda ser evaluada, sino hasta etapas postenores en el proceso de ingeniería de sofbare, cuando quede poco tiempo y se haya gastado ya mucho dinero[l].

El diseño estnrcturd define las relaciones entre los principales elementos estmcturales del sistema. El objetivo principal del diseño estructural es desarrollar una eshctura de programa modular y representar las relaciones de control entre los módulos. ES bien sabido que' el diseño detallado por procedimientos, se basa en los principios de la programación e structurada. E 1 diseño por procedimientos s e realiza d espues de que s e h a establecido la estructura del programa y de los datos, transformando los elementos eshcturales e n una descripción p rocedimental del s oftware, definiendo 1 os algoritmos de procesamiento necesarios que ayudan a la generación del código fuente[2]. Ahora, con el paradigma de programación orientado a objetos, solo se utiliza el concepto de método en lugar de función o procedimiento, pero el diseño estructural de un método se realiza de forma similar.

1.1.1 Alcances de la ingeniería de software

Así como los fabricantes buscan mejorar la calidad de los productos que producen, los ingenieros del software también deben encontrar los métodos para asegurar que SUS productos sean de calidad aceptable. De esta manera, la ingenieria de software siempre debe incluir una estrategia para producir software de calidad.[3]

Una de las tareas principales de la ingenieria de software, ha sido proponer nuevos métodos y herramientas que faciliten y mejoren la calidad de los productos de software. Desde el surgimiento del paradigma de la programación orientada a objetos, se han hecho esfuerzos por aplicar las mejores técnicas para el diseño de sistemas que siguen este paradigma, tratando de reducir el tiempo en el desarrollo, facilitando a1 desarrollador SU trabajo y garantizándole la extensión del ciclo de vida de sus productos de software.

cenidet 2003 2

' w'b,..*- , . ., . .'.?Y. si>

cspi~ii~oi: I N T R O D U C C I ~ N .l. . . .. .. ~

A pesar de los avances en el desarrollo y de la aceplacióti global del sonware, hay todavía mucho por hacer para mejorar la calidad, ya que la ausencia de calidad puede ser un factor de costo; cuando más se tarda en detectar un defecto inás costoso resulta corregirlo. Por lo general la mayoría de los errores no se dekectan en la fase temprana del desarrollo, y casi todos los errores encontrados durante las pruebas y el mantenimiento derivan de errores cometidos en las fases de análisis y diseño.

1.1.2 Niveles de abstracción en el diseño de software

El mecanismo fundamental para el desarrollo de software es dado por la dualidad de abstracción y representación. La abstracción es el proceso mediante el cual es posible

~ identificar los aspectos importantes de un' fenómeno, ignorando los deíalles. La representación es el proceso que permite describir sobre algún :formalismo, los aspectos importantes. El criterio que permite ,decidir qué elementos deben ser considerados importantes, depende del por qué se está realizando tal abstracción. Por ejemplo, un mapa caminero es el resultado de la aplicación de estos procesos, la abstracción permitió la identificación de los caminos y sus características más importantes, carpeta de rodado, distancias, etc., y la representación es ¡o que permite llevar esta abstracción a su forma de mapa. El diseño se representa a un alto nivel de abstracción, a un nivel que se puede seguir hasta requisitos específicos de datos, funcionales y de comportamiento. A medida que ocurren iteraciones del diseño, el refinamiento subsiguiente lleva a representaciones del diseño de mucho menor nivel de abstracción[4].

El modelo de los niveles de diseño del software se divide en dos categorías: El micro diseño y el macro diseño: Los niveles de macro diseño incluyen un nivel arquitectónico del sistema global. Los niveles de micro diseño incluyen el diseño refinado de una aplicación, Considerando un nivel bajo para el diseño de ¡os objetos y las clases. Cabe mencionar que los niveles de micro diseño soh más familiares para los desarrolladores, considerando que a este nivel de diseño se proporciona la clave para la funcionalidad de un sistema, así como para la optimización.de su representación en la impkmentación.

Los niveles de diseño son considerados como un importante soporte, debido a que cuando se logran utilizar adecuadamente, ayudan a simplificar problemas de diseño. Cuando se separa el diseño en diferentes.niveles, se están delimitando las funciones que se deben resolver en cada nivel. Esta,fonna de diseñar en niveles ha sido utilizada desde hace muchos años en la ingeniería de hardware digital, y ahora, se está adoptando de forma similar para la tecnología de objetos como una efectiva disciplina conceptual. Realizar el diseño en niveles, es una buena estrategia para las arquitecturas orientadas a objetos, porque de esta manera se definen los problemas y funciones que dicha arquitectura debería resolver[5].

Cada paso del proceso de ingeniería de sonware es un refinamiento del nivel (le abstracción de la solución de.uii sistema de soitware. Con.rome nos niovenios por diferentes niveles de abstracción, trabajamos para crear abstracciones de datos y de procediniientos. Una aúsfr-accióri procedintentd es una determinada secuencia de instntccioties que tienen una función limitada y específica. El r-efirtamierito sticesivo es una primera estrategia de diseño descendente. La arquitectura de un programa' se puede desarrollar en niveles sucesivos de refinamiento hasta llegar a los detalles procedimentales. Se desarrolla una

3 certidei 2003

http://optimizaci�n.de

Capítuio 1 : INTRODUCCION

jerarquía descomponiendo la declaración macroscópica de una función en forma sucesiva, hasta que se llega a los estatutos del lenguaje de programación.

Englobando la información anterior. En esta tesis el enfoque es hacia el estudio del diseño detallado de los métodos de un sistema 00, ya que se considera de gran importancia en el proceso de desarrollo de software. Aunque esta parte del diseño resulta más dificil de modelar, por considerarlo como el nivel más bajo de detalle, siempre se ha tratado de ir acorde a las nuevas tendencias en el área de la programación y para los métodos de una clase no podía ser la excepción. Actualmente la mayona los métodos de diseño orientado a objetos (DOO) combinan elementos de las tres categonas de diseño: El diseño de datos, diseño arquitectónico y diseño procedimental. Al identificar clases y objetos, se crean abstracciones de datos. El diseñador del objeto proporciona una descripción de su implantación y crea los detalles internos del objeto, y para poder diseñar ai más bajo nivel en un sistema 00, se debe hacer el diseño detallado de los métodos de una.clase.

1.1.3 Ubicación del trabajo

. .

I

Figura 1. Arquitectura actualizada de AMASS.

Esta tesis forma parte del proyecto A M A S S (Ambiente Integrado de Soporte para Administración y Desarrollo de Sistemas de Software), con el cual se trabaja dentro del área de ingeniena de software en el Cenidet, su objetivo principal es el apoyar al desarrollador de software para la obtención de productos que garanticen una mayor calidad, menor tiempo de desarrollo y la reducción de costos. AMASS es un sistema integrado por

cenidet 2003 4

.. r,i'

Capitulo 1 : INTRODUCCI~N

~

importancia al aspecto de los niveles más altos de abstracción de UD sistema 00, como el estático o de clases y el de. interacción entre objetos, pero sin atender el aspecto dinámico que tiene que ver con los detalles de los métodos de las clases.

El diseño permite presentar diferentes niveles de abstracción de un sistema, y entre más bajo sea el nivel de detalle, permitirá más fácilmente pasar a la implementación del mismo, pero sin duda también resulta más complicado. Considerando lo anterior, muchos desarrolladores d e s ofhvare nunca han dado importancia al diseño' detallado d e s istemas, aún conociendo que la notación del diseño, junto con los conceptos de la programación estructurada, permiten al diseiiador representar detalles de las actividades de un módulo, procedimiento o método, de manera que faciliten la traducción a código en cualquier lenguaje. La consecuencia de esto es una mala calidad de los productos de software.

En el medio del desarrollo de software lo que se considera en un futuro para mejorar esta kea, no son nuevos lenguajes orientados a objetos que Sean más eficientes, sino mejores métodos y herramientas que apoyen a la ingeniería. de software orientada a objetos[6]. Por esto, se ha considerado de suma importancia desarrollar esta tesis, con el propósito de construir e implementar una herramienta que permita realizar el diseño detallado de los métodos de sistemas orientados a objetos, y que ayude en cierta medida a facilitar el trabajo, a reducir el tiempo que emplean los diseñadores en el desarrollo del software, garantizando una buena documentación generada del diseño, así como su mantenibilidad. Para el diseño detallado de los métodos, se apoyará en 1 os diagramas' de actividades propuestos por UML, por considerar que actualmente es un lenguaje estándar para el modelado de sistemas, lo que permitirá estar a la vanguardia en ese sentido, garantizando la utilidad y aceptación de la herramienta.

- El uso de los diagamas de actividades se considera una ventaja, ya que con.ellos se

puede hacer un enlace con otros elementos del modelado con propósitos de visualización, especificación y construcción del comportamiento de los elementos. La principal ventaja de los diagramas de actividades es que todos los elementos dentro de un diagama son semánticamente ligados a un modelo fundamental (subyacente) con bastante riqueza expresiva. Por ejemplo, los diagramas.de actividades pemiten escribir el cuerpo de una operación computacional, lo que resulta más directo para la codificación. Además, cuando el comportamiento de una operación es muy complejo y difícil de entender, un diagrama de actividades será de gran utilidad, ya que simplifica,el entendimiento para iniciar el código. Cuando se observa el flujo de los datos de una operación en un diagrama de actividades se muestran detalles del algóritmo que no se visualizarían tan fácilmente en el código[7].

1.4 Alcances y Limitaciones

El alcance que se tiene con el desarrollo del presente trabajo se limita a lo siguiente:

Con este trabajo de tesis se construye la herramienta SIDDOO, usada para modelar el diseño detallado de los métodos de las clases de un sistema orientado a objetos. En el área de las gramáticas visuales, se tiene un acercamiento formal en la aplicación de este tipo de gramáticas para la definición de lenguajes de modelado

cenidet 2003 6

http://diagramas.de

O

i

a

b

~~

visual del tipo diagramático, y al mismo tiempo se propone la construcción de un analizador para Validar el diseño de los diagramas definidos por dicha grainática. Se cuetita con un ambiente visual que sirve de interfaz Iiombrelmáquina, en donde se da cierta flexibilidad al usuario en el modelado de los métodos de las clases de un sistema 00, siguiendo siempre el lenguaje diagramático definido por la gramática visual. Con respecto a’UML, se hace uso de casi toda la notación de los diagramas de actividades, que se utilizan para la construcción de los modelos. No se consideró el uso de los “swirnlanes” para la implementación de SDDOO, que son utilizados para dividir gnipos de trabajo en una organización. Otra restricción en este sentido, es en el modelado de las actividades concurrentes. Aquí solo se permiten niodelar como máximo tres líneas de actividades en sincronización. Con el presente trabajo queda el antecedente para el uso de.otras notaciones de UML, y así poder modelar el diseño de uti sistema a diferentes niveles de abstracción. Cada modelo disefiado a partir de SIDDOO, representará un método de un sistema, quedando de antecedente para que a partir del m odelo se pueda generar el código haciendo un análisis de la estructura de’datos que representa cada modelo, ya que la generación del código en fonna automática ya no corresponde al alcance de esta tesis. ,

1.5 Beneficios esperados

AI desarrollar este trabajo.de tesis, principalmente se hace una aportación al área de ingeniería de software, y en particular a la fase de disefio detallado de sistemas orientados a objetos. Se pretende apoyar con la herramienta SIDDOO a los desarrolladores de software, dándoles ciertas ventajas y beneficios en el diseño de sistemas, para que generen productos de mayor calidad, más maiiteiiibles y puedan alargar su ciclo de vida. Algunos otros beneficios esperados se mencionan en seguida: .

0 Se espera reducir el fieinpo en el desarrollo’ del soIhvare, ya que realizar un buen diseño puede ayudar a reducir tiempo, dinero y esfuerzo, Además, ayudará a resolver más fácilmente los imprevistos durante las siguientes etapas del desarrollo de ut1 sislema de software. Se contará con los modelos que corresponderán a los métodos de los objetos de un sistema 00, los que formarán parte de la documentación del diseño del niisiiio, a través de información generada a partir de la representación gráfica guardada en arcliivos de computadora. Todo esto, se considera una ventaja importante en el desarrollo de cualquier sistema de software. La utilización de los diagramas de aclividades que propone UML, se considera in1 beneficio y a la vez una ventaja, debido a que, la mayoría de las Iierrainientas existentes no modelan directamente los métodos de una clase,’ y al mismo tiempo se estará acorde a las tendencias actuales en el modelado de sistemas 00, ya que UML está siendo el lenguaje que más se usa en la actualidad, porque está consolidándose como un estándar en este sentido.

7

http://trabajo.de

Capiiuio 1 : I N T R O D U C C I ~ N

1.6 Metodología de solución

Para lograr el objetivo general de este trabajo de tesis se planteó desarrollar lo siguiente:

1. Para poder tener un panorama más amplio se analizaron: diversas herramientas de diseño y modelado o nentadas a objetos, m etodologías tradicionales p ara e 1 diseño detallado de programas, así como las herramientas actuales para el diseño detallado. Se estudiaron las notaciones que utilizan para tal fin, y así, poder determinar cuál utilizar para el modelado en la herramienta SIDDOO, de acuerdo a las necesidades que se tenían al inicio de la investigación y que se definieron anteriormente.

2. Con la finalidad de determinar las bondades y ventajas que proporcionan los diagramas de actividades de UML, se considero un estudio general de la notación simbólica que utiliza en sus diferentes aplicaciones. De esta manera, se propone su uso para la implementación de SIDDOO.

3. Para qÚe SIDDOO contara con un ambiente de modelado visual, era necesario definir un lenguaje visual que permitiera modelar los diagramas de actividades de UML. Para esto, fue importante la utilización de las gramáticas visuales, tomado en cuenta que el tipo de lenguaje visual que se pretendía definir era diagramático, para el cual, era necesario tener cierta flexibilidad 'de relación y/o conexión, así como, de ubicación espacial de los objetos gráficos en la constnicción.de las oraciones visuales de dicho lenguaje, lo que no se podría definir con otro tipo de gamaticas (textuales).

4. Las gramáticas visuales propuestas para 'la definición del lenguaje, fueron las posicionaIes,.ya que este tipo de gramáticas ofrecen las facilidades para cubrir las necesidades del 1 enguaje visual que se definió, e n donde s e p ennite 1 a c olocación espacial de objetos, y al mismo tiempo permite definir relaciones de conexión entre ellos. Además, porque este tipo de gramáticas han sido utilizadas para definir varios lenguajes del tipo diagramático.

5. Para dar mayor flexibilidad en el diseño de los modelos a través de SIDDOO y proporcionar facilidades a los usuarios de la herramienta, el diseñador podrá modelar sus diagramas con cierta libertad, de acuerdo a la gramática definda para 10s diagramas de actividades. S IDDOO contiene un ambiente d e edición gráfico, para que el diseñador pueda manipular sus modelos de manera fácil y rápida.

6. Se realizaron un grupo de pruebas del modelado visual de los' métodos de un sistema, para garantizar la consistencia y confiabilidad de SIDDOO.

cenidei 2003 8

http://constnicci�n.de

. I 1 .

capíniio 1 : INTRODUCCI~N

1.7 Referencias.

Luis Joymes Apilar. Fundamentos de Programación Estructura Mc Graw Hill. España 1996

Diseño de sistemas. hm>://www.chaco.4ov.ar/UTN/disenodesistemas/de/diseño estructurado.htm septiembre 1997

Shari Lawence Pfleger. Ingeniería de Software Teoría y práctica Prentice Hall . Argentina 1". Edición 2002.

El proceso del diseño de software. 1998 htto://www.itcc.edu.mx/inqsoft/detalla.htm

Rápael Malveau y Thomas J. Mowbray. Software Architect Bootcamp Prentice Hall 2001. p. 117, 118

Ian Graham. Métodos orientados a objetos Adison Wesley 1996. p.'9,10.

G Booch, Jacobson, Rumbaugh. El lenguaje Unificado de Modelado Addison Wesley 1999

cenidei 2003 9

Sistema Visual para el Diseño Detallado de Métodos de Clases con UML

Marco Teórico. Este capítulo describe los temas de interés que se relacionan con la presente

investigación y que de alguna manera dan el fundamento teórico a la misma, en donde se abordan tenias como: Diseíio de sistemas, diseño detallado, modelado orientado a objetos con diagramas de actividades de UML, lenguajes y gramáticas visuales y las herramientas CASE.

0 3 - 0 0 2 6

Capítulo 2 : MARCO TEÓRICO

2.1 Introducción

El diagrama de la figura 1 representa el ciclo tradicional de desarrollo de un sistema de software, mostrando la fase donde se puede aplicar este trabajo de investigación, haciendo referencia a las otras fases que se involucran. Como se describió en la ubicación del trabajo en el capítulo 1, esta tesis forma parte importante de un proyecto más gande, en donde se involucran otras herramientas como SOODA y DDVI, aportando en la fase del diseño detallado antes de llegar a la codificación de un sistema.

Figura 2. Fases del desarrollo de un sistema.

Cada una de las fases en el desarrollo de un sistema tiene su grado de importancia. Como se puede observar en la Figura 1; cada fase realiza un trabajo que necesita de la información de la fase previa, utilizándola para poder generar información nueva y pasarla a la fase posterior. Es aquí donde la herramienta SDDOO apoya ai modelado del diseño detallado de un sistema OO. La información generada de la fase de diseño será utilizada en las fases siguientes, como son: en la codificación, donde se implementan en algún lenguaje de programación las estructuras generadas en el diseño. En la depuración y pruebas por lo regular se presentan imprevistos y detalles que no se consideraron en el diseño, y resulta importante contar con la documentación realizada en el.diseño para agilizar la depuración. También, es de san ayuda contar con la información generada en el diseño para facilitar las tareas de mantenimiento y actualización del sistema.

cenidef 2003 11

,,*.,c* ,. . ,.' ~ ; , , > 3 , V m v ~ $ , , ,

.I

Caplido 2 : MARCO Tl3Ón1co

La itigeiiiería de software es el área que etigloba el contexto cn el que se desarrollo esta tesis, y en particular, es la fase de diseiio detallado de un sistema orientado a objetos; 10 que fonna una park iniportante eii el ciclo de desarrollo de cualquier sistema, debido a que en la actualidad, muchas aplicaciones se desariollan en base a este paradigtiia de programación. Haciendo 'uso de UML, se puede modelar cualquier nivel de detalle de un sistema, de esta manera, se están utilizando,los diagramas de actividades de UML que son, una de las notaciones para model& los aspectos dinámicos de un sistema orientado a objetos.

Para poder definir un lenguaje visual que permita modelar el diseño detallado de los métodos de las clases de un sistema orientado a objetos, se utiliza el formalismo de las gramáticas visuales. La herramienta SIDDOO generada como resultado de este trabajo de tesis es considerada una hehamienta CASE, por lo tanto se hace mención de las características de este tipo de herramientas:

2.2 Diseño de sistemas

Eldiseñoesuna etapaimportanteen e l desarrollodesistemasdesoftware. En l a ingeniería de software se tia evolucionado a través del tiempo, tratando de proponer nuevos métodos, técnicas y herramientas que facilitan y mejoran la calidad de todos los productos de software; en el área de diseño, se ha tratado de ir acorde a los nuevos modelos de programación, al querer diseñar sistemas cada vez más complejos y más grandes, convirtiendo esto, en una tarea dificil para los desarrolladores.

Cada vez que se tuvo.:la necesidad de utilizar un estilo diferente de programación, también se debió de buscar la forma de diseñar los sistemas de acuerdo a ese nuevo estilo, Cuando surgió el paradigma O 0 en los años ~ O ' S , y conforme fue teniendo mayor aceptación, se Iian hecho esfuerzos por contar con las. mejores técnicas y herramientas para el diseño de sistemas que siguen este paradigma, tratando de reducir el tiempo en el desarrollo, facilitar al desarroliador su trabajo y garantizándole el mejoramiento de la calidad de sus productos.

2.2.1 Conceptos básicos del diseño

El diseño del software es un proceso iterativo, a través del cual se traducen los requisitos en una representación gráfica. Cuando se trata de diseñar un sistema, se debe realizar de la mejor manera posible, ya que por lo general, de un buen diseño depende el tiempo de vida útil de cualquier sistema. Con los nuevos paradigmas de programación no ha cambiado este concepto, debido a que siempre un buen diseño ahorrará trabajo futuro en el desarrollo y mantenimiento de cualquier sistema de soflware.

Los desarrollos de sistemas orientados a objetos promueven una nueva forma de pensar. La palabra desarrollo hace alusión a la parte inicial del ciclo vital del software: análisis, diseño e implantación. El modelado y diseño orientado a objetos también constituye una nueva forma de pensar acerca de los problemas, empleando modelos que se organizan tomando como base conceptos del mundo real. Los modelos Orientados a objetos son útiles

12 cerriilcl 2003

Capitulo 2 : MARCO TEORICO

Para comprender problemas, comunicarse Con expertos en esa aplicación, modelar empresas y diseñar programas y'bases de datos:

Aunque los lenguajes, los métodos y las herramientas orientadas a objetos continúan su proceso de maduración, el diseño de las aplicaciones orientadas a objetos, retiene algo de ese oscurantismo propio de los desarrollos de software. El propósito del diseño es crear una arquitectura para el sistema que va a desarrollarse, y establecer las tácticas comunes que deben utilizarse por parte de elementos del sistema [l]. Durante el diseño orientado a objetos, se ejecuta la estrategia seleccionada durante el análisis y se rellenan los detalles. Los objetos identificados durante el análisis sirven como esqueleto del diseño, las operaciones identificadas en esta fase deben expresarse en forma de 'algoritmos, descomponiendo las operaciones complejas en operaciones internas más sencillas.

En la programación orientada a objetos se puede explicar el diseño detallado como una parte que corresponde a la descripción de los objetos, ya que ésta se puede dar de dos formas básicamente: Una de ellas es a través de los mensajes que reciben entre ellos y las operaciones que realizan al recibirlos (interacción entre objetos). La otra tiene que ver con el objetivo de esta tesis; en donde se describe la implementación de los métodos u operaciones de cada-objeto, mostrando los detalles de las operaciones implicadas en la recepción de los mensajes, proporcionahdo detalles internos requeridos para su postenor codificación [2].

2.2.2 Importancia del diseño en el desarrollo de software

Existen millones de:sistemas de software, de los cuales muchos están funcionando actualmente, aunque muchos de ellos hayan tenido buenos diseños, quizá su diseño original ya cambió o dejó de usarse totalmente, de ahí que; mientras mejor estén diseñados, mayor tiempo de vida útil tendrán. La calidad del software se podría medir de acuerdo a como el producto resuelve o se aplica para lo que fue desarrollado, también por, cómo es que éste fue desarrollado y de cómo se utilizaron los principios, métodos y técnicas, cuya adecuada aplicación nos puede. llevar a elevar su calidad. De cualquier manera, la calidad dependerá de cómo el cliente ve satisfechas Sus necesidades y requerimient0.s en el producto que se le entrega, lo que resulta dificilmente medible.

A lo largo del proceso de diseño, se evalúa la calidad con una serie de revisiones técnicas formales. Generalmente se sugieren tres características que sirven de directrices para la evaluación de un buen diseño:

El diseño debe implementar todos los requisitos explícitos contenidos en el modelo de análisis y debe acomodar todos los.requisitos implícitos que desea el cliente. El diseño debe ser una guía que puedan leer y entender los ,que construyan el código y los que prueban y mantienen el software. El diseño debe proporcionar una completa idea de lo que es el software, enfocando los dominios de datos, funcional y de comportamiento desde la perspectiva de la implementación.

cenidei 2003 13

- i.; .- . . .twcn:*i.., . .

it^^^^ z : MARCO TEORICO

Cada una.de estas características es de hecho un objetivo del proceso del diseño,

,: .. , . .

pero, alcanzar estos objetivos no es tarea fácil para cualquier desarrollador[3].

La construcción del soflware de calidad es una tarea que implica miiclia creatividad, disciplina, experiencia e inteligencia, y solo se puede tomar como una tarea simple si el sistema a desarrollar no tiene ninguna aplicación, ni importancia. Manejar adecuadainente la complejidad del software, nos llevará a obtener sistemas de mejor calidad y al mismo tiempo a obtener un aspecto importank en el desarrollo del s o h a r e , que es la realización de un diseño adecuado.

Otro aspecto importante del diseño en el desarrollo de sistemas es que pemiite obtener una buena documentación, proporcionando una explicación de la forma en que opera el sistema y qué características tienen los modelos y algoritmos utilizados en él. Aunque esta información es transpareiite para el iisuario, se puede recuperar cuando sea necesario ya sea en forma impresa o a través de una pantalla, cuando se utiliza una lierramieiita como la que se propone en esta tesis.

2.2.3 Diseño detallado . .

Dentro de la fase del diseño podemos representar un todo o sus partes en diferentes niveles o vistas, quizá unas mas entendibles que otras, pero cada una de estas vistas puede mostramos un aspecto importante del sistema que queremos desarrollar. Aquí nos enfocaremos a uno de los niveles más bajos dentro del diseño de un sistema, y nos referinios al nivel más bajo de abstracción, que es el diseño detallado de un sistema, en donde se pueden mostrar detalles tanto como sea posible, antes de decidir pasar a la fase de codificación.

El punto de ini.cio para el diseño detallado’es una estructura arquitectónica a la que se le van a proporcionar los detalles algorítmicos y las representaciones concretas de datos. Mientras que, hay una fuerte tentación. para proceder directamente de la estructura arquitectónica a la instrumentación, hay varias ventajas que pueden lograrse en el nivel intermedio de detalle proporcionado por el diseño detallado. La implementación comunica los aspectos de la sintaxis- ¿lei lenguaje de programación, el estilo de codificación, la documentación interna y la inserción de pruebas y depuraciones al código. Las dificultades que se encuentran durante la instrumentación casi siempre se deben al hecho de que, el instruinentador simultáneamente está realizando análisis, diseño y actividades de codificación niientras intenta expresar el resultado final en un lenguaje de iniplementación[3].

2.2.3.1 Conceptos de diseño detallado

El diselío detallado se refiere a los detalles que son considerados antes de la implementación de un sistema. Aquí se debe indicar cómo empacar módulos, de procesamiento y como instruinentar algoritmos. Ésta fase de diseño se encarga de separar las actividades que se deben realizar al más bajo nivel. Cuando se realiza una especificación clara y adecuada de diseño detallado, se garantiza una iniplementacióii de código siii

14 ceiiidel 2003

Capitulo 2 : MARCO T E ~ R I C O

ninguna sorpresa ni imprevisto, y sin duda le dará grandes ventajas y facilidades en futuros mantenimientos en todas sus aplicaciones.

El diseño detallado tiene que ver con la especificación de detalles algontmicos, representaciones concretas de datos, interconexiones entre fupciones y estructuras de datos, y empaque del producto de programación. El diseño detallado está fuertemente influenciado por el lenguaje de implementación, pero no es lo mismo; el diseño detallado tiene que ver más con aspectos semánticos y menos con detalles sintácticos que es la implementación.

Las actividades de diseño detallado inevitablemente exponen los defectos en la estructura arquitectónica y las modificaciones resultantes se verán facilitadas por tener menos detalles por manipular que los que estarían, presentes en el lenguaje de implementación. El diseño detallado también proporciona un vehículo para inspecciones de diseño, recomdos estructurados y la revisión crítica del diseño.

2.2.3.2 Dei diseño a la implementación del software

La escritura de código es una extensión del proceso de diseño. La escritura de código o también llamada implementación, deberia de ser sencilla, casi mecánica, porque ya deberiamos de haber tomado todas las decisiones dificiles durante el diseño. De igual manera, hay que tomar decisiones mientras se escribe el código,^ pero ,cada una de ellas debería de afectar solamente a una pequeña parte del programa. Debido a esto, el código del programa es la representación Última de la solución del problema, así la forma en que se escriba será importante para el buen mantenimiento y futuras extensiones del sistema.

El diseño detallado debe llevarse hasta un nivel donde. cada proposición en la notación del diseño resulte en unas 'cuantas (menos de 10) proposiciones en el lenguaje de implementación. Dadas las especificaciones arquitectónicas y de diseño detallado, cualquier programador familiarizado con el lenguaje de instrumentación debe ser capaz de implantar el producto de la programación. De esta manera al diseñar el detalle de cualquier sistema antes de llegar a la implementación, sin importar e¡ estilo o paradigma de programación que se vaya a utilizar, siempre s e tendrá un mejor control de los detalles y flujos de control del sistema para futuros imprevistos de correcciones y mantenimiento.

-

2.2.3.3 Métodos y técnicas tradicionales de diseño detallado

Los fundamentos del diseño procedimental iniciaron en los años ~ O ' S , a traves de construcciones estructuradas, que son kagmentos lógicos que reconocen elementos a nivel de instrumentación de un módulo en lugar de leer el diseño del código línea a línea, mejorando la comprensión cuando se encuentran formas lógicas fácilmente reconocibles, que se dan a través de tres construcciones estructuradas básicas la secuencial. la condicional y la de repetición, dando origen a la técnica de programación estructurada[4].

Aunque estas técnicas son nombradas como metodologias de diseño, en realidad son sólo puntos de vista y guías para el diseño; el diseño de productos de programación es una actividad creativa y como en todo proceso creativo, un marco de trabajo, así como un punto

cenidet 2003 15

- i: c. I Capliiil

Capitulo 2 : M c o T E ~ R I C O

El lado izquierdo del diagrama Warnier representa la panorámica, Conforme el analista se mueve de izquierda a derecha, el sistema es descompuesto en subsistemas más Pequeños. El desarrollo de diagramas Warnier es único, debido a que, una vez que está definda la estructura general, el anaiista comienza con la salida y trabaja hacia atrás, A diferencia de la gráfica N-S, se puede dejar suficiente espacio para hacer cualquier modificación necesaria. Wamier es una técnica que utiliza una representación semejante a la de cuadros sinópticos para mostrar el funcionamiento y organización de los elementos que conforman el algoritmo. Básicamente, utiliza una notación de llaves para organizar los módulos y se auxilia en otras simbologías para indicar operaciones de control.

2.2.3.3.4 Diagramas Nassi-Schneidermao N-S(8]

Estos diagramas son usados para mostrar procesos estructurados de control. Los diagramas N-S sirven como apoyo para la programación estructurada, reuniendo caractensticas gráficas propias de los diagramas de flujo y del pseudocódigo. Consta de una serie de cajas contiguas que se leerán siempre de arriba hacia abajo y se documentarán de forma adecuada. Estos diagramas utilizan las tres estructuras básicas de la programación estructurada como las secuenciales, selectivas y de repetición. Este tipo de diagramas aparentemente nos pueden ser muy útiles para muchas aplicaciones, pero en realidad también muestran algunas deficiencias, una de ellas es que no puede mostrar una. identación para los subprocesos de selección, también son más dificiles de interpretar al momento de utilizar varias iteraciones. 'Aunque Nassi-Schneiderman utiliza su propia notación para mostrar una selección, no es posible mostrar suhconjuntos de acciones relacionadas, y además resultan más dificiles de modificar.

' . La'mayona de 1%. técnicas presentan ciertas deficiencias dependiendo de la aplicación que se les quiera dar, aunque todas sirven para representar un nivel de detalle de los procesos de programa, tienen una aplicación más general y resultan dificiles de modificar y no son muy convenientes para los desarrolladores que necesitan aplicar 10s nuevos paradipas de programación en sus diseños, ya que éstos fueron pensados de acuerdo al paradigma de programación por procedimientos.

2.2.3.4 Diseño detallado orientado a objetos

En esta fase del diseño es donde los métodos de clases son definidos, siendo muy importante cuidar los aspectos de reutilización, debido a que, las clases y los métodos constituyen la interfaz de los componentes que se utilizarán en los desarrollos orientados a objetos. El propósito del diseño es, la especificación de una solución viable para facilitar la traducción a un código de programación. Las clases definidas en el análisis son detalladas y descritas a través de un diseño dinámico de ellas.

El diseño puede ser dividido en dos partes[9]:

Diseño Arquitectónico. Este es un diseño de nivel alto, en donde los paquetes (subsistemas) son definidos, incluyendo los mecanismos de comunicación básicos entre ellos.

cenider 2003 17

Capitiilo 2 : MARCO TEÓRICO

~ i ~ ~ f i ~ detallado. Esta parte Se encarga de detallar los coiiteliidos de 10s subsisteiiias, de tal manera, que todas i a s ~ clases son descritas en detalles Para dar una especificación clara para'éI programador, quien es el que va a codificar las chses.

El diseRo detallado.orieiitado a objetos nos ayuda a describir nuevas clases. Esto hace que se creen nuevos diagramas de clases, diagramas de estados y diagramas dinámicos (como de secuencia, colaboración y. de actividades), estos diagramas se usan de manera similar en el análisis, pero en esta fase de diseño son definidos a mayor nivel de detalle.

I1

Con el diseño de objetos se realiza una aproximación orientando el modelo para poder realizar una implementación práctica. Con respecto al detalle de los objetos, se definen operaciones correspondientes " al modelo dinámico del sistema, dependiendo de ' la implementación que se le quiera dar. Se diseñan algoritmos para implementar las operaciones de los métodos de las clases y se selecciona una estructura de datos adecuada para esos algoritmos.

En la programación orientada a objetos se puede explicar el diseño detallado como una parte que corresponde a la descripción de los objetos, ya que ésta se puede dar de dos formas básicamente: Una de ellas es, a través de los mensajes que reciben entre ellos y las operaciones que realizan al recibirlos (interacción entre objetos). La otra tiene que ver con el objetivo de esta tesis, en donde se describe la implementación de los métodos u operaciones de cada objeto, mostrando los detalles de las operaciones implicadas 'en la recepción de los mensajes, proporcionando detalles intemos requeridos para su posterior codificación [lo].

En general se pueden inencioiiar los siguientes puntos comunes en la fase de diseño detallado de los métodos de las clases:

El protocolo de comunicación lo constituyen las interfaces de las clases, los métodos públicos de las clases. Utilizando un ptotocolo estándar, los objetos mantienen una interfaz similar y una.fonna común de nombrar los métodos. Deben evitarse las clases demasiado grandes, transformándose en nuevas abstracciones o en pequeñas jerarquías de herencia. Cada método debe realizar sólo una tarea. De esta forma, el protocolo de la clase será más fácil de entender y por lo tanto ink fácil de reutilizar. Cuidar que el protocolo total .de la clase sea pequeño. El protocolo total de una clase consiste en todos los métodos definidos en la clase y en iodos los métodos heredados de sus superclases que no han sido redefinidos o anulados. Si se tienen muchos métodos en las clases :de los últimos niveles de la jerarquía de herencia, se tiene una abstracción muy compleja, y esta jerarquía puede ser dividida eii varias j erarquías más pequeñas y menos complejas. Cada método de una clase debe realizar una función específica, lo que considera la autononiia de cada uno de ellos.

SDDOO es una Iierramienta que 'fue construida para el diseño detallado de los ,métodos de las clases de un cisterna orientado a objetos, basándose en el modelado dinámico de un sistema OO. Con esta herramienta de software, se apoya al diseñador en la generación

18 ceiiidef 20113

Capítulo 2 : MARCO TEÓRICO

de un modelo visual de los métodos de las clases, proporcionando una documentación importante del diseño antes de su codificación. Además, tomando en cuenta que, a partir de los modelos generados por SIDDOO, en un trabajo futuro, se podna generar el código de dichos modelos en forma automática.

2.3 E1 modelado como técnica de diseño

El diseño de sistemas es la estrategia de alto nivel para resolver problemas y construir una solución. Durante la fase de diseño, se toman decisiones de la forma en que se resolverá el problema, primero desde un nivel elevado y después empleando niveles cada vez más detallados. En el diseño se decide la estructura y el estilo global del sistema[ 111. Para poder representar cualquier nivel de diseño en la resolución de un problema, se hace a través de modelos, por esto, el modelado se considera como una técnica de diseño.

Un modelo es una abstracción que proporciona una simplificación de la realidad, cuyo objetivo es comprenderlo antes de constniirlo o compararlo[l2]. La abstracción es una capacidad humana que nos permite enfrentar la complejidad. Los ingenieros y artistas han estado construyendo modelos durante miles de años para probar los diseños antes de ejecutarlos. En el desarrollo de sistemas de software no es la excepción; para construir sistemas complejos, el desarrollador debe abstraer distintas vistas del sistema, construir modelos utilizando notaciones precisas, verificar que los modelos satisfagan los requisitos del sistema y añadir gradualmente, elementos para transformar los modelos en una implementación.

La construcción de modelos en el diseño tiene varios objetivos: Probar una entidad fisica antes de construirla, de esta manera tanto los modelos físicos como los modelos por computadora suelen ser más baratos que construir un sistema completo, lo que hace posible corregir desde un principio los errores. Otro objetivo es la comunicación. con el cliente, siempre un diseñador construye un modelo para mostrárselo a su cliente, ayudando a cumplir con otro objetivo que es el de la visualización. La reducción de la complejidad es otro objetivo, la mente humana solamente puede almacenar simultáneamente una cantidad limitada de información. Los modelos reducen la complejidad, separando un pequeño número de cosas importantes para tratarlas por separado, al poder presentar diferentes niveles de abstracción con los modelos[l3].

2.3.1 Modelado Orientado a objetos

Los desarrollos de sistemas orientados a objetos promueven una nueva forma de pensar. El modelado y diseño orientado a objetos también constituye una nueva forma de pensar acerca de los problemas empleando modelos que se organizan tomando como base conceptos del mundo real. Los modelos orientados a objetos son Útiles para comprender problemas, comunicarse con expertos en esa aplicación, modelar empresas y diseñar programas y bases de datos.

La tecnología O 0 se apoya en los sólidos fundamentos de la ingenieria, cuyos elementos reciben el nombre global de modelo de objetos. El modelo de objetos abarca los

cenidet 2003 19

1 “.Y..;.+ *;.

Capliiilo 2 : MARCO TEÓRICO

principios de abstracción, encapsulación, niodularidad, jerarquía, tipos, concurrencia y persistencia. Ninguno de estos principios es nuevo por sí’ mismo. Lo importante del modelado de objetos es el hecho de conjugar todos estos elementos de forma sinérgica[l4].

2.3.2 Modelado con UML

EL lenguaje Unificado, de Modelado UML es un lenguaje de modelado visual We se usa para especificar, visualizar, construir y documentar artefactos de un sistema de software. y ullo .de 10s objetivos finales de UML es ser tan siinpk como fuera posible Pero iiiatitetiietido la capacidad de modelar toda la gania de sistemas que se necesita construir. UML tiene varios tipos de inodelos. C o s conceptos y niodelos de UML pueden agniparse en las siguientes áreas conceptuales:

‘1

Estrucfi~ru esiútica. Cualquier modelo primero debe definir el universo del discurso, esto es, los conceptos clave de la aplicación, sus propiedades internas, y las relaciones entre cada una. A esto se le denomina vista estática. Los conceptos de la aplicación son niodelados como clases, cada una describe un conjunto objetos discretos que almacenan información y se comunican para implementar un comportamiento. La información que almacenan es modelada como atributos; El comportamiento que realizan es modelado coino operaciones. Coinporlamierito dinúniico. Hay dos formas de modelar el coniportainiento. Una es la historia de la vida de un objeto, que muestra la forma que interactúan con el resto del mundo. La otra sbn los patrones de comunicación de un conjunto de objetos conectados, que muestra cómo interactúan para implementar su comportamiento. Construcciories de inrpleinentución. Los modelos de UML tienen significado para el análisis lógico y para la implemeiitación física. Ciertos constructores representan elementos de implementación. Organización del nioúelo. En un sistema grande, la información del modelo debe ser dividida en piezas coherentes. En el diagrama de clases, pueden incluirse entidades conocidas como “paqúetes” para dividir ‘y organizar mejor un sistema.

Cuando construimos sistemas con üML, no necesariamente se constmye un simple modelo. Existen distintos inohelos en las diferentes fases del desarrollo, y cada modelo tiene propósitos distintos. En la fase de análisis, el propósito del modelo es, para capturar los requerimientos del sistema y para modelar las clases y colaboraciones básicas del inundo real. Eii la fase de diseño el propósito del modelado es para extender los modelos del aliálisis a través de una solución técnica, con consideraciones para e l ainbieiite de iinplemeiitación. En la fase de impleinentación, el inodelado es el código fuente actual que es programado y conipilado en algún lenguaje de programación [15]. Como se puede ver en la figura 2 un sistema puede ser descrito a partir de varios inodelos.

6

6

I/

20

Figura 3. Modelos de un sistema.

El proceso de modelado con UML no es una tarea sencilla. Cuando se inicia, se realizan varias propuestas que modelan la solución del problema que se quiere resolver en las diferentes fases del desarrollo. En ocasiones, los primeros modelos se hacen de manera informal, donde se dan ideas por el grupo de desarrolladores para considerar posibles cambios. Un modelo, por io regular, se va detallando poco a poco, a través de este proceso se van detectando más detalles sobre la solución del problema y se van documentando. Cuando el modelo es terminado, se realiza una integración y verificación, io que permite que el modelo o diagrama inicie una. integración con otros diagramas o modelos de un mismo proyecto,’ para estar ‘seguros de que no existen inconsistencias. Además, el modelo es validado para verificar que resuelve el problema de forma correcta[ 161.

2.3.2.1 Modelado . . de aspectos dinámicos con UML

Las relaciones dinámicas son d ificiles d e c omprender d e m anera rápida. Lo m ejor para entender un sistema es, primero examinar su estructura estática, considerando los objetos y sus relaciones entre ellos. Después, se examinan los cambios de los objetos y sus relaciones con el tiempo. Los aspectos del sistema que están relacionados con el tiempo y con los cambios constituyen el modelo dinámico[l7].

Todos los sistemas de software tienen m a estructura estática y un comportamiento dinámico, y UML provee al desarrollador notaciones (diagramas) para capturar y describir esos dos aspectos. Los diagramas de clases son los más usados para documentar y expresar la estructura estática de un sistema, mostrando las clases, los objetos y sus relaciones entre ellos. Los diagramas de estados, secuencias, colaboración, y actividades son usados para expresar el comportamiento dinámico de un sistema, en donde se demuestra cómo los objetos interactúan dinámicamente durante la ejecución de un sistema[ 181.

Los objetos dentro de un sistema se comunican con otros objetos; ellos envían mensajes a otros objetos. Un mensaje es básicamente una llamada a una operación que, un objeto invoca sobre otro objeto. Como la comunicación de objetos y los efectos de dicha comunicación, &refieren a la dinámica de un sistema; de esta manera, es como los objetos colaboran en la comunicación y cómo estos objetos dentro del sistema cambian de estado en el tiempo de vida del sistema. La comunicación entre objetos es denominada interacción, la cual puede describir por tres clases de diagramas de UML: secuencia, colaboración O actividades.

21

Cqdiiilo 2 : MARCOTE6RIco .!

2.3.2.1.1 Diagramas de actividades de UML. '1

uii0 de los diagramas de UML usados para el modelado dinámico, son'los diagramas de actividades, L~~ diagramas de actividades son usados normalmente Para el control de un flujo secuel,cial, en donde un diagrama puede ser conectado a una operación dentro de una clase, modelar algunos sistemas de tiempo real, para el modelado de Procesos de negocios etc. Eli e I preseiite trabajo de tesis, estos diagramas son ~ a d o s Para n d e l a r diseño detallado de las clases de un sistema OO.

Uii diagrama de actividades 'es uno de los diagramas 'de UML para el modelado de aspectos dinámicos de un sistema OO. Un diagrama de actividades, se puede usar como u11 diagrama de flujo que muestra el flujo de control .de actividad en actividad. A través de actividades se muesiran los pasos, puntos de decisión y bifurcaciones, y es útil para representar las operaciones de un objeto y'los procesos de negocios o flujos de trabajo en una organización[ 191.

Los diagramas de actividades han sido diseñados para mostrar una visión simplificada de lo que ocurre durante una operación o proceso. Además de modelar los aspectos dinámicos, muestran la secuencia de acciones, las acciones concurrentes y íos pasos dentro de un proceso computacional, modelando el flujo de control de una operación. Con los diagramas de actividades se puede modelar el flujo de un objeto, y cómo se mueve éste de un estado a otro en diferentes puntos de un flujo de control, también pueden ser usados para modelar el' flujo de control de una operación, además pueden ser' utilizados para la ingeniería inversa como se menciona más adelante.

Los diagramas de acthdades siempre van'unidos a una clase o a la implementación de un caso de uso o de un método .(que tiene el mismo significado que en cualquier otra metodología 00). Estos diagramas se utilizaripara mostrar el flujo de operaciones que se desencadenan en un procedimiento interno del 'sistema. Estos diagramas nos permiten seleccionar el.orden en que lbse harán las cosas. Esto es, que dicta las reglas esenciales de secuenciación que se tienen,que seguir. Esta es la diferencia clave entre un diagrama de actividad y un diagrama de flujo. Los diagramas de flujo se limitan normalmente a procesos secuenciales; los diagramas de actividades pueden manejar procesos paralelos. Esto permite nlejorar la eficiencia y capacidad de respuesta de los procesos de negocio o flujos de trabajo de una organización, porque evitaría la ejecución de procesos secuenciales innecesarios[20].

¡I

Aunque se considera que un diagrama de actividades es, un caso especial de diagrama de estados y los dos pueden modelar los aspectos dinámicos de un sistema. Así, tanto los diagramas de actividades como los de estados son útiles para modelar la vida de un objeto. Sin embargo, mientras udiagrama de actividades muestra el flujo de coiitrol eritre actividades, que pueden describir el estado de un objeto, un diagrama de estados muestra el flujo entre estados de un objeto en p&ticular[22]. Además, lo que distingue a estos dos tipos de diagramas es, que con los diagramas de estados es imposible modelar el detalle de los métodos de una clase, por otra parte, los diagramas de actividades sí penniten inodelar a ese nivel de detalle. Por tal motivo, se optó por el uso de los diagramas de aciividades para lograr el objetivo de este trabajo, que es modelar el diseño detallado de los niétodos de las clases de un sistema OO.

22 ccr1Idl.i 2003

Capitdo 2 : MARCO T E ~ R I C O

Los diagramas de actividades son Útiles en los flujos de trabajo y para la descnpción del comportamiento que tiene una gran cantidad de procesos en paralelo. Para concluir, se dice que los diagramas de actividades no se pueden aplicar cuando: Se trata de ver como colaboran los objetos, es mejor usar un diagrama de interacción. Y cuando se trata de ver cómo se comporta un objeto durante su periodo de vida, mejor usar un diagrama de estados.

2.3.2.1.2 Aplicaciones con diagramas de actividades

Un .diagrama de actividades se puede usar junto con los diagramas de colaboración para especificar el comportamiento de un caso de uso. Por lo general se usan los diagramas de actividad de dos formas:[21]

1. Para modelar un flujo de trabajo. Los diagramas de actividades son utilizados para visualizar, especificar, construir y documentar procesos de negocios que envuelven el sistema que se esta desarrollando, aquí el modelado del flujo de objetos es lo más importante. Estos procesos de negocios son tipos de flujo de trabajo porque .representan el flujo de trabajo y objetos a, través del negocio. Los diagramas de actividades pueden, utilizarse para modelar los procesos de negocio, en los que colaboran los sistemas automáticos como pueden ser: de punto de venta, de mercado y/o almacén y humanos.

Para modelado d e operaciones. Aquí s e v a a utilizar u n diagrama d e actividades como un.flujo de datos, para modelar los detalles de un proceso computacional, En este uso de los diagramas de actividades el modelado de bifurcaciones, divisiones y uniones de actividades es lo más importante. La utilización de los diagramas de actividades para hacer una especie de diagrama de flujo de una operación es casi hacer de UML un lenguaje de programación visual. Por lo general, se utilizarán los diagramas de actividades para modelar una operación, cuando el comportamiento sea más complejo y, por lo tanto, dificil de comprender mediante una simple observación del código. De esta manera un diagrama de actividades puede revelar cosas sobre el algoritmo que no se podrán observar simplemente mirando el código.

Otra aplicación que los diagramas de actividades pueden tener es, que a partir de ellos se puede hacer la Ingeniería directa e inversa. La ingenieria directa (creación de código a partir de un modelo) se puede realizar especialmente si el contexto del diagrama representa una operación, lo que generaría el código en forma automática. La ingenieria inversa (creación de un modelo a partir del código) también es posible con los diagramas de actividades, considerando que el código represente el cuerpo de una operación[22].

2.3.2.2 Alcances con respecto a UML

2.

Aunque dentro de los diferentes diagramas para el modelado que se definen en UML, no existe una notación destinada para modelar los métodos de las clases de un sistema OO. En este trabajo de tesis se está aplicando uno.de los diagramas de UML, para modelar los detalles de los métodos de las clases. Como se ha mencionado, dentro de UML existen varios diagramas que son usados para modelar los aspectos dinámicos de un sistema, que

cenidet 2003 . 23

Cnpí~~do 2 : MARCO TE6RIco

pueden ser utilizados en variks aplicaciones dentro del proceso de análisis y diseño. Considerando los elementos gráficos y la flexibilidad para modelar diferentes aplicaciones, son los diagramas de actividades 'los que más ventajas proporcioiian en este sentido y por consecuencia ayudan a cumplir con los objetivos planteados en el capítulo 1.

Aprovechando el poder "expresivo de UML para los diferentes niveles de abstracción que se pueden presentar en el análisis y diseño de un sistema 00; se usan los diagramas de actividad para modelar el diseño detallado de los métodos de las clases de un sistema 00 por convenir a logro de los alcances de esta tesis.

'I

. .

2.4 Lenguajes y Gramáticas visuales.

Los lenguajes visuales han llegado a ser, una nueva lierraiiiieiita para los programadores de computadoras. Estos lenguajes penniten mejorar la interaccióii con los usuarios de sus aplicaciones, escribir un menor número de líneas de código y agilizar el tiempo de implementación. Con esta nueva forma de programar, ha surgido un nuevo paradigma: la programación basada en iconos, en donde el desarrollador puede crear, modificar y combinar pequeños objetos pictóricos llamados iconos con propiedades definidas y capaces de ejecutar una acción computacional.

Actualmente, muchos 'he los lenguajes de programación visual utilizan el paradigma de los iconos, pero ¿qué es la programación visual?. Ésta se entiende como el uso de expresiones visuales tales como dibujos, gráficas e iconos, o lo que se refiere a cualquier sistema que permita especificar un programa en forma de dos dimensiones.

2.4.1 Conceptos y aplicaciones.

Definición de lenguaje visual

Un lenguaje visual, consiste de oraciones visuales. Cada oración visual es una colocación espacial de objeios gráficos o iconos relacionados que comunican algo. De acuerdo a esta definición, un lenguaje visual puede-ser aplicado a un número diferente de representaciones, en donde su significado está dado por las relaciones que guardan los elementos visuales.

Ib Dentro de la especificación formal de los ienguajes de programación visual, la

composición espacial de iconos, que constituye una insmicción visual, es la contraparte bidimensional de la composición de oraciones en los lenguajes de programación textuales. En estos últimos, un programa se expresa como una cadena de oraciones concatenadas, que forman una insttucción cuya estructura y significado, son analizados sintáctica y semánticamente. Por su parte, en los lenguajes visuales se pudieran distinguir tres reglas generales de construcción, que se usan para componer. los iconos espacialmente: la concatenación horizontal, Id concatenación vertical, ¡as que representan las relaciones de enlace entre objetos gráfic0s.y la sobre-posición espacial[23].

ceiririet 2003 24

Capitulo 2 : MARCO T E ~ R I C O

Existen tres principales aproximaciones para ia especificación de lenguajes visuales: El enfoque gramatical, el enfoque de ia lógica y el enfoque algebraico. Aquí se hará' referencia a la forma gramatical para'la especificación de un,lenguaje visual, una gramática Para un lenguaje visual, está basada en el formalismo gramatical usado para 1; especificación de lenguajes de cadenas. Los lenguajes de cadenas, están formados por un conjunto de símbolos no terminales y terminales, un símbolo inicial y un conjunto de reglas de producción[24].

Una gramática es, el conjunto de regias por medio de las cuales se construyen expresiones válidas de un lenguaje. Las gramáticas ofrecen ventajas significativas a los diseñadores de lenguajes, ya que a través de ellas se especifica una sintaxis precisa y fácil de entender de un lenguaje de programación y también permiten construir analizadores sintácticos, para determinar si un programa es sintacticamente correcto:

Desde la aparición de los lenguajes visuales, han surgido nuevas gramáticas que permiten definir de una manera formal las expresiones de dichos lenguajes. Una de las principales motivaciones para el desarrollo y formalización de gramática gráficas (visuales) fue la gran necesidad de procesar imágenes. Por más de treinta años investigaciones han sido dedicadas a las gramáticas gráficas y a sus aplicaciones para el procesamiento de imágenes y reconocimiento de diagramas.

Para definir .una gramática visual, primero se debe identificar el tipo de lenguaje visual que es, considerando los siguientes puntos: primero debe delimitarse el dominio de aplicación, después se deben identificar los elementos que forman parte de ese dominio, definir las relaciones válidas con elementos dentro del mismo dominio y, finalmente, deteminar el comportamiento de las relaciones [25]. Con esto, se puede detemiinar, que tipo de gramática visual se puede utilizar para definir dicho lenguaje.

Cuando se utilizan las gramáticas textuales para definir un lenguaje visual, esto da como resultado un conjunto de elementos textuales combinado con elementos gráficos, indicando un orden secuencial en alguna oración reconocida por dicho lenguaje [26]. Esto marca ciertas limitantes para la flexibilidad que debe tener un lenguaje visual en la construcción de sus oraciones visuales, como son, la ubicación espacial. yIo la relación de enlace o conexión, lo que demuestra que cada elemento visual no será presentado necesariamente de forma secuencial, ya que debe dar cierta libertad en la construcción de sus oraciones. Por lo tanto, considerando que el lenguaje que se define para el modelado del diseño detallado, es un lenguaje visual, lo ideal para la definición de un lenguaje de este tipo es hacer uso de una gramática visual.

2.4.2 Clasificación de las gramáticas visuales

Existen muchas gramáticas que son consideradas como métodos formales para la especificación formal de lenguajes visuales. Aquí se hará referencia a algunas de ellas.

Gramáticas de cadena generalizada. Modifican las gramáticas de cadenas, proporcionando una generalización de la concatenación de dos dimensiones. La ventaja de utilizar esta gramática es, que representa un soporte para la teoría de

cenidet 2003 25

ric"r.-ux . , . . a

Capliulo 2 : MARCO TEÓRICo

cadenas y dcl eficietiie algoritmo de parseo. Su desventaja es que son gramáticas que no son muy poderosas pokque solamente especifican clases restrictivas de lenguajes visuales. No pueden aplicarse de manera general a los lenguajes visitales, porque SUS composiciones son limitadas.

Grai~~áttcas de relactóh d e sirr16olos (SR). Permite la reescritura d e setitencias, a partir de los símbolos terminales y no terminales, mediante la representación de objetos gráficos, así como reglas de evaluación para rescribir las restricciones. Éste es un formalismo sintáctico para describir un lenguaje visual, donde cada oración deiiíro del lenguajc se represcnla como un conjunto de objeíos visuales y un conjunto de relaciones entre objeíos [27].

Grardficas posiciortales. Las gramáticas posicionales extienden de manera natural a las gramáticas libres de contexto (GLC) para lenguajes .textuales, al considerar nuevas relaciones aparte de la concatenación de cadenas. De manera transitiva, la conocida eficiencia de los analizadores LR para GLC puede llevarse a las gramáticas posicionales. Estas gramáticas ayudan a definir ubicaciones espaciales de objetos, así como las relaciones de enlace entre ellos [28].

Aplicación de las gramáticas posicionales

Considerando que el lenguaje que.se utilizará para el modelado de los diagramas es estrictamente visual. El formalisino'utilizado para la definición de lenguajes de modelado visual es el de las grarnúficus posicioizules. Con una gramática textual (libre de contexto), solo es posible reconocer la concatenación de cadenas o de elementos gramaticales, mientras que, en una posicional se puede definir una colocación espacial ylo una interconexión eníre elementos gráficos. Además las gramáticas posicionales se pueden utilizar directamente en este trabajo de tesis, ya que han sido utilizadas para describir y analizar una gran cantidad de leiiguajes diagramáticos[29]. I

2.4.3

Las gramáticas posicioiiales extienden de manera natural a las gramáticas libres de contexto (GLC) para lenguajes textuales, al considerar nuevas relaciones aparte de la concatenación de cadenas. De manera transitiva, la conocida eficiencia de. los analizadores LR para GLC puede llevarse a'las gramáticas posicionales. Estas gramáticas ayudan a definir ubicaciones espaciales de objetos, así como las relaciones de enlace entre ellos[30].

Los elementos utilizadbs para describir. una gramática del tipo posicional, son muy similares a los utilizados por una GLC. En una posicional, únicamente se agregan dos elementos diferentes que tienen que ver con la posición y las posibles relaciones que tendrán los elementos visuales del lenguaje que sea definido por este tipo de gramáticas. Estos elementos se describen a continuación:

'I ii

POS. Es uti conjunto de identificadores de relación binaria, los cuales nos indicaran el sentido o posición espacial que tendrán los objetos gráficos. PE. Es un evaluador 'kictórico (reglas semánticas de acuerdo a POS). Es una regla de evaluación que convierte oraciones posicionales derivadas de la aplicación de las reglas gramaticales de :acuerdo a su representación gráfica (diagramas).

26 reitideel 2003

Capítulo 2 : MARCO TEORICO

Tanto POS y PE, como los otros elementos que componen la gramática definida para SIDDOO, se describirán con más detalle en el capítulo 4.

2.5 Herramientas CASE

Las Herramientas de ayuda al desarrollo de sistemas de software, surgieron para intentar dar solución a los problemas inherentes a los proyectos de generación de aplicaciones informáticas: plazos y presupuestos incumplidos, insatisfacción del usuario, escasa productividad y baja calidad de los desarrollos. Algunas de estas herramientas se enfocan, principalmente, a mejorar la calidad, como es el caso de las herramientas CASE (Computer Aided Software Engineering-Ingeniería de Software Asistida por Computadora)[3 11.

Las herramientas CASE son programas de computadora que sirven de apoyo a los desarrolladores de software para especificar y diseñar sus productos, permitiendo disminuir la complejidad y los problemas que se presentan en el proceso de desarrollo, enfocándose en las etapas de diseño, en donde se dedica mayor esfuerzo en el diseño antes de llegar a la codificación. El uso de este tipo de herramientas, ayuda a . reducir costos tanto de codificación como de mantenimiento, y a obtener una buena documentación de soporte para los sistemas de software..

Uno de los objetivos principales de las herramientas de este tipo es la automatización de:

01 El desarrollo del software (análisis y diseño). E La documentación. e La generación del código a partir del diseño.

La verificación y corrección de errores.

Además permite la reutilización del software, la portabilidad de los productos generados, así como, la estandarización de la documentación, aspecto sumamente importante p k a el ciclo de vida útil de cualquier sistema.

La principal ventaja de la utilización de una herramienta CASE, es la mejora d e la calidad de los desarrollos realizados y, en segundo término, el aumento de la productividad. Para conseguir estos dos objetivos, es conveniente contar con una organización y una metodología de trabajo, además de la propia herramienta. La mejora de calidad se consigue reduciendo sustancialmente muchos de los problemas de análisis y diseño, inherentes a los proyectos de mediano y gran tamaño (lógica del diseño, coherencia, consolidación, etc.). La mejora de productividad se consigue, a través de la automatización de determinadas tareas como, la generación de código y la reutilización de objetos o módulos.

La herramienta de software SIDDOO que se construyó con el desarrollo de este trabajo de tesis, es considerada como una herramienta CASE, una herramienta de ingeniería de software asistida por computadora, considerada así, debido a que es un sistema que ayuda a los desarrolladores de software a especificar y diseñar un sistema en su última fase, a

cenidet 2003 21

.. ? .,,, ,). . , capimip z : MARCO TEÓRICO

través de modelado visual, antes de llegar a la codificación. .SDDOO es, una herramienta visual para el diseño detallado de los métodos de clases de un sistema orientado a objetos, basado en la notación de los diagramas de actividades de UML.

2.6 Referencias.

Grady Booch. Análisis y diseño orientado a objetos Segunda edición Addison Wesley 1997. p. 32

Conceptos de diseño orientado a objetos. 1997 (página: httD://www.re8chilena.comiservicios/tafs/metodos de doo.htm )

El proceso del diseño de software. 1998 (página : http://www.itce.edu.mx/inesoi?/detalla.htm )

El proceso del diseño de software 1998 (página : hM,://www.itcp.edu.mx/inesoft/detalla.htm )

Luis Joyanes Apilar, Luis Rodriguez. Fundamentos de Programación. Mc Graw Hill. España 1997. p.24

I

'1

t,

ibidem:p. 25 II.

I. A. Parra Ramírez. Modelado Visual O 0 Tesis de Maestría del ,Centro Nacional de investigación y Desarrollo Tecnológico cenidet, 2000

I1

Donal J. Flynn. information Systems Requirements: Determination and Analysis Mc Graw Hill 1992

Hans Erik E, Magnus Penker. UML ToolKit. Wiley USA 1999. p.327,329

Conceptos de diseño orientado a objetos. (Página: hM,:/lwww.r~dchilena.com/senricios/tafs/metodos de doo.hmi 1998

James Rumbaugh, Michael Blaha, W Premerlani, Federic Eddy. Modelado y diseño orientado a objetos. Pentrice Hall. España 1997

G Booch, Jacobson, Rumbaugh. El lenguaje Unificado de Modelado Addison Wesley 1999

James Rumbaugh, Michael Blaha, William P., Frederic Eddy. op. cit., p. 38.

-

cenidei 2003 28

http://www.itce.edu.mx/inesoi?/detalla.htm

Cqiltiilo 2 : MARCO ’r’il6Rico , , ,~ . , . . ... . , ,_ . . . .. .~ . ,., .

Jaines Rumbaugh, Michael Blaha, William P., Frederic Eddy. op. cit., p. 197.

Grady Booch. op. cit., p. 31.

Hans Erik E, Magiius Penker. op. cit., p.31

James Rumbaugh, Michael Blalia, William P., Federic Eddy. op. cit., p. 125

Hans Erik E, Magiius Peiiker. op. cit., p. 119

Hands Erick E, Magnus Penker. op. cit., p.32

G Booch, Jacobson, Rumbaugh. El Lenguaje Unificado de Modelado Addison Wesley 1999. p. 225,226

Martin Fowler, Kendall Scott. UML gota a gota Addison Wesley 1999. p. 150

G Booch, Jacobson, Rumbaugh. op. cit., p.235,237

G Booch, Jacobson, Rumbaugh. op. cit., p.238

Lenguajes visuales. 1999 http://oreto.inf-cr.uclin.es/inprieto/h~e~~YEPLen~uaiesVisualesl .odf

Kim Marriot, Bemd Meyer. Visual Languaje Theory Ed. Springer. New York 1998

G. Costangliola, A de Lucia y G. Toríora, “A Framework of Syntactic Models for de Implementation of Visual Languages”, Universidad de Salermo Italia 1997.

Lenguajes visuales. 1999 hltp://oreto.iiif-cr.ucIni.es/ni~rieto/hvcp/~~YEPLeiinuaiesVisuales 1 .pdf

Kim Marriot, Bemd Mcyer. op. cit., p.128

G. Costaiigliola, A. De Luck y S. Orefice, “ Towars efficient Parsing of diagraiiiatic Languages”, Universidad de Salemio Italia 1994

Kim Marriot, Bemd Meyer. op. cit., p.135

Herramientas CASE http:l/www.coloinlielp.8in.coin/b-case.htiiil

29

http:l/www.coloinlielp.8in.coin/b-case.htiiil

Sistema Visual para el Diseño Detallado de Métodos de Clases con UML

Cupitdo ir

3 ; I/

Estado del Arte. ~

i!

Este capítiilo describe algunas de las metodologías y técnicas usadas actualmente para el análisis y diseño de sistemas orientados a objetos, también, hace referencia a algunas herramientas de análisis y diseño usadas para el modelado los sistemas de software a diferentes niveles de abstracción. Además, se mencionan varios trabajos que se relacionan con la investigación desarrollada eii esta tesis.

Capitulo 3 : ESTADO DEL ARTE

3.1 Introducción

El diseño es una etapa importante en el desarrollo de sistemas de soha re , la cual ha evolucionado a través del tiempo y se han propuesto nuevos métodos, técnicas y herramientas que facilitan y mejoran la calidad de los productos de software; en el área de diseño también se ha tratado de ir acorde a los nuevos modelos de programación, al querer diseñar sistemas cada vez más complejos y m ás grandes, convirtiendo ésto e n una t area dificil para los desarrolladores.

Con el paso del tiempo han surgido varias técnicas y herramientas para el diseño de sistemas, que consideran diferentes niveles de abstracción en sus aplicaciones, como el arquitectónico y en especial el detallado, y algunas llegan a la generación del código de los diseños que construyen. Muchas de estas herramientas se apoyan en UML. En los últimos años se han realizado muchas investigaciones que tienen que ver con las aplicaciones de los diagramas de actividad de UML, tratando de resolver diferentes problemas con su uso, pero, ninguno de estos trabajos se enfoca al objetivo que se tiene con en este trabajo de tesis, en donde, se están aplicando los diagramas de actividades de UML para modelar el diseño detallado de un sistema orientado a objetos.

3.2 Métodos y técnicas de diseño orientadas a objetos

Existe una variedad de métodos y técnicas de análisis y diseño orientado a objetos. Generalmente, en esta área de los métodos 00, existen dos comentes principales, dividiendo a estos en:

Estáticos.(enfocados a datos). En los que Io importante es la estructura de datos, anexa a los objetos .las operaciones que sobre ellos operan. Dinámicos (enfocados a comportamientos o enfocados a responsabilidades). Un objeto tiene sentido en estos métodos cuando exhibe un comportamiento diferencial respecto del resto de los objetos. Tal comportamiento puede referirse bien al objeto en sí (los cambios que pueden operarse en su representación interna) o bien a SUS relaciones con otros objetos.

De acuerdo con esta separación, a continuación se describen algunos métodos, que de alguna manera han tenido mayor trascendencia desde su aparición junto con la tecnologia orientada a objetos.

3.2.1 Metodología OMT [l]

La Técnica de Modelado de Objetos (OMT), es un procedimiento que se basa en aplicar el enfoque orientado a objetos a todo el proceso de desarrollo de un sistema de software, desde el análisis hasta la implementación. Los métodos de análisis y diseño que propone, son independientes del lenguaje