Caminos estático, dinámico y funcional del método OMT … · Web viewLa bibliotecaria revisa el carné y anota sus datos en una ficha de préstamo que posee cada material. Los

APUNTE : N-5ASIGNATURA : SISTEMA DE INFORMACIÓNCARRERA : Ingeniería en InformáticaPROFESORA : Magdalena Nieto.

http://www.unab.edu.co/editorialunab/revistas/rcc/pdfs/r11_art4_c.pdf

La metodología OMT (Object Modeling Technique) fue creada por James Rumbaugh y Michael Blaha en 1991, es una de las metodologías de análisis y diseño orientados a objetos, más maduros y eficientes que existen en la actualidad. La gran virtud que aporta esta metodología es su carácter de abierta (no propietaria), que le permite ser de dominio público y, en consecuencia, sobrevivir con enorme vitalidad. Esto facilita su evolución para acoplarse a todas las necesidades actuales y futuras de la ingeniería de software.

Jaaksi junto a otros desarrolla OMT++, un modelo basado en OMT (creado por Rumbaugh, que significa Object Modeling Technique), y estaba dirigido a la construcción de sistemas interactivos. El modelo trabaja con casos de uso, interfaz de usuario y se basan en modelamiento MVC (Model View Control).

Fases del proceso de desarrollo orientado a

I FASE : Conceptualización II FASE : Análisis OO III FASE : Diseño OO IV FASE : Construcción V FASE : Pruebas

http://es.wikipedia.org/w/index.php?title=Michael_Blaha&action=edit&redlink=1

http://es.wikipedia.org/wiki/James_Rumbaugh

CONCEPTUALIZACION ANALISISObjetivo Objetivo

Establecer los requeri- Comprender el dominiomientos básicos para del problema y el sistema

el sistema a ser implementadoActividades Actividades

Enunciar el problema Casos de uso Analísis de objeto Mod. de objeto del análisisProblema Rrequerim.funcionales Requerimientos Análisis de comportamiento Especif. de operaciones

Requerim.no funcionales Especificación de interfaz Diagramas de diálogosEstudio de factibilidad Diag. de componentes

DISEÑO Construcción PruebasObjetivo Objetivo Objetivo

Crear una arquitectura Traducir el diseño en Probar el para la aplicación una implementación Sistema

Actividades Actividades ActividadesModelo de objeto de diseñoMod. de objeto del diseño Definiciones de clases

Diseño orientado a objetoModelo de tres capas Creación de objetos Sist. implementado Integración Sistema Traza de eventos Diagramas de secuencia Llamada de operaciones Prueba como Sistema

Uso de la herenciaImplem. de asociasiones

1

...

Caso de uso A

Caso de uso B

Caso de uso C

Otros requerim.

Análisis

Xatributoatributo

Yatributo

Lista de operaci

Requerimien

AnálisisDiagrama de clase

Lista de operaciones

Operación 1

Operación 2

Operación 3

....

XAtributoAtributo

Función Función 6

YAtributoAtributo

Función 1Función 2

ZAtributo

Función 3Función 4

DiseñoDiagrama de clase

Trazas

Usuario Vista Contr Modelo

Función 1.1Función 1.2

Función 1.3

Función 1.4Función 1.5

Función 1.6

Class Y{ Function3(); Function5();X;};

Declarac

Y::function5(){X->function6();};

...

Código

...

Caso de uso A

Caso de uso B

Caso de uso C

Otros requerim.

Prueba de casos

CONCEPT ANALISIS DISEÑO CONSTRUCCION

2

Def. RequerimientosFuncionales

Def. Requerimientos NoFuncionales

Problema

Entrevistas

Casos de uso Parámetros

Modelo de Objetos

Lista de Operaciones

Análisis de Objetos

Análisis de Comportamiento

Especificación de Interfaz de Usuario

Diagrama de Diálogos Diagramas de Componentes

Enunciar problema

Modelo de Objetos

Modelo de Objetos

Modelo de 3 Capas

Diseño de Objetos

Traza de Eventos

Diagramas de Secuencia

CreaciónDe

Objetos

Definición de Clases

LlamadasDe

Operación

Uso de Herencia

Implementar

Asociación

Probar el Sistema

Sistema en Funcionamiento

CONCEPTUALIZACION

ANALISIS OO

DISEÑO OO

CONSTRUCCION OO

3

CASOS DE USO

10 consideraciones para obtener buenos casos de uso (Según los autores de OMT++)

1. Los casos de uso especifican los requisitos funcionales más importantes

Por ejemplo, si es importante para el cliente que el sistema imprima informes, entonces esa tarea debiera estar incluida en uno o más casos de uso.

2. Un caso de uso describe algo que el diseñador estaría orgulloso de hacer y que el cliente estaría dispuesto a pagar con gusto

Cada caso de uso debiera describir algo que es beneficioso para el usuario. Por ejemplo, “producir un informe de venta” suena como un buen caso de uso, mientras “seleccionar una impresora” es un caso de uso demasiado pequeño y no sólo es beneficioso para el usuario final.

3. Un caso de uso describe una manera típica de usar el sistema, pero no más.

El caso de uso debiera describir la manera recomendada para ejecutar una tarea. No debería cubrir temas que quedan fuera de su incumbencia y no debería tratar de definir todas las posibles formas de ejecutar la tarea. Otra manera de usar el sistema es descrito en otro caso de uso o en la sección de “Excepción” del caso de uso en cuestión.

4

4. Un caso de uso es una actuación

Un caso de uso es como el manuscrito de una obra de teatro que describe lo que debe hacer un actor en un escenario dado. El que tome el lugar de un actor debe ser capaz de jugar su rol. El sistema juega el rol de otro actor. El caso de uso no debe dar demasiada libertad a los actores como para que el acto termine en un caos.

5. Un caso de uso tiene un comienzo, un cuerpo principal, y un final.

Cada caso de uso debiera ser una historia completa. El comienzo de la historia define las precondiciones y entrega una lista de los pasos iniciales del caso de uso. El cuerpo principal describe la funcionalidad que el cliente pagaría con agrado. La parte final describe pasos con los cuales se termina la historia. Un caso de uso sin estas características es probablemente demasiado débil.

6. Un caso de uso es como un ensayo escrito por un estudiante de escuela básica.

A cierta edad los niños tienden a escribir historias que describen el flujo explícito de las acciones, una después de la otra, eso es exactamente lo que un caso de uso debería hacer. Ejemplo: “Hoy fui con mis compañeros a jugar fútbol a Puente Alto. En el primer tiempo yo marqué un gol. En el segundo tiempo Humberto causó un penal y nos marcaron un gol. Luego del gol Raúl marcó otro gol. Finalmente nosotros ganamos 2-1. Después del partido nos vinimos a Santiago en micro.”

7. Un caso de uso cabe en una página

Los casos de uso grandes son difíciles de comprender ya que, o son demasiado detallados, o intentan cubrir demasiada funcionalidad. En el último caso el problema se puede resolver quebrando el caso de uso en dos o más casos de uso.

8. Un caso de uso es fuerte y claro

Cada caso de uso debe hacer afirmaciones claras y explícitas para que cuando la gente lo lea, se pueda formar opiniones fuertes. Un caso de uso

5

debe motivar a los clientes a mejorar el sistema argumentando, discutiendo, hasta lograr un acuerdo con el caso de uso. Si nadie está en desacuerdo con la primera versión de un caso probablemente es demasiado vago o debería ser más explícito.

9. Los clientes y diseñadores de software pueden firmar el caso de uso

Cada caso de uso debería ser concreto y claro para que los clientes y los diseñadores lo puedan firmar. Los casos de uso actúan como un contrato entre los clientes y los desarrolladores. Nadie debería hacer alguna modificación a los casos de uso sin la aprobación de todos.

10. Un caso de uso puede ser usado en el desarrollo y la prueba del sistema

Los casos de uso no se usan en forma aislada. Los casos de uso deberían especificarse para ser usados en las siguientes fases del proceso, por ejemplo, en la fase de análisis de objetos y la fase de análisis de comportamiento. Si los casos son suficientemente explícitos ellos se pueden usar como una base para los casos de prueba del sistema.

6

OMT++ OBJECT MODELING TECHNIQUE

I FASECONCEPTUALIZACION O

CAPTURA DE REQUERIMIENTOS

OBJETIVO DE LA FASE CONCEPTUALIZACION: Establecer los requisitos esenciales para el sistema

Los requerimientos son una descripción de las necesidades o deseos de un producto. La meta primaria de ésta fase es identificar y documentar lo que en realidad se necesita, en una forma que claramente se lo comunique al cliente y a los miembros del equipo de desarrollo

ACTIVIDADES DE LA CONCEPTUALIZACIONSe recomiendan los siguientes artefactos en la fase de requerimientos:1.1) Enunciar el problema1.2) Requerimientos funcionales: Casos de uso1.3) Requerimientos no funcionales

El objetivo de esta fase es comunicarse con el usuario final y documentar los requerimientos. Los requerimientos son discutidos con el cliente. Si es posible, debería participar en la escritura de esos casos. De todas maneras los casos de uso debieran ser escritos de tal forma que el cliente pudiera entenderlos y hacerles comentarios. En las etapas posteriores todo debe ser revisado contra los casos de uso y los requerimientos no funcionales. Finalmente los casos de uso forman el conjunto básico de pruebas a que se somete la aplicación resultante [Jaaksi98a].

7

1.1) ENUNCIADO DEL PROBLEMA.

Actualmente la biblioteca del Departamento de Ingeniería Informática de la Universidad de Santiago atiende a tres tipos de usuarios distintos: alumnos de pre grado (ingeniería civil y de ejecución en informática), memoristas (alumnos terminales de las carreras ya mencionadas) y de post grado (magister en ingeniería en informática). Estos usuarios solicitan y devuelven los libros, apuntes, revistas, folletos, diarios, memorias y otros materiales en una ventanilla de atención única. Para pedir el material en préstamo el usuario debe presentar un carné que lo que acredite como alumno activo. La bibliotecaria revisa el carné y anota sus datos en una ficha de préstamo que posee cada material. Los periodos máximos de préstamo de material difiere, dependiendo del tipo de usuario.

Se desea un sistema para apoyar el préstamo de este material que incluye además manuales de software, revistas de investigación y libros técnicos del área informática. La idea es apoyar los préstamos de una manera automatizada, la cual permitirá ingresar datos de préstamo, registrar devoluciones, renovar préstamos, reservar, etc. También es necesario proveer facilidades de administración del sistema para modificar parámetros, por ejemplo períodos máximos de préstamo por tipo de usuarios de la biblioteca, etc. También interesa producir información resumida (estadísticas) de morosos, material prestado, cuánto material tiene un usuario determinado, cuántas veces se ha pedido un material específico, etc. El usuario final de este sistema será la Bibliotecaria.

8

1.2) REQUERIMIENTOS FUNCIONALES: CASOS DE USO

Los casos de uso se han transformado en una de las herramientas más aceptadas de la comunidad orientada al objeto. Ivar Jacobson los ha definido de la siguiente forma: “cuando un usuario utiliza el sistema, ella o él deberá ejecutar una secuencia relacionada de transacciones mediante un diálogo con el sistema. Esa secuencia especial es llamada caso de uso” [Jaaksi98b].

Un caso de uso describe una función que el sistema debe permitirle al actor realizar.

Un caso de uso puede iniciar a otro caso de uso.

Actor : Un actor es cualquier entidad que interactúa con el sistema, por ejemplo : un usuario, otro sistema.

Caso de uso : Es una operación/tarea específica que se realiza tras una orden de algún agente externo, sea desde una petición de un actor o bien desde la invocación desde otro caso de uso.

Relación Actor – Caso de uso : Es el tipo de relación más básica que indica la invocación desde un actor hacia un caso de uso. Dicha relación se denota con una flecha simple.

Relación entre casos de uso : es una relación o vínculo que indica la llamada desde un caso de uso a otro. Podemos agregar también que estas relaciones pueden ser de distintos tipos, entre ellas, las siguientes :

``usa'' ( <<uses>>) Relación de dependencia entre dos casos de uso que denota la inclusión del comportamiento de un escenario en otro.

``extiende'' (<< extends>>): Relación de dependencia entre dos casos de uso que denota que un caso de .uso es una especialización de otro.

9

10

MODELOS DE CASOS DE USOSDIAGRAMA DE CASOS DE USOS

Un diagrama de casos de uso (Use Case Diagram) es una representación gráfica de parte o el total de los actores y casos de uso del sistema, incluyendo sus interacciones.

Un actor es una entidad que utiliza alguno de los casos de uso del sistema. Se representa mediante el símbolo de la figura 2.1 acompañado de un nombre significativo, si es necesario.

En el ejemplo observamos un único actor representando a la bibliotecaria, aunque en un modelo de casos de uso más detallado se podría incluir otro actor para responsable del mantenimiento del material de biblioteca.

Figura 2.1: Actor

11

http://tvdi.det.uvigo.es/~avilas/UML/node25.html#fig:stickman

Relaciones de Casos de Uso

Las tres relaciones principales entre los casos de uso son soportadas por el estándar UML, el cual describe notación gráfica para esas relaciones.

1. Inclusión (Include) o (use)2. Extensión (Extend)3. Generalización

1) Inclusión (Include) o (use)

Es una forma de interacción, un caso de uso dado puede "incluir" otro. El primer caso de uso a menudo depende del resultado del caso de uso incluido.

Bibliotecaria

Regla de negocio: Previo a otorgar el préstamo debe verificar su disponibilidad

Un incluye es como una llamada a un procedimiento

Una relación «include» entre dos Casos de Uso indica que el comportamiento definido en el Caso de Uso a adicionar, es incluido en un lugar dentro de la secuencia del comportamiento realizado por una instancia del Caso de Uso base. Cuando una instancia del Caso de Uso «llega al lugar» donde el comportamiento de otro Caso de Uso debe ser incluido, ejecuta todo el comportamiento descrito por el Caso de Uso incluido y luego continúa de acuerdo a su Caso de Uso original. El Caso de Uso incluido no depende del Caso de Uso base. En este sentido, el Caso de Uso incluido representa comportamiento encapsulado que puede ser rehusado en varios Casos de Uso.

Prestar material

Verificar disponibilida

d

<<incluye>>DEBE

12

2) Extensión (Extend)

La relación «extensión» establece que un Caso de Uso puede ser extendido con algún comportamiento adicional definido en otro Caso de Uso. La relación contiene una condición y referencia una secuencia de puntos de extensión en el Caso de Uso base. Una vez que la condición es evaluada, si se cumple, la secuencia de la instancia se extiende para incluir la secuencia del Caso de Uso extensión.

La notación es una flecha rayada desde el caso de uso extensión al caso de uso extendido, con la etiqueta «extensión». Esto puede ser útil para lidiar con casos especiales, o para acomodar nuevos requisitos durante el mantenimiento del sistema y su extensión. La relación extensión es complementaria, generalmente se asocia a una condición

Bibliotecaria

Regla de negocio: En el caso de uso “Verificar disponibilidad” si no está disponible el material (condición), entonces se extiende el caso de uso “Proponer alternativo”.

Prestar material


d

<<incluye>> DEBE

Proponer alternativo

<<extensión>>PUEDE

13

3) Generalización/especialización

Un caso de uso dado puede estar en una forma especializada de un caso de uso existente. La notación es una línea sólida terminada en un triángulo dibujado desde el caso de uso especializado al caso de uso general.

Una relación de generalización entre Casos de Uso implica que el Caso de Uso hijo hereda todos los atributos, secuencias de comportamiento, puntos de extensión y relaciones definidos en el Caso de Uso padre. El Caso de Uso hijo puede definir nuevas operaciones, como también redefinir o enriquecer con nuevas secuencias de acciones operaciones ya existentes en el Caso de Uso padre. Para distinguir si la especialización está redefiniendo una operación del padre o agregándole secuencias de acciones, sugerimos la inclusión de un estereotipo (elemento de UML) <<redefine>> para el primer caso o <<enriquece>> para el segundo, en la operación en cuestión.

Bibliotecaria

Alumno

Regla de negocio: Los préstamos que se realizan a través de intranet, debe ser redefinido, pues requieren de agregar otros requisitos para hacer efectivo el préstamo por intranet

Prestar material


d

<<incluye>>DEBE


<<extensión>>PUEDE

Prestar On-lineMaterial

Caso de uso especializado

<<redefine>>

14

<<incluye>> <<extiende>> <<redefine>> / <<enriquece>>

Un caso de uso dado debe "incluir" otro

Un Caso de Uso puede ser “extendido” con algún comportamiento adicional definido en otro Caso de Uso

Un Caso de Uso hijo hereda todos los atributos, secuencias de comportamiento del padre.

utilizaremos una relación tipo << uses>> cuando nos encontramos con una parte de comportamiento similar en dos casos de uso y no queremos repetir la descripción de dicho comportamiento común.

Se utiliza una relación de tipo <<extends>> entre casos de uso cuando nos encontramos con un caso de uso similar a otro pero que hace algo más que éste (variante), ello depende de una condición

El Caso de Uso hijo puede definir nuevas operaciones <<redefine>>, como también redefinir o enriquecer <<enriquece>> con nuevas secuencias de acciones

Mientras, en una relación <<include>> el actor que realiza el caso de uso base también debe realizar el caso de uso incluido.

En una relación << extends>>, un actor que lleve a cabo el caso de uso base puede realizar o no sus extensiones.

y <<include>> cuando se repite un comportamiento en dos casos de uso y queremos evitar dicha repetición.

En general utilizaremos <<extends>> cuando se presenta una variación del comportamiento normal

Bibliotecaria

Estudiante

Prestar material


d

<<incluye>>


<<extensión>>

Prestar On-line Material

<<redefine>>

15

MODELOS DE CASOS DE USOSLlamamos modelo de casos de uso a la combinación de casos de uso y sus correspondientes diagramas. Los modelos de casos de uso se suelen acompañar por un glosario que describe la terminología utilizada. El glosario y el modelo de casos de uso son importantes puntos de partida para el desarrollo de los diagramas de clases.

A) DIAGRAMA PRINCIPAL O GENERAL DE CASOS DE USOSTodo sistema tiene como mínimo un diagrama Main Use Case, que es una representación gráfica del entorno del sistema (actores) y su funcionalidad principal (casos de uso).

Prestar material

Reservarmaterial

Devolver material

ConsultarMaterial

Emitir informes

Emitir estadístic

a

Eliminar material

Validar alumno

Ver dispo-nibilidad


Emitir morosos

Agregar material

Modificar material

Mantener material

<incluye>

<incluye>

<incluye>

<incluye>

<incluye>

<extensión>

<incluye>

<incluye><incluye>

<incluye>

<incluye>

<incluye>

<incluye>

<incluye>

16

Biblio- Adminis-

tecaria trador

Fig. 2.2 Diagrama principal de casos de usob) CASO DE USO DE GENERALIZACIÓN Y HERENCIAEstereotipo= compartir

Bibliotecaria

Usuario

Administrador

Diagrama de casos de uso para autentificación de usuario,( Las relaciones de los actores con el actor usuario son herencia o

generalización.)

Esta generalización se ha efectuado pues existen algunos casos de uso en los que, tanto el Alumno como el Profesor comparten acciones similares, de esta forma, la generalización y herencia permiten establecer un usuario en común “Alumno/Usuario” que llevará a cabo las funciones en común del Alumno y el Profesor en los casos de uso que así lo necesiten.

Autentificar usuario

Autenticar usuario

<incluye>

17

Además, éste es un caso de uso de estereotipo (actores que comparten un mismo caso de uso), dado que los actores son dos: Bibliotecaria y Administrador, cada uno de ellos accede al caso de uso de autentificación de usuario, para no especificar en todos los diagramas que los usuarios son autentificados hacemos este tipo de referencia concluyendo que cada uno de ellos es autentificado en el sistema por el caso de uso.

18

c) CASO DE USO PATRÓN

Administrador

Diagrama de casos de uso para mantener tablas.

A través de éste modelo de casos de uso se representan a todos aquellos casos de uso que mantienen a tablas, evitando así diagramar separadamente uno por cada tabla a mantener.

El mantenedor contiene o “incluye” una serie de otros casos de uso orientados a satisfacer las necesidades básicas de una mantención de tablas, entre ellas encontramos las funciones mas comunes como : agregar, modificar, eliminar y las opciones de navegación de registro (ir a registro siguiente, anterior, primero o último ).

Este patrón de casos de uso esta orientado principalmente a las tareas de Administración de sistema y se aplica a todas aquellas tablas que requieren de una gestión manual y no son modificables por usuarios comunes.

Mantenedor de Tablas

Navegar la Tablas

Agregar en Tablas

Modificar en Tablas

Eliminar en Tablas

<incluye>

<incluye>

<incluye>

<incluye>

19

d) CASOS DE USO PARA ACTOR BIBLIOTECARIA

d) CASOS DE USO PARA ACTOR ADMINISTRADOR

Prestar material

Reservarmaterial

Devolver material

ConsultarMaterial

Emitir informes

Emitir estadística

Autenticar usuario

Validar alumno

Ver disponibilida

d


Emitir morosos

<incluye>

<incluye>

<incluye>

<incluye>

<incluye><extensión>

<incluye>

<incluye>

Bibliotecaria

Modificar material

Autenticar usuario

Agregar material

Mantener material

<incluye>

<incluye>

<incluye>Eliminar material

20

Administrador

OBSERVACIÓN: Todos los diagramas presentados son a modo de ejemplo de representar la diversidad de diagramas, sin embargo el caso de Biblioteca que estamos revisando considerar que tiene sólo un usuario, que es la bibliotecaria

21

CASOS DE USO PARA ACTOR BIBLIOTECARIA para el ejemplo

Prestar material

Reservarmaterial

Devolver material

ConsultarMaterial

Autenticar usuario

Validar alumno

Emitir Estadística

<incluye>

<incluye>

<incluye>

Modificar material

Agregar material

Mantener material

<incluye>

<incluye>

<incluye>

Eliminar material

Bibliotecaria

22

DESCRIPCIÓN EXTENDIDA DE CASOS DE USO PARA EL ALUMNO

A continuación se presentan los casos de uso mediante la estructura propuesta por Jaaksi [Jaaksi98b]. Es importante mencionar que un caso de uso lo inicia un actor, el que es explicitado en el caso de uso.

Primero enlistaremos todos los casos de uso para el sistema

1. Logear usuario (bibliotecaria)2. Validar alumno3. Prestar material.4. Consultar material en sala5. Reservar material.6. Mantener material.7. Devolver material.8. Emitir estadística de préstamos.

Veremos la descripción extendida de los casos de uso, en ella se encuentra la descripción detallada de cada caso de uso utilizado en los diagramas de caso de uso presentados anteriormente, su funcionamiento y los detalles asociados que serán requerimientos para desarrollar la aplicación.

23

CASO DE USO 1: LOGEAR USUARIO

1. Logear usuario. Descripción El caso de uso logear usuario, permite comprobar que la persona

es usuaria del sistema.Actores BibliotecariaPre condiciones No hay Flujo normal o escenario exitosoResponsabilidad del Actor Responsabilidad del Sistema

1. Despliega cuadro de diálogo para logeo activado botones “aceptar” y “salir”

2. Ingresa nombre y contraseña

3. Presiona Aceptar4. Valida que persona sea usuario del sistema 5. Fin del caso de uso (Activa los casos de uso

“Préstamo”, “Consulta” “Reserva”, “Devolución”, “Mantenedor de material” y “Emitir estadística”)

Flujo alternativo 1: Valida que sea usuario del sistema. Si no es usuaria del sistemaResponsabilidad del Actor Responsabilidad del Sistema

2. Acepta el mensaje (botón Aceptar)

1. Despliega mensaje de “No es usuario del sistema de biblioteca” y habilita botón Aceptar

3. Fin flujo alternativo 1

Post condición El usuario queda habilitado para utilizar el sistema de Biblioteca

Logeo de usuario

Ingrese nombre de usuario

Ingrese contraseña

Aceptar Salir

24

CASO DE USO 2: VALIDAR ALUMNO

2. Validar alumno. Descripción El caso de uso validar alumno, permite comprobar que el alumno

se encuentra registrado como usuario de la biblioteca, lo que debe corroborarse antes de realizar una reserva, una consulta en sala o préstamo para la casa

Actores BibliotecariaPre condiciones El usuario (bibliotecaria) debe estar autentificado Flujo normal o escenario exitosoResponsabilidad del Actor Responsabilidad del Sistema

4. Habilita el ingreso del rut del alumno y el botón “buscar” y el botón “salir”

5. Ingresa rut6. Acepta rut (botón

Buscar)

9. Selecciona un caso de uso “Préstamo”, “Consulta” o “Reserva”

6. Valida el ingreso del rut (digitación)7. Valida que alumno sea usuario de biblioteca 8. Despliega datos del alumno y activa los casos

de uso “Préstamo”, “Consulta” y “Reserva” 10. Fin del caso de uso (El sistema deriva al caso de uso seleccionado)

Flujo alternativo 1: Valida el ingreso del rut (digitación). Si rut fue mal ingresadoResponsabilidad del Actor Responsabilidad del Sistema


1. Despliega mensaje de “rut mal ingresado” y habilita botón Aceptar

3. Fin flujo alternativo 1Flujo alternativo 2: Valida que alumno sea usuario de biblioteca. Si no es usuarioResponsabilidad del Actor Responsabilidad del Sistema


2. Despliega mensaje de “alumno no registrado como usuario de biblioteca” y habilita botón Aceptar

5. Fin flujo alternativo 2Post condición

Información Alumno

Datos del Alumno

Préstamo Consulta Reserva Salir

Numero rutBuscar

Nombres

Ap. Paterno Ap. Materno Carrera

Información Atrasos

Menú de Acciones

Préstamo de Material

Consulta de Material

Reserva de Material

Sistema de Biblioteca

25

El usuario es derivado a registrar un préstamo, una consulta o una reserva

26

CASO DE USO 3: PRESTAR MATERIAL

3. Prestar material Descripción El caso de uso solicitar un material en préstamo, permite registrar un

préstamo siempre y cuando las condiciones estén dadasActores BibliotecariaPre condiciones Validación de alumnoFlujo normal o escenario exitosoResponsabilidad del Actor Responsabilidad del Sistema

1. Despliega ventana de préstamo, habilita el ingreso del código del libro del alumno y el botón “buscar” y “salir”

2. Ingresa código del material

3. Acepta (botón Buscar)

9. Asigna el material en préstamo (clic en botón)

4. Valida que exista el material en biblioteca 5. Valida disponibilidad del material6. Verifica que alumno cumpla con las condiciones para

el préstamo7. Busca si el material lo tenía reservado y lo elimina de

la lista de reserva8. Despliega datos del material y alumno, además activa

el botón “Asignar Préstamo”

10. Registra en BD el préstamo11. Fin del caso de uso

Flujo alternativo 1: Valida que exista el material en biblioteca (4). Si no existe Responsabilidad del Actor Responsabilidad del Sistema


1. Despliega mensaje que “no existe el material” y habilita botón Aceptar

3. Fin flujo alternativo 1Flujo alternativo 2: Valida disponibilidad del material(5). Si no está disponibleResponsabilidad del Actor Responsabilidad del Sistema


1. Despliega mensaje de “material no disponible” y habilita botón Aceptar

3. Fin flujo alternativo 2Flujo alternativo 3: Verifica que alumno cumpla condiciones préstamo(6). Si no

1. Despliega mensaje de que alumno no cumple con condiciones y habilita botón Aceptar

2. Acepta el mensaje 3. Fin flujo alternativo 3

Préstamo Material

Datos del Material

Asignar Salir

Código del Material Buscar

Estado

Menú de Acciones

Información Alumno

Mensajes

Titulo Autor

27

Post condición Al usuario le queda registrado un préstamo a su haber

CASO DE USO 4: CONSULTA MATERIAL EN SALA –PRÉSTAMO EN SALA

4.- Consulta en sala Descripción Registra material asignado como préstamo en salaActores BibliotecariaPre condiciones Validación de alumnoFlujo normal o escenario exitosoResponsabilidad del Actor Responsabilidad del Sistema

1. Despliega ventana de préstamo en sala, habilita el ingreso del código del libro y el botón “buscar” y “salir”


3. Acepta código (botón Buscar)

7. Asigna el material en consulta (clic en botón)

4. Valida que exista el material en biblioteca 5. Valida disponibilidad del material6. Despliega datos del material y alumno,

además activa el botón “Asignar Préstamo en sala”

8. Registra en BD el préstamo en sala9. Fin del caso de uso







Consulta de Material

Datos del Material

Asignar Salir


Estado

Menú de Acciones

Información Alumno

Mensajes

Título Autor

28

3. Fin flujo alternativo 2Post condición Al usuario le queda registrado un préstamo de consulta en sala

29

CASO DE USO 5: RESERVA DE MATERIAL

5. Reserva de material Descripción Registra la reserva de un materialActores BibliotecariaPre condiciones Validación de alumnoFlujo normal o escenario exitosoResponsabilidad del Actor Responsabilidad del Sistema

1. Despliega ventana de reserva de material, habilita el ingreso del código del libro y el botón “buscar” y “salir”



4. Asigna el material en reserva (clic en botón)

5. Valida que exista el material en biblioteca

6. Valida disponibilidad del material7. Despliega datos del material y alumno,

además activa el botón “Asignar reserva de material”

8. Registra en BD el préstamo en sala9. Fin del caso de uso








Reserva de Material

Datos del Material

Reservar Salir


Estado Lista

Menú de Acciones

Información Alumno

Mensajes

Título Autor

30

Post condición Al usuario le queda registrado un préstamo a su haber

31

CASO DE USO 6: MANTENEDOR DE MATERIAL

6. Mantenedor de material Descripción Permite mantener actualizada las existencias de materialesActores BibliotecariaPre condiciones Logeo de usuario del sistemaFlujo normal o escenario exitosoResponsabilidad del Actor Responsabilidad del Sistema

1. Despliega ventana de mantención de material, habilita el ingreso del código del libro y el botón “buscar” y “salir”



6. Ingresa datos a modificar

7. Selecciona “Modificar” (clic en Modificar)

9. Selecciona “Eliminar” (clic en botón Eliminar)

4. Valida que exista el material en biblioteca

5. Despliega datos del material y los deja habilitado para posible modificaciones y habilita la posibilidad “guardar Modificaciones” o “Eliminar”

8. Actualiza la BD con la modificación del material

10. Actualiza la BD con la eliminación del material

11. Fin del caso de usoFlujo alternativo 1: Valida que exista el material en biblioteca (4). Si no existe , permite ingresar el material como “nuevo”Responsabilidad del Actor Responsabilidad del Sistema

2. Ingresar datos del nuevo material

3. Acepta el guardar

1. Habilita campos para ingresar datos del nuevo material y habilita botón Guardar “nuevo”

4. Guardar el nuevo material

Mantenedor Material

Datos del Material

Nuevo Salir

Código del Material BuscarAutor

Menú de Acciones

Título

Tipo Detalle

Modificar Eliminar

MensajeSistema de Biblioteca

32

nuevo material (botón Nuevo)


Post condición Las existencias de materiales quedan actualizadas en la BD

33

CASO DE USO 7: DEVOLVER MATERIAL

7. Devolver material Descripción Registra la devolución de un materialActores BibliotecariaPre condiciones Logeo de usuario del sistemaFlujo normal o escenario exitosoResponsabilidad del Actor Responsabilidad del Sistema

1. Despliega ventana devolución de material, habilita el ingreso del código del libro y el botón “buscar” y “salir”



7. Si se requiere ingresa estado del material

8. Selecciona registrar “devolución del material (clic en botón)

9. Valida que exista el préstamo de ese material

10. Despliega datos del material prestado, habilita campo estado y habilita el botón “Devolución de material”

9. Registra en BD la devolución10. Fin del caso de uso

Flujo alternativo 1: Valida que exista el registro de material prestado (4). No existe registro del préstamo del material Responsabilidad del Actor Responsabilidad del Sistema


1. Despliega mensaje que “no existe registro de préstamo para ese material” y habilita botón Aceptar

3. Fin flujo alternativo 1Post condición El material queda disponible para un nuevo préstamo

Devolución de Material

Datos del Material

Devolución Salir


Estado

Menú de Acciones

Información Alumno

Mensajes

Título Autor

34

CASO DE USO 8: EMITIR ESTADISTICA DE PRÉSTAMO EN UN PERIODO

8. Emitir informe estadístico de préstamos Descripción Emitir un estadístico de préstamo dentro de un periodo

determinadoActores BibliotecariaPre condiciones Logeo de usuarioFlujo normal o escenario exitosoResponsabilidad del Actor Responsabilidad del Sistema

1. Despliega ventana de emisión de estadística de préstamos, habilita los campos para seleccionar fecha desde hasta el cual se desea obtener el informe estadístico y habilita “ver” y “salir”

2. Selecciona periodo (desde y hasta)

3. Acepta “ver” informe estadístico (botón ver)

5. Acepta “imprimir” (botón imprimir)

4. Habilita la posibilidad de imprimir la estadística

6. Envía estadística a imprimir7. Fin del caso de uso

Flujo alternativo 1: Valida que exista el registro de material prestado (4). No existe registro del préstamo del material

Post condición No hay

Informes

Datos del Informe

Ver Salir

Fecha Inicio

Menú de Acciones

Período Informe

Texto Informe

Imprimir

Sistema de Biblioteca

35

1.3) REQUERIMIENTOS NO FUNCIONALES

Los atributos del sistema son cualidades no funcionales que a menudo se confunden con las funciones. Por ejemplo: facilidad de uso, tolerancia a fallas, tiempo de respuesta, metáfora de interfaz, plataformas.

Los atributos tienen un posible conjunto de detalles de atributos, los cuales tienden a ser valores discretos, confusos o simbólicos.

Por ejemplo: tiempo de respuesta = (psicológicamente correcto) metáfora de interfaz = (gráfico, colorido, basado en formularios)

Algunos atributos del sistema también pueden tener restricciones de frontera del atributo, que son condiciones obligatorias de frontera, generalmente en un rango numérico de valores de un atributo.

Por ejemplo: tiempo de respuesta = (dos segundos como máximo)

Algunos requerimientos no funcionales (atributos) de un Sistema de punto de venta, podrían ser:

tiempo de respuesta (restricción de frontera) Cuando se registre un producto vendido, la descripción y el precio aparecerán en 1 segundo.

metáfora de interfaz (detalle) Ventanas orientadas a la metáfora de un formulario y cuadros de diálogo.

(detalle) Maximiza una navegación fácil con teclado y no con mouse. tolerancia a fallas (restricción de frontera) Debe registrar los pagos a

crédito autorizados que se hagan a las cuentas por cobrar en un plazo de 24 horas, aun cuando se produzcan fallas de energía o del equipo.

plataformas del sistema operativo (detalle) Microsoft Windows 95, 98, 2000 y NT.

Un caso típico de requerimientos no funcionales son las características del hardware que se requiere. También se puede decir que representan las restricciones del sistema que se está diseñando.

Finalmente, es conveniente describir todos los atributos del sistema que se relacionen claramente con las funciones especificadas.

36

A continuación se presentan los requisitos no funcionales identificados para el Sistema de Biblioteca:

El software debe funcionar en un PC IBM compatible Pentium de 100 Mhz y 2 GB de capacidad en disco duro1.

El alumno debe demostrar su calidad de usuario válido de la biblioteca mostrando un carné entregado por la biblioteca central de la Universidad.

El sistema debe poseer un tiempo de respuesta breve ya que es utilizado en un solo puesto de trabajo.

Se presta máximo tres materiales bibliográficos por alumno.

En caso de producirse retraso en la devolución del material se suspenderá tres días hábiles por cada día de atraso. Si el material es de reserva la suspensión será de una semana.

El sistema no debe permitir el préstamo a domicilio de un libro si queda una sola copia disponible.

Una vez al semestre se actualizarán los datos de los alumnos matriculados en las carreras que imparte el Departamento desde el servidor “Huara” (servidor que mantiene la base de datos corporativa de la Universidad).

Como identificación de usuario de biblioteca válido se pedirá el carné emitido por la biblioteca central o en el caso de los alumnos de primer semestre, el comprobante de matrícula.

El material bibliográfico se identifica por un código CDU (para que sea único se le agrega el número de copia), por un número secuencial generado en la biblioteca del departamento (único) y por un número secuencial (único) que se genera en la biblioteca central (en cuyo caso viene en un código de barra) o en el mismo departamento. Se ha decidido usar el número secuencial único generado en la biblioteca central para identificar el material bibliográfico ya que es más fácil de digitar y permitirá en un futuro tener un lector de código de barra.

1 Son las características del computador personal que posee la biblioteca del Departamento de Ingeniería Informática.37

Documents

Caminos estático, dinámico y funcional del método OMT … · Web viewLa bibliotecaria revisa el carné y anota sus datos en una ficha de préstamo que posee cada material. Los