Uml diagramas-caso-de-uso
Upcoming SlideShare
Loading in...5
×
 

Uml diagramas-caso-de-uso

on

  • 399 views

 

Statistics

Views

Total Views
399
Views on SlideShare
399
Embed Views
0

Actions

Likes
0
Downloads
18
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Uml diagramas-caso-de-uso Uml diagramas-caso-de-uso Presentation Transcript

  • • ¿ Qué es un Objeto ? Un objeto es una entidad física o abstracta que tiene un comportamiento antes ciertos estímulos, tanto externos como de otros objetos específicos que se encuentran dentro del sistema. • Cada objeto es un elemento con características propias. La definición de un tipo de objetos se llama CLASE. • Hay Clases de las cuales no se derivan objetos sin otras clases y se llaman clases abstractas. CLASES Y OBJETOS
  • • ¿ Qué se puede considerar como objeto ? • -Persona -Equipo Hardware -Materiales • -Información -Software -Procesos • -Procedimientos • Objeto Físico:Horno • Operaciones asociadas: Encendido/Apagado/Cargado/Descargado. • Objeto Abstracto:Cola • Operaciones: Agregar/Eliminar/Verificar vacía/ Verificar si llena/Primero cola/Siguiente cola/
  • • Identidad de un objeto Cada objeto tiene su propia identidad que lo distingue de los demás objetos. En otras palabras, dos objetos distintos no son iguales aunque todos los valores de sus atributos sean idénticos. • Tipos de objetos • 1.- Objetos reales • 1.1 Objeto físico: Son objetos extremamente perceptibles ejemplo(vista, olfato,gusto,oído) • 1.2 Objetos psíquicos: Son internamente perceptibles. Ejemplo: dolor, sentimiento, imágenes. • 2.- Objeto ideales no son perceptibles. • 2.1 Relaciones o asociaciones entre objetos • 2.2 Pensamientos • 2.3 Matemáticos, lógicos semiótico
  • • Clasificación: • El proceso de clasificación es el enfoque central de la orientación por objeto y concierne a la agrupación de objetos con propiedades (estructuras de datos o atributos) y comportamiento (operaciones) similares dentro de una clase. • Una clase es la abstracción que describe propiedades importantes para una aplicación. • Cada clase describe una posibilidad infinita de un conjunto individual de objetos. Cada objeto que pertenezca a una clase es llamado instancia de la clase. • La instanciación es lo inverso a la clasificación y concierne a la generación de los distintos objetos de una clase. La distinción entre una clase y sus instancias es similar a la distinción entre una definición de tipo y la declaración de una variable en un lenguaje de programación convencional. Sin embargo, la mayoría de los sistemas orientados por objeto crean dinámicamente instancias por envío de mensajes "Nuevo" y "Crear" una clase.
  • Modelan la vista estática del sistema Elementos básicos: Clases Relaciones Objeto: Representación de una entidad discreta (real o abstracta) - Estado: Definido por valores de propiedades y relaciones - Comportamiento: Operaciones que puede realizar el objeto - Identidad: Unicidad independientemente de su estado Clase: Conjunto de objetos con las mismas propiedades, operaciones, relaciones y semántica Relaciones - Asociación: Conexión bidireccional entre clases - Agregación: Relación especial. Relación Todo-Parte - Herencia: Relación entre superclases y subclases Multiplicidad: Número de objetos con el que se puede combinar un obj. Atributos asociación: Propiedad de una asociación Clases asociación: Asociaciones convertidas a clases Diagramas de clases Asociación Generalización Agregación Nombre Clase atributo operacion
  • Notación para representar una clase. Una clase se representa por una caja la cual puede tener 3 regiones. • La primera región contiene el nombre de la clase. • La segunda región contiene la lista de atributos, cada nombre de atributo puede estar seguido por detalles opcionales tales como tipo de atributo y valores por defectos. • La tercera región contiene los nombres de las operaciones. Cada nombre de operación puede ser seguido por detalles opcionales tales como listas de argumentos y tipos de resultados. Los atributos y operaciones puede o no mostrarse; esto depende del nivel de detalle deseado. Aplicando abstracción Objetos polígonos Clase polígono Atributos Vértices Color del borde Color de relleno Operaciones Dibujar Borrar Mover
  • • Polimorfismo Polimorfismo significa que la misma operación puede comportarse diferentemente sobre distintas clases. Por ejemplo, la operación "mover" ejemplo puede comportarse diferentemente sobre una clase llamada Ventana y una clase llamada Piezas_ajedrez. Universal Ad Hoc Paramétrico Inclusión Overloading Coerción Polimorfismo Clasificación de Polimorfismo
  • • Herencia • La herencia consiste en el compartir atributos y métodos entre clases basándose en una relación jerárquica. • Una clase puede definirse ampliamente y redefinirse sucesivamente en subclases más refinadas. • Cada subclase que se incorpora, hereda todas las propiedades de su superclase y adiciona sus propias y únicas propiedades.
  • Conceptos básicos de la OxO • Tipos de Herencia: Simple y Múltiple. • Simple. Nombre Persona Empleado Estudiante Secretaría Director Año de experiencia Idiomas Dependencia Cargo Denominación Carrera Edad Dirección Sexo Profesión Dependencia
  • Vehículos Vehículos Terrestres Vehículos Acuáticos Carros Vehículos Anfibios Bote • Herencia Múltiple: Una clase puede heredar rasgos de más de una superclase. Una clase con más de una superclase es llamada clase junta. Un rasgo de una clase ancestro que se encuentra más de una vez a lo largo de una ruta solo se hereda una vez.
  • Qué es UML? • UML es un Lenguaje de Modelado Unificado basado en una notación gráfica la cual permite: especificar, construir, visualizar y documentar los objetos de un sistema programado. • Este lenguaje es el resultado de la unificación de los métodos de modelado orientados a objetos de Booch, Rumbaugh (OMT: Object Modeling Technique) y Jacobson (OOSE: Object- Oriented Sotfware Engineering). PARA VISUALIZAR  Símbolos con semántica bien definida.  UML transciende al lenguaje de programación.  Modelo explícito, que facilita la comunicación.
  • PARA ESPECIFICAR • Especificar es equivalente a construir modelos que cumplan las condiciones de no ambigüedad y completitud. • UML cubre la especificación del análisis, diseño e implementación de un sistema software. PARA CONSTRUIR Modelo UML Ingeniería Directa Ingeniería Inversa CÓDIGO Es posible hacer corresponder con los lenguajes de programación (Java, C#, B.Datos, etc.). PARA DOCUMENTAR cubre la documentación de un sistema: –Requisitos -Arquitectura -Diseño -Código fuente –Planificación -Pruebas -Prototipos -Versiones
  • UML “aglutina” enfoques OO UML Rumbaugh Jacobson Meyer Harel Wirfs-Brock Fusion Embly Gamma et. al. Shlaer-Mellor Odell Booch Pre- and Post-conditions State Charts Responsabilities Operation descriptions, message numbering Singleton classes Frameworks, patterns, notes Object life cycles Nov ‘97 UML aprobado por el OMG 1998 1999 2000 UML 1.2 UML 1.3 UML 1.4 2001 UML 2.0 Revisiones menores Historia de UML
  • Modelos y Diagramas  Un proceso de desarrollo de software debe ofrecer un conjunto de modelos que permitan expresar el producto desde cada una de las perspectivas de interés  El código fuente del sistema es el modelo más detallado del sistema (y además es ejecutable). Sin embargo, se requieren otros modelos ...  Cada modelo es completo desde su punto de vista del sistema, sin embargo, existen relaciones de trazabilidad entre los diferentes modelos Modelo: captura una vista de un sistema del mundo real. Es una abstracción de dicho sistema, considerando un cierto propósito. Diagrama: representación gráfica de una colección de elementos de modelado, a menudo dibujada como un grafo con vértices conectados por arcos.
  • Vista de Diseño Vista de Procesos Vista de Despliegue Vista de Implementación Vista de los Casos de Uso Organización de Modelos
  • Diagramas de UML Use Case Diagrams Use Case Diagrams Diagramas de Casos de Uso Scenario Diagrams Scenario Diagrams Diagramas de Colaboración State Diagrams State Diagrams Diagramas de Componentes Component DiagramsComponent DiagramsDiagramas de Distribución State Diagrams State Diagrams Diagramas de Objetos Scenario Diagrams Scenario Diagrams Diagramas de Estados Use Case Diagrams Use Case Diagrams Diagramas de Secuencia State Diagrams State Diagrams Diagramas de Clases Diagramas de Actividad Modelo
  • Relación Vistas - Diagramas Vista de casos de uso Diagramas de casos de uso Diagramas de actividades Vista de diseño Diagramas de clases Diagramas de interacción Diagramas de estados Vista de procesos Diagramas de clase Diagramas de interacción Vista de implementación Diagramas de componentes Vista de despliegue Diagrama de despliegue
  • Casos de Usos • Un diagrama de Casos de Uso muestra la distintas operaciones que se esperan de una aplicación o sistema y cómo se relaciona con su entorno (usuario u otras aplicaciones). • Es una herramienta esencial para la captura de requerimientos y para la planificación y control de un proyecto interactivo. Elementos básicos: Actores Casos de uso Relaciones Actores Modelan diferentes papeles que pueden representar los usuarios o sistemas que interactúan con el sistema a desarrollar Casos de uso Representan todo lo que el usuario puede realizar con el sistema Relaciones Permiten asociar los elementos anteriores
  • Casos de Usos
  • Casos de Usos -Actor: Es un usuario del sistema, que necesita o usa alguno de los casos de uso. Un usuario puede jugar más de un rol. Un solo actor puede actuar en muchos casos de uso; recíprocamente, un caso de uso puede tener varios actores. Los actores no necesitan ser humanos pueden ser sistemas externos que necesitan alguna información del sistema actual. - Casos de uso: Secuencia de transacciones que se realizan en un diálogo determinado entre un actor y el sistema. El conjunto de todos los casos de uso relacionados con el sistema especifica todas las formas de utilización del sistema Incluyen: Descripción de la secuencia básica (comportamiento normal) Secuencias alternativas = Variantes Sec. básica (p.e. errores) Herramientas, Diagramas de interacción (Diagramas de colaboración, de secuencia)
  • Casos de Usos -Relaciones: -Comunica (comunicates) Entre un actor y un caso de uso, denota la participación del actor en el caso de uso determinado. -Usa (uses): Relación entre dos casos de uso, denota la inclusión del comportamiento de un escenario en otro. Se utiliza cuando se repite un caso de uso en dos o más casos de uso separados. Frecuentemente no hay actor asociado con el caso de uso común. -Extiende (extends): Relación entre dos casos, denota cuando un caso de uso es una especialización de otro. Se usa cuando se describe una variación sobre el normal comportamiento. Tipos de relaciones: Generalización entre actores Generalización entre casos de uso Relación de asociación entre actores y casos de uso Relación de extensión Relación de inclusión Identifican la comunicación entre actores, casos de uso y actores con casos de uso.
  • Relación de extensión: Factoriza un caso de uso en nuevos casos de uso que extienden o amplían su comportamiento A B extend A extiende a B A puede conllevar B Relación de inclusión: Expresa que un caso de uso incluye comportamiento de otros casos de uso como parte de su propio comportamiento A B include A usa a B A siempre ejecuta B Generalización entre actores: Organización de actores mediante descripciones abstractas compartidas por otras descripciones de actores más específicos Generalización entre casos de uso: Casos de uso más específicos heredarían la descripción de casos de uso más genéricos, añadiendo una descripción complementaria Relación de asociación entre actores y casos de uso: Comunicación existente entre ambos
  • Uso de cajero automático: 1) para retiro - dinero disponible en cuenta no autorización de cantidad autorización de cantidad - dinero insuficiente - no hay dinero 2) para consulta 3) para deposito 4) para transferencia entre cuentas
  • Ejemplo: Uso de cajero automático TRANSFERENCIA CONSULTA DEPOSITO RETIRO dispara/ inicia retiro disponible c/ autorizacion n o hay dineroretiro disponible s/ autorizacion dinero insuficiente dispara/inicia Cliente
  • Ejemplo: Uso de cajero automático retiro disponible c/ autorizaciretiro disponible c/ autorizacióónn identificacion validacion clave acceso cuentas operacion validacion montoautorizacion entrega dinero < usa > < usa > < extiende >< usa > < usa > < usa > < extiende > < extiende > clientecliente Gestion < usa > < usa > < dispara >
  • Diagrama de casos de uso Realizar llamada telefónica Recibir llamada telefónica Usar Agenda Realizar llamada de conferencia Recibir llamada adicional Teléfono móvil «extend» «extend» Usuario Red telefónica
  • Coordinador Modificar <<Inicia>> Buscar B.D Modificar B.D Mensaje Error Cambiar Contraseña <<Extiende>> <<Usa>> <<Extiende>> <<Extiende>> Caso de Uso: Modificar – SIE. Actores: Coordinador . Propósito: Poder realizar una modificación en SIE. Resumen: El Coordinador desea realizar una Modificación, en el sistema la única modificación es el cambio de contraseña, se realiza mediante la colocación de la contraseña anterior. Acción de los Actores Respuesta del Sistema 1.- El Coordinador pide una Modificación al sistema, (Véase la sección Cambiar Contraseña). 3.- El Coordinador Ingresa la contraseña vieja y la contraseña nueva. 2.- Pide Ingresar la contraseña vieja y la contraseña nueva. 4.- Verifica la contraseña vieja y sí la nueva esta escrita bien. 5.- Actualiza la base de datos.
  • Caso de uso: actualiza cuentas del sistema de contabilidad.
  • CASO DE USO REALIZAR FACTURA. -El usuario solicita la creación de la nueva factura. -El sistema solicita el pedido de la venta. -El usuario proporciona los datos para identificar el pedido - El sistema muestra los datos del pedido - El usuario actualiza los datos de productos y cantidades -El sistema pregunta por el tipo de pago. -El usuario introduce el tipo de pago. -El sistema solicita la confirmación de los datos. -El usuario confirma. -El sistema registra la factura e imprime una copia de esta.