Apunte Omt Actualizado Mayo 20101

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

http://sistemas.itlp.edu.mx/tutoriales/fundamentosdeprog/t21.htmPara enseñar conceptos básicos de OO

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

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

http://sistemas.itlp.edu.mx/tutoriales/fundamentosdeprog/t21.htm

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

CONCEPTUALIZACION ANALISIS

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

el sistema a ser implementado

Actividades ActividadesEnunciar el problema Casos de uso Analísis de objeto Mod. de objeto del análisis

Problema Rrequerim.funcionales Requerimientos Análisis de comportamiento Especif. de operacionesRequerim.no funcionales Especificación de interfaz Diagramas de diálogos

Estudio de factibilidad Diag. de componentes

DISEÑO Construcción Pruebas

Objetivo Objetivo ObjetivoCrear 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 3Función 5

ZAtributo


DiseñoDiagrama de clase

Trazas

Usuario Z X Y


Función 3

Función 4

Función 5

Función 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

FACTIBILIDAD

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 funcionales1.4) Estudio de factibilidad

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

MODELOS DE CASOS DE USOS

DIAGRAMA 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.

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 “Contabilizar rechazos”, seguramente esto permitirá tomar decisión de adquirir o no más copias del material.

Prestar material


d

<<incluye>> DEBE

Contabilizarrechazos

<<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, requieren de requerimientos adicionales al préstamo físico del material

Prestar material


d

<<incluye>>DEBE

Contarrechazos

<<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).

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 realiza 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>>

Contar rechazos

<<extensión>>

Prestar On-line Material

<<redefine>>

15

MODELOS DE CASOS DE USOS

Llamamos 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 USOS

Todo 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ística

Validar alumno

Ver disponibilida

d

Contarrechazos

Emitir morosos

Agregar material

Modificar material

Mantener material

<incluye>

<incluye>

<incluye>

<incluye>

<incluye><extensión>

<incluye>

<incluye>

<incluye>

<incluye>

16

Biblio- Adminis-

tecaria trador

Fig. 2.2 Diagrama principal de casos de uso

b) 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

Eliminar material

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

Contarrechazos

Emitir morosos

<incluye>

<incluye>

<incluye>

<incluye>

<incluye><extensión>

<incluye>

<incluye>

Bibliotecaria

Modificar material

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

Autenticar usuario

21

CASOS DE USO PARA ACTOR BIBLIOTECARIA

Prestar material

Reservarmaterial

Devolver material

ConsultarMaterial

Autenticar usuario

Validar alumno

Emitir Estadística

<incluye>

<incluye>

<incluye>

Bibliotecaria

Modificar material

Agregar material

Mantener material

<incluye>

<incluye>

<incluye>

Eliminar material

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 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

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

2. Ingresa rut3. Acepta rut (botón

Buscar)

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

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

de uso “Préstamo”, “Consulta” y “Reserva” 8. El sistema deriva al caso de uso seleccionado9. Fin del caso de uso

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

2. Acepta el mensaje (botón Aceptar)

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


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

3. 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

24

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

25

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)

10. 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”

11. Registra en BD el préstamo12. 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


3. Fin flujo alternativo 1

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

Flujo 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

Préstamo Material

Datos del Material

Asignar Salir

Código del Material Buscar

Estado

Menú de Acciones

Información Alumno

Mensajes

Titulo Autor

26

(botón Aceptar) 3. Fin flujo alternativo 3Post 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




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

2. Acepta el mensaje 1. Despliega mensaje de “material no

disponible” y habilita botón Aceptar


Datos del Material

Asignar Salir


Estado

Menú de Acciones

Información Alumno

Mensajes

Título Autor

27

(botón Aceptar)3. Fin flujo alternativo 2

Post condición Al usuario le queda registrado un préstamo de consulta en sala

28

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




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


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


Reserva de Material

Datos del Material

Reservar Salir


Estado Lista

Menú de Acciones

Información Alumno

Mensajes

Título Autor

Consulta en Sala

Cod-matTituloAutorEstado

Buscar( )AsignarConsulta( )Salir()

29

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

30

CASO DE USO 6: MANTENEDOR DE MATERIAL

6. Mantenedor de material Descripción Permite mantener actualizada las existencias de materialesActores BibliotecariaPre condiciones Validación de usuario Flujo 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. Acepta el guardar nuevo material (botón Nuevo)

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


Mantenedor Material

Datos del Material

Nuevo Salir

Código del Material BuscarAutor

Menú de Acciones

Título

Tipo Detalle

Modificar Eliminar

Mensaje


31

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

32

CASO DE USO 7: DEVOLVER MATERIAL

7. Devolver material Descripción Registra la devolución de un materialActores BibliotecariaPre condiciones Validación de alumnoFlujo 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

33

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


34

II FASEANALISIS ORIENTADO A OBJETO

INDICE INFORME DE ANÁLISIS ORIENTADO A OBJETOSIntroducciónAnálisis de objetos

Descripción de Casos de UsoIdentificar clases u objetos (Sustantivos)Diagrama de objetos

Análisis de comportamientoDescripción de operaciones por casos de usosLista de operaciones para la aplicación

Especificación de interfazDiagrama de diálogosFunciones que realiza cada ventana de diálogoEspecificación de ComponentesDiseño de la interfaz gráfica utilizando lenguaje

ConclusionesBibliografíaAutoevaluación

OBJETIVO DE LA FASE DE ANALISISEl propósito del análisis es comprender el dominio del problema y el sistema a

ser implementado. La fase de análisis está basada sobre un conjunto de requerimientos y casos de uso, y la fase incluye las siguientes tareas:

Análisis de Objeto Análisis de Comportamiento Especificación de Interfaz del usuario

ACTIVIDADES DEL ANALISISEl análisis de objeto consiste en especificar todos los conceptos claves relacionados al sistema a ser desarrollado. Esto produce un Modelo de Análisis de Objeto, que documenta los conceptos del dominio del problema.

El análisis de comportamiento define las operaciones que el usuario realizará con el sistema. El análisis de comportamiento modela el sistema como una caja negra, o sea, modela sólo la funcionalidad externa del sistema y produce una Lista de Operaciones. El sistema final debe soportar la realización de todas las operaciones incluidas en la lista. Sin embargo, la Lista de Operaciones y el Modelo de Análisis de Objeto son modelos separados, las operaciones incluyen y usan los conceptos definidos por el modelo de objeto. A esta altura del desarrollo. Aún la lista de operaciones no está relacionada como funcionales de las clases de del modelo de objeto. Así el modelo de análisis de objeto incluye pocas operaciones; típicamente, sólo clases y sus atributos.

35

Especificación de la interfaz de usuario es una entidad intermedia entre el usuario final y la aplicación. Ésta debe ser capaz de representar los objetos de la aplicación tal como el usuario comprendió las relaciones entre la representación y el mundo real. A un nivel más alto podemos ver la interfaz gráfica usuaria como una colección de diálogos. Para simplificar el concepto, todos los diálogos y ventanas son llamados diálogos. Cada diálogo posee uno o más componentes. Un componente es una colección de elementos del sistema de ventanas. Cada componente consiste de herramientas, tales como botones y campos de textos. Las herramientas pueden ser herramientas de manipulación que el usuario necesita para controlar la aplicación, o herramientas de feedback que la aplicación necesita para presentar cosas al usuario final. Los contenidos para los diálogos son definidos de acuerdo a la Lista de Operaciones.

Ilustración 1: Técnica de modelamiento de objeto en C++ (OMT++)

36

2.1 Análisis de objetos.

De la captura de requerimientos se asume que la aplicación tiene como objetivo proveer la funcionalidad de administrar, por parte de la bibliotecaria tanto las reservas, como préstamos y devoluciones de material bibliográfico (memorias, manuales, revistas y libros), solicitado por los alumnos, además de mantener el material y emitir informe estadístico de préstamos. Por tanto los conceptos clave de esta aplicación son: alumno, material, bibliotecaria, informe.

2.1.1. Descripción de Casos de Uso (Quién, Qué, Cómo/Cuando/Donde/Para)

2. Validar alumnoLa bibliotecaria se valida la condición del alumno para registrar un préstamo, consulta o reserva de un material

3. Prestar materialLa bibliotecaria valida la existencia y disponibilidad del material para asignar el préstamo al alumno

4. Consultar material en salaLa bibliotecaria valida la existencia y disponibilidad del material para asignar la consulta al alumno

5. Reservar material La bibliotecaria registra reserva del material para asignar un posterior préstamo al alumno

6. Mantener material La bibliotecaria registra ingreso, modificación o eliminación de material para su posterior solicitud de parte de alumnos

Devolver material La bibliotecaria registra la devolución de material para su posterior solicitud de parte de alumnos

8. Emitir estadísticoLa bibliotecaria emite informe estadístico de préstamos solicitados por los alumnos

37

2.1.2. Identificar clases u objetos (Sustantivos)De la descripción de casos de usos se identificaron los objetos que a de contener la aplicación a desarrollar

ObjetosBibliotecariaAlumnoMaterialInforme

Diagrama clases u objetos (Modelo de Análisis de Objetos)

El diagrama de clases representa a todas las clases identificadas para la aplicación, desprendidas de los casos de usos.

1 1..*

1 1

1..* 1..*

1..* 1..*

(La líneas de relación mencionan a los casos de usos.)

Bibliotecaria

Alumno Material

Informe

Valida

Solicita, Consulta, Reserva, Devuelve

Emite

Mantiene

38

2.2. Análisis de comportamiento.

El análisis de comportamiento produce una lista de operaciones, la cual es construida sobre la base de los casos de uso. Del análisis de los casos de usos se desprenden las siguientes operaciones que son las que realizará el usuario con la aplicación:

2.2.1. Descripción de todas las operaciones por caso de uso

Caso de uso 1: Validar alumno (tomar el caso de uso y considerar sólo las operaciones que realiza el ACTOR)Operaciones: ingresar rut, Aceptar rut, Seleccionar préstamo, Seleccionar consulta, Seleccionar reserva, Aceptar “mensaje”

Caso de uso 2: Prestar materialOperaciones: Ingresa código del material, Aceptar “código”, Asignar el material en préstamo, Aceptar “mensaje”

Caso de uso 3: Consulta en salaOperaciones: Ingresa código del material, Aceptar “código”, Asignar el material en consulta, Aceptar “mensaje”

Caso de uso 4: Reservar materialOperaciones: Ingresa código del material, Aceptar “código”, Asignar el material en reserva, Aceptar “mensaje”

Caso de uso 5: Mantener materialOperaciones: Ingresa código del material, Aceptar “código”, Ingresar datos a modificar, Seleccionar modificar, Seleccionar eliminar, Aceptar “nuevo” material

Caso de uso 6: Devolver materialOperaciones: Ingresa código del material, Aceptar “código”, Ingresar estado de material, Seleccionar devolver material, Aceptar “mensaje”

Caso de uso 7: Emitir estadística de préstamosOperaciones: Selecciona periodo (desde y hasta), Aceptar “ver” informe estadístico, Aceptar “imprimir”

39

2.2.2. Lista de operaciones para la aplicación

De acuerdo al análisis de los casos de usos, se definen las siguientes operaciones para la aplicación:

1. Ingresar rut2. Aceptar rut3. Seleccionar préstamo4. Seleccionar consulta5. Seleccionar reserva6. Aceptar “mensaje”7. Ingresa código del material8. Aceptar “código”9. Asignar el material en préstamo10. Asignar el material en consulta11. Asignar el material en reserva12. Ingresar datos a modificar13. Seleccionar modificar14. Seleccionar eliminar15. Aceptar “nuevo” material16. Ingresar estado de material17. Seleccionar devolver material18. Selecciona periodo (desde y hasta)19. Aceptar “ver” informe estadístico20. Aceptar “imprimir”21. Salir del sistema

40

2.3. Especificación de la interfaz de usuario.

La interfaz de usuario es la encargada de transmitir las órdenes que el usuario realiza al programa y al mismo tiempo presentar información de retroalimentación al usuario. Esta interfaz está compuesta por varias ventanas que se relacionan entre sí por medio de acciones, las cuales pueden ser: presionar un botón, seleccionar un menú.

2.3.1. Diagrama de Diálogos: En aspectos generales, la interfaz de usuario del sistema de biblioteca, esta compuesta de nueve ventanas de diálogo, que realizan las distintas tareas del sistema.

41

2.3.2. Funciones que realiza cada ventana de diálogo

Cada ventana de diálogo realiza funciones propias y para pasar entre las ventanas el usuario debe realizar una acción, ya sea seleccionando un menú o apretando algún botón. (Estas funciones se obtienen desde la redacción de los casos de uso en lo que respecta a la responsabilidad del sistema

La ventana de diálogo Sistema de Biblioteca es la ventana principal sus funciones son: Obtener la hora y fecha del sistema. Selección del menú Validar Alumno (información del alumno).

SeleccionaInformeSalir

Seleccionadevolución

Salir

SeleccionaInformaciónSolicita

mantención

Préstamo Material

Hace:7,8,9

Reserva Material

Hace:7,8,11

Asignapréstamo

Asignareserva

Asi

gn

arSalir

Mensaje

Aceptar

Salir

Informe EstadísticoHace:18,19,20

Sistema Bibliotecaria

Hace:21

MensajeHace:6

Mantención Materiales

Hace:7,8,12,13,14,15

Devolución MaterialHace:7,8,16,17

Consulta Material

Hace:7,8,10

Información Alumno

Hace:1,2,3,4,5

42

Selección del menú Devolución Selección del menú Informes Selección del menú Mantenedor Salir de la aplicación. (21)

La ventana de diálogo Información Alumno es la encargada de validar al usuario de la biblioteca dependiendo de su última matrícula y de sus atrasos en la devolución de material, sus funciones son: Ingresar el número de rut del alumno. (1) Buscar información de alumno (Validar el ingreso del número de rut del alumno. /

Validar que el alumno sea usuario de la biblioteca / Desplegar información del alumno) (2)

Seleccionar menú Préstamo. (3) Seleccionar menú Consulta. (4) Seleccionar menú Reserva. (5) Seleccionar Salir o volver

La ventana de diálogo Préstamo de Material se encarga de asignar el material en préstamo a los usuarios y sus funciones son: Ingresar código de material. (7) Buscar información del material (Validar que exista el material en biblioteca /

Validar disponibilidad del material / Verificar que alumno cumple condición para el préstamo / Buscar si el alumno estaba en nómina de reserva del material / Desplegar datos del material). (8)

Asignar material en préstamo a alumno. (9) Seleccionar Salir o volver

La ventana de diálogo Consulta de Material se encarga de asignar el material en consulta a los usuarios y sus funciones son: Ingresar código de material. (7) Buscar información del material (Validar que exista el material en biblioteca /

Validar disponibilidad del material / Desplegar datos del material) (8) Asignar material en consulta a alumno. (10) Seleccionar Salir o volver

La ventana de diálogo Reserva de Material se encarga de asignar al usuario a una lista de reserva para cada material, sus funciones son: Ingresar código de material. (7) Buscar información del material (Validar que exista el material en biblioteca /

Validar disponibilidad del material / Desplegar datos del material) (8) Agregar al alumno en la lista de reserva. (11) Seleccionar Salir o volver

43

La ventana de diálogo Mensajes se encarga de desplegar los mensajes de error o de alerta al usuario del sistema, sus funciones son: Aceptar el mensaje (6)

La ventana de diálogo Devolución de Material es la encargada de actualizar el sistema cuando un usuario de la biblioteca devuelve el material que se le había prestado o entregado en consulta, sus funciones son: Ingresar código de material. (7) Buscar información del préstamo (Valida que exista el préstamo del material /

Desplegar información del préstamo) (8) Ingresar estado del material (16) Actualizar BD con devolución de material. (17) Seleccionar Salir o volver

La ventana Informes es la encargada de generar los informes y de desplegarlos ya sea por pantalla o por impresora, sus funciones son: Ingresar periodo: fecha desde y hasta (18) Seleccionar ver informe (19) Seleccionar imprimir (20) Seleccionar Salir o volver

La ventana Mantenedor de Material es la encargada de actualizar los registros del material disponible, ingresar nuevo material y eliminar el material que no tiene uso, sus funciones son: Ingresar código de material. (7) Buscar información del material (Valida que exista el material / Desplegar

información del material) (8) Ingresar datos del material (12) Seleccionar modificar, para actualizar BD (13) Seleccionar eliminar, para actualizar BD (14) Seleccionar agregar, para actualizar BD (15) Seleccionar Salir o volver

44

2.3.3. Especificación de Componentes

Las ventanas de diálogo poseen componentes y los componentes se pueden dividir entre herramientas de manipulación y herramientas de retroalimentación. Tomando como base los diagramas de diálogo, se pueden clasificar los componentes de cada ventana de acuerdo su funcionalidad como herramientas, tanto de manipulación como de retroalimentación:

Ventana de Diálogo

Herramientas de Manipulación(operaciones que el usuario hace)

OPERACIONES

Herramientas de Retroalimentación

DATOSSistema de Biblioteca

Iniciar la aplicación (Obtener la hora y fecha del sistema).

Seleccionar menú Validar Alumno (información del alumno).

Seleccionar menú Devolución Seleccionar menú Informes Seleccionar menú Mantenedor Salir de la aplicación.

Fecha Hora

Información Alumno

Ingresar el número de rut del alumno. Buscar información de alumno (Validar el

ingreso del número de rut del alumno. / Validar que el alumno sea usuario de la biblioteca / Desplegar información del alumno)

Seleccionar menú Préstamo. Seleccionar menú Consulta. Seleccionar menú Reserva. Seleccionar Salir o volver

Entrada (ingreso o selección) Número de Rut

Salida (despliegue) Nombres Apellido Paterno Apellido Materno Carrera Alumno Información Atrasos


Ingresar código de material. Buscar información del material (Validar que

exista el material en biblioteca / Validar disponibilidad del material / Verificar que alumno cumple condición para el préstamo / Buscar si el alumno estaba en nómina de reserva del material / Desplegar datos del material).

Asignar material en préstamo a alumno. Seleccionar Salir o volver

Entrada Código de Material

Salida Título Autor Estado

45



exista el material en biblioteca / Validar disponibilidad del material / Desplegar datos del material)

Asignar material en consulta a alumno. Seleccionar Salir o volver



Reserva de Material


exista el material en biblioteca / Validar disponibilidad del material / Desplegar datos del material)

Agregar al alumno en la lista de reserva. Seleccionar Salir o volver



Mensajes Aceptar el mensaje MensajeMantenedor de Material

Ingresar código de material. Buscar información del material (Valida que

exista el material / Desplegar información del material)

Seleccionar nuevo. Seleccionar modificar. Seleccionar eliminar. Seleccionar Salir o volver


Salida Titulo Autor Tipo Detalle


Ingresar código de material. Hacer Click en buscar información del

préstamo (Valida que exista el préstamo del material / Desplegar información del préstamo)

Ingresar estado del material Actualizar BD con devolución de material. Seleccionar Salir o volver

Entrada Código de Material Estado

Salida Titulo Autor Detalle

Informes Ingresar fecha desde y hasta Seleccionar Ver Seleccionar imprimir. Seleccionar Salir o volver

Entrada Fecha desde Fecha hasta Datos del Informe

Cada herramienta de manipulación es una tarea que el usuario realiza y se implementan mediante el uso de botones, menús, sliders, etc. Las herramientas de retroalimentación es información que debe ser presentada al usuario, para ello se utilizan los cuadros de texto, listas, gráficos interactivos, etc.

46

De acuerdo a la clasificación anterior se obtienen los siguientes componentes de diálogo.

Ilustración 1: Componente de Diálogo Sistema de Biblioteca

Ilustración 2: Componente de Diálogo Información Alumno

(previo a un préstamo, consulta o reserva)


Menu (Barra de Herramientas)

Préstamos

Devolución

Informes

Salir

Datos del Sistema

Fecha

Hora

Información Allumno

Devolución de Material Salir

Informes

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



Reserva de Material


Info de alum

Mant.Material

Salir

Mantención de

materiales

1

21

3 4 5

2

47

Ilustración 3: Componente de Diálogo Préstamo de Material

Ilustración 4: Componente de Diálogo Consulta de Material

Préstamo Material

Datos del Material

Asignar Salir


Estado

Menú de Acciones

Información Alumno

Mensajes

Titulo Autor


Datos del Material

Asignar Salir


Estado

Menú de Acciones

Información Alumno

Mensajes

Título Autor

7 8

9

7 8

10

48

Ilustración 5: Componente de Diálogo Reserva de Material

Ilustración 6: Componente de Diálogo Mensaje

Mensaje

Cuadro de Mensaje

Aceptar

Mensaje

Reserva de Material

Datos del Material

Reservar Salir


Estado Lista

Menú de Acciones

Información Alumno

Mensajes

Título Autor7 8

11

6

49

Ilustración 7: Componente de Diálogo Mantenedor de Material

Ilustración 8: Componente de Diálogo Informes

Mantenedor Material

Datos del Material

Nuevo Salir

Código del Material BuscarAutor

Menú de Acciones

Título

Tipo Detalle

Modificar Eliminar

Mensaje


Informes

Datos del Informe

Ver Salir

Fecha Inicio

Menú de Acciones

Período Informe

Texto Informe

Imprimir


7 8

15 13 14

12

18

19 20

50

Ilustración 9: Componente de Diálogo Devolución de Material


Datos del Material

Devolución Salir


Estado

Menú de Acciones

Información Alumno

Mensajes

Título Autor

78

16

17

51

2.3.4. Diseño de la interfaz gráfica utilizando lenguaje

Estos diagramas y componentes de diálogo permiten el diseño de las interfaces gráficas que se aprecian en las siguientes ilustraciones.

Ilustración 2: Interfaz gráfica para el componente de diálogo Sistema de Biblioteca

Ilustración 11: Interfaz gráfica para el componente de diálogo Información Alumno

52

Ilustración 12: Interfaz gráfica para el componente de diálogo Préstamo de Material

Ilustración 13: Interfaz gráfica para el componente de diálogo Consulta de Material

53

Ilustración 14: Interfaz gráfica para el componente de diálogo Reserva de Material

Ilustración 15: Interfaz gráfica para el componente de diálogo Mensaje

Ilustración 16: Interfaz gráfica para el componente de diálogo Mantenedor de Material

54

Ilustración 17: Interfaz gráfica para el componente de diálogo Informes

Ilustración 18: Interfaz gráfica para el componente de diálogo Devolución de Material

55

Bibliografía.

[Aalto94] Juha-Markus Aalto y Ari Jaaksi, “Object – Oriented Development of Interactive Systems with OMT++”, Incluido en TOOLS 14, Technology of Object – Oriented Languajes & Systems, Prentice Hall, 1994.

[Antillanca99] Héctor Antillanca Espina, “Apuntes de la asignatura: Ingeniería de Software Orientada al Objeto”, Universidad de Santiago de Chile, Programa de Magister, Chile, 1999.

2. [Booch96] G. Booch, “UML, Booch & OMT: Quick Reference”, Rational Software Corporation, Estados Unidos, 1996, 12 páginas.

3. [Booch98a] Grady Booch, “Rational Rose: past, present, and future”, Rose Architect, Volumen 1, Número 1, Octubre de 1998, páginas 8 - 10.

4. [Booch98b] Grady Booch, “The Visual Modeling of Software Architecture for the Enterprise”, Rose Architect, Volumen 1, Número 1, Octubre de 1998, páginas 18 - 25.

5. [Companion98] Companion Corporation, “Alexandria for Windows: the multimedia library automation system for schools”, COMPanion Corporation, 1998, información del producto, www.companioncorp.com.

6. [Jaaksi98a] Ari Jaaksi, “A Method for Your First Object – Oriented Project”, Journal of Object – Oriented Programming, Volumen 10, Número 9, Enero de 1998, páginas 17 - 25.

7. [Jaaksi98b] Ari Jaaksi, “Our Cases with User Cases”, Journal of Object – Oriented Programming, Volumen 10, Número 9, Enero de 1998, páginas 58 - 65.

56

III FASEDISEÑO ORIENTADO A OBJETO

DISEÑO OOINDICE INFORME DE DISEÑO ORIENTADO A OBJETOSIntroducciónDiseño de objetos

Modelo de objetos de la capa VISTAModelo de objetos de la capa CONTROLADORs

Diseño de comportamientoElaboración de trazas de eventos

ConclusionesBibliografíaAutoevaluación

OBJETIVO DE LA FASE DEL DISEÑOEl diseño tiene por finalidad especificar cómo será implementada la solución. Define los métodos de las clases

Componentes del diseño.

El diseño orientado a objetos (en adelante DOO) supone que ya se posee las clases aunque sin los métodos. Definir estos últimos es uno de los objetivos del DOO [Antillanca99]. Se supone que:

AOO DOOEl análisis produce descripciones del problema, especifica qué debe hacer el sistema, bosqueja la solución desde el punto de vista del usuario.

El diseño por su parte usa artefactos y especifica cómo será implementada la solución

Los modelos del análisis capturan y ejemplifican conceptos y operaciones desde el punto de vista del usuario

Los modelos del diseño, aparentemente similares a los del análisis, ilustran la implementación del sistema, en varios niveles de abstracción

Los elementos de los modelos del análisis muestran el mundo de los usuarios,

Los elementos del diseño ilustran los conceptos de los programadores

En la figura siguiente se ha destacado los componentes del DOO dentro del contexto de la ingeniería de software orientada al objeto (en adelante ISOO):

57

Ilustración 3: El diseño orientado al objeto en el contexto de la POO.

58

3. Diseño del “Sistema de préstamo bibliotecario”.

3.1. DISEÑO DE OBJETOS Las clases de la vista se obtienen fácilmente de la fase de especificación de la interfaz usuaria. Cada diálogo de los diagramas de diálogo se transforma en una clase vista. Cada componente especificada en los diagramas de diálogo es una componente vista.

Las clases de la capa controlador conectan la vista con el modelo de objetos. Por cada objeto vista existe un único objeto controlador. Un objeto controlador puede estar ligado a múltiples objetos del modelo y un objeto del modelo puede estar ligado a varios objetos controladores.

3.1.1. Modelo de objetos de la capa VISTACada diálogo de la interfaz gráfica representa un objeto compuesto de atributos y métodos (observe cuidadosamente cada diálogo y en él encontrará atributos (datos) y métodos (funciones) que los dispone dentro de la clase

Ilustración 4: Modelo de objetos del diseño (capa VISTA).

Sistema de Bilioteca

FechaHora

ObtFecha()SelPrestamos()SelDevolucion()Sel Informes()Salir()

Información Alumno

num_rutNombresAp_PaternoAp_MaternoCarrera_alumnoInf_ Atrasos

Buscar()Prestamos()Consulta()Reserva()Salir()

Prestamo de Material

Cod_MaterialEstado

Buscar()Asignar()Salir()


Cod_MaterialEstado

Buscar()Asignar()Salir()

Reserva de Material

Cod_MaterialEstado_Lista

Reservar()Salir()

Mensajes

Mensaje

SelAceptar()

Mantenedor de Material

Cod_MaterialTituloAutorTipoDetalle

Buscar()Nuevo()Eliminar()Modificar()Salir()

Devolucioo de Material

Cod_MaterialEstado

Buscar()Devolucion()Salir()

Informes de Material

FechaInicioPeriodoTexto

Ver()Imprimir()Salir()

Préstamo Material


Buscar( )AsignarPrestamo( )Salir()

Consulta en Sala


Buscar( )AsignarConsulta( )Salir()

Consulta en Sala

Cod-matTituloAutorEstadoBuscar( )AsignarReserva( )Salir()

59

3.1.2. Modelo de Objetos de diseño de la capa CONTROLADOR).

Reemplazar por el DER (BD es relacional)En la fase de Análisis OO, se elaboró un primer Modelo de Objetos, pero en

ese entonces lo sustantivo fue identificar cuáles eran los objetos para la aplicación, pues bien, ahora en la fase de Diseño OO, tomamos ese Modelo elaborado en el AOO y agregamos los atributos y métodos que ellos deben contener, bajo la perspectiva de los objetos que manipulará el CONTROLADOR. esto siempre y cuando trabaje con Base de Datos OO, de los contrario, si usted trabaja con Modelo de Base de Datos Relacional DEBE reemplazar este Modelo de Objetos por el Diagrama Entidad Relacional (DER)

1 1..*

1 1

1..* 1..*

1..* 1..*

Ilustración 4: Primer modelo de objetos del diseño. (capa CONTROLADOR, conecta con la BD)

BibliotecariaNombreClaveValidarEmiteMantiene

AlumnoRutNombreCarreraEstadoSolicitaConsultaReservaDevuelve

MaterialCodigoTituloAutorAsigna

InformeDesdeHastaVerImprimir

Valida

Solicita, Consulta, Reserva, Devuelve

Emite

Mantiene

60

Diseño del comportamiento

3.2.1. Elaboración de Trazas de Eventos (diagramas de secuencia).

El diseño orientado al objeto se compone de: las vistas el controlador y el modelo. Las vistas es lo que el usuario ve y con lo que interactúa. Al ejecutar alguna acción el usuario provoca que la vista la interprete y le pida requerimientos al controlador. Este a su vez interactúa con el modelo. Esto se aprecia mejor gráficamente:

Manipulación Realimentación

Usuario

Acciones Solicitudes deInterpretadas atención

Solicita Resultado acción

Ilustración 4: Modelo de las tres capas.

VISTA

CONTROLADOR

MODELO

61

Por cada operación definida en la etapa de análisis se debe generar su traza de eventos o diagrama de secuencia.

Al dibujar las trazas de eventos se especifican las responsabilidades de los objetos del diseño, en definitiva las funciones que llevarán a la práctica.

El nombre de la función es escrito sobre la flecha. Las llamadas a funciones se representan a través de flechas sobre la cual se escribe el nombre de la función y cuando corresponde se señalan los parámetros necesarios entre paréntesis, y los valores retornados de las llamadas a funciones son escritos sin paréntesis.

Las trazas de eventos grafican las hebras de ejecución como normalmente se han de realizar.

A continuación se inicia la construcción de las trazas de eventos para las operaciones especificadas en los casos de usos representando la responsabilidad del Actor y del Sistema

62

2. Validar alumno. Flujo normal o escenario exitosoResponsabilidad del Actor Responsabilidad del Sistema

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

2. Ingresa rut3. Acepta rut

(botón Buscar)

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

4. Valida el ingreso del rut (digitación)5. Valida que alumno sea usuario de

biblioteca 6. Despliega datos del alumno y activa

los casos de uso “Préstamo”, “Consulta” y “Reserva”

8. Fin del caso de uso

IMPORTANTE, Si en la operación n°1 se desea que la pantalla muestre datos, en la traza debe hacer que desde el CONTROLADOR se vaya al MODELO y luego el MODELO debe devolverle los datos al CONTROLADOR y sólo entonces el CONTROLADOR despliega la pantalla en la VISTA

Usuario

1 HabilitaRutyBotones BuscarySalir ( )

2 Ingresa (rut) Cuando se usa teclado

3 Acepta (rut)

Al usar mouse 4 Validaingreso (rut) Trabaja sobre RAM

5 ValidaCondiciónUsuario(rut)

Ir por datos a la BD

6 DevuelveDatos (alumno)

BD retorna los datos leidos6 DespliegaDatos(alumno)

7 SeleccionaPréstamo

Vista Controlador Modelo

Los nombres de los métodos, no tienen porque ser tan extensos, recuerde que un método es sinónimo de una function.

Siempre el método debe llevar ( ). Si llevan datos deben ir entre los paréntesis, pues representan parámetros.

Siempre que se actualiza la BD, esta retorna un flag que señala operación exitosa

Los flujos entre las 3 capas NO debieran estar cortados, deben permitir un tránsito.

Si la última operación del Sistema es derivar a otro caso de uso, no es necesario que aparezca como flujo va dentro de lo que se entiende como fin del caso de uso

63

ConsultaReserva ( )

8 FinCasoUso( )

64

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


Usuario

1 MensajeHabilitaAceptar (“rut mal ingresado”)

2 AceptaMensaje ( )

3 FinFlujoAlternativo( )

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


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


Usuario

1 MensajeHabilitaAceptar (“No registrado”)

2 AceptaMensaje ( )

3 FinFlujoAlternativo( )

; Vista ; Controlador ; Modelo

; Vista ; Controlador ; Modelo

65

Apunte Omt Actualizado Mayo 20101

Documents

Transcript of Apunte Omt Actualizado Mayo 20101