Desarrollo de uml

LUIS ENRIQUE RENDON REYES
DROXSARALIFEX@HOTMAIL.COM

El Lenguaje Unificado de Modelado (UML) fue creado para forjar un lenguaje de
modelado visual común y semántica y sintácticamente rico para la arquitectura,
el diseño y la implementación de sistemas de software complejos, tanto en
estructura como en comportamiento. UML tiene aplicaciones más allá del
desarrollo de software, por ejemplo, en el flujo de procesos en la fabricación.
Es comparable a los planos usados en otros campos y consiste en diferentes
tipos de diagramas. En general, los diagramas UML describen los límites, la
estructura y el comportamiento del sistema y los objetos que contiene.
UML no es un lenguaje de programación, pero existen herramientas que se
pueden usar para generar código en diversos lenguajes usando los diagramas
UML. UML guarda una relación directa con el análisis y el diseño orientados a
objetos.

HISTORIA
El lenguaje UML comenzó a gestarse en octubre de 1994, cuando Rumbaugh se
unió a la compañía Rational fundada por Booch (dos reputados investigadores en el
área de metodología del software).
El objetivo de ambos era unificar dos métodos que habían desarrollado: el método
Booch y el OMT (Object Modelling Tool ). El primer borrador apareció en octubre de
1995. En esa misma época otro reputado investigador, Jacobson, se unió a Rational
y se incluyeron ideas suyas. Estas tres personas son conocidas como los “tres
amigos”. Además, este lenguaje se abrió a la colaboración de otras empresas para
que aportaran sus ideas. Todas estas colaboraciones condujeron a la definición de
la primera versión de UML.

Es un lenguaje de modelado visual que se usa para especificar, visualizar,
construir y documentar artefactos de un sistema de software. Se usa para
entender, diseñar, configurar, mantener y controlar la información sobre los
sistemas a construir.
UML capta la información sobre la estructura estática y el comportamiento
dinámico de un sistema. Un sistema se modela como una colección de objetos
discretos que interactúan para realizar un trabajo que finalmente beneficia a un
usuario externo.
El lenguaje de modelado pretende unificar la experiencia pasada sobre técnicas
de modelado e incorporar las mejores prácticas actuales en un acercamiento
estándar.
UML no es un lenguaje de programación. Las herramientas pueden ofrecer
generadores de código de UML para una gran variedad de lenguaje de
programación, así como construir modelos por ingeniería inversa a partir de
programas existentes.

La notación UML se deriva y unifica las tres metodologías de análisis y diseños más extendidas.
Metodología de Grady Booch para la descripción de conjuntos de objetos y sus relaciones.
Técnica de modelado orientada a objetos de James Rumbaugh (OMT: Object - Modelling Technique).
Aproximación de Ivar Jacobson (OOSE: Object- Oriented Software Engineering) mediante la metodología
de casos de uso (use case).
El desarrollo de UML comenzó a finales de 1994 cuando Grady Booch y Jim Rumbaugh de Rational
Software Corporation empezaron a unificar sus métodos. A finales de 1995, Ivar Jacobson y su compañía
Objectory se incorporaron a Rational en su unificación, aportando el método OOSE.
En 1997 UML 1.1 fue aprobada por la OMG convirtiéndose en la notación estándar de facto para el
análisis y el diseño orientado a objetos.
UML es el primer método en publicar un meta-modelo en su propia notación, incluyendo la notación para
la mayoría de la información de requisitos, análisis y diseño. Se trata pues de un meta-modelo auto-
referencial (cualquier lenguaje de modelado de propósito general debería ser capaz de modelarse a sí
mismo).

El UML debe entenderse como un estándar para modelado y no como un estándar de proceso software.
Aunque UML debe ser aplicado en el contexto de un proceso, la experiencia ha mostrado que
organizaciones diferentes y dominios del problema diferentes requieren diferentes procesos. Por ello se
han centrado los esfuerzos en un meta-modelo común (que unifica las semánticas) y una notación común
que proporcione una representación de esas semánticas. De todas formas, los autores de UML fomentan
un proceso guiado por casos de uso, centrado en la arquitectura, iterativo e incremental. Bajo estas
líneas genéricas proponen el proceso software definido en una de las extensiones del UML (Objectory
Extension for Software Engineering) , pero en general el proceso software es fuertemente dependiente de
la organización y del dominio de aplicación
Cualquier modelo preciso debe primero definir su universo, esto es, los conceptos clave de la aplicación,
sus propiedades internas, y las relaciones entre cada una de ellas. Este conjunto de construcciones es la
estructura estática. Los conceptos de la aplicación son modelados como clases, cada una de las cuales
describe un conjunto de objetos que almacenan información y se comunican para implementar un
comportamiento. La información que almacena es modelada como atributos; La estructura estática se
expresa con diagramas de clases y puede usarse para generar la mayoría de las declaraciones de
estructuras de datos en un programa.

Los modelos UML tienen significado para el análisis lógico y para la implementación
física. Un componente es una parte física reemplazable de un sistema y es capaz de
responder a las peticiones descritas por un conjunto de interfaces. Un nodo es un
recurso computacional que define una localización durante la ejecución de un sistema.
Puede contener componentes y objetos.
Hay dos formas de modelar el comportamiento, una es la historia de la vida de un
objeto y la forma como interactúa con el resto del mundo y la otra es por los patrones
de comunicación de un conjunto de objetos conectados, es decir la forma en que
interactúan entre sí. La visión de un objeto aislado es una máquina de estados,
muestra la forma en que el objeto responde a los eventos en función de su estado
actual. La visión de la interacción de los objetos se representa con los enlaces entre
objetos junto con el flujo de mensajes y los enlaces entre ellos. Este punto de vista
unifica la estructura de los datos, el control de flujo y el flujo de datos.

UML 1.x Como notación de modelado, la influencia de la OMT domina UML (por ejemplo, el uso
de rectángulos para clases y objetos). Aunque se quitó la notación de "nubes" de Booch, sí se
adoptó la capacidad de Booch para especificar detalles de diseño en los niveles inferiores. La
notación de "Casos de Uso" del Objectory y la notación de componentes de Booch fueron
integrados al resto de la notación, pero la integración semántica era relativamente débil en UML
1.1, y no se arregló realmente hasta la revisión mayor de UML 2.0.
Conceptos de muchos otros métodos orientados a objetos (MOO) fueron integrados
superficialmente en UML con el propósito de hacerlo compatible con todos los MO. Además, el
grupo tomó en cuenta muchos otros métodos de la época, con el objetivo de asegurar amplia
cobertura en el dominio de los sistemas en tiempo real. Como resultado, UML es útil en una gran
variedad de problemas de ingeniería, desde procesos sencillos y aplicaciones de solamente un
usuario a sistemas concurrentes y distribuidos.
VERSIONES

VENTAJAS
● UML Se puede usar para diferentes tipos de sistemas
● UML consolida muchas de las notaciones y conceptos más usadas
orientados a objetos.
● UML es fácilmente entendible

DESVENTAJAS
● UML no es un método de desarrollo.
● UML al no ser un método de desarrollo es independiente del ciclo de
desarrollo
● UML no se presta con facilidad al diseño de sistemas distribuidos.

UML 2.x
UML ha madurado considerablemente desde UML 1.1, varias revisiones menores
(UML 1.3, 1.4 y 1.5) han corregido defectos y errores de la primera versión de UML. A
estas le ha seguido la revisión mayor UML 2.0 que fue adoptada por el OMG en 2005.
Aunque UML 2.1 nunca fue lanzado como una especificación formal, las versiones
2.1.1 y 2.1.2, aparecieron en 2007, seguidas por UML 2.2 en febrero de 2009. UML
2.3 fue lanzado oficialmente en mayo de 2010. UML 2.4.1 fue lanzado oficialmente en
agosto de 2011. UML 2.5 fue lanzado en octubre de 2012 como una versión "En
proceso" que fue formalmente liberada en junio de 2015.

StarUML nace por la necesidad de interpretar los requerimientos de un sistema de tal forma
que el cliente los entienda de manera empírica (sin tecnicismos,) e intuitiva. StarUML fue
creado en 1996 por James Rumbaugh, Grady Booch e Ivar Jacobson conocidos como “los
tres amigos”, cada uno contribuyó con su mejor metodología para interpretar requerimientos
de sistema.
● James Rumbaugh: Contribuyo con OML (Técnica de modelado de objetos), que era
una de las mejores metodologías para el análisis orientado a objetos.
● Grady Booch: Booch ofrecía un método, el cual era el mejor para el diseño orientado a
objetos.
● Ivar Jacobson: Creador del método ingeniería de software orientado a objetos.

VENTAJAS
Soporte completo al diseño UML mediante el uso de:
– Diagrama de casos de uso.
– Diagrama de clase.
– Diagrama de secuencia.
– Diagrama de colaboración.
– Diagrama de estados.
– Diagrama de actividad.
– Diagrama de componentes.
– Diagrama de despliegue.
– Diagrama de composición estructural

DESVENTAJAS
● Solo corre en Windows.
● ·El código generado sobre-escribe el código anterior generado.
● ·La generación de clases las crea sin tomar en cuenta el paquete donde se
encuentra.
● ·Puedes crear Diagramas E-R pero al final no genera nada de SQL.
● ·No dispone de ingeniería inversa para PHP .

REQUERIMIENTOS PARA SU INSTALACIÓN
● Procesador Intel (R) Pentium (R) 233 MHz o superior
● · SO Windows (R) 2000, Windows XP ™ o superior
● · Memoria 128 MB de RAM (se recomiendan 256 MB)
● · 110 MB de espacio en disco duro (150MB de espacio recomendado)
● · SVGA o de mayor resolución (1024×768 recomendado)

ArgoUML es una aplicación de diagramado de UML escrita en Java y publicada bajo
la Licencia BSD. Dado que es una aplicación Java, está disponible en cualquier
plataforma soportada por Java.
El Magazine de Desarrollo de Software entrega premios anuales a herramientas de
desarrollo de software populares en varias categorías. En 2003 ArgoUML fue una de
las finalistas en la categoría "Design and Analysis Tools". ArgoUML recibió un premio
"runner-up"(revelación), derrotando a muchas herramientas comerciales.
Sin embargo, desde la versión 0.20, ArgoUML está incompleto. No es conforme
completamente a los estándares UML y carece de soporte completo para algunos
tipos de diagramas incluyendo los Diagrama de secuencia y los de colaboración

VENTAJAS
● Construido en diseños críticos suministra una revisión no obstructiva del diseño y
sugerencias para mejoras.
● Interfaz de módulos Extensible.
● Soporte de Internacionalización para Inglés, Alemán, Francés, Español y Ruso.
● Restricciones OCL para Clases.
● Soporte para el lenguaje de generación de Código: Java, PHP, Python, C++ y C Sharp
(C#)
● Ingeniería inversa
● Disposición(layout) automática del diagrama de clases.
● Generación de ficheros PNG, GIF, JPG, SVG, EPS desde diagramas.
● Soporte para comentarios para múltiples elementos.
● Todos los diagramas 1.4 están soportados.

DESVENTAJAS
● No tiene botón "deshacer".
● Los Modelos a veces no pueden ser reabiertos.
● Import/Export a Java.
● No hay llamadas-reflexivas en los diagramas de secuencia, si existen las llamadas
reflexivas, es un poco complejo hacerlas, pero sí se pueden, se hacen al tomar una
acción, partir desde el objeto que se quiere reflexivo, generar 2 puntos
(como haciendo un cuadrado) fuera del objeto y luego volviendo al objeto.
● Al mover una clase las relaciones no se mueven de forma correcta.
● Al seleccionar un área no se seleccionan las clases de relación.
● Debes de crear un diagrama de clases, para crear algún otro diagrama.

REQUERIMIENTOS PARA SU INSTALACIÓN
1. Bajar ArgoUML
2. Descomprimir el archivo Zip de ArgoUML en un directorio que lleve su mismo nombre :
/usr/local/argouml/, en el serán colocados los ocho archivos JAR que componen ArgoUML.
3. Posteriormente, estando en el mismo directorio antes mencionado, puede arrancar Argouml
con el siguiente comando : java -jar argouml.jar.
4. Al ejecutar el comando anterior será invocada la pantalla principal de ArgoUML, sin
embargo, en este mismo proceso puede observar una serie de mensajes en la consola de
arranque entre los que se encuentran los siguientes :
5. java.io.FileNotFoundException : Este mensaje implica que no fue localizado un archivo JAR
al momento de inicializarse ArgoUML, aunque no prohíbe el arranque inicial, puede
ocasionar que ciertas funcionalidades no sean operables una vez inicializado.

● Resource org.argouml.not found / missing : Este tipo de mensaje también implica
que no fue posible cargar un recurso al momento de inicializarse ArgoUML,
recursos que por lo general también son incluidos en los archivos JAR
complementarios incluidos en la distribución.
● Unable to load configuration ‘Directorio de ‘Usuario’/argo.user.properties : El
mensaje indica que no fue posible cargar la configuración particular de un usuario
para ArgoUML. El archivo llamado argo.user.properties debe ser colocado bajo el
directorio raíz del usuario que arranca el proceso de ArgoUML.

Para que determinados archivos JAR sean cargados al momento de arranque
tiene dos alternativas :
● Al ser invocado : A través de la siguiente alternativa de arranque : java -
classpath "./log4j.jar:CLASSPATH:.:" -jar argouml.jarse estarían cargando los
archivos incluidos en el componente JAR llamado log4j, misma sintaxis que
puede ser utilizada para los otros archivos JAR de ArgoUML.
● A nivel global en la variable CLASSPATH : Agregando la ubicación de los
diversos archivos JAR alternos a la variable ambiental CLASSPATH, se evita
especificar éstos en cada ocasión que se invoque ArgoUML.

IMPLEMENTACIÓN DE BASES DE DATOS EN UML
La creación de modelos de UML se basa en los principios de
programación orientada a objetos. UML define un conjunto estándar de
diagramas de creación de modelos para todas las fases de desarrollo de
un sistema de software.
Esta información describe el modelo de relación de entidad del diseño de
base de datos. Otro modelo que se puede utilizar es Unified Modeling
Language (UML). El grupo de gestión de objetos es un consorcio que
creó el estándar de UML. Este tema proporciona una breve visión general
de UML.

A continuación se proporcionan algunos ejemplos de diagramas de UML:
● Clase
● Identifica entidades de alto nivel, conocidas como clases. Una clase describe un
conjunto de objetos que tienen los mismos atributos. Un diagrama de clases
muestra las relaciones entre clases.
● Caso de uso
● Presenta una vista de alto nivel de un sistema desde la perspectiva del usuario.
Un diagrama de casos de uso define las interacciones entre los usuarios y las
aplicaciones o entre aplicaciones. Estos diagramas describen gráficamente el
comportamiento del sistema. Puede trabajar con diagramas de casos de uso para
capturas requisitos del sistema, conocer cómo funciona el sistema y especificar el
comportamiento del sistema.

Actividad
● Crea modelos del flujo de trabajo de un proceso empresarial, generalmente definiendo
reglas para la secuencia de actividades del proceso. Por ejemplo, una empresa de
contabilidad puede utilizar diagramas de actividades para crear modelos de
transacciones financieras.
Interacción
● Muestra la secuencia necesaria de interacciones entre objetos. Los diagramas de
interacciones pueden incluir diagramas de secuencias y diagramas de colaboraciones.
● Los diagramas de secuencias muestran interacciones entre objetos en una secuencia
basada en el tiempo que establece los roles de objetos y ayuda a determinar interfaces
y responsabilidades de clases.
● Los diagramas de colaboraciones muestran asociaciones entre objetos que definen la
secuencia de mensajes que implementan una operación o una transacción.

Componente
● Muestra las relaciones de dependencia entre componentes como, por ejemplo, programas
principales y subprogramas.
● Numerosas herramientas disponibles de la familia de productos de WebSphere y Rational
facilitan la tarea de crear un modelo de UML. Los desarrolladores pueden representar
gráficamente la arquitectura de una base de datos y cómo ésta interactúa con aplicaciones
utilizando las siguientes herramientas de creación de modelos de UML:
● WebSphere Business Integration Workbench, que proporciona un creador de modelos de
UML para crear diagramas de UML estándar.
● Un conector de WebSphere Studio Application Developer para crear modelos de
aplicaciones y servicios web de Java y para correlacionar el modelo de UML con el modelo
de relación de entidad.

DIAGRAMA DE CLASES
En ingeniería de software, un diagrama de clases en Lenguaje Unificado de Modelado (UML) es un tipo de
diagrama de estructura estática que describe la estructura de un sistema mostrando las clases del sistema, sus
atributos, operaciones (o métodos), y las relaciones entre los objetos.
● El diagrama de clases puede tener como ejemplo: una clase que sería un objeto o persona misma en la
cual se especifica cada acción y especificación.
● Propiedades de objetos que tienen propiedades y/u operaciones que contienen un contexto y un dominio,
los primeros dos ejemplos son clases de datos y el tercero clase de lógica de negocio, dependiendo de
quién diseñe el sistema se pueden unir los datos con las operaciones.
● El diagrama de clases incluye mucha más información como la relación entre un objeto y otro, la herencia
de propiedades de otro objeto, conjuntos de operaciones/propiedades que son implementadas para una
interfaz gráfica.
● Presenta las clases del sistema con sus relaciones estructurales y de herencia.
● El diagrama de clases es la base para elaborar una arquitectura MVC o MVP.

VENTAJAS
● Genera un código auto
● máticamente.
● Propone soluciones a algunos errores.
● Representa las relaciones entre las clases de sistema.
● Se diseña los componentes de los sistemas.
● Se protegen los datos.
● Se posibilita una reducción de acoplamiento.
● Mas fácil la comunicación entre los programadores, descubrimiento de fallas del sistema en
el diseño Mejor diseño del sistema ofrece más documentación.

DESVENTAJAS
● Los diagramas de clases especifican qué clases hay y cómo están
relacionadas, pero no cómo interactúan para alcanzar comportamientos
particulares.
● El método tiende hacer muy lento.
● La instalación es muy costosa

DIAGRAMA DE SECUENCIA
El diagrama de secuencia es un tipo de diagrama usado para modelar
interacción entre objetos en un sistema según UML.
VENTAJAS:
Posibilidad de representar los mensajes en función del tiempo.
La separación de los mensajes no indica intervalos o cantidades de tiempo, solo
ordenación temporal.
Es posible añadir restricciones temporales.

DESVENTAJAS
Un diagrama de secuencia demasiado largo, puede ser difícilmente
entendido por alguien ajeno al sistema.

DIAGRAMA DE CASO DE USO
En el Lenguaje de Modelado Unificado, un diagrama de casos de uso es una
forma de diagrama de comportamiento UML mejorado. El Lenguaje de
Modelado Unificado (UML), define una notación gráfica para representar
casos de uso llamada modelo de casos de uso. UML no define estándares
para que el formato escrito describa los casos de uso, y así mucha gente no
entiende que esta notación gráfica define la naturaleza de un caso de uso;
sin embargo una notación gráfica puede solo dar una vista general simple de
un caso de uso o un conjunto de casos de uso. Los diagramas de casos de
uso son a menudo confundidos con los casos de uso.

VENTAJAS
Su ventaja principal es la facilidad para interpretarlos, y hacen que sean
especialmente útiles en la comunicación con el cliente.
• Identifica requerimientos estancados, dentro de un conjunto de
requerimientos.
• Permite representar más de un rol para cada afectado.
• El lenguaje que utilizan es común y entendible para el usuario.

DESVENTAJAS
En sistemas grandes toman mucho tiempo para definir todos los casos de
uso.
• El análisis de calidad depende de cómo se haya realizado la descripción
inicial del caso de uso.

DIAGRAMA DE COMPONENTES
Un diagrama de componentes es un diagrama tipo del Lenguaje Unificado de Modelado.
Un diagrama de componentes representa cómo un sistema de software es dividido en
componentes y muestra las dependencias entre estos componentes. Los componentes
físicos incluyen archivos, cabeceras, bibliotecas compartidas, módulos, ejecutables, o
paquetes. Los diagramas de Componentes prevalecen en el campo de la arquitectura de
software pero pueden ser usados para modelar y documentar cualquier arquitectura de
sistema.
Debido a que los diagramas de componentes son más parecidos a los diagramas de casos
de usos, éstos son utilizados para modelar la vista estática y dinámica de un sistema.
Muestra la organización y las dependencias entre un conjunto de componentes. No es
necesario que un diagrama incluya todos los componentes del sistema, normalmente se
realizan por partes. Cada diagrama describe un apartado del sistema.

VENTAJAS
Representan aspectos físicos del sistema.
● Se pueden construir a partir del modelo de clases y escribir desde cero para
el nuevo sistema.
● Se puede importar de otros proyectos o de productos terceros.
DESVENTAJAS
● No representan aspectos irremplazables del sistema

DIAGRAMA DE ESTADO
Un diagrama de estados, en ocasiones conocido como diagrama de máquina
de estados, es un tipo de diagrama de comportamiento en el Lenguaje
Unificado de Modelado (UML). Se especializa en mostrar transiciones entre
diversos objetos.

VENTAJAS
● El Diagrama de Estados tiene éxito en sistemas interactivos, ya que expresa la
intención que tiene el actor (su usuario) al hacer uso del sistema.
● Como técnica de extracción de requerimiento permite que el analista se centre en las
necesidades del usuario, que espera éste lograr al utilizar el sistema, evitando que la
gente especializada en informática dirija la funcionalidad del nuevo sistema basándose
solamente en criterios tecnológicos.
● A su vez, durante la extracción (elicitation en inglés), el analista se concentra en las
tareas centrales del usuario describiendo por lo tanto los casos de uso que mayor valor
aportan al negocio. Esto facilita luego la priorización del requerimiento.

DESVENTAJAS
● La inclusión de estas relaciones hace que los diagramas sean más difíciles
de leer, sobre todo para los clientes.

DIAGRAMA DE DESPLIEGUE
Los diagramas de despliegue son los complementos de los diagramas de
componentes que, unidos, proveen la vista de implementación del
sistema. Describen la topología del sistema la estructura de los
elementos de hardware y el software que ejecuta cada uno de ellos.Los
diagramas de despliegue representan a los nodos y sus relaciones. Los
nodos son conectados por asociaciones de comunicación tales como
enlaces de red, conexiones TCP/IP.

VENTAJAS
● Muestra un conjunto de nodos y sus relaciones.
● Se utilizan para describir la vista de despliegue estática de un
sistema.
● Se relacionan con los diagramas de componentes, ya que un nodo
normalmente incluye uno o más componentes.

DESVENTAJAS
● La posible falla en la modelación de un hardware.
● Tales sistemas contienen a menudo varias versiones de
componentes software, alguno de los cuales pueden incluso migrar
de un nodo a otro.El diseño de tales sistemas requiere tomar
decisiones que permitan un cambio continuo de la topología del
sistema.

DIAGRAMA DE ACTIVIDADES
El Lenguaje Unificado de Modelado tiene varios subconjuntos de diagramas que
puede modelar, incluidos los diagramas estructurales, los diagramas de interacción y
los diagramas de comportamiento. Los diagramas de actividades son un subconjunto
de estos últimos. Junto con los diagramas de casos de uso y de máquinas de estado,
se usan para describir las actividades de negocios y la funcionalidad de los sistemas
de software. Usarás un conjunto de símbolos especializados incluidos aquellos para
pasos de inicio, finalización, fusión y recepción en el flujo para crear un diagrama de
actividades.
Las partes interesadas tienen muchos asuntos que manejar, por lo que es importante
una comunicación clara y breve. Los diagramas de actividades ayudan a que las
personas en las áreas de negocios y desarrollo de una organización se integren.

VENTAJAS
● Ayudan a las personas que trabajan en el proceso a entender el mismo , con lo
que facilitaran su incorporación a la organización e incluso, su colaboración en la
búsqueda de mejoras del proceso y sus deficiencias.
● Al presentarse el proceso de una manera objetiva, se permite con mayor facilidad
la identificación de forma clara de las mejoras a proponer.
● Permite que cada persona de la empresa se sitúe dentro del proceso, lo que
conlleva a poder identificar perfectamente quien es su cliente y proveedor interno
dentro del proceso y su cadena de relaciones, por lo que se mejora
considerablemente la comunicación entre los departamentos y personas de la
organización.

DESVENTAJAS
● Normalmente sucede que las personas que participan en la elaboración del
diagrama de flujo se suelen volver entusiastas partidarias del mismo, por lo que
continuamente proponen ideas para mejorarlo.
● Es obvio que los diagramas de flujo son herramientas muy valiosas para la
formación y entrenamiento del nuevo personal que se incorpore a la empresa.
● Lo más reseñable es que realmente se consigue que todas las personas que
están participando en el proceso lo entenderán de la misma manera, con lo que
será más fácil lograr motivarlas a conseguir procesos más económicos en tiempo
y costes y mejorar las relaciones internas entre los cliente-proveedor del proceso.

Desarrollo de uml

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Desarrollo de uml

Similar a Desarrollo de uml (20)

Último

Último (20)

Desarrollo de uml