REGISTRO USUARIO

REGISTRO ADMINISTRADOR

VALIDACIÓN USUARIO

Modificación de Usuario

REFERENCIA CASO DE USO: CASO DE USO – 03
NIVEL	Alto _X_ Medio__ Bajo__
Nombre	Modificación de Usuario
Actor(es)
Descripción	Hacemos referencia a la forma como se cambia los datos de una cuenta de usuario con su respectiva verificación.
Precondiciones	Tener presente la información anterior
Post-condiciones	N/A
Referencia cruzada	N/A
ACCIÓN DE LOS ACTORES	RESPUESTA DEL SISTEMA
1. Ingresar Datos 2. Confirmar Datos 3. Ingresar Nombre de Usuario. 4. Insertar Clave 5. Ingresar al Sistema. 6. Solicitar Cambio 7. Ingresar datos nuevos 8. Confirmar datos	Verificar Datos Guardar Datos Validar los Datos ingresados Ingresar al Sistema Dar paso al Sistema Mostrar Opciones Verificar Nuevos datos Validar datos nuevos.
FALLO POSIBLE	SOLUCIÓN
Errar al ingresar datos antiguos al sistema	Dar opciones de recordatorio.

MODIFICACIÓN USUARIO

PERFIL

NOMBRE:

Diego Dominguez

EXPECTATIVAS:

Terminar mi tecnología teniendo como agregado almenos 2 certificaciones la primera en ORACLE y la segunda en JAVA, las cuales me permitan tener mayor competencia laboral.

Posteriormente aspiro a realizar la ingenieria para obtener mi titulo profesional.

U.M.L.

HISTORIA U.M.L.

UML (Unified Modeling Language) es un lenguaje que permite modelar, construir y documentar los elementos que forman un sistema software orientado a objetos. Se ha convertido en el estándar de facto de la industria, debido a que ha sido concebido por los autores de los tres métodos más usados de orientación a objetos: Grady Booch, Ivar Jacobson y Jim Rumbaugh. Estos autores fueron contratados por la empresa Rational Software Co. para crear una notación unificada en la que basar la construcción de sus herramientas CASE. En el proceso de creación de UML han participado, no obstante, otras empresas de gran peso en la industria como Microsoft, Hewlett-Packard, Oracle o IBM, así como grupos de analistas y desarrolladores.

Esta notación ha sido ampliamente aceptada debido al prestigio de sus creadores y debido a que incorpora las principales ventajas de cada uno de los métodos particulares en los que se basa: Booch, OMT y OOSE. UML ha puesto fin a las llamadas "guerras de métodos" que se han mantenido a lo largo de los 90, en las que los principales métodos sacaban nuevas versiones que incorporaban las técnicas de los demás. Con UML se fusiona la notación de estas técnicas para formar una herramienta compartida entre todos los ingenieros software que trabajan en el desarrollo orientado a objetos.

El objetivo principal cuando se empezó a gestar UML era posibilitar el intercambio de modelos entre las distintas herramientas CASE orientadas a objetos del mercado. Para ello era necesario definir una notación y semántica común. En la figura 2 se puede ver cuál ha sido la evolución de UML hasta la creación de UML 1.1.
Hay que tener en cuenta que el estándar UML no define un proceso de desarrollo específico, tan solo se trata de una notación. En este curso se sigue el proceso propuesto por Craig Larman[Larman99] que se ajusta a un ciclo de vida evolutivo e incremental dirigido por casos de uso.
En la parte II de este texto se expone la notación y semántica de UML, mientras que en la parte III se presenta el proceso de desarrollo orientado a objetos de Larman, que se sirve de los modelos de UML que se han visto anteriormente.

CONCEPTOS

Es un lenguaje de modelado visual que se usa para especificar, visualizar, construir y documentar artefactos de un sistema de software, a la vez UML nos permite la abstracción de un sistema y sus componentes de una manera facil y comprensible.


CASOS DE USO


Un caso de uso es una técnica para la captura de requisitos potenciales de un nuevo sistema o una actualización de software.

En definitiva un caso de uso es una secuencia de interacciones que se desarrollarán entre un sistema y sus actores en respuesta a un evento que inicia un actor principal sobre el propio sistema.


CONCEPTOS C.U.

Cada caso de uso proporciona uno o más escenarios que indican cómo debería interactuar el sistema con el usuario o con otro sistema para conseguir un objetivo específico.

Elementos

Los elementos que pueden aparecer en un Diagrama de Casos de Uso son: Actores, casos de uso y relaciones entre casos de uso.

Actores

Un actor es una entidad externa al sistema que realiza algún tipo de interacción con el mismo. Se representa mediante una figura humana dibujada con palotes. Esta representación sirve tanto para actores que son personas como para otro tipo de actores (otros sistemas, sensores, etc.).

Relaciones entre Casos de Uso

Entre dos casos de uso puede haber las siguientes relaciones:
• Extiende: Cuando un caso de uso especializa a otro extendiendo su funcionalidad.
• Usa: Cuando un caso de uso utiliza a otro.
Se representan como una línea que une a los dos casos de uso relacionados, con una flecha en forma de triángulo y con una etiqueta <> o <> según sea el tipo de relación. En el diagrama de casos de uso se representa también el sistema como una caja rectangular con el nombre en su interior. Los casos de uso están en el interior de la caja del sistema, y los actores fuera, y cada actor está unido a los casos de uso en los que participa mediante una línea. En la figura 15 se muestra un ejemplo de Diagrama de Casos de Uso para un cajero automático.

EJEMPLO:

PREGUNTAS

1. ¿Para qué sirve U.M.L?

• UML se usa para entender, diseñar, configurar, mantener y controlar la información sobre los sistemas a construir.

2. ¿Para qué sirven los casos de uso?

• El diagrama de casos de uso sirve para identificar los elementos y procesos principales que forman un sistema.

3. Ventajas de los C.U.

• Facilidad de comprensión tanto para usuarios como para analistas.
• Identificacióm precisa de los estadios que influyen en el sistema.
• Mayor control sobre las revisiones del sistema.
  
• Comprensión detallada de la funcionalidad del sistema.

4. Desventajas de los C.U.

• La inclusión de relaciones como el Extends o el Include suelen causar que se dificulte la comprensión para el usuario.
• No tener del todo claro el momento en el cual se debe detener la aplicación del mismo.
• No tener definida la cobertura del caso de uso.
• No se puede ejecutar.
  

TEMAS VISTOS

1. Casos de Uso


2. Diagrama de Clases


3. Diagrama de Secuencia