1. CBT 2° DR. MARIO JOSE MOLINA HENRIQUEZ
MATERIA: SUBMODULO III
PROFR. IMELDA GOMEZ
Ken Castañeda Colina
2° “C”
2. • Es un lenguaje gráfico para visualizar, especificar, construir y documentar un
sistema. UML ofrece un estándar para describir un "plano" del sistema (modelo),
incluyendo aspectos conceptuales tales como procesos, funciones del sistema, y
aspectos concretos como expresiones de lenguajes de programación, esquemas
de bases de datos y compuestos reciclados.
• UML no puede compararse con la programación estructurada, pues UML
significa Lenguaje Unificado de Modelado, no es programación, solo se diagrama
la realidad de una utilización en un requerimiento. Mientras que programación
estructurada es una forma de programar como lo es la orientación a objetos, la
programación orientada a objetos viene siendo un complemento perfecto de
UML, pero no por eso se toma UML solo para lenguajes orientados a objetos.
¿QUE ES UML?
3. 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”.
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
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).
4. los tres amigos) de la ingeniería de software, como se los conocía, habían desarrollado otras metodologías. Se asociaron
para brindar claridad a los programadores creando nuevos estándares. La colaboración entre Grady, Booch y Rumbaugh
fortaleció los tres métodos y mejoró el producto final.
Los esfuerzos de estos pensadores derivaron en la publicación de los documentos UML 0.9 y 0.91 en 1996. Pronto se
hizo evidente que varias organizaciones, incluidas Microsoft, Oracle e IBM, consideraron que UML era esencial para su
propio desarrollo de negocios. Ellos, junto con muchas otras personas y compañías, establecieron los recursos
necesarios para desarrollar un lenguaje de modelado hecho y derecho. "Los tres amigos" publicaron la Guía del usuario
para el Lenguaje Unificado de Modelado en 1999, y una actualización que incluye información sobre UML 2.0 en la
segunda edición de 2005.
5.
6. 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.
7. 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.
8. REQUERIMIENTOS
• Procesador Intel® Pentium® (o mejor)
• Microsoft® Windows 98 SE, Windows NT® 4.0 con Service Pack 5, Windows 2000,
Windows XP o Windows 2003
• 128 MB de RAM (256MB o más)
• Espacio en disco disponible de 70 MB
• 800*600 (1024x768 o más)
9. IMPLEMENTACIÓN DE BASE DE
DATOS DE UML
• La creación de modelos de Uml se basa en los principios de programación orientada
a objetos.
• UML define un conjunto de desarrollador de un sistema de software la información
describe el modelo de relación de entidad del diseño de base de datos.
• Otro modelo que se puede utilizar el grupo de gestión de objetos es un consorcio
que creo el estándar de UML
11. DIAGRAMAS DE CLASES
• Muestran un conjunto de clases, interfaces y colaboraciones, así como sus relaciones.
Estos diagramas son los más comunes en el modelado de sistemas orientados a objetos y
cubren la vista de diseño estática o la vista de procesos estática (sí incluyen clases activas).
ventajas
*Generar el código
*Propone soluciones errores
*Se protegen datos
*Se hace una reducción de acoplamiento
DESVENTAJAS
EL METODO ES MUY LENTO
ES MUY COSTOSA LA INTALACION
12.
13.
14.
15.
16.
17.
18.
19. DIAGRAMAS DE CASO DE USO
• Diagramas de Casos de Usos
Muestran un conjunto de casos de uso y actores (tipo especial de clases) y sus
relaciones. Cubren la vista estática de los casos de uso y son especialmente
importantes para el modelado y organización del comportamiento.
VENTAJAS
*PREPERMITE REPRESENTAR UN ROL AL AFECTADO
*ENGUAJE UTILIZADO ES MUY COMUN
DESENTAJAS
ANALIZA LA CALIDAD QUE DEPENDE COMO SE HAYA REALIZADO
20.
21.
22.
23.
24.
25. DIAGRAMA DE SECUENCIA
• Este diagrama es un tipo de diagrama usado ara moldear interacción en objetos en
un sistema de UML
DESVENTAJAS
*ES MUY LARGO Y TEDIOSO
VENTAJAS
*ES MUCHO MEJOR REPRESENTAR UN MENSAJE UNA FUNCION
*SE AÑADE RESTRICCIONES TEMPORALES
26.
27.
28.
29.
30.
31.
32. DIAGRAMAS DE COMPONENTES
• Muestra la organización y las dependencias entre un conjunto de componentes. Cubren la vista de la
implementación estática y se relacionan con los diagramas de clases ya que en un componente suele
tener una o más clases, interfaces o colaboraciones
VENTAJAS
*REPRESENTAN ASPECTOS FISICOS DEL SISTEMA
*SE PUEDE IMORTAR DE OTRS PROYECTOS
DESVENTAJAS
NO SE REPRESENTAN LOS ASPECTOS IRREMLAZABLES
33.
34.
35.
36.
37.
38.
39. DIAGRAMA DE ESTADOS
• Los diagramas de estado son un método conocido para explicar el comportamiento
de un sistema. Que explican todos los estados posibles en los que puede ingresar
un objeto particular y la manera en que modifica el estado del objeto, como
resultado de los eventos que llegan
40. VENTAJAS
• Ventajas
La técnica de caso de uso 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, qué 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.
41. DESVENTAJAS
La inclusión de estas relaciones hace que los diagramas sean más difíciles de leer,
sobre todo para los clientes.
42. DIAGRAMAS DE DESPLIEGUE
• Representan la configuración de los nodos de procesamiento en tiempo de ejecución y los
componentes que residen en ellos. Muestran la vista de despliegue estática de una
arquitectura y se relacionan con los componentes ya que, por lo común, los nodos
contienen uno o más componentes.
VENTAJAS
MUESTRA UN CONJUNTO DE NODOS Y SUS RELACIONES
SE UTILIZAN DESCRIBIR LA VISTA DE DESPLIEGUE ESTTICA DE UNSISTEMA
SE REALIZAN CON LOS DIAGRAMAS DE COMPONENTES; YA QE UN NODO NORMAMENTE
43. DESVENTAJAS
• LA POSIVILIDAD EN LA MODELACION DE UN HARDWARE
• TALES SISTEMAS CONTIENE A MENUDO VARIAS VERCIONES DE
COMPONETES SOFTWARE