apunte_omt__actualizado_mayo_20101

APUNTE
ASIGNATURA
CARRERA
PROFESORA
:
:
:
:
N-5
SISTEMA DE INFORMACIÓN
Ingeniería en Informática
Magdalena Nieto.
http://www.unab.edu.co/editorialunab/revistas/rcc/pdfs/r11_art4_c.pdf
http://sistemas.itlp.edu.mx/tutoriales/fundamentosdeprog/t21.htm
Para 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
II FASE
III FASE
IV FASE
V FASE
:
:
:
:
:
Conceptualización
Análisis OO
Diseño OO
Construcción
Pruebas
Problem a
CONCEPTUALIZACION
Objetivo
Establecer los requerim ientos básicos para
el sistem a
Actividades
Enunciar el problem a
Rrequerim .funcionales
Requerim .no funcionales
Estudio de factibilidad
Casos de uso
Requerim ientos
DISEÑO
Objetivo
Crear una arquitectura
para la aplicación
Actividades
Modelo de objeto de diseñoM od. de objeto del diseño
Diseño orientado a objetoModelo de tres capas
Traza de eventos
Diagramas de secuencia
ANALISIS
Objetivo
Com prender el dom inio
del problem a y el sistem a
a ser im plem entado
Actividades
Analísis de objeto
Mod. de objeto del análisis
Análisis de com portam iento Especif. de operaciones
Especificación de interfaz Diagram as de diálogos
Diag. de com ponentes
Construcción
Objetivo
Traducir el diseño en
una implementación
Pruebas
Objetivo
Probar el
Sistema
Actividades
Definiciones de clases
Creación de objetos
Llamada de operaciones
Uso de la herencia
Implem. de asociasiones
Actividades
Sist. implementado
Integración
Prueba como Sistema
1
Sis
Diseño
Diagrama de clase
Análisis
Análisis
Diagrama
de clase
X
Atributo
Atributo
Requerimien
Y
atributo
Class Y{
Function3();
Function5();
X;
};
Z
Atributo
Y
Atributo
Atributo
Función 3
Función 5
Caso de uso A
Declarac
Función
Función
6
X
atributo
atributo
Función 1
Función 4
Caso de uso C
...
Lista de
operaciones
Usuario
Otros
requerim.
Código
Caso de uso C
Y::function5()
{
X>function6();
};
...
Trazas
Lista de operaci
Z
Y
X
Operación 1
Función 1
Función 2
Operación 2
Caso de uso A
Caso de uso B
...
Caso de uso B
Prueba de
casos
Otros
requerim.
Función 3
...
Operación 3
Función 4
....
Función 5
Función
6
CONCEPT
ANALISIS
DISEÑO
CONSTRUCCION
2
CONCEPTUALIZACION
Entrevistas
Enunciar
problema
FACTIBILIDAD
Problema
Def. Requerimientos
Funcionales
Def. Requerimientos No
Funcionales
Casos de uso
ANALISIS OO
Parámetros
Análisis de Objetos
Modelo de Objetos
Análisis de Comportamiento
Lista de Operaciones
Especificación de Interfaz de Usuario
Diagrama de Diálogos
DISEÑO OO
Diagramas de Componentes
Modelo de Objetos
Modelo de Objetos
Diseño de Objetos
Modelo de 3 Capas
Traza de Eventos
CONSTRUCCION OO
Definición
de Clases
Diagramas de Secuencia
Creación
De
Objetos
Llamadas
De
Operación
Uso de
Herencia
Implement
ar
Asociación
Probar el
Sistema
3
Sistema en Funcionamiento
CASOS DE USO
10 consideraciones para obtener buenos
autores de OMT++)
casos de uso (Según los
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 FASE
CONCEPTUALIZACION 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 CONCEPTUALIZACION
Se recomiendan los siguientes artefactos en la fase de requerimientos:
1.1) Enunciar el problema
1.2) Requerimientos funcionales: Casos de uso
1.3) Requerimientos no funcionales
1.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
10
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.
Prestar
material
<<incluye>>
DEBE
Verificar
disponibilidad
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.
11
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.
Prestar
material
Bibliotecaria
<<incluye>>
DEBE
Verificar
disponibilidad
<<extensión>>
PUEDE
Contabilizar
rechazos
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.
12
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.
Prestar
material
<<incluye>>
DEBE
Bibliotecaria
<<redefine>>
Prestar On-line
Material
Caso de uso especializado
Verificar
disponibilidad
<<extensión>>
PUEDE
Contar
rechazos
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
13
<<incluye>>
<<extiende>>
<<redefine>> /
<<enriquece>>
Un caso de uso dado debe Un Caso de Uso puede ser
"incluir" otro
“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
Prestar
material
Bibliotecaria
<<redefine>>
Prestar
On-line
Material
<<incluye>>
Verificar
disponibilidad
<<extensión>>
Contar rechazos
Estudiante
14
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
<incluye>
Ver
disponibilidad
<incluye>
Validar
alumno
<incluye>
<incluye>
Reservar
material
<incluye>
<extensión>
Contar
rechazos
Consultar
Material
Devolver
material
<incluye>
Emitir
estadística
<incluye>
Emitir
morosos
Emitir
informes
Agregar
material
Modificar
material
Biblio-
<incluye>
<incluye>
Eliminar
material
Mantener
material
<incluye>
tecaria
Administrador
Autenticar
usuario
Fig. 2.2 Diagrama principal de casos de uso
15
b) CASO DE USO DE GENERALIZACIÓN Y HERENCIA
Estereotipo= compartir
Bibliotecaria
Autentificar
usuario
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.
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.
16
c) CASO DE USO PATRÓN
Navegar la
Tablas
<incluye>
Mantenedor
de Tablas
<incluye>
Agregar en
Tablas
<incluye>
Modificar en
Tablas
Administrador
<incluye>
Eliminar en
Tablas
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.
17
d) CASOS DE USO PARA ACTOR BIBLIOTECARIA
Prestar
material
<incluye>
Ver
disponibilidad
<incluye>
Validar
alumno
<incluye>
Reservar
material
<incluye>
Contar
rechazos
Consultar
Material
<incluye>
<extensión>
Devolver
material
<incluye>
Emitir
estadística
<incluye>
Emitir
morosos
Emitir
informes
Autenticar
usuario
Bibliotecaria
d) CASOS DE USO PARA ACTOR ADMINISTRADOR
Agregar
material
<incluye>
Modificar
material
<incluye>
Eliminar
material
Mantener
material
<incluye>
Administrador
Autenticar
usuario
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
18
CASOS DE USO PARA ACTOR BIBLIOTECARIA
Prestar
material
<incluye>
Validar
alumno
<incluye>
<incluye>
Reservar
material
Consultar
Material
Devolver
material
Emitir
Estadística
Autenticar
usuario
Agregar
material
Bibliotecaria
<incluye>
Mantener
material
<incluye>
Modificar
material
<incluye>
Eliminar
material
19
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.
2.
3.
4.
5.
6.
7.
8.
Logear usuario (bibliotecaria)
Validar alumno
Prestar material.
Consultar material en sala
Reservar material.
Mantener material.
Devolver material.
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.
20
CASO DE USO 2: VALIDAR ALUMNO
Información Alumno
Datos del Alumno
Numero rut
Nombres
Ap. Paterno
Ap. Materno
Buscar
Carrera
Información Atrasos
Menú de Acciones
Préstamo
Préstamo de
Material
Consulta
Consulta de
Material
Reserva
Reserva de
Material
Salir
Sistema de
Biblioteca
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
Bibliotecaria
Pre condiciones
El usuario (bibliotecaria) debe estar autentificado
Flujo normal o escenario exitoso
Responsabilidad 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 rut
3. Acepta rut (botón Buscar)
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
7. Selecciona un caso de uso
uso “Préstamo”, “Consulta” y “Reserva”
“Préstamo”, “Consulta” o
“Reserva”
8. El sistema deriva al caso de uso seleccionado
9. Fin del caso de uso
Flujo alternativo 1: Valida el ingreso del rut (digitación). Si rut fue mal ingresado
Responsabilidad del Actor
Responsabilidad del Sistema
1. Despliega mensaje de “rut mal ingresado” y
2. Acepta el mensaje (botón
habilita botón Aceptar
Aceptar)
3. Fin flujo alternativo 1
Flujo alternativo 2: Valida que alumno sea usuario de biblioteca. Si no es usuario
Responsabilidad del Actor
Responsabilidad del Sistema
1. Despliega mensaje de “alumno no registrado
como usuario de biblioteca” y habilita botón
2. Acepta el mensaje (botón
Aceptar
Aceptar)
3. Fin flujo alternativo 2
Post condición
El usuario es derivado a registrar un préstamo, una consulta o una reserva
21
CASO DE USO 3: PRESTAR MATERIAL
Pré sta mo Ma te ria l
Da tos de l Ma te ria l
Código del
Material
Titulo
Autor
Buscar
Estado
Me nú de Accione s
Asignar
Salir
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 dadas
Actores
Bibliotecaria
Pre condiciones Validación de alumno
Flujo normal o escenario exitoso
Responsabilidad 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)
4. Valida que exista el material en biblioteca
5. Valida disponibilidad del material
6. Verifica que alumno cumpla con las condiciones para el
préstamo
7. Busca si el material lo tenía reservado y lo elimina de la
lista de reserva
8. Despliega datos del material y alumno, además activa el
botón “Asignar Préstamo”
10. Asigna el material en
préstamo (clic en botón)
11. Registra en BD el préstamo
12. 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
2. Acepta el mensaje (botón
botón Aceptar
Aceptar)
3. Fin flujo alternativo 1
Flujo alternativo 2: Valida disponibilidad del material(5). Si no está disponible
Responsabilidad del Actor
Responsabilidad del Sistema
1. Despliega mensaje de “material no disponible” y habilita
2. Acepta el mensaje (botón
botón Aceptar
Aceptar)
3. Fin flujo alternativo 2
Flujo 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 (botón
Aceptar)
3. Fin flujo alternativo 3
Post condición
22
Mensajes
Información
Alumno
Al usuario le queda registrado un préstamo a su haber
CASO DE USO 4: CONSULTA MATERIAL EN SALA –PRÉSTAMO EN SALA
Consulta de Material
Datos del Material
Código del
Material
Título
Autor
Buscar
Estado
Menú de Acciones
Asignar
Salir
Mensajes
Información
4.- Consulta en sala
Alumno
Descripción
Registra material asignado como préstamo en sala
Actores
Bibliotecaria
Pre condiciones Validación de alumno
Flujo normal o escenario exitoso
Responsabilidad 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”
2. Ingresa código del material
3. Acepta
código
(botón
Buscar)
4. Valida que exista el material en biblioteca
5. Valida disponibilidad del material
6. Despliega datos del material y alumno, además
activa el botón “Asignar Préstamo en sala”
7. Asigna el material en
consulta (clic en botón)
8. Registra en BD el préstamo en sala
9. 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
2. Acepta
el
mensaje
(botón Aceptar)
3. Fin flujo alternativo 1
Flujo alternativo 2: Valida disponibilidad del material(5). Si no está disponible
Responsabilidad del Actor
Responsabilidad del Sistema
1. Despliega mensaje de “material no disponible” y
2. Acepta el mensaje (botón
habilita botón Aceptar
Aceptar)
3. Fin flujo alternativo 2
Post condición
Al usuario le queda registrado un préstamo de consulta en sala
23
CASO DE USO 5: RESERVA DE MATERIAL
Reserva de Material
Datos del Material
Código del
Material
Título
Autor
Buscar
Estado Lista
Menú de Acciones
Reservar
Salir
Mensajes
Información
Alumno
5. Reserva de material
Descripción
Registra la reserva de un material
Consulta en Sala
Actores
Bibliotecaria
Pre condiciones Validación de alumno
Cod-mat
Flujo normal o escenario exitoso
Titulo
Autor
Responsabilidad del Actor
Responsabilidad del Sistema
Estado
1. Despliega ventana de reserva de material, habilita
el ingreso del código del libro y el botón
“buscar”
Buscar( )
AsignarConsulta( )
y “salir”
Salir()
2. Ingresa código del material
3. Acepta
código
(botón
Buscar)
5. Valida que exista el material en biblioteca
6. Valida disponibilidad del material
7. Despliega datos del material y alumno, además
activa el botón “Asignar reserva de material”
4. Asigna el material en
reserva (clic en botón)
8. Registra en BD el préstamo en sala
9. 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
2. Despliega mensaje que “no existe el material”
y habilita botón Aceptar
3. Acepta
el
mensaje
(botón Aceptar)
4. Fin flujo alternativo 1
Flujo alternativo 2: Valida disponibilidad del material(5). Si no está disponible
Responsabilidad del Actor
Responsabilidad del Sistema
2. Despliega mensaje de “material no disponible” y
4. Acepta el mensaje (botón
habilita botón Aceptar
Aceptar)
5. Fin flujo alternativo 2
Post condición
Al usuario le queda registrado un préstamo a su haber
24
CASO DE USO 6: MANTENEDOR DE MATERIAL
Mantenedor Material
Datos del Material
Código del
Material
Título
Tipo
Autor
Buscar
Detalle
Menú de Acciones
Nuevo
Modificar
Mensaje
Eliminar
Salir
Sistema de
Biblioteca
6. Mantenedor de material
Descripción
Permite mantener actualizada las existencias de materiales
Actores
Bibliotecaria
Pre condiciones Validación de usuario
Flujo normal o escenario exitoso
Responsabilidad 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”
2. Ingresa código del material
3. Acepta
código
(botón
Buscar)
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”
6. Ingresa datos a modificar
7. Selecciona “Modificar” (clic
en Modificar)
8. Actualiza la BD con la modificación del material
9. Selecciona “Eliminar” (clic
en botón Eliminar)
10. Actualiza la BD con la eliminación del material
11. Fin del caso de uso
Flujo 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
1. Habilita campos para ingresar datos del nuevo
material y habilita botón Guardar “nuevo”
2. Acepta el guardar nuevo
material (botón Nuevo)
3. Fin flujo alternativo 1
Post condición
Las existencias de materiales quedan actualizadas en la BD
25
CASO DE USO 7: DEVOLVER MATERIAL
De volución de Ma te ria l
Da tos de l Ma te ria l
Código del
Material
Título
Autor
Buscar
Estado
Me nú de Accione s
Devolución
Salir
Mensajes
Información
Alumno
7. Devolver material
Descripción
Registra la devolución de un material
Actores
Bibliotecaria
Pre condiciones Validación de alumno
Flujo normal o escenario exitoso
Responsabilidad 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”
2. Ingresa código del material
3. Acepta
código
(botón
Buscar)
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”
7. Si se requiere ingresa
estado del material
8. Selecciona
registrar
“devolución del material
(clic en botón)
9. Registra en BD la devolución
10. 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
2. Acepta el mensaje (botón
Aceptar
Aceptar)
3. Fin flujo alternativo 1
Post condición
El material queda disponible para un nuevo préstamo
26
CASO DE USO 8: EMITIR ESTADISTICA DE PRÉSTAMO EN UN PERIODO
Informes
Datos del Informe
Fecha Inicio
Período Informe
Texto Informe
Menú de Acciones
Ver
Imprimir
Salir
Sistema de
Biblioteca
8. Emitir informe estadístico de préstamos
Descripción
Emitir un estadístico de préstamo dentro de un periodo
determinado
Actores
Bibliotecaria
Pre condiciones Logeo de usuario
Flujo normal o escenario exitoso
Responsabilidad 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)
4. Habilita la posibilidad de imprimir la estadística
5. Acepta “imprimir” (botón
imprimir)
6. Envía estadística a imprimir
7. 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
27
II FASE
ANALISIS ORIENTADO A OBJETO
INDICE INFORME DE ANÁLISIS ORIENTADO A OBJETOS
Introducción
Análisis de objetos
Descripción de Casos de Uso
Identificar clases u objetos (Sustantivos)
Diagrama de objetos
Análisis de comportamiento
Descripción de operaciones por casos de usos
Lista de operaciones para la aplicación
Especificación de interfaz
Diagrama de diálogos
Funciones que realiza cada ventana de diálogo
Especificación de Componentes
Diseño de la interfaz gráfica utilizando lenguaje
Conclusiones
Bibliografía
Autoevaluación
OBJETIVO DE LA FASE DE ANALISIS
El 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 ANALISIS
El 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.
28
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.
Requerimientos del Cliente
AOO
Análisis de
Comportamiento
Análisis de Objeto
Modelo de
Objetos
DOO
Especificación
de
Operaciones
Especificación de
Interfaz Usuaria
Diagramas de
Diálogos
Diseño de
Comportamiento
Diseño de Objeto
Modelo de
Objeto de
Diseño
POO
Diagramas
de
Componentes
Traza de
Eventos
Especificación de
Clases
Declaración de
Clases
Máquina de
Estados
Implementación
de Clases
Implementación
de Métodos
29
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 alumno
La bibliotecaria se valida la condición del alumno para registrar un préstamo,
consulta o reserva de un material
3. Prestar material
La bibliotecaria valida la existencia y disponibilidad del material para asignar el
préstamo al alumno
4. Consultar material en sala
La 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ístico
La bibliotecaria emite informe estadístico de préstamos solicitados por los alumnos
30
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
Objetos
Bibliotecaria
Alumno
Material
Informe
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.
Bibliotecaria
Informe
1
Emite
1..*
1
1
Valida
Mantiene
1..*
1..*
Alumno
Material
1..*
Solicita, Consulta,
Reserva, Devuelve
1..*
(La líneas de relación mencionan a los casos de usos.)
31
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 material
Operaciones: Ingresa código del material, Aceptar “código”, Asignar el
material en préstamo, Aceptar “mensaje”
Caso de uso 3: Consulta en sala
Operaciones: Ingresa código del material, Aceptar “código”, Asignar el
material en consulta, Aceptar “mensaje”
Caso de uso 4: Reservar material
Operaciones: Ingresa código del material, Aceptar “código”, Asignar el
material en reserva, Aceptar “mensaje”
Caso de uso 5: Mantener material
Operaciones: Ingresa código del material, Aceptar “código”, Ingresar datos a
modificar, Seleccionar modificar, Seleccionar eliminar, Aceptar “nuevo” material
Caso de uso 6: Devolver material
Operaciones: 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éstamos
Operaciones: Selecciona periodo (desde y hasta), Aceptar “ver” informe
estadístico, Aceptar “imprimir”
32
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.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
Ingresar rut
Aceptar rut
Seleccionar préstamo
Seleccionar consulta
Seleccionar reserva
Aceptar “mensaje”
Ingresa código del material
Aceptar “código”
Asignar el material en préstamo
Asignar el material en consulta
Asignar el material en reserva
Ingresar datos a modificar
Seleccionar modificar
Seleccionar eliminar
Aceptar “nuevo” material
Ingresar estado de material
Seleccionar devolver material
Selecciona periodo (desde y hasta)
Aceptar “ver” informe estadístico
Aceptar “imprimir”
Salir del sistema
33
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.
Informe Estadístico
Hace:18,19,20
Selecciona
devolución
Sistema
Bibliotecaria
Hace:21
Salir
Solicita
mantención
Mantención
Materiales
Hace:7,8,12,13,14,15
Préstamo
Material
Hace:7,8,9
Salir
Selecciona
Asigna
préstamo
Información
Información
Alumno
Hace:1,2,3,4,5
Asignar
Salir
Selecciona
Informe
Devolución Material
Hace:7,8,16,17
Consulta
Material
Hace:7,8,10
Salir
Mensaje
Hace:6
Aceptar
Asigna
reserva
Reserva
Material
Hace:7,8,11
Mensaje
34
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).
 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)
35
 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
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
36
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
Sistema de
Biblioteca
Información
Alumno
Préstamo de
Material
Herramientas de Manipulación
(operaciones que el usuario hace)
OPERACIONES
Herramientas de
Retroalimentación
DATOS
 Iniciar la aplicación (Obtener la hora y fecha  Fecha
 Hora
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.
 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
 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 (ingreso o
selección)
 Número de Rut
Salida (despliegue)
 Nombres
 Apellido Paterno
 Apellido Materno
 Carrera Alumno
 Información Atrasos
Entrada
 Código de Material
Salida
 Título
 Autor
 Estado
37
 Ingresar código de material.
 Buscar información del material (Validar que
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
 Ingresar código de material.
Material
 Buscar información del material (Validar que
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
Mantenedor
 Ingresar código de material.
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
Devolución de  Ingresar código de material.
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
Informes
 Ingresar fecha desde y hasta
 Seleccionar Ver
 Seleccionar imprimir.
 Seleccionar Salir o volver
Consulta de
Material
Entrada
 Código de Material
Salida
 Título
 Autor
 Estado
Entrada
 Código de Material
Salida
 Título
 Autor
 Estado
 Mensaje
Entrada
 Código de Material
Salida
 Titulo
 Autor
 Tipo
 Detalle
Entrada
 Código de Material
 Estado
Salida
 Titulo
 Autor
 Detalle
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.
38
De acuerdo a la clasificación anterior se obtienen los siguientes componentes
de diálogo.
Sistema de Biblioteca
Menu (Barra de Herramientas)
Datos del Sistema
InfoPréstamos
de alum
Fecha
21
Devolución
Salir
Hora
Informes
Salir
Mant.Material
Devolución de
Material
Salir
Mantención de
materiales
Informes
Información
Allumno
Ilustración 1: Componente de Diálogo Sistema de Biblioteca
Información Alumno
2
Datos del Alumno
Numero rut
1
Buscar
Nombres
Ap. Paterno
Ap. Materno
Carrera
Información Atrasos
Menú de Acciones
3
4
Préstamo
Consulta
Préstamo de
Material
Consulta de
Material
5
Reserva
Reserva de
Material
Salir
Sistema de
Biblioteca
Ilustración 2: Componente de Diálogo Información Alumno
(previo a un préstamo, consulta o reserva)
39
Préstamo Material
Datos del Material
7
Código del
Material
8
Titulo
Autor
Buscar
Estado
Menú de Acciones
9
Asignar
Salir
Ilustración 3: Componente de Diálogo Préstamo de Material
Mensajes
Información
Alumno
Consulta de Material
Datos del Material
7
Código del
Material
8
Título
Autor
Buscar
Estado
Menú de Acciones
10
Asignar
Salir
Mensajes
Información
Alumno
Ilustración 4: Componente de Diálogo Consulta de Material
40
Reserva de Material
Datos del Material
7
Código del
Material
8
Título
Autor
Buscar
Estado Lista
Menú de Acciones
11
Reservar
Salir
Mensajes
Información
Alumno
Ilustración 5: Componente de Diálogo Reserva de Material
Mensaje
Cuadro de
Mensaje
Mensaje
6
Aceptar
Ilustración 6: Componente de Diálogo Mensaje
41
Mantenedor Material
Datos del Material
7
8
Código del
Material
Título
Autor
12
Tipo
Buscar
Detalle
Menú de Acciones
15
13
Nuevo
14
Modificar
Eliminar
Salir
Sistema de
Biblioteca
Mensaje
Ilustración 7: Componente de Diálogo Mantenedor de Material
Informes
Datos del Informe
Fecha Inicio
18 Período Informe
Texto Informe
Menú de Acciones
19
20
Ver
Imprimir
Salir
Sistema de
Biblioteca
Ilustración 8: Componente de Diálogo Informes
42
Devolución de Material
Datos del Material
7
Código del
Material
Título
Autor
8
Buscar
Estado
16
Menú de Acciones
17
Devolución
Salir
Mensajes
Información
Alumno
Ilustración 9: Componente de Diálogo Devolución de Material
43
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
44
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
45
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
46
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
47
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.
48
III FASE
DISEÑO ORIENTADO A OBJETO
DISEÑO OO
INDICE INFORME DE DISEÑO ORIENTADO A OBJETOS
Introducción
Diseño de objetos
Modelo de objetos de la capa VISTA
Modelo de objetos de la capa CONTROLADORs
Diseño de comportamiento
Elaboración de trazas de eventos
Conclusiones
Bibliografía
Autoevaluación
OBJETIVO DE LA FASE DEL DISEÑO
El 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
El análisis produce descripciones
del problema, especifica qué
debe hacer el sistema, bosqueja
la solución desde el punto de
vista del usuario.
Los modelos del análisis capturan
y ejemplifican conceptos y
operaciones desde el punto de
vista del usuario
Los elementos de los modelos del
análisis muestran el mundo de
los usuarios,
DOO
El diseño por su parte usa artefactos y
especifica cómo será implementada la
solución
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 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):
49
Requerimientos del Cliente
AOO
Análisis de
Comportamiento
Análisis de Objeto
Modelo de
Objetos
DOO
Especificación
de
Operaciones
Especificación de
Interfaz Usuaria
Diagramas de
Diálogos
Diseño de
Comportamiento
Diseño de Objeto
Modelo de
Objeto de
Diseño
POO
Diagramas
de
Componentes
Traza de
Eventos
Especificación de
Clases
Declaración de
Clases
Máquina de
Estados
Implementación
de Clases
Implementación
de Métodos
Ilustración 3: El diseño orientado al objeto en el contexto de la POO.
50
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 VISTA
Cada 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
Sistema de
Bilioteca
Fecha
Hora
ObtFecha()
SelPrestamos()
SelDevolucion()
Sel Informes()
Salir()
Consulta en Sala
Reserva de Material
Información Alumno
Prestamo de
Préstamo
Material
Material
num_rut
Nombres
Ap_Paterno
Ap_Materno
Carrera_alumno
Inf_ Atrasos
Cod-mat
Titulo
Cod_Material
Estado
Autor
Estado
Titulo
Cod_Material
Estado
Autor
Buscar()
Prestamos()
Consulta()
Reserva()
Salir()
Buscar(
)
Buscar()
Asignar()
AsignarPrestamo(
)
Salir()
Salir()
Buscar( )
Buscar()
Asignar()
AsignarConsulta(
Salir()
Salir()
Mensajes
Consulta de
Consulta
en Sala
Material
Cod-mat
Estado
)
Mantenedor de
Material
Cod-mat
Cod_Material
Titulo
Estado_Lista
Autor
Estado
Buscar( )
Reservar()
AsignarReserva( )
Salir()
Salir()
Devolucioo de
Material
Cod_Material
Estado
Buscar()
Devolucion()
Salir()
Mensaje
SelAceptar()
Informes de Material
Cod_Material
Titulo
Autor
Tipo
Detalle
Buscar()
Nuevo()
Eliminar()
Modificar()
Salir()
FechaInicio
Periodo
Texto
Ver()
Imprimir()
Salir()
Ilustración 4: Modelo de objetos del diseño (capa VISTA).
51
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)
Bibliotecaria
Nombre
Clave
Validar
Emite 1
Mantiene
1
Emite
1..*
1
Informe
Desde
Hasta
Ver
Imprimir
Mantiene
Valida
1..*
1..*
Alumno
Rut
Nombre
Carrera
Estado
Solicita
Consulta
Reserva
Devuelve
1..*
Solicita, Consulta,
Reserva, Devuelve
1..*
Material
Codigo
Titulo
Autor
Asigna
Ilustración 4: Primer modelo de objetos del diseño. (capa CONTROLADOR, conecta con la BD)
52
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
VISTA
Acciones
Interpretadas
Solicitudes de
atención
CONTROLADOR
Solicita
acción
Resultado
MODELO
Ilustración 4: Modelo de las tres capas.
53
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
54
2. Validar alumno.
Flujo normal o escenario exitoso
Responsabilidad 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 rut
3. Acepta rut (botón Buscar)
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”
7 Selecciona un caso de uso
“Préstamo”, “Consulta” o
“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
Vista
Controlador
1 HabilitaRutyBotones
BuscarySalir ( )
2 Ingresa (rut)
Cuando se usa teclado
3 Acepta (rut)
 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

Modelo
 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
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 leidos
6 DespliegaDatos(alumno)
7 SeleccionaPréstamo
ConsultaReserva ( )
8 FinCasoUso( )
55
Flujo alternativo 1: Valida el ingreso del rut (digitación). Si rut fue mal ingresado
Responsabilidad del Actor
Responsabilidad del Sistema
1. Despliega mensaje de “rut mal ingresado” y
2. Acepta el mensaje (botón
habilita botón Aceptar
Aceptar)
3. Fin flujo alternativo 1
Usuario
; Vista
; Controlador
; Modelo
1 MensajeHabilitaAceptar (“rut mal ingresado”)
2 AceptaMensaje ( )
3 FinFlujoAlternativo( )
Flujo alternativo 2: Valida que alumno sea usuario de biblioteca. Si no es usuario
Responsabilidad del Actor
Responsabilidad del Sistema
1. Despliega mensaje de “alumno no registrado
como usuario de biblioteca” y habilita botón
2. Acepta el mensaje (botón
Aceptar
Aceptar)
3. Fin flujo alternativo 2
Usuario
; Vista
; Controlador
; Modelo
1 MensajeHabilitaAceptar (“No registrado”)
2 AceptaMensaje ( )
3 FinFlujoAlternativo( )
56