Descargar para leer sin conexión
Subido porMauricio Alarcon
UML
Este documento presenta las pautas generales para desarrollar usando el Lenguaje Unificado de Modelado (UML), incluyendo diagramas de paquetes y dependencia, casos de uso, secuencia y colaboración, clases y objetos, estados, componentes y despliegue. Explica cada uno de estos diagramas UML y cómo modelar diferentes aspectos de un sistema de software.
Más contenido relacionado
UML
- 1. Trabajo de ingenieriade software NOMBRE: OSCAR ALARCON NIVEL: SEXTO SISTEMAS FECHA: 27 de julio del 2012
- 2. PAUTAS GENERALES PARADESARROLLAR 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 estepunto 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 clasesy 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 secuenciay 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 Estediagrama 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 ElDiagrama 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 Unificadode 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.