Uml diagramas-caso-de-uso
-
Upload
johanna-gavilanez -
Category
Education
-
view
647 -
download
2
Transcript of Uml diagramas-caso-de-uso
• ¿ 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:ClasesRelaciones
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ónClases 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
• PolimorfismoPolimorfismo 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ónCarrera
Edad Dirección Sexo
Profesión
Dependencia
Vehículos
Vehículos Terrestres Vehículos Acuáticos
CarrosVehí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
ModeloUML
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-BrockFusion
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
19981999
2000
UML 1.2
UML 1.3
UML 1.42001 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 CaseDiagramsUse Case
DiagramsDiagramas de Casos de Uso
ScenarioDiagramsScenario
DiagramsDiagramas deColaboración
StateDiagramsState
DiagramsDiagramas deComponentes
ComponentDiagramsComponent
DiagramsDiagramas deDistribución
StateDiagramsState
DiagramsDiagramas de Objetos
ScenarioDiagramsScenario
DiagramsDiagramas deEstados
Use CaseDiagramsUse Case
DiagramsDiagramas deSecuencia
StateDiagramsState
DiagramsDiagramas deClases
Diagramas deActividad
Modelo
Relación Vistas - Diagramas
Vista de casos de uso Diagramas de casos de usoDiagramas de actividades
Vista de diseño Diagramas de clasesDiagramas de interacciónDiagramas de estados
Vista de procesos Diagramas de claseDiagramas 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:ActoresCasos de usoRelaciones
ActoresModelan diferentes papeles que pueden representar los usuarios
o sistemas que interactúan con el sistema a desarrollar
Casos de usoRepresentan todo lo que el usuario puede realizar con el sistema
RelacionesPermiten 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 actoresGeneralización entre casos de usoRelación de asociación entre actores y casos de usoRelación de extensiónRelació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 Bextend 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 Binclude 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 cuentano autorización de cantidadautorización de cantidad
- dinero insuficiente- no hay dinero
2) para consulta3) para deposito4) 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
claveacceso cuentas
operacion
validacion montoautorizacion
entrega dinero
< usa >
< usa >
< extiende >< usa >
< usa >
< usa >
< extiende >
< extiende >
clienteclienteGestion
< 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
CoordinadorModificar
<<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 USOREALIZAR 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.