UML
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
552
On Slideshare
552
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
5
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Trabajo de ingenieria de softwareNOMBRE: OSCAR ALARCON NIVEL: SEXTO SISTEMAS FECHA: 27 de julio del 2012
  • 2. PAUTAS GENERALES PARA DESARROLLAR USANDO UMLNTRODUCCIÓNPAUTAS GENERALES PARA DESARROLLAR USANDO UMLPaquetes y dependenciaDiagrama de Casos de UsoDiagrama de Secuencia y diagrama de ColaboraciónDiagrama de Objetos y diagrama de ClasesDiagrama de EstadosDiagrama de ComponentesDiagrama de DespliegueCONCLUSIONESREFERENCIAS
  • 3. PaquetesEs desde este punto de vista que podemos apreciar el gran cambioque han significado los objetos. Ha desaparecido la separaciónentre el proceso y los datos, y la descomposición funcional, pero lavieja pregunta sigue en pie. Una idea es agrupar las clases enunidades de nivel más alto. Esta idea aparece, aplicada de maneramuy libre, en muchos métodos orientados a objetos. En el UML, aeste mecanismo de agrupamiento se le llama paquete.La idea de un paquete se puede aplicar a cualquier elemento de unmodelo, no sólo a las clases. Sin cierta heurística que agrupe lasclases, el agrupamiento se vuelve arbitrario. El que yo heencontrado más útil, que también es el que recibe mayor énfasis enel UML, es la de pendencia. Empleo el término diagrama depaquetes para indicar un diagrama que muestra los paquetes declases y las dependencias entre ellos.
  • 4. Dependencia● Existe una (dependency) dependencia entre dos elementos silos cambios a la definición de un elemento pueden causarcambios al otro. En las clases, la dependencia existe por variasrazones: una clase envía un mensaje a otra; una clase tiene aotra como parte de sus datos; una clase menciona a otra comopará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 clasedeberían afectar a otra clase. El arte del diseño en gran escalaimplica minimizar las dependencias, de modo tal que sereduzcan los efectos del cambio y se requiera de menosesfuerzo 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 objetosDiagramas 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 unconjunto de objetos en una aplicación a través del tiempo y semodela para cada caso de uso. Mientras que el diagrama decasos de uso permite el modelado de una vista business delescenario, el diagrama de secuencia contiene detalles deimplementación del escenario, incluyendo los objetos y clasesque se usan para implementar el escenario, y mensajesintercambiados entre los objetos.● Un diagrama de colaboración en las versiones de UML 1.x esesencialmente un diagrama que muestra interaccionesorganizadas alrededor de los roles. A diferencia de losdiagramas de secuencia, los diagramas de colaboracion,también llamados diagramas de comunicación, muestranexplícitamente las relaciones de los roles. Por otra parte, undiagrama de comunicación no muestra el tiempo como unadimensión aparte, por lo que resulta necesario etiquetar connúmeros de secuencia tanto la secuencia de mensajes comolos hilos concurrentes.
  • 8. Diagrama de estados● Los diagramas de estado muestran el conjunto de estados porlos cuales pasa un objeto durante su vida en una aplicación enrespuesta a eventos (por ejemplo, mensajes recibidos, tiemporebasado o errores), junto con sus respuestas y acciones.También ilustran qué eventos pueden cambiar el estado de losobjetos de la clase. Normalmente contienen: estados ytransiciones. Como los estados y las transiciones incluyen, asu vez, eventos, acciones y actividades, vamos a ver primerosus definiciones.Al igual que otros diagramas, en los diagramas de estadopueden aparecer notas explicativas y restricciones.
  • 9. DIAGRAMAS DE COMPONENTESEste diagrama representa a una entidad real (un componente desoftware).Pero, ¿qué es un componente?, un compone desoftware es la parte física de un sistema, yse encuentra en lacomputadora, no en la mente del analista, un componentepuede ser porejemplo una Tabla, un archivo de datos, bibliotecade vínculos dinámicos, documentos ycosas por el estilo.Peropara que modelar componentes y sus relaciones, la respuesta aesto es muy sencilla,esto se hará para que:1. Los clientespuedan ver la estructura del sistema finalizada.2. Losdesarrolladores cuenten con una estructura con la cual trabajaren adelante.3. Quienes escriban las notas técnicas y ladocumentación puedan entender queescribirán.4. Para podervolver a utilizar los componentes.Cabe mencionar que uno delos puntos más importantes de los componentes es elpotencialde poder volver a ser utilizados
  • 10. Diagrama de DespliegueEl Diagrama de Despliegue es un tipo de diagrama del LenguajeUnificado de Modelado que se utiliza para modelar el hardwareutilizado en las implementaciones de sistemas y las relacionesentre sus componentes.Los elementos usados por este tipo de diagrama son nodos(representados como un prisma), componentes (representadoscomo una caja rectangular con dos protuberancias del ladoizquierdo) 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 unnodo. Este tipo de diagrama debemos también añadir que novan a existir actores para relacionarse con los nodos (no es undiagrama de casos de uso) si no que las relaciones que puedahaber siempre seran entre los nodos y por ejemplo con unabase de datos.
  • 11. Conclucion●El lenguaje Unificado de modelado UML es una notación quees el resultado de la evolución de las notaciones previas eningeniería de software, toma los aspectos fuertes de tresmetodologías anteriores: OMT, Booch y OOSE.●La notación UML se fundamenta en principios de modelado, locual es importante para toda implementación de un sistema deinformació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 desarrollode los sistemas de información, pueden variar dependiendo deltamaño y tipo de sistema, por lo que es necesario organizarlossegún las fases del Proceso Unificado.
  • 12. Referenciashttp://es.wikipedia.org/wiki/Diagrama_de_desplieguehttp://es.wikipedia.org/wiki/Diagrama_de_secuenciahttp://es.wikipedia.org/wiki/Diagrama_de_colaborachttp://es.scribd.com/doc/43944315/Ya-Diagramas-de-Componentes-Uhttp://es.wikipedia.org/wiki/Diagrama_de_estadoshttp://astreo.ii.uam.es/~jlara/TACCII/5_UML_rev1.pdf