Embed Size (px)
DESCRIPTION
clase de introducción a uml
Citation preview
UML
Tecnología de Objetos
Origen de UML
Como consecuencia del nacimiento de los primeros lenguajes de programación OO así como de la complejidad creciente de las aplicaciones, comienzan a surgir, en la década de los 80, los primeros métodos de análisis y diseño OO.
Así, fue necesario diseñar un método que permitiera unificar las teorías planteadas hasta el momento para estandarizar la emergente tendencia
Por esta razón, Booch, Jackobson y Rumbaugh se unieron para crear el lenguaje unificado UML
Reseña histórica
El Lenguaje de Modelado Unificado (UML) fue aprobado en septiembre 1997 como lenguaje estándar de modelado de sistemas orientados a objetos por la OMG
La versión 1.2 apareció en 1998La versión 1.3 en 1999En el 2002 apareció la versión 2.0
Diagramas primarios
Diagramas de Casos de Uso
Modelo Conceptual
Diseño de Clases
Diagramas de Asociación
Diagramas de Secuencia
Diagramas de Colaboración
Diagramas de Casos de Uso
Los casos de uso son descripciones narrativas en lenguaje natural de los procesos del dominio en un formato estructurado de prosa.
Los casos de uso no son propiamente un elemento del análisis y diseño orientado a objetos (pueden ser utilizados en análisis no orientados a objetos), pero constituyen un paso preeliminar muy útil porque describen las especificaciones de un sistema.
Los casos de uso requieren tener al menos un conocimiento parcial de los requerimientos del sistema.
Un caso de uso es un documento narrativo que describe la secuencia de eventos de un actor (agente externo) que utiliza un sistema para completar un proceso.
Para especificar los casos de uso en el lenguaje UML, se utiliza un elipse que encierra el nombre del caso
Diagramas de Casos de Uso
Los casos primarios de uso representan los procesos comunes más importantes. Los casos secundarios de uso representan procesos menores o raros. Finalmente, los casos opcionales de uso representan procesos que pueden no abordarse
Es conveniente comenzar con los casos de uso de alto nivel para lograr rápidamente entender los principales procesos globales.
Este esquema tiene por objeto ofrecer una clase de diagrama contextual que nos permita conocer rápidamente los actores externos de un sistema y las formas básicas en que lo utilizan.
Un caso de uso describe la interacción con un sistema.
Diagramas de Casos de Uso
Las fronteras del sistema se representan en el diagrama por un rectángulo exterior.
Las fronteras corresponden a: la frontera hardware/software de un dispositivo o sistema de cómputo, un departamento de una organización, o la organización entera.
En síntesis, para determinar los casos de uso de un sistema, es necesario, como primer paso, identificar los actores y sus funciones. El segundo paso es describir los casos de uso. El tercer paso es dibujar el diagrama de casos de uso
El Modelo Conceptual
Un modelo conceptual muestra gráficamente, a través de un grupo de diagramas, los conceptos (clases de objetos), los atributos y las asociaciones más importantes del dominio.
Un modelo conceptual explica los conceptos significativos en un dominio del problema, identificando los atributos y las asociaciones, y es la herramienta más importante del análisis orientado a objetos.
Los casos de uso son una importante herramienta para el análisis de requerimientos, pero realmente no están orientados a objetos.
El Modelo Conceptual
Un modelo conceptual representa cosas del mundo real, no componentes del software.
En UML se representa mediante un grupo de diagramas de estructura estática donde no se define ninguna operación.
En estos diagramas se muestran conceptos (objetos), asociaciones entre conceptos (relaciones) y atributos de conceptos (atributos).
Un modelo conceptual es una descripción del dominio de un problema real, no es una descripción del diseño del software. Debido a esto, no es conveniente aquí incluir elementos como ventanas o bases de datos.
El Modelo Conceptual
Por lo general es mejor exagerar un poco y especificar un modelo conceptual con muchos conceptos. Esto debido a que es frecuente omitir conceptos durante el análisis, y al descubrirlos más tarde, es más difícil incorporarlos.
Diagramas de Diseño de Clases
Para definir las clases de objetos se deben contestar dos preguntas: ¿cómo se conectan unos objetos a otros? y ¿cuáles son los métodos de cada clase?.
Un diagrama de diseño de clases contesta estas preguntas
Diagramas de asociación
Una asociación es una relación entre dos conceptos que indica alguna conexión significativa entre ellos.
Las asociaciones útiles a determinar, suelen incluir el conocimiento de una relación que ha de preservarse por algún tiempo: puede tratarse de milisegundos o de años (según el contexto).
Una asociación se representa como una línea entre conceptos, con el nombre de la asociación.
La asociación es intrínsecamente bidireccional, es un posible nexo lógico entre los objetos.
Diagramas de Asociación
Este nexo es totalmente abstracto, no es una afirmación sobre las conexiones entre las entidades del software.
Los extremos de una asociación pueden contener una expresión de multiplicidad que indica la relación numérica entre las instancias de los conceptos.
Opcionalmente se puede poner una flecha que indique la dirección en que debe leerse el nombre de la asociación (no indica nada más, es sólo una ayuda para leer el diagrama).
Contratos
Para ayudar a explicar lo que una operación (o evento del sistema) se propone hacer, es conveniente usar contratos.
Un contrato de operación del sistema describe los cambios de estado del sistema total cuando se llama a una de sus operaciones.
Diagramas de Secuencia
El diagrama de secuencia de un sistema muestra gráficamente los eventos que originan los actores.
La creación de los diagramas de secuencia forma parte de la investigación para conocer el sistema, por lo que es parte del análisis del mismo.
La creación de los diagramas de secuencia depende de la formulación de los casos de uso.
Los casos de uso indican cómo los actores interactúan con el sistema.
Durante la operación del sistema, los actores generan eventos, solicitando alguna operación a cambio.
Diagramas de Colaboración
Los contratos muestran qué hacen las operaciones del sistema, pero no muestran cómo los objetos de software van a cumplir con ellas.
Los diagramas de interacción (diagramas de secuencia o diagramas de colaboración) explican gráficamente cómo los objetos interactúan a través de mensajes para realizar las tareas.
Antes de definir estos diagramas, hay que generar el modelo conceptual, los contratos de operación y los casos de uso reales (estos últimos se generan a partir de los casos de uso definidos en el análisis).
Diagramas de Colaboración
Los diagramas de colaboración explican gráficamente las interacciones entre las instancias del modelo (objetos).
Los diagramas de colaboración representan el flujo de mensajes entre las instancias y la invocación de métodos.
Análisis y Diseño
La habilidad más importante en el análisis y diseño orientado al objeto es asignar eficientemente las responsabilidades a los componentes de software.
En segundo lugar aparece la determinación de las clases de objetos.
Durante el análisis y diseño orientado a objetos, se procura identificar, describir y definir los objetos que finalmente serán implementados en un lenguaje de programación orientado a objetos.
Ejemplo: Un juego de dados.
Se tiene un juego de dados en que un jugador lanza dos dados.
Si el total obtenido es siete, el jugador gana, de lo contrario pierde.
Juego de dados: Definición de casos de uso
Caso de uso: Jugar un juego.
Participantes: Jugador.
Descripción: Este caso de uso comienza cuando el jugador recoge y tira los dados. Si los puntos suman siete, gana y pierde si suman cualquier otro número.
Juego de Dados: Diagrama de caso de uso
Juego de Dados: Modelo Conceptual
Juego de Dados: Diagramas de Colaboración
¿Como denotar Clases y Objetos?
Juego de Dados: Diseño de Clases
