1.

cual era el objetivo de la creacion de uml

Uno de los objetivos principales de la creación de UML era posibilitar el

intercambio de modelos entre las distintas herramientas
CASE orientadas a objetos del mercado. Para ello era necesario definir
una notación y semántica común. Las herramientas
CASE (Computer Aided Software Engineering, Ingeniería de SoftwareAsistida por Computadora) son
diversas aplicaciones informáticas destinadas a aumentar la productividad en el desarrollo
de software reduciendo el costo de las mismas en términos detiempo y de dinero.

2. En qué empresa nació UML?

En 1994 Los Tres Amigos, Se Unieron en Una Empresa llamada Rational Software
Corporation. Uniendo sus Ideas para la creación de la Primera versión de UML. Mas
adelante IBM, accede comprarla. Inmediatamente UML queda Identificada, como producto
de IBM

3. Quienes son los creadores de la versión 0.9 de UML?

Los Creadores de la Versión 0.9 de UML: Ivar Jacobson, Grady Booch y James
Rumbaugh los famosos Tres Amigos
4. Qué empresas respaldaron el lanzamiento de la versión 1.0 de UML?
La Respaldaron mas de 800 Empresas, Organismos Gubernamentales y Universidades.
Que promueven la adopción de dicho proyecto.

5. ¿Qué es el UML?

Respuesta

El Lenguaje Unificado de Modelado preescribe un conjunto de

notaciones y diagramas estándar para modelar sistemas orientados
a objetos, y describe la semántica esencial de lo que estos diagramas y
símbolos significan. Mientras que ha habido muchas notaciones y
métodos usados para el diseño orientado a objetos, ahora los
modeladores sólo tienen que aprender una única notación.

6. En qué tipos de sistemas se puede utilizar UML para efectos de modelamiento?

En Todo tipo de Sistema se puede utilizar. Puesto q UML, esta basado Principalmente en
el paradigma Orientado a Objetos

UML es una notación, no un método. Explique esta aseveración.

UML se Cataloga notación, y no método, por el hecho q es una herramienta muy útil para
representar los modelos del sistema en desarrollo, pero no ofrece ningún tipo de guía o
criterio acerca d como obtener modelos/procesos

7. ¿Por qué el UML no es un método?

Respuesta
El UML es el Lenguaje de Modelado Unificado Orientado a Objetos, UML
no es un método porque no tiene noción de proceso el cual es una
parte importante de un método. Ahora bien si UML no es método;
entonces ¿Cuáles son las etapas a seguir en el desarrollo de sistemas
con UML?, varios especialistas en desarrollo de sistemas de información
arguyen de que existe la necesidad de adoptar un Proceso de Desarrollo
de sistemas para enmarcar las fases importantes que sigue el UML, por
ello los desarrolladores de proyectos de sistemas de información
emplean el Procesos Unificado para dar soluciones adecuadas a las
necesidades de los clientes.
El lenguaje de modelado es la notación (principalmente gráfica) que usan los métodos para
expresar un diseño. El proceso indica los pasos que se deben seguir para llegar a un diseño.

8. Vistas: Las vistas muestran diferentes aspectos del sistema modelado. Una vista no es
una gráfica, pero sí una abstracción que consiste en un número de diagramas y todos
esos diagramas juntos muestran una "fotografía" completa del sistema. Las vistas también
ligan el lenguaje de modelado a los métodos o procesos elegidos para el desarrollo.

10 y 11.

 Vista Use-Case: Una vista que muestra la funcionalidad del sistema como
la perciben los actores externos.

 Vista Lógica: Muestra cómo se diseña la funcionalidad dentro del sistema,

en términos de la estructura estática y la conducta dinámica del sistema.

 Vista de Componentes: Muestra la organización de los componentes de

código.

 Vista Concurrente: Muestra la concurrencia en el sistema, direccionando los

problemas con la comunicación y sincronización que están presentes en un
sistema concurrente.

 Vista de Distribución: muestra la distribución del sistema en la arquitectura

física con computadoras y dispositivos llamados nodos.

12. Tipos de Diagramas de UML

Estructura

 Diagrama de clases
 Diagrama de objetos
 Diagrama de componentes
 Diagrama de estructura compuesta
 Diagrama de paquetes
 Diagrama de despliegue
Comportamiento

 Diagrama de casos de uso

 Diagrama de actividades
 Diagrama de estado
Interacción

 Diagrama de secuencia
 Diagrama de colaboración
 Diagrama de tiempo
 Diagrama de interacción


13.

 Diagrama de casos de uso que muestra a los actores (otros

usuarios del sistema), los casos de uso (las situaciones que se
producen cuando utilizan el sistema) y sus relaciones.

Los diagramas de casos de uso describen las relaciones y las

dependencias entre un grupo de casos de uso y los actores
participantes en el proceso.
Es importante resaltar que los diagramas de casos de uso no están
pensados para representar el diseño y no puede describir los
elementos internos de un sistema. Los diagramas de casos de uso
sirven para facilitar la comunicación con los futuros usuarios del
sistema, y con el cliente, y resultan especialmente útiles para
determinar las características necesarias que tendrá el sistema. En
otras palabras, los diagramas de casos de uso describen qué es lo
que debe hacer el sistema, pero no cómo.

 Diagrama de clases que muestra las clases y la relaciones entre

ellas.
 Los diagramas de clases muestran las diferentes clases que
componen un sistema y cómo se relacionan unas con otras. Se
dice que los diagramas de clases son diagramas «estáticos»
porque muestran las clases, junto con sus métodos y atributos, así
como las relaciones estáticas entre ellas: qué clases «conocen» a
qué otras clases o qué clases «son parte» de otras clases, pero no
muestran los métodos mediante los que se invocan entre ellas.

 Diagrama de secuencia muestra los objetos y sus múltiples

relaciones entre ellos.

Los diagramas de secuencia muestran el intercambio de mensajes

(es decir la forma en que se invocan) en un momento dado. Los
diagramas de secuencia ponen especial énfasis en el orden y el
momento en que se envían los mensajes a los objetos.
En los diagramas de secuencia, los objetos están representados
por líneas intermitentes verticales, con el nombre del objeto en la
parte más alta. El eje de tiempo también es vertical,
incrementándose hacia abajo, de forma que los mensajes son
enviados de un objeto a otro en forma de flechas con los nombres
de la operación y los parámetros.

 Diagrama de colaboración que muestra objetos y sus relaciones,

destacando los objetos que participan en el intercambio de
mensajes.

Los diagramas de colaboración muestran las interacciones que

ocurren entre los objetos que participan en una situación
determinada. Esta es más o menos la misma información que la
mostrada por los diagramas de secuencia, pero destacando la
forma en que las operaciones se producen en el tiempo, mientras
que los diagramas de colaboración fijan el interés en las relaciones
entre los objetos y su topología.
En los diagramas de colaboración los mensajes enviados de un
objeto a otro se representan mediante flechas, mostrando el
nombre del mensaje, los parámetros y la secuencia del mensaje.
Los diagramas de colaboración están indicados para mostrar una
situación o flujo programa específicos y son unos de los mejores
tipos de diagramas para demostrar o explicar rápidamente un
proceso dentro de la lógica del programa.
 Diagrama de estado muestra estados, cambios de estado y
eventos en un objeto o en parte del sistema.

Los diagramas de relaciones de entidad (diagramas ER) muestran

el diseño conceptual de las aplicaciones de bases de datos.
Representan varias entidades (conceptos) en el sistema de
información y las relaciones y restricciones existentes entre ellas.
Una extensión de los diagramas de relaciones de entidad llamado
«diagramas de relaciones de entidad extendida» o «diagramas de
relaciones de entidad mejoradas» (EER), se utiliza para incorporar
las técnicas de diseño orientadas a objetos en los diagramas ER.

 Diagrama de actividad que muestra actividades, así como los

cambios de una a otra actividad junto con los eventos que ocurren
en ciertas partes del sistema.

Los diagramas de actividad describen la secuencia de las

actividades en un sistema. Los diagramas de actividad son una
forma especial de los diagramas de estado, que únicamente (o
mayormente) contienen actividades.

 Diagrama de componentes que muestra los componentes de

mayor nivel de la programación (cosas como Kparts o Java
Beans).
 Los diagramas de componentes muestran los componentes del
software (ya sea las tecnologías que lo forman como Kparts,
componentes CORBA, Java Beans o simplemente secciones del
sistema claramente distintas) y los artilugios de que está
compuesto como los archivos de código fuente, las librerías o las
tablas de una base de datos.
 Los componentes pueden tener interfaces (es decir clases
abstractas con operaciones) que permiten asociaciones entre
componentes.

 Diagrama de implementación que muestra las instancias de los

componentes y sus relaciones.
 Los diagramas de implementación muestran las instancias
existentes al ejecutarse así como sus relaciones. También se
representan los nodos que identifican recursos físicos, típicamente
un ordenador así como interfaces y objetos (instancias de las
clases).

 Diagrama de relaciones de entidad que muestra los datos y las

relaciones y restricciones entre ellos.

Los diagramas de relaciones de entidad (diagramas ER) muestran

el diseño conceptual de las aplicaciones de bases de datos.
Representan varias entidades (conceptos) en el sistema de
información y las relaciones y restricciones existentes entre ellas.
Una extensión de los diagramas de relaciones de entidad llamado
«diagramas de relaciones de entidad extendida» o «diagramas de
relaciones de entidad mejoradas» (EER), se utiliza para incorporar
las técnicas de diseño orientadas a objetos en los diagramas ER.