1. Trabajo de ingenieria de software
NOMBRE: OSCAR ALARCON
NIVEL: SEXTO SISTEMAS
FECHA: 27 de julio del 2012

2. PAUTAS GENERALES PARA DESARROLLAR USANDO
UML
NTRODUCCIÓN
PAUTAS GENERALES PARA DESARROLLAR USANDO UML
Paquetes y dependencia
Diagrama de Casos de Uso
Diagrama de Secuencia y diagrama de Colaboración
Diagrama de Objetos y diagrama de Clases
Diagrama de Estados
Diagrama de Componentes
Diagrama de Despliegue
CONCLUSIONES
REFERENCIAS

3. Paquetes
Es desde este punto de vista que podemos apreciar el gran cambio
que han significado los objetos. Ha desaparecido la separación
entre el proceso y los datos, y la descomposición funcional, pero la
vieja pregunta sigue en pie. Una idea es agrupar las clases en
unidades de nivel más alto. Esta idea aparece, aplicada de manera
muy libre, en muchos métodos orientados a objetos. En el UML, a
este mecanismo de agrupamiento se le llama paquete.
La idea de un paquete se puede aplicar a cualquier elemento de un
modelo, no sólo a las clases. Sin cierta heurística que agrupe las
clases, el agrupamiento se vuelve arbitrario. El que yo he
encontrado más útil, que también es el que recibe mayor énfasis en
el UML, es la de pendencia. Empleo el término diagrama de
paquetes para indicar un diagrama que muestra los paquetes de
clases y las dependencias entre ellos.

4. Dependencia
● Existe una (dependency) dependencia entre dos elementos si
los cambios a la definición de un elemento pueden causar
cambios al otro. En las clases, la dependencia existe por varias
razones: una clase envía un mensaje a otra; una clase tiene a
otra como parte de sus datos; una clase menciona a otra como
parámetro para una operación. Si una clase cambia su interfaz,
entonces los mensajes que envía pueden dejar de ser válidos.
● En forma ideal, sólo los cambios a una interfaz de clase
deberían afectar a otra clase. El arte del diseño en gran escala
implica minimizar las dependencias, de modo tal que se
reduzcan los efectos del cambio y se requiera de menos
esfuerzo para cambiar el sistema.

5. Casos de uso
● Describen qué hace el sistema desde el punto de vista de un
observador externo.
● Ponen énfasis en qué hace el sistema, no en cómo lo hace.
hace.
● Un escenario es una instancia particular de un escenario es
una instancia particular de undiagrama de casos de uso.
● Ejemplo de lo que ocurre cuando alguien interactúa con el
sistema
● Actor = Algo con comportamiento (persona, otro programa,
organización...), que interactua con el sistema.
● Escenario (instancia de caso de uso) = Secuencia de acciones
e interacciones entre los actores y el sistema.
● Caso de Uso = Colección de escenarios (éxito y fracaso) que
describen actores que usan el que describen actores que
usan el sistema para conseguir un objetivo.

6. Diagrama de clases y de objetos
Diagramas de clases. Estructura del sistema.
● Clases.
Atributos: Tipos, valores iniciales.
Operaciones: visibilidad.
● Relaciones Relaciones con otras clases: Asociaciones
Diagramas de objetos. Estructura del sistema en tiempo de
ejecución.
● Objetos. Instancias de una Clase.
Atributos (valores actuales).
● Links. Relaciones entre objetos, instancias de asociaciones.

7. Diagrama de secuencia y colaboraicon
● Un diagrama de secuencia muestra la interacción de un
conjunto de objetos en una aplicación a través del tiempo y se
modela para cada caso de uso. Mientras que el diagrama de
casos de uso permite el modelado de una vista business del
escenario, el diagrama de secuencia contiene detalles de
implementación del escenario, incluyendo los objetos y clases
que se usan para implementar el escenario, y mensajes
intercambiados entre los objetos.
● Un diagrama de colaboración' en las versiones de UML 1.x es
esencialmente un diagrama que muestra interacciones
organizadas alrededor de los roles. A diferencia de los
diagramas de secuencia, los diagramas de colaboracion,
también llamados diagramas de comunicación, muestran
explícitamente las relaciones de los roles. Por otra parte, un
diagrama de comunicación no muestra el tiempo como una
dimensión aparte, por lo que resulta necesario etiquetar con
números de secuencia tanto la secuencia de mensajes como
los hilos concurrentes.

8. Diagrama de estados
● Los diagramas de estado muestran el conjunto de estados por
los cuales pasa un objeto durante su vida en una aplicación en
respuesta a eventos (por ejemplo, mensajes recibidos, tiempo
rebasado o errores), junto con sus respuestas y acciones.
También ilustran qué eventos pueden cambiar el estado de los
objetos de la clase. Normalmente contienen: estados y
transiciones. Como los estados y las transiciones incluyen, a
su vez, eventos, acciones y actividades, vamos a ver primero
sus definiciones.
Al igual que otros diagramas, en los diagramas de estado
pueden aparecer notas explicativas y restricciones.

9. DIAGRAMAS DE COMPONENTES
Este diagrama representa a una entidad real (un componente de
software).Pero, ¿qué es un componente?, un compone de
software es la parte física de un sistema, yse encuentra en la
computadora, no en la mente del analista, un componente
puede ser porejemplo una Tabla, un archivo de datos, biblioteca
de vínculos dinámicos, documentos ycosas por el estilo.Pero
para que modelar componentes y sus relaciones, la respuesta a
esto es muy sencilla,esto se hará para que:1. Los clientes
puedan ver la estructura del sistema finalizada.2. Los
desarrolladores cuenten con una estructura con la cual trabajar
en adelante.3. Quienes escriban las notas técnicas y la
documentación puedan entender queescribirán.4. Para poder
volver a utilizar los componentes.Cabe mencionar que uno de
los puntos más importantes de los componentes es el
potencialde poder volver a ser utilizados

10. Diagrama de Despliegue
El Diagrama de Despliegue es un tipo de diagrama del Lenguaje
Unificado de Modelado que se utiliza para modelar el hardware
utilizado en las implementaciones de sistemas y las relaciones
entre sus componentes.
Los elementos usados por este tipo de diagrama son nodos
(representados como un prisma), componentes (representados
como una caja rectangular con dos protuberancias del lado
izquierdo) y asociaciones.
En el UML 2.0 los componentes ya no están dentro de nodos.
En cambio, puede haber artefactos u otros nodos dentro de un
nodo. Este tipo de diagrama debemos también añadir que no
van a existir actores para relacionarse con los nodos (no es un
diagrama de casos de uso) si no que las relaciones que pueda
haber siempre seran entre los nodos y por ejemplo con una
base de datos.

11. Conclucion
●El lenguaje Unificado de modelado UML es una notación que
es el resultado de la evolución de las notaciones previas en
ingeniería de software, toma los aspectos fuertes de tres
metodologías anteriores: OMT, Booch y OOSE.
●La notación UML se fundamenta en principios de modelado, lo
cual es importante para toda implementación de un sistema de
información.
El UML debe adoptar el Proceso Unificado de Desarrollo para
●
modelar las actividades de un proyecto.
●Los diagramas a utilizar en las diferentes etapas del desarrollo
de los sistemas de información, pueden variar dependiendo del
tamaño y tipo de sistema, por lo que es necesario organizarlos
según las fases del Proceso Unificado.

12. Referencias
http://es.wikipedia.org/wiki/Diagrama_de_despliegue
http://es.wikipedia.org/wiki/Diagrama_de_secuencia
http://es.wikipedia.org/wiki/Diagrama_de_colaborac
http://es.scribd.com/doc/43944315/Ya-Diagramas-de-Componentes-U
http://es.wikipedia.org/wiki/Diagrama_de_estados
http://astreo.ii.uam.es/~jlara/TACCII/5_UML_rev1.pdf