Embed Size (px)
Citation preview
UNIVERSIDAD NACIONAL DE EDUCACIÓN
Enrique Guzmán y Valle
Alma Máter del Magisterio Nacional
FACULTAD DE CIENCIAS
Escuela Profesional de Matemática e Informática
MONOGRÁFIA
UML
Introducción al UML, modelando con UML, utilidad del UML,
conceptos de USE CASE, objetos, clases y atributos, operaciones,
Aplicaciones.
Examen de Suficiencia Profesional Resolución N° 1153-2018-D-FAC
Presentada por:
Tito García, Sandra Rubí
Para optar al Título Profesional de Licenciado en Educación
Especialidad: Informática
Lima, Perú
2018
ii
MONOGRÁFIA
UML
Introducción al UML, modelando con UML, utilidad del UML,
conceptos de USE CASE, objetos, clases y atributos, operaciones,
Aplicaciones.
Línea de investigación: Tecnología y soportes educativos
iii
Dedicatoria
La presente monografía la dedico a nuestro Padre
Celestial, por haberme permitido llegar hasta este
momento importante de mi formación profesional.
A mi esposo y mis hijas por ser los pilares de mi
vida y demostrarme su paciencia y amor
incondicional. A mis padres por estar conmigo en los
momentos más significativos y a mi querido profesor
quien me oriento y guío en el tema.
iv
Índice de contenidos
Portada........................................................................................................................... i
Hoja de firmas de jurado ............................................................................................... ii
Dedicatoria .................................................................................................................. iii
Índice de contenidos .................................................................................................... iv
Lista de tablas .............................................................................................................. vi
Lista de figuras ........................................................................................................... vii
Introducción ............................................................................................................... viii
Capítulo I. Herramientas de modelamiento de datos ...................................................... 9
1.1 Herramientas CASE ............................................................................................... 9
1.2 Proceso de desarrollo de software ......................................................................... 10
1.3 Clasificación de las herramientas CASE ............................................................... 10
1.4 CASE en el ciclo de vida de un sistema ................................................................ 12
1.5 Objetivos de las herramientas CASE ..................................................................... 13
1.6 Estructura de las herramientas CASE ................................................................... 14
1.7 Módulo de Prototipado ......................................................................................... 15
1.8 Proceso de desarrollo: software con herramientas CASE ...................................... 16
1.9 Características principales de las herramientas CASE ........................................... 17
Capítulo II. Lenguaje unificado de modelado (UML) .................................................. 20
2.1 Lenguaje unificado de modelado (UML) .............................................................. 20
2.2 Objetivos del UML .............................................................................................. 22
2.3 Modelando con UML ........................................................................................... 22
2.4 Evolución del UML ............................................................................................. 23
2.5 Beneficios del UML .......................................................................................... 26
v
Capítulo III. Modelo conceptual de UML .................................................................. 28
3.1 Modelo conceptual de UML ................................................................................. 28
3.2 Papel de UML en el diseño Orientado a Objetos (OO) ......................................... 28
3.3 Diagramas en UML .............................................................................................. 29
3.3.1 Diagramas de clase ..................................................................................... 29
3.3.2 Diagrama de objetos ................................................................................... 29
3.3.3 Diagrama de casos de uso ........................................................................... 29
3.3.4 Diagramas de secuencia y colaboración ...................................................... 29
3.3.5 Diagramas de estados ................................................................................. 30
3.3.6 Diagrama de actividades ............................................................................. 30
3.3.7 Diagrama de componentes .......................................................................... 30
3.3.8 Diagramas de despliegue ............................................................................ 30
3.4 Vista de uso de casos............................................................................................ 31
3.5 Características del diagrama Casos de uso (Use case) de UML ............................. 33
3.6 Objetos ................................................................................................................. 35
3.7 Clases................................................................................................................... 36
3.8 Atributos y operaciones ........................................................................................ 37
3.9 Arquitectura del Software ..................................................................................... 39
Aplicación didáctica .................................................................................................... 40
Síntesis ....................................................................................................................... 51
Apreciación crítica y sugerencias ................................................................................ 52
Referencias ................................................................................................................. 53
vi
Lista de tablas
Tabla 1. Ventajas y desventajas de las herramientas CASE ......................................... 12
vii
Lista de figuras
Figura 1. Herramientas CASE y su ciclo de vida ......................................................... 13
Figura 2. Diagrama de un repositorio .......................................................................... 15
Figura 3. Ciclo de vida: diseño–prototipo–producción ................................................. 16
Figura 4. Arquitectura jerárquica de las herramientas CASE ....................................... 17
Figura 5. Intercambio de datos. ................................................................................... 18
Figura 6. Integración Total de herramientas CASE ...................................................... 19
Figura 7. Diagrama de despliegue ............................................................................... 31
Figura 8. Vistas del modelado de un sistema ............................................................... 31
Figura 9. Posicionamiento de Casos de uso (Use CASE) ............................................. 34
Figura10.Como cliente y cliente comercial .................................................................. 35
Figura11.Organización de los casos de uso .................................................................. 37
Figura12. Atributos ..................................................................................................... 38
Figura13. Operaciones ......................................................................................................... 38
viii
Introducción
UML en siglas en inglés: Unified Modeling Languaje, que significa Lenguaje de
modelamiento unificado, es una aplicación utilizada para dar especificaciones,
construcción, visualización y documentación de un sistema de software orientado a objetos
(OO).
Es un lenguaje visual para la documentación de proyectos y los estándares de
software, se puede aplicar en varias áreas diferentes y puede documentar y transmitir
cualquier cosa desde los principios de la empresa hasta los procesos de negocio y el
software, representando todos los procesos y procedimientos mediante una notación que es
sencillo en su aprendizaje y en su escritura, generalmente empleando un formato visual
combinado con la notación gráfica, la cual se ha convertido en un modelo de aplicaciones
de software y cada vez es más utilizado en el mundo del desarrollo del software.
Esta monografía la vamos a dividir en tres capítulos, en el primero describiremos lo
que son las herramientas de modelamiento de datos, lo que son las herramientas CASE su
clasificación, objetivos, características y sus ponderaciones en su utilización. En el
segundo capítulo definiremos lo que es el lenguaje unificado de modelado (UML), sus
objetivos, su evolución y los principales beneficios que tiene. En el tercer capítulo
describiremos el modelo conceptual del UML y sus diversas formas y diagramas. Por
último se presenta la aplicación didáctica, la síntesis, las apreciaciones y sugerencias y las
referencias bibliográficas.
9
Capítulo I
Herramientas de modelamiento de datos
1.1 Herramientas CASE
“Las herramientas CASE se definen como un grupo de programas, empleadas para
automatizar las actividades en el ciclo de vida del desarrollo de sistemas o SDLC”
(Quinteros, 2015, p.18). Es un lenguaje visual para la documentación de proyectos y los
estándares de software, se puede aplicar en varias áreas diferentes y puede documentar y
transmitir cualquier cosa desde el proceso más básico de la empresa hasta los procesos de
negocio y el software, representándolos mediante una notación que es sencillo en su
aprendizaje y en su escritura, generalmente empleando un formato visual combinado con
la notación gráfica, la cual se ha convertido en un modelo de aplicaciones de software y
cada vez es más utilizado en el mundo del desarrollo del software.
Tenemos actualmente muchas herramientas CASE a disposición, las cuales
principalmente nos permiten facilitar los procesos en las etapas del ciclo de vida del
desarrollo de software, es decir estas herramientas nos facilitan realizar el análisis y
diseño, la gestión de proyectos en su parte operativa, en el diseño de la base de datos, en la
generación de documentación, entre otras actividades.
10
“La utilización de herramientas CASE permite la aceleración y optimización del
desarrollo del proyecto, produciendo finalmente los resultados deseados, además permite
ayudar a reconocer fallas antes de seguir con la siguiente etapa en el desarrollo de
software” (Quinteros, 2015, p.25).
1.2 Proceso de desarrollo de software
Tiene pasos definidos, el cual permite elaborar un software con un buen diseño y sobre
todo de forma mantenible. Asimismo, hay que tener en cuenta las etapas.
Las etapas son las siguientes:
• Análisis
• Diseño
• Implementación
• Integración y documentación.
• Mantenimiento
• Reingeniería
1.3 Clasificación de las herramientas CASE
Lo más importante que tienen las herramientas CASE es que los programas adicionados
permiten realizar el análisis de los sistemas que se encuentran en desarrollo con el fin de
mejorar sus calidad y permitir mejorar sus resultados. Estas herramientas en la década de
1990 representaron una parte muy importante de la ingeniería del software, siendo
utilizada por las empresas más importantes del desarrollo del software.
Fawler (2009) indica que “se incorporan varias herramientas en CASE y se
denominan herramientas CASE, que se utilizan para admitir diferentes etapas e hitos en un
ciclo de vida de desarrollo de software las cuales son”: (p. 37).
11
Por su amplitud tenemos:
• Toolkit, que permite automatizar las fases del ciclo de vida del sistema informático.
• Workbench, las que ayudan a dar soporte para automatizar el proceso de desarrollo
completo del sistema informático, es decir no aporta el código ejecutable y la
documentación.
Por las tareas que automatizan:
• Upper case, se encargan de planificar y requerir el desarrollo funcional del
desarrollo del sistema informático.
• Middle case, se encargan del análisis y diseño del sistema informático.
• Lower case, generarán los códigos para la implantación.
También tenemos:
CASE. Analista (Macroproyecto)). El resultado de tales herramientas es la
especificación de los componentes e interfaces del sistema, la arquitectura del sistema,
los algoritmos y las estructuras de datos; herramientas de diseño de bases de datos que
proporcionan modelado de datos y generación de esquemas de bases de datos
(generalmente en SQL) para los DBMS más comunes. Las principales herramientas
son ERwin, S-Designor y DataBase Designer (ORACLE), también se tienen a las que
permiten diseñar bases de datos también como Vantage Team Builder, Designer /
2000, Silverrun y PRO-IV CASE. Estos incluyen herramientas 4GL (Uniface
(Compuware), JAM (JYACC), PowerBuilder (Sybase), Developer / 2000 (ORACLE),
New Era (Informix), SQL Windows (Gupta), Delphi (Borland, etc.) y generadores
códigos incluidos en Vantage Team Builder, PRO-IV y parcialmente en Silverrun;
herramientas de reingeniería que proporcionan análisis de códigos de programa y
esquemas de bases de datos y la formación de varios modelos y especificaciones de
diseño sobre la base de ellos. Sobre la realización del análisis de esquemas en las
12
bases de datos y de herramientas de generación de ERD podemos tener a Vantage
Team Builder, Erwing, PRO-IV, Silverrun, Designer / 2000 y S-Designor. Sobre los
especializados en el código de lenguajes de programación, estas están orientadas a
objetos que proporcionan reingeniería de programas C ++ (Rational Rose, Object
Team).
Tabla 1
Ventajas y desventajas de las herramientas CASE
Nota: Descripción de las ventajas y desventajas de las herramientas CASE. Fuente: Quintero, 2015.
1.4 CASE en el ciclo de vida de un sistema
De acuerdo a Quinteros (2015), “Observamos las etapas del ciclo de vida del desarrollo de
un software, empleando Herramientas CASE” (p. 26).
Tipo Ventajas Desventajas
Upper Case -Empleada en diversas
plataformas de PC y se puede
aplicar en entornos distintos.
-El costo es bajo.
-Permite mejorar aspectos de
calidad pero no de productividad.
-Se integra en el ciclo de vida de
un sistema de información.
Lower Case -Permite mejorar en tiempos
reducidos su productividad.
-En cuanto al soporte es
considerado como bueno.
-Sobre la persistencia en niveles
corporativos no lo garantiza.
-De igual modo en el análisis y
diseño no garantiza su eficiencia.
-En el ciclo de vida no es
permitida su integración.
I –Case -Se encuentra integrado en el
ciclo de vida.
-En cuanto a la productividad es
mejorada a mediano plazo.
-Sobre el soporte de
mantenimiento es bueno.
-Los niveles corporativos en
cuanto a la persistencia son
mantenidos.
-Funciona eficientemente en
niveles complejos, pero no
garantiza en niveles simples.
-Está en función del hardware y
software.
-Costos elevados.
13
Las herramientas CASE pueden intervenir en todas las fases del ciclo de vida de un
sistema, bajos modelos específicos que permiten optimizar la ejecución de estas, desde el
análisis, el diseño del sistema, sobre todo en la correspondiente a la base de datos.
Figura 1. Herramientas CASE y su ciclo de vida. Fuente: Quintero, 2015.
1.5 Objetivos de las herramientas CASE
En general, los objetivos aceptados de las herramientas CASE son:
A nivel de proyecto:
• Mejorar la calidad de los sistemas desarrollados.
• Mejorar la calidad y la integridad de la documentación.
• Aumentar la velocidad de desarrollo y diseño.
• Facilite y mejore el proceso de prueba a través de la verificación automática
• Simplifique el mantenimiento del programa.
A nivel empresarial:
• Ayuda a estandarizar el proceso de desarrollo.
• Mejora la gestión de proyectos.
14
• Promover su reutilización.
1.6 Estructura de las herramientas CASE
Según Quinteros (2015) “Las herramientas CASE se pueden dividir ampliamente en las
siguientes partes según su uso en una etapa SDLC particular” (p. 43).
La presencia de menús. Para representar los modelos de proceso CASE, las
herramientas deben poder mostrar los procesos como diagramas. Los esquemas son mucho
más fáciles de usar que varios textos y descripciones numéricas. Esto le permite obtener
componentes de modelo fácilmente manejables con una estructura simple y clara.
La presencia de un repositorio. Un repositorio es una base de datos general que
contiene una descripción de los elementos de los procesos y las relaciones entre ellos.
Cada objeto de repositorio debe tener una lista de propiedades específicas solo para este
objeto.
Flexibilidad de aplicación. Esta característica permite representar los procesos de
negocio de diversas formas que son importantes desde el punto de vista del análisis. Las
herramientas CASE deberían permitirle analizar procesos y crear modelos enfocados en
varios aspectos de la empresa.
Paneles de trabajo. El análisis y el modelado de procesos pueden requerir que
varias personas trabajen juntas. Para trabajar simultáneamente en los modelos de proceso
CASE, las herramientas deben proporcionar gestión de cambios para cualquier fragmento
de modelo y su modificación cuando se comparte.
Construcción de procedimientos. Los prototipos de proceso son necesarios para que
en las primeras etapas del cambio de proceso, sea posible comprender cómo el proceso
cumplirá con los requisitos.
Elaboración de reportes. Las herramientas CASE deben proporcionar informes
sobre todos los modelos de proceso, teniendo en cuenta la relación de elementos. Estos
15
informes son esenciales para analizar modelos e identificar oportunidades de optimización.
Los informes permiten controlar la integridad y suficiencia de los modelos, el nivel de
descomposición de los procesos, la sintaxis correcta de los diagramas y los tipos de
elementos utilizados.
1.7 Módulo de Prototipado
La creación de prototipos es beneficiosa para conocer las necesidades de un producto de
paquete complicado, para demostrar una idea, para conectar nuevos conceptos, etc. Las
opciones vitales de una herramienta CASE de creación de prototipos son las siguientes:
• Conocer la interacción del sistema con el usuario
• Conocer los procedimientos generados por el sistema
• Guardar y acceder los procesos que requiere el sistema
• Generar el procesamiento automático de datos
Transacciones Paneles de
Trabajo
Menús Procedimientos
Reportes
Base de Datos
Repositorio
Figura 2. Diagrama de un repositorio. Fuente: Quintero, 2015.
16
Módulo de generadores de código: En este módulo se generan en forma automática
el código
Módulo generador de documentación: Transcribe las especificaciones del
repositorio, a este módulo se suman la ayuda en línea o las ayudas del programa
1.8 Proceso de desarrollo: software con herramientas CASE
La Ingeniería de Software se ocupa de la calidad del software realizados para los sistemas
de información, estas son llamadas CASE, buscando una mayor productividad en el
proceso de desarrollo. En pocas palabras, su objetivo es el desarrollo, la gestión y la
documentación del software. Fuentes (2015), definió como “el establecimiento y uso de
principios de ingeniería sólidos para obtener un software económicamente confiable que
funcione de manera eficiente en máquinas reales” (p.85).
Aborda tanto cuestiones relacionadas con el entorno de desarrollo de software,
como métodos, procesos y herramientas para su producción. Se debe tener cuidado al crear
software, ya que cuando hay una planificación y un desarrollo deficientes, los recursos que
se gastarán en la reparación y especialmente el tiempo disponible para tal procedimiento
no son factibles en ningún mercado, especialmente en tecnología, donde estas dos
características son indispensables.
Diseño Prototipo Producción
Figura 3. Ciclo de vida: diseño-prototipo-producción. Fuente: Quintero, 2015.
17
El enfoque es el análisis y división del problema en partes pequeñas, de manera que
se pueda dar una solución a cada una de ellas y, una vez resueltas, se puedan integrar. Para
todo este control se deben seguir una serie de pasos, denominados ciclo de software.
Básicamente, gira en torno a todas las fases determinadas de un software, desde la
planificación hasta su finalización, con el objetivo de cumplir todos o, al menos, casi todos
los requisitos idealizados. Debido a que es un ciclo, los pasos no se pueden repetir sin
antes verificar la calidad de cada paso.
Para cada etapa de verificación hay herramientas disponibles en la web; y con
tantas tecnologías disponibles para facilitar el trabajo, el propio desarrollador tiene dudas
sobre cuál elegir y por qué unas se consideran mejores que otras..
Figura 4. Arquitectura jerárquica de las herramientas CASE. Fuente: Quintero, 2015.
1.9 Características principales de las herramientas CASE
Como principales herramientas CASE tenemos principalmente tenemos a:
• Soporte de diagrama
• Secuencias de comandos SQL
• Ingeniería avanzada: de DER (diagrama de entidad relación) se conecta al banco e
implementa automáticamente el modelo físico. Esta característica permite a una
persona sin conocimientos de SQL, Lenguaje de Consulta Estructurado, implementar
18
un Der directamente en el banco.
• Ingeniería inversa: a partir del modelo físico implementado en el banco puede generar
Der. Esta característica permite a una persona que no conoce el modelo implementado
en el banco extraer el DER. Un escenario que podemos mencionar es el de un nuevo
contratista de la empresa que necesita desarrollar un sistema basado en la base de
datos que ya existe en una empresa. Puede, mediante el uso de una herramienta de
caja, conectarse a la base de datos y extraiga el modelo existente.
• Documentación: durante la creación de tablas y atributos ya ha documentos, es decir,
ya crea el diccionario de datos para su modelo. De esta forma siempre puedes tener
documentación actualizada.
Ventajas principales:
- Mejor documentación, siempre actualizada
- Mayor rapidez en el desarrollo de proyectos
- Calidad de procesos
- Interfaz gráfica
Herramienta A Herramienta B
TRADUCTOR
Datos Privados
Figura 5. Intercambio de datos. Fuente: Sánchez, 2015.
19
• Integración Total: En la integración total necesitamos dos características esenciales, la
gestión de metadatos y su capacidad de control de ellas. Las metas, son datos que
permiten representar información mediante herramientas CASE en cuanto a los datos de
ingeniería generados.
Herramienta A
INTERFASE DEL USUARIO COMÚN
Herramienta B Herramienta C
Almacén de datos compartidos
META DATOS
MECANISMOS DE ACTIVACIÓN
Figura 6. Integración total de herramientas CASE. Fuente: Arias, 2016.
20
Capítulo II
Lenguaje unificado de modelado (UML)
2.1 Lenguaje unificado de modelado (UML)
Definamos lo que significa UML de acuerdo al autor más relevante:
UML, significa en inglés Unified Modeling Language, traducido el lenguaje
unificado de modelado es un lenguaje visual para la documentación de
proyectos y los estándares de software, se pueden aplicar en varias áreas
diferentes y puede documentar y transmitir cualquier cosa desde los procesos
básicos de la empresa hasta los procesos de negocio y el software,
representando todos los procesos y procedimientos mediante una notación que
es sencillo en su aprendizaje y en su escritura, generalmente empleando un
formato visual combinado con la notación gráfica, la cual se ha convertido en
un modelo de aplicaciones de software y cada vez es más utilizado en el
mundo del desarrollo del software. (Fuentes, 2015, p.46).
¿Por qué UML?
El desarrollo de la www, permitió reducir y simplificar temas relacionadas a los
sistemas de información, pero también exacerbo algunos de ellos. El UML (lenguaje de
modelado unificado) fue elaborado para dar respuesta a estos problemas. Los objetivos
21
principales en el diseño del UML según resumen de Page-Jones en el diseño orientado a
objetos el UML es fundamental porque:
• Dota a usuarios un tipo de lenguaje de modelación de tipo visual listo para ser empleado
en el desarrollo de estos y que permita el intercambio de modelos significativos.
• Dota de mecanismos de extensión y de especialización.
• No forma parte de los lenguajes de programación y de procesos de desarrollo.
• Genera un proceso formal para comprender el lenguaje de modelado.
• Permite el auge en el mercado de las herramientas orientadas a objetos.
• Permite conocer nuevas formas de desarrollo de nivel superior, en colaboraciones,
marcos, patrones y componentes.
• Mejoran las prácticas y las integran
Antes de comenzar a analizar la teoría del UML, vamos a dar un breve repaso a los
principales diagramas del UML. Tenemos 14 diagramas que son los más representativos
de estas herramientas. Como diagramas estructurales donde permiten conocer la estructura
estática del sistema de información con sus elementos en diferentes niveles de abstracción,
tenemos a las siguientes:
• Diagrama de Clase
• Diagrama de componentes
• Diagrama de implementación
• Diagrama de Objetos
• Diagramas de paquetes
• Diagrama de estructura de composición
• Diagrama de perfil
Como diagramas de comportamiento donde se muestra el proceso dinámico de los
objetos del sistema de información, tenemos:
22
Diagrama de casos
Diagrama de actividades
Diagrama de estados
Diagrama de secuencias
Diagrama de comunicación
Diagrama de interacción
Diagramas de tiempos
2.2 Objetivos del UML
Como principales objetivos que tiene el modelado UML tenemos:
• Definición de un lenguaje de modelo visual y que permita una fácil utilización para
modelar la estructura del sistema de información.
• Permite generar mayor extensibilidad
• Es independiente de cualquier lenguaje y de la plataforma que se utiliza para modelar
un sistema que se está diseñando e implementando.
• Incorpora mejores prácticas de conformidad con los estándares de la industria.
• Brindar soporte para la orientación a objetos, diseñar y aplicar marcos y patrones
2.3 Modelando con UML
Modelado es una forma de abstracción del sistema, donde se especifica al sistema
modelado los puntos de vista con un nivel de abstracción determinado.
• El modelado es una simplificación de la realidad
• Ofrecen una visión global del sistema.
• Omiten aquellos elementos que son relevantes
23
• Cada modelado tendría que ser estructural (en primer lugar destaca la organización del
sistema) y también de comportamiento (resalta la dinámica de a organización).
Para comprender mejor el sistema que estamos desarrollando a través del modelado
conseguimos 4 objetivos:
• Los modelos nos permiten visualizar como queremos que sea nuestro sistema.
• Permite conocer a nivel de detalle la estructura y el comportamiento del sistema.
• Nos proporciona guías para la construcción de un sistema
• Permite documentar las decisiones consideradas.
Como visión general de UML y de acuerdo a la importancia de esta herramienta
establecida por la experiencia que se tiene UML es un lenguaje que sirve para:
• Visualizar
• Especificar
• Construir
• Documentar
2.4 Evolución del UML
A finales de los años 80 y comienzo de los años 90, nació una gran cantidad de notaciones
gráficas y/o técnicas orientadas a objetos llamada “guerra de métodos” que se utilizaban de
manera individual impidiendo compartirse con otros desarrolladores y dificultando el
trabajo de los desarrolladores, ante esta situación surge la necesidad de crear un lenguaje
orientado a objetos de manera estandarizada que permitiera brindar la facilidad de trabajar
de manera correcta y es de esa manera que surgen tres grandes científicos computacionales
con sus metodologías orientadas a objetos.
A partir de los años 80, surgieron una serie de sucesos donde los desarrolladores
realizaban el software de manera artesanal, es decir usaban métodos o técnicas basados a
24
través de la experiencia de ensayo-error pensando que era el mejor camino a seguir, no
obstante este enfoque produjo una serie de éxitos, pero a la vez una seria de software sin
calidad que producían perdidas y costos elevados que perjudicaban a empresas y ante esta
situación se requería de una solución generando diversos métodos y/o técnicas que
brindaran el soporte necesario entre los más resaltantes fueron Rumbaugh, Booch y
Jacobson quienes realizaron metodologías orientada a objetos y que la empresa Software
Rational respaldo tales creaciones dando origen así al UML con una versión de 1.0 pero
que hasta la actualidad ha ido evolucionando en una mejor versión 2.5.
Del mismo modo, García y Pardo (2016) nos brindan una información más
detallada de cómo ha sido el génesis del UML:
Durante 1989 y 1994 empieza una gran preocupación en el ámbito informático ya
que se produjo una confrontación entre métodos que se originó gracias a que varios
expertos presentaban metodologías diferentes para soluciones dentro del ADOO que eran
el resultado del método experimental para la validación de sus esfuerzos. Ante esto surgen
tres importantes metodologías que consiguen unificarse para dar inicio a UML que permite
diseñar, visualizar y analizar un sistema software y con el apoyo de especialistas
informáticos y empresas industriales como: Oracle, Microsoft, etc. lograron que UML sea
un lenguaje estandarizado.
De la misma manera, Bonaparte (2012) expone la historia del UML hasta que fue
considerado como un estándar aprobado por la ISO.
UML ha tenido una gran acogida desde su iniciación tras el respaldo de OMG, que
ha servido de gran ayuda para su evolución y aplicación en diferentes software
produciendo una mayor calidad y soporte al momento de diseñar un modelo para un
requerimiento especifico según lo plantee el cliente al desarrollador sin embargo, todo esto
25
se ha dado gracias a que muchas empresas, técnicos, científicos entre otros apoyaran a que
UML sea un lenguaje estándar para crear un sistema software sin ninguna complejidad.
Para fortalecer lo antes mencionado consultamos a Schmuller (2016), quien a
inferido que: UML es la creación de Booch, Jacobson y Rumbaugh conocidos como los “3
amigos” cada uno trabajo de manera independiente el análisis y diseño orientado a objetos
que para mediados de los 90 decidieron trabajar de manera conjunta.
En 1994 Rumbaugh ingresa a trabajar a Rational Software Corporation donde
trabajaba Booch, y un año después ingresa a trabajar Jacobson. Tiempo más t arde, muchos
corporativos notaron que UML era útil para muchas aplicaciones así que el consorcio
produjo la versión 1.0 del UML y lo puso a consideración a OMG y luego trabajaron con
UML 1.1 y nuevamente lo colocaron a consideración del OMG. El grupo adopto esta.
Podemos decir entonces que UML ha evolucionado de manera positiva y siendo
participe para la creación de nuevos softwares que ofrece un estándar para describir,
diseñar, especificar, analizar, construir y documentar gráficamente un modelo o sistema
con una versión más actualizada de 2.5 que cuenta con una variedad de 22 diagramas que
facilitan al desarrollador teniendo en cuenta que para el 2015 UML fue liberada para su
mayor eficiencia en la invención de nuevos o futuros softwares.
Actualmente el propósito básico detrás del modelado UML es visualizar, construir,
especificar y documentar un sistema. Siendo aceptado en forma universal para generar una
estructura a todo el sistema de información que se está implementando.
Los tres componentes principales de UML son:
• Elementos del modelo.
• Relaciones entre elementos del modelo.
• Diagramas UML
26
2.5 Beneficios del UML
UML es una forma que proporciona calidad en la construcción de sistemas de información,
utilizado en la descripción visual de los programas conformantes del sistema orientado a
objetos y permite apoyar en la organización, planificación y visualización de un programa.
Garlan, Cheng y Kompanek (2002) afirmaron que el uso de UML tiene beneficios,
pero que existen preguntas abiertas sobre si las soluciones orientadas a objetos son
suficientemente expresivas para esto. En su trabajo, describieron cuatro estrategias para
representar la estructura arquitectónica a través de UML, para al menos intentar hacer
representaciones expresivas.
Las estrategias creadas se enfocan en los componentes, que según los autores, son
elementos centrales de un proyecto de descripción arquitectónica, y para cada estrategia
elegida, se consideraron sub-alternativas para representar los demás elementos
arquitectónicos como puertos, conectores y sistemas. Cada estrategia se ha descrito en una
sección y son:
• Clases y objetos. Tenemos que los componentes tienen representación por clases UML
y sus instancias tienen representación por sus objetos;
• Clases y clases. Es decir sus diversos tipos de componentes y sus instancias son
representados por clases UML;
• Componentes UML. Estos tipos de componentes tienen representatividad como
componentes UML y sus instancias como también instancias de componentes UML;
• Subsistemas. Son representados los tipos de componentes como subsistemas UML y
también sus instancias, como instancias de subsistemas UML.
Además, también se definieron los criterios de evaluación, donde idealmente, los
autores quisieron que se mostraran tres características:
27
• Correspondencia semántica: El mapeo debe respetar la semántica de UML, el modelo
debe ser inteligible tanto para los arquitectos como para las herramientas basadas en
UML;
• Claridad visual. Estas descripciones arquitectónicas que son resultados del UML tienen
que aportar claridad, evitar el caos visual y resaltar los principales detalles del diseño;
• Integridad. Los conceptos arquitectónicos abordados por los autores deben ser
representables en UML.
A través de este trabajo, Garlan, Cheng y Kompanek (2002) llegaron a la
conclusión de que UML no proporciona el mejor camino para la codificación y los
elementos arquitectónicos. Las estrategias que muestran tienen fortalezas y debilidades y,
en general, se debe priorizar un requisito sobre el otro cuando se trata de claridad e
integridad.
La decisión a tomar depende de qué aspectos de la arquitectura deben describirse.
Además, se dice que todas las estrategias tienen alguna forma de incompatibilidad
semántica. Otro problema señalado fue la dificultad de representar conceptos
arquitectónicos, como puertas, conectores y subestructuras.
28
Capítulo III
Modelo conceptual de UML
3.1 Modelo conceptual de UML
Muestra todos los conceptos importantes del dominio del sistema, así como las
asociaciones entre estos conceptos. La idea es que el usuario que tiene acceso a este
modelo comprenda los principales elementos del dominio que están involucrados en el
sistema a desarrollar. Puede mostrar: conceptos, asociaciones entre conceptos y atributos
de conceptos.
El modelo conceptual ayuda a aclarar la terminología o el vocabulario del dominio.
3.2 Papel de UML en el diseño Orientado a Objetos (OO)
La gran parte de los diagramas UML son utilizados para modelar diferentes características
como el estático y el dinámico, etc.
Si observamos los diferentes diagramas como el diagrama de clase, de objeto, de
colaboración, de interacción, estos se diseñarían básicamente en función de los objetos.
29
3.3 Diagramas en UML
UML es una forma de visualizar un sistema automatizado utilizando una colección de
diagramas. Su notación ha evolucionado a partir del trabajo de muchos informáticos en el
uso del diseño orientado a objetos, pero desde entonces ha sufrido una extensión para
cubrir una variedad más amplia de proyectos de ingeniería de software.
3.3.1 Diagrama de clase.
Permite la visualización de un conjunto de clases, detallando los atributos y
operaciones (métodos) presentes en este último, así como las probables relaciones entre
estas estructuras. Este tipo de representación también puede incluir definiciones de
interfaz.
3.3.2 Diagrama de objetos.
Presenta el estado de instancias de objetos dentro de un sistema, teniendo en cuenta
un intervalo de tiempo específico.
3.3.3 Diagrama de casos de uso.
Dirigido a presentar las funcionalidades y características de un sistema, así como
cómo estos elementos se relacionan con los usuarios y entidades externas involucradas en
un determinado proceso.
3.3.4 Diagramas de secuencia y colaboración.
Estos diagramas muestran el resumen del flujo de control entre los nodos que
interactúan. Demuestra las interacciones entre diferentes objetos en la ejecución de una
operación, destacando también el orden en que estas acciones tienen lugar durante un
30
período de tiempo. La secuencia en la que se realizan las distintas operaciones se produce
de forma vertical, de arriba hacia abajo.
3.3.5 Diagrama de estados.
Detalla los diferentes estados por los que puede pasar un objeto, en función de la
ejecución de un proceso dentro del sistema que se está considerando.
3.3.6 Diagrama de actividades.
Incluye las diversas tareas que se realizan en la ejecución de una actividad,
usándose generalmente en la representación de procesos dentro de una empresa /
organización.
3.3.7 Diagrama de componentes.
Presenta diferentes componentes de un sistema, así como posibles dependencias
entre dichos elementos. La idea de un componente se refiere a una parte (o incluso un
módulo) de una aplicación, abarcando así una serie de otras estructuras relacionadas (como
clases, interfaces, etc.).
3.3.8 Diagrama de despliegue.
Empleado para demostrar la estructura de hardware adoptada para la
implementación de una aplicación en un entorno. Puede involucrar dispositivos como
servidores de aplicaciones, servidores de bases de datos, terminales de usuario, etc.
31
Figura 7. Diagrama de despliegue. Fuente: Fuentes, 2016.
3.4 Vista de uso de casos
Figura 8. Vista del modelado de un sistema. Fuente: Fuentes, 2016.
Permite describir el comportamiento de un sistema de información desde el alcance de los
usuarios finales, analistas y personal que están encargados de realizar las pruebas del
sistema, sus diagramas UML, son:
De diseño
De implementación
De procesos
De despliegue
Vistas de uso de casos
32
• Diagramas de caso de uso
• Diagramas de interacción
• Diagramas de estados
• Diagramas de actividades
Vista de diseño: Permite mostrar los requisitos y servicios que el sistema permite
brindar a los usuarios finales. Comprende a las clases, interfaces y colaboraciones que
forman la solución del sistema los diagramas utilizados son:
• Diagramas de clases
• Diagramas de objetos
• Diagramas de interacción
• Diagramas de estado
• Diagramas de actividades
Vista de procesos: Permite mostrar las tareas y procesos que conforman los
mecanismos de sincronización y concurrencias de un sistema de información. Puede
comprender su funcionalidad, su capacidad de crecimiento y su rendimiento. Los
diagramas que se utilizan vienen a ser los mismos que la vista de diseño pero enfatizando
las clases activas que representan a las tareas y procesos.
• Diagramas de clases
• Diagramas de objetos
• Diagramas de interacción
• Diagramas de estado
• Diagramas de actividades
Vista de implementación: Permite mostrar todos los componentes y archivos que
son importantes para hacer disponible el sistema físicamente. Prioriza principalmente la
gestión de configuración de las distintas versiones del sistema, sus diagramas son:
33
• Diagramas de componentes
• Diagramas de interacción
• Diagramas de estado
• Diagramas de actividades
Vista de despliegue: Muestran los nodos que conforman la topología del hardware
donde se ejecuta el sistema. Es importante tenerla en la distribución, en la entrega e
instalación de las partes que conforman el sistema físico y son:
• Diagramas de despliegue
• Diagramas de interacción
• Diagramas de estado
• Diagramas de actividades
3.5 Características del diagrama Casos de uso (Use case) de UML
Un diagrama de caso de uso es una técnica de modelado utilizada para la descripción de lo
nuevo que debe hacer un sistema. Se construye a través de un proceso interactivo en el que
las discusiones entre el cliente y los desarrolladores del sistema conducen a una
especificación del sistema en la que todos están de acuerdo.
Un caso de uso describe las operaciones que el sistema debe realizar para cada
usuario. Ayudará a formalizar las funciones que debe realizar el sistema. Un caso de uso se
presenta como una lista completa de las interacciones entre un usuario y el sistema para
realizar una tarea. La lista completa significa que el caso de uso describe las interacciones
desde el principio de la tarea hasta el final.
Los casos de uso deben ser comprensibles para los usuarios porque solo ellos saben
lo que debe hacer el sistema. Los casos de uso le permiten verificar que el desarrollador y
el usuario están de acuerdo en lo que debe hacer el sistema. Este es un problema
34
importante en el desarrollo de software. Al mismo tiempo, los casos de uso pueden servir
como contratos entre los usuarios y el equipo de desarrollo.
Sus objetivos principales son:
• Descripción de los requisitos funcionales del sistema.
• Proporciona una descripción clara y coherente de lo que realizara el sistema; (Describa
QUÉ hacer, no CÓMO hacerlo)
• Permitir descubrir los requisitos funcionales de las clases y operaciones del sistema.
(Los casos de uso NO son requisitos)
• Documentar y comprender los requisitos de un sistema;
• Delimitar el contexto de un sistema;
De esta forma, los casos de uso actúan como una fase de transición entre los
requisitos y el análisis. Podemos decir que los componentes de un modelo de caso de uso
son:
Actor: es un rol que normalmente estimula / solicita acciones / eventos del sistema y recibe
reacciones. Cada actor puede participar en varios casos de uso
Casos de uso: documento narrativo que describe la secuencia de eventos realizados por un
actor en el uso del sistema.
Sistema: el sistema a modelar
Figura 9. Posicionamiento de Casos de uso (Use case). Fuente: Fuentes, 2016.
35
Los diagramas de casos de uso permiten representar solamente los requisitos
funcionales de un sistema. Las reglas comerciales, los requisitos de calidad de servicio y
las restricciones de implementación, como otros requisitos deben representarse por
separado, nuevamente, con otros diagramas UML. Sus componentes son:
Nombre: Formado por una cadena de caracteres y cada diagrama debe tenerlo.
Actores: Son los elementos interactuantes con el caso de uso (función del sistema).
Son nombrados por sustantivos y juega un papel en el negocio.
El concepto es similar al de usuario, pero este puede jugar diferentes roles
Por ejemplo:
Un profesor puede ser instructor y también investigador juega 2 roles con dos
sistemas
El actor desencadena diagramas de casos de uso.
El actor tiene una responsabilidad hacia el sistema (entradas), y el actor tiene
expectativas del sistema (salidas).
Figura 10. Como cliente y cliente comercial. Fuente: Fuentes, 2016.
3.6 Objetos
Cosa u objeto que puede interactuar, es decir puede enviar varios mensajes y reacciona
ante ellos.
36
Lo que interesa es que con que objetos interactúa, generalmente se dirige al mismo
por su nombre, es decir un objeto tiene una identidad que lo distingue del resto de los
objetos.
Un objeto o cosa esta compuesto de la siguiente manera según Booch.
• Cosa: es una representación de un concepto en el sistema, ejemplo un objeto o cosa se
puede representar físicamente como es un cliente, un reloj o una mesa.
• Estado: constituye todos los datos que encapsula en un momento determinado, lo
normal de un objeto es que tiene un número al que se le conoce como atributo o
variables de instancia, cada uno de ellos tienen un valor. También algunos atributos
pueden cambiar.
• Ejemplo: un objeto que se represente a un cliente, puede tener un atributo dirección el
cual puede cambiar si el cliente se muda a otro lugar de residencia.
• Comportamiento: se refiere a la manera cómo actúa y reacciona un objeto en función de
sus cambios de estado y el paso de mensajes que actúa sobre ellos. La reacción de un
objeto puede depender de los valores de sus atributos en un momento determinado.
• Identidad: es una propiedad que permite diferenciar a un objeto de otro (distinguirse).
Por ejemplo: tenemos un objeto de color rojo, su propiedad única es su color rojo, así
que para nosotros no tiene sentido usar otro nombre para el objeto que no sea el valor de
la propiedad que identifica.
3.7 Clases
Es la abstracción de cosas que pueden trasladarse directamente a un lenguaje de
programación. La clase moldea la abstracción de un objeto defiendo sus propiedades o
comportamiento, una clase no es un objeto, es solo un plan de un objeto.
37
El gráfico que se muestra a continuación se resalta las partes importantes de una
abstracción: nombre, atributos y operaciones.
Figura 11. Organización de los casos de uso. Fuente: Fuentes, 2016.
Nombres
Todas las clases tienen nombres diferentes. Es una cadena de texto, según la
práctica los nombres de clase son cortos o expresiones extraídas del vocabulario del
sistema de información que se está modelando. Se puede dibujar mostrando solo su
nombre, como se visualiza.
3.8 Atributos y operaciones
Los atributos son una propiedad de una clase u objeto. Puede referirse o establecer un
valor específico de un elemento que se está modelando y que es compartido por todos los
objetos de esa clase. Lo representamos en las siguientes figuras:
Proveedor.
38
Figura 12. Atributos. Fuente: Fuentes, 2016.
Las operaciones son las abstracciones de alguna acción que se puede realizar en el
objeto y que puede ser compartido por todos los demás objetos de la clase. Cada clase
puede tener una o muchas operaciones o también no la puede tener.
Las operaciones se representan mostrando sólo sus nombres de acuerdo a la
siguiente figura:
Figura 13. Operaciones. Fuente: Fuentes, 2016.
39
3.9 Arquitectura del Software
Como muchos en el mundo del software, siempre han sido cauteloso con el término
arquitectura, ya que a menudo sugiere una separación de la programación y una dosis poco
saludable de diseño. Pero resuelvo el problema enfatizando que la buena arquitectura es
algo que respalda su propia evolución y está profundamente entrelazada con la
programación. La mayor parte ha girado en torno a las preguntas de cómo es la buena
arquitectura, cómo los equipos pueden crearla y cómo cultivar mejor el pensamiento
arquitectónico en nuestras organizaciones de desarrollo.
40
Aplicación didáctica
Sesión de Clase
I. Objetivos
• Promover el interés de los alumnos del quinto grado de secundaria a la importancia
de conocer una herramienta de modelamiento de sistemas ERWIN
• Aprender a utilizar los diagramas del Rational Rose para un sistema automatizado.
II. Expectativa de Aprendizaje
• Define y modela un sistema por automatizar.
• Conoce los objetivos de una herramienta ERWIN.
• Conoce diferentes tipos de diagramas del ERWIN.
III. Organización de los Aprendizajes
Conceptos Aprendizajes esperados Actitudes
• Sistemas de
Información
• Herramienta de
modelamiento
• Conociendo ERWIN
• Ventajas y
Desventajas de
modelamientos.
• Diseño de
Información
• Define un Sistema de Información.
• Define una herramienta de
modelamiento
• Observa los distintos software de
modelamiento de sistemas
• Ventajas y Desventajas en la
utilización del ERWIN.
• Utiliza e interactúa con el sistema
de información.
Mostrar disposición de
emprendimiento
Tener voluntad y
auto motivación para
conseguir el logro de las
metas
Tener autonomía para
decidir y actuar.
41
IV. Secuencia Didáctica
Situación de
aprendizaje Estrategias
Recursos
didácticos
Evaluación Tiempo
Criterios Indicadores Instrumentos
Inicio
• Presentación.
• Introducción a Sistemas de
Información.
Expresión oral
Diapositivas
*Gestión de
procesos
Participación en clase
(Dialogo)
Cuestionario.
5 min
Proceso
*Define un modelamiento de
sistemas
*Define el ERWIN
*Realiza la diagramación
utilizando el ERWIN.
Diapositivas
Expresión oral
*Comprensión y
aplicación de la
tecnología.
*Gestión de
procesos
*Comprende el
concepto de
modelamiento
*Genera gráficos
utilizando ERWIN.
Lista de cotejo.
20 min
Salida
Laboratorio Práctico con
ERWIN
• Diagrama de Casos de usos
• Diagramas de clase
Guía práctica de
Laboratorio
*Comprensión y
aplicación de la
tecnología
* Genera diagrama de
usos
* Genera diagrama de
clase
Ficha de evaluación
15 min
Guía de laboratorio
Ingreso y creación del modelo lógico en ERWIN
1. De un clic en el botón Inicio.
2. Seleccionar Programas\ Erwin Data Modeler 7.3\Erwin Data Modeler
3. Se visualiza la pantalla de presentación del programa lo cerramos y luego elegimos en la
barra de herramienta la opción file y creamos el modelo.
43
4. Elegimos la opción logical/physical y por último la opción bajo qué base luego se va
exportar.
5. Utilizamos la barra de herramientas y elegimos el archivo format, elegimos la opción
STORED DISPLAYS.
44
6. Saldrá un cuadro de dialogo en donde utilizaremos la opción rename para colocar el
nombre del proyecto, en la pestaña del área de trabajo.
7. Aprenderemos a cambiar el nombre del modelo, dando un clic derecho o en la barra de
herramientas model elegimos propierities.
45
8. Muestra el cuadro de dialogo y colocaremos el nombre del modelo a trabajar.
9. Iniciamos a crear las entidades y sus atributos, utilizando la barra de herramientas
views, opción toolbar, drawing. Creamos la entidad: libro, autor, préstamo, usuario y
editorial, con sus respectivos atributos.
46
10. Después de culminar con la creación de las entidades, vamos al menú format y
elegimos la opción stored display para elegir la opción primary key designator, para
que todas las entidades puedan visualizar su llave primaria.
11. Después de haber culminado con las entidades, luego pasaremos a relacionarlas.
47
12. Después de haber culminado con las entidades, luego pasaremos a relacionarlas.
13. La relación /conexión de las entidades será una relación identificadora, que quiere
decir que son aquellas que la clave primaria de la entidad padre forma parte de la
clave de la entidad hija.
48
14. Iniciamos las relaciones identificadoras: primera relación identificadora: autor con libro
15. Segunda relación identificadora: editorial con libro. Tercera relación identificadora:
libro con préstamo. Cuarta relación identificadora: usuario con préstamo.
49
16. Ahora pasamos a la vista lógica observamos por defecto las entidades con los atributos
y sus tipo de campo es char, las cuales se procederán al cambio respectivo.
50
17. Ahora pasamos a la vista lógica observamos por defecto las entidades con los atributos
y sus tipo de campo es char, las cuales se procederán al cambio respectivo.
18. Al finalizar las entidades terminan modelada como corresponde, utilizando las
herramientas necesarias de Erwin 7.3.0.
51
Síntesis
UML, es un lenguaje de modelado unificado, no es un lenguaje de programación, más bien
es un lenguaje que sirve como una herramienta para construir y documentar un software
que se requiera.
El lenguaje de modelado unificado (UML), es utilizado por analistas y
programadores para que puedan representar el comportamiento y la estructura de un
sistema, UML utiliza diversos diagramas, en especial los diagramas de caso de uso.
El Object Management Group (OMG) adoptó el lenguaje de modelado unificado
como estándar en 1997. La Organización Internacional de Normalización (ISO) publicó
UML como un estándar aprobado en 2005, por lo cual es revisado a lo largo de los años y
se revisa periódicamente.
Actualmente es considerado como un lenguaje estándar de análisis y diseño de
sistema de cómputo ya que posee características más visuales que programables que
facilitan el manejo de aplicaciones complejas y planificación de múltiples equipos, por lo
tanto, requieren una forma clara y concisa de comunicarse entre ellas.
Estas herramientas permiten el ahorro de tiempo y optimizan los costos y la
productividad sobre todo cuando los equipos pueden visualizar en el desarrollo de un
sistema los procesos, interacciones del usuario y la estructura estática del sistema.
52
Apreciación crítica y sugerencias
Como se discutió a lo largo de esta monografía, UML ofrece una amplia variedad de
diagramas que buscan cubrir diferentes aspectos del desarrollo de software. Esto no significa
necesariamente que el modelado de una nueva aplicación deba utilizar todas las
representaciones proporcionadas por este lenguaje. De hecho, cada proyecto tiene
características muy específicas, lo que significa que solo algunos de los diagramas pueden
realmente agregar algún valor como documentos que especifican el sistema a construir.
Además, el uso de elementos UML no se limita a la elaboración de artefactos
dentro de un proyecto. Es bastante común que UML se utilice como medio para
representar estructuras basadas en conceptos Orientados a Objetos o incluso en
mecanismos de ingeniería inversa que permitan la elaboración de diagramas a partir de
estructuras de código previamente implementadas. La gran preocupación por la
estandarización de este lenguaje fue un factor determinante para su éxito, con este hecho
no restringido al ámbito académico, sino contando aún con el apoyo de gigantes
tecnológicos (Microsoft, Oracle e IBM son algunas de estas empresas).
53
Referencias
Arias, L. (2016). Lenguaje de modelamiento unificado (UML) para modelamiento de
embotelladora. Scientia Et Technica, 21 (1), 38-42. Recuperado de
http://www.redalyc.org/pdf/.
Bernardo, J., Anaya, R., Marín, J.C., y Bilboa, A. (2015, marzo). Un estudio comparativo
de herramientas para el modelado con UML. Universidad Eafit.41 (137), 60-76.
Recuperado de http://www.redalyc.org/
Bonaparte, U. (2012). Proyectos UML Diagramas de clases y aplicaciones JAVA en
NetBeans 6.9.1, 56-59. Recuperado de http://www.edutecne /tutoriales.
Ferré, X., y Sánchez, M., (2013). Desarrollo Orientado a Objetos con UML. 78-81. Artículos
sobre UML. Recuperado de https://www.uv.mx/personal/maymendez/
Fowler, M. (2009). UML gota a gota. Revista herramientas UML (5), 18-25. Recuperado
de: http://www.face.ubiobio.cl/cvidal/modelamientoUMLgotaagota.pdf.
Francisco, P. (2016). Lenguaje Unificado de Modelado – UML. Recuperado de
https://www.unican.es/pluginfile.php/
Fuentes, J. (2015). Lenguaje Unificado de Modelado (UML). Recuperado de
http://thales.cica.es/rd/
García, F., y Pardo, C. (2016). UML 1.1. Un lenguaje de modelado estándar para los
métodos de ADOO. Recuperado de http://gredos.usal.es/
García, J., Tinoco, L., Gonzáles, G., García, J., y Moreno, J. (2013). Modelado e
implementación de un sistema de enseñanza de Lenguaje de Señas Mexicano.
Revista Ciencia Ergo Sum 14 (2), 185-190.
54
Garlan, D., Cheng, S., y Kompanek, A., (2002). Reconciling the needs of architectural
description with object-modeling notations. Science of Computer Programming,
44(1), 23-49.
Pérez, S., y Orejas, F. (2006). Extensión de la meta modelo de UML para una arquitectura
de componentes. Ingeniería industrial. XXVII (2-3), 63-66.
Quintero, J. (2015). UML - Objetivos y arquitectura. Recuperado de
http://atomcol.blogspot.pe/2015/02/
Rumbaugh, J., Jacobson, J., y Booch G. (2007). El lenguaje unificado de modelado. Manual
de referencia. Segunda edición. Recuperado de
ftp://april.frm.utn.edu.ar/METODOLOGIA%20DE%20SISTEMAS/
Schmuller, J. (2016). Aprendiendo UML en 24 horas. Recuperado de
https://es.scribd.com/document/
Sparks, G. (2014). Una Introducción al UML. Recuperado de
http://www.sparxsystems.com.ar/whitepapers/
Vela B., y Marcos E., (2013). Una extensión de UML para representar XML, España:
Editorial Schemas
Harmon, P., y Watson, P., (2008). Entendiendo UML: La guía del desarrollador, con una
aplicación java basada en web, Editorial Morgan Kauffman Publishers, Inc.
Recuperado de www.mkp.com/books_catalog/
Zapata, C., y Arango, F. (2007). Un ambiente para la obtención automática de diagramas
UML a partir de un lenguaje controlado. Recuperado de http://www.redalyc.org/
